成本与用量

成本与用量 是一条工程预算，不是财务指标：让团队在动手之前估一次「这次大概要花多少」。记账的粒度是变更，不是人。

助手写代码看着不要钱，账单上不是：上下文、评测样本、整文件重写都在计费。

想知道这次超没超线，直接看额度线与超限后的三级动作。

本层判断标准

随便挑一个已合并的变更，能不能说出它花了多少、贵在哪一步？

答「不能」，说明用量没有按变更归因，只看到一个月度总额。总额只能引发「省一点」的空讨论——把记录按变更名聚合，才知道该动哪一步。

为什么成本要写成规范

下面四类消耗不会报错、不会让 make check 变红，只会让账单悄悄变大，同时让重要的几句话被淹在上下文里。

看不见的消耗可识别的现象后果
上下文膨胀每次对话开头都贴一遍目录树或整个模块贵，且真正重要的规则被淹掉，模型开始忽略约束
无谓重跑同一任务重试超三次，每次不缩小范围成本翻倍，结论还不可比——两次跑的不是同一件事
评测铺开常规回归里随手把样本数从 40 加到 200一次回归跑掉一周的额度，还没人看得完报告
大范围重写为了改一个函数，助手重写整个文件评审成本和计费一起涨，改动差异里噪音盖过信号

这条用量规范替上下文预算兜底：有了额度线，才会在贴整仓之前先想一下，该不该改成按路径生效的规则。

额度线与超限后的三级动作

额度不是财务指标，是工程预算。它的作用是让团队在动手前先估一次「这次大概要花多少」，而不是事后看账单。下表是课程项目的起始参考值，先照抄，跑两周再按实际调整——调整要改文件并留一次记录，不能只在群里说。

额度项参考上限记在哪
单任务输入 token≤ 80kdocs/usage-budget.md
单任务输出 token≤ 8kdocs/usage-budget.md
单人单日输入 token≤ 200k用量报表
同一任务的提交前重跑次数≤ 3 次用量记录里的 tool_calls 与重试理由
常规评测样本core 集 40 题；全量 200 题另批eval/questions.yaml
单条规则文件长度≤ 200 行AGENTS.md 与 .claude/rules/
全组周额度输入 ≤ 1.2M token周报 docs/metrics/
一级：超出上限 1.2 倍以内在合并请求里写一行原因，继续做，不需要审批。写原因是为留下判据，不是走过场。
二级：超出上限 2 倍停手。先把任务拆小，或把上下文缩到按路径生效的规则；由组内负责人当天确认再继续，并把这次原因追加进 docs/usage/。拆不动，说明规约没把边界写清。
三级：周额度用尽冻结非必要任务：探索性调研、大范围重写、临时放大的评测样本。只保留门禁与回归，并在周报里列出冻结清单与解冻条件（额度回到额定的 80% 以下）。

超限时最该做的是缩小任务范围，不是调高上限。一次说不清的任务拆成三次，通常更便宜也更准。调高上限，只会在下一次以更大的幅度超限——超限的原因（任务边界不清）没被碰到。

用量按什么归因

只知道总数没用，要能回答「这个变更花了多少」「哪一类任务最贵」。三种统计维度能回答的问题不同，用错维度会把工程问题变成考勤问题。

统计维度主键能回答什么答不了什么记录方式
按变更openspec/ 目录名这个变更花了多少、贵在实现还是贵在试探谁上手最快会话结束时追加一行 JSON 到 docs/usage/<变更名>.jsonl
按人提交者邮箱新成员前两周的用量是否异常高哪类任务贵；用久了就会滑向考勤表只在新成员前 2 周记录，之后停用
按会话会话 id + 时间戳一次任务里试探了多少轮产出了什么；会话本身不产出可合并的东西工具侧日志，保留 30 天，不入仓库

docs/usage/class-isolation.jsonl

一行一次会话，字段固定六项。费用不记在行里——单价会变，行里只记 token 数，费用在聚合时用当时的单价算。

{"ts":"2026-10-03T14:02Z","change":"class-isolation","actor":"zhang","tool":"claude-code","model":"主模型","in_tokens":48210,"out_tokens":3210,"tool_calls":27,"result":"merged"}
{"ts":"2026-10-04T09:11Z","change":"class-isolation","actor":"li","tool":"claude-code","model":"轻模型","in_tokens":12030,"out_tokens":880,"tool_calls":6,"result":"merged"}

按变更聚合的一条命令

费用 = 输入 token × 输入单价 + 输出 token × 输出单价；单价以模型厂商的官方定价页为准（Anthropic、OpenAI），不写死在仓库里。

jq -s 'group_by(.change)
  | map({change: .[0].change,
         in:  (map(.in_tokens)  | add),
         out: (map(.out_tokens) | add),
         calls: (map(.tool_calls) | add)})' docs/usage/*.jsonl

把记录落在仓库里，不要只留在某个平台的控制台里。控制台会换、会过期，历史不会。换工具时把 docs/usage/ 一起迁走，这一层才连续。

助手交出来的样子

{"ts":"2026-10-03T14:02Z","actor":"zhang","tool":"claude-code",
 "in_tokens":48210,"out_tokens":3210,"result":"merged"}
{"ts":"2026-10-04T09:11Z","actor":"li","tool":"claude-code",
 "in_tokens":12030,"out_tokens":880,"result":"merged"}

认它的办法：随便挑一个已合并的变更，能不能说出它花了多少、贵在哪一步。上面每行都没有 change 字段，只能按人聚合——而按人聚合的下一步就是排名，排名之后这张表就成了考勤表，真正该问的「哪个变更最贵、贵在实现还是贵在试探」一句也答不了。缺一个字段，整层判据就失效了。

把它当成一个工程指标

把总额除以产出，才有可比性。四个指标都和上一页的周报一起看。

指标怎么算看什么
单位成本总成本 ÷ 已合并的变更数趋势是不是在涨；涨了先看是不是变更拆得太细
单次请求成本总成本 ÷ 请求量是否随上下文膨胀而上升
返工成本被返工的变更成本 ÷ 总成本超过三成说明规约没写住，先补规约再加额度
评测成本评测总成本 ÷ 回归次数是否在为没有结论的回归付费

要和怎么知道生效了一起看：速度上去了但返工成本同步上去，等于没有净收益。这时该停的是改动方式，不是额度。

要省先省什么

省成本要按顺序来。从前到后，每次只动一级；动完一级等一周，看哪个指标真的降了，再决定要不要动下一级。

第一级：省试探性调用同一个问题换个说法再问一遍，是成本里最没用的一部分。提问前先写清输入与期望输出，不要靠多问几轮逼近。识别现象：同一会话的 tool_calls 超过 20。
第二级：省整仓粘贴这一步通常省得最多。把「把整个仓库贴进上下文」改成按路径生效的规则文件，规则只在该目录下加载。做法见规则。
第三级：省评测样本常规回归只跑 core 集 40 题，全量 200 题在发布前单独一批跑、结果单列，不混进常规回归。
第四级：省大范围重写改一个函数就只改那一个函数。发现改动差异里有整份文件被重写，退回让助手重做，并把它记进 docs/usage/ 的原因字段。
最后一级：动门禁与回归到这一步就停。门禁与回归不参与削减——省掉的是判据，省下来的钱会在返工里加倍花掉。

边界：这套顺序适用于「额度紧张」的常规情况。真正的例外只有一类——某个变更的安全问题（越权、密钥泄漏）需要立即加检查，这类不排队，直接加。

常见的失败

#失败真正的错在哪改法
1只看账单总额没有产出做分母按变更归因，再看单位成本
2按人排名用量把工程问题变成考勤聚合到变更，不聚合到人
3超限就一律加额度任务拆得不够细，加额度只是把问题往后推先拆任务或缩上下文，再谈额度
4用量只留在平台控制台换了工具历史就断了落进 docs/usage/ 或流水线产物
5省成本省到门禁上省掉的是判据门禁与回归不参与削减，要省先省试探性调用