当代码不再稀缺 - 01

AI 几乎写完了代码，项目为什么只从六个月缩短到四个月？

AI can generate code. It cannot own the outcome.

AI 可以生成代码，但它不会替团队对结果负责。

下一篇：AI 没有消灭瓶颈：Slop 正在吞掉团队的注意力

我们最近做了一个床位管理项目。

按照过去的开发方式，团队估计大概需要六个月。这一次，AI 几乎取代了人工代码输出，项目最后用了四个月。

四个月当然比六个月好。我也很高兴。

但这个结果有点别扭：写代码这件事几乎都被 AI 接管了，整个项目为什么没有出现同样幅度的压缩？剩下的时间去哪儿了？

项目结束后回头看，我们确认了几件事：

• Implementation 明显变快；
• Code review 的绝对耗时增加；
• QA 的绝对耗时增加；
• 团队投入了更多验证工作；
• 最终返工和缺陷反而减少。

这些事实不支持“AI 只帮我们省了两个月”这种简单结论。更准确的说法是，项目成本换了位置。

过去，很多时间花在生产代码。现在，更多时间和注意力花在理解候选实现、恢复缺失的 context、验证业务行为，以及确认我们是否敢把它交给客户。

Coding speed 和 delivery speed，开始明显脱钩。

AI 加速的是 Candidate，不是 Outcome

过去一个 engineer 做功能，通常会边理解、边实现、边修改。这个过程慢，有时慢得挺烦，但业务上下文、技术选择和代码是一起长出来的。

现在流程变了。

Engineer 可以把任务交给 AI，很快拿到 API、页面、migration 和 tests。Candidate implementation 出现得比以前早得多。

可“代码已经生成”只说明系统里多了一个候选答案。它还没有回答几件更麻烦的事：

• 它理解的是不是正确的问题；
• 它依赖了哪些未写出的假设；
• 它是否符合已有 architecture 和 abstraction；
• Tests 验证的是 implementation，还是业务行为；
• 上线后凭什么相信它真的有效。

AI 把写答案的时间压缩了，没有自动补齐这些问题。

这也是六个月没有直接变成一个更夸张数字的原因。项目需要的从来不只是代码。

一行逻辑没错，整个业务错了

床位系统里有一个很典型的 bug。

这个系统只以“天”为单位追踪床位占用。团队约定所有床位在当天 UTC 12:00:00 PM check-in，在次日 UTC 11:59:59 AM check-out。

这不是普通的 implementation detail。它定义了系统里的“业务日”，是床位占用模型成立的 business invariant。

Engineer 没有把这个假设完整交给 AI。AI 根据自己拿到的 context，生成了一个局部上很合理的实现：使用查询发生的绝对时间，判断当前时刻是否落在预约区间内。

问题出现在 UTC 中午 12 点之前。

客户查询一个当天已经被预约的床位时，那段预约在绝对时间上还“没有开始”。API 因此返回：床位没有被预约。

从代码看，时间区间判断没有明显问题。业务真正问的是：

这一天是否已经被占用？

代码回答的是：

当前这一秒是否落在预约区间？

AI 很认真地回答了错误的问题。更尴尬的是，我们也很认真地 review 了这个错误答案。

这个 bug 没有在 code review 中暴露，也没有被 QA 覆盖，最后由客户反馈发现。

这不是一个“AI 写了烂代码”的故事

把这个 bug 全部甩给 AI 很容易，但是不诚实。人类 engineer 一样可能遗漏时间边界。

这里真正缺失的是 intent 对其。

Business-day invariant 只存在于人的脑子里。它没有进入 AI 的 context，没有变成 executable test，也没有成为 review 和 QA 明确检查的对象。

AI 得到的问题不完整，生成的答案却足够 plausible。代码能跑，局部逻辑也说得通，所以它顺利进入了后续流程。

这类问题麻烦的地方，不是代码看起来很差，恰恰是它看起来还不错。

AI 不需要先理解整个业务，才能写出局部可用的实现。团队则必须在之后投入高质量 attention，判断这个实现是不是值得相信。

如果没有明确的 intent 和 verification evidence，AI 加速的就不只是正确实现，也包括未经验证的假设。

Intent 不是在某一个环节突然丢失的

我举的例子故事很容易给人一个印象：engineer 忘了把 business-day invariant 告诉 AI，所以 AI 写错了。

这还不够完整。

真实的信息链可能更长：

原始业务问题
→ PM 理解
→ PM / AI 润色后的 ticket
→ Engineer 解释 ticket
→ Agent 根据 context 生成代码和 tests
→ Engineer / reviewer 检查结果
→ Production behavior

每一步都可能丢掉一点东西，也可能凭空补上一点“看起来合理”的内容。

PM 使用 AI 润色 ticket 本身不是问题。AI 可以把表达变清楚。风险在于润色后的文本常常没有 provenance：哪些是客户原话，哪些是 PM 的判断，哪些 acceptance criteria 是模型补出来的，后面的 engineer 和 agent 看不出来。

Tests 也不天然是独立证据。如果 code 和 tests 都由同一个 agent 根据同一份失真的 ticket 生成，tests passing 只能说明代码和测试彼此一致，不能证明它们与原始业务 intent 一致。

多加几个 AI reviewer 可能提高发现问题的概率，但也不能自动解决这个问题。独立、互补的判断可以减少随机误差；如果所有 agent 都共享同一份错误 context，它们也可能非常一致地得出同一个错误答案。

所以这套论证不能建立在“engineer 不会理解和验证自己实现的东西”这个前提上。恰恰相反：

谁接受并提交一个 PR，谁就必须对它与业务 intent 的对齐和 verification evidence 负责。

如果 engineer 只是把 ticket 转给 agent，再看一眼 agent 根据同一 ticket 生成的 tests，他与一个自动创建 PR 的 agent 没有拉开多少差距。

AI-native engineer 的价值不再只是亲手写代码，而是充当 accountable aggregator：恢复原始 context、质疑输入中的 assumptions、判断不同 verification signal 是否独立，并对接受的 change 负责。

Human-in-the-loop 不是因为 human 永远正确。人类也会漏掉 invariant。Human 必须留在 loop 里，是因为系统需要一个有 domain context、决策权和责任归属的 owner，而不是因为 manager 有时间替所有人 review。

省下来的时间，变成了 Attention Demand

AI 以前所未有的速度生产 candidate，但团队每天可用的高质量 attention 没有同步增加。

这里说的 attention，不是坐在电脑前的工时。它是 reviewer 理解 system fit、QA 推演业务状态、domain expert 恢复历史 context、EM 判断风险和发布条件时真正消耗的认知资源。

这种资源有几个特点：

• 每个人每天都有限；
• 被打断后需要重新加载 context；
• 依赖 domain knowledge，不能随便找一个“有空的人”替代；
• 用在低价值 output 上，就无法同时用在高风险判断上。

当 Generation capacity 上升，更多 candidate 同时进入系统。里面既有高价值实现，也可能有重复代码、缺少抽象的 PR、只覆盖 happy path 的 tests，以及其他看起来完成、却缺少 evidence 的 AI slop。

它们都会竞争同一份 human attention。

更多 candidate output
→ 更多理解和验证需求
→ Review / QA queue 增长
→ Context switching 增加
→ Feedback 变慢
→ Delivery speed 不再跟随 coding speed

在我们的项目里，团队确实增加了 review 和 QA 投入，最后的返工与缺陷才会下降。但这不应该被理解成在原有 implementation budget 上继续加人、加时间。

AI 已经减少了亲手实现代码所需的 allocation。合理的 operating model 是把其中一部分释放出来的 engineering capacity 转移到 context recovery、verification 和 evidence，而不是一边保留过去的 implementation allocation，一边再叠加一套昂贵审核流程。

问题在于，这个转换不是免费的。Engineer 需要学习怎样监督 agent、识别 shared assumptions、设计 independent evidence；PM 需要保留 context provenance；团队需要建立新的 tests、gates、ownership 和绩效预期。在 transition 期间，人和 AI 甚至会暂时重复工作，短期收益因此低于 generation benchmark 看起来那么漂亮。

Implementation allocation 下降
→ 支付 transition cost
→ Freed capacity 转向 Intent、Verification 和 Evidence
→ 才可能形成净 delivery gain

如果 freed capacity 只是让 engineer 同时启动更多 feature，系统得到的不会是转型，而是更多 candidate、WIP 和 queue。

这仍然不能证明 AI 代码天然比人类代码更危险。它支持的是一个更有限、也更有用的判断：如果团队只提高 generation speed，却没有把 implementation savings 转成新的 ownership 和 verification capacity，更多 candidate 很可能只会转化成更多风险和 attention demand。

软件交付需要四个环节

这个项目之后，我开始用一条更完整的 lifecycle 看 AI delivery：

Intent → Generation → Verification → Evidence

Intent

团队到底要改变什么？

这里包括用户问题、业务规则、acceptance criteria、system constraints 和 invariants。

床位 bug 首先断在这里。业务日的定义没有被显式表达。

Generation

AI 根据 context、prompt、tool 和 repository 生成 candidate implementation。

这是目前被压缩得最明显的部分，也是最容易被 dashboard 看见的部分。

Verification

团队凭什么相信 candidate 是正确的？

Tests、code review、QA、安全检查和 system reasoning 都属于这一层。它们不是给 AI 擦屁股，而是在把候选答案变成团队愿意承担责任的 change。

Evidence

Change 上线后，什么证据说明它真的有效？

Production behavior、用户反馈、escaped defects、performance 和业务结果，才是软件最终面对的现实。

床位 bug 也是在这一层被客户 evidence 打回来的。只不过这个反馈来得太晚，成本也更高。

EM 最容易做错的，是继续增加 Output

看到 coding 变快，一个很自然的管理动作是提高 output target：更多 ticket、更多 PR、更多 feature。

这会让 dashboard 很快变漂亮。它也可能让 delivery system 更堵。

如果每个新增 candidate 都需要人理解和验证，继续增加上游 output，相当于持续给一个已经拥堵的下游加工作。

另一种反应是增加 reviewer 和 QA。这有时确实需要，但它仍然没有解决根本问题：哪些 candidate 值得消耗人类 attention？哪些检查应该自动完成？哪些 high-risk change 需要 domain expert？哪些工作根本不该进入 review？

这些问题会在后面的章节展开。第一步只是承认，代码产出已经不能代表项目进度，更不能代表项目价值。

这个案例能证明什么，不能证明什么

一个项目不能证明 AI 软件开发的普遍规律。

它不能证明：

• 所有项目使用 AI 后都会得到相同的周期变化；
• AI 一定比人类制造更多 bug；
• Code review 和 QA 永远是下一个瓶颈；
• 所有 AI-generated code 都是 slop；
• 只要投入更多 verification，项目就一定成功。

它支持的判断更窄：

当代码生成速度超过团队理解和验证候选实现的速度，coding acceleration 不会自动转化成 delivery acceleration。

这条判断已经足够改变 EM 的工作重点。

EM 应该开始问另一个问题

过去我们经常问：

这个功能需要几个 engineer，多久能写完？

AI 时代还需要再问：

团队需要投入什么 attention、verification 和 evidence，才能对这个 change 负责？

这意味着项目管理不能只追踪 ticket、PR 和 implementation status，还要看：

• Intent 和 invariants 是否显式；
• Candidate 在哪里等待 review 或 QA；
• 稀缺 attention 被什么工作占用；
• Verification 是否覆盖真正的业务行为；
• 从 intent 到 production evidence 的端到端时间；
• 哪些 escaped defect 暴露了 context 缺口。

AI 几乎写完代码，并不意味着项目会按同样比例缩短。它加速了 Generation，同时把更多压力暴露在 Intent、Verification 和 Evidence。

当代码不再稀缺，EM 要管理的是团队如何把有限 attention 转化成 verified outcome。

下周可以做的一个小实验

找一个最近完成的 feature，按照四个环节重新画一遍：

Intent → Generation → Verification → Evidence

然后记录：

1. Candidate implementation 多久出现；
2. 工作在哪些环节等待；
3. 哪些活动消耗了高质量 attention；
4. 哪些 assumptions 直到 review、QA 或 production 才暴露；
5. 最终有什么 evidence 证明它解决了原来的问题。

先不要急着给团队增加新的 AI productivity target。

先看清楚代码生成之后，真正稀缺的东西是什么。

When generation becomes abundant, attention is all we have.