What · 是什么
tiktoken-go 计费（o200k/cl100k_base），预算前瞻截断、80% token 大文件丢弃、prompt-cache 亲和键命中前缀缓存
基于 tiktoken-go 精确计费：o1/o3/o4 系列用 o200k_base，其余模型用 cl100k_base，分词口径与 OpenAI 一致
estimate.go 提供 token 预估与预算前瞻：审查前估算输入 token 量，预判是否超出模型上下文与成本预算
filterLargeDiffs 自动丢弃超过 MaxTokens 80% 的超大文件 diff，防止单文件撑爆上下文
三区压缩策略：对超大输入分区压缩，显著降低送入模型的 token 总量
prompt-cache affinity key 设计：按（会话+任务+文件）组合生成缓存键，命中 provider 前缀缓存后 input 成本节省约 98%
端到端对比通用 Agent，同样审查任务 token 消耗节省 5-15 倍
Why · 为什么
原理 · Principle
token 即成本，审查任务动辄处理整个 diff，无预算控制会产生不可控账单
超大 diff 塞入模型不仅贵，还会稀释注意力导致审查质量下降，丢弃 80% 阈值之上的文件是质量与成本的双赢
前缀缓存命中与否直接决定 input 成本量级（约 98% 差异），affinity key 让重复/相似任务尽量复用缓存
How · 怎么做
默认策略即可享受收益：filterLargeDiffs 与三区压缩自动生效，无需配置
关注预算：审查前查看 estimate.go 输出的 token 预估，判断本次任务的成本量级
最大化缓存命中：保持会话与任务结构稳定（同一仓库同一文件多次审查），让 prompt-cache affinity key 命中 provider 前缀缓存
按模型选口径：使用 o1/o3/o4 时确认计费走 o200k_base，其余模型确认 cl100k_base，避免计费误判
结合遥测验证：在 metric 中观察 token 计数与缓存命中率，量化节省效果并发现异常增长
案例 · Cases
| 代表性案例 |
|---|
| 超大 PR 审查：一个 2000 行文件被 filterLargeDiffs 自动跳过，审查继续进行而非整体失败，成本可控 |
| 重复审查同一分支：第二次运行命中前缀缓存，input token 成本骤降至约 2% |
| 多模型对比：用预估工具对比不同模型的 token 消耗，选择性价比最高的审查模型 |
| 成本审计：月末按 metric 的 token 计数核对账单，确认无异常放大 |
反模式 · Anti-patterns
- 忽视 80% 阈值丢弃：以为『审查不完整』而调高阈值甚至禁用 filterLargeDiffs，导致成本与质量双双恶化
- 频繁变更 prompt 前缀（改系统提示/顺序），破坏前缀缓存命中，让 98% 的节省归零
- 用 cl100k_base 口径估算 o1 系列任务，token 数量与账单对不上，影响预算决策
- 在长会话中堆积无关上下文，压缩与缓存机制失效，实际 token 远超预估
正反实例论证 · Evidence
正例 · Pro
filterLargeDiffs 自动丢弃超大文件
# 单文件 diff 超过 MaxTokens 80% 时filter_large_diffs: dropped tool_calls.py (9213 tokens > 80% of 8192)超大 diff 自动跳过而非撑爆上下文，审查继续完成且注意力不被稀释，成本与质量双赢。
反例 · Con
调高阈值甚至禁用过滤
filter_large_diffs: disabled # 或 threshold=95%2000 行文件全量入模，token 账单飙升且审查焦点被稀释，一次审查的成本抵得上十次正常审查。
正例 · Pro
稳定 prompt 结构命中前缀缓存
# 同一会话+任务+文件组合重复审查ocr review --commit abc123ocr review --commit abc123 # 第二次运行命中 provider 前缀缓存prompt-cache affinity key 按（会话+任务+文件）生成，重复任务命中缓存后 input 成本节省约 98%。
反例 · Con
频繁改动 prompt 前缀破坏缓存
# 每次审查前改系统提示/规则顺序ocr review --rule "A" && ocr review --rule "B"前缀字节变化导致整个缓存失效，98% 的 input 成本节省归零，token 账单回到全价。
正例 · Pro
按模型口径准确计费
# o1/o3/o4 系列走 o200k_base，其余走 cl100k_baseestimate.go: model=o3, tokenizer=o200k_base, estimated_input=12.4k审查前 estimate.go 给出与模型匹配的 token 预估与预算前瞻，成本决策有据可依。
反例 · Con
用错分词口径估算 o1 系列
# 按 cl100k_base 估算 o1 任务 tokenestimate: 9.8k tokens (实际应走 o200k_base 口径)预估与账单口径不一致，预算前瞻失真，月底对账对不上才发现成本超支。