文章总结： 本文系统介绍了SDD规范驱动开发方法，旨在通过编写明确规范约束AI模型代码生成行为，解决模型执行偏移问题。核心提出三模型工作流：使用高质量模型设计规范、低质量模型审计歧义、中高质量模型执行实现。文章对比了SDD与VibeCoding差异，分析Kiro、SpecKit、OpenSpec等工具特性，并给出四步校对法等可操作建议，强调规范应作为AI开发的确定性依据。 综合评分： 87 文章分类： 安全开发,技术标准,解决方案,AI安全,安全工具

SDD规范驱动开发：自用的三模型工作流

原创

洋洋 ouo 洋洋 ouo

塔罗安全学苑

2026年5月20日 11:20 江西

在小说阅读器读本章

去阅读

什么是规范驱动开发

现在越来越多任务交给 agent 自己跑：读代码、改接口、补测试、跑命令、修失败，有时还要跨多轮会话继续干。模型已经不只是代码补全工具，它更像一个低自治开发者。

模型越强，越容易把模糊需求做成”看起来合理”的实现。它会自动补上你没说清楚的部分，替你选择兼容策略、命名方式、迁移路径。SDD 要做的，就是提前把这些选择写清楚，限制模型自由发挥的空间。

2025 年，SDD 开始被更多人知道。三类工具有代表性：AWS Kiro 把 spec-driven development 做进 AI IDE 的核心流程；GitHub Spec Kit 把 Specify、Plan、Tasks、Implement 做成开源工具；OpenSpec 围绕现有代码库的变更管理提供轻量级框架。

SDD 和 Vibe Coding 的关系

SDD 和 Vibe Coding 是 AI 编程的两种模式。Vibe Coding 是对话即指令，靠 Prompt 直接出代码，快但不确定；SDD 是规范即事实源，先写清楚再动手，慢但可控。

| 对比维度 | 规范驱动开发（SDD） | Vibe Coding | | — | — | — | | 核心逻辑 | 规范即事实源，代码严格遵循规范 | 对话即指令，Prompt 直接生成代码 | | 流程设计 | 需求澄清→规范编写→任务拆解→代码生成，每步可追溯 | Prompt 调试→代码生成→人工修改→再次 Prompt，无固定流程 | | 质量控制 | 规范自动生成测试用例，缺陷预防前置 | 依赖人工校验，易出现隐性缺陷 | | 团队协作 | 规范作为共享契约，跨角色协作 | 依赖个人 Prompt 技巧，协作成本高 | | 适用场景 | 核心系统、API 设计、合规项目、迁移重构 | 原型验证、个人工具、创意探索 | | 工具依赖 | OpenSpec、Kiro、Spec Kit | Cursor、Copilot Chat 等通用工具 | | 长期维护 | 规范即活文档，支持版本化管理 | 代码即真相，文档缺失，重构困难 |

实际项目里两者经常配合用：先用 Vibe Coding 快速试错，验证方向可行后，再用 SDD 规范锁定核心逻辑。代码生成是概率的，SDD 通过规范约束上下文让它趋向确定性。

为什么现在需要 SDD

GPT 5.5 xh 或 Opus 4.6 这类高质量模型适合做方案设计和复核，但让它全程写代码，成本太高。更常见的做法是：高质量模型写 spec，低成本模型按 spec 实施。SDD 就是在给低成本模型写施工说明。

复杂改动最怕旧方案残留。迁移、重构、接口统一、数据模型调整，这类任务真正的难点在于删掉旧路径，明确哪些输入必须失败，保证前端、后端、测试理解的是同一个模型。边界提前写出来，返工会少很多。

还有一点容易被低估：AI 让试错成本下降，也让错误扩散更快。方向一错，模型会很快生成一大片错误代码。没有 spec，错误藏在实现细节里；有 spec，至少可以在动手前、实现中、验收时反复对照。

当执行者从人变成模型，需求就得变成模型更容易理解的形式。

模型跑偏

用 AI 写代码，很多人都经历过这个过程。

给模型一个需求，它很快写出第一版。小功能还行，稍微复杂一点就开始出问题：今天补一个兼容字段，明天改一个接口命名，后天又接一个前端入口。几轮之后，模型开始分不清哪些是旧方案，哪些才是最终方案。

项目里出现大量模型偏移产生的垃圾代码：

• 旧字段没删干净；
• 新接口和旧接口一起存在；
• 文档说已经迁移，代码里还留着 fallback；
• 测试只覆盖 happy path，没有覆盖必须拒绝的旧输入；
• 前端、CLI、API、持久化层各自理解了一套模型。

这些问题靠”再强调一遍”解决不了。模型不会天然知道哪些信息是权威来源，哪些只是历史过程。上下文里同时出现两个版本，它就可能做折中。

SDD 要处理的就是这个夹缝。

动手写代码之前，先把几件事讲清楚：目标模型是什么，哪些旧模型必须删除，哪些输入必须 fail fast，哪些字段是唯一权威来源，各层分别要改到哪里，什么情况算完成。

规范可以被审计、被修改、被反复验证。

Kiro、Spec Kit、OpenSpec 和 Plan 模式有什么区别

Plan 模式最轻。它发生在一次对话里，让模型先分析需求、列步骤、确认改动范围，再进入代码实现。适合修一个 bug、改一个页面、补一组测试这类边界清楚的小任务。问题是，计划通常还在聊天记录里。上下文变长、模型切换、会话中断之后，那份计划很容易失效。后面换一个模型执行，未必还能准确继承原来的判断。

Kiro 把 spec 工作流做进 IDE。它会围绕一个功能或 bug 生成 requirements.md、design.md、tasks.md，再通过 IDE 界面跟踪任务状态。产品化程度高，也会根据 tasks 的依赖关系并行执行一部分任务。

Spec Kit 是通用 SDD 脚手架，GitHub 推出。核心流程是 Spec、Plan、Tasks、Implement。不绑定某个 IDE 或某个模型，给不同 coding agent 准备命令、模板、目录结构和上下文规则。它更适合从零搭项目，或者给团队统一一套规范驱动流程。

OpenSpec 更轻，重点放在现有代码库里的变更管理。它围绕一个 change 生成 proposal.md、design.md、tasks.md 和 spec delta。优势是让规格留在仓库里，和代码一起被 review、被修改、被继承。对成熟项目来说，真正的难点是弄清楚当前系统已经承诺了什么，这次变更又要改掉什么。

• 临时小改，Plan 模式够用；
• 想在 AI IDE 里把需求、设计、任务串起来，用 Kiro；
• 新项目从零开始建规范流程，用 Spec Kit；
• 老项目做迁移、重构、接口统一，我偏向 OpenSpec。

快速对比：

| 维度 | Spec-Kit | OpenSpec | Kiro | | — | — | — | — | | 产品类型 | CLI 工具包 | 轻量级框架 | 完整 IDE | | 开源 | MIT | 是 | 专有 | | 使用方式 | 嵌入现有 AI 编码工具 | 嵌入现有 AI 编码工具 | 独立 IDE 环境 | | 场景侧重 | 0→1 新项目 | 1→n 现有代码库 | 两者兼顾 | | 工作流 | specify → plan → tasks → implement | draft → review → implement → archive | requirements → design → tasks | | 核心特色 | constitution.md 项目宪法 | brownfield-first + 变更提案管理 | Agent Hooks 自动化 + 规格代码同步 | | 成本 | 免费 | 免费 | 付费订阅（$20/月起） |

它们可以互补。可以用 Spec Kit 或 OpenSpec 产出规范，再让模型执行具体任务时开 Plan 模式。

区别在于：Plan 模式约束当前这次执行；SDD 工具把约束沉淀成可以反复读取的文件。

规范是写给模型看的

很多人第一次用 SDD，会下意识用人读文档的方式检查方案：自己读一遍 proposal，觉得逻辑顺；读一遍 design，觉得没问题；tasks 看起来也全，于是丢给模型执行。

这一步很危险。

规范最终是交给 AI 执行的。人读起来没歧义，不代表模型读起来也没歧义。人看到”迁移到新模型”，自然理解为旧字段要删掉；模型看到”迁移”，可能理解为要兼容一段时间。人看到”统一使用 workflow”，知道 workflowIds[] 不该再出现；模型可能只删请求入参，忘了响应 DTO 里也不能输出。

SDD 里一个重要的动作，是让模型检查文档会不会被模型误读。

让低上下文、低能力模型来审。如果一个方案只有高质量模型能看懂，那它还不够。低能力模型会暴露文档里的含糊处、遗漏处和歧义处。高质量模型觉得理所当然的地方，低质量模型反而会产生理解偏差。

这些，往往就是后面实施时最容易出事的地方。

为什么模型会跑偏

很多人把模型执行偏移归结为”提示词没写好”。提示词当然有影响，但复杂任务里，偏移更多来自模型的工作方式本身。

模型会补全空白。人看到”迁移到新模型”，会结合项目背景、会议讨论、历史经验去理解。模型没有这些隐含记忆，只能根据上下文里的文字推断。文档没写清楚”旧字段必须 fail fast”，它就可能自己补出一个兼容期。

模型天然倾向于给出可运行结果。它看到旧字段、旧接口、旧测试时，会本能地保留 alias、加 fallback、做双读。这在人类维护老系统时很常见，但在一次性迁移任务里就是偏移。

否定约束也容易被忽略。你写”使用 workflow”，模型会记住要加 workflow。你写”不接受 workflowIds[]”，它也可能漏掉，尤其在长上下文和多文件修改里。

模型切换会放大偏移。高质量模型写方案时，默认很多背景成立；低成本模型执行时看不到这些隐含判断，只能读文档表面。高质量模型觉得”这里当然是存内部 workflowId”，低成本模型可能把完整 scanWorkflows/subdomain_discovery 存进数据库。

任务越长，局部正确越容易压过全局一致。模型在每一层的形态理解不一样，执行就会整体偏移。

偏移的根源在于规范不完整。模型在做概率推断。没有唯一权威来源，它就从旧代码、旧测试、聊天记录、常见工程习惯里找答案。SDD 就是把这些可以猜的地方提前收窄。

模型变强了，SDD 还需要吗

模型能力提升确实会减少低级偏移。更长上下文、更好的代码检索、更强的规划能力，都会让模型更容易看完整个项目。未来的 agent 也会更擅长自我检查，主动发现”这里和 spec 不一致””这里保留了旧字段”。

但偏移同时也是信息问题。只要需求本身有歧义，模型就必须做选择。只要代码库里同时存在旧实现和新设计，模型就必须判断哪个更权威。模型越强，反而越擅长把未说明的地方补得很自然，看着像一个合理实现。

长期看，SDD 的形态可能会变。不一定还是现在这样的 Markdown 文件，也可能是更结构化的需求图、可执行约束、类型化 spec。但”需要规范”这件事不会变。只要软件开发还有多人协作、历史包袱、兼容取舍，就需要一个地方记录最终决策。

模型再强，也不能替你决定业务上到底要不要兼容旧字段、数据库里应该存资源名还是内部 ID。

四步校对法

三类模型：

• 方案审核模型

  ：用最领先的模型（GPT 5.5 xh 或 Opus 4.6）写方案、做最终复核。这类模型理解力最强，适合处理复杂设计决策和跨模块依赖。

• 执行模型

  ：用中高质量模型（GPT 5.4 high）按 spec 实际写代码。执行模型要比审计模型更高级，负责把规范落地为可运行的实现。

• 审计模型

  ：用低质量模型（GPT mini）审文档。它的作用是暴露歧义——如果 GPT mini 都能读懂你的 spec，那执行模型大概率不会跑偏。

具体流程：

第一步，用 GPT 5.5 xh 或 Opus 4.6 写方案。把目标模型、删除项、边界、任务、验收条件都写清楚。

第二步，把方案交给 GPT mini 审。让它找出文档里读不懂、有歧义、会走偏的地方。

第三步，把审计结果交回 GPT 5.5 xh 或 Opus 4.6 复核，修改设计文档。

第四步，再让 GPT mini 审一轮。等它觉得文档已经没问题，可以 实施的时候，再把实施交给 GPT 5.4 high。

一句话概括：你的文档如果能让幼儿园的小朋友也能算出高数问题，那就是好文档。

为什么审计反而省 token

表面看，反复审计文档会多花 token。

但真正贵的是错误实现之后再返工。大改动里，模型一旦按错误理解写了几千行代码，后面修起来要读旧实现、理解新要求、找差异、删兼容逻辑、补测试。上下文越来越长，误差也越来越大。

在写代码前把方案打磨到低能力模型也能读懂，成本低得多。

总结

SDD 解决的是 AI 开发里一个很现实的问题：模型执行任务时，必须有一个稳定、明确、可验证的依据。

三类模型各司其职：方案审核模型（GPT 5.5 xh 或 Opus 4.6）负责设计和最终复核；执行模型（GPT 5.4 high）负责按规范写代码；审计模型（GPT mini）负责暴露文档里的歧义。用低质量模型发现文档问题，用最领先的模型审核方案，再把实施交给比审计模型更高级的执行模型。

校对做好以后，再把实施交给执行模型，成功率会高很多。方案审核模型也不用从头到尾烧 token 陪跑，更多负责设计、复核和纠偏。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：塔罗安全学苑 洋洋 ouo 洋洋 ouo《SDD规范驱动开发：自用的三模型工作流》