去年有公司把员工的 Token 消耗量写进绩效考核，结果并没有自动带来生产力，反而催生了荒诞操作：有人让两个 Agent 互相聊天一整天，只为了把用量刷上去。这个现象被称为 tokenmaxxing：用行政指标逼团队“用 AI”，哪怕消耗本身没有任何业务意义。
更有意思的是，复盘者的判断不是“AI 没用”，而是“第一阶段的 tokenmaxxing 已经结束”。早期公司需要用粗糙指标推动试用，这是可以理解的；但当团队已经知道怎么调用模型、接入 Agent、购买 Copilot 或内部工具后，再用 Token 数量当目标，就会把组织带偏。
Token 曾经是好指标，但很快失效
在 AI 落地早期，Token 消耗量有一点价值：它至少说明员工真的打开了工具，团队真的在尝试把 LLM 放进工作流。对管理者来说，这比“大家要拥抱 AI”的口号更可观测。
问题在于，Token 是输入成本，不是产出结果。它只能回答“模型被调用了多少”，不能回答这些更关键的问题：
- 这次调用是否减少了人工时间？
- 生成内容是否被采纳、修改还是直接丢弃？
- Agent 是否完成了任务，还是在循环里自言自语？
- 成本是否低于节省下来的工程、运营或客服时间？
一旦 Token 被写进绩效，它就从观测指标变成了目标。Goodhart 定律会准时到场：当一个指标成为目标，它就不再是好指标。两个 Agent 互相聊天，就是这个逻辑的极端版本。
从“用了多少”转向“省了什么”
下一阶段的 AI 管理指标，应该更接近业务语言，而不是账单语言。Token 仍然要看，但它应该被放在成本侧，而不是成就侧。
可以考虑把指标拆成三层：
- 采用率：有多少人、多少流程实际接入了 AI。
- 任务完成率：AI 输出是否完成了明确任务，比如生成 PR 摘要、分类工单、补全测试。
- 单位收益：每 1 美元模型成本换来了多少分钟节省、多少缺陷减少、多少转化提升。
这不是说所有 AI 价值都能被精确量化。研发探索、写作草稿、调研启发有时很难立刻折算成钱。但至少可以避免把“消耗更多 Token”误认为“做得更先进”。
可以这样实践：记录一次 AI 调用的真实结果
下面是一个最小可改造的 Python 示例，用来记录每次 LLM 调用的成本、耗时和人工评价。它不假设某个具体公司的内部平台，只演示一种更健康的度量方式：把 Token 当成本，把任务结果当核心字段。
运行前需要：
pip install openai
export OPENAI_API_KEY="你的 API Key"
保存为 track_ai_task.py：
import csv
import os
import time
from datetime import datetime
from openai import OpenAI
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
MODEL = "gpt-4o-mini"
INPUT_PRICE_PER_1M = 0.15
OUTPUT_PRICE_PER_1M = 0.60
def estimate_cost(usage):
input_cost = usage.prompt_tokens / 1_000_000 * INPUT_PRICE_PER_1M
output_cost = usage.completion_tokens / 1_000_000 * OUTPUT_PRICE_PER_1M
return round(input_cost + output_cost, 6)
def run_task(task_name, prompt):
started = time.time()
response = client.chat.completions.create(
model=MODEL,
messages=[
{"role": "system", "content": "你是一个严谨的工程助手，回答要可执行。"},
{"role": "user", "content": prompt},
],
)
latency_ms = int((time.time() - started) * 1000)
text = response.choices[0].message.content
usage = response.usage
print("\n=== AI 输出 ===\n")
print(text)
accepted = input("\n这个结果是否被采用？yes/no: ").strip().lower()
minutes_saved = input("估计节省了多少人工分钟？例如 15: ").strip()
row = {
"time": datetime.utcnow().isoformat(),
"task_name": task_name,
"model": MODEL,
"prompt_tokens": usage.prompt_tokens,
"completion_tokens": usage.completion_tokens,
"cost_usd": estimate_cost(usage),
"latency_ms": latency_ms,
"accepted": accepted,
"minutes_saved": minutes_saved,
}
file_exists = os.path.exists("ai_task_metrics.csv")
with open("ai_task_metrics.csv", "a", newline="", encoding="utf-8") as f:
writer = csv.DictWriter(f, fieldnames=row.keys())
if not file_exists:
writer.writeheader()
writer.writerow(row)
if __name__ == "__main__":
run_task(
"生成 PR 摘要",
"请根据以下变更说明生成一段给代码评审者看的 PR 摘要：新增订单取消接口，补充幂等校验，修复重复退款问题。",
)
跑几天后，你可以用最简单的命令看趋势：
python track_ai_task.py
column -s, -t ai_task_metrics.csv | less -S
这个文件里最重要的列不是 prompt_tokens，而是 accepted 和 minutes_saved。如果某类任务 Token 很高、采纳率很低，就该优化提示词、换模型、缩小任务范围，甚至停止自动化。
Agent 尤其需要“刹车”和“验收”
tokenmaxxing 最容易发生在 Agent 场景里，因为 Agent 可以自动循环、自动调用工具、自动把上一步输出变成下一步输入。如果没有停止条件，它会非常擅长制造“看起来很忙”的日志。
给 Agent 设计指标时，建议加上几条硬约束：
- 每个任务必须有明确的完成定义，例如“创建一个可运行的测试文件”。
- 每轮循环必须说明为什么还需要下一步。
- 设置最大轮次、最大 Token、最大费用。
- 输出必须经过测试、人工验收或业务系统反馈。
- 把失败样本保存下来，用于改进工具，而不是隐藏在总 Token 里。
一个简单的 Agent 任务配置可以长这样：
agent_task:
name: generate_unit_tests
goal: 为订单取消逻辑生成可运行的单元测试
success_check:
command: "pytest tests/test_order_cancel.py"
must_pass: true
limits:
max_steps: 6
max_cost_usd: 0.50
max_runtime_seconds: 180
report:
include:
- files_changed
- tests_passed
- human_review_required
- estimated_minutes_saved
这类配置的重点不是 YAML 本身，而是组织姿态：Agent 不是来表演消耗的，它要交付一个能被验证的结果。
给团队的采用建议
如果你正在推动 AI 落地，不必把早期 tokenmaxxing 全盘否定。它可能确实帮团队跨过了“不敢用、不知道怎么用”的冷启动阶段。但继续沿用同一个指标，就会把探索变成刷量。
更稳妥的做法是：
- 初期可以看使用频次，但设定退出时间，不让它永久进入绩效。
- 中期按任务类型建立基线，比如写测试、查日志、生成客服回复。
- 后期关注采纳率、节省时间、质量变化和单位成本。
- 对 Agent 设置预算和验收，不奖励无边界循环。
- 允许团队报告“这个场景不适合 AI”，这同样是有效学习。
Tokenmaxxing 的第一阶段结束，并不意味着少用 AI。恰恰相反，它意味着 AI 已经从新鲜工具进入工程管理阶段：少看热闹的消耗曲线，多看任务有没有真的变快、变稳、变便宜。