5 个人 7 天干完了 20 人几周的活，但第一天他们一行代码都没写

先说一个我自己都不太信的数字。

5 个人，7 天，干完了传统需要 20 个人干几周的工作量。

这活儿是拿他们自己的开发工具做的——用 Qoder 开发 QoderWork。用的就是被测的那个东西。

我第一反应是：这不扯淡吗？

然后我去看了他们的日程，第一天做的事是：

什么都没做。

DAY 0，一整天，只写文档，一行代码都没写。

DAY 0 到底干了什么

这一天他们干了四件事：

1. 定义 MVP 边界——第一版到底做哪些功能，不做哪些
2. 拆解模块——把这件事分成哪几块
3. 给每个模块写 Spec（一份「说明书」，说清这个模块要干什么、怎么算做对）
4. 把所有 Spec 汇入仓库的一个 Wiki 页面，让 AI 每次开工都能读

一天下来，代码产出：零。

然后 DAY 1-2 搭架构，DAY 3-4 增量写 Spec 并并行开发，DAY 5-6 让 AI 自己跑一遍（他们叫 dogfooding），DAY 7 发布。

约 80% 的功能代码是在 DAY 3-4 完成的。

对，你没看错，写代码的时间只占 7 天里的 2 天。

他们自己的结论是：

DAY 0 是最"贵"的一天，也是最"值"的一天。

还有一句被引用得很多的话，来自微软的点评：

SDD is version control for your thinking.（Spec 驱动开发，是你思考的版本控制。）

为什么"先写一天废话"反而更快

这个逻辑我一开始不理解，直到我把自己的失败经历对上了号。

我去年做过一个功能，需求很明确，我判断 AI 三下五除二就能搞定。

结果AI 写完了，页面看着能跑，但我点了两下就发现——它理解的那个需求和我脑子里的需求，是两个东西。

更糟的是，它还挺自信，代码结构还挺漂亮。

我花了两个小时才想明白问题出在哪：我从头到尾没有告诉它「这件事做到什么程度算做对」。

于是它自己定义了一个标准，然后完美达成了那个标准。

这不是 AI 蠢。这是需求没被写下来。

Spec 干的就是这件事：在让 AI 动手之前，先让人类自己把「做完」这件事定义清楚。

它不让 AI 变聪明，它让 AI 变可控。

这套方法的代价：安全的部分和危险的部分

5 天干完 20 人几周的活，听起来像神话。但代价那一栏也很长。

同一个行业里，有几个数字必须放在一起看：

数据

出处

45% 的 AI 生成代码含安全漏洞（无 Spec 约束前提下）

Veracode 2025

人工精炼 Spec 可减少 LLM 代码错误 50%

同源

代码重复率 4 年增长 4 倍

GitClear，2.11 亿行代码研究

Stripe 用 Harness 方法交付 1300 个 AI PR，未引发系统性问题

公开案例

这几个数字放一起，讲的是同一件事：

AI 写代码的量是指数级涨的，但「验证」这件事还停留在原来的节奏上。

于是就出现了 AI 编程最典型的死法——业内有个说法叫「三个月墙」：

• 第 1-3 个月：很兴奋，什么都能做
• 第 4-9 个月：开始卡住，「为什么新功能总是破坏旧功能？」
• 第 10-15 个月：彻底崩，「这坨代码没人能维护了，不如重写」

GitClear 那个「重复率涨 4 倍」的数据，就是这面墙的物理证据。

代码在膨胀，但结构在腐烂。

关键不在模型，在脚手架

那问题来了：怎么越过这面墙？

有个腾讯的工程师给了一个我觉得最实在的判断——

脚手架 > 模型。

他的对比是这样的：

动作

成本

效果

模型升级

+300%

+20%

脚手架升级

+50%

+200%

（作者标注为个人经验估算，不是通用结论，但方向可信）

什么是脚手架？就是那些围着模型转的东西——规则文件、检查脚本、流程、测试基线。

同一套逻辑下，AI 编程的瓶颈不在于「AI 有多聪明」，而在于「你有没有给它搭好发挥的舞台」。

有句话被反复引用，我很喜欢：

AI 编程的瓶颈从来不在 AI 有多聪明，而在我有没有给它搭好发挥的舞台。好马需要好鞍。规则是缰绳，验证是刹车，Agent 体系是分工。

一个反常识的细节：规则不是越多越好

有份实践记录里有个数字，我第一次看到的时候愣了一下。

一个团队优化 AI 规范之后：

always-applied 规则从 14 条降到 4 条，总行数从 1010 行砍到 275 行。

规则变少了，效果反而变好了。

原因是这样的：对话一长，最早塞进去的那批规则就慢慢被挤出模型的注意力范围了。

作者说得很准：

这不是 AI 的 bug，Transformer 架构在长上下文下就是这个特性。

所以他们的做法是把一部分规则从「写在文档里」改成「写成脚本去扫」。

以前 Rule 是「告诉 AI 不要犯错」，本质是预防，但预防会失效。现在 Script 是「犯了错我一定能抓到」，本质是兜底。

这个思路，我觉得可以推广到所有 AI 使用场景，不只是写代码。

你反复叮嘱 AI 的每一条，它都会忘。你反复检查的那几件事，它不该负责。

结尾：我觉得最该带走的一句

这5 个人 7 天干掉的不是 20 人几周的活。

他们干掉的是「需求没说清 → AI 猜一个意思 → 人返工 → 再猜」这个循环。

这个循环每天都在每个人的项目里跑，只是没人统计过它消耗了多少人力。

所以如果你也在用 AI 干活，我建议只改一件事：

下一次，别急着让 AI 动手，先花 20 分钟，把「这件事做到什么程度算做对」写成三行字。

不是写文档，是写三行字。

第三行写完你大概率会发现：原来你自己也没想清楚第二行。

这20 分钟，可能比你后面所有的返工都值。

这是「数字生命岐伯」第 6 问。我，野慢，广东，25岁。白天在大厂做AI产品，晚上被AI教做人。今天这题我替你们问过了，坑也替你们踩了。想让我测哪个AI，评论区点单。我们，下篇见