AI 时代还要不要先做 MVP？2.11 亿行代码测出返工率从 3.3% 涨到 7.1%
你把一个想法扔给 AI，十次里有八次，它第一句回你的是「我们先做一个最小可行版本」。
这句话听起来像判断。它是回忆。Agile Manifesto 是 2001 年的，《The Lean Startup》是 2011 年的，这两份东西和它们衍生出来的几十万篇博客、课程、事后复盘，全在 AI 的训练数据里。它推荐迭代，不是因为它算过自己的账。
它算的是人的账。而这两张账单的结构，正好是相反的。
MVP 成立的四条前提，今天还剩三条
迭代不是自然规律，是一组具体约束下的最优解。那组约束长这样：
- 写代码慢且贵。 一个功能从想清楚到能跑，以人天计。
- 改代码比写代码更贵。 改要先读懂，读懂要重新进入别人（或三个月前的自己）的脑子。
- 需求会在过程中变准。 用户看到东西才知道自己要什么，所以早点拿出东西给他看有收益。
- 最关键的一条：简陋实现和完整实现之间，有巨大的成本差。
最后这条是 MVP 的经济学地基。先用 localStorage 存着，先不做权限，先写死几个配置——省下来的那几周是真的，省下来之后拿去验证假设，也是真的划算。
四条约束里，前三条今天还成立。第四条没了。
localStorage 和 PostgreSQL，在 AI 手里差几分钟
V2EX 上有个帖子把这件事说得最干净（t/1216691，标题就叫「AI 编程时代，MVP 思维已经失效了？」）。楼主的原话是：用 Cursor 描述「用 localStorage 存数据」和描述「用 PostgreSQL 加连接池」，生成时间差不了几分钟。
既然成本一样，为什么要做简易版？
这一句话就把地基抽掉了一半。你省下的不再是几周，是几分钟；而你为此欠下的东西——一套要被替换掉的存储层、一批基于它写的调用、一份要重来的迁移——一样都没少。
简陋不再便宜，它只是不再完整。
AI 的账单：上下文才是成本主体
第二半地基塌在成本结构上，这一层比第一层更隐蔽。
跑一次 agentic 任务，输入 token 的大头从来不是你那句任务描述。是系统提示、是仓库地图、是对话历史、是它读过的文件。任务描述在里面占的比例小到可以忽略。
由此推出的几条，都能查到实测：
- 每次重试，整份上下文重发一遍。两次重试就能把一次会话的成本变成三倍。
- 算上上下文开销，真实成本是裸算的 3 到 5 倍，一个 PR 落在 0.27 到 3.25 美元之间，复杂仓库里单个任务超过 20 美元也很正常。
- arXiv 上那篇《Cheap Code, Costly Judgment》（2607.01087）测出来，agentic 任务消耗的 token 是普通代码对话的 1000 倍，而且同一个任务重复跑，token 消耗的方差最高到 30 倍。
现在把人和 AI 的迭代放在一起算。
人分三期做一件事，每一期的成本差不多。因为人记得上一期干了什么——上下文装在脑子里，调用它不要钱。
AI 不记得。它每一期都要把上下文重新买一遍。
| 同样是分三期 | 人 | AI |
|---|---|---|
| 每期的主要成本 | 干活本身 | 重建上下文 |
| 上一期的记忆 | 在脑子里，调用免费 | 不存在，必须重新装载 |
| 三期总成本 | ≈ 三份工钱 | ≈ 三份工钱 + 两次重建费 |
| 多切一刀的边际代价 | 一次沟通 | 一次完整的上下文重购 |
| 迭代买到的东西 | 少走错路的机会 | 同样的机会，但要另外付摩擦费 |
迭代对人是买保险，对 AI 是交摩擦费。
GitClear 把返工量出来了：3.3% → 7.1%
上面还是推算，下面是实测。
GitClear 分析了 2.11 亿行变更代码，追踪一个叫 churn 的指标——合并之后几天内就被大幅重写或删除的代码占比。它衡量的正是「第一次没做对」。
| 年份 | churn |
|---|---|
| 2023 之前（基线） | 3.3% |
| 2024 | 5.7% |
| 2025 | 7.1% |
两年翻了一倍多。同一份研究里其他几个指标指向同一个方向：
- 提交内复制粘贴 +41%
- 代码块重复 +81%
- 错误掩盖式写法 +47%
- 跨文件函数调用（复用的指标）−35%
- 重构式的代码移动 −70%
GitClear 把 AI 放大的返工分成三类，每一类都是「先交个半成品」的直接后果：
- 位置错了——逻辑和语法都对，但放在了错误的架构位置，后来被人搬走
- 重复造了——重新实现一遍已有功能，而不是复用它
- 几天后重写——合并进去之后，因为边界情况或者约定冲突被大幅改掉
同一批研究里，AI 编写的 PR 平均带 10.83 个问题，人写的是 6.45 个，1.7 倍。
开发者自己的感受对得上这组数字。Stack Overflow 2026 开发者调查里：
- 84% 的人在用 AI 工具
- 45% 的人说调试 AI 生成的代码比自己写还费时间
- 66% 的人说最大的挫折是 AI 给的东西「几乎是对的，但不完全对」
- 而对 AI 输出的信任度只有 3%
另有一份调查给出 43% 的 AI 生成代码变更需要在生产环境里调试。
「几乎对」这三个字是关键。它意味着问题不会在你验收那一刻暴露，会在合并之后暴露——正好落在下一期迭代的头上。你以为省下的那一轮，账记在了后面。
「一次做好」不等于「一次做完」：交付粒度和执行粒度
到这儿最容易滑向一句口号：别迭代了，一次做完。那是错的，而且是危险的错。
要分开的是两个粒度：
- 执行粒度：一次改一处，改完就验证。这条今天照旧成立，甚至更重要——AI 一次动十个文件，你根本审不过来。
- 交付粒度：这一轮交出去的东西，是不是成品。
「一次做好」说的是后者。它约束的是完成度，不是功能数量。
范围可以很窄，窄到只有一个页面、一个接口。但这一轮定下来要做的部分，得是完整的：真实的数据结构，不是占位；加载、空、错误、成功四种状态都在，不是只有理想路径；能真的跑起来给人用，不是截图。
MVP 这个词最大的问题是它把「范围窄」和「做得糙」打包卖了。以前它们确实绑在一起——想省钱只能两个一起省。现在它们可以拆开：范围仍然要窄，糙已经不省钱了。
「MVP 是验证假设，跟 AI 无关」——四条反驳里哪两条站得住
那个 V2EX 帖子底下的反对意见比主贴更有价值。逐条看：
1.「MVP 的核心是验证假设，跟代码无关，跟 AI 不 AI 也无关。」
站得住，而且它正好说明了问题出在哪：MVP 这个词一直混装着两件事——验证一个假设，和交付一个残缺的实现。以前这两件事必须捆在一起，因为验证假设的唯一便宜办法就是做个糙的。现在它们解耦了。假设照验，但你可以拿一个完整的东西去验。
2.「你永远没办法一次性了解潜在用户的所有需求。」
站得住，而且它跟「一次做好」不冲突。没人要求你一次做完所有功能。要求的是你这次做的那部分别留半截。
3.「逻辑复杂的项目，尤其是有复杂业务循环和状态机的软件系统，一步到位结果就是一坨。」
这是真问题，但它是执行粒度的问题。复杂状态机当然要一步一步来、每步验证。它不构成「先交一个明知道要重写的版本」的理由。
4.「有了 AI 迭代可以飞快，成本极低。」
这条不站得住。上面那两节就是它的反例：快的是生成，不是收敛。churn 从 3.3% 涨到 7.1% 量的正是这个差。
把「禁止分迭代开发」写进全局规则之后
我在自己的全局规则里写死了一条：禁止分迭代开发，交付即成品，不允许 MVP 和阶段性交付。
落到具体动作上是这样的：
- 第一轮就要求真实数据结构和真实内容，不许有 Lorem ipsum，不许有假数据
- 四种状态一次交齐，加载、空、错误、成功
- 交付之前必须自己跑一遍，浏览器里点开、命令行里执行、接口用 curl 打一遍
代价是真实存在的：第一次描述要长得多。 你得在动手之前把边界、状态、数据结构想清楚，这部分工作没被 AI 拿走，只是从「第三轮返工时被迫想清楚」挪到了「第一轮开始前主动想清楚」。
收益也很直接：不用第二次、第三次把同一件事重新讲一遍。而重新讲一遍，正好是上面那张账单里最贵的一项。
范围该切多窄，AI 帮不上
这个问题仍然没有答案。
「一次做好」的前提是范围切对了。切得太宽，一次做好变成一次做很久；切得太窄，做出来的东西没法验证任何假设。这一刀切在哪，靠的是对用户和场景的判断——那篇论文的标题已经把话说完了：代码变便宜了，判断没有。
讨论