为什么你的 Agent 产出不符合预期？你缺的不是好模型，而是SDD
SDD，全称是 Spec-Driven Development，规格驱动开发。
你有没有遇到过这种情况？
你只是和Agent说：
帮我在现有的XX项目中加个XX功能。
它马上就开干，定架构，创建文件，生成待办清单......一气呵成，看起来非常高效、非常AI。
虽然这很Vibe Coding，但这给后续的交付埋下了隐患。
-
它可能理解错了业务规则。
-
它可能改动了原有的代码依赖，带崩了其他业务模块的问题。
-
它忘了前面刚确认过的设计细节。
它把一个小需求，整成了大型事故现场，却还"自信满满"。
-
你让它修一下BUG，它又继续大动干戈。
-
你让它别动某块代码，它下一轮又动了。
-
你让解决这个问题，却又忘了你前面提出的要求。
上下文越塞越多，它也越来越混乱。
这时候很多人的第一反应是：是不是模型还不够好，是不是提示词没写清楚。
但在真实工程里，很多问题并不是模型本身的问题。
真正的问题是：
你让 Agent 开始写代码之前，并没有给它一份边界明确和目标清晰的规格（Spec）。
这就是 SDD 在 Agent 编程里越来越重要的原因。
一、 Agent 的问题，不是不会写，而是不知道该按什么规格写
过去我们用 AI 写代码，更多是在写 Prompt。
比如：
帮我写一个登录接口。帮我加一个权限功能。帮我重构这段代码。帮我修复这个 Bug。
这种方式在小任务里很有效。
因为小任务的上下文短，边界清楚，改坏的成本也不高。
但一旦进入真实工程，情况就变了。
真实工程不是"生成一个页面"这么简单。它里面有历史代码、业务规则、权限边界、异常处理、数据兼容、接口约定、测试约束，还有一堆没有写在文档里、但大家默认知道的工程习惯。
人类开发者遇到模糊需求时，通常会先停下来问：
-
用户角色有哪些？
-
权限粒度到菜单，还是按钮？
-
是否兼容历史数据？
-
老接口要不要保留？
-
异常情况怎么处理？
-
验收标准是什么？
但 Agent 很多时候不会主动问到这个程度。
它更像一个执行很强欲望的助手。只要你给它一个方向，它就会开工。
这也是 Agent 编程最容易翻车的地方：
它不是不会干活，而是太容易在边界、目标、规格不明确的情况下，自己补上所有假设，就提前开工。
这并不是大模型的幻觉，而是你并没有制定明确的规格。
二、什么是 SDD？简单说，就是先写清楚"做对"的标准
SDD，全称是 Spec-Driven Development，规格驱动开发。
它不是让你回到传统项目里一堆项目文档规范，也不是为了写文档而写文档。
在 Agent 编程里，SDD 的核心价值很简单：
在写代码之前，先把目标、边界、约束、验收标准说明白。然后让 Agent 围绕这份规格去计划、拆任务、实现和校验。
换句话说：
Prompt 是一次性指令。 Spec 是持续性约束。
Prompt 更像你随口交代一句：
去把这个功能做一下。
Spec 更像施工图：
做什么，不做什么，怎么判断做对，哪些边界不能碰，哪些规则必须遵守。
这两者的差别，在小任务里不明显。但在复杂工程里，差别会被放大。
因为 Agent 的上下文窗口再大，也不是人类团队的长期记忆。它会遗忘，会误解，会把旧信息和新信息混在一起，也会在长对话里抓错重点。
所以，Spec 的意义不是"多一份文档"。
它更像是 Agent 的工作锚点。
当 Agent 要写计划时，它回到 Spec。当 Agent 要拆任务时，它回到 Spec。当 Agent 要写代码时，它回到 Spec。当 Agent 要检查结果时，它还是回到 Spec。
这才是 SDD 在 Agent 时代重新变重要的原因。
以前规格文档经常写完就被丢在一边。但现在，规格可以变成 Agent 持续工作的输入。
这就把文档从"项目仪式感"，变成了"模型执行依据"。
三、没有 SDD，Agent 很容易变成 Vibe Coding
现在很多人喜欢说现在是 Vibe Coding 时代。
但在特定语境里，他更像是一种贬义：你不用指定严格的工程流程，纯靠一种氛围感Coding。
当你做原型、做 Demo、试想法时，让 Agent 跟着感觉快速生成，非常爽。
但真实的软件工程项目不能一直靠感觉。
因为真实工程最怕的不是写得慢，而是方向错。
方向错的时候，Agent 越勤快，问题越大。它能在几分钟内写出一堆代码，也能在几分钟内制造一堆技术债。
没有 SDD 的 Agent 编程，经常会出现四类问题：
-
需求假设。你没说清楚的地方，Agent 会自己补。
-
边界失控。你只想改一个接口，它顺手重构了一片代码。
-
上下文污染。你越解释，信息越多，Agent 越容易把重点和噪音混在一起。
-
验收漂移。一开始说的是 A，做着做着变成了 B，最后代码看起来能跑，但不是你要的东西。
所以，SDD 不是为了让开发变慢。
它是为了避免 Agent 在错误方向上高速狂奔。
四、三类工具横向看：Spec Kit、Matt skills、Superpowers
现在围绕 Agent 工程化，已经出现了不少工具和方法。
这里重点看三个：
-
Spec Kit
-
Matt skills
-
Superpowers
它们都和 Agent 工作流有关，但定位并不一样。
可以先用一句话理解：
| 工具 | 一句话定位 |
|---|---|
| Spec Kit | 更接近正统 SDD，把 spec、plan、tasks、implement 串起来 |
| Matt skills | 工程师工具箱，按需增强 Agent 的局部能力 |
| Superpowers | 强流程外骨骼，让 Agent 按完整工程纪律工作 |
五、谁更像 SDD？
如果只看 SDD 程度，我会这样排：
| 排名 | 工具 | 判断 |
|---|---|---|
| 1 | Spec Kit | 最接近 SDD 主流程 |
| 2 | Superpowers | 有设计和计划，但更偏工程流程控制 |
| 3 | Matt skills | 更像 SDD 辅助工具，不是完整 SDD 框架 |
1. Spec Kit：规格驱动的主线工具
Spec Kit 的重点很明确：
先写规格，再澄清，再计划，再拆任务，最后实现。
它适合这种流程：
需求 → spec → clarify → plan → tasks → implement
它最大的价值，是把 Agent 从"听一句话就开工"的状态，拉回到"先理解规格，再进入执行"的状态。
这对复杂功能很有用。
比如你要做一个权限模块、订单流程、审批流程、直播管理模块、消息队列链路改造，如果直接让 Agent 写，很容易跑偏。
但如果先有 Spec，Agent 后面的计划和实现就会有依据。
所以，Spec Kit 更像 SDD 的主流程。
2. Matt skills：工程师的局部增强工具箱
Matt skills 不是一个完整 SDD 框架。
它更像一套工程技能包。
比如：
-
方案不确定，可以用 grill-me 让 Agent 追问和质疑；
-
需求需要和代码上下文对齐，可以用 grill-with-docs；
-
Bug 很难排，可以用 diagnose；
-
想用 TDD 推进，可以用 tdd；
-
想把 PRD 拆成任务，可以用 to-issues；
-
想控制 Git 风险，可以用 git guardrails；
-
想做提交前检查，可以用 pre-commit。
它的特点是：不抢主流程，只在关键点补强。
所以，Matt skills 本身不算 SDD。但它很适合成为 SDD 的辅助工具。
尤其是 grill-me 这类技能。
它不是帮你生成完整规格，而是帮你把问题问清楚，把漏洞挑出来，把模糊的地方压实。
这一步很像 SDD 前的需求澄清和方案评审。
所以更准确地说：
Matt skills 不是 SDD 主体，而是 SDD-friendly 的工程工具箱。
3. Superpowers：强流程约束工具
Superpowers 的思路更强。
它不是让你一个技能一个技能地调用，而是希望 Agent 在做软件开发时，自动进入一套完整流程。
比如：
brainstorming → writing-plans → executing-plans → TDD → review
它会强调先头脑风暴，再写计划，再执行，再测试，再 Review。
这个方式对 Agent 新手很友好。
因为很多人不知道该怎么约束 Agent。Superpowers 就像给 Agent 穿上一套工程外骨骼，让它不要一上来就乱写代码。
但它的问题也很明显：流程偏重。
如果你已经熟悉 Agent 的执行过程，知道什么时候该澄清、什么时候该计划、什么时候该测试，那么 Superpowers 未必适合日常常开。
它更适合这些场景：
-
Agent 使用经验较少；
-
希望工具强制规范流程；
-
做高风险模块；
-
做核心重构；
-
希望强制 TDD 和 Review。
所以，Superpowers 不是不好。
它只是更像强流程方案，而不是纯 SDD 方案。
六、Token 消耗不是成本问题，而是上下文管理问题
很多人讨论 Agent 工具时，会说哪个更省 token，哪个更费 token。
但我觉得这个说法还不够准确。
Token 消耗不只是钱的问题，更是上下文管理问题。
因为上下文越长，模型不一定越聪明。
如果上下文是结构化的，里面有清晰的 Spec、Plan、Tasks、验收标准，那它是有价值的。模型知道该看哪里，也知道什么信息更重要。
但如果上下文是散的、重复的、互相冲突的，那就很麻烦。
它会让模型在一堆信息里找方向。找着找着，就容易抓错重点。
所以，真正要关心的不是：
这个工具会不会多消耗 token？
而是：
它消耗的 token，是否换来了更清晰的上下文结构？
三者大概可以这样看：
| 工具 | Token 压力 | 上下文特征 |
|---|---|---|
| Matt skills | 低到中 | 按需触发，局部上下文，比较轻 |
| Spec Kit | 中到高 | 规格、计划、任务结构清晰，可回溯 |
| Superpowers | 高 | 流程长，设计、计划、TDD、Review 都会增加上下文 |
这并不是说 token 越低越好。
低 token 但没有结构，Agent 还是会乱。高 token 但结构清晰，反而可能更稳定。
最糟糕的是：
高 token，加上无结构上下文。
那不是工程化。那是把一屋子资料都倒给 Agent，然后希望它自己能整理清楚。
七、这三个工具会不会冲突？
如果都安装，一般不一定会硬冲突。
真正的问题是：流程可能重叠。
比如你要做一个新功能。
Spec Kit 会想让你先写 spec，再 plan，再 tasks。Superpowers 会想先 brainstorming，再 writing-plans，再 executing-plans。Matt skills 里的 grill-me 又可以继续追问和质疑。
如果没有主次，很容易变成：
三个产品经理同时开会，代码还没开始写，文档已经满地开花。
所以，关键不是能不能一起装。
关键是要明确谁是主流程，谁是辅助工具。
我的建议是：
| 使用方式 | 推荐程度 |
|---|---|
| Spec Kit + Matt skills | 推荐 |
| Spec Kit + Superpowers | 谨慎，流程容易重叠 |
| Matt skills + Superpowers | 可以，但 TDD、Review、计划部分会重复 |
| 三者全流程同时开 | 不建议 |
比较稳的方式是：
Spec Kit 管主流程。Matt skills 做辅助增强。Superpowers 只在需要强流程约束时按需启用。
八、普通开发者应该怎么选？
如果你是普通开发者，刚开始想把 Agent 用得更稳，我建议不要一上来就追求全家桶。
可以按这个顺序理解。
1. 想理解 SDD，先看 Spec Kit
因为它最能体现 SDD 的核心思想：
先写清楚规格，再让 Agent 执行。
它适合复杂需求、新功能开发、团队讨论和工程留痕。
如果你经常遇到 Agent 需求理解跑偏，Spec Kit 是很值得研究的。
2. 想增强 Agent 的局部能力，用 Matt skills
Matt skills 更适合已经会用 Agent 的人。
你知道自己什么时候需要追问，什么时候需要诊断，什么时候需要 TDD，什么时候需要拆 Issue。
它不会替你接管整个流程，而是像一组工程工具。
所以它的控制感更强，token 压力也相对可控。
3. 想让 Agent 被强流程管住，再考虑 Superpowers
Superpowers 适合 Agent 使用经验不多，或者希望工具强制约束流程的人。
它的优点是完整、严格、有纪律。
但它也更重。
如果你已经熟悉 Agent 的执行节奏，不一定需要日常常开。
可以把它放在核心模块、复杂重构、强 TDD 分支里使用。
九、我的推荐组合：Spec Kit + Matt skills
如果只选一个组合，我更推荐：
Spec Kit + Matt skills
原因很简单。
Spec Kit 负责主线：
需求 → 规格 → 计划 → 任务 → 实现
Matt skills 负责补强：
追问、质疑、诊断、TDD、Issue、Git 安全、提交前检查
这套组合的好处是：
第一，主流程清晰。不会让 Agent 一上来就写代码。
第二，控制权还在开发者手里。你知道什么时候该进入下一步，而不是完全交给工具自动推进。
第三，适合真实工程。既能减少需求跑偏，又不会把流程搞得过重。
第四，token 消耗更可控。该结构化的地方结构化，该轻量处理的地方轻量处理。
Superpowers 当然也有价值。
但我更愿意把它理解成"重型工程外骨骼"。它适合需要强约束的时候穿上，而不是每天都穿着它写所有代码。
十、结尾：Agent 时代，真正重要的是上下文管理的能力
未来的 Agent 编程，不会只停留在"帮我生成一段代码"。
真正有价值的方向，是让 Agent 进入真实工程流程：
先理解目标->再明确规格->再拆解计划->再执行实现。
最后回到验收标准里检查自己有没有做对。
这就是 SDD 的价值。
它不是为了让开发变慢，它是为了减少错误方向上的高速狂奔。
当模型越来越强，代码生成能力会变得越来越普遍。
真正拉开差距的，可能不再是你会不会写一句漂亮的 Prompt，而是你能不能给 Agent 建立一套清晰、稳定、可执行的规格系统。
因为 Agent 最怕的，不是任务复杂。
它最怕的是：
你自己也没说清楚，却希望它一次做对。
当然，也并不是一次性把所有信息都喂给他，他也能做好。
人与人的沟通中信息会折损，而大模型也一样。
那应该怎么做？比如：只在测试阶段，给测试设计文档；在验收阶段，给验收规格文档；在review阶段，调用code review skill由另一个subAgent执行。
在合适的时机，给合适的prompt，也就是：渐进式披露。
所以Agent 时代的工程能力，不只是提示词能力。更重要的是：
规格约束和上下文管理能力。
关于大模型的缺陷
人与AI协作的过程，其实和我们真实世界里人类协作过程高度相似。
只是我们潜意识里默认AI无所不知，甚至你的所有想法，而降低了沟通范式标准。
大模型有缺陷：
-
上下文窗口有限
-
有注意力机制（分不清大量信息中的重点信息）
-
自审查死循环（所以要由subAgent审查）
-
在不明确的工作流中迷失方向
-
有幻觉
其实人脑也一样：
-
也会遗忘
-
对自己模糊的信息做假设补全
-
在固有的思维中自我感觉良好（所以要有测试人员）
-
在不规范的工作流程中需要不断干预矫正
-
对不了解的知识自以为是
所以在用任何AI工具前，可以试试先降低标准，
把他当成我们真实工作场景中的再普通不过的合作伙伴