当代码不再稀缺 - 04

AI 时代还需要 Estimate 吗？

Don't estimate how long it takes to generate code. Estimate what it takes to trust the change.

不要只估算生成代码需要多久，要估算团队需要付出什么，才能相信这个 change。

上一篇：别再用更多 Ticket 衡量 AI Productivity

如果现在有人问 engineer：“这个 ticket 要多久？”答案可能越来越像这样：

“代码今天能出来。至于什么时候敢上线，我不知道。”

这不是 engineer 在打太极，而是“多久”这个问题里，本来就混着好几个不同的问题。

AI 让其中一个答案突然变得很短，于是我们终于看见其他问题一直都在那里。

一个 Estimate，其实混合了三个时钟

过去做项目，我们经常把一个 ticket 估成三天、五天或者几个 story points。

这个数字看起来是在估算 coding effort，实际上偷偷打包了至少三件事：

多久能写出一个实现；
多久能确认它是对的；
多久能通过 review、QA、dependency 和 release；

Coding 足够慢的时候，这三个时钟经常被 implementation 遮住。反正代码还没写完，review、QA 和 release 都不用着急。

AI 把第一个时钟压缩以后，剩下两个时钟就集体站到了台前。

所以 AI 没有让 estimation 失效。它只是让我们过去最常用的 proxy——coding effort——变得更不可靠了。

第一个时钟：Candidate Time

Candidate time 是从 intent 到获得一个 plausible implementation 的时间。

这是 AI 最容易压缩的部分。API、页面、migration、tests，很多时候都能很快生成。Engineer 甚至可以同时让几个 agent 尝试不同方案。

但 candidate 只是“一个看起来可行的答案”，不是 verified outcome。

如果我们把“AI 已经把代码写出来了”当作百分之八十完成，后面往往就会体验那种熟悉的项目管理惊喜：剩下百分之二十又做了很久。

不是最后一点工作特别神秘，而是我们一开始只估了 generation，没有估 confidence。

第二个时钟：Confidence Time

Confidence time 是团队获得足够 evidence、愿意相信这个 change 正确所需要的时间和 attention。

它包括：

Reviewer 理解 intent 和 system fit；
Tests / evals 验证业务行为；
QA 覆盖 corner cases；
Security 和 performance 检查；
验证 business invariants；
准备 failure recovery。

这里可以继续用床位管理的例子。

“判断某一天床位是否被预约”，从代码上看像一个简单的时间区间查询。AI 很快就能生成一个合理实现。

但系统真正使用的是“业务日”：当天 UTC 12:00:00 PM check-in，次日 UTC 11:59:59 AM check-out。查询“某一天是否被占用”，和查询“当前这一秒是否落在预约区间”，是两个不同的问题。

Implementation 很小，背后的 invariant、时间边界和验证 permutations 却不小。

如果只估 coding，这可能是一个 tiny ticket；如果估 confidence，它需要 domain context、边界测试和真正理解业务语义的 reviewer attention。

这正是 AI 时代 estimation 最大的变化：

实现大小不再稳定地代表验证难度。

第三个时钟：Delivery Time

就算 candidate 已经生成、tests 也通过，change 还不一定能立刻进入 production。

它可能还在等待：

另一个团队的 dependency；
Reviewer attention；
QA 环境；
Security approval；
Data migration；
Release window；
Rollout 和 rollback 准备。

这些 queue 不会因为 AI 写代码更快就自动消失。相反，如果 generation capacity 上升，大量 candidate 同时进入下游，等待时间还可能增加。

所以“多快能写完”和“什么时候能交付”必须成为两个不同的 forecast。

前者主要看 generation；后者看整个 delivery system。

这也是第四章停止计时的边界。Engineer 的 estimation 到 change 获得足够 confidence、能够安全进入 production 为止。上线后的 operational acceptance 和 user / business outcome 由 PM / Ops 主责，不再作为第四个工程时钟。

但 Eng 不能因此退出 outcome loop。Confidence Time 仍应包括建立 instrumentation、dashboard、logs、data-quality checks 和 diagnostic path，使 PM / Ops 上线后能够基于可信 evidence 做判断。Eng 负责让结果可验证；PM / Ops 负责解释结果并决定是否达成业务目标。

不要停止 Estimate，要改变估算对象

AI 时代真正应该减少的，不是 estimation，而是对 coding effort 的过度依赖。

与其先问“几天能写完”，不如先判断五个维度。

1. Intent clarity

业务问题是否清楚；
Acceptance evidence 是否定义；
Invariants 是否显式；
是否存在多个合理解释。

Intent 越模糊，AI 越可能快速生产 slop，然后把澄清成本推给 reviewer 和 QA。

2. Change surface

影响多少模块、服务和数据；
是否修改公共 abstraction；
是否有 migration 或兼容性问题；
是否会制造重复实现。

代码 diff 很小，也可能跨过一个高风险系统边界。

3. State space

涉及多少业务状态；
是否存在权限、并发和时间边界；
Happy path 是否足够代表真实行为；
哪些 permutations 必须被验证。

4. Reversibility 和 blast radius

出错后能否快速 rollback；
Failure 是否容易被发现；
是否影响账务、权限、数据完整性或核心业务；
Recovery cost 是什么。

5. Evidence cost

什么证据才足以发布；
哪些验证可以自动化；
哪些需要稀缺 domain expertise；
哪些 evidence 必须在 release 前建立。

这些维度比“AI 写这段代码要多久”更能解释项目为什么延迟，也更适合用来判断 forecast range 和 confidence。

Estimate Net Allocation，不要只做成本加法

很多 AI business case 会先保留过去的 implementation estimate，再在后面新增更多 review、QA 和 governance。这样算出来，AI 当然像一个又贵又麻烦的实习生。

更合理的 forecast 应该拆开四类 allocation：

Remaining implementation allocation
+ Transition cost
+ Confidence / verification forecast
+ Delivery constraints

第一项应该随着 AI 替代 implementation work 而下降；第二项在转型期暂时上升；第三项吸收一部分 freed engineering capacity；第四项反映 queue、dependency 和 release reality。

EM 在 estimation 时不能只问“还要增加多少 verification”，还要问：

哪些 implementation effort 已经被 agent 可靠替代；
哪些 freed capacity 可以在当前阶段真正转成 verification expertise；
团队还要支付多久的 learning、workflow 和 double-work transition cost；
哪些旧 allocation 或 output expectation 应该从 forecast 中移除。

这避免把同一份 capacity 计算两次，也解释了为什么转型初期的总周期未必立刻按 generation benchmark 缩短。

Risk 用来校准 Forecast，不用来设计 Attention Routing

说到这里，很容易出现一个危险冲动：既然 story point 不够用了，那我们发明 attention point 吧。

然后开一场 planning meeting，认真讨论这个 ticket 是三个 attention points 还是五个。兜兜转转，又回到了熟悉的 framework theater。

Attention 很难被压成一个可比较的数字。一个 domain expert 连续半小时的判断，可能比一个不熟悉系统的人读一天代码更有价值；一次被打断十次的 review，也不等于一段连续的 deep focus。

第四章不解决“有限 attention 应该分配给谁”，那是上一篇的 attention allocation 问题。Estimation 在这里要回答的是：attention、expertise 和 verification burden 会怎样影响 forecast。

Risk 和 uncertainty 应该改变四件事：

Range： 未知越多，delivery range 越宽；
Confidence： 关键 assumption 尚未验证时，不能给出高 confidence commitment；
Learning step： 可以先用 spike 或早期 candidate 消除最影响 forecast 的未知；
Checkpoint： 明确何时更新 estimate，以及什么变化会让原 forecast 失效。

低 uncertainty、可逆且有历史数据的 change，可以给更窄的 range。Domain 语义不清、dependency 未确认或 recovery cost 很高的 change，需要更宽的 range 和更早的 checkpoint。

Risk 在这一章是 forecast input，不是 workflow routing rule。

EM 应该怎样问 Estimate

过去的问题是：

这个 ticket 几天能写完？

新的 estimation conversation 应该包含：

多快能得到 candidate？
最大 uncertainty 是什么？
什么 evidence 才足以相信它？
Verification 依赖哪些稀缺 expertise 和 capacity？
哪些 queue、dependency 和 release constraint 决定 delivery time？
如果判断错了，blast radius 和 recovery cost 是什么？

这不是为了让 planning meeting 变得更长。对 uncertainty 低、历史数据充分的 change，团队可以快速形成 forecast。真正需要先做 spike 或设置早期 checkpoint 的，是那些“代码看起来很简单，但未知很多”的 change。

管理层还是需要一个日期

最强的反对意见通常很现实：讲了这么多 confidence、risk 和 evidence，老板最后还是会问，哪天上线？

合理。项目管理不能只输出哲学思考。

但一个负责任的日期，不应该只来自 coding effort。它应该来自：

团队历史 flow；
当前 queue 和 WIP；
External dependencies；
Verification burden 和 required expertise；
Risk 和 reversibility；
尚未解决的 uncertainty。

比起给一个看起来精确的单点日期，更诚实的方式是给出：

一个 range；
当前 confidence；
关键 assumptions；
下一次 checkpoint；
什么变化会让 forecast 失效。

如果最大的 uncertainty 还没有被验证，可以先做一个短 spike，让 AI 快速生成 candidate、暴露未知，再更新 forecast。

AI 的价值不只是让 delivery 更快，也可以让 learning 更早发生。

这其实也不是一个新理论

一个资深 EM 可能会说：Estimation 本来就应该包含 uncertainty、risk 和 dependency。你只是把正常的项目管理重新说了一遍。

这个反对意见也是对的。

原则没有变。变化的是过去很多团队可以偷懒地把 coding effort 当作整体复杂度的 proxy，因为 implementation 本身占据了足够大的成本。

AI 让这个 proxy 更快失效了。

今天，一个 change 可以在几分钟内生成，却需要几天理解、验证和排队；另一个 change 代码很多，却高度可逆、automated evidence 完整，可以快速进入 production。

当 generation cost 和 confidence cost 开始脱钩，继续只估 coding effort，就不再是简化，而是误导。

下周可以做的一个小实验

选择一个即将开始的 feature，不要先给一个总 story point。

分别记录：

Candidate time forecast；
Confidence plan 和 required attention；
Delivery constraints 与 queue；
最大 uncertainty；
Reconsider / checkpoint 条件。

交付后再看，真正造成 forecast 偏差的是哪个时钟。

你可能会发现，AI 对 estimation 最大的帮助，不是让 estimate 更准，而是让 candidate 更早出现，让团队更早知道自己原来不知道什么。

不要只估算代码什么时候生成。估算团队什么时候有理由相信它。