规范驱动开发Spec-Driven DevelopmentSDD的价值不在于把所有实现细节都提前写完而在于把“什么叫正确”定义成可审查、可追踪、可验证的契约从而降低 AI 编程过程中的理解偏差和实现失控风险。关键词契约与共识、约束范围边界、验证符合契约一、SDD 解决的不是“写代码”而是“定义正确性”高风险场景里的真正问题通常不是“能不能写出代码”而是“写出来的代码是否可靠地满足业务约束、审计要求和异常边界”。在这类场景中SDD 的职责是把业务不变量、范围边界、验收标准和禁止项明确下来使团队先对“对错标准”达成一致再进入设计与实现阶段。更准确地说SDD 是把需求从自然语言意见转化为可执行约束和验证依据的过程如果没有后续的设计分层、任务拆解和 verify 机制spec 很容易重新退化成静态文档。二、设计细节不能消失只是要分层管理OpenSpec 相关实践通常会将 spec 与 design 分开spec 负责定义目标、边界和验收design 负责解释如何在具体架构中实现这些要求例如模块边界、事务策略、幂等机制、状态流和错误处理。这种分层的意义在于团队可以把“红线”与“机制”区分开。前者决定什么不能破坏后者决定用什么方法实现这样既不会让 spec 变成巨型技术文档也不会让关键设计空白到只能依赖 vibe coding 来临时补全。三、OpenSpec 更适合管理约束与变更不适合独自承载全部实现控制比较成熟的团队做法通常不是“让 OpenSpec 管一切”而是把它放在一组协同机制中OpenSpec 管 intent、范围和约束设计文档或 ADR 管关键机制决策AI coding agent 管 task 级别的实现CI 与验证体系负责兜底。这种组合比“只靠 spec”或者“只靠 vibe coding”都更稳因为它同时解决了上下文丢失、关键决策缺位和实现不可验证的问题。四、受约束编码的核心先约束再拆解再生成较一致的实践路径是先写 spec 定义目标与边界再写 design 补关键机制然后把工作拆成小任务最后让 AI 按 task 执行并在每一步都附带验证条件。一个有效的 task 通常应至少包含四类信息目标、涉及文件、必须遵守的约束、完成后的验证方式。例如“给提现服务增加单日额度校验仅修改WithdrawalService、LimitPolicy与测试文件不得改变 API 契约必须覆盖额度边界、重复请求与跨日重置测试”这样的任务就比“帮我实现提现限额”更能约束 AI 的自由发挥。五、不应把高风险核心逻辑交给无约束的 vibe codingvibe coding 的价值主要在探索、原型和低风险功能上它擅长快速试错但不擅长承担必须可审计、可回归、可证明正确的核心逻辑。 在高风险场景中若没有 spec、design 和验证框架AI 很容易在边界处理、异常路径、并发状态和历史兼容性上产生隐性错误而这些错误往往难以通过表面功能演示发现。这并不意味着高风险项目不能使用 AI 编码。更合理的方式是将普通实现细节、样板代码、接口胶水、测试脚手架交给 AI而把业务红线、关键设计、事务策略、权限模型和审计要求保留在人主导的 spec/design 体系中。换句话说vibe coding 不是被彻底否定而是被限制在“护栏之内”的局部实现阶段。六、验证是 SDD 真正落地的分水岭从规则到工程控制的关键如果 spec 不能进入验证闭环它最终仍会变成“写过但没人持续依赖”的文档。OpenSpec 官方公开说明也明确表示AI 生成代码可以接受但前提是经过测试和验证这反映出 spec-driven 开发的关键不在“AI 是否参与编码”而在“实现是否被验证为符合契约”。因此高风险场景中的 verify 不应只依赖单元测试还应覆盖契约测试、边界测试、回归测试、静态检查、关键不变量断言以及必要的人审卡点。只有当 spec 中的关键规则能够映射到自动化验证或明确 review checklist 时SDD 才真正从“规则定义”走向“工程控制”。七、可执行的团队落地模式将上述最佳实践转化为团队工作方式时可以采用一个简洁的四层分工Spec 定义 correctnessDesign 定义 mechanismTask 定义 execution boundaryVerify 定义 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 了而是很轻量的受约束编码。