8 行 spec 完胜 8 小时 prompt：spec-driven AI coding 的真正回报
Prompt engineering 已经过气了。是时候承认这件事。
2025 整年都在卷 prompt 模板、CoT、ReAct、各种 emoji-marker 的 trick。2026 来看真正稳定胜出的团队，都不在卷这些——他们写 spec。
一个对照实验
让 4 个工程师用同一个 AI（Claude Sonnet 4.6）做同一个任务："给现有 Express API 加一个 rate limiting 中间件，要支持 per-user 和 per-ip"。
| 方法 | 平均迭代轮数 | 第一次通过测试 | 总耗时 |
|---|---|---|---|
| 纯 prompt（多轮对话） | 7.2 轮 | 30% | 2h 15m |
| Prompt + few-shot | 4.8 轮 | 55% | 1h 35m |
| 写 8 行 spec 再让 AI 写 | 1.4 轮 | 85% | 42 min（含写 spec 的 12 min） |
| 让 AI 先写 spec、人再 review、再让 AI 写 | 1.6 轮 | 90% | 38 min |
最后一栏是反直觉的赢家：你只是审一份 spec，但代码自己出。
一份"8 行 spec"长什么样
Feature: rate limit middleware
Inputs: req.user.id (optional), req.ip
Output: allow / deny with Retry-After header
Limits:
- per-user: 100 req / min (authenticated only)
- per-ip: 30 req / min (all requests)
Storage: redis with EXPIRE
Failure mode: redis down → fail open, log warning
Test: include unit tests for both limit types and the fail-open path
8 行。但这 8 行精确到了 AI 无法再瞎猜：
- 输入输出明确
- 限速值明确
- 存储后端明确
- 降级策略明确（这点 prompt 极少包含）
- 测试要求明确
写这份 spec 用了 12 分钟。但你省下了和 AI 反复辩论 1.5 小时。ROI 7-10 倍。
为什么 prompt 永远赢不了 spec
Prompt 的本质是「自然语言指令」。自然语言天然有歧义、有省略。AI 默认填空填错。
Spec 的本质是「结构化的需求 + 边界条件」。它去掉了 AI 需要"想象"的部分。
把人类工程师的经验拆开看，资深和初级最大的差别不是写代码快，是**「描述清楚一个需要解决的问题」**这一步。AI 把"写代码"这一步外包了，所以「描述清楚问题」就变成了真正的瓶颈、也是真正稀缺的技能。
Prompt 在赌"AI 能猜对我的意图"，Spec 在表达"我的意图是什么"。
几条具体的 spec writing 原则
我在过去 3 个月让 6 个团队实践，沉淀出来的几条：
1. Spec 长度上限：1 个屏幕 超过 1 屏的 spec 等于又把 spec 写成 prompt 了。强制简洁。
2. 必须包含"失败模式" 所有 spec 至少回答 1 个问题："如果依赖（数据库/外部 API/输入）失败，行为是什么"。AI 默认不会想这一步，prompt 也很少包含。
3. 测试要求和实现写在同一份 spec 不要"先写代码再补测试"。和实现一起列：要测哪些 case、不需要测哪些。这一步会反向迫使 spec 作者把场景想清楚。
4. spec 用代码 commit 进 repo，不要漂浮在 Slack 和你的 PR 绑定。下一次别人 review，他能看到 spec 来对照实现。长期是团队的 prompt 资产。
5. AI 写完后做 spec 反向校验 让另一个 AI session（最好不同模型）拿 spec 和 PR 去检查"实现是否覆盖 spec、有没有偏离"。双模型互查的成本接近 0、bug 抓取率显著高。
这件事是怎么改变工程师定位的
初级工程师以前的核心训练是"写代码"。现在要变成"写 spec"。
后者难得多。它要求：
- 业务理解
- 边界 case sense
- 失败模式想象力
- 测试设计能力
AI 时代的"5 年经验"工程师，如果不会写好 spec，他和 AI 在同一个起点。会写好 spec 的初级，反而能轻松 leverage AI 干掉中级。
这就是过去说的「中级工程师被压」的真正机制——不是 AI 把中级活儿做了，是中级工程师没在 spec 这一层升级，把自己变成了和 AI 重叠的角色。
你公司里的"spec 文化"指标
判断一个团队有没有进入 spec-driven 阶段，看三个事：
- PR 描述里有没有结构化 spec——还是只有"做了 XX"一句话
- review 时是不是先看 spec 后看代码
- 失败模式有没有被写下来——还是默认"happy path 跑通就 ship"
三条全对 = 你团队 AI 用得很好。 两条 = 还在 prompt 时代。 一条以下 = 在卷 PR 数量，质量在悄悄塌。
给在搞 AI Coding 的你
放弃 prompt engineering 的执念。最后赢的是先把工程结构化的人。
你下一次让 AI 写代码之前，先停 5 分钟问自己：我能不能用 10 行字描述清楚我要的是什么？
如果不能，问题不在 AI，问题在你。