规范驱动开发（SDD）火起来，不是因为大家突然爱写文档了，而是因为 vibe coding 露了馅。你甩给 AI 一句话目标，它回你一坨代码，乍一看像那么回事，跑起来却差口气。GitHub 自己都说得很直白：2025 年 9 月推出 spec-kit 时，他们形容模型“擅长模式补全，不会读心”。大家的解法于是变成了：把需求写得又细又全，在动手前就一次性塞进 SPEC.md，让 AI 别瞎猜。几个命令下去，GitHub 到底是 GitHub，spec-kit 迅速带起了一波节奏，AWS 的 Kiro、Tessl、BMAD、Agent OS 紧随其后。不到一年，SDD 成了显学。

不过先纠正一个常见的误读。SDD 不是 AI 时代的发明，早有人把它翻了个底朝天。Larman 和 Basili 2003 年在 IEEE Computer 上追溯过，迭代开发的理念 1950 年代就有；Royce——也就是常被扣上“瀑布模型之父”帽子那位——从一开始就质疑过那种一次成型、文档驱动的理想。2004 年 XP 大会上，Ostroff、Makalsky 和 Paige 的论文《Agile Specification-Driven Development》甚至不是鼓吹大规格说明书，而是恰恰相反：所谓“完整”的规格本身就是个伪命题，规格应该从测试和契约里长出来。他们写到 complete 这个词时，都忍不住打引号。所以现代 SDD 在 AI 浪潮之前就有了工业实践。vibe coding 的破产没有发明 SDD，只是把它送上了风口。真正点燃这根引线的人是 Andrej Karpathy，他发明了 vibe coding，而不是 SDD。他连接了两个时代，后来也是他先说 vibe 时代快结束了。把两个词都安在他头上，是偷懒的写法，错了。

下面要说的这个版本，才是对的，而且几乎没人讲。因为大家还在 SDD 里挣扎。

SDD 的窟窿，是 Agent 替你填的

SDD 真正的毛病在于：每个人都按自己的方式写规范。里面塞满了需求、实现，甚至工程师当天早上脑子里想的所有东西。然后 Claude Code、Codex、Droids 这些 Agent 读着这份规范，遇到大窟窿，就自己做决定。这些窟窿不是规范的 bug。

这是两个“人”的缺口，不是工具的锅。第一，工程师从没认真学过“规范”到底该长什么样。我们以为自己会写，毕竟写了 20 年。但那是给老板看的规格，不是给 AI 干活的指令。第二，现在网上炒得最火的方法，大多是给那些“理想环境”准备的。一个四十分钟 YouTube demo 里，在全新小项目上游刃有余的方法，放到十年历史、十二个团队、合规审查晚上睡不着觉的真实企业代码库里，完全是两码事。这行的营销层，正在把演示当方法论卖。演示和方法论之间的差价，下游会一分不少地买单。

OpenAI 的 Symphony 规格，恰恰证明了我的观点

看看 OpenAI 2026 年 4 月发布的 Symphony 就知道了。它是一份公开的智能体编排规范，核心文件 2,169 行，十八个章节，正式到 must/should 的措辞。这份深度刚好说明了我们要求人做什么，也说明人根本做不到。

如果谁都能在动手前写出这么一份 SPEC.md，那 SDD 确实能跑。这话不是讽刺，是字面意思。一份完整、无歧义、两千行的规范，确实能产出好软件。OpenAI 内部花了六个月做了一款工具，规定不能手写一行代码，全部由 Codex 生成。跑通之后，他们才从运行中的系统里提炼出这份规范。接着又让 Codex 用 Elixir 一次性实现参考版本，再用 TypeScript、Go、Rust、Java、Python 五种语言分别实现同一个规范，目的就是把所有歧义都震出来。这份深度达 RFC 级别的规范，是对已经跑起来的软件的回顾性文档。这是 OpenAI 自己说的顺序，不是我加戏。正所谓“纸上得来终觉浅，绝知此事要躬行”。

所以规范是有效的——前提是你能在事前写出来。这才是陷阱：你写不出来。而唯一一家写出这种规范的公司，是先把软件做出来，再反向提炼。整个行业却在把这个过程的输出，当成方法论本身在卖。

我自己也踩过这个坑

那份规范写得不错，但 Agent 还是跑偏了，因为我中途当了甩手掌柜，让它替我填了我没想清楚的部分。我曾把这叫“漂移”。其实根本不是漂移，“漂移”只是你不想承认自己“离场”时找的词。我花了整整三天返工，把本不该出现的代码一点点拆掉。我日常跑 1.5 到 2 亿 token 的 Agent 工作流，按 Opus 的单价，三天返工的 token 成本大概是 985 美元——真金白银，先花钱造出问题，再花钱把它抹平。这是我在这篇文章里代价最小的一次失败，毕竟是自己机器上花的自己的钱。规范写得好，反而更说明问题：好规范不是自己会立住，而是需要有人守在循环里。那次，我没守。

ICE：三门手艺，一个循环

替代方案我叫它 ICE：Intent（意图）、Context（上下文）、Expectations（期望）。这篇文章先讲 Intent，因为它是其他一切的原子。Context 和 Expectations 也是真本事，但三样一起塞进来，又会变成一张臃肿的大文档——那正是我们要躲开的东西。所以先把 Intent 说明白。

举个最俗的例子。业务情况：用户想买一双 90 美元以下的红鞋。意图就是“用户想买一双 90 美元以下、真的能买到的红鞋”，里面不规定任何技术栈或服务。Intent 是这个方法的第一性原理，但它不是一句话。五样东西合在一起，才配叫 Intent：想要的东西是什么、约束条件是什么、什么情况算失败、什么情况算成功、以及它和其他意图的连接——改了这里会牵动哪里的链路。缺任何一条，你都会留一个窟窿让 Agent 替你填。

如果下周一你只做一件事，就做这件事。挑一个本周要交付的真实结果，不是整个系统，就一个结果：90 美元以下的红鞋。把这五部分写清楚。想要的东西：用户能买到一双 90 美元以下的红鞋。约束：有货、尺码合适、能配送。失败情况：返回一双 140 美元的鞋、一双缺货的鞋、一双不是红色的鞋。成功情况：用户把一双价格合适的红鞋加进购物车并完成结账。连接：任何涉及价格、库存、结账的改动，都会牵连到这里。然后做个测试：把它交给一个完全不知道你在想什么的人，问 ta 哪里 Agent 还得靠猜。ta 指出的每一个地方，都是你差点让 Agent 自由发挥的窟窿。把这些窟窿填上，而不是把整个世界都文档化。这就是第一步，花一个小时，不是上一个方法论。

期望（Expectations） 是人们通常称作“规范”的部分，但我故意不用这个词。它是边界：什么情况下结果算完成，什么情况下算失败，以及不能越过的红线，而且要用用户能听懂的话写，而不是实现细节。把它作为一门独立的技艺，由同一个 owner 守住，这才是解药。一旦“完成”的定义从想要结果的人手里滑走，Agent 就开始替他们决定什么叫“done”。

上下文（Context） 是“怎么做”：技术栈、现有系统、代码库的约束。它应该由 harness 按需逐步拉取，而不是开头就糊一堵墙。剩下的——模型、提示词、编排、真正跑循环的 harness——都只是机械层。

三大手艺只有动起来才有意义，所以下面就是这个循环。

ICE 工作流循环：人类提供意图与期望，Harness 循环执行拉上下文、编码、验证直到满足期望并合并代码

人类只给两样东西：意图，以及定义“什么叫完成/什么叫不能碰”的期望。它们进入一个 Agent 工作循环：harness 拉取上下文、写代码、用期望验证；不满足就再来，直到满足，然后代码合并。人类永远攥着意图和期望不撒手；harness 负责跑循环，从不被允许去发明人类到底想要什么。这就是 ICE 的核心。SDD 之所以崩，是因为它要求同一份文档、由当时敲键盘的人用他的风格写，同时充当意图、完成定义、工作流和上下文，中间的缝隙全交给 Agent 自由裁量。

还要说清楚：harness 不是方法。spec-kit、BMAD，还有那些 prompt+workflow 的工具，都是 harness，有用的 harness，但也只是 harness。ICE 才是方法：在 harness 碰活之前，先决定“这活是什么”。现在普遍的玩法是只 adopt harness，因为下载按钮最显眼；没有方法只有 harness，就会复现我那三天返工的失败，只不过规模放大，客户名字挂在账单上。

我把它叫 IDSD：意图驱动软件开发（intent-driven software development）。正常的工作方式不是写死规范，而是声明结果，让机器决定实现。

有人说这不过就是换个名字的规范。文件层面他们说得对，但所有权变了。这些都是 markdown：intent、expectations、context，格式从来不是问题的根源。变的是每个文件是什么、由谁负责。不再有那份 sprawling 的规范：原来 sprawling 的东西现在被拆成 expectations，一个简短的边界，由想要结果的人来写，而不是由当时碰巧握着键盘的人来猜。Context 是 Agent 工具干活的方式，由 harness 拥有，而不是和用户的愿望挤在同一段落里。过去“一个人凭早上心情写一份文件”的玩法被打破了；现在是一个意图 + 一套明确的期望，交给一个跑构建的 harness。这是完全不同的两件事。

IDSD 至少比行业现状高两级

我把这个实现给团队看。不是理论，是真家伙。我展示了怎么为一个消费级情形写意图，又怎么写一个给 Agent 消费的意图，包括约束、失败情况，以及它牵连的所有其他意图的回链。我观察着他们的反应。第二页 PPT 你就能读出房间气氛，那次安静得不太对劲。

团队里一位干了十八年的老顾问先开口：“很多团队 SDD 还没整明白呢。这玩意出来才一年，大部分人都在假装做。你现在又要求他们把意图和期望当成独立手艺写，还要做追溯。这比团队实际水平高了两级。”

另一位同事让讨论继续滑了一会儿，才轻轻说了一句：“等一下。”声音很轻，像只是个小问题。“团队没准备好不是风险。真正的风险，是哪天一个 Agent 一晚上写了一万行看起来没毛病的代码，却没人拥有‘什么算对’的解释权。我们不是在让他们学一种更难写规范的方法，而是在要求他们守住一种最容易被跳过的判断。”

她四句话把整件事说了回来，还把老顾问的反对变成了必须做的理由。我走出会议室时的结论是：老顾问说得对，团队确实跟不上；但她说得也对，答案不是等他们准备好，而是把那件最不能跳过的事变得不可能跳过。后面我做的所有事情，都在朝这个方向努力。

真正让我睡不着的事

说实话，我担心的事还没完全解决。

我的团队做项目时，会漏掉系统的关键部分。这就是那位同事轻轻点出来的“一万行看起来对的代码”。不是他们不行，而是现在生成代码太容易了，生成越容易，你越能以一种自信的姿态大量出错。2025 年 METR 做了一项对照实验：有经验的开发者用 AI 之后速度反而变慢，却坚信自己变快了。“又快又错”就是整个失败的浓缩。我们会花时间和金钱，把错误的东西做得很好。这让我睡不着，而我手上有账单证明这担心不是杞人忧天。又是那三天返工，只是规模大得多，账单上写着客户的名字。

真正的解药，我相信但还没完全做到，就是全程在场。不是最后才出场、对着一个已经大得读不完的 diff 点头的审查者，而是工作发生时就在团队里。我把它作为核心指标：在场，而不是在关卡盖章。我做得还行，但不能时刻做到。那个想信任 Agent 然后走开的我，和那个买了三天返工单的我，是同一个人。我太熟悉这个失败了，因为我不止一次当回头客。

最后是谁在买单

说到底，这不是一个软件工程故事，而是一个经济学故事。而最底层买单的人，可能一辈子没见过什么规范。

有两种建造方式，行业心知肚明，只是不说。一种是手写代码，写得慢，但跑起来便宜，因为算力早就是白菜价了。另一种是靠 Agent，写得快，但跑起来贵。不是 token 涨价了，恰恰相反，token 单价一直在跌。贵是因为 Agent 一旦去填那些窟窿，就会烧掉比完成一个结果多得多的 token，而且其中惊人比例花在了“自信地做错”上，等有人发现时已经晚了。

坏掉的 SDD 站在贵的那一侧，而且它不安静地待着。它会抬高整个软件建造成本，而卖方法论的厂商和做 demo 的网红并不承担这笔成本。

SDD 崩了，是因为我们让人类去做一件人类根本做不到的事：在东西存在之前就把它完整描述出来。它还崩在那些方法论本来就是为 demo 设计的。这些成本不会凭空消失，只会往下游转移。最终落到客户头上，以及客户服务的那些人头上——他们没读过规范，甚至不在那个决定做坏的房间里。

我的团队正在往 IDSD 转。意图和期望写得有纪律，上下文只给真正需要的，然后让 Agent 干活。我有点慌，但该做还得做。背后的原则是 dogfooding：在方法到达客户账单之前，先把它用在自己身上。飞轮只有转起来才会复利，而转起来需要有人先推第一把。这就是开始。

所以问题不是 Agent 能不能干活。它能。问题是你有没有纪律自己拥有意图和期望，有没有胆量在机器运转时留在循环里——尤其是在你明明可以走开、去“祝福”那个 diff 的时候。那一天，才是关键。所谓“行百里者半九十”，最后那段路才是胜负手。你怎么选？