AWS资深工程师直言：AI写代码越快，越需要“先写规格”

当所有人都在追求用大模型“秒出代码”时，AWS 的一位资深工程师却泼了一盆冷水：真正能让你写得更快、更稳、更可控的，不是更强的模型，而是更严格的规格文档。这场关于 Spec-Driven Development 的分享，揭示了一个反直觉却正在成真的开发新范式。

最反直觉的一点：AI 不是高级工程师，而是“过度热情的实习生”

Eric Hanchett 一上来就点破了一个很多人不愿承认的事实：我们每天用的这些大语言模型，更像是“过度积极、但缺乏边界感的 AI 实习生”。你给它一句模糊的需求，它不会停下来确认，而是立刻埋头苦干，甚至一路跑偏。

他讲了一个自己的真实经历：刚当实习生时，只要 VP 随口提一句想法，他就会立刻放下手头工作去实现，结果反而被直属经理质问。后来他才明白，正确的流程是：把想法写下来、形成需求、评估优先级、再进入执行。

Spec-Driven Development，本质上就是把这套“成熟工程师的工作方式”，强行灌输给 AI。不是让模型更聪明，而是让它更受控。Eric 的一句话非常狠："只要给 AI 一点自由，它就会彻底失控。"

为什么模型再强，也救不了没有规格的代码生成

一个常见的质疑是：现在的前沿模型已经这么强了，为什么还要多此一举写规格？Eric 的回答并不浪漫，但极其现实。

第一，模型永远需要上下文，而规格文档是“高密度、低噪音”的上下文。没有规格，你只能靠反复 prompt 修补；有规格，模型一开始就知道边界在哪。

第二，软件开发的现实是：需求一直在变。今天是新功能，明天是合规调整，后天是架构重构。Spec 文档不是一次性的，它是一个可以持续更新、反复对齐的“锚点”。

第三，也是最容易被忽视的一点：你才是最终责任人。Eric 反复强调 Human-in-the-loop——不管代码是谁写的，出了问题，背锅的人一定是你，而不是 agent。Spec 的存在，本质上是在帮你留下一条“理性决策链”。

从“氛围编程”到规格驱动：AWS 团队踩过的坑

Eric 分享了一个很有代表性的背景：在 AWS 内部和客户中，他们发现大量团队在“vibe coding”——感觉对了就让 AI 写，但结果经常不对。

很多团队已经自发形成了一种变通流程：先让 agent 写需求文档，再写设计文档，最后才是代码。AWS 干脆把这件事系统化，做成了 Kiro 这个 AI IDE 助手，把它拆成两种模式：vibe mode 和 spec mode。

但 Eric 特意强调：你不需要 Kiro 也能做 Spec-Driven Development。核心流程只有四步：
- 需求文档（EARS 格式的用户需求）
- 设计文档（可以有架构图、Mermaid 图）
- 实现任务拆解（task list）
- 基于规格的测试（包括 property-based tests）

关键不是工具，而是节奏：每一步都要停下来由人审一遍，改一遍，再继续。

真正的硬核细节：规格、测试和 MCP 怎么连起来

这场分享里最“内行”的部分，藏在几个容易被忽略的细节中。

第一是“Goldilocks zone”的上下文原则：信息不是越多越好。Eric 提到 steering docs——专门用来“引导模型行为”的文档，比一次性塞满背景资料更有效。

第二是 property-based tests。Kiro 在实现阶段，会基于需求和设计自动生成性质测试，而不是只测几个例子。这意味着测试本身也在“对齐规格”，而不是事后补救。

第三是 MCP（Model Context Protocol）。尽管有人唱衰它，但 Eric 很看重它在规格驱动中的价值：直接从 Jira、Asana 拉取真实需求，让规格不是凭空生成，而是嵌在现有流程里的。

最后一个实战建议非常实用：先做 MVP。把 task list 重排，优先跑通最小闭环，让规格尽早接受现实检验，而不是写成一本文档小说。

总结

Spec-Driven Development 并不是让你写更多文档，而是让你把“思考”前置，把“试错”变便宜。在 AI 能力极速膨胀的今天，真正拉开工程师差距的，不是你会不会用模型，而是你能不能为模型设定清晰的边界和目标。

一个可执行的行动建议是：下一个中等复杂度的功能，不要直接开写代码。先用 AI 生成需求和设计，用 30 分钟认真改一遍，再让它写实现。你会第一次感受到：AI 不只是快，而是开始“听话”了。

关键词： Spec-Driven Development， 大语言模型， 代码生成， AI Agent， AWS

事实核查备注： 需要核查：1）Eric Hanchett 的职位为 AWS Senior Developer Advocate；2）Kiro 是否为 AWS 发布的 AI IDE 工具及其官网 kiro.dev；3）Spec-Driven Development 中 EARS 格式与 property-based tests 的具体用法；4）Kiro 发布后下载量“数万次”的说法；5）MCP（Model Context Protocol）的当前状态与定位。