翻译：Transwan
改写：Carl Cui
最近几条新闻放在一起看，很有意思：Microsoft 开始收缩部分团队对 Claude Code 的使用，把工程师引回自家的 GitHub Copilot CLI；Uber 在 2025 年底向数千名工程师部署 Claude Code，结果四个月烧完了全年 AI 编程预算；Klarna 曾高调用 AI 替代大量客服，后来又重新招聘人工客服。
这 3 个故事很容易被解读成极端的版本：一种可能会说 AI 编程工具失败了，另一种可能会说这些公司只是暂时没做好成本管理。这两种说法都不准确，我觉得问题的本质其实是：AI 确实能加速一部分工作，但是很多企业把 AI 加速的这部分工作当成了全部工作。
Microsoft：好用，不代表可无限放大
Microsoft 是 AI 时代最激进的玩家之一，向 OpenAI 投入巨资，也深度推进自家的 AI 编程工具。但 Microsoft 内部很多工程师仍然偏好 Claude Code。工具好不好用，工程师的选择已经给出了答案。
问题不在于 Claude Code 没价值，而在于它在企业规模下太容易失控。一个工程师偶尔用 AI 写代码，和一个大型部门把 AI Agent 接进日常开发，是两种完全不同的成本结构。后者消耗的不是一个固定订阅费，而是持续增长的 token、上下文、工具调用和自动化尝试。
所以 Microsoft 的动作，与其说是“停止使用 AI”，不如说是企业终于开始重新思考：哪些 AI 工具值得用，在哪些场景里用，谁来付账，成本上限在哪里，数据和工作流又该留在谁的平台里。
这不是 AI 无用，而是 AI 进入企业主流程之后，凸显出预算、治理和平台控制权的重要性。
Uber：使用量不是价值
Uber 的数据看起来更像一场成功推广：工程师采用率很高，AI 参与的代码提交比例很高，Agentic AI 功能使用率也快速上涨。按很多公司的 AI KPI，这几乎可以写进成功案例。
但问题恰恰在这里。
更多使用，不等于更多价值。更多提交，也不等于更好的工程结果。Uber 高管承认，漂亮的使用数据和真实用户价值之间，并没有那么容易建立联系。
这其实是 AI 编程工具最容易制造的错觉。代码行数、提交次数、生成速度，这些都很好统计；但一个改动是否真的解决了正确的问题，是否降低了系统复杂度，是否减少了未来维护成本，是否让用户体验变好，就难得多。
工程师早就知道，代码数量不是工程价值。AI 只是让这个老问题变得更明显：如果组织用“产出更多代码”来衡量生产力，那么 AI 一定会让报表更好看，也可能让系统更难维护。
Klarna：AI 能处理流程，却不等于能处理工作
Klarna 的故事发生在客服领域，但对工程团队同样有启发。
它曾经用 AI 聊天机器人替代大量客服，并公开宣传 AI 能处理大部分客户互动。刚开始，这听起来很有效率：响应更快，成本更低，自动化率更高。
但后来问题出现了。标准问题确实可以被处理，复杂问题却开始堆积。客户满意度下降，回复变得模板化，需要判断力的场景没人兜底。最后，Klarna 又重新招聘人工客服。
这件事的重点不是“AI 客服失败了”，而是：AI 完成了它擅长的那部分工作，却暴露出公司低估了另一部分工作。
真实工作从来不只是流程。它还包括例外、上下文、判断、情绪、历史经验，以及知道什么时候标准答案不再适用。
工程工作也是一样。
真相是：企业误判了工程工作的构成
AI 编程工具最擅长的是清晰、局部、可验证的任务：写样板代码、补测试、解释函数、生成脚手架、做小范围重构、查 API 用法。这些任务当然有价值，也确实值得用 AI 加速。
但工程工作里还有另一类任务：判断要不要做，决定怎么做，理解系统为什么变成今天这样，识别需求里的模糊地带，评估改动对未来维护的影响，知道一个看似优雅的方案为什么三年前被团队放弃。
第二类工作更难展示，也更难量化。它不会在仪表盘上变成“本月新增多少行代码”。但它往往决定一个系统能不能长期活下去。
企业的问题，是太快把第一类任务的自动化，误读成了整个工程工作的自动化。
这就是 Microsoft、Uber、Klarna 三个故事共同指向的结构性问题：AI 擅长处理可定义的工作，但真实工作里最贵的部分，往往恰恰是那些难以定义、难以衡量、难以快速验证的部分。
工程师从中学到什么
这并不是一篇反 AI 的文章。相反，AI 编程工具会继续进入工程工作流，而且会越来越强。问题是，工程师不能把它当作判断力的替代品。
未来更有价值的工程师，不是不用 AI 的人，也不是把所有事情都交给 AI 的人，而是能分清任务类型的人：
- 哪些任务可以让 AI 快速生成；
- 哪些结果必须自己审查；
- 哪些上下文不能丢；
- 哪些设计决策不能外包；
- 哪些代码虽然能生成，但不应该进入系统。
后端工程师尤其要注意这一点。后端系统会积累历史，很多关键知识不在代码里，而在事故复盘、旧约束、未写下来的团队经验和长期演化路径里。AI 可以读代码，但它不一定知道为什么某个方案当年被否掉，也不知道某个服务背后承载了多少历史包袱。
如果你真正理解系统，AI 会放大你的能力。如果你不理解系统，AI 只会让你更快地产出自己也解释不清的东西。
结语
Microsoft 和 Uber 的问题，不是工程师用了 AI；Klarna 的问题，也不是自动化本身有罪。真正的问题是：组织过早把“AI 能完成一部分任务”理解成了“AI 能承担整份工作”。
AI 可以写代码，但工程价值从来不只是代码。它可以提高产出速度，却不能自动保证产出是正确的、有价值的、可维护的。它可以帮你执行，但不能替你承担判断。
未来最会用 AI 的团队，不会是那些放弃工程判断、依赖模型生成的团队，而是那些保留判断力，再用 AI 加速执行的团队。
AI 没有取代工程师。它只是让我们重新看清：工程师真正值钱的部分，原本一直不是打字速度。