认知到底花在了哪

用 AI 写代码越久，我越有一个挥之不去的疑问：怎么知道一个人，还在动脑子。代码是 AI 写的，方案是 AI 提的，review 是 AI 过的，每个人看起来都在高效地产出，可人自己的判断力到底花在了哪里，越来越没人能说清。而我们手里那堆 AI 指标，从一开始就没打算回答这个问题。

#一个从没说破的前提

过去一年我们追的那堆 AI 指标，几乎全是按"越多越好"设计的——鼓励大家尽可能多地用 AI 替代手上的活，比如 AI 生成的代码占比，越高越好。这些目标单拎出来都挺美好，但它们共享一个从没被说破的前提：那个用 AI 的人，本身已经有判断力了。

可这个前提经常不成立。最明显的是刚入职的新人——判断力还没建立起来，你就让他贡献率越高越好、token 越多越好、生成占比越高越好，等于推着他往"人只 verify"的终点走。但 verify 本身就是一种判断，而判断只能靠亲自下场练出来。让一个还不会判断的人去 verify，他做得到的只有 approve。他以为自己在把关，其实在闭眼放行。

而且这不光是资历的问题。一个做了十年的工程师，空降到一个从没碰过的代码库、一个不熟的业务域，一样是从零开始。写代码的本事他不缺，缺的是这个环境里的历史决策、技术债、业务逻辑、协作方那些没说出口的做事风格——这些东西文档里没有，只有泡进去、自己动手才长得出来。而 verify 靠的正是这些。所以只要一个人还需要 onboarding，不管他原来多资深，都不该一步跨到 verify。

于是有意思的地方来了：那堆"越多越好"的指标，只要把前提从"人已经有判断力"换成"人正在建立判断力"，就得全部倒过来读。

#什么叫倒过来读

我们手里抓着的代码指标，其实就一个：AI 代码贡献率——合并进 master 的代码里，源自 AI 的占多大比例。倒过来读很简单，就是手写代码的比例，对应"断网练习"：看一个人没了 AI，还能不能自己写。

不过这个指标以前不是这么看的。过去我们会把它再往下拆一层，看里面那些 AI 代码是怎么产生的，大体两类：一类是补全，就是以前 Copilot 那种 tab 补全；一类是生成，直接用 agent 写代码。这两种方式代表两种行为模式，我们觉得生成比补全更好，因为它说明 AI 的贡献更深入，人已经退到只 verify 的位置。

现在倒过来看，这个拆法依然有价值，只是好坏翻了个个。补全占比高，说明人在主导——意图、结构、决策是你定的，AI 只填 token，这种认知参与正是判断力的来源。生成占比高，说明人退到了验证位，理解债在输入侧就欠下了。于是过去那句"贡献率越高越好、生成占比越高越好"，倒过来读就是手写越多越好、补全越多越好，三个点拼成一条谱系：手写 → 补全 → 生成。一个同学落在哪一格，基本能看出他处在什么阶段、用得对不对。

而补全和生成这个 split 最锋利，因为它直接测"谁在作者"——作者化正是判断力建立的地方。更妙的是，这个 split 不用去 git 里反推哪行是谁写的，补全和生成在创建那一刻就被记下来了：Copilot 的 usage metrics 里 code_completion 和 agent_edit 是两个 feature 类别，Cursor 的 Analytics API 干脆把 /tabs（补全）和 /agent-edits（生成）拆成两个端点，都能按人头导出。这把尺子不是想象出来的，它已经是一个产品功能。

#倒过来读，就是一道闸门

这张进度表看懂了，下一步就是把它变成一道闸门：新人 token 消耗量不该大，贡献率不该高，生成占比甚至要强制压低；等过了 onboarding、或者 leader 签字认可了，再放开。AI 用得少，在早期不是坏事，是在老老实实建立认知和判断力。

这里有个让我反复回味的性质：这个闸门很难被作弊。一个新人想把自己的补全占比刷上去，唯一的办法是拒绝生成、自己动手写代码——而这恰好就是闸门想逼他做的事。作弊这个指标的方式，就是完成它想逼的训练。大部分指标一被 gaming 就失效，这个指标反过来，被 gaming 就等于被满足。这也是为什么"补全 vs 生成"特别值得当闸门，而不是当一个看看就好的数字。

不过这个闸门有个现实的尴尬。补全 vs 生成这个指标漂亮是漂亮，可大家现在已经习惯用 Claude Code、Codex 这类 agent 直接生成代码了，还在用 Copilot、Cursor 那种 tab 补全的人越来越少。真把它当闸门，就得逼着大家退回补全式的编辑器，这又没法复用现成的 harness 基建。所以落地的时候，可能还是得另找其他替代指标。

#token 消耗量大，究竟是好是坏

每个团队里好像都有这么一个人：token 消耗量巨大，一个人顶十个人。我一直很好奇这是怎么做到的。同时我也一直隐约觉得，token 消耗量不是越大越好。这两件事，我花了很久才意识到其实是同一件事。

先说我为什么怀疑"越大越好"。人用 AI 干活，认知投入是在两端的：上游你得想清楚要什么、标准是什么；下游你得确认出来的东西对不对、再把结果消化成自己的理解。中间的执行可以外包给 AI。既然两端还都压在人的身上，而人的注意力、判断力有生理上限，那 token 消耗量理论上就该有个天花板。一个编辑一天能认真看透的稿子是有限的，一个投资人一年能认真尽调的项目是有限的。真出现一个 token 消耗抵十个同事的人，我第一反应是，他把某一端省掉了——上游没想清楚就随手出 prompt，或者下游没验证就拿了直接用。

我管这种状态叫 surrender mode，投降模式。它跟 augmentation，增强模式，正好相反。增强模式里 AI 放大你本来就在做的事；投降模式里你期待 AI 凭空产出价值，把自己本该投入的那份认知劳动也外包了出去。所以 token 消耗量与其说是能力指标，不如说是认知投入指标：太多让我警惕，太少也未必好，可能压根没用，也可能还在老老实实积累。

但同样的数字，也能讲一个相反的故事。一个人 token 消耗量远超同事，也可能恰恰是因为技高一筹——他把判断收拢成了可复用的东西：一份写透的 spec、一个沉淀好的 skill、一条反复打磨的 workflow、一个能自己跑起来的 loop。判断没有消失，只是从散在每个任务里的即兴思考，搬进了标准里，于是每单位判断撬动了成倍的执行。这样的 token 高，靠的是放大杠杆——他可能真的一个人顶十个人。

这件事业界已经吵过一架了。Meta 内部一度有个按 token 消耗量给员工排名的 leaderboard，据报覆盖八万五千人，第一名一个月烧掉 2810 亿 token。这东西被挖出来后招来一片骂声，大家给它起了个名字叫 tokenmaxxing——token 版的"代码行数"，量的是活动，不是价值。Jellyfish 拿七千多个工程师做统计，token 消耗前 20% 的人，PR 产出是后 20% 的两倍，但 token 成本是十倍；Faros AI 追了两万两千个开发者，任务量涨了 34%，bug 跟着涨了 54%，review 时间变成五倍。业界的结论基本收敛到一句：把 token 消耗当"越多越好"的 KPI，就会被人 gaming。

绕到最后，我得承认这个问题我回答不了。投降和技高一筹，一个省掉了判断，一个放大了判断，可在 token 这个数字上，它们长得一模一样，单看数字分不开。所以不该继续纠结这个指标：它确实能反映一些事情，但给不出结论。它是指路牌，不是判决书。

#那就不看输出，看你的输入

绕开 token 之后，我想换个更根本的问法：这个人的认知，到底花在了哪里。

前文那个 AI 代码贡献率，其实已经藏着答案的一半。AI 贡献越多，人贡献就越少；倒过来看，AI 贡献越少的地方，人贡献就越多，认知投入就越重。于是最直接的想法是：把一件工作拆开，度量每一块各自的 AI 贡献率，然后倒过来读，哪块贡献率低，哪块就是这个人真正动脑子的地方。

但这个想法卡在一个现实上：代码是一种很特殊的输出，相对标准、边界清晰，所以 AI 贡献率才量得出来。你很难统计一篇文档里，哪些是 AI 写的，哪些是人写的。开会讨论、跟人沟通，更是连"输出"都散落在对话里，无从下尺。用 AI 贡献率倒推认知，只在代码这一种产物上成立，换到别的工种就不成立了。

于是我退了一步，先不度量 AI 的输出，改去度量人的输出——毕竟人的输出才是认知投入的直接体现。可这条路也走不通：人的输出不是 100% 都能被统计到，你跟别人聊的那一小时，就是输出，可它留不下痕迹。

再退一步，落到一个能抓住的东西上：人的输出里，那些给了 AI 当输入的部分。说人话就是，统计你主动跟 agent 说的话。注意，这里要划一条线——统计的不是 prompt，因为 prompt 里可能被注入了大量被动塞进去的内容，比如整份文档、整段报错日志；要统计的，是你亲自写下的那部分，那才是你的认知留下的字据。

这个指标有意思的地方在于，它绕开了前面所有的死结。它是人写出来的东西，有生理上限，不会像 AI 输出那样无限膨胀，review 得过来——说不定将来会冒出一种 "prompt review"，就像现在的 code review 一样。它也比"贡献率"更接近认知本身：你在 agent 面前主动写下什么，你的注意力大概就落在了什么上。

#我现在还没搞明白的一些事

"人的输出、AI 的输入"到底该叫什么、该用哪些指标去量，我还没想清楚。最容易抓的是量——一个人写了多少字、喂进去多少 token。但量和前文那个 token 消耗撞的是同一堵墙：量大可能是精心准备的约束，也可能是塞了一大坨上下文让 AI 自己琢磨，单看数字分不开。频率也一样，高频可能是反复验证，也可能是同一个没想清楚的要求重试了几十遍。真正有区分力的，是这些输入在干什么——下约束、验证、探索、还是执行——但这需要对内容做语义分类，不是 telemetry 直接吐得出来的。也许这里藏着一些能用的东西，等以后有想法了再说。

以及一个反证：如果一个团队真的按这个闸门跑了一年，那些刚进入新环境的人（不一定是 junior）的判断力到底有没有比放开 AI 的对照组长得更快？这是整个框架最该被验证、也最难被验证的地方，因为 onboarding 结束后的独立 review 表现，本身又是个不好量化的东西。

#参考文献

• GitHub (2026). Copilot usage metrics. 官方文档。usage metrics 的 feature 维度区分 code_completion 与 agent_edit 等 token 类别；code generation dashboard 报 "Agent contribution"（agent 增删行数占比）。
• Cursor (2026). Analytics API. 官方文档。/analytics/team/tabs（补全）与 /analytics/team/agent-edits（生成）两个端点，可按用户过滤，均属企业版。
• Faros AI (2026). Tokenmaxxing: Why AI token consumption isn't engineering productivity. 博客。追踪 22,000 名开发者：任务量 +34% 但 bug +54%、review 时间 5 倍；把 token 消耗当生产力指标是"代码行数"错误的翻版。
• Jellyfish (2026). AI Coding Productivity Study. Q1 2026 对 7,548 名工程师的研究：token 消耗前 20% 的人 PR 产出是后 20% 的 2 倍，但 token 成本是 10 倍。
• Meta (2026). 内部 token 消耗 leaderboard（经 LeadDev、PeopleManagingPeople 等媒体 2026 年报道）。按 token 消耗给约 85,000 名员工排名，最高者单月消耗 2810 亿 token，被批评为 vanity metric。