AI 编程的生产函数：当代码变便宜，什么变贵了
我想从一个反直觉的观察开始。
过去这两年，关于 AI 编程的讨论里，最常见的一个说法是“AI 让程序员效率翻了 X 倍”。X 是多少不重要，反正大家都在说这是一场效率革命。
但如果你认真追踪过这件事，会发现一个很有意思的现象——真正深入工程组织内部的人，反而很少这么说。他们说的是别的东西：上下文工程、激励扭曲、token 通胀、锯齿能力、生产函数重排、判断溢价。这些词听起来都不像“效率翻倍”那么爽快，但它们更接近真相。
这群人里我最喜欢追的一个，是 Gergely Orosz。他不是模型公司的人，也不是工具测评的博主，是一个长期在工程组织内部看问题的写作者——Uber、Microsoft、Skype、Skyscanner 这些公司他都待过。后来他创办了 The Pragmatic Engineer，从 2023 年开始持续做 AI 编程的调研和报道，一直追到 2026 年。
我为什么觉得他的视角格外重要？因为他给我们提供了一个稀缺的东西：一个有方法论、有时间纵深、有真实样本的工程现场观察。他既不站在模型公司的角度，也不站在职业焦虑的对立面，而是反复追问——这些工具到了真实工程组织里，到底如何改变了工程师、团队、成本和度量。
这篇文章想做的，就是把他这几年的观察提炼成一个可用的思维框架。我会用八个相互独立又彼此咬合的概念来组织：心理价格、锯齿能力、生产函数、上下文工程、token 通胀、指标黑洞、判断溢价、生产系统。
理解了这八个概念，你大概就能比 95% 关于 AI 编程的讨论看得更深一点。
一、第一个概念：从“心理价格”看 AI 编程的真正变化
我先给一个数据序列。
Orosz 从 2023 年开始做开发者 AI 使用调研。第一年大约有 170 多位工程师反馈，他记录的核心结论是“明显有用，但影响边界未定”。2024 年他记录到生成式 AI 工具被 75% 以上的工程师使用。2025 年这个数字是 85%，只有约 4% 的人说自己不用。到了 2026 年，他的调查显示 95% 的受访者每周使用 AI，75% 的人称一半以上工程工作要用，56% 的人称七成以上要用。
光看数字会得出一个简单结论：AI 编程已经主流化了。但这个结论太浅。真正发生变化的，不是“用没用”，而是用 AI 时的心理价格。
经济学里有个概念叫心理账户，丹尼尔·卡尼曼在《思考，快与慢》里讨论过。同样是损失十美元，“丢了一张电影票”和“丢了一张十美元钞票”在人脑中的核算方式完全不同。账面价格相同，心理价格不同，行为就不同。
AI 编程的真正转折，发生在心理价格的翻转上。
2023 年我们用 AI 像用一个按小时收费的顶级律师。每次提问之前要精心组织 prompt，生怕浪费一次调用。心态是“这个问题值不值得动用 AI”。2026 年的工程师早已不是这种心态。他们的默认动作是“先让 AI 看一眼”，工作流变成了“AI 跑一轮 → 出三个方案 → 我从中挑一个”。底层 token 价格未必整齐降了一百倍，但主观体验上，从“昂贵顾问”变成了“自来水”。
这个翻转的意义，比任何一个具体百分比都重要。它不是效率提升，它是行为模式改写。
这件事的 takeaway 是：AI 编程的第一阶段变化不在能力，在心理价格。当调用一次 AI 的心理成本足够低，工程师的整套工作流会自动重排。能力跃迁是大事，但行为重排才是真正的范式变化。
二、第二个概念：锯齿能力——AI 不是均匀的杠杆
理解 AI 编程的第二关，是放弃“均匀提升”的幻觉。
很多关于 AI 的讨论默认它是个均匀工具，比如“提升 30% 效率”。但 Orosz 的观察一直在反复指出一件事：AI 在不同任务上的表现差异极大，它不是均匀提升，而是锯齿状提升。
我把这个特征命名为锯齿能力。
锯齿能力的意思是：AI 在某些任务上表现极佳，在另一些任务上几乎没有帮助，在某些任务上甚至会让事情变更糟。这不是“平均效率”能描述的，必须按任务类型分。
Orosz 的材料里给出过非常具体的分布：
锯齿的高峰区——绿色草地项目、原型开发、小型工具、迁移脚本、测试补全、样板代码、文档生成、跨语言翻译。这些任务的共同特征是：边界清楚、历史依赖少、上下文需求小、失败成本低。AI 在这里几乎是降维打击。
锯齿的低谷区——大型既有代码库里的核心模块、高约束遗留系统、内部框架密集的环境、合规相关逻辑、跨团队接口。Orosz 在 LinkedIn 上专门写过这件事。他从 Google、Meta、Microsoft 等大公司开发者那里听到的反馈是，在二十年历史的核心服务里，AI 工具的价值常常远小于绿色草地项目，很多人实际用法仍停留在 autocomplete。他还提到一个例子：某大公司给所有开发者配了 Cursor license，几个月后约一半人停止使用。
锯齿的反向区——AI 给出看似漂亮、实则绕过内部约定或重复实现的代码。这种代码的副作用不在生成那一刻显现，而在数月后维护时显现。METR 和 Cursor 都做过类似研究，发现在某些大型开源任务中，使用 AI 的开发者实际花的时间反而更长。
锯齿能力解释了一个普遍困惑：为什么两个工程师对 AI 编程的体验会截然相反？一个用 Cursor 周末做出小应用，觉得软件工程要被颠覆；另一个在公司核心服务里调几行代码反而更慢。两者讲的都是真话。差别是他们抓到了锯齿上不同的齿。
这件事的 takeaway 是：评估 AI 编程不能问“它有多大用”，要问“在哪种任务上有多大用”。把任务类型作为分析维度，是理解 AI 编程的最低门槛。任何不区分任务类型的“AI 编程效率提升 X%”的说法，本质上都是在求一个无意义的平均数。
三、第三个概念：生产函数重排——瓶颈不会消失，只会迁移
经济学里有个概念叫生产函数，描述投入和产出的关系。
软件工程的生产函数大致可以写成：工程师时间 × 技能 × 团队流程 × 工具 × 代码库状态 → 软件产出。AI 编程进来之后，函数本身没有崩塌，但每一项的权重和性质都在重组。
我把这个过程命名为生产函数重排。
Orosz 在多篇文章里都呈现过同一个观察：AI 让代码生成速度大幅提升后，瓶颈并没有消失，而是迁移到了别的地方。他记录到的具体场景是：工程师写代码速度上来了，团队反而开始被 Product 和 Design 阻塞；Staff+ 工程师更多卷入 PRD 和上游产品定义，因为如果需求不清楚，AI 只会更快地产出错误方向的代码。
这就是生产函数重排在现实中的样子。
把这件事拆解成更精确的描述：
工程师时间的分配重心从“实现”迁移到“定义、审查、验证、处理例外”。亲手写代码的占比下降，定义任务、提供上下文、审阅 AI 输出、构造验证路径的占比上升。
技能的核心从“语言/框架熟练度”迁移到“系统理解、产品判断、架构品味、AI 编排能力”。语法和样板可以让 AI 补齐，但“知道这段代码值不值得存在”无法外包。
团队流程从“围绕人写代码”重组为“围绕人和 agent 共同工作”。代码审查的对象从同事变成 agent 输出；CI 流水线里要不要嵌入 AI 步骤；工具如何在团队间共享上下文——这些都是新议题。
工具从“编辑器”扩展为“能跨代码库、命令行、文档、CI、issue tracker 行动的半自主系统”。Orosz 反复强调 Claude Code 这类工具代表的是从“建议下一行代码”到“围绕任务操作工程环境”的范式跃迁。
代码库状态的权重急剧上升。测试完善、文档清楚、架构边界明确的代码库更容易被 AI 利用；混乱、隐式约定多、缺少测试的代码库会放大 AI 的错误。原本就在拉开差距的代码库，被 AI 放大得更厉害。
这件事的 takeaway 是：AI 编程不是给生产函数加了一个常数，是把每个变量都换了一种性质。任何只看其中一个变量（比如“工程师写代码快了”）的判断，都会丢掉真正的故事。瓶颈从不消失，它只迁移。瓶颈在哪里，那里就是真正需要投入注意力的地方。
四、第四个概念：上下文工程——AI 时代的新第一性原理
如果说生产函数重排是从外部看变化，那从内部看，最重要的新工作是上下文工程。
这个词不是我发明的，但在 AI 编程语境里，它是被严重低估的核心能力。
上下文工程指的是：如何系统性地为 AI 提供它做出有效输出所需要的全部上下文，包括代码库结构、内部约定、业务规则、风险边界、验证标准等。
Orosz 在多篇文章里反复提到这个主题。他在大公司语境里讨论的“AI 工具在大型代码库里效果差”，本质就是上下文工程问题——大型代码库的上下文是隐式的、非文档化的、深度纠缠的，AI 拿不到，只能在表层瞎写。他在 MCP（Model Context Protocol）相关讨论里关注的，也是这件事——MCP 之所以重要，不是因为它是个神奇协议，而是因为它代表了 AI 助手与真实工程系统之间的连接：代码库、数据库、文档、issue tracker、CI/CD、内部服务都可能成为 AI agent 可调用的上下文和工具。
我把上下文工程拆成三个层级，由浅到深：
第一层：Prompt 工程。给 AI 写清楚“你要做什么”。这是最浅的一层，也是大多数初学者停留的地方。
第二层：环境工程。给 AI 配置好“它能看到什么”。包括代码库结构、相关文件、已有约定、历史变更——通过 MCP、文件挂载、知识库等方式让 AI 接触到必要信息。
第三层：组织工程。给 AI 设计好“它如何在组织里安全运转”。包括权限边界、敏感数据隔离、合规约束、审查流程。这是大公司真正卡住 AI 编程的地方，也是小公司能跑得飞快的原因——它们没有这层包袱。
这三层的难度是指数上升的。Prompt 工程几乎人人都能做；环境工程是工程师的活；组织工程是管理者+安全+合规+架构师一起的活。
Orosz 在大公司案例里反复呈现的现象——“工具很强，但用不起来”——本质上是组织工程没解决。模型不是问题，让模型在公司既有约束下安全调动公司既有资源才是问题。
这件事的 takeaway 是：AI 编程时代真正稀缺的能力，不是“会写 prompt”，而是“会工程化地为 AI 提供它需要的上下文”。这个能力越往组织层走越值钱，也越难。把上下文工程当作 AI 编程的第一性原理，是从工具使用者升级为系统设计者的关键。
五、第五个概念：token 通胀——重演一遍云计算 FinOps 的故事
我现在想谈一个非常具体也非常残酷的话题：钱。
Orosz 在 2026 年 4 月的一篇文章里记录到，过去两三个月很多科技公司的 AI agent 花费在急剧增长。他采访了 15 家公司的人员，看到一些组织的 token 花费在 6 个月内增长约 10 倍，且没有放缓迹象。具体的例子非常生动：有公司从原来每人每月约 200 美元的预算，涨到每人每月数千美元；有工程师每天在 Claude Code 上花数百美元；有团队把昂贵模型用在低价值任务上。
我把这个现象命名为 token 通胀。
它跟 2010 年前后的云计算成本失控几乎是一比一对应的。
云计算的故事大家都熟悉了。早期大家觉得云就是更灵活的基础设施，按需付费应该更便宜。然后过了几年发现账单失控，原因不是云本身贵，而是没人管——每个团队都能开实例，谁也没盯着关；每个项目都自己买带宽，谁也没归集；月底账单出来财务部门一片哀嚎。后来才有了 FinOps：预算归属、成本可见性、tagging、自动化关停、异常检测——本质上是给“花钱”补上一套组织肌肉。
AI 编程现在就是云计算的 2010 年。
agentic coding 工具不再是补全几行代码就走，它会反复读文件、生成计划、调用模型、运行命令、出错重试、再读上下文。每一次跑都在啃 token。token 消费从个人订阅小钱，变成了团队级、组织级的开支。但大多数公司目前的治理水平，连云计算 2010 年都不如——因为云计算至少还有 instance ID、tag、归属组，AI agent 跑出来的 token 是谁的，谁也没回答好。
Orosz 呈现了两派分歧。
Let it rip 派：先放开让工程师充分使用，再测量产出和质量。担心过早控费会扼杀真正的效率跃迁。
Treasury 派：必须先建治理和上限。担心没有度量地放开会制造惊人浪费和扭曲激励。
这两派都不全对。但有一条共识值得承认：AI 编程的成本已经不是个人订阅级别的小问题，它是组织级别的财务议题。需要靠归属、可见性、异常检测、设默认模型、加 token caps 来管理。
这件事的 takeaway 是：AI 编程的成本曲线正在重演云计算的早期故事。过早控费会扼杀创新，过晚控费会引爆账单。正确答案不是选边，而是承认这是一个组织治理问题，提前建立 FinOps for AI 的能力。在工具公司还在卷模型之前先把家里的账本理清楚，是少数几件值得在 2026 年做的事情之一。
六、第六个概念：指标黑洞——错误指标会制造错误行为
我对生产力指标有一个长期的怀疑，这个怀疑在 AI 编程时代被进一步加深了。
Orosz 和 Kent Beck 曾经讨论过软件工程生产力指标的风险。核心论点是：一旦某个指标和金钱、地位、绩效绑定，人们就会游戏化它；越容易度量的东西，越可能不是最该优化的东西。这话在 AI 编程上来得特别快也特别狠。
Orosz 记录到一个现象，他叫 tokenmaxxing——当公司把“AI 用得多”当成先进性指标时，工程师就会最大化 token 消费。具体做法包括：故意运行 agent 来满足使用指标、把任务拆得更细以便切出更多 token、放着便宜模型不用而开高级模型、用昂贵工具做低价值活。Orosz 给出的判断很尖锐：tokenmaxxing 对 AI 厂商很好，对其他所有人都不好。
我把这种现象抽象为指标黑洞。
指标黑洞的形成机制很简单，但破坏力极强：
- 公司想推动 AI 转型；
- 公司选了最容易测量的指标（token、采纳率、PR 数量、AI 接受率、工具登录次数）；
- 这些指标被绑定到考核或战略汇报；
- 工程师为了在这些指标上好看而调整行为；
- 调整后的行为不再代表“AI 真的在帮组织赚钱”，而代表“AI 看起来在帮组织赚钱”；
- 公司继续用这些被污染的指标做决策；
- 决策错误，资源浪费，激励扭曲，但仪表盘上一切都很绿。
Orosz 和 Kent Beck 在那次讨论里把开发者工作拆成 effort、output、outcome、impact 四层。越靠前越容易量化，越靠后越接近真实价值。AI 编程的陷阱就是它显著增加 output（更多代码、更多 PR、更多 token），所以管理者容易误以为 impact 同步增加。但软件工程里，更多代码经常意味着更多维护负担。
那么有没有什么指标是值得追的？我从 Orosz 的材料里整理了一组互相制衡的方向：
| 维度 | 反映什么 | 注意 |
|---|---|---|
| 交付速度 | PR 周期、lead time、deploy frequency | 单看会牺牲质量 |
| 系统质量 | change failure rate、事故频次、回滚率 | 单看会阻碍探索 |
| 维护成本 | 代码审查时长、技术债趋势、可读性 | 难量化但必须看 |
| 开发者体验 | 认知负担、满意度、留存 | 主观但真实 |
| 业务结果 | 客户价值、收入、留存、NPS | 信号慢但最重要 |
这件事的 takeaway 是：评估 AI 编程不要寻找一个神奇数字，要建立一组互相制衡的指标。任何单一指标都会被游戏化，关键是组合。McKinsey 式的“努力和产出最容易测量，但 outcome 和 impact 才更接近真实价值”在 AI 时代变得更危险——因为 output 的虚假繁荣实在太容易制造了。
七、第七个概念：判断溢价——能力的相对价值正在重排
我现在要转到一个更宏观的层面：能力市场的重新定价。
Orosz 在 2026 年的文章里把工程师粗略分成三类：Builders、Shippers、Coasters——爱建系统的人、强烈交付驱动的人、维持现状的人。他的判断不是“AI 让所有人变强”，而是“AI 放大每种人原本的倾向”。Builders 用 AI 重构、补测试、清理技术债；Shippers 用 AI 把想法快速推向用户；Coasters 用 AI 制造“看起来完成了”的假象。
这个分法有点扎心，但它准。AI 不是公平的提升器，它是放大器。一个有判断力的工程师变得更有判断力，一个没有判断力的工程师变得更没判断力。
我把这种重新定价命名为判断溢价。
判断溢价的意思是：当代码生成的边际成本逼近零时，能力市场上原本被代码生产能力遮蔽的“判断类能力”会显著升值。包括：
- 把模糊需求变成清晰任务的能力
- 给 AI 提供足够上下文的能力
- 审查 AI 输出的能力
- 设计可验证边界的能力
- 识别 AI 幻觉和过拟合的能力
- 判断“这段代码是否值得存在”的能力
- 在大量 AI 候选方案中收敛的能力
- 控制成本和资源的能力
这些能力都有一个共同特征——它们要求一个有 stake 的人。AI 可以推理，但不需要为推理结果承担后果；人推理同时承担后果，这是判断溢价的根源。
Orosz 自己呈现的一个细节让我印象很深：在他 2026 年的调查中，staff+ 和 director+ 级别的人对 agentic 工具的热情非常高。这跟“AI 让初级工程师更受益”的常见叙事不太一样。但仔细想想很合理——越资深的工程师，越能把 AI 当作执行层杠杆。他们知道要问什么、哪里危险、怎样验证、哪些输出不能信。AI 对他们来说不是替代思考，而是把思考转成更快的实验和实现。
而对初级工程师，AI 是一把双刃剑。它可以解释陌生代码、生成样板、帮助调试，加速学习；但它也可能让人绕过最关键的成长环节——理解为什么这样写、哪里会坏、如何承担后果。Orosz 关注的“AI slop”现象，本质上是这种学习路径错乱的产物：更多代码被生成，但质量、可维护性、上下文理解未必同步提高。
判断溢价对个人的启示很直接：与其问“AI 会不会替代我”，不如问“我的能力组合有多少落在判断层”。落在判断层的越多，AI 越是你的杠杆；落在执行层的越多，AI 越是你的替代者。
这件事的 takeaway 是：能力市场正在被 AI 重新定价。代码生产能力贬值，判断类能力升值。这个再定价不是均匀的——它会把原本就在判断层的人推得更高，把原本困在执行层的人挤得更紧。AI 不让世界变公平，它让世界变锐利。
八、第八个概念：生产系统观——AI 编程是一场组织能力建设
到这里，我想把所有概念串成最后一个总图。
如果只能用一句话总结 Orosz 这几年的判断，我会这么说：AI 编程改变的不是某个工具，而是软件工程的整套生产系统。
这是一个生产系统的视角，不是一个工具视角。
工具视角的提问方式是：哪个工具最强？哪个模型最准？哪个 IDE 最快？这种提问当然有价值，但它解释不了为什么同样的工具在不同公司里能产生差距如此巨大的结果。
生产系统的视角不一样。它把 AI 编程拆成至少七个相互咬合的子系统：
| 子系统 | 关键问题 |
|---|---|
| 工具子系统 | 选什么工具、如何组合、如何对接现有工具链 |
| 上下文子系统 | 如何把代码库、文档、约定、风险沉淀成 AI 可用的上下文 |
| 验证子系统 | 测试、CI、审查机制如何升级以应对 AI 输出 |
| 成本子系统 | 预算归属、可见性、上限、异常检测 |
| 指标子系统 | 用哪组指标衡量 AI 真实价值，如何避免游戏化 |
| 人才子系统 | 招聘、培养、晋升标准如何随判断溢价调整 |
| 治理子系统 | 安全、合规、权限、责任如何在 AI 时代重新设计 |
每一个子系统都不是独立的。指标子系统失灵会污染成本子系统；上下文子系统薄弱会拖垮工具子系统；治理子系统缺位会让任何工具都跑不起来。
这就是为什么 Orosz 反复强调：“最大问题不是工具不够强，而是上下文、治理和激励”。在大公司语境里，工具能力的边际收益已经很小，组织能力的边际收益才是主要变量。
生产系统观对管理者最有用。它把“我们要不要采购 Cursor”这种简单问题，重新升级为“我们的生产系统准备好让 AI 进入了吗”。它把“工程师 AI 采纳率多少”这种 vanity metric，重新升级为“我们的子系统之间是否在咬合，还是在打架”。
它对工程师个人也有用。它告诉你，你最该投资的能力，不是某个具体工具的熟练度（那会很快被新工具替代），而是你在七个子系统里的覆盖度——你能不能既懂工具，也懂上下文，也懂验证，也懂成本，也懂指标，也懂治理。这种 T 型能力组合，是 AI 时代真正稀缺的。
这件事的 takeaway 是：AI 编程不是工具升级，是生产系统重构。看 AI 编程必须从工具视角升级到系统视角。任何停留在“哪个模型最强”层面的讨论，都会错过真正的故事。真正的赢家不是用了最强工具的公司，而是把整套生产系统都重新设计好的公司。
九、把八个概念合起来：AI 编程现实主义的认知地图
把上面八个概念合在一起，可以画出一张 AI 编程现实主义的认知地图：
1 | 心理价格翻转 → 行为模式改写 → 工作流被自动重排 |
这张图里没有“AI 会替代程序员”或“AI 改变一切”这种廉价的判断，因为这种判断没有解释力。它有的是一组分析维度，让你在面对任何具体问题时都能定位到合适的层次。
举例。当有人问“我们公司该不该买 Cursor”，你可以反问：你们的上下文工程做到第几层了？你们的指标子系统会不会污染采购决策？你们的成本治理能不能承受 agentic 工具的扩张？
当有人问“AI 会不会替代程序员”，你可以反问：哪种程序员？做哪种任务？在哪种代码库里？落在判断层还是执行层？
当有人问“我该不该让团队全员用 AI”，你可以反问：你的团队是 Builders 多还是 Coasters 多？你的指标子系统能区分真假使用吗？你打算用什么标准衡量 ROI？
这些反问不是在抬杠。它们是在把问题从“是非题”重新还原为“分析题”。AI 编程从来都不是是非题。任何把它压扁成是非题的人，要么在卖东西，要么在自欺。
十、写在最后：保留判断力本身就是一种修炼
我用这八个概念写完这篇文章，最想留下的不是任何一个具体结论，而是一种认知姿态。
AI 编程的浪潮是真的。它真的在改变工程师、团队、成本、度量和工具。Orosz 的调查数据从 75% 涨到 95%，Claude Code 在两年内冲到一线工具，agentic coding 已经不再是未来时态。这些事实没有争议。
但越是浪潮汹涌，越需要保留一点点判断力。
判断力的反面不是反对浪潮，是不被浪潮带着跑。当所有人都在喊“用 AI、用 AI、用 AI”，问一句“用 AI 干什么”是判断力。当所有人都在追“采纳率”，问一句“采纳之后呢”是判断力。当所有人都在比“token 消费”，问一句“消费换来了什么”是判断力。当所有人都在说“程序员要被替代了”，问一句“替代的是哪种程序员”是判断力。
Orosz 这几年做的事情，本质上就是在替整个行业保留这种判断力。他不是反对 AI，他是反对廉价的对 AI 的判断。他不否认浪潮，但他始终把浪潮拆回到具体的工程现场——在哪种任务上有用？在哪种代码库里失效？在哪种激励下被扭曲？在哪种治理下能跑通？
这种“拆回到现场”的能力，在 AI 时代会越来越稀缺。因为 AI 让“看起来有道理”的内容变得太便宜了——每个人都可以让 AI 帮自己写出一篇“AI 编程的十大趋势”。当看起来有道理的内容泛滥，真正稀缺的反而是看穿这些内容、回到事实、回到任务、回到组织、回到现场的能力。
这种能力没法外包给 AI。它需要一个有限的、会承担后果的、长期身处现场的人来生长。
所以 AI 编程现实主义，最后落到的不是某个工具选择，也不是某个组织架构，而是一种个人姿态：在所有人都在加速时，留出一点不加速的时间。在所有人都在生成时，留出一点不生成的判断。在所有人都在追指标时，留出一点不被指标定义的自我。
这不是反技术，也不是矫情。它只是承认一件事——当生成变得便宜、判断变得昂贵时，最值得投资的不是更多 token，而是更清醒的自己。
这件事的 takeaway 是：AI 编程的最高级用法不是把更多事交给 AI，而是搞清楚什么事必须自己来。前者是采购，后者是修炼。前者会被时代淘汰，后者才会留下你。
而 Gergely Orosz 这几年在做的事，就是用工程现场的细节，反复提醒整个行业一件可能很基本但很容易被忘记的事：在浪潮里保持清醒，本身就是一种工程能力。
可能也是 AI 时代里，最被低估的那一种。