别把 AI 编程当成更快的打字机
我承认，我对最近这一两年关于 AI 编程的讨论是有点烦的。
这个烦不是说讨论本身错。是讨论的姿势不对。一边是模型公司发布会上的 demo，一个十二岁小孩用一句话就让 AI 写出一个完整的 SaaS，全场鼓掌；另一边是公司里跑出来的“AI 使用率排行榜”，工程师为了不显得落后于战略，每天往 Claude Code 里塞 token，塞得键盘都冒烟。两边看上去走在不同的方向上，其实是同一个毛病——都把 AI 编程理解成了更快的打字机。
打字机这个比喻我得解释一下。打字机这东西的好处是写得快，坏处是它不会替你想该写什么。如果你本来就不知道要写什么，打字机只是让你更快地不知道写什么。如果你是抄写员，打字机让你更快地抄；如果你是写情书的，它让你更快地写情书；如果你是骗子，它让你更快地骗。打字机不挑活，它只是提速。
我的同行里有一个叫 Gergely Orosz 的人，他写过一个公众号叫 The Pragmatic Engineer，背后做过 Uber、Microsoft、Skype、Skyscanner。这个人有意思的地方在于，他既不是模型公司的，也不是测评博主，他是一个长期在工程组织内部看问题的人。他从 2023 年就开始追这件事，一直追到今年，留下了一串能让人冷静下来的观察。我读他的东西比较多，越读越觉得，他做的事情其实很朴素，就是把“AI 编程”这台漂亮的打字机搬下台，重新放回工程现场，看一看它在真实的水泥和螺丝面前到底干了些什么。
这篇就是借他的视角，说说这个过程里被忽略的那些事。
一、有些热闹是真热闹，有些热闹是热闹本身
Orosz 自己每年做调研，都会把工程师拉来问一句：你用 AI 吗？
数字是越来越漂亮的。2023 年他征集了一百七十多份反馈，工程师普遍说“挺有用”；2024 年大约 75% 的人在用；2025 年到了 85%；2026 年这个数字飙到了 95%，其中 75% 的人说一半以上的工作要用，56% 的人说七成以上的工作要用。Claude Code 几乎一夜之间冲到最受欢迎工具的前几名，Anthropic 的模型挤掉了不少老牌选手。
看这种数字看多了，第一反应是软件工程的天变了。第二反应是想想自己用没用，没用的话心里有点慌。第三反应才是问一句：这数字到底意味着什么？
我觉得有意思的是第三反应。
数字告诉你工程师在用 AI，但它没告诉你他们用 AI 干什么、用得怎么样、是因为有用而用还是因为不用就显得落后而用。这就好比一个数字说“今年有 95% 的家庭买了电饭煲”，你能据此推断出大家都吃上香喷喷的米饭吗？不能。这个数字也可能只意味着电饭煲卖得好，米饭可能照样夹生，照样烧糊，照样有人煮完一锅放冰箱里忘掉。
Orosz 自己很清楚这件事。他一边记下“使用率创新高”，一边在另一篇文章里冷冷地写：他在大公司工程师里听到的反馈是，公司给所有人配了 Cursor license，几个月之后大约一半人不再打开它。这两件事看起来矛盾，其实根本不矛盾。很多人用 AI，是因为公司发了；很多人不再用 AI，是因为发现自己手头那活儿用了反而更慢。这两种人加起来，凑成一个漂亮的数字。
在我看来，数字的真正用处不是证明结论，而是提醒人去问一个尴尬的问题：这群正在使用 AI 的人，里头有多少人是真的因为它好用？
二、AI 是把锯齿，不是磨刀石
Orosz 在 LinkedIn 上发过一段话，意思大致是这样：行业里关于 AI 编程的成功故事很多，但没什么人愿意承认它在大型成熟代码库里的效果远不如绿色草地项目。他从 Google、Meta、Microsoft 等大公司开发者那里听到的反馈是，在公司里二十年历史的核心服务上，AI 工具的价值往往小得多，很多人实际用法仍然停留在 autocomplete，而不是完整的 agentic 开发。
这话听上去像泼冷水。其实不是。它只是描述事实而已。
我自己的体验和 Orosz 描述的差不多。一个周末，我在自己的小项目里让 Claude Code 跑一通，半天写出一个能跑的小工具，那种感觉像捡到钱。第二天回到公司，让同一个工具去改一个 2014 年遗留下来的服务里的几行代码，结果它得先理解六层封装的内部框架，再揣摩一堆没有文档的隐式约定，最后给出一个看起来对、实际上把上下游打穿了的 patch。我花在解释上下文、修补它的副作用、给它打补丁的时间，比我自己写还多。
为什么会这样？因为 AI 的能力不是均匀的。它不是那种“在所有任务上稳定提升 30%”的工具。它更像一把锯齿——某些齿很锋利，某些齿是缺口，某些齿甚至会反过来割到你。
锋利的那些齿，对应的是边界清楚、上下文少、试错成本低的活：原型、脚本、迁移、跨语言翻译、样板、CRUD、测试骨架、文档生成。这些活的共同特点是“做错了影响小，做对了不需要太多内部知识”。AI 在这种活上像猛兽。
缺口的那些齿，对应的是上下文重、约定隐式、依赖纵深、错了代价大的活：成熟代码库里的核心模块、性能敏感路径、跨团队协作的接口、合规相关的逻辑、长期演进的架构。这种活的关键根本不是“写”，是“知道这家公司这十年来为什么这么写”。AI 看不见这个十年。
会反咬人的那些齿，更微妙——AI 给出一份漂亮的代码，看上去比你能写的还工整，但悄悄绕过了一个你内部约定好的抽象，或者重复实现了一个已经存在的工具方法，又或者引入了一个微小的语义偏差，要等到生产事故那天才看见。这种代码进入主干的瞬间，AI 没有副作用，是你团队下一个季度的维护成本。
理解这把锯齿的形状，比争论“AI 能不能替代程序员”重要得多。它解释了为什么两个工程师对 AI 编程的体验会差到完全相反的程度：一个人用 Cursor 周末做出小应用，觉得软件工程要完了；另一个人在二十年的核心服务里调一行配置，被 AI 折磨到怀疑人生。两边讲的都是真话。差别只是他们各自抓的是这把锯齿上的哪个齿。
三、Tokenmaxxing：刷量这件事，永远不会缺席
我读 Orosz 的材料里，最让我笑出声的是一个词，叫 tokenmaxxing。
意思很简单：当公司开始把“AI 用得多”当成先进性指标时，工程师就会开始最大化 token 消耗。
这事本身的可笑之处在于，它太可预见了。任何在中国的 IT 公司待过几年的人，对“指标一旦挂在 KPI 上立刻就被刷掉”这种事简直是有肌肉记忆。代码行数、提交数、bug 修复数、CR 通过率、加班时长、周报字数、群里活跃度——所有这些指标，只要被官方拿去当评估，第二天它就不再代表它原本想代表的东西。它代表的是：员工知道这玩意儿被用来评估自己。
token 不过是这条长长清单里的最新一员。
Orosz 记录到的细节非常生动。他采访了十五家公司的人，看到有些组织半年内 token 花费暴涨十倍，没有放缓迹象。有公司的工程师每天在 Claude Code 上花掉数百美元；有公司从原来每人每月两百美元的工具预算飙到每人数千美元；有公司的开发者为了“AI 使用指标”运行 agent，把任务拆得越细越好，反正切出来都是 token；有公司把 Claude 这种昂贵工具用在打杂活上——这就像让外科医生贴创可贴，贴一次比挂一次专家号还贵。
Orosz 给 tokenmaxxing 下的定义我特别欣赏，他大致这么说：这件事对 AI 厂商很好，对其他所有人都不好。
这话翻译成大白话就是：当你开始用 token 数衡量“你的公司有多 AI”时，你已经把自己变成了 AI 厂商最好的客户，不管他们的产品有没有真的让你赚到钱。
我得插一句私货。我对这种事情的厌恶不只是因为浪费钱，更因为它羞辱了一线工程师。一个工程师为了不显得落后于公司战略，开始故意运行 agent、故意拆细任务、故意放着便宜模型不用而开高级模型——这不是他想这样，是组织逼他这样。逼他用一种他自己都觉得很傻的方式来证明自己跟得上时代。这种事情发生过太多次了。每一次都让人恶心。
所以 Orosz 在这件事上的判断我觉得是非常宝贵的：错误的指标会制造错误的行为。当一个组织把“用了多少 AI”本身当成目标，它就一定会得到一群擅长把 AI 用得“看起来很多”的员工。但这个组织真正需要的，从来不是 AI 用得多，是事情做得对。
这两件事经常被混为一谈。混着混着，钱就烧光了。
四、我们正在重演一遍云计算早期的故事
我对 token 失控这件事的另一个直觉是：这一幕我们看过。
云计算早期，公司一窝蜂上云。理由都很漂亮——弹性、按需、降本、提速。然后过了几年，账单到了，发现钱烧得比 IDC 还猛。原因不在云本身，而在没人管。每个团队都能开实例，谁也没盯着关；每个项目都自己买带宽，谁也没归集；老板看不到全貌，工程师没有归属感，财务部门看着月底账单只会念阿弥陀佛。
后来才慢慢出现 FinOps 这个东西，开始做预算归属、成本可见性、资源治理、tagging、自动化关停。本质上是给“花钱”这件事补上一套组织肌肉。云本身没变，变的是治理。
AI 编程现在差不多就是云计算 2010 年的样子。
现在大家还沉浸在“按个人订阅几十美元/月”的旧叙事里，觉得 AI 工具就是那点小钱。但 agentic coding 一旦普及，账单的形状是会变的。一个 agent 不是补全几行代码就走的，它是反复读文件、生成计划、调用模型、运行命令、出错重试、再重试的。它每跑一次都在啃 token。token 不再是个人订阅这种“小钱”，它成了团队级、组织级、跟人头数和任务复杂度强相关的开支。
更要命的是，这种开支没有云计算那种现成的归属机制。云资源至少还有 instance ID，还有 tag，还有归属组。AI agent 跑出来的 token 是谁的？某个工程师的？某个团队的？某个产品的？某个 CI 流水线里偷偷调起来的某个工具的？大多数公司目前都没回答好这个问题。
Orosz 在这件事上呈现的两种声音都值得听。一派是“let it rip”，先放开让工程师用，再测量产出，再讨论控费——他们的担心是过早控费会扼杀真正的效率跃迁。另一派是必须先建治理，否则 token 会变成新的浪费中心——他们的担心是没有度量地放开会制造惊人的浪费和扭曲的激励。
这两派谁都不全对。但我觉得有一条共识他们都该承认：AI 编程的“账单”问题已经不是个人问题了，是组织问题。是要靠治理、归属、可见性、异常检测、设默认值、加上限这些“不性感”的东西去管的。
那些以为只要选对模型就能解决一切的人，会在某个季度末被财务请去聊一聊。
五、绿地公司可以飞，老房子里还得修管道
Orosz 写过一段我特别认同的判断，大意是：AI 编程的红利，对小团队和创业公司更友好，对大公司则要复杂得多。
为什么呢？小团队的代码库新、约定少、决策链短、合规约束轻、试错速度快。一个有判断力的工程师加 AI，在这种环境里像是给一个少年装了喷气背包——飞起来之前他什么都没有，飞起来之后他什么都不缺。这就是为什么我们能不断看到“两个人做出原本五十人才能做的产品”这种故事。这些故事真的不假，但它们大多发生在没有历史包袱的地方。
大公司的处境完全不一样。代码库是十几年前几百号人攒起来的，里头有一堆只在公司内部传授的隐式约定，有一堆早已离职的工程师留下的逻辑黑洞，有一堆 PII 数据访问限制，有一堆合规审查流程，有一堆和上下游团队互相承诺过的契约。这种环境下，让 AI 写代码不是“让 AI 写代码”这么简单，而是“让 AI 在一栋你不愿意拆又不敢乱动的老房子里加一根新管道”。
老房子有老房子的尊严。它今天还能跑、还能赚钱，本身就值得敬畏。乱拆的代价远远高于多盖一栋新楼的代价。
Orosz 记录的事实是：很多大公司在 AI 工具上反应慢，并不是因为它们笨，而是因为它们必须处理安全、合规、预算归属、供应商锁定、数据治理、采购流程这些“不性感”的东西。这些东西看起来拖慢了创新，其实是公司能持续存在的原因之一。
这件事对个人选择也是有启发的。对一个想最大化享受 AI 编程红利的人来说，去一家能让你飞起来的小公司可能比待在一家管道复杂的大公司更划算。但对一个真正想理解软件工程长期形态的人来说，老房子里发生的故事才更值得看。
因为长期来说，世界上大部分软件，都是老房子。
六、Senior 比 Junior 更兴奋，这事你想过没
Orosz 在 2026 年的调查里有一个很反直觉的发现：staff+ 和 director+ 级别的工程师，对 agentic 工具的热情非常高。Claude Code 这种东西在他们当中受欢迎的程度，超过很多人的预期。
这跟我们平时听到的“AI 让初级工程师更受益”的故事不太一样。
我想了很久这个反差。我觉得它其实挺合理的。
资深工程师之所以更兴奋，是因为他们最清楚自己被卡在哪里。他们清楚自己手里那些“早就该做但一直没时间做”的活——补一个测试矩阵、清理一段技术债、把某个内部工具升级到现代版本、给一个野生的脚本加上 README、把某个模块重构得不那么离谱。他们脑子里有一个长长的待办清单，每一条都是“我知道这事重要但今天还有更紧的事”。
AI 进来之后，这种工程师手里的杠杆突然变长了。他们知道要做什么、知道哪些是坑、知道怎么验证，AI 只是替他们把“动手”这一步做完。这是天作之合。一个有判断力的人，加上一个肯干粗活的执行层，加起来就是一台真正运转得起来的机器。
初级工程师就尴尬一点。他们手里没有那张待办清单，他们手里只有公司布置的任务。AI 给他们的不是杠杆，是替代品——替他们写代码，替他们查错，替他们解释。看上去他们获得了更多，实际上他们失去了一段最重要的成长机会。
我说这话不是想吓唬谁。我是想说：AI 对人的放大作用，是双向的。如果你有判断力，AI 让你更有判断力的人；如果你没有，AI 让你更没有。那些最容易被 AI 替代的人，恰恰是那些把“会写代码”当成自己唯一卖点的人。会写代码这件事，正在快速贬值。但“知道什么代码值得写、什么代码不值得”这件事，正在快速升值。
Orosz 在文章里把工程师粗略分成 Builders、Shippers、Coasters 三类——爱建系统的人、强烈交付驱动的人、维持现状的人——并认为 AI 会把每种人原本的倾向放大。Builders 用 AI 重构、补测试、清债；Shippers 用 AI 把想法快速推向用户；Coasters 用 AI 制造“看起来完成了”的假象。这个分法听起来有点扎心，但我觉得它准。
世界从来不是公平地把好处发给每个人的。世界只是把放大器接到每个人身上，让他原本的样子更明显一点。
七、写代码这件事，正在被重新定价
我自己写了二十多年代码。我一开始是觉得 AI 编程是个工具问题——选哪个工具、用什么 prompt、什么模型最好。但越往后越觉得，这事的真正变化不在工具，在身份。
写代码这件事，对一个工程师意味着什么？
它不只是产出。它是一种掌控感。你坐在屏幕前，世界乱糟糟的，但你这一片是你说了算的——光标在哪，函数怎么命名，这一行用 if 还是 switch，全凭你。你写的每一段代码都像一个微型协议：在这个范围内，世界按我说的办。这个掌控感，是工程师职业身份里非常底层的一块东西。
AI 拿走的，恰恰就是这种“我说了算”的那一段。它把代码生产从“我亲手做出来”变成“我审阅一份提案”。从产出者，变成裁决者。这是个很大的身份转变，比任何工资变化都要大。
Orosz 自己很坦白地写过这种感觉。他写到 2026 年初的某段时间，他发现新一代模型让他停止手写代码，因为让 Claude Code 写已经更快了。他既兴奋，也难受——兴奋是因为效率确实跳了一档，难受是因为他意识到一种自己曾经珍视的手艺正在被重新定义。这话我觉得说得很真诚。我也是这种感觉。
我不准备假装这种失落不存在。它存在。它真实。它对一个把代码当作自己人生一部分的工程师来说，是有重量的。
但我也不准备把这种失落浪漫化成“工匠精神被 AI 摧毁了”。坦白说，工匠精神不是手敲键盘，工匠精神是“对自己产出的东西负责到底”。一个工匠精神饱满的工程师，今天用 AI 写代码，但他愿意为最后那段代码的质量、风险、维护成本承担责任，他依然是一个工匠。一个工匠精神匮乏的工程师，就算他坚持每个字符都自己敲，他也不是工匠，他只是一个手感不错的打字员。
工匠精神在 AI 时代不死，只是它从“打字层”上移到“判断层”。从写每一行代码，转向定义问题、设计系统、审查质量、塑造产品、组织流程。code 这件事仍然在，只是它不再是工匠精神的唯一载体。
这件事对工程师个人来说有点冷酷，但也有点温柔。冷酷在于，那些只会写代码的人会越来越脆弱；温柔在于，那些懂系统、懂产品、懂取舍、懂质量、懂协作的人，会比任何一个时代都更值钱。
八、一个糟糕的问题：AI 会不会让程序员失业
Orosz 在这种问题上从来不直接回答。他更喜欢把问题拆开。
“会不会让程序员失业”这种问题，我觉得它和“汽车会不会让马车夫失业”是一样的。答案当然是会。但这个答案没什么用，它太粗了。它没告诉你具体哪种马车夫先失业，哪种工种从马车夫转成了出租车司机，哪种工种反而变得更稀缺（比如修车工、保险评估员）。
工程师这个职业内部，AI 影响是非常不均匀的。
有些任务会被吃掉：样板、CRUD、简单前端、迁移、脚本、跨语言翻译、文档、低风险小功能、原型、重复性重构、接口适配。这种活的共同特点是“上下文少、风险低、规则明确”，恰好踩在 AI 的舒适区上。
有些任务则会显著升值：复杂系统设计、模糊需求澄清、业务优先级判断、跨团队协调、生产事故处理、安全合规、长期架构演进、性能权衡、技术债治理、对“什么是好软件”的品味。这种活的共同特点是“上下文重、需要判断、需要承担后果”，AI 在这里只能当参谋。
所以问题不应该问“AI 会不会让程序员失业”，应该问“AI 让哪种程序员更脆弱、哪种更值钱”。
更脆弱的：把“写代码”当成自己唯一职业身份的那种人。一旦写代码这件事的边际成本降到接近零，他们就失去了唯一的支撑。
更值钱的：把“写代码”当成众多技能之一、并且把判断、审查、设计、协作、产品理解放在更高位置的那种人。AI 对他们来说不是替代，是杠杆。
我觉得 Orosz 的真正贡献，是反复在不同的文章里、用不同的角度，把这个分化讲清楚。他没说“程序员要完了”，也没说“程序员要起飞了”。他说的是：程序员这个职业内部正在分层，分得比以前任何时候都厉害。
这是个让人有点不舒服但更接近真相的判断。
九、给管理者的几句不太礼貌的话
我对管理者群体一直有点意见，是因为他们最容易把 AI 编程这件事理解错。
管理者最容易犯的错是：把“AI 转型”当成一次采购。
他们觉得，给每个工程师配一个 license，再开几次“AI-first 战略宣讲会”，再在 KPI 里加一项 AI 使用率，事情就办完了。这种做法的失败是写在剧本里的。它失败不是因为 AI 不好用，而是因为这种姿势本身就把 AI 用废了。
Orosz 关于 tokenmaxxing 的报道已经把这种失败的轮廓画清楚了。一旦把“用了多少 AI”本身当成目标，工程师就会刷量；一旦把“生成了多少代码”当成生产力，团队就会制造更多代码；一旦把“AI 采纳率”当成绩效项，员工就会为了表演而使用。这些行为都是组织自作自受。它们不是工程师不诚实，是组织在用错误的方式问问题。
我对管理者的建议——虽然他们大概不会听——是把 AI 转型放回工程目标里。
不要问“我们用了多少 AI”，要问“客户价值是不是更快交付”。
不要问“AI 采纳率多少”，要问“缺陷率有没有改善”。
不要问“token 消耗是不是同行水平”，要问“长期维护成本是不是可控”。
不要问“工程师是不是都开了 Cursor”，要问“工程师是不是更满意自己的工作”。
这些问题听起来不性感，写不出朋友圈金句，没法在年度汇报里做成一张漂亮 slide。但它们是真问题。AI 编程是真的能在这些问题上有所作为，前提是你愿意承认你想要的是这些，而不是看起来像 AI-first。
还有一件事。管理者得承认 AI 编程让代码更快出现的同时，也让坏代码更快出现。METR 和 Cursor 自己的研究都呈现过一个让人不舒服的结果：在某些情况下，使用 AI 的开发者实际花费的时间反而更长。Orosz 在引用这种研究时不是用来否定 AI，他是用来提醒：学习曲线、提示成本、等待成本、审查成本、上下文不完整，全都是真成本。它们不会出现在工具仪表盘上，但它们会出现在你下个季度的事故复盘里。
如果你只看仪表盘，仪表盘永远是绿的。问题在仪表盘之外。
十、一些尾声
写到这里，我得承认，我对 AI 编程的态度并不像表面上那么悲观。
我对它持有的是一种“现实主义的谨慎乐观”。乐观的部分是真的：它确实让一些事情成为了可能，让一些瓶颈消失了，让一些人找到了新的杠杆。我自己也是这其中的获益者之一。
谨慎的部分也是真的：它制造了一批新的指标陷阱、新的成本黑洞、新的组织扭曲、新的错误激励。我看到太多公司在还没搞清楚怎么用之前，就先把“用没用”挂到了 KPI 上；看到太多工程师在还没建立判断力之前，就先把代码生成权交给了 AI；看到太多管理者在还没问对问题之前，就先把预算批了下去。
Orosz 这几年做的事情，其实是在反复提醒整个行业：别忙着兴奋。先停下来想清楚——你要的是什么、你怕的是什么、你打算把什么交出去、你打算自己守住什么。
这是工程现实主义。它不性感，不上头条，不会出现在融资 deck 的封面上。但它是少数几样在浪潮过去之后还能站得住的东西之一。
AI 编程是不是更快的打字机？我希望读到这里的人都已经能给出自己的答案。
它当然能让你打字打得更快。但如果你要的只是打字更快，那你大概率会在某一天发现，你打了一堆没有人需要读的字。打字机的悲剧从来不是它太慢，是它太快——快到让人来不及想清楚自己到底要写什么。
所以问题从来不是“AI 编程能不能让你更快”。问题是：当一切都变快之后，你打算用这些多出来的时间干什么。
如果答案是“想清楚一点点”，那么这场浪潮值得参与。
如果答案是“再多塞一点点 token”，那祝你好运。
毕竟，人这一辈子，能用来想清楚事情的时间本来就不多。AI 给你省下来的那点时间，最好别拿去刷指标。