2026年10月27日，亚马逊在其官方网站 aboutamazon.com 发布了一份面向全体软件工程师的备忘录，将 token 用量、AI 工具采用率、代码变更数等指标明确定性为「deeply flawed」——严重有缺陷的衡量方式。据 CNBC 同日报道，这份备忘录早在9月就已在亚马逊内部传阅，此次公开发布标志着这家全球最大的科技雇主之一，正式向整个行业亮出了它在 AI 时代工程绩效评估上的立场。

这份备忘录的核心主张可以浓缩为一句话：工程师应该被长期业务成果（long-term outcomes）衡量，而非 AI 使用量。亚马逊副总裁兼杰出工程师 Terk Terkowitz 在备忘录中写道：「We all need to embrace this change and take the time to learn, or we risk being left behind.」他认为 AI 对软件工程的改变比云计算时代更快、更根本。

但这份备忘录的意义远不止于工程管理。它是亚马逊从今年5月关停内部 token 排行榜以来，一系列内部纠偏动作的集大成者，也是科技行业从「拥抱 AI 使用量」向「衡量 AI 业务成果」转向的标志性事件。

从 KiroRank 到公开备忘录：一条从内部纠偏到行业表态的时间线

要理解这份备忘录的分量，需要回溯到2026年5月发生的事。

据 Business Insider 报道，亚马逊在5月关停了一个名为「KiroRank」的内部排行榜。这个排行榜由员工自行创建，追踪各团队和个人的 AI token 使用量，并据此排名。问题在于，排行榜激励了一种被称为「tokenmaxxing」的行为——员工为了攀升排名而执行大量并不解决实际问题的 AI 任务。

亚马逊高级副总裁 Dave Treadwell 在当时告诫员工：「Please don’t use AI just for the sake of using AI. Use AI to help you solve customer problems, to help you solve business problems, to innovate.」亚马逊发言人向 Business Insider 确认 KiroRank 已被「deprecated」（弃用），并称其「was never intended to promote the use of AI for usage’s sake」，只是一个员工非正式创建的追踪器。

从5月的内部纠偏到9月备忘录在内部传阅，再到10月27日正式公开发布，亚马逊用了大约5个月时间完成了从发现问题、内部讨论到形成系统性指导方针的全过程。这个节奏本身就传递了信息：亚马逊在 AI 工具的大规模部署中确实遇到了真实的管理困境，而且这个困境严重到需要以公开备忘录的形式向外界表态。

据 Business Insider 今年4月报道，亚马逊在关停 KiroRank 之前，其零售业务部门已在密切追踪工程师使用 AI 的情况，包括每月有多少工程师使用 AI、AI 工具嵌入工作流的频率、以及 AI 部署创造了什么结果。这些追踪本身并无问题，但当追踪指标变成了考核目标，行为扭曲就开始了。

备忘录的核心内容：「Deeply Flawed」指标与「Renaissance Developer」愿景

据 CNBC 10月27日报道，备忘录的核心判断是：token 用量、AI 工具采用率、代码变更或评审数量，作为衡量团队或组织 AI 使用情况的指标，是「deeply flawed」的。这些指标可能导致更高的成本和过多的复杂性。

但亚马逊并没有走向另一个极端——完全弃用这些指标。备忘录明确表示，token 用量和代码生成量应该「with care and judgment」——带着审慎和判断力——结合其他数据来使用。用 Terkowitz 在 Business Insider 报道中的表述：这些指标「can correlate with the outcomes it values」，即它们可以与亚马逊看重的成果相关联，但必须谨慎使用。更多的 token 使用可能推高成本，而对代码行数的关注可能制造不必要的复杂性。

备忘录提出的替代框架是：「We believe that it is best to measure, and be measured by, long-term outcomes.」——以长期成果来衡量，也被长期成果所衡量。

AWS 副总裁兼杰出工程师 Marc Brooker 在接受 CNBC 采访时给出了更具体的替代指标思路。他表示亚马逊已经在使用「feature velocity」来衡量 AI 如何提升工程师生产力。这个指标关注的是「how many launches are we doing, how many successful changes are we making in production」——我们发布了多少功能、在生产环境中做了多少成功的变更。

Brooker 对 CNBC 的表述清晰地勾勒出了亚马逊的思考框架：「Broadly, we think about this as a return on investment. If there is an important problem to solve for our customers, important problem to solve for our business, we’re going to invest tools, time, tokens, human effort, etc. into those.」他补充说：「What we don’t want to see is wasted effort where we are going and spending those tokens solving problems that don’t matter and sometimes it’s hard to know, so we do need to have some appetite for experimentation.」

这段话的关键在于「return on investment」这个框架。Token 消耗被重新定位为一种投入成本，与人力投入、时间投入并列，而非一个独立的产出指标。这是一个根本性的视角转换。

备忘录同时提出了「Renaissance Developer」（文艺复兴式开发者）的概念。据 Business Insider 10月27日报道，亚马逊将当前时代定义为「era of the Renaissance Developer」，即人类判断力与机器智能结合来更快、更高效地创造新产品和服务的时代。Terkowitz 在备忘录中写道：「This is a time of change for our industry, and a time of change for what it means to be a software engineer.」

这个概念的实质是重新定义工程师的核心能力。在 AI 可以大量生成代码的时代，工程师的价值不再主要体现在编写代码的速度和数量上，而在于判断力——判断什么问题值得解决、AI 生成的方案是否正确、系统架构是否合理。备忘录对工程管理者也提出了明确要求：据 Business Insider 报道，领导者应该亲自在生产工作中使用 AI 工具，了解 AI 在哪些地方有帮助、在哪些地方不足，并向团队解释这种判断。

备忘录中一个被广泛引用的表述是关于 AI 工具不适用场景的处理方式：「If your work does not benefit from current AI tooling, that is a finding, not a failing.」——如果你的工作目前无法从 AI 工具中受益，这是一个发现，不是一个缺陷。备忘录进一步指出：「An engineer who can explain where AI does not yet help their work is demonstrating the judgement we are asking for.」能够解释 AI 在哪些地方尚无法帮助自己工作的工程师，恰恰在展示亚马逊所要求的判断力。

Terkowitz 还建议管理者特别关注 AI 采用光谱两端的团队：底部10%——理解他们为什么没有有效使用 AI；以及顶部10%——判断更高的使用量是否真正转化为更快的交付。据 Business Insider 报道，他表示亚马逊最前沿的「frontier teams」已经展现出更强的生产力和交付能力，而未采用 AI 或未提升产出指标的团队和个人正在落后。

Goodhart 定律的 AI 版本：当 KPI 扭曲行为

亚马逊 KiroRank 排行榜的兴衰是 Goodhart 定律在 AI 工具采用中的经典案例。这条经济学定律的通俗表述是：一个指标一旦成为目标，就不再是一个好指标。

回溯5月的事件，问题的根源在于：token 使用量是一个极易量化、极易追踪、极易排名的指标。在大型组织中，可量化的指标天然具有管理吸引力——它们可以被放进仪表盘、生成报告、用于绩效评估。KiroRank 排行榜的出现几乎是必然的：当组织鼓励 AI 采用，而 token 使用量恰好是最容易追踪的代理指标时，围绕它建立排名体系只是时间问题。

但 token 使用量与业务价值之间的关系是非线性的，甚至可能是负相关的。一个工程师可能通过精心设计的 prompt 用少量 token 解决了一个关键的客户问题；另一个工程师可能通过反复让 AI 生成和重写代码消耗了大量 token，最终产出的代码质量堪忧。在 KiroRank 的排名逻辑下，后者的「绩效」优于前者。

亚马逊发言人在5月的声明中试图将 KiroRank 定性为一个非正式的、员工自发创建的工具，但据 Business Insider 10月27日报道，亚马逊确实在组织层面追踪了工程师的 AI 使用情况，一些团队使用了与 token 消耗等指标挂钩的排行榜。这表明 KiroRank 虽然可能不是官方产品，但它所反映的管理倾向在组织中是真实存在的。

代码变更数（code changes）同样存在类似的扭曲风险。在传统软件工程中，代码行数早已被证明是一个糟糕的生产力指标——最优秀的工程师往往通过删除代码来改善系统。AI 时代的代码变更数面临同样的问题，而且被放大了：AI 工具可以在极短时间内生成大量代码变更，但这些变更是否改善了系统、是否解决了客户问题、是否引入了新的技术债务，都需要人类判断力来评估。

亚马逊备忘录中「deeply flawed」的定性，以及「with care and judgment」的使用建议，实际上承认了一个管理难题：这些指标不能完全弃用，因为它们确实携带了某些信息（Terkowitz 也承认它们「can correlate with」有价值的成果），但它们绝不能成为考核目标。这个区分在实际管理中极难操作——当一个指标被追踪和报告时，它就天然倾向于成为目标，无论管理层如何强调「仅供参考」。

笔者判断，亚马逊最终可能需要建立一套更复杂的多维评估体系，将 token 使用量降格为成本监控指标（类似于追踪云计算支出），而将 feature velocity、客户满意度变化、系统可靠性等指标提升为核心绩效维度。这个转变的难度在于：后者的衡量周期更长、归因更复杂、跨团队对比更困难，对管理者的判断力要求远高于简单的排名表。

行业困境：AI 成本飙升与 ROI 衡量的系统性挑战

亚马逊的备忘录并非孤立事件。据 CNBC 10月27日报道，大公司正从自由放任的 AI 支出文化中转向，面临 AI 预算膨胀但回报难以量化的挑战。据 Business Insider 5月报道，这种转向是「the latest sign that big companies are pivoting from a culture of free-wheeling AI spending amid concerns about ballooning AI budgets that lack the returns to justify them」。

Tokenmaxxing 这个现象正在失去市场。Business Insider 5月报道中提到，Uber 首席运营官 Andrew Macdonald 表示，这家网约车巨头的 AI 支出增加并没有带来相应的生产力和其他收益。这番话的背景是 Uber 首席技术官 Praveen Neppalli Naga 此前因透露公司到4月份就已用完全年的 Claude Code 预算而引发广泛关注。

据 CNBC 报道，一些公司已经开始对员工的 token 使用设置上限，以遏制不断上升的 AI 账单；另一些公司则转向使用更便宜的开源模型来处理特定任务。亚马逊发言人则表示公司没有设置 token 使用上限——这意味着亚马逊选择了通过文化引导和绩效框架调整来管理 AI 成本，而非简单的行政限制。

2026年 token 使用量的急剧上升有其技术背景。据 Business Insider 报道，token 使用量在2026年大幅增长，部分原因是 agentic AI（智能体 AI）的兴起——这种 AI 允许代理以最少的人类干预运行，有时可以连续运行数小时。这意味着 AI 成本的增长不仅仅是因为更多人在使用 AI，还因为每次使用的深度和持续时间都在增加。

在这个背景下，feature velocity 作为替代指标的吸引力就更容易理解了。Marc Brooker 对 CNBC 描述的这个指标——关注功能发布数量和生产环境中的成功变更——试图直接衡量工程组织的产出，而非投入。但 feature velocity 本身也有局限性：它可能鼓励团队追求大量小功能的快速发布，而忽视需要长期投入的架构改进或技术债务清理。

笔者认为，更合理的衡量框架可能需要分层设计：

第一层是成本监控层，追踪 token 使用量、AI 工具调用频率等投入指标，但仅用于成本管理和异常检测，不与个人或团队绩效挂钩。这类似于企业追踪云计算支出——你需要知道钱花在了哪里，但不会因为一个团队的 AWS 账单更高就认为他们更有生产力。

第二层是产出衡量层，使用 feature velocity、交付周期、部署频率等指标来衡量工程组织的产出速度和质量。这些指标与 DORA（DevOps Research and Assessment）指标体系有天然的亲和力。

第三层是成果衡量层，追踪客户满意度变化、业务指标改善、系统可靠性等长期成果。这正是亚马逊备忘录中「long-term outcomes」所指向的层面。

这三层之间的关系是：第一层的投入应该转化为第二层的产出，第二层的产出应该转化为第三层的成果。AI 的 ROI 最终体现在第一层投入与第三层成果之间的比率上。

据 CNBC 报道，亚马逊 CEO Andy Jassy 此前曾预测 AI 将「change the scope and speed」日常工作，并可能在未来几年通过自动化缩减企业员工规模，尽管他也指出这将同时创造「other jobs」。这个表态为备忘录提供了更宏观的组织背景：当 AI 可能改变工程团队的规模和结构时，如何衡量留下来的工程师的价值，就变成了一个更加紧迫的问题。

Feature Velocity 的优势与盲区

Marc Brooker 向 CNBC 介绍的 feature velocity 指标值得更深入的分析。这个指标的核心优势在于它衡量的是可观察的业务产出——功能发布和生产环境变更——而非投入。它与软件工程领域已有的 DORA 指标体系（部署频率、变更前置时间、变更失败率、服务恢复时间）有天然的衔接点。

但 feature velocity 作为核心指标也存在几个需要注意的盲区。

首先是质量维度的缺失。一个团队可以通过发布大量低质量的功能来提升 feature velocity，就像工程师可以通过 tokenmaxxing 来提升 token 使用量一样。如果不配合变更失败率、回滚率、客户反馈等质量指标，feature velocity 可能重蹈覆辙。

其次是不同工作类型的可比性问题。基础设施团队、安全团队、平台团队的工作产出很难用「功能发布数量」来衡量。一个花了3个月重构核心数据库的团队，其 feature velocity 可能远低于一个快速迭代前端功能的团队，但前者的业务影响可能更大。

第三是 AI 辅助下的指标通胀。当 AI 工具可以加速代码生成时，feature velocity 可能自然上升，但这并不一定意味着工程组织的能力在提升——可能只是同样的工作用了更少的时间完成。如何区分「AI 带来的效率提升」和「AI 带来的指标通胀」，是一个尚未解决的问题。

Brooker 对 CNBC 的表述中有一个关键的限定词：「we do need to have some appetite for experimentation」。这暗示亚马逊自身也承认，在 AI 工具快速演进的当下，没有任何单一指标体系能够完美衡量工程生产力。备忘录选择提供原则性指导（以长期成果为导向）而非详细的指标清单，可能正是出于这个考虑。据 Business Insider 报道，备忘录的设计意图是避免制定一份可能很快过时的详细 AI 操作手册（「detailed AI playbook that could quickly become obsolete」），而是聚焦于对客户和业务的长期影响。

人机协作的绩效体系：组织设计的新挑战

亚马逊备忘录中「Renaissance Developer」的概念，以及对管理者亲自使用 AI 工具的要求，指向了一个更深层的组织设计问题：当 AI 成为工程师的核心协作伙伴时，绩效体系需要从「衡量个人产出」转向「衡量人机系统的产出」。

传统的软件工程绩效评估通常基于几个维度：代码质量、技术设计能力、项目交付、团队协作、技术影响力。AI 工具的介入使得这些维度中的一部分变得模糊。当一段代码是由工程师与 AI 协作完成的，如何评估工程师的个人贡献？当 AI 可以在几分钟内生成一个技术设计方案的初稿，工程师的价值是否转移到了评审和改进方案的能力上？

备忘录对这个问题给出了一个方向性的回答：工程师的核心价值在于判断力。Terkowitz 建议管理者关注 AI 采用光谱两端的团队，这个建议本身就体现了一种新的绩效评估思路——重要的不是你用了多少 AI，而是你是否在正确的场景下、以正确的方式使用了 AI。

备忘录中对「AI 不适用场景」的处理方式尤其值得注意。「If your work does not benefit from current AI tooling, that is a finding, not a failing」这句话，为那些工作内容尚未被 AI 工具有效覆盖的工程师提供了保护。但它也提出了一个要求：工程师需要能够清晰地解释为什么 AI 在自己的工作中不适用，并与同事和管理者分享这些发现。换言之，即使不使用 AI，工程师也需要展示对 AI 能力边界的理解。

笔者判断，这种「判断力优先」的绩效框架在实际落地时会面临几个挑战。首先，判断力比 token 使用量难以量化得多，这增加了绩效评估的主观性和管理者的工作量。其次，在一个拥有数万名工程师的组织中，如何确保不同管理者对「判断力」的评估标准一致，是一个巨大的校准问题。第三，当组织同时强调「AI will be at the center of software engineering practice」和「不使用 AI 不是缺陷」时，工程师可能面临矛盾的信号——尤其是当他们观察到那些大量使用 AI 的同事获得了更快的晋升时。

Terkowitz 提到的「frontier teams」展现出更强的生产力和交付能力，以及未采用 AI 的团队和个人正在落后，这些表述本身就传递了一个明确的信号：AI 采用不是可选的。备忘录的微妙之处在于，它试图在「必须拥抱 AI」和「不能被 AI 使用量绑架」之间找到平衡点。

备忘录的行业信号意义

亚马逊选择将这份备忘录从内部文件转为公开发布，这个决定本身就是一个信号。科技公司通常不会公开其内部工程管理指导方针——除非它们认为这样做有战略价值。

笔者认为这个战略价值至少包含三个层面。

第一，人才市场信号。在 AI 时代，优秀的软件工程师面临的一个核心焦虑是：我的价值是否正在被 AI 替代？亚马逊通过公开强调「判断力」和「Renaissance Developer」的概念，向人才市场传递了一个信息——在亚马逊，工程师不会被简化为 AI 工具的操作员。

第二，行业标准制定。当亚马逊这个体量的雇主公开宣布 token 使用量是「deeply flawed」的指标时，它实际上在为整个行业的 AI 绩效评估讨论设定议程。其他公司在设计自己的 AI 采用指标时，将不得不回应亚马逊提出的问题。

第三，AI 工具供应商关系。亚马逊作为 AWS 的运营者，同时也是 AI 工具的提供方和使用方。公开表态反对 tokenmaxxing，有助于将行业讨论从「谁用了更多 AI」转向「谁用 AI 创造了更多价值」——这对于 AI 工具供应商来说意味着，他们需要证明自己的工具能够提升业务成果，而非仅仅增加使用量。

备忘录中「We’re just seeing the beginning of AI’s effect on software engineering」这句话，也暗示了亚马逊对当前指导方针的临时性认知。在 AI 工具能力快速迭代的环境下，今天的「最佳实践」可能在6个月后就需要修订。亚马逊选择提供原则框架而非操作手册，可能是对这种不确定性的务实回应。

从「用了多少 AI」到「AI 帮你做成了什么」，这个转变听起来简单，执行起来极其困难。它要求企业放弃最容易量化的虚荣指标，转向更复杂、更模糊、更需要管理判断力的成果衡量。亚马逊的备忘录迈出了定义问题的第一步，但解决问题——设计出一套既能激励 AI 采用、又能防止行为扭曲、同时准确反映业务价值的绩效体系——仍然是一个开放的工程管理挑战。Brooker 对 CNBC 说的那句话或许最能概括当前的状态：「sometimes it’s hard to know, so we do need to have some appetite for experimentation.」

主题分类：劳动力变革

参考资料

  1. Amazon Shuts Down AI Leaderboard After Employee Tokenmaxxing — Business Insider, 2026-05-29
  2. Amazon tells software engineers what really matters — Renaissance Developer — Business Insider, 2026-10-27

  3. Amazon’s anti-tokenmaxxing memo says engineers should be judged by long-term outcomes — CNBC, 2026-10-27

  4. An update from Amazon engineering leadership on the role of the developer in the age of AI — 2026-10-27
  5. Goodhart’s law - Wikipedia — 2026-10-09
  6. Nobody brags about lines of code twice — 2026-10-18
  7. Amazon pushes AI use and closely tracks adoption, as some employees push back — 2026-04-27