大部分”AI 帮我做完了功能”的故事，都停在”完成 80%、最后 20% 怎么都收不了尾”。原因几乎都一样：spec 一直是在代码里被隐式写出来的，agent 一路在猜——而且猜错了。真正的修法在上游。写一页 spec、逼 AI 把自己的歧义点抖出来、把活拆成每个都带真验收测试的 ticket，再一个一个 ticket 上线。到 2026 年，这套打法已经有了名字——spec 驱动开发（SDD）——背后也有了真工具：GitHub 的 Spec Kit（截至 2026 年 6 月已超过 10.9 万 GitHub star）、AWS Kiro，以及 Claude Code、Cursor 内置的计划模式。
一句话总结
- “凭感觉写代码”翻车的根因，是 spec 没说清。把 spec 显式写出来，最后 20% 就不再跟你较劲。
- 五步循环：spec → 澄清 → 计划 → 拆任务 → 实现，一次一个 ticket，每个都有可运行的验收测试。
- 工具选择：要跨 30+ agent 的结构化 CLI 流程用 GitHub Spec Kit；想要 spec 优先的 IDE 用 AWS Kiro；想要零安装的轻量版用 Claude Code 计划模式（连按两次 Shift+Tab）。
- 选推理强的模型：实现用 Claude Opus 4.7（SWE-bench Verified 87.6%）或 Sonnet 4.6，终端密集的 agent 跑批用 GPT-5.5。
- 整个任务里杠杆最高的 10 分钟：在 AI 列出”它不知道什么”之后，回头改 spec。
这套工作流解决什么
半成品陷阱：agent 看起来把功能做完了，你开心地演示，接下来一周陆续发现 spec 没盖到的边界、AI 静悄悄塞进来的范围扩张、能过但根本没测新行为的测试。GitHub 给 Spec Kit 的定位里把这叫”凭感觉写代码（vibe-coding）“——做一次性原型还行，一碰真代码库就不可靠。这套工作流把”隐式 spec”路径在后段慌忙买单的那份严谨，提前预付到前段。
这篇适合谁
独立开发者、做原型的人、以及在 deadline 压力下赶功能的开发者。如果你已经上线过两三个 AI 做的功能，并且发现它们全都需要一次”比第一遍还久”的二次过——这篇尤其相关。琐碎功能（一个函数、一个验收测试）就不必这么搞，spec 的开销不划算。
什么时候用、什么时候别用
功能大到需要一页 spec 时就该用：动 3+ 个文件、多个 endpoint、或者带分支的 UI 流程。Deadline 压力让你想跳过规划（“让 agent 直接写”）时该用。被”demo 漂亮、上线翻车”咬过几次之后，也该用。
但别在 spec 还不存在的纯研究 / 探索任务上用。先做原型，搞清楚”能做什么”，再从学到的东西里归纳 spec。在探索性工作上强行 spec 优先，会制造虚假的清晰，把你从学习里带偏。Spec Kit 的维护者也是这么划线的：SDD 是给 0 到 1 的搭建和已知系统的迭代增强用的，不是给”创意探索”阶段用的。
选你的工具
这套流程在任何聊天窗口里都能手动跑，但有三个工具把它直接固化了。按你想被框住多少来选。
| 工具 | 是什么 | 流程 | 什么时候最合适 |
|---|---|---|---|
| GitHub Spec Kit | 开源 CLI（specify），10.9 万+ star（2026 年 6 月） | /speckit.constitution → specify → clarify → plan → tasks → analyze → implement | 想要一套可复用、可 review、并能跨 30+ agent 的 spec 流程 |
| AWS Kiro | spec 优先的 agentic IDE（2026 年 5 月 15 日起对新用户取代 Amazon Q Developer） | 生成 requirements.md、design.md、tasks.md，再照任务清单干活 | 想让 spec 成为工作单元，并以文件形式呈现在 IDE 里 |
| Claude Code / Cursor 计划模式 | 内置的规划闸门，零安装 | 计划模式写出编号计划，你批准后才允许改动 | 想要最轻量的版本，而且本来就活在 agent 里 |
2026 年常见的分工：复杂项目的结构化功能规划用 Kiro，快速迭代用 Cursor，深度架构推理用 Claude Code。它们都不会替你免掉那件最关键的事——在 spec 里替决策负责。
GitHub Spec Kit，两条命令上手
Spec Kit 通过 uv 安装，并把它的斜杠命令注入到你用的任意 agent 里（Claude Code、Copilot、Gemini CLI、Cursor、Codex，外加约 30 个）：
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
specify init my-feature快速试一把，在 agent 里跑精简路径：/speckit.specify → /speckit.plan → /speckit.tasks → /speckit.implement。要做关键功能，就把质量闸门加上：开头先 /speckit.constitution（项目级不可妥协的原则），写完 spec 后 /speckit.clarify，实现前 /speckit.analyze 去抓 spec、计划、任务三者之间的不一致。
Claude Code 计划模式（零安装）
不想上工具链，Claude Code 的计划模式就是那个 80/20 版本。在任意提示下连按两次 Shift+Tab。Claude 会读相关文件、把编号计划写回终端，并在你批准前拒绝改文件、拒绝跑会改状态的命令。这个批准闸门，恰好就是”写代码前先把 spec 显式说清”的纪律——只不过是工具替你执行，而不是靠意志力。
工作流，一步步走
- 先写 spec。 一页：user story、验收准则、边界情况，外加一节明确的”不做”清单。“不做”是被跳过最多、价值最高的一节。
- 让 AI 把缺口找出来。 把 spec 粘进去问：“列出这份 spec 的歧义和缺失细节。先别写代码，只问问题。“你想要的输出像这样：“用户上传 50 MB 图片会怎样？匿名上传允许吗？rate-limit 的错误 UX 怎么处理？“（在 Spec Kit 里这一步就是
/speckit.clarify。） - 照这些缺口修 spec。 这是整个任务里杠杆最高的 10 分钟。现在解决的每一处歧义，都是你将来不必付的半天返工。
- 把 spec 拆成 ticket。 问：“把这份 spec 拆成 5-8 个可实现 ticket。每个给：标题、可能动的文件、一句话的验收测试。“（Spec Kit：
/speckit.tasks；Kiro：tasks.md。） - 一次实现一个 ticket。 把每个 ticket 连同完整 spec一起给 agent，不只是当前 ticket。每个做完跑验收测试。过了就 commit，没过就修完再走下一个。
- 所有 ticket 做完跑集成测试。 把完整 spec 的验收准则当成集成测试。不通过不上线。
- 拒绝范围扩张。 AI 建议”顺便处理一下 X”时，回头看 spec。spec 里没 X，就推迟到 follow-up issue。“顺手做一下”正是功能做成 3 倍估时的真正原因。
一页 spec 模板
# Feature: [名字]
## User story
作为 [角色]，我想 [动作]，以便 [结果]。
## 验收准则
- [ ] 准则 1（具体、可测）
- [ ] 准则 2
- [ ] 准则 3
## 边界情况
- X 时会怎样
- Y 时会怎样
## 不在范围内（明确不做）
- 功能 A（推迟）
- 功能 B（另一个 ticket）
## 数据模型改动
[schema diff 或 "无"]
## API 变化
[endpoint 变化 或 "无"]这个模板刻意贴近 Kiro 的三文件拆法（requirements / design / tasks），这样你将来升级到工具时不用重学结构。
spec 放哪儿，agent 才看得到
spec 只有在 agent 每个 ticket 都去读它时才有用。两个靠谱的去处：
- 草稿 PR 描述。 在任何 AI 介入之前，先开 feature 分支和草稿 PR；PR 正文就是 spec 的标准家，而且 review 你的人顺手就能读到。
- 仓库 rules 文件。 2026 年这些 agent 收敛到了仓库根目录的一个 markdown 文件：
CLAUDE.md（Claude Code）、AGENTS.md（开放标准，Codex、Cursor、Copilot、Gemini CLI、Windsurf 都原生读）、或给 Cursor 用的按 glob 生效的.cursor/rules/*.mdc。把 spec 路径写进去，agent 就会自动加载。上下文里没有完整 spec，agent 每个 ticket 都会自己重新发明上下文。
第一次实操怎么跑
挑一个最近上线、但出现过范围扩张或晚发现边界情况的功能。回头补写它本该有的一页 spec，再跟你实际做的对比。这中间的差距，就是你的”spec 纪律”学习材料。然后在下一个真功能上跑这套流程，量一下：写 spec 是净省时间，还是觉得是 overhead？大多数开发者在第 2 个功能上看到盈亏平衡点。
完成后检查
- Spec 是不是一页装得下？装不下，就拆功能，或者你的验收准则太啰嗦了。
- AI 揭示的是真歧义，还是”你考虑过错误处理吗”这种通用废话？通用，说明你的 spec 太薄、或者 prompt 没逼住。
- Ticket 是不是干净映射到 spec 的各节？一个 ticket 跨两节，那它其实是两个 ticket。
- 每个 ticket 的验收测试能不能在 30 秒里跑完？如果”人工验”就是测试，那 spec 还不够紧。
- Agent 提的范围扩张被你拒了几次？超过 3 次说明 spec 在干活；0 次说明 agent 不够野。
FAQ
- 该用哪个模型跑这套？ 实现用 Claude Opus 4.7（SWE-bench Verified 87.6%，截至 2026 年 6 月业内最高）或更便宜的 Sonnet 4.6（每百万 token 输入/输出 3/15 美元）。终端密集的 agent 跑批用 GPT-5.5，它在 Terminal-Bench 2.0 上以 82.7% 领先。小模型抓不到”spec 里没写的”那条 prompt 的意图。
- 这不就是 GitHub Spec Kit 多绕几步吗？ Spec Kit 只是这套工作流的一种实现。这里写的手动循环是工具无关的；Spec Kit、Kiro、Claude Code 计划模式编码的都是同一条 spec → 计划 → 任务 → 实现的主干。
- 写一份 spec 要多久？ 一天工作量的功能，30-60 分钟。它在下游省回来的是好几倍——省的不止返工，还有清晰度本身。
- AI 能写 spec 吗？ 能起草。决策由你负责。没有 owner 的 spec，产出没方向的代码。这个阶段把 AI 当速记员，别当作者。
- 重构的 spec 怎么写？ 形状稍不同：改前 / 改后、为什么、影响半径。看 AI 重构工作流。
- 这不就是瀑布吗？ 不是。一页 spec 是单个功能的”做完的定义”。真瀑布是 30 页加上签字闸门。SDD 让 spec 一直活着，现实一偏离就立刻更新它。