面向 AI 编码代理的规范驱动开发
规范驱动开发（SDD）是一种实践，其中一份书面、可测试的规范——需求与验收标准—— 是构建代码并据以验证代码的唯一可信来源。 与其直接从提示词或工单走向代码， 你先就软件必须做什么达成一致，然后按照这份规范来构建。如今 AI 代理已经在编写大量代码， 规范正是让它们持续构建正确东西的东西。
- 规范是唯一可信来源；代码由它派生，并对照它来检查。
- 需求与明确的验收标准配对，因此“完成”是可测试的，而非主观的。
- AI 代理向规范查询意图，而不是从代码中猜测——更少的错误构建。
- 它与测试驱动开发互补，而非取而代之。
最后更新：2026年5月
什么是规范驱动开发？
规范驱动开发颠倒了通常的工作顺序。它不把规范当作事后补写的文档——也不把它完全跳过—— 而是让规范成为首要的产物。代码、测试和评审都追溯回它。
这个意义上的规范不是一堵文字墙。它是结构化的：一组需求，每条都带有明确的验收标准， 以可测试的措辞说明要让该需求被满足，什么必须为真。正是这种结构， 让评审者、测试套件和 AI 代理都能以相同的方式解读同一份文档。
规范还是一个活的产物。当需求改变时，规范先改变，代码随之跟进—— 因此规范永远不会漂移成虚构。
为什么现在重要：AI 抬高了赌注
AI 编码代理生成代码的速度远快于人能读它的速度。这转移了瓶颈。难的部分不再是敲出实现， 而是把意图说明得足够清楚，使生成的代码就是你想要的代码。 一个被给到模糊提示词的代理，会自信地产出看似合理却错误的东西，而且是以机器的速度。
规范就是那道护栏。当预期行为和验收标准被写下来，代理就有了一个明确的构建目标， 以及一份据以验证的检查清单——而人类评审者在任何代码存在之前，就有了一个固定的东西可以批准。 SDD 是团队避免让 AI 的速度变成 AI 返工的方式。
规范驱动开发如何运作
工作流是一个循环，而不是一份一次性的文档：
- 捕捉意图。 在确定解决方案之前，先记录尚未成形的方向——问题、目标、未决问题。
- 规定行为。 把达成一致的方向转化为需求，每条都带有明确、可测试的验收标准。
- 分解为计划。 把规范拆成有序的任务，每个任务都引用它所满足的验收标准。
- 实现。 按照规范，逐个任务地构建——由人或 AI 代理完成。
- 对照标准验证。 用验收标准而非感觉来检查结果。
- 让规范保持鲜活。 当需求改变时，先更新规范；代码随之跟进。
规范驱动开发的好处
- 分歧在规范评审期间浮现——成本低——而不是在实现之后——成本高。
- “完成”是客观的，因为验收标准是可测试的。
- 规范是所有人的共享上下文：产品、工程和 AI 代理。
- 变更可追溯——每个任务都指回它所满足的标准。
为什么它对 AI 代理尤其有帮助
- 机器可读的意图： 代理直接读取需求，而不是从代码中推断它们。
- 需要加载的上下文更少： 代理查询规范中相关的一片，而不是整个代码仓库。
- 可验证的输出： 验收标准给代理一个具体的通过/不通过目标。
- 可追溯性： 生成的代码可以回溯到促成它的需求。
规范驱动开发与相关实践的对比
| 实践 | 唯一可信来源 | 与 SDD 的关系 |
|---|---|---|
| 测试驱动开发 | 代码层面失败的测试 | 互补——验收标准成为那些测试。 |
| 传统 PRD | 为人撰写的散文 | 结构化程度较低；不能直接测试，也不可被机器读取。 |
| 仅靠提示词（“vibe coding”） | 提示词和模型的猜测 | 没有持久、可评审的目标——这正是 SDD 存在要修复的问题。 |
要查看 SpecScore 与其他规范工具的详细对比，请参见对比页面。
权衡，以及何时不要使用它
规范驱动开发并非免费。它把精力前置到在任何代码运行之前去思考和书写， 对于一次性脚本或用完即弃的实验来说，这是一笔错误的交易。而且规范只有在保持最新时才有帮助—— 一份任其腐烂的规范会变得具有误导性，比没有还糟。当工作大到值得规划、需要被维护， 或要交给 AI 代理大规模构建时，SDD 才会获得回报。
在实践中与 AI 代理一起做规范驱动开发
要与 AI 代理一起运行 SDD，你需要两样东西：一种你的团队和代理都能理解的机器可读的 规范格式，以及一种让代理读取、写入和验证这些规范的方式。
SpecScore 正是这样的一种实现。它是一种面向特性、需求和验收标准的开放 Markdown + YAML 格式——你仓库中的纯文件——并配有一个 CLI，供你的代理调用以查询、 编辑和 lint 它们。由于结构是机器可读的，代理可以问“我接下来该构建什么？”， 得到未完成的需求及其验收标准，然后对照它们检查自己的工作。它与工具无关，且开源。
从 面向你的编码代理的 AI 技能开始，或安装 CLI。
常见问题
规范驱动开发和测试驱动开发是一回事吗？
不是。TDD 在代码层面从失败的测试驱动实现。规范驱动开发在更上一层运作：它先把预期行为和验收标准固定在一份书面规范中。两者是互补的——规范中的验收标准往往会成为 TDD 随后驱动的那些测试。
规范驱动开发会拖慢你吗？
它在写代码之前增加了时间，却减少了重做错误东西所花的时间。对于一次性脚本，这点开销并不值得。但对于 AI 代理大规模生成的东西，或团队必须维护的东西，先写规范通常从头到尾都更快。
规范和 PRD 有什么区别？
PRD 通常是面向人的散文。规范驱动开发中的规范是结构化且可测试的——带有明确验收标准的离散需求——因此评审者和 AI 代理都能据以精确地行动。
AI 编码代理如何使用规范？
当规范可被机器读取时，代理会向它查询与当前任务相关的需求和验收标准，而不是加载整个代码库，然后对照这些标准检查自己的输出——这是对看似合理却错误的代码的一道防护。