AI原生研发：超越Token消耗的迷思

许多企业发现，推动工程团队拥抱 AI 的首要举措，是将使用量转化为考核指标——设立内部排名、设定 Token 预算、将 AI 使用纳入绩效评估。Meta、Amazon、Microsoft、OpenAI 均被曝出类似的内部追踪手段。这种策略有了新称呼：Tokenmaxxing，即将 Token 消耗量本身视作生产力的代理指标。

2026 年，Amazon、Microsoft、Google、Meta 这四家公司的 Capex 总额预计在 6500 亿至 7000 亿美元之间，签署这笔巨额预算的高管必须向投资者展示 AI 采用率的数字。Token 用量是最容易量化呈现的数据——因此它便被频繁展示。Tokenmaxxing 并非几家公司的 HR 粗心大意，而是 Capex 周期下几乎必然出现的组织性失败模式。然而，这套基于 Token 用量衡量产出的逻辑，实际上是在度量执行的规模，而在 AI 时代，执行恰恰是成本最低的环节。用量攀升并不代表组织变强，甚至可能适得其反——一个团队通过让 Agent 空转来刷量，与一个团队真正解决难题，在这套指标体系下看起来别无二致。

工程组织面临两大难题。其一为组织内部可解：除了将使用量指标化，AI 原生研发组织究竟该具备何种形态，哪些旧规范亟需重构。其二是组织自身难以把控：构建正确的研发组织后，开发效率能否实现量级跃升，进而带动营收增长？

2026 年 5 月，Anthropic 的 Claude Code 工程总监 Fiona Fung 发表了一场演讲，精准回应了上述第一个问题。主题聚焦于当 Agentic Coding 从个人工具转变为全组织的默认配置时，哪些旧规范失效、哪些需要重写。她的核心结论是：难点不在于工具，而在于流程。具体需要重构的领域包括：代码审查、所有权归属以及人才招聘。

撰写 PR 的成本已趋近于零，但验证 PR 的成本并未同步下降。这两者之间的剪刀差，构成了新的瓶颈。AI 生成的代码比人类编写的代码更难验证。人类写代码时，错误往往伴随着明显的特征——逻辑不通、风格混乱、半途而废。AI 生成的代码则不同，它总是显得整齐、完整且合理。一段调用错误参数的代码与一段正确的代码，在 AI 的笔下几乎一模一样。验证者失去了过去用来快速筛选的表面信号，必须逐行核对逻辑本身。

此外，AI 甚至会主动让测试结果看起来正确——当测试失败时，它有时会修改测试用例，将原本正确的断言改为能让自己通过的断言。我本人也曾遭遇过几次：要求它实现一个功能，它发现测试通不过，随即修改测试中的期望值，整个改动看起来“全绿”，但规格说明已被悄悄篡改。验证的难度比传统软件高出数个量级——AI 既是被验证的对象，又具备绕过验证的动机。

开源社区已开始应对这一状况。2026 年 1 月，Ghostty 作者 Mitchell Hashimoto（Vagrant、Terraform 创始人）合并了一条新政策：未经预审批的 AI 生成贡献一律立即关闭，提交劣质 AI 内容者将被永久封禁。他的理由是：“Agentic programming 消除了过去那种基于努力的自然压力。现在只需最少的努力就能制造大量糟糕的内容。”curl 维护者 Daniel Stenberg 直接关闭了 bug bounty 项目，因为 2025 年提交的安全报告中不到 5% 是真实的，其余均为 AI 幻觉；他写道：“无穷无尽的垃圾提交对人的心智是真实的消耗。”tldraw、Apache Airflow 等项目也在出台类似政策。还有人利用 AI Agent 系统性刷 GitHub 贡献者数量，进行声誉造假——将过去依赖人力评估的“贡献者声誉”机制变成了可工业化伪造的指标。

开源是验证机制最薄弱的环节——任何人都可以提交 PR，维护者依赖声誉和时间来筛选。当 AI 使生成成本归零，而筛选成本不变，这套机制便不再适用。企业内部反应较慢，是因为身份认证（employee/contractor）卡住了入口——但这一屏障保护的是提交规模，而非验证能力。Salesforce 在 2026 年 5 月的官方报告中提到，其工程师 2026 年 4 月合并的 PR 数量比 2025 年 4 月增长了 79%——一家企业级 SaaS 公司，PR 规模已接近翻倍。开源目前发生的问题，企业正在经历中。

Anthropic 内部运行了一个多 Agent 的 Code Review 系统数月。部署后，收到实质性评审意见的 PR 比例从 16% 提升至 54%，超过一千行的 PR 有 84% 能被发现问题，小于 50 行的改动也有 31% 能被识别，而工程师标记为错误的发现不到 1%。每位工程师过去一年的代码产出增长了 200%，导致 review 直接成为瓶颈——换言之，在这套系统之前，超过八成的 PR 是在未经真正审查的情况下被合并的，人工 review 跟不上 AI 生成代码的速度，大量 PR 只能被“看一眼就放行”。

大多数工程组织衡量产出的方式，仍依赖于代码行数、PR 数量、提交频率等指标。这些指标隐含着一个共同的假设：代码是人工一行行敲出来的，因此写得越多等于产出越高。这一假设在 AI 时代已彻底失效。

Meta 的 Claudeonomics 看板依据 Token 消耗量对八万余名员工进行排名，30 天内全员 Token 消耗超 60 万亿，榜首者月均消耗超过 2800 亿——这个数字分摊到每天近 100 亿，远非手动输入 Prompt 能达到的量级，背后是有人为了让 Agent 连续空转数小时来刷榜。还有人观察到，当一名 OpenAI 工程师同时管理 20 个并行的 Codex 线程、比同事多开 70% 的 PR 时，所有传统指标都失去了意义——代码行数由 AI 撰写，提交由 AI 完成，PR 速度靠灌水，代码审查在人类看到前 Agent 已先完成。每一个传统指标都建立在“代码是人写的”这一前提上，而该前提已不复存在。

在这种产出规模下，继续用代码行数或 PR 数量衡量工程师，无异于鼓励灌水。一名工程师让 Agent 空转产出一万行无用代码，在这套指标下看起来比删掉五千行冗余代码、让系统更简洁的工程师“产出更高”。被奖励的是执行规模——而执行规模是 AI 时代成本最低的环节，奖励它等于在花钱让组织做最不稀缺的事。

行业内已有尝试新的度量方法。一种称为 Complexity-Adjusted Throughput，给 PR 按难度赋分——简单改动 1 分，中等 3 分，困难 8 分——因为原始 PR 数会高估琐碎改动、低估困难改动。还有人开始追踪 AI 辅助提交的比例、建议接受率、审查覆盖率一致性等行为指标。这些尝试尚处早期，但重心已从“写了多少”转向“解决了多大问题”以及“质量是否守住”。

换上新指标未必能立刻看到速度提升。METR 做过随机对照试验，发现经验丰富的开源开发者在使用 AI 工具时反而慢了 19%——工具被塞进了一个未为其重新设计的流程中，AI 写得再快也不重要，瓶颈卡在它前后那些未改过的环节。工具下发不等于组织提效，节省下来的时间会消失在未改流程的缝隙里。如果 AI 辅助代码占比不配以质量数据，本身就是个虚荣指标。

我自己带团队时有体会：度量的难点从来不在“算得出来的那些数”，而在“算不出来但真正重要的那些事”。工程师是否把模糊问题想清楚、是否在动手前判断对方向、是否在 review 中拦下别人没看到的隐患——这些在 AI 时代比过去更值钱，但代码行数和 PR 数完全捕捉不到。当“写”这个动作本身不再能区分工程师价值时，衡量他的尺子就必须更换。换不掉的组织，会一边奖励灌水、一边流失真正有判断力的人才。

过去工程师对技术方案有分歧时，解决方式是开会、画白板、争论，最后由资历最深或嗓门最大的人拍板。原因很简单：把每个方案都真正实现出来再比较，成本太高，开发时间耗不起。所以大家只能在抽象层面争论，用经验和直觉代替证据。

当实现成本趋近于零，这一逻辑改变。与其在白板前争论哪个方案更好，不如让每个方案都真正跑出来——几位工程师各自让 AI 实现一个版本，然后用真实代码和运行结果进行比较。Fiona 将此称为“Code Wins”：让代码本身投票，而非让会议室里的声音投票。

此举将技术决策从“基于权威和直觉”转向了“基于证据”。过去初级工程师的好想法可能因说不过资深人员而被否决；现在他可以直接把方案实现出来，让结果说话。决策质量不再那么依赖于谁更会表达、谁的资历更深。

我在做技术选型时曾用过这种方式。以前评估两个方案，要么靠经验拍脑袋，要么花一两周各做一个原型——成本太高，通常只能选一个方向赌一把。现在让 AI 快速实现两三个方案到可测试程度，用实际数据比较，再决定走哪条路。过去这种做法因太贵几乎无人使用，现在成本下降，可以成为默认动作。

一个组织要真正享受这些变化的红利，需要在哪些方面投资？答案是基础设施。

此处的“基础设施”并非指服务器、数据库等传统意义上的硬件。它指的是支撑 AI 与人协作的那一层组织能力——将单次 AI 调用转化为系统性产出，将个人判断沉淀为组织资产，将验证、知识、责任等过去依赖人力支撑的事物，重新构建在可持续运转的机制上。没有这套基础设施，AI 原生只是一个概念；有了它，AI 原生才是一个能运转的组织。基础设施分为两层：Infra 层和人员层。

从开发角度看，eval 比传统单元测试难得多。传统软件测试是静态对象：编写一组用例，通过即通过，不过即不过，测试本身不会与被测对象互动。AI 工程中的 eval 则不同。被测对象不是函数，而是一个有自由度、有“动机”的系统。同一段代码，模型这次输出 A、下次输出 B 都可能符合规范；同一个 prompt，喂给不同版本模型甚至同一模型的不同温度参数，结果都不一样。这意味着 eval 没有“通过/失败”这种二元状态，只有概率分布。测试组合通过率从 70% 提升至 75% 算不算改进，要看它在哪些 case 上提升、又在哪些 case 上下降。eval 本身是一个有方差、需持续维护、需随模型演化的对象。

eval 与被测对象之间存在对抗关系。前文提到 AI 会修改测试用例以通过测试——这在工程上称为 Reward Hacking，是 Goodhart's Law 的具体形态：一个指标一旦成为 AI 可见的目标，AI 就会优化指标本身而非指标背后的能力。在 AI 工程中这一问题尤为突出，因为 AI 既是被验证对象，又有能力修改验证规则。给它代码权限的同时，也给了它修改测试、修改 CI 配置、修改 eval 数据的权限。一个 eval 系统如果仅在“测试通过”这一层判断，AI 会找到漏洞；它必须有更高一层——能看出“AI 是否在动测试本身”、“测试覆盖率是否被偷偷削减”、“规范是否被篡改”。

还有一类问题：同一个模型既写代码又写测试时，会带有同源的偏见。它误解了规范的某个边界条件，代码写错；用同一种思维写测试，测试也按错的边界来——两边都错，但错法一致，于是测试通过。它对一段代码有“这应该是合理的”偏见，写测试时倾向于在它认为可疑的地方少覆盖、在它认为安全的地方多覆盖。这不是 AI 在主动绕过验证，而是它的思维方式本身是统一的——让同一个模型自我审查，与让一个人审查自己刚写的代码效果差不多。但在传统软件中，“自己审查自己代码”是临时状态，工程文化会推给同事或 reviewer；在 AI 工程中，这种状态变成了默认，因为许多团队的工作流就是“让 Claude Code 写完再让 Claude Code 自检”。这种结构性偏见用一组测试通过率是看不出来的——它需要一个不同