工程领导力的新“Token”规则

Chainguard 联合创始人兼首席执行官 Dan Lorenc 正在公司内部为 AI 采用建立新的规范。我们都已看到 AI 采用带来的初步成果，但这些成果并不均衡。我们认为这是一个值得他人借鉴的有用框架，因此征得 Dan 同意后，将其公开分享。 

简而言之，他们如今要求工程经理在其直接下属中的 token 使用量处于第 50 百分位。如果过低，他们就缺乏推动管理和成果进展所需的背景与语境；如果过高，他们则需要把重点放在指导培养以及 AI 工具的扩散应用上。

感谢 Dan 分享这些见解，因为所有公司都在这个新世界中摸索前行。

———- 转发消息 ———
发件人：Dan Lorenc
日期：2026年4月20日，星期一
主题：工程领导力的一项新 Token 规则
收件人：Chainguard 团队及董事会

大家好，

我们已经从 AI 工具中看到了切实成效，但这种成效并不均衡。有些团队和个人获得了巨大的杠杆效应；另一些人则几乎没有真正使用这些工具。缩小这一差距，是我们领导团队当前最具杠杆效应的事情之一。随着时间推移，这个问题或许会自行缓解，但我们等不起。

这是当下全球每家公司都在试图解决的问题。我们的做法是，为工程领导层设定一项新的预期：每一位工程负责人，其 Claude Code 代币使用量都应大致处于其直接下属中的第 50 百分位附近。这是一个大致指导原则，不是精确目标。处在第 45 百分位比第 70 百分位更好；第 55 百分位也比第 30 百分位更好。在其他条件相同的情况下，我宁愿领导者用得偏多，也不愿偏少。唯一绝对不能出现的位置，就是零使用。

这要从我、Dustin 和 Matt 开始。上个月，我们的使用量位居前列。我们不希望通过放慢自己来解决这个问题——我们希望通过帮助其他人迎头赶上来解决。这份备忘录，就是其中一步。

为什么是第50百分位？

我们知道，这意味着对预期作出一次重大调整。但我们现在必须这样做。

明显低于第50百分位的领导者，对这些工具所能实现的效果缺乏足够的一手经验。他们无法准确界定工作范围，无法设定切合实际的预期，也无法就这些工具为团队提供指导。他们正在领导一场自己尚未亲身经历的转型。

明显高于这一水平的领导者则面临另一类问题。他们已经触及能力边界，但他们的团队还没有。领导者的职责不是成为“重度用户”，而是成为“放大器”。那些远远走在前面的领导者，应把这份精力用于赋能团队，而不是亲自上阵。

处于中间水平，意味着你了解这些工具能做什么，你的团队也同样了解。

这适用于各个领域。工程团队只是我们的起点。

这一要求适用于整个公司。各层级的每一位管理者，都应对其团队使用的工具具备真实的上手经验。工程团队是当前最紧迫的领域，也是我们如今能够进行衡量的地方。Andrea Klemm 正在制定一项计划，帮助其他职能团队尽快启动——如果你有兴趣参与，请联系她！

问责机制

我们的核心价值观之一是“我们彼此信任，并始终假定对方出于善意”。任何指标都可能被钻空子，这一项也不例外。我们相信你和你的团队不会让这种情况发生。每位经理都应对其团队使用情况的真实性负责。

我们如何衡量

我们不会公布全公司的排行榜，但每个月，经理都会收到一份报告，显示其在直属下属的 Claude Code token 使用量中处于什么位置。经理的经理也将看到其下属的同类视图。这是一种相当粗略的衡量方式，我们对此心知肚明。我们会随着时间推移不断改进这一衡量方法，但不会为了等待一个完美的指标而迟迟不设定预期。

成本

我们正在密切关注这一点。我们上个月的 Claude 账单仅占云支出的一小部分，而且我们也在积极优化与供应商的协议。我们不会以任何方式限制工程团队的使用。现在，大多数 token 都不会直接进入产品，这没关系——每个人都必须支付“学费”来学会使用这些工具。落后的代价远高于 token 的成本。

这不是什么

这并不完美，我们也不会对个别百分点进行事无巨细的管理。我们希望这些数据是对话的起点，而不是终点。如果你持续在任一方向上明显偏离，我们就来谈谈原因。

我现在该怎么做？

如果你远低于上个月的水平，也不用担心——这是一个新的要求，我们不会就上个月的情况追究你的责任。联系我，我们会帮助你开始上手。

如果你不确定该从哪里开始，也别想得太复杂。把你一直搁置的某个想法构建出来。从你团队积压任务列表的末尾挑一项，直接试试看。把你团队本季度的一份设计文档或产品需求文档交给 Claude，看看它会怎么想。关键是先从某个地方开始。

如果你已经远远领先，那很好——就与你的同事或团队合作，向他们展示你的工作方式，帮助他们尽快跟上。这是一个共同目标，我们都会从中受益。

这并不是唯一的变化。

这项代币规则只是其中一步。我们还将在产品和工程规划流程中引入两项新要求。Patrick 和 Dustin 会分享更多细节，简而言之：

现在，每份产品文档都要有一个部分：“LLM 对这份文档有什么看法？”把文档内容贴进去，看看返回了什么，并把结果写进文档。

现在，每份工程设计文档都要有一个部分：“当你在这段代码的代码库中打开它并粘贴进去时，Claude Code 说了什么？”思路相同——让工具结合实际代码库的上下文审视你的方案，并告诉你它的看法。

如果你在请人审阅方案之前，还没有先用这些工具过一遍，那你就是把现成的简单杠杆白白留在桌面上。