规格驱动开发中规格错误被稳定放大的风险
风险描述
在规格驱动开发（Spec-driven development）流程中，AI 助手会按 proposal、spec、design、tasks 等结构化文档推进开发。这意味着：spec 越清晰、越结构化，Agent 越能稳定执行；但反过来，一旦 spec 本身写错（业务目标错、验收条件错、范围边界错），AI 也会更稳定地实现错误目标，而不是通过试错暴露歧义。
风险要点
- 规格错误被稳定放大：自然语言直接改代码时，Agent 偶尔会"自我怀疑"；在结构化 spec 驱动下，Agent 会更顺畅地实现错的目标。
- 文档维护成本：每次变更都要维护 proposal、spec、design、tasks 与归档；规范越完整，维护成本越高，若不坚持容易出现"前期文档与后期实现脱节"。
- 形式完整但实际测试不足：文档齐全不代表代码被充分验证；常见失败模式是 spec 通过、归档齐全，但测试覆盖不到关键路径——见 risks/risk-coding-agent-passes-test-but-wrong-business-logic。
- 工具版本兼容变化：OpenSpec 的具体命令和目录结构可能随上游版本变化，过期文档会误导 Agent 与新成员。
- 范围蔓延：proposal 中的"范围"一旦被 Agent 严格执行，反而会切断合理的小幅调整；反之若 proposal 留口子，又会失去约束力。
触发场景
- 业务目标本身没想清楚就写 spec。
- 验收条件由 AI 起草后没有人工核对。
- 团队或 Agent 在新会话中没有重读 spec，而是基于"上次就是这么做的"惯性推进。
- 跨多个 Agent / 多个会话协作时，spec 在不同分支上漂移——见 risks/risk-coding-agent-context-drift-and-business-miss。
缓解方式
- 业务目标、技术边界、完成标准由人确认，AI 仅负责起草。
- 每项任务完成后运行测试并对照 spec 验收，不能仅依赖 Agent 自报"已完成"。
- 跨会话协作时，把 spec 与归档一起作为新会话的必读上下文。
- 在 CLAUDE.md 项目级指令文件（Claude Code 项目宪法） 等项目级指令中明确"先读 spec 再动手"。
- 定期回头校对 proposal / spec 与最新实现的一致性。
关联方法与任务
来源边界
本风险条目基于作者 ForceInjection 在 OpenSpec-practise 中的实践整理与边界声明；并非来自独立部署或性能测试。