夜雨聆风一位CTO 对外说"预算崩了"，这在行业里不多见。
2026 年 4 月，Uber 的 CTO Praveen Neppalli Naga 公开承认，公司在四个月内烧光了 2026 年全年的Token预算。5000 名工程师里，95% 已经用上了 Claude Code。
问题：每人每月 $500 到 $2000 的 API 费用，累加起来是个让 CFO 睡不着觉的数字。
CTO面对预算崩盘
这件事背后藏着 AI 编程工具正在浮出水面的三件事，每件都值得在决定"上车"之前先看清楚。
第一：成本不是线性增长，而是按用量堆上去的
传统软件采购有个特点：授权制。用户增加，总成本线性增长，但增长曲线是可预测的。
AI 编程工具不是这样。
它按量计费，用得越多，账单越高。更重要的是：使用量越大，单位成本越低，但总成本越高。
AI编码成本结构
这听起来矛盾，其实很简单。
Claude Code 这类工具的核心逻辑是"帮你省时间"。
工程师发现 AI 能帮他省 30 分钟，他就会毫不犹豫地用。
用一次省 30 分钟，用一百次就省 50 个小时。
但每一次"省 30 分钟"都对应着一次 API 调用，积累起来就是天文数字。
Uber 的案例很清楚：四个月，烧掉全年预算。
不是因为他们乱花钱，而是因为采用率从 32% 飙升到 95% 的速度，远超财务团队的预估能力。
教训是：AI 编程工具的成本结构，和你习惯的软件采购完全不同。
传统的"年初做预算、年终看执行"在这里失效了。
你需要一个动态的预算机制，按季度重估，设置硬性上限，超限自动告警。
第二件事：厂商锁定比想象中来得更快
当一家公司 95% 的工程师依赖同一个工具，这个工具的任何中断都直接等同于工程生产力归零。
有人说："Claude Code outages have already had entire teams at a stand-still."
传统软件时代，我们不会说"微软 Word 中断导致整个公司的文档工作中断"。
但 AI 编程工具不同，它深度嵌入工作流，中断的影响是全局性的。
Uber 的 CTO 说出那句话的背景，正是因为他们发现：
当预算崩了想换方案时，发现整个工程团队的工作流已经和 Claude Code 绑在一起了。切换成本比想象中高得多。
这不是说不要用 AI 编程工具，而是说从第一天起就要想清楚备份方案。
主力工具配一个低成本备选工具（如 DeepSeek），甚至考虑本地部署的开源方案（如 Hermes Agent）。
厂商锁定风险
这不是过度谨慎，这是工程风险管理的基本操作。
第三：省下的时间，可能在别的地方还回去了
AI 工具"让工程师做更少的工作，产出更多的代码"。这个在短期内完全成立。
但往往容易被忽视的问题：这些工具在提升生产力的同时，也在以看不见的方式提高周围系统的复杂度。
具体：
AI 生成代码的速度远超人工 review 速度，review 成为新的瓶颈 AI 生成的代码引入了隐含假设，这些假设在不同 run 中可能不一致 当 AI 错误传播到系统深处，修复成本指数级上升
还有一个问题：技能退化。
初级工程师用 AI 生成代码，但不理解底层逻辑。
AI 生成的代码成为"黑箱"，出了问题无法 debug。
长期来看，工程师的核心能力：系统思维、问题拆解，在退化。
vibecoding 社区的共识是：
Use AI for：boilerplate、文档、简单 refactor、测试生成；
Don't use AI for：核心业务逻辑、复杂 bug fix、需要深度系统理解的任务。
这不是拒绝 AI，而是有边界地使用 AI。
知道自己在哪里用、在哪里不用，才是真正重要的事。
懂问题，比懂工具更重要
Uber 的 CTO 说他"必须回到画图板重新规划"，这句话值得记住。
他不是第一个遇到这个问题的人，也不会是最后一个。
AI 编程工具的强大是真的，它的隐性代价也是真的。
真正的问题不在于"用不用 AI"，而在于用的人知不知道自己在做什么。知道代价在哪里，才能决定值不值得。知道工具的边界在哪里，才能用得更久。
这不是唱衰。这是：在决定把多少工作交给 AI 之前，先把问题的全貌看清楚。
领取2026·PDF-40页·Agentic Coding能力
参考
[1] Hacker News: Agentic Coding is a Trap
[2] Reddit r/artificial: Uber burned its entire 2026 AI coding budget
[3] The Information: Uber CTO Shows How Claude Code Can Blow Up AI Budgets
