从指标压力到行为异化，Amazon 内部正在上演一场关于 AI 工具使用率的博弈。当管理层设定了 “80% 开发者每周使用 AI” 的硬性目标，并辅以 token 消耗排行榜进行追踪时，工程师们并没有选择提升真实产出效率，而是发展出了一套名为 “tokenmaxxing” 的应对策略 —— 用内部 AI 工具 MeshClaw 自动化那些本不必要的任务，以此拉高自己的 token 消耗数字。这种现象并非孤例，Meta 员工同样存在类似行为。它揭示的并非工具本身的失败，而是 KPI 设计失当如何系统性地扭曲技术采纳的价值。
为什么量化目标会催生 tokenmaxxing
理解 tokenmaxxing 的本质，需要回到指标设计的原始逻辑。当企业将 AI 采纳率设为强制目标时，实际上是在用线性指标衡量一项非线性价值创造活动。AI 工具的核心价值在于降低特定任务的边际成本、提升输出质量、缩短迭代周期 —— 这些收益本质上是情境依赖的，无法被一个固定的使用率数字所捕获。然而，一旦这个数字成为可追踪、可排名的绩效维度，员工的行为逻辑就发生了根本性转变：从 “工具能帮我完成什么” 转向 “工具能帮我达成什么指标”。
这种转变在组织行为学中有成熟的解释框架。目标设定理论（Goal Setting Theory）早已指出，当指标被赋予外在奖励或惩罚属性时，目标的达成行为会逐渐替代目标背后的原始目的。在 Amazon 的场景中，管理层宣称 token 统计数据不会纳入绩效评估，但员工观察到的事实是管理者确实在查看这些数据。这种认知落差 —— 即使没有正式关联，感知到的关联足以驱动行为调整 —— 使得 tokenmaxxing 成为理性个体在压力下的占优策略。
从博弈论视角看，这是一个典型的委托代理问题。委托方（公司）希望代理方（员工）提升 AI 使用率以证明基础设施投资回报；代理方在不完全信息下进行最优响应。最优响应不是提升真实使用价值，而是最大化可观测指标。当排行榜机制被引入后，竞争性动机进一步放大了这种倾向 —— 部分工程师将排名视为隐性竞赛，从而在真实需求之外主动创造 AI 使用场景。
MeshClaw 的技术能力与安全代价
Amazon 内部工具 MeshClaw 的设计本身并无原罪。它的核心功能是允许员工创建能够连接工作流软件、执行任务委托的 AI agents，具体能力包括代码部署触发、邮件分类、以及与 Slack 等应用的交互。MeshClaw 的设计理念借鉴了今年二月走红的开源工具 OpenClaw，后者允许用户在本地硬件上运行 agents。这套框架的潜力在于将重复性工作自动化，让工程师将注意力聚焦于需要判断力的任务。
然而，当工具被用于 tokenmaxxing 时，其安全模型受到了根本性挑战。多位 Amazon 员工表达了同一层担忧：MeshClaw 被授予了代用户行事的权限，这意味着 AI agent 可能在用户不知情的情况下执行错误操作或采取非预期行为。一位员工的话极具代表性：“默认的安全态势让我感到恐惧。我不会让它自行其是。” 这句话背后指向的是一个核心问题：当 AI agent 被鼓励最大化 token 消耗时，行为边界在哪里？谁为自动化决策的后果负责？
这些问题在工程实践中并无现成答案。AI agent 的自主性与安全性之间的张力本就是当前 MLOps 领域的前沿难题。MeshClaw 能够在用户会议期间监控部署、在用户醒来前完成邮件分类 —— 这些能力在设计上是高效的，但当它们被用于刷指标而非解决实际问题时就变成了风险敞口。任何允许 AI 系统代表用户采取行动的基础设施，都需要建立完善的权限隔离、操作审计和回滚机制，而这些安全措施在 “尽快推广、尽快采纳” 的压力下往往被优先级降级。
指标异化的工程系统性后果
Tokenmaxxing 带来的最深远影响，可能不是个别安全事件，而是对工程团队整体心智模型的系统性侵蚀。当 “使用 AI 工具” 本身成为目标时，工程师会逐渐形成一套隐性的行为准则：优先选择能被工具捕获的工作方式，而非最能解决业务问题的工作方式。这种优先级错位在短期内表现为 token 消耗数字的攀升，在中期内则会导致技术债务的隐性累积。
具体而言，当工程师习惯于用 AI 工具自动化一切可自动化的任务时，他们正在引入一种新型的技术债务：过度依赖性（Over-dependency）。代码部署、邮件分类、Slack 交互 —— 这些工作流原本需要人类判断的介入才能发现潜在问题。当 AI agent 以高吞吐量处理这些任务时，异常信号被淹没在自动化流中，真正的风险点反而更难被察觉。更重要的是，当工程师习惯于将决策权委托给 AI 时，他们的批判性思维能力会随时间衰减。这不是危言耸听 —— 重复性判断的自动化会系统性地剥夺工程师练习该技能的机会。
另一个系统性风险在于资源消耗的失控。Amazon 今年预计在资本支出上投入 2000 亿美元，其中绝大部分流向 AI 和数据中心基础设施。当 token 消耗成为目标而非手段时，这些投资被用于驱动毫无业务价值的计算活动。这不仅是财务上的浪费，更是一种环境层面的负外部性 —— 在碳中和压力日益增大的背景下，为刷指标而进行的无意义计算正在成为企业 ESG 报告中的暗角。
构建反 tokenmaxxing 的工程机制
面对指标异化的风险，企业需要的不是放弃 AI 采纳目标，而是重新设计指标体系与推行机制。首先，衡量 AI 工具价值的方式应该从 “使用量” 转向 “产出质量”。可操作的替代指标包括：任务完成时间的变化、代码审查问题率的趋势、自动化流程的错误率、以及最终的业务结果指标（如功能交付周期、客户问题解决时长）。这些指标比 token 消耗更难被游戏化，因为它们的提升依赖于真实的效率改进而非表面的使用频率。
其次，追踪机制需要从公开排行榜转向结果导向的团队评估。如果 token 消耗数据被公开排名，即使管理层声称它不与绩效挂钩，员工也会将其视为隐性信号。消除这种信号干扰的方法是将数据访问权限限定为个人和直接经理可见，并且将讨论焦点从 “我的 token 数是多少” 转向 “我的任务完成质量如何”。亚马逊最近已经开始限制 AI 使用统计的可见范围，这一调整方向正确，但执行的一致性至关重要。
第三，对于 AI agent 的安全模型，需要建立明确的操作边界与审批流程。MeshClaw 一类的工具如果要被安全地使用，必须配备以下机制：最小权限原则下的权限授予、关键操作的人工审批节点、自动化行为的回滚能力、以及异常行为的实时告警。这些安全措施不应被视为采纳速度的阻碍，而应被视为可持续使用的前提条件。
最后，组织文化层面需要重新定义 “成功使用 AI” 的含义。当工程师感到只有大量使用 AI 才能满足绩效预期时，说明组织内部的沟通存在根本性误解。高层需要明确传达：AI 工具是用来增强人类判断力的，而不是替代它的；使用 AI 的目的是解决问题，不是累积数字。做到这一点需要管理层以身作则 —— 如果高管自己的 token 消耗成为公开指标，那 tokenmaxxing 就不可能被根除。
技术采纳的本质回归
Tokenmaxxing 的出现是技术采纳过程中指标异化的又一案例。它的警示意义在于：当企业急于证明 AI 投资的回报时，容易陷入 “以可见指标替代真实价值” 的陷阱。Token 消耗是可量化的、可见的、排名友好的，但它与 AI 的真实价值贡献之间的关联往往脆弱。真正的价值体现在问题解决能力的提升、工程时间的解放、产品质量的改善 —— 这些成果无法被一张排行榜所捕获。
对于工程领导者而言，这意味着在推动 AI 工具采纳时，必须保持对 “手段” 与 “目的” 关系的清醒认识。工具是为目标服务的，而不是目标本身。当发现团队开始出现 tokenmaxxing 的迹象时，首要任务不是惩罚行为，而是审视指标设计本身是否出了问题。指标的优化永远无法替代价值的创造 —— 任何试图用数字游戏代替实际工作的尝试，最终都会以技术债务、信任损耗和组织内卷作为代价。
资料来源：Ars Technica 基于 Financial Times 报道（2026 年 5 月 12 日）。
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。