规范驱动开发（Spec-Driven Development，SDD）的价值，不在于把所有实现细节都提前写完，而在于把"什么叫正确"定义成可审查、可追踪、可验证的契约，从而降低 AI 编程过程中的理解偏差和实现失控风险。
SDD 最适合高风险场景的原因，不是它能替代设计和编码，而是它能把需求红线、关键设计决策和验证机制前置，让 AI 的实现处于可控边界内。
SDD 解决的不是"写代码"，而是"定义正确性"
高风险场景里的真正问题，通常不是"能不能写出代码"，而是"写出来的代码是否可靠地满足业务约束、审计要求和异常边界"。
在这类场景中，SDD 的职责是把业务不变量、范围边界、验收标准和禁止项明确下来，使团队先对"对错标准"达成一致，再进入设计与实现阶段。更准确地说，SDD 是把需求从自然语言意见，转化为可执行约束和验证依据的过程；如果没有后续的设计分层、任务拆解和 verify 机制，spec 很容易重新退化成静态文档。
设计细节不能消失，只是要分层管理
SDD 并不排斥设计，相反，它要求关键设计决策被显式承载，而不是留给 AI 在生成代码时临场猜测。OpenSpec 相关实践通常会将 spec 与 design 分开：spec 负责定义目标、边界和验收；design 负责解释如何在具体架构中实现这些要求，例如模块边界、事务策略、幂等机制、状态流和错误处理。
这种分层的意义在于，团队可以把"红线"与"机制"区分开。前者决定什么不能破坏，后者决定用什么方法实现；这样既不会让 spec 变成巨型技术文档，也不会让关键设计空白到只能依赖 vibe coding 来临时补全。
OpenSpec 更适合管理约束与变更，不适合独自承载全部实现控制
OpenSpec 的公开资料展示了 proposal、apply、archive 这类以变更为中心的流程，重点是让 AI 编程建立在已批准的需求与设计上下文之上，而不是根据一次对话即兴生成大段代码。
比较成熟的团队做法通常不是"让 OpenSpec 管一切"，而是把它放在一组协同机制中：
- OpenSpec 管 intent、范围和约束，设计文档或 ADR 管关键机制决策，
- AI coding agent 管 task 级别的实现，
- CI 与验证体系负责兜底。
这种组合比"只靠 spec"或者"只靠 vibe coding"都更稳，因为它同时解决了上下文丢失、关键决策缺位和实现不可验证的问题。
受约束编码的核心：先约束，再拆解，再生成
较一致的实践路径是：
- 先写 spec 定义目标与边界，
- 再写 design 补关键机制，
- 然后把工作拆成小任务，最后让 AI 按 task 执行，
- 并在每一步都附带验证条件。
一个有效的 task 通常应至少包含四类信息：目标、涉及文件、必须遵守的约束、完成后的验证方式。例如，"给提现服务增加单日额度校验；仅修改 WithdrawalService、LimitPolicy 与测试文件；不得改变 API 契约；必须覆盖额度边界、重复请求与跨日重置测试"，这样的任务就比"帮我实现提现限额"更能约束 AI 的自由发挥。
不应把高风险核心逻辑交给无约束的 vibe coding
vibe coding 的价值主要在探索、原型和低风险功能上，它擅长快速试错，但不擅长承担必须可审计、可回归、可证明正确的核心逻辑。 在高风险场景中，若没有 spec、design 和验证框架，AI 很容易在边界处理、异常路径、并发状态和历史兼容性上产生隐性错误，而这些错误往往难以通过表面功能演示发现。
这并不意味着高风险项目不能使用 AI 编码。更合理的方式是：
- 将普通实现细节、样板代码、接口胶水、测试脚手架交给 AI；
- 而把业务红线、关键设计、事务策略、权限模型和审计要求保留在人主导的 spec/design 体系中。
换句话说，vibe coding 不是被彻底否定，而是被限制在"护栏之内"的局部实现阶段。
验证是 SDD 真正落地的分水岭
如果 spec 不能进入验证闭环，它最终仍会变成"写过但没人持续依赖"的文档。OpenSpec 官方公开说明也明确表示，AI 生成代码可以接受，但前提是经过测试和验证，这反映出 spec-driven 开发的关键不在"AI 是否参与编码"，而在"实现是否被验证为符合契约"。
因此，高风险场景中的 verify 不应只依赖单元测试，还应覆盖契约测试、边界测试、回归测试、静态检查、关键不变量断言，以及必要的人审卡点。
只有当 spec 中的关键规则能够映射到自动化验证或明确 review checklist 时，SDD 才真正从"规则定义"走向"工程控制"。
可执行的团队落地模式
将上述最佳实践转化为团队工作方式时，可以采用一个简洁的四层分工：
- Spec 定义 correctness，
- Design 定义 mechanism，
- Task 定义 execution boundary，
- Verify 定义 pass/fail。
这种模式兼顾了架构治理与 AI 效率，特别适合需要在复杂系统中控制需求漂移和实现失真的团队
一个典型的交付链条可以是：
- 先提交变更 proposal，明确需求意图、风险边界和验收标准；
- 再补充设计说明，写清事务、状态、幂等、权限或审计等关键机制；
- 之后将工作拆成多个可 review 的 task，由 AI 分步实现；
- 最后通过 CI、测试与人工 review 完成验证和归档。
这种方式的重点不在"让 AI 少写"，而在"让 AI 只在受控空间内高效地写"。
最佳实践总结
高风险场景需求
综合来看，高风险场景下的 SDD 最佳实践不是"用 spec 替代实现"，而是建立一套从 intent 到 verify 的控制闭环。
- Spec 负责写清不能错的业务契约，
- Design 负责写清关键实现机制，
- AI 负责在受约束的 task 中高效生成代码，
- Verify 负责判断产物是否真的符合契约。
真正值得推广的实践，不是把所有工作都塞进 OpenSpec，也不是把复杂问题重新交给无约束的 vibe coding，而是在二者之间建立清晰的责任边界：用规范保护高风险部分，用设计补足关键机制，用 AI 加速低歧义实现，用验证守住最后的正确性底线。
中风险（功能迭代）：Plan Mode + 一页轻量 Spec。
低风险简单需求："轻约束 prompt"
可以让 AI 直接实现，但最好只实现一个小任务，不要一次生成整个 feature。
生成后必须 review 和 run tests，把 AI 代码当作默认不可信输入处理。
你不一定每次都要完整写 spec.md，但至少要把 AI 锁在一个明确任务里。Spec-first 实践普遍强调，spec 是 source of truth，任务要围绕 behavior、inputs/outputs 和 edge cases 来定义，而不是只给一句模糊意图。
比如不要这样说：
- "帮我把提现功能补完整。"
而更建议这样说：
- "在现有
WithdrawalService上增加单日额度校验。" - "不要改 controller 和 API 契约。"
- "复用现有
LimitPolicy接口，不新增第三方依赖。" - "补 3 类测试：额度边界、重复提交、跨日重置。"
- "先给 implementation plan，再修改代码。"
这已经不是典型 vibe coding 了，而是很轻量的受约束编码。