Tokenmaxing 之后，谁在替谁思考？

画图临出秦川景，亲到长安有几人？ —— 元好问《论诗三十首·其十一》

最近我在公司做了一件吃力不讨好的事：给部分最贵的 AI 模型加上用量限制。

从今年一月开始，我们的 AWS Bedrock 开销一路上涨，每个月不是翻番，就是涨了 50% 以上。一个月用掉大几千刀的员工，多到一辆大巴都塞不下。就连产品经理 demo 一个工具，安装环节也是让 Fable 去读文档、执行安装。看到上个月的 AI 支出，我这个平时不关心财务的人也血压飙升。

限额系统上线第一周，哀鸿遍野。不少人一两天就几乎用完了整个月的 budget。我们只限制了 Fable、Opus、Astra、Sol 这些最贵的模型，其他模型没有加这层上限，但抱怨 Sonnet、Luna 不给力的声音还是此起彼伏。

其中一条 DM 尤其让我印象深刻。对方语气和谐，意思却很明确：你逼我用 Sonnet，影响了 marketing workflow，到时候 KPI 完不成，谁来负责？

我的第一反应是：真是活见久，难道半年前你就不会工作？

等情绪过去，我更想弄明白的是：为什么一种刚出现不久的工具，会这么快变成工作的必要条件？大家用 AI 完成了更多事情，对这些事情的理解有没有跟着增加？

从个人套餐到企业采购

我一直觉得，Claude Code、Codex 用两百刀级别的个人套餐占领程序员心智，是极其成功的商业动作。

对重度用户而言，这样的套餐能用出按 API 标价折算三五千刀的量。这不意味着厂商真的承担了同等数额的成本，也不意味着额度无限；它改变的是使用者做决定时的感受：只要还在额度之内，多试一次不需要再掏钱。

于是，探索几乎没有心理负担。读仓库、写脚本、装工具、调配置，都可以先交给最强的模型。一次没做好就再来一次，几个 Agent 一起跑也无妨。这种自由确实有价值：很多以前嫌麻烦而没有尝试的事情，现在可以动手了。

用久了，人也容易对价格变得迟钝。我们很快就学会了怎样让最强模型替自己工作，却未必认真想过哪些任务值得动用它。

回到公司，使用体验可以很相似，支付方式却完全不同。具体到我们，绝大多数 coding agent 使用走的是按量付费的 Bedrock。员工仍然像使用个人套餐一样，随意挥洒，公司却要为每一次调用付费。

所谓「羊毛出在猪身上」，在这里，企业就是那头猪。厂商未必从一开始就设计好了这条路径，但从我们的使用情况看，个人套餐确实影响了企业的采购。

这里最厉害的地方，是厂商进入了企业的采购决策，却不必先说服采购部门。开发者已经替它完成了试用、培训和工作流改造。等公司开始认真计算成本时，问题已经从「要不要买」变成了「为什么不让我们继续用」。

换模型的困难，也未必在数据迁移。人们按熟悉的模型编写提示词、拆分任务、搭建流程。很多原本需要说明的条件，因为它往往能猜中，就没有被写下来。换一个模型，这些省略的条件才暴露出来，原来的流程也就不再顺手。等团队按这套流程承诺了交付时间，调整就更难了。

为什么大家都默认用最强模型

把开销失控全归结为员工大手大脚，是只知其一，不知其二。

假设我负责一个项目，公司考核我的上线时间，却不把模型费用算进我的决策。此时，选择最强模型相当合理：哪怕它只是略微提高成功率，也值得试。费用由公共预算承担，延期却会直接影响我的评价。换便宜模型是在替公司节约，失败则可能变成我个人的问题。

那条「谁来背 KPI」的 DM，除了让我不舒服，也暴露了这套激励：业务负责人担心交付受影响，基础设施负责人担心费用继续增长，双方都觉得对方没有理解自己的处境。只要没人同时考虑收益和成本，就很难讨论到底应该投入多少。

这也解释了为什么「大家自觉一点」很难奏效。愿意尝试便宜模型的人，要花时间调整流程，还可能需要解释进度为什么慢了；继续用最强模型的人反而容易按时交付。评价标准不变，节约就很难成为大家优先考虑的事。

不过，支出上涨本身仍然不能证明浪费。公司也可能在完成更多过去做不起的事情。要分清两者，就得知道增加的调用带来了什么：更多合格的交付、更短的等待，还是简单问题上的大量浪费。没有这层信息，放开额度和一刀切限额都只是在猜。

Agent 在忙，员工在干嘛？

Agent 让人能够投入极少的注意力，就调动大量资源。过去，自己亲自排查一个问题，忙了一小时没有进展，多少会停下来想想是不是方向不对。现在，一个含糊的任务可以让 Agent 自己读文件、试方案、重试半天。人只花了几秒钟发出指令，系统就开始持续工作。

能够把执行交出去，本来是好事。但过去那些费劲的步骤，有时也在迫使人思考：信息够不够？方向对不对？有没有更直接的办法？Agent 把执行变容易之后，人可以跳过这些问题，短期内还不太容易看出有什么不对。

设想一下，有人丢过去一句「帮我优化这个系统」。Agent 很快列出性能、架构、测试、可观测性等几个方向，逐项分析，开始改代码。整个过程井井有条。但系统到底出了什么问题，可能从头到尾没有人问过。一个模糊的念头，就这样变成了正在推进的项目。

强模型尤其容易让人忽略这一步。它很擅长把模糊的要求补成完整的方案，有理由、有步骤，还有对风险的讨论。人读完觉得通顺，便以为自己也想清楚了。可是，理解一段解释和有根据地接受它，中间还差着对事实和前提的检查。

我担心的是，人逐渐习惯只在模型提供的选项里挑选。它说该优化性能，人便开始比较几种缓存方案；它说需要重构，人便开始挑架构。方案依赖什么前提，这些前提是否成立，反而没有再讨论。

有时，换一个模型再问一遍也解决不了问题。两个模型如果都接受了同一个未经检查的前提，答案再接近，也不能证明这个前提成立。

独立思考在这里有很具体的含义：我得知道自己为什么接受这个建议，以及什么事实会让我改变主意。理由可以来自 AI，但我需要把它和实际情况对上。比如「系统慢」究竟发生在哪一步，影响多少用户，数据从哪里来；如果这些都不知道，就应该先调查，暂时不要让 Agent 开始大改。

遇到陌生领域，当然可以先让模型帮助理解，不必每次提问前都自己推导一遍答案。但在把建议变成行动之前，得确认自己有充分的理由照做。否则，Agent 忙了半天，我们还停在最初那个没有想清楚的问题上。

「离不开强模型」究竟意味着什么

九月，我开始给自己做过一个实验：除了复杂的 system design 用 Opus 5.5/Astra，其他事情一律用最便宜的 Luna 6。之前用其他模型完成的事情，我都完成了，没有遇到明显的 blocker。

自己的不少日常任务确实不需要最贵的模型。但「没有遇到 blocker」并不能说明总成本更低，更不能证明其他同事也该得到同样的结果。我对系统的熟悉程度、拆解任务的习惯，都影响着 Luna 能不能完成工作。

如果问题需要跨越很长的推理链，弱模型确实做不出来，那是能力差距。如果它缺的是背景、验收标准或者一个能观察结果的工具，那么升级模型可能暂时奏效，却没有修复工作流。还有一种情况：输出其实可用，只是使用者无法判断，于是只能选择一个更贵、更让自己安心的模型。

这几种情况，从表面上看都叫「便宜模型不给力」，处理方式却完全不同。

对于 marketing workflow 来说，内容不合格，可能是模型不擅长写，也可能是品牌要求从来没有明确过；客户分组不对，可能是推理出了错，也可能是输入数据没有包含必要字段；格式不稳定，可能只需要结构化输出和校验。找出具体哪一步失败，才知道该换更强的模型，还是该调整流程。

拿前沿科研和 marketing 比高低，也回答不了这个问题。一个任务听起来多么高深，不能决定它该花多少钱。看似普通的营销流程，如果影响大量客户，也可能值得很贵的模型；反过来，一个挂着前沿研究名号的机械整理任务，未必需要它。

模型预算应该跟着任务的价值、失败的代价和验证的难度走。

强模型还有一种容易被忽视的价值：它可以让缺少专业背景的人完成原本做不了的事。不能要求每个产品经理先成为工程师，再让 AI 安装工具。如果花一点模型费用就能省掉一次跨团队求助，这可能非常划算。

所以，模型好不好用，要放回具体的工作里看。笼统地说「非它不可」，既解释不了失败，也无法判断换一种做法能否解决问题。

做出来的东西，有人需要吗？

还有一种情况更容易被忽略：任务已经定义得很清楚，Agent 也执行得很好，但这件事本身不值得做。

这也是我越来越看重产品思维的原因。一个工程师不能只关心需求能不能实现，还得理解谁遇到了什么困难，为什么现有办法不够用，做完之后准备观察什么变化。即使这些问题通常由产品经理负责，接手实现的人也需要知道答案。否则，AI 提高的只是接受指令之后的执行速度。

还是拿 marketing workflow 举例。假设团队想做一个自动生成并发送营销内容的工具，Agent 很容易围绕这个要求展开：接入客户资料、做用户分组、生成不同版本、安排发送，再做一个 dashboard。每个功能都有道理，演示起来也很完整。

但团队真正遇到的困难，可能是销售不知道该优先联系哪些客户，也可能是内容审核太慢，还可能是根本没有找到客户愿意回应的话题。这几个问题需要的改进很不一样。把整套系统都做出来，也未必碰到最重要的那个。

此时值得做的，也许是拿少量真实客户资料，人工挑选一组对象，用 AI 辅助准备内容，实际试一次。先看看选人和内容有没有帮助，再决定哪些步骤值得自动化。如果这一小步没有效果，应该回头检查对客户的理解，而不是继续丰富 dashboard。

这件事在 AI 之前就成立。变化在于，以前实现很费力，团队还会因为人手不够而被迫排序、删需求。现在，一个新功能看起来只需要再发一条指令，做完又很有成就感，大家更容易一路加下去。

可用户仍然要花时间理解和使用这些功能，团队仍然要维护它们，其他工作也仍然在等待。生成得快，没有让这些后续负担一起消失。某个功能即使几乎不花钱就能做出来，也可能不值得留下。

对工程师来说，这意味着要更早参与判断。有时最有价值的工作是找用户聊清楚一件事，做一个足以验证想法的小实验，或者指出现有工具已经能满足需求。这样的贡献在提交记录里不显眼，却决定了后面的开发有没有意义。

什么时候值得继续

确定了事情值得尝试，还得决定投入多少、做到什么程度。模型的单价只是其中一个因素。

便宜模型反复失败，需要人盯着调试，可能比贵模型一次完成更贵。真正的任务成本包括模型调用、人的介入、等待，以及错误造成的返工和损失。只压低其中一项，其他几项可能涨得更多。

因此，我不认同「任何任务都必须先用最便宜的模型」。对已经知道很难、失败代价又很高的任务，直接用最强模型是正常的工程判断，没有必要先走一遍已知的弯路。

但「人的时间贵，所以一律用最强模型」也不充分。需要比较的是：多花的模型费用，究竟省下了多少人的时间，降低了多少失败风险。同样能完成的任务，贵模型如果没有带来相应改善，人的工资再高，也不能替这部分支出辩护。

任务开始以后，也得根据进展调整。Agent 已经重试了十轮，第十一轮还值得吗？如果它获得了新的日志、排除了一个假设，继续可能有价值；如果它只是用不同措辞重复同一种尝试，增加预算很可能只会延长失败。已经花出去的钱，不能成为继续调用的理由。

这里缺的往往是停止条件。让一个系统「尽量把事情做好」，它总能找到还可以再做的事情。交代任务时就应该说清楚，什么结果可以验收，出现什么情况需要停下来找人讨论。

当然，探索不能要求事先证明成功。未知问题本来就需要试错。合理的办法是给探索留预算，约定阶段性的检查点，再根据新得到的信息决定是否继续。一次失败如果排除了重要路线，仍然可能值得；十次漂亮的输出如果没有减少任何不确定性，也可能没有进展。

Tokenmaxing 最让我警惕的，是它容易把投入当成成绩。跑了多少 Agent、烧了多少 token，都很容易展示；究竟消除了什么问题，需要更费力地解释。一旦组织开始奖励前者，消耗就有了自行增长的理由。

当实现变快，团队会堵在别的地方

前两天和同事聊天，他说他们组可以砍掉一大半，留下三四个人加 AI，就能包打天下。

我理解这个感受。给人分配工作也是分配，给 AI 分配也是分配。如果同事接到任务后，只把我的原话扔给 AI，卡住再回来找我要思路，最后还得让我逐项验收，那么这个中间环节到底贡献了什么？

把任务交出去，本来是希望接手的人能够独立解决一部分问题。他可以使用任何工具，但交回来时，事实应该已经核实，含糊的地方应该已经澄清，只剩少数需要共同决定的取舍。如果每个困难都原封不动地返回，或者让 AI 决策，那么这个人的存在就失去了意义。

过去，实现本身是个坎，一个高难度的问题，优秀的人可以找到方案，平庸的人望洋兴叹。如今，所有员工都能在 AI 的加持下实现任何需求，却只有少量人真正理解业务约束，理解架构，能判断哪个方向是合理的，能指导 AI 写出更高质量的代码，能够把 AI 的产出真正上线。瓶颈从生产转移到了验收。继续提高生成速度，只会让待审查的东西堆得更高。

更糟的是，审查经常不算在生产者的成本里。一个人一天提交十个 PR，看上去比提交两个的人高产；但如果前者需要资深同事逐一重建上下文、识别错误假设、处理后续返工，他只是把工作转移到了别人那里。

一个人的产出增加，可以与整个团队的有效产出下降同时发生。

这就是为什么我对一些「高绩效」越来越不放心。生成越容易，用交付物数量衡量贡献就越容易失真。反过来，一个人否掉了错误方向，没有留下多少代码，却可能省掉整个团队几周的工作。

我把那些交付很多、却把核心判断都留给别人或者 AI 的人叫作新型的「混吃等死」。然而如果公司用 PR 数、任务数证明 AI 转型成效，却是在鼓励这种行为。我们一再向 manager 强调，PR 数、review 数、实验数量和成功次数，都要结合具体工作看，不能单凭一项指标评价员工。但不可否认，这些数字仍然影响着员工的选择。

方案是否合理，交付是否可靠，返工有没有减少，接手的人能否理解，这些更能说明一个人的贡献，却恰恰不好量化。管理者需要花时间看具体工作、了解协作中的困难。指标可以提供线索，却省不掉这部分判断。

工作完成了，自己学到了什么

我去年的 程序员的角色重塑 已经讨论过判断、澄清和责任。但这些能力不会因为一个人被要求「多思考」就自然长出来。它们需要在实际工作中反复练习，也需要知道自己哪里想错了。

过去，写代码附带着大量反馈。你以为接口是这样用的，运行结果告诉你不是；你以为某个边界不会出现，线上故障告诉你会。实现过程虽然慢，却迫使你不断修改自己对系统的认识。

AI 替人处理掉许多细节之后，学习就不再自动伴随交付发生。任务完成了，使用者可能只知道「这样问能得到结果」，却没有想过为什么成功、自己从中学到了什么。日积月累，交付了很多东西，对工作的理解却没增加多少。

所以，复盘需要更有意识地做。把对话记录扔给模型，生成一篇「经验总结」，看过一遍，并不等于学到了。模型很会把已经发生的过程解释得合情合理，但我们需要检查的，是当初为什么那么想，后来的证据又说明了什么。

我的一个方法是：在关键决定之前，留下自己当时的预期。无需正式文档，几句话就够。比如，怀疑接口超时是数据库慢查询造成的，就记下预计哪些请求应该受到影响、日志里会出现什么。有了这些记录，任务结束后才能比较自己原来怎么想、实际发生了什么，而不至于看完结果就觉得「我本来也是这么想的」。

假设 Agent 最后通过调整连接池缓解了超时，复盘就不能停在「问题解决了」。需要确认原来的判断是否成立，连接池为什么会耗尽，这次调整是在消除原因还是暂时缓解症状。否则，下次负载一变，自己很可能还会从头猜起。

成功也值得复盘。有些方案有效，是因为判断正确；有些只是碰巧没有遇到坏情况。如果测试没有覆盖某个边界，上线后暂时没出事，不能据此认为那个边界已经安全。分清这些，才能知道哪些经验可以复用，哪些还只是未经验证的猜测。

AI 完全可以参与这个过程。让它找出日志里不支持原判断的证据，构造会让方案失败的输入，或者分析另一种解释，都比让它再写一遍「本次项目的三点收获」更有帮助。但证据仍然要来自实际系统和用户。模型依据同一种理解生成实现和测试，两者一致，并不能排除需求一开始就被理解错了。

前面那个 marketing workflow 也是一样。生成了多少内容、自动发送了多少封邮件，只能说明流程在运转。真正值得回看的是：原来认为哪类客户会回应，实际是谁回应了，差异来自选人、内容还是时机？一次小范围尝试，如果改变了对客户的认识，下一次就能做出更有根据的选择。

并非每件小事都需要正式复盘。值得花时间的是那些出乎意料的结果、反复出现的失败，以及一旦判断错就会造成明显后果的决定。把修正后的认识写进测试、操作说明或者下一次实验里，学习才会真正影响后续工作。

如果一个员工用 AI 越久，就越依赖它替自己作判断，换个模型后连问题出在哪里都说不清，企业确实需要认真考虑：这个人还在为团队提供什么，保留这个职位的意义何在。仅仅把模型的输出转交出去，已经很难成为一份工作的充分理由。

拉闸只是开始

回到这次限额的行为。它能够暂时控制开销，却不能自动改善大家使用 AI 的方式。

如果给每个人一样的额度，用完就停，表面上公平，实际却忽略了任务差异，负责困难项目的人可能最先被卡住。也有些人既不调整做法，也不认真分析模型为什么失败，遇到难题就以额度不够为由退缩。限制开销如果只教会大家避免超支，甚至回避难题，就没有达到目的。后续还得把几件事做好。

首先，让使用者和负责人看得见消耗。一个任务大致花了多少，主要用在哪些步骤，长时间运行有没有获得新信息，都应该能查到。不同模型的价格不同，实际费用比 token 总数更有参考价值。日常小额使用不需要层层审批，否则省下的模型费用，很容易变成更多沟通成本。

其次，给昂贵任务和未知探索留下清楚的通道。重要项目可以有自己的预算，合理的失败可以被接受。超过预期时，讨论的是目前知道了什么、下一阶段值得投入多少。如果业务负责人判断贵模型不可或缺，就应该能把预期收益和费用放在一起讨论；基础设施团队也应该拿出限制的依据，接受这项限制可能需要调整。

还有，已经摸索清楚的事情，要留下来。复杂任务第一次值得用最强模型探索，成功后就应该整理出必要的背景、验证方法、脚本和交接说明。后来的同事才能接着做，不必每换一个人，就让最强模型重新调查一遍。

最后，管理者也要调整自己的预期。既要求员工全面拥抱 AI、显著提高产出，又把 AI 费用当成最好不存在的开销，这两件事无法长期同时成立。成本约束和交付目标必须一起谈。那条让我恼火的 DM，需要对方拿出工作流受影响的证据，也需要我们愿意根据证据修改预算或者目标。

我仍然愿意为强模型付很多钱。只要能解决重要的问题，该投入就投入。但如果大家只是指望模型包办一切，自己对问题的理解没有加深，工作方式也没有改进，就不能只想着再加预算。

AI 省下来的时间，我希望至少有一部分能用来接触用户、检查自己的假设、弄明白一次意外。事情可以交给 Agent 去做，做完以后，我们总该比开始的时候多懂一点。