> ## 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.

# 当代码不再稀缺 - 03
- URL: https://andybase.com/dang-dai-ma-bu-zai-xi-que-03/
- Published: 2026-07-25T23:40:51.000Z
- Updated: 2026-07-26T16:12:00.000Z
- Author: andy

## 别再用更多 Ticket 衡量 AI Productivity

> **Code is cheap. Verified outcomes are not.**  
>  
> AI 可以廉价制造代码，但不能廉价制造可信结果。

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

下一篇：[AI 时代还需要 Estimate 吗？](https://andybase.com/dang-dai-ma-bu-zai-xi-que-04/)

有一种项目周会，特别容易让 EM 心情愉快。

这个 sprint 完成的 ticket 比以前多了，PR 数量涨了，commit 也很活跃。自从团队开始用 AI，dashboard 上的每一条线都在往右上角走。管理层一看：不错，AI productivity 已经兑现了。

然后 reviewer 默默打开 GitHub，面对一面 PR 墙；QA 还在等上一批功能修完；客户则继续等那个真正能解决问题的版本。

每个人都很忙，数字也很好看，只有价值还堵在路上。

并不是说ticket、PR 和 commit 没有用了。而是我们把“进入系统的工作”误认为了“走出系统的结果”。

## Ticket 为什么曾经看起来像 Productivity

传统软件项目里，写代码是一个相对昂贵的环节。

一个 engineer 在一个 sprint 里能完成的 implementation 有限。Ticket 被拆出来、认领、开发、关闭，通常意味着某个人确实投入了不少时间。所以 ticket completion 虽然从来不是完美指标，但与实际 effort 之间多少还有一点相关性。

久而久之，我们开始用它回答越来越多问题：

- 项目做了多少；
- 团队是不是更快；
- 谁的 output 更高；
- 这个 sprint 是否成功；
- AI 是否提高了 productivity。

一个 coordination tool，慢慢兼职成了 performance metric。

AI 进来以后，这个本来就不牢靠的 proxy 更快失效了。

## AI 让 Output 与 Outcome 进一步脱钩

AI 最直接的能力，是降低 code output 的生产成本。

一个模糊需求可以很快变成几个 ticket；一个 ticket 可以很快生成一组代码；一组代码可以很快形成 PR。只要我们愿意，dashboard 上几乎永远可以有更多进度变更。

但从上一篇开始，我们已经知道：

> **When generation becomes abundant, attention is all we have.**

每一份候选实现仍然需要 reviewer 理解它为什么存在、是否复用了正确抽象、有没有违反 system invariants。QA 仍然要确认 corner cases，EM 和 stakeholder 仍然要判断它是不是解决了正确的问题。

如果 AI 让 ticket completion 增加，却同时制造更多重复代码、更大的 review surface 和更多 verification work，那么这些 ticket 并没有自动成为 productivity。它们只是把更多 attention demand 推向了下游。

```text
Ticket completion 增加
→ Candidate output 增加
→ Review / QA attention demand 增加
→ Queue、WIP 和 context switching 增加
→ Verified outcome 没有同比增长

```

Dashboard 看到的是 output，系统承担的是 attention tax。

更麻烦的是，AI slop 也完全可以被统计成“完成的工作”。一个重复已有实现的 PR、一个只覆盖 happy path 的功能、一个最后没人使用的 feature，都可以贡献 ticket count。

Ticket 数量不会问它们有没有价值。它只负责数数。

## Ticket 是 Inventory，不是 Value

更准确的理解是：

> **Ticket 是 coordination unit 和 work inventory，不是 productivity unit。**

Ticket 很适合用来：

- 记录 intent 和 scope；
- 协调谁在推进什么；
- 表达 priority；
- 控制 WIP；
- 链接代码、verification evidence 和 production result。

但 ticket 被 close，只能说明某个定义好的动作已经结束，不能自动说明：

- 用户问题已经解决；
- 代码经过了足够验证；
- Production 行为符合预期；
- 团队没有制造新的维护成本；
- 这项工作值得消耗之前投入的 attention。

仓库里多了一个箱子，不代表客户已经收到了货。

## 最危险的不是指标不准，而是奖励太准

团队很聪明。你奖励什么，大家就会想办法生产什么。

如果 AI adoption 的成功标准是“每个人完成更多 ticket”，最合理的行为就会变成：

- 把工作拆得更碎；
- 启动更多容易完成的任务；
- 生成更多可见的 PR；
- 优先做容易展示的 output；
- 把 refactoring、删代码和减少 scope 放到以后。

因为删掉一千行冗余代码，很可能只对应一个 ticket；让 AI 新增五个功能，却可以贡献五个漂亮的 completion。尽管这五个功能每个都可能需要两千行代码，在 AI 的努力下，也就是几个小时的工作量，而且这几个小时中 engineer 可能只是在等待 AI 迭代输出。

最后团队可能真的完成了更多 ticket，输出了更多的代码，也真的变得更忙。可是导向的结果是系统更复杂，技术债更多，reviewer 更累，客户获得的价值没有同比增加。

这不是员工在 gaming system。很多时候，他们只是在理性响应管理层设计的 scoring rule。

所以不要把 candidate output 用作 productivity metric。它不仅测不准，还会主动改变团队行为。

## 从 Output Dashboard 到 Conversion Dashboard

不看 ticket 数，并不意味着项目管理从此只能靠感觉。

我们需要的是一条从 intent 到 outcome 的转化链：

```text
Intent
→ Ticket / Candidate Output
→ Verified Increment
→ Production Evidence
→ User / Business Outcome

```

### 第一层：Candidate Output

包括 ticket、PR、commit、LOC 和 AI-generated artifacts。

它们回答的问题是：

> 有多少工作进入了系统？

这是 workload 和潜在 attention demand，不是 productivity。

### 第二层：Verified Delivery

包括完成 verification 的功能增量、intent-to-verified lead time、PR queue age、review cycles、WIP 和 deployment。

它回答：

> 有多少候选工作真正通过了质量和风险门槛？

### 第三层：Production Evidence

包括 production behavior、escaped defects、rollback、hotfix、support signal 和真实运行数据。

它回答：

> 我们凭什么相信它在真实环境中工作？

### 第四层：User / Business Outcome

包括用户是否采用、行为是否改变、运营负担是否降低，以及最初的问题是否真的消失。

它回答：

> 这件事究竟值不值得做？

## Outcome 由 PM / Ops 判断，但 Evidence Infrastructure 由 Eng 负责

这里需要避免一个新的 ownership gap。

Production Evidence 和 User / Business Outcome 的 primary owner，确实不应该是 engineer。PM / Ops 更接近用户问题、运营流程和业务目标，应该负责判断功能是否值得保留、迭代或撤回。

但 PM / Ops 无法凭空验证结果。Engineer 仍然需要提供可信的 evidence infrastructure：

- 定义清楚、语义稳定的 events 和 metrics；
- 能区分 rollout cohort、feature version 和异常路径的 dashboard；
- 可以下钻到 logs、trace 和业务对象的 diagnostic path；
- 经过验证的数据完整性、时效性和口径；
- 必要的 feature flag、rollback 和 before / after comparison。

因此责任边界是：

```text
Eng：Functional Verification + Observability + Telemetry Correctness
PM / Ops：Operational Acceptance + Outcome Interpretation + Product Decision

```

Dashboard 不是 engineer 把责任转交给 PM / Ops 的终点。如果埋点本身错误、指标无法归因，PM / Ops 只会基于错误 evidence 作出更自信的错误判断。

四层之间还要持续问一个问题：

> 为了把工作推进到下一层，我们消耗了多少 human attention？

这就是 Attention Conversion Rate 的意义。不是要求 EM 给每个人安装一个 attention 计时器，而是帮助团队看见：哪些 output 需要大量 review 和返工，却几乎没有形成新的 evidence。

## 不要寻找另一个“KPI”

看到 ticket count 失效，一个常见反应是赶紧找一个新 KPI，比如 deployment frequency、lead time，或者 verified outcome 数量。

但任何单一指标一旦承担绩效压力，都会开始扭曲行为。

只看 deployment frequency，团队可能更频繁地发布低价值改动；只看 lead time，大家可能回避高风险工作；只看 defect，最安全的选择就是什么都不发布。

所以第三章并不是建议用 `verified outcome count` 替换 `ticket count`，然后继续做排行榜。

更合理的是一组互相制衡的指标：

| 观察对象               | 代表性问题         |
| ------------------ | ------------- |
| Candidate Output   | 有多少工作正在进入系统？  |
| Flow               | 工作在哪里等待？      |
| Attention          | 哪些活动消耗最多认知资源？ |
| Quality / Evidence | 我们凭什么相信它是正确的？ |
| Outcome            | 它是否解决了真实问题？   |

这些指标首先用于诊断系统，而不是评价个人。

## Outcome 很重要，但它也最难测量

一个资深 EM 可能会反驳：业务 outcome 往往几周甚至几个月后才出现，而且还受到市场、产品、政策、销售和运营等等诸多方面的影响。工程团队怎么可能只对 outcome 负责？

这个反对意见是对的。

因此不能从“只看 ticket”直接跳到“只看 revenue”。我们需要分层证据：

- 短期看 verified delivery；
- 中期看 production evidence 和用户采用；
- 长期看业务 outcome；
- 全程观察 attention cost 和 flow。

Outcome 难测，不代表 output 就突然变成了价值。我们不能因为正确的东西难测量，就只管理最容易数的东西。

## EM 应该怎么用 Ticket

保留 ticket，但降低它在 productivity 讨论中的地位。

在创建 ticket 时，不只写“要做什么”，还链接：

- 它对应什么 intent；
- 成功需要什么 evidence；
- 涉及哪些 invariants；
- 风险和 blast radius 是什么；
- 上线后在哪里观察结果。

在关闭 ticket 时，也不要只问代码有没有 merge，而要问它现在处于哪一层：

```text
Candidate complete?
Verified?
In production?
Evidence available?
Outcome observed?

```

Ticket 仍然有用，只是它不再冒充价值本身。

## 下周可以做的一个小实验

选一个最近交付的 feature，做一张简单的 conversion ledger：

1. 创建了哪些 tickets 和 PRs；
2. 哪些成为 verified increments；
3. 哪些进入 production；
4. 哪些产生了用户或业务 evidence；
5. 每次转化消耗了哪些 review、QA 和 decision attention；
6. 哪些 output 最终成为 slop、返工或无人使用的功能。

然后回头看 dashboard 上那些绿色数字，再问一次：

> 我们是在生产更多 activity，还是在用有限 attention 转化出更多 verified outcome？

**Code is cheap. Verified outcomes are not.**