我们注意到，开发者社区最近在密集讨论一个新词：SDD，全称 Specification-Driven Development——翻译过来就是「规格驱动开发」。起因很朴素：越来越多工程师发现，让 AI（像 Claude Code、Cursor 这类工具）"凭感觉"写代码，效率其实很低——小功能来回改五轮，逻辑反而越改越乱。
这是什么
SDD 不是新发明。早在 2000 年代瀑布模型时代就有类似理念，但它真正"复活"是 AI 编程之后的事。过去人写代码，规格文档写完没人看；现在 AI 写代码，规格变成给机器的指令集——写得越精确，AI 生成的代码越可控。
主流工具（GitHub 的 Spec-Kit、亚马逊的 Kiro、Tessl 等）基本遵循同一套四步流程：先写 Spec（功能边界与验收标准）→ 再写 Design（技术方案）→ 拆 Tasks（任务清单）→ 最后生成 Code。文章作者的亲历：优惠券核销接口，「凭感觉」让 AI 写崩了 5 轮，按 SDD 流程重做一次就跑通。
行业怎么看
支持者认为，SDD 抓住了 AI 编程的本质矛盾：AI 不是「理解需求的同事」，它是「严格执行工单的施工队」。工单模糊，施工就失控；工单清楚，一次到位。GitHub、亚马逊相继推出官方工具，说明大厂已经把 SDD 当作工程师与 AI 协作的标配在推。
反对声音同样尖锐。有开发者指出，SDD 本质上是把「写代码」的成本转嫁到「写文档」上——你花了 10 分钟写 Spec，可能比直接写代码还累。对于一次性脚本、小工具、个人项目，SDD 是杀鸡用牛刀。更何况，现实中需求经常变，Spec 写完第二天就过期，文档维护成本反而成了新负担。还有人质疑：当前 AI 模型对长 Spec 的遵从度并不稳定，AI 经常"自作主张"跳过某些条款，号称「按 Spec 写」却偷偷改设计——你还是要逐行 review 代码。
对普通人的影响
对企业 IT：如果公司正在评估「AI 提效」，SDD 提供了一个可落地的考核维度——不是看代码生成速度，而是看规格文档与产出的对齐率。这会重塑外包管理与软件采购的话语权。
对个人职场：非程序员也要警惕——产品经理、运营、咨询顾问，如果习惯用「大概是这样」和 AI 协作，输出质量会越来越不稳定。「写清楚你想要什么」正在成为跨岗位的通用技能。
对消费市场：短期内你看不到变化。但中长期，软件交付成本下降意味着更多小工具、SaaS（按订阅付费的软件）会冒出来——同时 bug 率也可能上升，因为太多团队跳过了 Spec 这步直接「氛围编程」。