73.7 万亿个 token，30 天。这个数字来自 Meta 面向约 6000 名员工的内部备忘录：仅内部员工用大模型写代码，一年账单就可能逼近数十亿美元。CTO Andrew Bosworth 把这种现象称为 “tokenmaxxing”，也就是为了刷 token 量而使用模型。他提醒团队：不是所有动作都等于进步，token 消耗本身不是生产力。
这件事对工程团队的信号很清楚：AI 编程工具已经从“能不能用”进入“怎么管、怎么算、怎么证明价值”的阶段。
Token 不再只是技术指标，而是成本科目
很多团队刚接入代码助手、Agent、自动 PR 工具时，关注点通常是体验：补全是否聪明、能不能跑测试、能不能自动修 bug。但当调用量进入组织级规模，token 就变成了类似云计算账单里的 CPU、带宽和存储。
一个常见误区是把“用了多少 AI”当成“提升了多少效率”。这很危险。模型多轮解释同一段代码、Agent 反复读取整个仓库、每次提交都把超长上下文塞进去，都会让 token 飙升，却不一定减少缺陷、缩短交付周期，甚至可能制造更多需要人工审查的输出。
更合理的看法是：token 是投入，不是产出。真正要看的指标应该包括：
- 每个合并 PR 的平均 token 成本
- AI 生成代码被修改、回滚、拒绝的比例
- 缺陷修复耗时是否下降
- 测试覆盖率或静态检查通过率是否提升
- 人工 review 时间是否真的减少
“tokenmaxxing” 暴露的是工程管理问题
把 token 用多，本身不一定错。复杂迁移、跨模块重构、遗留系统理解，确实可能需要大量上下文。但如果团队没有边界，模型很容易被用成“昂贵的搜索框”和“无限耐心的橡皮鸭”。
几个高风险场景尤其值得盯住：
- IDE 插件默认把大文件、日志、依赖源码塞进上下文
- Agent 每次任务都全仓扫描，而不是按文件、符号、调用链收敛
- CI 里对每个失败测试都调用大模型解释，但没有去重和缓存
- 开发者用模型生成大量样板代码，却缺少质量门禁
- 组织只统计调用量，不统计交付结果
这也是为什么大厂开始踩刹车。不是否定 AI 写代码，而是把它从“随便试”拉回到工程经济学：每一次调用都应该有目标、有上限、有可观测性。
可以这样实践：给团队加一个 Token 预算器
下面这个例子不是来源中的内部工具，而是一个可以直接改造的最小实践：用 Python 粗略估算 prompt 和输出 token 成本，并按任务类型设置预算。它适合放在本地脚本、CI 预检或内部 Agent 网关里。
运行前安装依赖：
pip install tiktoken
保存为 token_budget.py：
import argparse
import sys
import tiktoken
MODEL_PRICES = {
# 示例价格，请替换成你们实际供应商和模型的价格
"example-large": {"input_per_1m": 3.00, "output_per_1m": 15.00},
"example-small": {"input_per_1m": 0.15, "output_per_1m": 0.60},
}
TASK_BUDGETS_USD = {
"code_review": 0.10,
"bug_fix": 0.25,
"migration": 2.00,
}
def count_tokens(text: str, encoding_name: str = "cl100k_base") -> int:
enc = tiktoken.get_encoding(encoding_name)
return len(enc.encode(text))
def estimate_cost(model: str, input_tokens: int, output_tokens: int) -> float:
price = MODEL_PRICES[model]
return (
input_tokens / 1_000_000 * price["input_per_1m"]
+ output_tokens / 1_000_000 * price["output_per_1m"]
)
def main() -> int:
parser = argparse.ArgumentParser()
parser.add_argument("--model", default="example-large", choices=MODEL_PRICES.keys())
parser.add_argument("--task", default="code_review", choices=TASK_BUDGETS_USD.keys())
parser.add_argument("--expected-output-tokens", type=int, default=2000)
parser.add_argument("file", help="包含 prompt 或上下文的文本文件")
args = parser.parse_args()
with open(args.file, "r", encoding="utf-8") as f:
prompt = f.read()
input_tokens = count_tokens(prompt)
cost = estimate_cost(args.model, input_tokens, args.expected_output_tokens)
budget = TASK_BUDGETS_USD[args.task]
print(f"model={args.model}")
print(f"task={args.task}")
print(f"input_tokens={input_tokens}")
print(f"expected_output_tokens={args.expected_output_tokens}")
print(f"estimated_cost_usd={cost:.4f}")
print(f"budget_usd={budget:.4f}")
if cost > budget:
print("ERROR: estimated token cost exceeds task budget", file=sys.stderr)
return 2
return 0
if __name__ == "__main__":
raise SystemExit(main())
准备一个 prompt 文件：
cat > review_prompt.txt <<'EOF'
请审查下面这个变更，只关注并发安全、异常处理和测试缺口。
不要重写整个文件，只输出高风险问题和对应行号。
<在这里粘贴 diff 或关键代码片段>
EOF
python token_budget.py --task code_review --model example-large review_prompt.txt
你需要改的地方很少：
- 把
MODEL_PRICES换成真实模型价格 - 把
TASK_BUDGETS_USD调成团队可接受的预算 - 在 CI 或内部网关里把超预算请求打回，让调用者缩小上下文
这类脚本解决不了所有问题，但它能让团队从“感觉用得有点多”变成“这次 review 预计花 0.18 美元，超过了 code_review 预算”。工程管理需要这种可见性。
更重要的是限制上下文，而不是禁止使用
很多 AI 成本浪费来自上下文过宽。可以把规则写得更具体：
ai_usage_policy:
default_model: example-small
escalation_model: example-large
max_context_files: 8
max_input_tokens:
code_review: 12000
bug_fix: 30000
migration: 120000
require_human_approval_when:
estimated_cost_usd_gt: 1.00
touches_paths:
- "payments/**"
- "auth/**"
- "infra/**"
prompt_rules:
- "只附上与任务直接相关的文件和 diff"
- "优先使用小模型做摘要、分类、去重"
- "大模型只用于架构判断、复杂调试和高风险变更"
- "禁止为了生成活动量而批量调用模型"
这份 YAML 不是标准格式，而是一种可落地的内部约定。关键是让模型选择、上下文规模、审批条件都从口头习惯变成可审计配置。
采用建议：把 AI 编程当成有预算的生产工具
踩刹车不是倒退。真正成熟的 AI 工程实践，应该像管理云资源一样管理 token：默认可用，但有配额、有日志、有成本归因，也有质量指标。
可以从一个小清单开始：
- 给 IDE、Agent、CI 分别统计 token 和费用
- 按团队、仓库、任务类型拆账
- 建立“每个合并 PR 的 AI 成本”指标
- 对超长上下文请求做预算提醒或审批
- 缓存重复分析结果，避免同一个失败日志反复喂给模型
- 用小模型处理摘要和分类，把大模型留给高价值判断
- 定期抽样检查 AI 输出的缺陷率和返工率
AI 写代码会继续进入主流开发流程，但“无限 token 换效率”的阶段正在结束。下一阶段的胜负，不在于谁调用得最多，而在于谁能用更少的上下文、更明确的目标，产出更可靠的代码。