规格驱动开发（Spec-Driven Development）

直接让智能体「做个登录功能」，它只能靠猜：猜字段、猜错误提示、猜跳转逻辑，结果往往要反复返工。规格驱动开发（Spec-Driven Development）把顺序倒过来，先写一份简短规格，讲清输入输出、边界情况与验收方式，再让智能体按规格实现。规格在这里同时充当提示词、检查清单与交接文档，是人与智能体之间的契约。

规格里要有什么

• 目标与范围：这次要做什么、明确不做什么，避免顺手改动无关模块。
• 接口契约：函数签名、请求响应字段与类型、错误码，越具体越省返工。
• 边界与异常：空值、超长输入、并发重复提交分别应该怎样处理。
• 验收标准：写成可执行的检查项，例如哪几条测试必须通过。
• 约束条件：依赖哪些现有模块、遵循什么命名与目录约定。

为什么它比长提示词更稳

长提示词是一次性的，写完就散落在对话里；规格是持久产物，可以评审、可以版本化、可以在下一轮对话里重新贴给智能体。它的另一个作用是让分歧提前暴露：字段该不该可空、错误码怎么定义，这些在写规格时就必须决定，而不是等代码写完才发现两边理解不同。规格还能反过来当作验收依据，实现是否完成不靠感觉判断。

常见误区

• 规格写得比代码还长：重点是把容易产生分歧的地方钉死，其余交给实现者判断。
• 与代码不同步：规格要和代码放在一起并随改动更新，否则下一个人读到的是过期描述。
• 矛盾时自行选择：智能体实现中发现规格矛盾应停下来澄清，而不是自己挑一种解释。
• 只写正常路径：异常与边界不写清，实现时就会被随意填补，返工概率很高。
• 当成一次性文档：需求变化后规格要跟着改，否则契约失效，返工重新出现。

和测试驱动开发的关系

规格驱动开发与测试驱动开发的思路接近，都要求先把「什么算完成」写下来，再动手实现。区别在于粒度和执行者：测试用例是精确、可自动执行的断言，规格则更偏描述性，允许人参与判断。实践中两者可以叠用——规格给出目标与边界，验收标准落成测试用例，智能体实现时按测试结果自查，人只需要评审规格与最终结果。

可以从模板化开始：把规格存成仓库里的固定文件，列出目标、接口、边界与验收四类必填小节，再写一个小脚本在提交前检查缺项，缺了就让任务停下来补齐。这样「规格是否齐备」由脚本判定，而不是靠人记得，返工大多来自没写清的地方，也更容易在评审时被发现。