> ## Content Index
> Fetch the complete content index at: https://andybase.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# 当代码不再稀缺 - 01
- URL: https://andybase.com/dang-dai-ma-bu-zai-xi-que-01/
- Published: 2026-07-24T04:24:19.000Z
- Updated: 2026-07-26T15:56:07.000Z
- Author: andy

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

> **AI can generate code. It cannot own the outcome.**  
>  
> AI 可以生成代码，但它不会替团队对结果负责。

下一篇：[AI 没有消灭瓶颈：Slop 正在吞掉团队的注意力](https://andybase.com/dang-dai-ma-bu-zai-xi-que-02/)

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

按照过去的开发方式，团队估计大概需要六个月。这一次，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 写错了。

这还不够完整。

真实的信息链可能更长：

```text
原始业务问题
→ 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。

```text
更多 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 看起来那么漂亮。

```text
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：

```text
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，按照四个环节重新画一遍：

```text
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.**