在已有项目里使用 AI，最大风险通常不是写不出来，而是改得太多、影响太广。OpenSpec 的价值，就是在每次协作前先把变更范围说清楚，让 AI 在明确边界内工作。
核心理念先限定范围，再开始改动
避免 AI 在复杂项目里到处联想、顺手改一片。
适用场景已有系统功能迭代和修复
尤其适合需要稳妥修改、不能大范围重构的项目。
主要价值减少误改和扩散风险
让每次协作都更像一次受控修改，而不是模糊探索。
核心理念
OpenSpec 的本质不是多一份文档，而是让“这次允许改什么、不允许碰什么”在动手前就变得明确。
- 每次改动都应有清晰范围。
- 把允许修改的模块、目标和边界讲清楚。
- 减少 AI 因上下文不完整导致的误改。
使用场景
它最适合用于已经在线、已有复杂逻辑、需要稳定演进的项目。
- 已有项目的功能迭代。
- 老系统中的 Bug 修复。
- 对影响范围敏感的局部优化。
工作流程
1. 定义变更范围
明确本次只处理什么问题，涉及哪些模块。
2. 编写 OpenSpec
把边界、约束、目标和验收条件写清楚。
3. AI 生成代码
让 AI 基于受控输入执行修改，而不是自由发挥。
4. 验证影响范围
检查改动是否仍然停留在预期边界内。