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