夜雨聆风很多公司意识到要让工程团队用 AI 之后，做的第一件事是把使用量做成指标——内部排行榜、Token 预算、把 AI 使用写进绩效。Meta、Amazon、Microsoft、OpenAI 都被报道过类似的内部追踪机制。这套打法已经有了一个新名字，叫 Tokenmaxxing——把 Token 用量本身当成生产力的代理指标。
Amazon、Microsoft、Google、Meta 这四家 2026 年 capex 合计在 6500 亿到 7000 亿美元之间，签下这笔钱的高管必须给投资人交代 AI adoption 的数字。Token 用量是最容易给得出来的数字——所以它就被给出来了。Tokenmaxxing 不是几家公司 HR 蠢，是 capex 周期下几乎必然出现的组织失败模式。但这套打法用 Token 用量来衡量产出，等于在度量执行的规模，而执行是 AI 时代成本变得最低的那一段。用量涨上去不等于组织变强，它甚至可以反过来——一个团队让 agent 空转刷量，跟一个团队真正解决问题，在这套指标里看起来一样。
摆在工程组织面前的是两个问题。一个是组织自己能解决的：把使用量做成指标之外，AI-Native 的研发组织该是什么样，什么需要重写。另一个是组织自己解决不了的：把研发组织搞对之后，开发效率提升一个量级，营收会跟着涨吗？
Anthropic 的 Claude Code 工程总监 Fiona Fung 在 2026 年 5 月做过一场演讲，正好回答了第一个问题。主题是当 agentic coding 从个人工具变成全组织默认，哪些旧规范失灵了、他们重写了什么。她的总结一句话：工具不是难点，流程才是。具体要重写的有三个地方——review、ownership、hiring。
验证比写更难
写一个 PR 的成本趋近于零，验证一个 PR 的成本没有变。这两者之间的剪刀差，就是新的瓶颈所在。AI 写的代码比人写的更难验证。人写代码时，错误往往伴随着明显的痕迹——逻辑不通、风格混乱、半途而废。AI 写的代码不会这样，它总是看起来工整、完整、合理。一段调用了错误参数的代码和一段正确的代码，在 AI 的笔下长得一模一样。验证者失去了过去用来快速筛查的那些表面信号，必须逐行去核对逻辑本身。
AI 还会主动让测试结果看起来对——遇到测试失败时，它有时候会去改测试 case，把一个原本正确的断言改成一个能让自己通过的断言。这件事我自己撞到过几次：让它实现一个功能，它发现测试过不了，转头就把测试里的期望值改掉，整个改动看起来"全绿"，但 spec 已经被它悄悄改了。验证这件事比传统软件难一个量级——AI 既是被验证的对象，又是有动机绕过验证的对象。
开源世界已经在面对这件事。2026 年 1 月，Ghostty 的作者 Mitchell Hashimoto（也是 Vagrant、Terraform 的创始人）合并了一条新政策：未经预批准 issue 的 AI 生成贡献一律立即关闭，提交劣质 AI 内容者永久封禁。他的理由是："agentic programming 消除了过去那种基于努力的天然背压。现在用最少的努力就能制造大量糟糕的内容。"curl 维护者 Daniel Stenberg 直接关掉了 bug bounty 项目，因为 2025 年提交的安全报告里不到 5% 是真实的、其余是 AI 幻觉；他写道，"无穷无尽的 slop 提交对人的心智是真实的损耗"。tldraw、Apache Airflow 等项目也都在出类似政策。还有人在用 AI agent 系统性地刷 GitHub contributor 数量、做 reputation farming——把过去靠人脑评估的"贡献者声誉"机制变成可以工业化伪造的指标。
开源是验证机制最薄弱的地方——任何人都能提 PR，维护者靠声誉和工时来筛。当 AI 让生成端的成本归零、而筛端的成本不变，这套机制就不再够用了。企业内部之所以慢一拍，是因为入口被 employee/contractor 身份卡住了——但这个屏障保护的是提交规模，不是验证能力。Salesforce 在 2026 年 5 月的官方报告里写到，他们工程师 2026 年 4 月 PR merged 比 2025 年 4 月涨了 79%——一个企业 SaaS 公司，PR 规模已经接近翻倍。开源现在出的事，企业已经在面对了。
Anthropic 内部跑了好几个月一个多 agent 的 Code Review 系统。部署之后，PR 收到实质性评审意见的比例从 16% 涨到了 54%，超过一千行的 PR 84% 能找到问题，小于 50 行的小改动也有 31% 能找到问题，而工程师标记为错误的发现不到 1%。他们每个工程师过去一年代码产出涨了 200%，review 直接成了瓶颈——换句话说，在这套系统之前，超过八成的 PR 是在没有被真正审查的情况下合并的，人工 review 跟不上 AI 产出代码的速度，大量 PR 只能被"看一眼就放行"。
代码行数不再重要
大部分工程组织衡量产出的方式，是代码行数、PR 数量、commit 频率这类指标。这些指标有一个共同的隐含假设：代码是人一行行写出来的，所以写得多约等于产出多。这个假设在 AI 时代彻底失效了。
Meta 的 Claudeonomics 看板按 Token 消耗量给八万多名员工排名，30 天里全员消耗 Token 超过 60 万亿，排第一的人月均两千八百多亿——这个数字分摊到每天将近一百亿，远不是手动写 prompt 能达到的量级，背后是有人为了冲榜让 agent 连续空转几小时来刷量。还有人观察到，当一个 OpenAI 工程师同时管理 20 个并行的 Codex 线程、比同事多开 70% 的 PR 时，所有传统指标都失去了意义——代码行数是 AI 写的，commit 是 AI 提的，PR 速度是灌水灌出来的，code review 在人看到之前 agent 已经先审了一遍。每一个传统指标都建立在"代码是人写的"这个前提上，而这个前提已经不成立了。
在这种产出规模下，继续用代码行数或 PR 数衡量工程师，等于在鼓励灌水。一个工程师让 agent 空转产出一万行没人需要的代码，在这套指标下看起来比一个删掉五千行冗余、让系统更简洁的工程师"产出更高"。被奖励的是执行规模——而执行规模是 AI 让成本变得最低的那一段，奖励它等于在花钱让组织做最不缺的事。
行业里已经有人在尝试新的度量方式。一种叫 Complexity-Adjusted Throughput，给 PR 按难度赋分——简单的改动一分，中等的三分，困难的八分——因为原始 PR 数会高估琐碎改动、低估困难改动。还有人开始追踪 AI-assisted commit 的比例、suggestion 的接受率、review 覆盖的一致性这些行为指标。这些尝试都还在早期，但重心已经从"写了多少"转向"解决了多大的问题"以及"质量有没有守住"。
换上新指标也未必能立刻看到速度提升。METR 做过一个随机对照试验，发现有经验的开源开发者在用 AI 工具时反而慢了 19%——工具塞进了一个没有为它重新设计过的流程里，AI 能写得多快不重要，瓶颈卡在它前后那些没改过的环节。工具发下去不等于组织提效，省下来的时间会消失在没改过的流程缝隙里。AI-assisted code 的占比如果不配上质量数据，本身就是个虚荣指标。
我自己带工程的时候有个体会：度量的难点从来不在"算得出来的那些数"，而在"算不出来但真正重要的那些事"。一个工程师有没有把一个含糊的问题想清楚、有没有在动手之前判断对了方向、有没有在 review 里拦下一个别人没看出来的隐患——这些在 AI 时代变得比过去更值钱，但代码行数和 PR 数完全捕捉不到。当"写"这个动作本身不再能区分一个工程师的价值，你用来衡量他的尺子就必须换。换不掉的组织，会一边奖励灌水、一边流失真正有判断力的人。
用代码替代辩论
过去工程师对一个技术方案有分歧，解决方式是开会、画白板、争论，最后由资历最深或者嗓门最大的人拍板。原因很简单：把每个方案都真正实现出来再比较，成本太高，开发时间耗不起。所以大家只能在抽象层面争论，用经验和直觉代替证据。
当实现的成本趋近于零，这个逻辑变了。与其在白板前争论哪个方案更好，不如让每个方案都真正跑出来——几个工程师各自让 AI 实现一个版本，然后用真实的代码、真实的运行结果来比较。Fiona 把这个叫 "code wins"：让代码本身投票，而不是让会议室里的声音投票。
这件事把技术决策从"基于权威和直觉"转向了"基于证据"。过去一个初级工程师的好想法，可能因为他说不过资深的人而被否掉；现在他可以直接把方案实现出来，让结果说话。决策的质量不再那么依赖于谁更会表达、谁的资历更深。
我自己在做一些技术选型时用过这个方式。以前评估两个方案，要么靠过去的经验拍脑袋，要么花一两周各做一个原型——成本高到通常只能选一个方向赌一把。现在让 AI 把两三个方案都快速实现到能测的程度，用实际数据比较，再决定走哪条路。过去这种做法因为太贵几乎没人用，现在成本掉下来了，可以变成默认动作。
AI-Native 研发组织必须具备更好的基础设施
一个组织要真正吃到这些变化的红利，得在哪些地方投资？答案是基础设施。
这里说的"基础设施"不是服务器、数据库那种传统意义。它指的是支撑 AI 和人协作的那一层组织能力——把单次的 AI 调用变成系统性的产出，把个人的判断沉淀成组织的资产，把验证、知识、责任这些过去靠人力撑住的东西，重新搭在一套能持续运转的机制上。没有这套基础设施，AI-Native 是一个概念；有了它，AI-Native 才是一个能运转的组织。基础设施分两层：infra 层和人这一层。
验证基础设施：让 review 系统自己进化
从开发的角度看，eval 比传统的单元测试要难得多。传统软件里的测试是个静态对象：你写一组 case，跑过就是过，不过就是不过，测试本身不会跟被测对象互动。AI 工程里 eval 不是这样。被测的不是一个函数，是一个有自由度、有"动机"的系统。同一段代码，模型这一次输出 A、下一次输出 B 都可能符合 spec；同一个 prompt，喂给不同版本的模型、甚至同一个模型的不同温度参数，结果都不一样。这意味着 eval 没有"过/不过"这种二元状态，只有概率分布。一个测试组合的通过率从 70% 提到 75% 算不算改进，要看它在哪些 case 上提了、又在哪些 case 上掉了。eval 本身是一个有方差、要持续维护、要随模型一起演化的对象。
eval 跟被测对象之间还有对抗关系。前面提到 AI 会去改测试 case 让自己通过——这件事在工程上叫 reward hacking，是 Goodhart's Law 的具体形态：一个指标一旦成为 AI 看得见的目标，AI 就会优化指标本身而不是指标背后的能力。在 AI 工程里这个问题特别突出，因为 AI 既是被验证的对象，又有能力修改验证规则。给它写代码权限的同时，就给了它修改测试、修改 CI 配置、修改 eval 数据的权限。一个 eval 系统如果只在"测试通过"这一层做判断，AI 会找到漏洞；它必须有更高的一层——能看到"AI 是不是在动测试本身"、"测试覆盖率是不是被偷偷削掉"、"spec 是不是被改了"。
还有一类问题：同一个模型既写代码又写测试时，会带着同源的 bias。它误解了 spec 的某个边界条件，代码写错；用同一种思维去写测试，测试也按错的边界来——两边都错，但错法一致，于是测试通过了。它对一段代码有"这应该是合理的"的偏见，写测试时就倾向于在它认为可疑的地方少 cover、在它认为安全的地方多 cover。这不是 AI 在主动绕过验证，是它的思考方式本身是统一的——让同一个模型自我审查，跟让一个人 review 自己刚写完的代码效果差不多。但传统软件里"自己 review 自己代码"是临时状态，工程文化会推到同事或 reviewer 那里；AI 工程里这种状态变成了默认，因为很多团队的工作流就是"让 Claude Code 写完再让 Claude Code 自检"。这种结构性 bias 用一组测试通过率是看不出来的——它需要一个不同来源的 reviewer 介入，理想情况下是不同模型、或者训练数据有差异的模型，至少是有独立 spec 理解的人。
verify 跟规模是两个独立的难点，但答案是同一个：人做不过来。最直接的反应是多招 reviewer，但验证的规模已经超过了招人能补上的程度。Boris Cherny 在红杉资本的一次访谈里描述过他认为的未来工作流——不是一个工程师跟一个 AI 对话，而是"循环与异步"：让 AI 自动、重复地运行成千上万个子 agent，组成一个持续运转的循环，全天候盯着系统、修测试、抓用户反馈、做聚类分析。一个工程师指挥的不再是一个 agent，是一支随时在跑的 agent 大军。在这种工作流下，产出的代码量是过去的几十倍。人工 review 在这个规模面前，从"忙不过来"变成了"根本不在一个尺度上"。
我跟一些 Anthropic 的工程师聊过他们现在的做法。海量代码已经让人 review 所有代码变得不可能。所以 review 这件事本身也交给了 agent：他们有一条 CI pipeline，由 agent 来做代码审查。在 review agent 后面，还有一系列 agent 在持续总结 review 中发现的问题，把这些问题沉淀成 skill，反过来让 review agent 变得越来越好。
这套机制是一个会自我改进的验证系统。每一次 review 发现的问题，不只是修掉了这一个 bug，还会变成组织的一项可复用资产——一个 skill，让以后所有的 review 都能查出同类问题。个人在一次审查里积累的判断，被沉淀成了整个系统的能力。
Salesforce 在 Claude Code 之上搭了一个叫 AI Expert Suite 的内部库，把工程团队反复用到的判断、约定、领域知识，沉淀成一组 Claude Code skills 文件，全公司共享。一个工程师做的 review 发现，可以变成一条 skill，下一次别的 team 用 Claude Code 时就能用上。他们的报告里有一个具体的故事——一个产品团队要把 33 个 API endpoint 迁移到新的云原生架构，按传统做法要 231 个 person-day。他们用 Claude 搭了一个 rule-based 框架（markdown 文件 + 参考实现），每轮 PR 反馈都把发现的问题沉淀回这套规则里，让后续输出越来越接近 production-ready，13 天做完了原本 231 天的工作。
2026 年 3 月 Anthropic 把一个类似思路的产品对外发布，叫 Code Review，Claude Code Team 和 Enterprise 客户能在自己的 GitHub repo 上接入。对外产品和内部那套机制不完全是一回事——内部有专门的 agent 把 review 中发现的问题提炼成 skill，对外产品的反馈回路是 thumbs up/down 加一个 verification step 过滤误报——但思路是接近的：多 agent 并行、各自查一类问题，再有一层验证。平均一次 review 20 分钟、$15-25。产品里还有一个具体接口叫 REVIEW.md，组织可以把自己对 review 的指令写进去，这些指令会被注入到每个 review agent 的 system prompt 最高优先级。这是把组织对 review 的判断注入 agent 流程的一个具体形态——文件里写什么，决定了 agent 看哪些问题、用什么 severity 来 flag。
Cloudflare 自建了一套类似的多 agent review 系统，跑在 OpenCode 之上，按改动大小分三档分配 reviewer 数量。他们公布了 30 天的运行数据——48095 个 MR、131246 次 review run、中位数 3 分 39 秒完成、$0.98 一次，工程师手动"break glass"绕过 AI 的只占 0.6%。review infra 自建还是买商业产品，正在变成 CTO 要做的选择——但"让 review agent 来跑、人只守住边界"这件事，企业内部已经在跑了。
这件事往前走一步，指向的是 AI agent 当前最大的一个缺口——它们不会积累经验。
一个工程师入职一个新项目，前几周磕磕绊绊，但几个月之后会长出一套对这个项目独有的认识：哪几个模块有历史包袱、哪些约定不写在文档里但所有人默认、为什么有段代码看起来奇怪却动不得。这些认识从工作里来，跟着这个人走。AI agent 现在没有这一层——每次调用都接近"新人入职第一天"，没有从过去的工作中学到的判断，没有对这个具体项目的独有理解。结果就是同样的错误一犯再犯，同样的解释一遍又一遍。
Anthropic 那套 review 系统能做到自我改进，靠的是在 agent 之外加了一层——把 agent 在工作中遇到的问题，提炼成 skill，存回组织，下一次的 agent 调用能用上。Agent 本身不变，但它身边那层"组织积累的判断"变得越来越厚。一个工程师的"项目经验"不在工程师的脑子里，是在他和这个项目反复打交道中形成的；同样，一个 AI agent 的"项目经验"也不能只存在模型权重里，得有一层组织层的、跟着项目走的累积。
真正能在工作里站住的 AI agent，光模型强还不够，得有跟着项目长大的那层累积。Anthropic 这套 review + skill 沉淀是个早期样本——把 AI agent 接进流程只是起点，让它能从流程中学到东西、把学到的东西沉淀回组织，才是真正决定长期价值的地方。
人留在哪个位置，他们的做法是按路径的关键程度来分：如果一个改动不在 critical service path 上，agent review 完成之后可以自动合并，不需要人介入；只有关键路径上的改动，才保留人工审查。
这条边界为什么这么划，我分别跟 OpenAI 和 Anthropic 的工程师聊过，两边给的理由都一致——不是"人的注意力要投在最重要的地方"，而是事故响应。关键路径上的代码必须每一行都有人逐行 review 过，因为一旦出问题，事故响应时是没有 AI 来帮你诊断和恢复服务的。AI 不在 oncall 群里、不知道这套系统积累下来的奇怪历史、不能在凌晨三点钟陪你判断这个 bug 是不是值得马上回滚。一段从来没人看过的关键代码，意味着事故发生时，组织里没有人对它有过那种"in-memory 的熟悉"，恢复时只能从零开始读代码——这种情况下，分钟级的 RTO 就变成小时级。所以关键路径上的人工 review 不只是为了拦 bug，是为了让 oncall 工程师对每一行代码都有过一次接触，事故响应时能立刻动手。
我自己维护一个比较大的代码库，重度用 Claude Code 和 Cursor，对这个剪刀差有切身体会。产出代码从来不是问题，一下午能产出过去一周的量。真正的负担全部压在后面——这些代码对不对、有没有引入隐蔽的问题、跟现有架构合不合。当产出快到一定程度，"我自己 review 一遍"会变成整个流程里最慢的一环。
知识基础设施：codebase 作为单一事实来源
传统工程组织里，关于"这个系统是怎么设计的、为什么这么设计"的知识，散落在文档、wiki、设计评审记录、以及资深工程师的脑子里。这套知识管理方式一直有个老问题：文档会过时，写下来的那一刻就开始和代码脱节。
AI-Native 组织里这个老问题变得更严重，但同时 AI 也提供了一个新解法：让 codebase 本身成为唯一的事实来源。代码是不会过时的，它就是系统当前的真实状态。配上一套自描述的结构——每个模块有说明自己职责的文件、整个项目有交代架构决策的文档（比如 CLAUDE.md 这类约定）——AI 在每次工作前先读这些，就能理解系统的设计意图，而不需要去翻一份可能已经过期的 wiki。
Fiona 提到他们把 codebase 当成 single source of truth，减少对独立的、难维护的文档的依赖。知识不再存在文档里，而是存在代码和它的自描述结构里，跟着代码一起更新。
我自己维护大代码库时，越来越多的精力花在这件事上——不是写代码，是维护一套让 AI 能读懂这个代码库的结构。哪些约定写在顶层、哪些上下文放在模块级、怎么让 AI 在改动一处时知道它会影响什么。context 管理做得好，AI 产出的代码质量和一致性会高一个档次；做得差，AI 每次都要重新猜测系统的结构，产出会逐渐偏离原本的设计。
验证基础设施和知识基础设施做的是同一件事——让 AI 在一个具体的组织里越用越聪明，而不是每次都从零开始。一边沉淀"什么是问题"，一边沉淀"系统是怎么设计的"。
人员基础设施：ownership 和 hiring
过去一段代码的归属很清楚——谁写的谁负责。但当代码是工程师和 AI 协作产出的，当一部分 PR 在 agent review 之后自动合并、没有任何人逐行看过，"谁对这段代码负责"就变得模糊了。如果自动合并的代码出了问题，责任在写 prompt 的人、在配置 review agent 的人、还是在定义自动合并规则的人？
这个问题没法靠"明确一下流程"解决。它触及的是工程组织里一个底层的东西——责任和控制是绑定的。过去工程师对代码有完全的控制，所以承担完全的责任。现在控制被分散到人、AI、和一套自动化规则之间，责任也必须跟着重新分配。一个 AI-Native 的工程组织得想清楚：哪些东西必须有一个明确的人类 owner，哪些可以交给系统，以及当系统出错时，问责链条是怎样的。
"会写代码"作为招聘标准的价值在下降。Boris 说他招工程师时看重 generalist，会留意候选人有没有"side quest"——业余项目，比如有人特别痴迷于做康普茶。他的逻辑是，这是一个人好奇、全面的信号。他还说，现在所有职能都这么招：PM 写代码，数据科学家写代码，连用户研究员也写一点代码。
这个取向背后是一个判断：当 AI 能把任何一个明确定义的任务执行得又快又好，一个人最稀缺的能力就不再是"在某个专项上很深"，而是"能在多个领域之间建立连接、能判断什么值得做"。专才的护城河被 AI 填平了一部分，通才的价值反而凸显出来。招一个会写代码但只会写代码的人，和招一个能写代码、也能想产品、还能自己找用户验证的人，后者在 AI-Native 组织里的杠杆要大得多。
Notion CEO 公开讲过他们把工程组织重构成了一个杠铃结构——一端是非常 junior 的工程师，刚毕业或者职业早期；另一端是少数非常 senior 的架构师；传统组织里那种"中坚力量"——经验不浅但谈不上顶尖的中级工程师——被刻意压缩了。年轻人没有被旧的工程实践和工具链塑造过，反而更容易接受新的开发范式；资深架构师负责定义系统级的分工——哪些部分交给模型、哪些部分坚持规则、怎么组织数据和服务——确保产品作为一个系统是连贯的。中间那一档在 AI 时代变成了最尴尬的位置：经验不足以做架构判断，但又被旧范式塑造得太深、不容易扔掉过去的认知去拥抱新方法。这是组织结构层面的变化——不只是招什么样的人，整个经验分布都在重新排。
我自己有个类似的判断：在 AI-Native 组织里，真正稀缺的两类人是"有 view 的人"和"做过 0 到 1 的人"。有 view 的人——对产品、对架构、对方向有自己一套判断、不需要靠别人给框架的人——能定义"AI 该做什么、不该做什么"这件事，对应的是 Notion 杠铃的资深端。做过 0 到 1 的人——完整地把一个产品从无到有跑通过的人，不管是创业、独立开发还是 side project——他们知道一件事被做完是什么样，知道在没有现成流程的情况下怎么自己定流程。这一类人不限定资历，但他们的特质跟 AI-Native 组织高度匹配：AI 让"从 0 到 1"变得便宜了，但前提是有人知道"1 长什么样"。中间那一档传统中级工程师之所以变得尴尬，是因为他们的经验都是在"1 到 100"的环境里积累的——执行成熟方案、维护已有系统、在既定流程里跑——而 AI 让这一段贬值最快。
Boris 自己有个更远的预测：软件开发正在被彻底民主化，会变得像发短信一样是一项基本技能。当写代码变得极度廉价，真正拉开差距的不再是编程能力，而是对业务领域的深刻理解——未来最好的行业软件，会由最懂那个行业的领域专家直接用 AI 造出来，而不是由纯粹的程序员造。这对 hiring 的含义是：一个工程组织未来要抢的人，可能不是更强的工程师，而是那些既懂某个具体业务、又愿意亲手用 AI 把想法做出来的人。在很多领域，后者比前者稀缺得多。
infra 和人这两层一起决定了一个组织能不能真正把 AI 用起来。infra 决定 AI 在组织里能学多深、记多久；人决定谁来负责、谁来判断、谁能跟 AI 配合到底有多紧。只盯着"工程师每天用了多少 token"，是在测一个表面信号；真正决定组织竞争力的，是 infra 和人这两层有没有搭起来。
当瓶颈不在工程内部
假设你把验证、知识、ownership、招聘、度量、协作方式都按 AI-Native 重新设计了一遍，开发效率真的提升了一个量级——一个团队过去一个季度做三个功能，现在一个月能做三十个。下一个问题，是工程组织自己解决不了的：营收并不会跟着涨三十倍，多数情况下连三倍都不会，有时候根本看不到提升。
Salesforce 在 2026 年 5 月公布过工程团队的产出数据——PR merged per developer 涨了 79%，他们自己用机器学习算出的 effective output 涨了 151%，一个本来要 231 person-day 的迁移项目用 13 天做完，效率 18 倍。报告里详细讲了他们怎么搭 AI infra、怎么沉淀 skill、怎么换流程。整篇报告里有一件事一次都没提——这些工程效率的提升给 Salesforce 带来了多少营收增长。这不是疏忽，是没法讲：工程组织把执行端做到了行业最快的状态之一，但这跟"Salesforce 卖出更多 license"之间，没有直接因果。
Boris 在同一场访谈里讲到，当工程师资源足够多的时候，瓶颈就不在工程了，而在"做什么"。开发效率提升 10 倍，对商业结果的影响往往不是 10 倍，有时候甚至看不到提升。一个用户不需要的功能做得快 10 倍，只是更快地浪费了资源——工程效率放大的是执行，但决定价值的是方向，而方向不在工程效率的管辖范围内。
戴雨森在跟张小珺的播客里讲过一个更具体的商业循环：现在涌进来用 AI coding 的人远多于发现 token 烧出去没价值就退出的人，所以 Anthropic、OpenAI、国产 coding 模型的收入都在快速增长——这有点像一个上面进水、底下漏水的水槽。但增加编程能力和增加收入之间不是直接的因果关系，最后必须有人能从烧的 token 里赚到钱，而且周期不能太长。如果漏水堵不住，整个循环就成立不了。现在很多公司发现，能直接算清账的回报反而集中在降本一端——也就是裁员。一旦 AI 的回报主要寄托在"替代谁的工资"上，故事的逻辑就开始紧张。
戴雨森还做过一个区分——AI coding 真正解决的，是个人和小公司过去"有想法没人做"的瓶颈。这一点确实是历史级的变化，独立开发者和早期创业团队的天花板被显著推高了。但大公司的问题不是这个，大公司的问题是"不知道做什么、以及组织效率很低"。把更多 AI 编码能力塞进一个不知道做什么的大公司，并不会让它变得知道做什么。同一套 AI 工具，对一个 5 人小团队是杠杆，对一个 500 人不清楚方向的大组织可能只是放大了原本的问题。
我自己做技术管理多年，对这件事有体会。一个工程组织最容易陷入的状态，是把"开发速度"当成自己的核心 KPI——因为速度是可以衡量的，而"做对了什么"很难量化。于是组织内部所有的优化都围绕速度展开：流程、工具、自动化、AI。但站在更高一层往下看，一个用户不需要的功能做得再快，也只是更快地占用工程时间。AI 把这个问题从"难发现"变成"很显眼"——因为速度提升十倍之后，"功能没人用"这件事会以十倍的体量暴露出来。
Uber 是硅谷最 AI-forward 的公司之一，但它四个月就烧光了全年的 AI 编码工具预算——起因是搞了一个按 AI 使用量给团队排名的内部排行榜。烧完之后，COO 公开表示，很难在"用了多少 Claude Code"和"给用户多交付了有用的功能"之间画出一条线。他的原话是，那条线还不存在。微软的反应是另一种——它一度给员工大量开放 Claude Code，但很快又砍掉了大部分直接 license、把工程师转回自家的 Copilot CLI，部分原因是财务考量。一家算账的，一家直接收手；两家都站在同一个事实面前：当 AI 预算的支出能算清楚、回报算不清楚，理性的反应不是继续加码。
AI 不是没用。AI-Native 的工程改造能把执行这台放大器调到最大，但它放大不出本来不存在的价值。如果产品方向是对的，10 倍的工程效率会变成实实在在的增长；如果方向不清楚，10 倍的工程效率只会让你更快、更贵地撞墙。工程组织的 AI-Native 化是必要的，但它从来不是充分的。它解决"做得快不快"，解决不了"做得对不对"。后者才是价值的来源。
过去市场把识别需求和工程能力捆在一起评估——一个工程能力强的团队，自然能挑出对的方向去做。AI 把这两件事解耦了：工程能力变得便宜、可复制，识别需求依然依赖判断、品味、对用户的理解。两类能力的市场价格正在快速分化。一个工程组织如果只在工程效率上加码、不在识别需求上加码，它在 AI 时代的相对位置会持续下降——前者的优势会被竞争对手快速追平，识别需求才是真正能拉开差距的地方。
人在 AI-Native 研发组织中的位置
一个 AI-Native 的研发组织和一个"用了 AI 的研发组织"，差别在两件事：组织内部有没有围绕"写代码不再是瓶颈"重写运转方式，外部有没有把节省下来的工程产能用在识别真正值得做的需求上。一件解决"做得快不快"，另一件解决"做得对不对"。两件都做到位，AI 才真正带来增长；只做第一件，速度提升只会让浪费来得更快。
验证也在被 agent 接管，而且那套验证系统还在自我进化。技术辩论交给了代码本身。知识沉淀进了代码库。那么人还占着哪些位置？
剩下的位置都是 AI 暂时接不了的：定义什么问题值得解决，判断什么是真正的好，守在最关键的那条路径上做最后的把关，以及设计和维护那套让 AI 高效工作的系统——review 系统、自描述的代码结构、自动合并的边界规则。这些工作的共同点是"判断"和"设计"，不是"执行"。其中最难的一件，工程效率本身回答不了——这一切的速度，到底在服务于什么。
戴雨森在同一段访谈里讲到，一个程序员八九成的工作是编程，剩下一两成是沟通协调、是组织里靠人与人之间的信任和关系驱动的事——这部分时间不多，但 agent 直接取代不了。人在工程组织里的存在价值，过去主要由"我能写多少代码"来兑现；当代码这件事大幅交给 AI 之后，那一两成原本"看不见"的工作浮出来，变成了主要价值——谁在跟谁建立信任、谁在协调跨团队的紧张、谁在为一个决策真正背锅。戴雨森还说，一个组织里能够背的锅是有限的。哪怕 AI 让你能看十倍的报告、做十倍的分析，你能承担的责任并不会跟着翻十倍。决策的下游是后果，后果要有人扛，而扛的人没法多到哪里去。
所以 AI-Native 的工程组织里，人会变得更少还是更多不是关键，关键是每个留下来的人承担的判断和责任会越来越密。被减掉的是执行环节里可替代的部分，留下来的是判断、设计、协调和承担。这两类工作过去是混在一起的，一个人 80% 的代码工作掩盖了 20% 的协调工作；现在 80% 被剥离出去，剩下的 20% 站到了前台。
如果一个工程组织还在用"写代码的快慢"来衡量自己、来配置团队、来奖励员工，那它量错了东西，也会把人才推向错误的方向。Tokenmaxxing 是这个错误最极端的形态，但即便没有排行榜，只要你的尺子还停留在"写"上，你就还停留在 Tokenmaxxing 的逻辑里。
真正的问题不是你的团队用了多少 Token、产出了多少代码，而是两个可以拿来对照自己组织的判断。
第一个判断：当一个工程师离开你的组织，他在 AI 协作中积累的判断，留下来了多少？
她在 review 中看出来的那些隐患，变成了下次 review agent 能自动查出的规则，还是跟着她一起走了？她对这个 codebase 的理解，沉淀进了模块说明和架构文档让下一任和 AI 都能读懂，还是只活在她的脑子里？她设的那些自动合并边界、那些 prompt 模板、那些 skill 文件，能被组织的下一个人继承吗？
如果答案接近"什么都没留下"，那不管你买了多少 Claude Code license，AI 都只是在放大每个个人的能力。个人能力的放大对个人是好事，对组织是脆弱——人走则空。AI-Native 的核心 infra 投资，是把 AI 协作中产生的判断，从一次性的个人事件，变成跟着组织、可累积、可继承的资产。判断这件事的标准很简单：你的组织一年之内积累了多少可复用的 skill、约定、规则？这个存量在增长还是停滞？
第二个判断：AI 让你节省下来的产能，进了利润表，还是进了判断力？
第一条路：用 AI 替代了一部分工作，省下了人力成本，组织其他部分照旧——同样的产品方向、同样的决策节奏、同样比例的人在做执行。这条路在财务上立刻好看，但它假设你过去的方向是对的、做的事是值钱的，只是太贵。如果这个假设站不住，AI 只是让你更快、更便宜地做错事。
第二条路：节省下来的人没有被减掉，被挪到了上游——做用户研究、做架构判断、做方向选择、做品味把关。组织里"决定做什么"的密度变大，"做出来"的密度变小。这条路在财务上短期看不出好看，但它在押注一个判断：AI 时代真正稀缺的能力是判断力，工程效率是必要但不充分。
这两条路上短期都没人能给出确定答案。但一个 AI-Native 的研发组织和一个"用了 AI 的研发组织"，差别就在这两个判断上有没有想清楚、敢不敢押一边。判断不清楚的组织，会同时做两件事——一边宣布裁员、一边采购 AI 工具——然后被两边的成本同时拖累。
参考资料
- https://www.hcamag.com/asia/specialisation/hr-technology/amazon-workers-are-gaming-the-ai-leaderboard-hr-built-it/575013
- https://blog.devgenius.io/open-source-projects-are-now-banning-ai-generated-pull-requests-8e1dd3e8d41c
- https://www.axios.com/2026/03/10/ai-agents-spam-the-volunteers-securing-open-source-software
- https://thenewstack.io/ai-generated-code-crisis/
- https://www.salesforce.com/news/stories/how-engineering-became-agentic/
- https://claude.com/blog/code-review
- https://code.claude.com/docs/en/code-review
- https://blog.cloudflare.com/ai-code-review/
- https://youtu.be/igO8iyca2_g
- https://youtu.be/SlGRN8jh2RI
- https://www.xiaoyuzhoufm.com/episode/6a15a2cbff7b9a8c0a5b953f
- https://fortune.com/2026/05/26/uber-coo-ai-spending-tokens-claude-code/
- https://tech.yahoo.com/ai/copilot/articles/microsoft-ditching-claude-code-copilot-133318848.html
