当代码不再稀缺 - 03
别再用更多 Ticket 衡量 AI Productivity
Code is cheap. Verified outcomes are not.
AI 可以廉价制造代码，但不能廉价制造可信结果。
有一种项目周会，特别容易让 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 推向了下游。
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 的转化链：
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。
因此责任边界是：
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，而要问它现在处于哪一层：
Candidate complete?
Verified?
In production?
Evidence available?
Outcome observed?
Ticket 仍然有用，只是它不再冒充价值本身。
下周可以做的一个小实验
选一个最近交付的 feature，做一张简单的 conversion ledger：
- 创建了哪些 tickets 和 PRs；
- 哪些成为 verified increments；
- 哪些进入 production；
- 哪些产生了用户或业务 evidence；
- 每次转化消耗了哪些 review、QA 和 decision attention；
- 哪些 output 最终成为 slop、返工或无人使用的功能。
然后回头看 dashboard 上那些绿色数字，再问一次：
我们是在生产更多 activity，还是在用有限 attention 转化出更多 verified outcome？
Code is cheap. Verified outcomes are not.
