背景：vibe coding 为什么在多文件自主改写时失灵
2024 到 2025 年，团队普遍用非结构化的自然语言提示来加速交付，这种「vibe coding」在单文件 bug 修复、小脚本场景里问题不大——改动半径小、人能在几秒内审完整段 diff。但当智能体被授权做多文件改动、自主提 PR 时，同样的宽松输入开始失控：一个被要求「加上订阅计费」的 Agent 必须自行推断数据库 schema、错误处理约定、命名规范与边界情况，而且它会非常自信地推断，哪怕推断是错的。
失败往往不是崩溃，而是三四个冲刺之后才暴露的架构漂移、重复逻辑，以及不再匹配任何人心智模型的代码库。2026 年中的多项企业内部复盘显示，用非结构化提示构建的软件，长期技术债比传统开发流程高出约 140%，并伴随意料之外的边界情况失效——尽管它在最初提供了约 60% 的即时代码生成速度跃升。
规格驱动开发的本质，是把生成式模型从「创意作者」重新定位为「在严格、机器可读的行为框架内运行的确定性执行编译器」。团队在代码产出之前就提供状态定义、边界条件与不变式规则，从而消除导致多步合成退化的上下文漂移。规格文件成为首要协作与审查对象，而不是生成的差异。
规格驱动开发的四阶段骨架
尽管各家的产品形态不同，当下主流 SDD 工具都收敛到同一条流水线：先写规格，再定计划，再拆任务，最后才让 Agent 实现。差别主要在「规格用什么格式」「计划与任务如何被校验」。
| 阶段 | 核心产物 | 要回答的问题 | 关键约束 |
|---|---|---|---|
| Specify | 产品场景规格文档 | 要解决什么、成功长什么样 | 用结构化模板，避免模糊自然语言 |
| Plan | 技术计划 / 设计文档 | 拆成哪些模块、依赖与风险 | 可被人工评审，作为实现边界 |
| Tasks | 可执行任务清单 | 谁来做、做到哪算完 | 每条带验收标准，可转 issue |
| Implement | 代码与 PR | 在边界内落地 | 实现后回比对规格，检测漂移 |
这条骨架的价值不在框架本身，而在于「规格成为可持久、可继承的制品」。当一个项目交付给客户或下一个团队时，他们拿到的是规格加代码，而不只是代码当前的状态。
三大主流工具拆解：constitution、EARS 与执行契约
2026 年定义 SDD 版图的有五套方案，取向明显不同。下面按「约束落在哪一层」对比：
| 工具 | 定位 | 规格载体 | 独特机制 | 适用场景 |
|---|---|---|---|---|
| GitHub Spec Kit | 开源 CLI（MIT） | Markdown 规格 + constitution | constitution 文件沉淀跨会话不变原则，微提示向量拆分大规格 | 通用、可移植的工程团队 |
| AWS Kiro | VS Code 派生 IDE | requirements.md / design.md / tasks.md | EARS 形式化需求 + SMT 求解器证明矛盾 | 强约束、安全敏感项目 |
| Google Conductor | 多智能体编排框架 | 规格即多智能体执行契约 | 规格更新后自动派发子 Agent，Antigravity 持续对账 | 复杂系统、多 Agent 协同 |
| BMAD-METHOD | 开源方法论 | 12+ 专职 Agent 角色文档链 | 产品经理/架构/QA 等角色各产出一份文档 | 端到端可追溯交付 |
| OpenSpec | 轻量开源 | 仓库内 Given/When/Then | delta 追踪（ADDED/MODIFIED/REMOVED） | 既有代码演进，非全新构建 |
值得注意：Kiro 把「需求分析」前置到自然语言需求本身，用 LLM 把需求翻译成形式逻辑，再用 SMT 求解器数学证明其中是否存在矛盾或漏洞；Conductor 则把规格当成多 Agent 的执行契约，规格一更新就自动把任务派给数据库校验、schema 校验、单测生成等子 Agent。两者代表了「输入层约束」与「执行层约束」两条路线。
EARS 与形式化需求：把验收标准写进输入层
AWS Kiro 把航空航天领域原生的 EARS 记法（Easy Approach to Requirements Syntax）嵌进编辑器内核。EARS 用固定句式描述需求，例如「WHEN [条件] THE SYSTEM SHALL [行为]」，把模糊的功能描述转成可机器校验的触发—状态—输出三元组。
在输入层强制结构化，有两重效果：一是降低上下文歧义，稳定模型输出；二是在代码产出前就能发现需求冲突。Kiro 的 Requirements Analysis 进一步把 LLM 与 SMT 求解器结合——求解器数学证明需求是否自洽，把「含糊提示必然产生含糊规格、Agent 悄悄替你做错误决定」的风险挡在编码之前。
量化证据：缺陷率、技术债与 token 节省
SDD 不是信仰，而是有公开基准支撑的工程选择。2026 年几个可溯源的数据点如下：
| 指标 | 数值 | 来源 / 口径 |
|---|---|---|
| 逻辑缺陷率 | 较 vibe coding 降低约 84% | 2026 企业工程部门跨团队量化研究 |
| 整体 token 消耗 | 降低约 45% | 同上（规格替代反复试错） |
| 长期技术债 | vibe coding 反向抬高约 140% | 同期对比传统开发流程 |
| 特性/数据管道工单合并率 | 最优规格流达 90%，对照组约 60% | Uvik SDD Benchmark（50 张生产 Python 工单） |
| 每合并工单成本 | Kiro 约 $2.35，对照组约 $2.43 | Uvik SDD Benchmark（Kiro 在规格框架中最低） |
| 评审缺陷密度 | 规格流 0.46 / 工单，对照组 0.86 | Uvik 盲审（规格流显著更低） |
Uvik 的基准把 GitHub Spec Kit、Kiro、BMAD、OpenSpec 与「无规格」对照组放在同一组 50 张真实生产 Python 工单上对比：OpenSpec 合并数最高（42/50），无规格对照组为 36/50；规格流在特性与数据管道工单上优势最明显，但工单规模强烈影响是否划算——改动涉及 3 个及以上文件时增益显著，1 到 2 个文件的微小改动几乎无差。
SDD 的收益是「条件性」的：它在多文件、高歧义、误解代价高的特性上回报明确；在微小 bug 修复、已有绿测的重构、部分测试编写任务上，额外规格开销往往不划算。结论不是「凡事都写规格」，而是「按工单规模、歧义度与受影响文件数选择性使用」。
工程落地清单与避坑
基于上述证据，可落地的实践清单如下：
- 先分类再决定是否写规格：估计改动文件数，3 个及以上优先完整规格；小改动用清晰工单加人工评审即可。
- 验收标准前置：在 Agent 动手前写清期望行为、边界、约束与校验步骤，而不是事后补。
- 人工评审生成规格：规格由 Agent 产出后，仍须人工 review 再进入实现阶段，避免「因为格式结构化就默认正确」。
- 实现后对账：把成品代码与已批准规格逐项比对，检测规格漂移。
- 追踪合并率、返工、评审缺陷、耗时与成本，而非主观判断工作流好坏。
常见陷阱包括：对每张工单无差别套用完整框架；以为更多 Markdown 自动等于更好实现；在工单复杂度不支撑时花比实现更多的精力写评审规格；以及把 Agent 产出的结构化规格直接当成真理。
局限与冷静判断
- 规格本身有成本：Uvik 基准中规格创建占相当比例 token，BMAD Method 占比更高，小工单上可能得不偿失。
- 精确复现依赖评审纪律：规格流的优势来自「人工在正确节点介入」，若跳过评审，退化成更贵的 vibe coding。
- 横向对比需同口径：不同框架用同一模型、同一工单、同一时限与评审标准才有可比性，跨框架照搬分数无意义。
- 收益非普适：bug 修复、重构、测试编写常不需要完整 SDD，盲目全量应用会拉高成本。
- 原始研究口径：84% 缺陷率降幅、140% 技术债等来自厂商与行业汇编的汇总口径，具体绝对值随团队与模型波动，应作为区间参考而非承诺。