AI 编程的组织议题：从工具采购到激励设计的一份从业者笔记

我打算用一种相对冗长且偏向行业内部视角的方式，写一份关于 AI 编程的笔记。这份笔记不是给营销人员看的，也不是给那些把 AI 当成奇观的旁观者看的；它是写给那些在工程组织里实际承担成本、做出采购决策、设计激励机制、并最终需要在年底向 CFO 解释钱花到哪去了的人。如果你属于这类人，那么我假设你已经读过足够多关于“AI 改变一切”的高层叙事，也已经对这种叙事产生了健康的怀疑——这种怀疑既不是反对技术本身，也不是出于职业焦虑，而仅仅是因为你在工程组织里待得够久，知道任何一项被宣传成“改变一切”的东西，最终都需要在采购流程、合规审查、预算归属、绩效考核和事故复盘里逐一证明自己。

带着这种从业者的视角，我想谈一谈 Gergely Orosz 这几年在 The Pragmatic Engineer 上对 AI 编程的持续追踪。我先声明，我不打算重复模型公司发布会的 slogans，也不打算引用那些“工程师效率翻 N 倍”的耸动数字（这类数字的来源通常包含足够多的免责条款，使得它们在严格意义上几乎不可证伪也不可证实）。我想谈的，是 Orosz 在他的报道里反复呈现出来的那些“不太性感”的议题——上下文工程、采购流程、token 治理、激励扭曲、组织政治、激励设计——也就是那些任何一个真正在工程组织里推动 AI 落地的人都绕不过去的议题。

在我观察到的范围内，Orosz 是少数几个在这一波 AI 浪潮里既不站队模型公司、也不站队反 AI 派、并且持续把工程组织本身作为分析对象的写作者。他的视角恰好是我自己最熟悉的视角——我职业生涯的大部分时间也都花在思考“为什么看起来明明很合理的工程实践，在真实组织里就是推不动”这类问题上。所以这篇笔记，与其说是对 Orosz 观点的转述，不如说是借他这几年累积的报道，把我自己长期想说但一直没系统说过的几件事讲清楚。

我会按七个相互关联的主题展开：采纳率叙事的可信度问题、锯齿能力的真实分布、上下文工程作为大公司核心瓶颈、token 治理的 FinOps 视角、tokenmaxxing 现象的激励经济学、判断溢价对人才市场的重新定价、以及生产系统视角下的管理者议程。每一节我都会尽量保持一种“把话说全”的写法——这意味着段落会偏长、限定词会偏多、并且会包含大量的 in-my-experience 类型的从业者注脚。如果你只想要一句话结论，这份笔记不适合你；如果你想理解为什么“一句话结论”在这个领域里几乎总是误导人的，那么请继续读。

一、采纳率叙事：那些漂亮的数字到底意味着什么

让我先从一组数字开始，这组数字本身是真实的，但围绕它们形成的叙事则需要被仔细审视。

Orosz 从 2023 年开始系统性地向工程师调研 AI 编程使用情况。第一年他收到约 170 份反馈，整体偏正面。2024 年他记录到生成式 AI 工具的开发者使用率超过 75%。2025 年这个数字升到 85%，仅约 4% 的人表示完全不用。到了 2026 年，他的样本里 95% 的工程师每周使用 AI，75% 的人称一半以上的工作要用，56% 的人称 70% 以上的工作要用。这些数字在表面上构成了一个无懈可击的“AI 编程已主流化”的故事。

但任何一个在工程组织内部待过几年的人，看到这种数字曲线，第一反应应该不是兴奋，而是好奇——好奇这些数字背后的真实采纳质量是什么。在我职业生涯接触过的为数不少的工具采购里，“采纳率”这个指标常常意味着两件完全不同的事情：要么是工具本身好用到工程师抢着用，要么是公司层面要求每个工程师必须用，至于他们用得有多深、用得对不对、用了之后有没有产出实际价值，这些问题往往被采纳率本身的光鲜数字遮蔽了。

Orosz 自己是清楚这一点的。他在 LinkedIn 上写过一段话——我已经在多个内部会议里把这段话当作清醒剂来引用——大致意思是：行业里关于 AI 编程的成功故事很多，但很少有人愿意承认它在大型成熟代码库里的效果远不如绿色草地项目；他从 Google、Meta、Microsoft 这一类大公司的开发者那里听到的实际反馈是，在公司核心系统的语境里，AI 工具的价值往往明显小于它在新项目中的表现，许多人实际使用方式仍然停留在 autocomplete 这个相对浅的层面。他还提到一个具体例子：某大公司给所有开发者配了 Cursor license，几个月之后大约一半人不再使用。

这两组事实（高采纳率与高弃用率）在表面上是矛盾的，但在工程组织内部却完全不矛盾。它们只是说明，“采纳率”这个指标在企业语境里早已被复杂的组织动力学污染——一部分采纳是真实的，一部分采纳是合规性的（比如战略宣讲后的姿态使用），还有一部分采纳是在 KPI 压力下产生的（这一点我下面会专门展开）。把这三种采纳混在同一个百分比里报告，相当于把“客户喜欢我们的产品”和“客户被迫订阅了我们的产品”混在同一个续约率里报告——它在数学上是正确的，但在管理决策上是有害的。

我对那些试图用采纳率证明 AI 转型成功的管理者，有一个相当一致的建议：在你拿出 95% 这个数字之前，请先回答三个子问题——这 95% 里有多少是工程师在做之前做不到的工作，又有多少是用 AI 做以前自己也能做的工作；这 95% 里有多少在过去三个月里产生了可以归因到 AI 的具体结果（比如缺陷率下降、交付周期缩短、客户问题更快解决），又有多少只是在仪表盘上贡献了好看的曲线；以及，如果你明天悄悄关闭所有这些 AI 工具，公司未来三个月的实际产出会受到多大影响——这是一个有点反直觉但非常有效的诊断方法，它绕开了所有关于“使用率”的故事，直接问“价值”这个本质问题。

如果这三个问题的答案让你感到不安，那么你的 AI 转型可能比你想象的更早地进入了 vanity metric 阶段。这并不是 AI 工具本身的问题——它是任何一项被组织正式推动的技术变革都会在某个阶段必然遇到的问题。承认这件事，是把转型从公关阶段推进到工程阶段的第一步。

二、锯齿能力：在哪种工作上有用，在哪种工作上无用

Orosz 反复强调 AI 编程能力的“锯齿状”特征——在某些任务上极其有用，在另一些任务上几乎帮不上忙，在某些任务上甚至会让事情更糟。这一点不只是修辞，它有非常具体的工程含义，而且这些含义对采购决策、人才配置和工作流设计都产生直接影响。

让我把这个分布说得更具体一些（基于我自己在不同规模公司里观察到的、也大致与 Orosz 报道的情况吻合的分布）：

AI 在以下任务上提供高确定性收益：原型开发、内部工具、迁移脚本、测试骨架、跨语言翻译、文档生成、低风险的小功能、CRUD 表单、样板代码、简单脚手架。这一类任务的共同特征是上下文需求小、规则相对明确、错误代价低、可逆性强。AI 在这里能稳定地把一项原本需要几小时的工作压缩到几分钟，这种压缩是真实的，并且通常能直接转化为团队产出。

AI 在以下任务上提供低且高度方差的收益：成熟代码库里的核心模块修改、跨服务接口变更、性能敏感路径优化、并发与一致性逻辑、合规相关代码、安全敏感模块、跨团队协作的契约层。这一类任务的共同特征是上下文重、隐式约定多、副作用范围大、错误代价高。AI 在这里偶尔有用，但其有用性高度依赖于工程师本人的判断力——也就是说，AI 在这里不是工具，而是放大器：放大判断力的存在或缺失。

AI 在以下任务上提供负收益：需要深度理解组织历史的架构决策、跨多个系统的根因分析、涉及业务和技术折衷的优先级判断、长期演进路径的设计、需要承担实际后果的发布决策。这一类任务里 AI 的输出往往看起来合理，但它无法承担后果，因此在严格意义上不构成可信输入；任何把这一层工作交给 AI 的人，本质上是把责任结构悄悄外包给了一个不存在责任能力的实体——这件事的长期代价通常会在某个事故复盘里显现，并且通常会让一个本来挺好的工程师承担本不该由他独自承担的责任。

我特别想强调这个三分法对人才配置的含义。在我经手过的几个工程组织里，最常见的错误是把 AI 工具均匀地配给所有工程师，然后期待整体产出均匀提升。这个期待几乎从不实现，原因正是因为锯齿能力的不均匀分布。一个更可行的做法（虽然在政治上更难推行）是先识别团队里哪些工作落在第一类、哪些落在第二类、哪些落在第三类，然后把 AI 工具的预算和组织注意力主要集中在第一类上，对第二类保持谨慎评估，对第三类明确不做激励——直到组织有了足够的上下文工程能力（下一节会展开）来把第二、第三类逐步往第一类的方向迁移。

这种做法的政治难点在于，它需要管理者承认“我们的 AI 转型不会让所有人均匀受益”。这种承认在很多公司是不被允许的，因为现行的转型叙事要求所有人都看起来同样兴奋。但在我观察到的范围内，那些愿意做这个承认的组织，最终在两到三个季度后展现出比那些追求均匀光鲜采纳率的组织明显更好的实际成果——这个差异不是因为他们用了更好的工具，而是因为他们对“工具有效边界”的认识更诚实。

诚实是一种被严重低估的工程能力。

三、上下文工程：为什么大公司用 AI 比小公司难十倍

Orosz 在多篇文章里都呈现过一个现象——AI 编程对小团队和创业公司更友好，对大公司则要复杂得多。这件事在表面上似乎可以归因于工具成熟度或开发者技能差异，但在我看来，它的根本原因只有一个：上下文工程。

让我把这个概念解释得更具体一些。AI 模型的能力是相对均一的——同一个 Claude Code 在创业公司和大公司里运行，模型本身没有差别。差别在于这两种环境下 AI 能“看到”的上下文完全不同。

在一个三个月历史、五千行代码、两个工程师维护的代码库里，AI 几乎可以看到一切——所有文件、所有约定、所有上下游依赖、所有测试。只要工程师愿意把代码库交给 AI，模型基本上可以建立完整的全局图景。在这种环境下，“agentic” 这个词是名副其实的：AI 真的可以围绕任务自主操作工程环境。

但在一个十五年历史、八百万行代码、三百个工程师维护、跨二十个内部框架、三千个内部服务、五十种部署管道的代码库里，“让 AI 看到一切”在物理上不可能、在合规上被禁止、在组织上没有人有权限做这件事。这种代码库里真正的工作上下文有相当大一部分是非文档化的——它存在于资深工程师的脑子里、存在于多年来的 Slack 历史里、存在于离职工程师留下的注释里、存在于和上下游团队达成过又被悄悄修改的口头协议里。这些东西不会自动进入 AI 的上下文窗口，而且在大多数情况下也无法以可信的方式被结构化输入。

这就是为什么 Orosz 反复呈现的那个现象——大公司给所有人配 Cursor license、几个月后一半人弃用——在工程上是有合理解释的。它不是工具问题，也不是工程师问题，是上下文供给问题。模型再强，没有上下文它也只能写出“看起来合理但实际上忽略了三十个内部约定”的代码；而审查这种代码的成本，在某个临界点之后会超过工程师自己写的成本——这就是工具被弃用的真实原因。

那么大公司怎么办？这是一个真问题，而且没有简单答案。在我看来，大公司的 AI 编程战略不应该围绕“采购更好的工具”展开，而应该围绕“建设上下文供给系统”展开。这个系统至少包括三层：

第一层：可被 AI 检索的代码层上下文。包括代码库结构索引、内部框架的标准用法、约定库、设计模式库、历史决策的可检索文档。这一层的工作量巨大且没有捷径——它本质上是把过去十几年内部口口相传的 tribal knowledge 系统化沉淀。

第二层：可被 AI 理解的业务层上下文。包括产品规则、合规约束、SLA 条款、跨团队接口契约、关键不可变假设。这一层比第一层更难，因为业务上下文的迭代比代码快得多，文档天然滞后。

第三层：可被 AI 安全访问的运行时上下文。包括与生产数据的隔离机制、敏感操作的权限边界、审计日志、回滚路径。这一层是合规、安全、SRE 共同负责的工作，它决定了 AI 能否被允许进入工程流程的关键节点。

值得注意的是，这三层工作里，没有一层是单纯采购就能解决的。它们都是组织能力建设——需要长期投入、需要跨部门协作、需要对“什么是 tribal knowledge、它如何被沉淀”这个看似抽象的问题给出具体的工程答案。在我观察到的范围内，那些把 AI 转型主要理解为“采购工具”的大公司，几乎无一例外地在 18-24 个月后陷入低效采纳的泥潭；而那些一开始就把它理解为“建设上下文供给系统”的公司，虽然前期看起来进展慢，但在第二年开始展现出可见的复利效应。

这不是巧合。这是工程上下文密度的本质属性——它无法被绕过，只能被建设。

四、token 治理：FinOps for AI 这件事到底有多严肃

接下来我要谈一个更具体的运营议题：token 成本。

Orosz 在 2026 年 4 月的一篇文章里详细记录了过去几个月许多科技公司 AI agent 花费的急剧增长。他采访了 15 家公司的工作人员，看到一些组织的 token 花费在 6 个月内增长约 10 倍，且没有放缓迹象。具体的例子他写得很细：有公司从原来每人每月约 200 美元的 AI 工具预算，涨到每人每月数千美元；有工程师每天在 Claude Code 上花数百美元；有公司发现开发者为了“AI 使用指标”运行 agent；有团队把 Claude 这种昂贵工具用在低价值任务上。

我对这个现象的看法相当直接：我们正在重演 2010-2015 年云计算成本失控的剧本，而且这一次的曲线可能更陡。

让我把这个类比说得更精确一些。云计算早期，企业普遍认为“按需付费”就是“少花钱”，这个误解的根源在于他们把“可以按需”和“会按需”混为一谈。实际发生的事情是：每个团队都获得了开实例的权力，但谁也没有关实例的责任；每个项目都自己买带宽，但谁也没归集；财务部门在某个季度末突然发现账单是预算的三倍，于是开始疯狂找谁该负责，但发现整个组织里没有任何一个人有完整可见性。FinOps 这个学科就是在这种历史背景下产生的——它本质上是给“按需付费的灵活性”补上一套组织肌肉，让花钱这件事重新可见、可归属、可治理。

AI 编程现在面对的成本结构问题，和当年云计算的问题在结构上几乎一致，但有几点更糟：

第一，单位成本的不透明度更高。云计算的实例费用至少是按小时×规格计费的，工程师可以大致估算成本。token 的消费则取决于上下文长度、模型选择、retry 次数、agent 行为等多个变量，工程师在调用之前几乎无法准确预估单次调用的成本。

第二，归属机制更弱。云资源至少有 instance ID、tag、project、cost center 这一整套归属链。AI agent 跑出来的 token 是谁的？是那个发起调用的工程师？是 CI 流水线？是某个内部工具？大多数公司目前在归属层面还停留在“看 API key 是谁的”这种粗糙水平。

第三，行为放大效应更明显。云资源的浪费通常是被动的（忘了关），AI 的浪费可以是主动的（agent 自己决定多 retry 几次、多读几个文件、多生成几个候选）。这意味着就算工程师本人完全没有恶意，agent 的行为模式仍然可能在不知不觉中把一次调用变成十次调用。

第四，激励错位的可能性更大。这一点我下一节会展开，但简单说，AI 工具厂商的收入与你的 token 消费成正比，这意味着工具的设计取向天然倾向于鼓励更多调用——这与你作为采购方的利益并不天然一致。

那么应该怎么做？我的建议是把“token 治理”从一个工程问题升级为一个 FinOps 问题，并按以下几个维度建设：

预算归属：每一笔 token 消费都应该可以追溯到具体的人、团队、项目、任务类型。这听起来基础，但大多数公司目前做不到。

可见性：管理者和工程师本人都应该能看到自己最近的 token 消费曲线。在我观察到的情况里，仅仅“让工程师看到自己花了多少钱”这一项，就能在前两周显著降低 30-50% 的不必要消费。

默认值：默认模型应该是性价比最高的，而不是能力最强的。能力最强的模型应该是工程师明确选择的，而不是默认推送的。

异常检测：单个工程师/项目的 token 消费如果在一周内陡增 X 倍，应该自动触发告警。这件事不需要复杂的 AI——简单的统计阈值就够了。

上限：每个团队应该有月度 token 预算上限，超出需要明确审批。这不是为了省钱，是为了让“花钱”这件事重新进入决策视野。

关于 ROI 的诚实评估：定期把 token 消费曲线和工程产出曲线（速度、质量、缺陷率、客户满意度等）放在一起看。如果两条曲线长期不相关，说明 AI 投资没有产生工程价值，这件事必须被严肃讨论而不是被掩盖。

Orosz 在他的报道里呈现了行业里的两派分歧——let-it-rip 派认为应该先放开使用、再讨论控费，treasury 派认为必须先建立治理、再放开使用。这两派各有道理，但我个人倾向于一种中间立场：先放开使用是合理的，但放开的同时必须把可见性建好。换句话说，让工程师试，但所有的试都被记录在案、可被分析、可被回顾——这样在三个月后做评估时，你才有真实的数据基础来判断哪些用法值得保留、哪些应该停掉。

没有这一层基础，任何关于“AI 是否值钱”的讨论都只是猜想。在企业语境里，猜想是高级别管理层的特权，但它不是工程组织该用的决策方式。

五、tokenmaxxing：当指标变成激励，激励变成行为

我现在要谈一个 Orosz 创造或者至少推广的术语，叫 tokenmaxxing。

它的定义大致是：当公司把“AI 用得多”当成先进性指标或绩效信号时，工程师会开始故意最大化 token 消费——通过运行不必要的 agent、把任务拆得更碎、用昂贵模型做廉价活、放着便宜替代品不用而开高级模型。Orosz 在他的报道里给出过一个非常精炼的判断，大意是说这件事对 AI 厂商很好，对其他所有人都不好。

这个现象在我看来不是 AI 时代独有的，它只是一个非常古老的组织行为学规律的最新版本：任何被绑定到激励的指标都会被游戏化。Goodhart’s Law 早就说过这件事——当一个度量成为目标，它就不再是一个好度量。

让我把 tokenmaxxing 的形成机制写得更精确：

第一阶段：战略叙事。公司高层希望对外（投资人、董事会、媒体）和对内（员工、合作伙伴）展示“AI-first”。这本身没有问题——这种叙事在 2025-2026 年是合理的市场动作。

第二阶段：寻找指标。战略叙事需要可被汇报的进展。最容易被汇报的是采纳率、token 消费、活跃用户数、AI-generated PR 数量这一类指标。它们的好处是数字能涨、能做成 slide、能在年度汇报里展示出曲线。它们的坏处是它们与工程价值的关联度极弱。

第三阶段：绑定激励。指标进入团队 OKR、部门考核、甚至个人 KPI。这一步是分水岭——一旦指标被绑定到激励，第四阶段就不可避免。

第四阶段：行为调整。工程师为了在这些指标上看起来好看，开始调整行为：故意多调用 agent、用昂贵模型做简单活、把一个任务拆成五个 PR 以提高 PR 数、在不需要 AI 的地方使用 AI 以提高采纳率。这些行为在工程师层面是完全理性的——他们只是在响应组织发出的激励信号。

第五阶段：决策污染。被污染的指标继续被高层用来做战略决策。基于“采纳率提升 50%”，公司决定增加 AI 工具预算；基于“token 消费翻倍”，公司证明转型正在加速。这些决策建立在已经被污染的数据上，因此它们与真实的工程价值脱钩。

第六阶段：反噬。在某个时间点（通常是预算审查或事故复盘），公司发现 AI 投资与产出的关联度远低于预期。这时候责任通常被归到“工具不够好”或“工程师不会用”，而不是“激励设计错了”。然后公司启动新一轮工具采购或培训，整个循环重新开始。

这个六阶段模型在我职业生涯里见过的版本不只 AI 一个——过去几年的低代码、再往前的 DevOps 转型、再往前的敏捷转型，都走过类似的路径。每一次的关键失败点都不在工具或工程师，而在第二、第三阶段——选错了指标、错误地绑定了激励。

tokenmaxxing 之所以特别有破坏力，是因为它的反馈延迟特别长。云成本失控会在月底账单上立刻显现，技术债会在下次发布事故里显现，但 AI 投资 ROI 的真实信号通常要 6-12 个月之后才能看清——而这段时间里，被污染的指标会持续制造“一切顺利”的假象。

我对管理者关于 tokenmaxxing 的建议（虽然我承认这种建议在大多数公司不会被采纳）非常具体：

不要把 token 消费、AI 采纳率、AI-generated PR 数量绑定到任何形式的考核或汇报。这些指标作为“可见性数据”是有价值的，但作为“激励信号”是有害的。一旦它们进入考核，它们就会被游戏化，从那一刻起它们停止反映真实情况。

衡量 AI 的价值要回到工程结果本身：交付速度、缺陷率、change failure rate、客户问题解决时间、开发者满意度。这些指标本身也会有问题，但至少它们是“组织真正想要的东西”的近似——而采纳率不是。

如果一定要衡量 AI 使用，至少分类衡量：区分高价值场景（边界清晰、ROI 可证明）和低价值场景（agent 自己决定多跑几次的那种）。把整体 token 数当成单一指标，等于把客户支付的钱和员工随手刷的钱算在一起。

在组织层面接受一个不舒服的事实：在 AI 转型的前 12-18 个月，最重要的“成果”可能是搞清楚“什么不该做”，而不是“做了多少”。这种姿态在很多公司不被允许，但它是少数几个能避免长期 ROI 灾难的姿态。

这些建议不性感，但它们大概率比下一次工具采购更值钱。

六、判断溢价：工程师劳动力市场的一次安静重排

我现在要谈一个更长期的问题：工程师劳动力市场正在发生的重新定价。

Orosz 在 2026 年的一篇文章里把工程师粗略分成三类——Builders、Shippers、Coasters——并指出 AI 不会让所有人均匀变强，而是会放大每种人原本的倾向。这个分法听起来像是性格描述，但在我看来它更接近一种能力组合分类：Builders 倾向于把 AI 用作系统建设的杠杆，Shippers 倾向于把 AI 用作交付加速器，Coasters 倾向于把 AI 用作维持现状的便利工具。

更宏观地看，这个分化反映了一个更基本的事实：当代码生产的边际成本逼近零时，工程师劳动力市场上“代码生产能力”的相对权重会下降，“判断类能力”的相对权重会上升。我把这个现象称为判断溢价。

什么是判断类能力？我觉得它至少包括：

把模糊的业务需求转化为清晰可执行任务的能力
设计可验证的输出边界和成功标准的能力
在大量 AI 候选输出中识别出真正可信的那一个的能力
识别 AI 幻觉、过拟合、或绕过内部约定的能力
判断“这段代码值不值得存在”的能力
在系统层面预判一个变更可能引发的副作用的能力
在跨团队、跨系统、跨时间尺度上做合理折衷的能力
在事故发生时定位根因并设计预防机制的能力
在不完整信息下拍板的能力，并愿意为这个拍板负责

这些能力都有一个共同特征——它们要求一个有 stake 的人来执行。AI 可以推理，但它不需要为推理结果承担后果；人类可以推理同时承担后果，这个差异在 AI 时代变得格外珍贵。

Orosz 调查里那个反直觉的发现——staff+ 和 director+ 级别的人对 agentic 工具最热情——在判断溢价框架里完全可以解释。资深工程师之所以更兴奋，是因为他们最清楚自己被卡在哪里：他们手里有一长串“知道该做但没时间做”的任务清单（重构、测试矩阵、技术债清理、内部工具升级），AI 给了他们一个把这些清单消化掉的杠杆。他们的判断力和经验不被 AI 替代，反而被 AI 放大——他们提供的是“做什么、怎么做、什么算完成”，AI 提供的是“动手”。

而初级工程师面对的情况则相反。他们手里没有那张清单，他们手里只有公司布置的任务。AI 给他们的不是杠杆，更接近替代品——替他们写代码、查错、解释。这种替代在短期内看起来加速了产出，但长期看会让他们绕过最关键的成长机会：理解为什么这样写、哪里会出错、如何承担后果、如何在一个有限信息的真实系统里做判断。这就是 Orosz 关注的“AI slop”现象的本质——更多代码被生成，但工程判断力没有同步增长。

判断溢价对工程师个人职业策略的含义相当直接：

短期（未来 12-24 个月）：AI 工具的熟练度本身有一定的市场溢价，因为还有相当一部分团队在补这个缺口。值得投资，但要意识到这个溢价的窗口期不会太长——工具熟练度本身会快速贬值，因为它太容易被新工具替代。

中期（未来 2-5 年）：判断类能力的市场溢价会显著扩大，特别是那些能跨“代码 + 系统 + 业务 + 组织”四个维度做判断的工程师。这种 T 型甚至 π 型能力组合，在 AI 时代会成为定义 senior 级别的真正标准——不再是“能写多少行代码”，而是“能保障多少行代码值得存在”。

长期（5 年以上）：那些把“会写代码”作为唯一职业身份的工程师会面临结构性挤压。这不是说他们会失业，而是说他们的市场价位会从原本的“高于平均”逐步回落到“平均或以下”。这件事不会一夜之间发生，但它的方向是确定的。

判断溢价对组织人才策略的含义同样具体：

招聘：以“代码量”或“语言/框架熟练度”作为主要筛选标准的公司会越来越多地招到错的人——招到的是擅长写代码的人，但需要的是擅长判断的人。招聘流程里需要明确加入判断类能力的考察，比如系统设计、需求拆解、风险识别、跨系统决策等。

晋升：如果晋升标准里“代码产出”权重过高，组织会自动把判断力强的人推离他们最该做的工作。判断力强的人往往代码量不会比 AI 加持的初级工程师多，但他们的工作不能用代码量衡量。

培养：初级工程师的成长路径需要重新设计。如果把“先写大量代码积累手感”作为默认培养路径，AI 会让这条路径在工程意义上失效。新的路径需要更早引入“判断、审查、负责”的训练，可能甚至需要刻意限制 AI 在初级工程师身上的使用，以保护他们最关键的成长窗口。

这些事情都不性感、都需要长期投入、都会在短期看起来与 AI 转型主流叙事不一致。但它们是组织在 AI 时代真正需要做的人才工作。

七、生产系统视角：管理者真正该上的议程

我把上面六节的内容收拢一下，提出一个我认为管理者应该认真对待的议程框架。

绝大多数关于 AI 转型的管理者议程都太简单了——它们大致长这样：“采购一批 AI 工具 + 给所有人配 license + 在 KPI 里加一项 AI 使用率 + 季度汇报里放一张采纳率曲线”。在我观察到的范围内，这种议程几乎无一例外地在 12-18 个月后陷入 vanity metric 困境，最终需要重启。

更靠谱的议程不应该围绕“工具采购”展开，而应该围绕“生产系统重构”展开。生产系统视角把 AI 转型理解为对一整套工程生产流程的重新设计，而不是对其中一个工具节点的替换。在这个视角下，管理者的真正议程包括至少以下七项工作：

第一，明确 AI 在不同任务类型上的定位。基于锯齿能力的真实分布，明确告诉团队哪些场景鼓励大胆使用 AI、哪些场景使用 AI 时需要更严格的审查、哪些场景明确不依赖 AI。这种分类不应该是抽象原则，而应该是写在内部 wiki 上的具体清单。

第二，建设上下文供给系统。这是大公司能否真正用上 AI 的核心瓶颈，需要长期投入。包括代码层、业务层、运行时层的三层上下文工程，每一层都需要专门的负责人和路线图。把这件事当成“文档完善工作”来做的公司，三年后会发现自己什么都没做出来；把它当成“基础设施建设”来做的公司，会在第二年开始享受复利。

第三，建立 FinOps for AI 能力。把 token 治理升级到与云成本治理同等的严肃程度。包括预算归属、可见性、默认值、异常检测、上限、ROI 评估。这件事的前期投入不大，但它是少数几件能让 AI 转型在两年后不变成预算灾难的事情。

第四，重新设计指标体系。明确放弃把“AI 使用率”和“token 消费”作为激励指标，回到工程结果本身（交付速度、质量、缺陷率、开发者体验、客户价值）。在这一过程中，要做好心理准备——短期内你的“AI 转型成果汇报”会比同行难看一些，因为你不再追求那些容易做出来的虚假数字。但你的工程组织会因此保持健康。

第五，分级使用 AI 的人才策略。承认 AI 对不同 seniority 的工程师产生不同影响。资深工程师应该被鼓励大胆使用 agentic 工具去清理他们手里的存货；初级工程师的 AI 使用应该被有意识地节制，以保护他们的成长窗口。这件事在政治上很难——它会让人误解为“对初级工程师不公平”——但它是负责任的人才工作。

第六，更新代码审查、测试、发布的工程实践。当代码生产速度上升 N 倍，下游的审查、测试、发布流程必须同步升级，否则瓶颈会迁移到这些环节并造成系统性堵塞。具体包括：审查标准是否需要提高、测试覆盖率的最低线是否要上调、发布灰度策略是否要更保守、回滚能力是否要更强。这些工作的投入回报不在“我们用了多少 AI”上，而在“我们的事故频次有没有保持低位”上。

第七，定期做诚实的 ROI 复盘。每个季度（不是每个月，那太频繁；不是每年，那太晚）拿出一个工作日，把这个季度的 AI 投入（钱、人时、工具采购）与产出（具体的工程结果）放在一起对比，并允许团队明确说出“这部分投入没产生价值，下季度停掉”。这种复盘的价值不在于纠正具体决策，而在于它是组织文化层面的一种诚实承诺——承认 AI 转型不是一次单向加速，而是一个需要持续校正的长期工程。

我承认这份议程比“采购 + 配 license + 上 KPI”难得多、慢得多、也无聊得多。它不会出现在融资 deck 的封面上，也不会让 CEO 在年度汇报里发出激动的总结。但它是少数几件能让你的组织在三到五年后真正从 AI 中获得复利的事情。

而且——这一点我觉得在 2026 年这个时间点尤其重要——做这件事的窗口正在快速收窄。当 token 通胀的曲线持续陡峭、当 vanity metric 越来越普及、当全行业的 ROI 焦虑开始浮现，那些已经把生产系统重构做扎实的组织会展现出明显的相对优势；而那些还在为下一份 AI 工具合同和下一份采纳率汇报忙碌的组织，会越来越发现自己被困在一个看起来很忙、实际上没动的状态里。

八、一些克制的尾声

我写这份笔记的目的，不是反对 AI 编程，也不是给 AI 转型泼冷水。我自己日常工作里大量使用 AI 工具，并且能感受到它们带来的真实生产力提升——这种提升是真的，不是叙事。

但与此同时，我也观察到这场浪潮里大量被忽略的组织议题。这些议题不性感、不上头条、不会出现在模型公司的发布会里，但它们决定了一家公司在 AI 转型上是真的在前进，还是只是在制造前进的样子。Orosz 这几年最有价值的工作，就是把这些被忽略的议题反复拽到台前——上下文工程、采购流程、token 治理、激励扭曲、生产系统重构。这些议题不是 AI 编程的反面，它们是 AI 编程在工程组织里能否真正落地的前提。

如果一定要我给这份笔记一个一句话的收束，我会说：AI 编程的胜负不在模型层，而在组织层；不在工具采购，而在系统重构；不在采纳率，而在判断力。任何把这件事处理成简单工具问题的公司，都会在两到三年后用具体的代价学到这个道理；那些一开始就把它当成组织能力建设的公司，会在同一时间点开始收获复利。

这两种结果的差距，最终不会显示在 token 消费曲线上，而会显示在更长期的工程质量、人才结构、和组织韧性上。这些东西在仪表盘上看不见，但在五年之后看得见。

而五年——以软件工程的尺度——并不算长。