AI驱动开发反思：过度规格化反而拖累AI编程

9 月 5 日，我从自动驾驶代理的仓库里一次提交删除了 1,782 个文件。Agents、模板、工作流配置、一份 PRD（产品需求文档）、一份架构文档、一份比大多数小说还长的故事待办清单。大约 16 MB 的流程文件，没有一行产品代码。

敲下那条提交信息的感觉，比那个月交付的任何东西都要好。

先交代点背景，如果你第一次听说这个项目。我的自动驾驶代理是一个自主编码系统，我构建并运行了几个月：它接收 GitHub webhooks，运行无头 Claude Code 会话，在不需要我操作键盘的情况下完成代码编写、审查和合并 Pull Request。我之前写过从构建到它燃尽 token 那一天的全过程。但那些帖子都绕开了一个问题：在 agent 看到任务之前，工作应该怎样规划。

业界对这个问题有答案。SDD（Spec-driven development，规格驱动开发）：先写规格，让规格成为契约，然后让 agents 根据规格实现。BMAD 就是这个理念的全面落地——一个完整的敏捷组织被搬进了软件里，有 AI 分析师、架构师、产品经理和开发者，还有一套按顺序运行它们的工作流。整整四周，它在为我规划产品。

这篇文章要讲的是那个月的代价，以及那个小得令人尴尬的东西——它才真正解决了 BMAD 本应解决的问题。如果你运行编码 agents，而你的 PR 老是在变成"人质谈判"，这篇文章就是写给你的。我错了两次才找到正确答案，而那两个错误的答案在当时看起来都很聪明。

引发这一切的失败

你经历过这种失败。这周你可能就犯过。

你很忙，agent 能力很强，所以你提了一个一行的问题：去掉这个，加上那个，让它可配置。Agent 看到了你的描述，构建出来的要么是错误的东西，要么是对正确东西的过度设计。然后你花大价钱请来专门捕捉问题的审查模型，在审查中捕捉到了问题——在工作已经存在之后，在钱已经花掉之后。

我最严重的一次：一次本该安静删除的清理工作，跨越十轮审查，收到了六十条评论。两个模型相互争论，一轮又一轮，每一轮都在向我收费。然后我关闭了那个 Pull Request，没有合并。

六十条评论。十轮审查。没有交付任何东西。而整场争论都源于我在三十秒内写下的那一行描述。

尝试 1：机器试图自我修复

我的自动驾驶代理对"PR 太大"问题的回答是——我发誓——更多的自动驾驶。

它生成了一个规模门禁：一个 scope agent 估算每个 issue 会产生多少 diff，超过了预算就把工作拆成有序的子 issue。近六千行新代码，就为了强制未来的代码遵守行数预算。这不是我设计的，是机器设计的，而且它对问题的诊断也很准确——它自己的 PR 描述诊断出大规模 PR 是导致审查翻车的原因。

但它还是在攻击症状。门禁是在意图已经写糟了之后才去度量工作。工作拆分是事后进行的，根本不是真正的规划。一旦有了 diff 需要评估，犯下的错误就已经根深蒂固了——问题早在 issue 里就铸成了。

我从未合并它。最危险的部分是它看起来是那么合理。

我是通过一个关于规格驱动开发的播客发现 BMAD 的。其中一位嘉宾是 BMAD 的贡献者，他说的每件事听起来都很扎实。我渴望这种扎实。我厌倦了和自己的 Pull Request 争论。

所以在拒绝了机器的六千行修复方案的第二天，我安装了一个包含 1,782 个文件的方案。

BMAD 像企业规划卫星发射一样规划我的产品。一份 13,397 字的 PRD。一份 19,867 字的架构核心。一份达到 43,062 字的 epics.md 待办列表。九个 epic，八十六个 story，每个都有验收标准。读这个计划的感觉就像是终于有了成年人的监督。

五天后，实现就绪评估发现了一个关键遗漏和三个主要规划缺陷，阻断了所有进一步的实施。仔细想想吧——计划在计划的审查中失败了。同一天批准的修复方案将计划扩大到 91 个 stories。产品没有任何进展。

然后循环开始了，我开始见识到真正的账单。一个典型的 story 消耗了一到两百万 token。一个 story 达到了约三千万。三千万 token，一个 story。也许我配置错了什么；说实话，我可能确实配错了。但看看我的配置为了自保变成了什么：每个 story 四百万 token 的预算、二百一十分钟的会话超时、七次审查轮次的硬上限、没有结果的会话的推动预算。这些不是配置。这些是限制令。

公平地说，bmad-loop 本身确实做得很好。TUI 令人印象深刻。质量标准是真实的；审查确实捕捉到了真实的缺陷。四周内，23 个 stories 通过它实现并审查。还有六个完成了代码但停在"等待操作员"状态，等待只有人类才能做的事情。

但我的产品还很年轻，变化很频繁，每次变更都创造了作业。更新 PRD。更新架构。更新待办列表。文档需要保持最新，代码才能被允许移动，所以代码以文档的速度移动。

我本该操作一个自主系统。我却成了它的秘书。

我的判断不是 BMAD 不好。BMAD 很扎实。太扎实了。对于一个规格稳定、已建立的产品，这个标准可能恰好合适。对于仍在寻找形态的产品，这个标准扼杀了唯一重要的指标：发布的时间。9 月 5 日，整套东西在一次提交中离开了，发布线在同一天向前移动了。

尝试 3：偷走好的部分，跳过宗教

这是真正有效的方法，也是我会告诉你做的，而不是我那两个失败的做法。

我没有采用另一个框架。我从规格驱动世界拿了那个真正有价值的东西——Spec Kit 表达意图的方式——然后把它塞进了我已经用来提交工作的 add-autopilot-issue 技能里。Spec Kit 在 BMAD 包罗万象的地方做到了简洁，它问的问题恰好是真正重要的：什么改变了，为了谁，你怎么知道它有效。

现在运行我接收流程的机制，都很小：

每个 story issue 都带有一个固定的规格引用：Spec: owner/repo@sha:path#user-story-N，需要完整的 40 字符 SHA。Coder 和 reviewer 读取同一版本，这样任何人都不能在会话中期通过编辑规格来移动球门柱。

一个 user story 对应一个 issue。两个或更多则变成一个父 epic issue，每个 story 一个 issue，并带有 epic/NNN-<slug> 集成分支。

超过 12 个 task 的 story 在提交前会被拆分。

审查根据固定的规格运行，使用 BLOCKING/SHOULD/NIT 评价标准，这样"我不喜欢它"和"这违反了规格"不再是同一条评论。

还有一条没有代码强制执行的规则，因为这是我的规则：当我写 issue 时，我的目标是大约 300 行非测试代码。足够小以至于会话不会偏离，足够小以至于审查不会失控。

这就是整个修复方案。一个重新设计的技能和一行固定的文字。我尝试过的最小的东西，也是唯一仍在 main 分支上的。

在它开始之前就决定了

三次尝试，一个穿着三种服装的教训。自主编码会话的质量和成本在它开始之前就决定了：由意图表达得多精确，以及工作到达时多小。规模门禁试图在代码中强制执行，但在意图之后。BMAD 试图在文档中强制执行，在意图之上。有效的方法就是去做：精确地说出我想要的，以足够小的块来承受审查的接触。

还有一个观察，作为观察提供，因为我还没有测量它，而且它显然不是线性的：意图表达得越好，执行它的模型就越便宜。

还有一个判断，给现在正在权衡 BMAD 的人。我没有浅尝辄止。我运行了完整的、基本的方法，按照它被设计的方式运行，但它对我来说不工作：太长了，太贵了。对于一个规格稳定且能容忍繁文缛节的企业，同样的重量可能恰好合适。我的项目进展很快，BMAD 无法跟上。所以实验关闭了。我不会在任何我的项目上运行它；更灵活的方法以一小部分成本携带了它最好的想法。

这就是那 1,782 个被删除文件的意义。不是 一个失败的工具。