加载失败
帖子围绕一则关于 Uber 的报道展开：The Information（科技媒体）称 Uber 在 4 个月内把 Claude Code（Anthropic 的终端式 agentic coding 工具）预算烧得很快，并声称大量工程师在使用 AI 工具，甚至有相当比例的提交代码与 AI 相关。评论区先质疑这篇文章的来源、统计口径和“花钱=产出价值”的推断，认为它把使用率、代码提交和业务收益混在了一起。随后讨论扩展到 Claude Max/Pro 订阅（Anthropic 的固定月费套餐）、API 计费、1M context window（单次上下文上限）、prefix caching（前缀缓存）以及多 agent 和多 worktree 工作流为什么会让 token 消耗迅速膨胀。因为 Uber 本身是全球规模很大的出行与配送平台，研发预算本就庞大，所以评论里也在争论这笔 AI spend 相对整体 R&D 到底是“小钱”还是“失控的信号”。
很多人解释高额账单不是单次问答，而是 Claude Code 这类 agentic CLI 在多轮循环里不断回传整个上下文、测试输出和错误栈。长对话不压缩、反复复用同一线程、同时开多个 worktree 或 subagent，会让每次请求都携带很长的前缀，哪怕有 caching 也会在 TTL 到期或刷新后继续付费。还有人提到把日志、Jupyter 输出、3D 帧、邮件全文直接喂给模型，token 消耗几乎没有上限。另一些人补充说，真正会把费用拉高的，是让 agent 在后台无人值守地反复修 bug、跑测试、再读回大段失败输出。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]
不少评论认为，问题不在 AI 本身，而在公司把 AI 使用率、token 消耗甚至 PR 数量变成了指标。只要上榜、拿奖、过考核和加薪都和“用得多”挂钩，工程师就会自然把最贵的模型、最长的循环、最夸张的 agent swarm 都开满。有人把这和 Goodhart's Law、PR/line counting、甚至人事管理里的音乐椅游戏类比，认为管理层根本无法阻止刷分。也有评论直接指出，指标一旦从“做出什么”变成“用了多少 AI”，预算爆炸就是必然结果。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]
最核心的质疑是：花出去的 token 到底换回了什么，更多收入、更多功能，还是只是把同样的工作换个更贵的做法？很多人坚持说，如果 AI 真有 5x 或 10x 的效果，外部表现应该早就能看出来，不会还停留在“预算超支”的新闻里。也有人提醒，开发成果和收入之间有滞后，生产率还涉及反事实比较、竞争对手追赶和 SRE 里的可用性投资，不能简单看当季账面。反方则反击说，工程师的总成本不止薪资，还包括福利、设备和 mentoring，所以拿 token 预算去跟 junior engineer 比，并不天然荒唐。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11]
另一派给出很具体的高效用法：先写 research.md 和 plan.md，再让多个 agent 并行研究、写代码、跑测试，最后人工只做选择和 review。有人在大仓库里同时开多个 agent、worktree 和 GitHub Actions，把开发周期压到以前的一小部分，自己反而成了 bottleneck。还有人把 Claude Code 当 IDE、pair programmer 或安全审查助手，用它做 reachability analysis、检测规则、日志处理和临时脚本。这个观点承认质量会参差不齐，但认为只要需求清晰、测试明确，AI 能显著减少机械劳动。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]
很多评论把高耗费归因于 codebase 本身：大型 monorepo、定制框架、复杂内部 API 和缺文档的系统，都迫使模型不断搜索、读文件、拼上下文。有人说团队甚至开始专门写“给 Claude 看的文档”，或者把文档做成 repo skill，这反过来也帮了人类自己。关于 microservices 是否能省 token，讨论很分裂：支持者觉得小服务更容易放进 context，反对者则说复杂度只是转移到 orchestration、集成测试和跨服务推理。也有人因此反而偏好 monorepo，认为它让依赖关系更透明，Git snapshot 也更适合 LLM 和人一起理解。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13]
不少人认为这里真正值得看的不是 Uber 花了多少，而是 Anthropic 的计费结构：个人 Pro/Max 订阅看起来很便宜，但背后可能是在补贴巨量 compute。企业一旦进入 Team/Enterprise，价格、credit、NDAs、审计和管理员可见性又完全是另一套逻辑，很多人担心规模一上来就会从“月费很香”跳成“API 账单爆炸”。评论里还提到 5 分钟和 1 小时 cache、prefix caching 和超长 context window 的计费细节，说明“看起来像固定月费”的使用体验并不等于真实成本低。也有人怀疑不同公司拿到的折扣和上限差异很大，所以表面上的单价未必能直接外推。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]
评论区对原文和转述都很不信任，指出文章几乎没有来源，引用链路也混乱，有些数字看起来像是把不同口径拼在一起。有人专门去核对 The Information 的原始报道，发现后续文章里出现的 $500-$2,000/engineer、70% AI 代码占比等说法并不清晰，甚至可能被二次加工。还有人按 Uber 的工程师规模和 R&D 预算倒推，觉得 AI spend 相对总研发费用并不算大，但“花了多少”并不能推出“赚了多少”。这让整条讨论持续回到同一个问题：如果没有明确的 outcome 和可复现的统计方法，任何高额预算数字都只能算刺激性的标题。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
tokenmaxxing: 刻意把 token 消耗拉高，把“多用 AI”当成目标或炫耀指标的行为。
context window: 模型单次可处理的上下文长度上限；越大，单次请求携带的信息越多，成本也更容易飙升。
prefix caching: 对重复提示前缀做缓存以降低成本，但仍会受 TTL、刷新和计费规则影响。
worktree: Git 的并行工作目录，可让多个 agent 或任务同时在不同分支上开发。
Goodhart's Law: 一旦某个指标变成目标，这个指标就容易被刷坏，失去原本代表性。
monorepo: 把多个相关项目放在同一个仓库里，便于统一理解，但上下文可能更大。
microservices: 把系统拆成多个小服务，降低单服务复杂度，但会增加跨服务协作和测试成本。