AI 代码审查降本：缓存、调用与模型分级

Cloudflare 的 AI 代码审查成本降了 68%，靠的是调整缓存边界、删掉无效调用，再按审查任务选择模型和推理强度。原文给出的结果是：单次审查从 $2.43 降到 $0.77，中位耗时从 4 分 9 秒缩到 1 分 32 秒。

这份案例值得读的地方，是他们把账单和审查质量放在一起检查。总成本下降、有效评论增加的同时，性能审查员确实漏掉了更多问题。对正在做 AI 编程工具的团队，这比一张降本成绩单更有参考价值。

缓存命中率已经有 97%，为什么还这么贵

按照原文，Cloudflare 每个合并请求都会经过协调器，分成 full、lite、trivial 三档。完整审查会启动六个 Claude 专项 agent，分别检查代码质量、安全、性能、AGENTS.md 合规、文档和标准，由 OpenCode 编排并调用 Anthropic API。

成本上涨来自几件事叠加。2026 年 4 月，单次审查平均 $1.19；8 月初统一使用 Anthropic 模型后，从 $1.38 涨到 $2.03。标准审查员切到 Claude Opus 4.7，单项成本从 $0.25 涨到 $0.88。到 8 月底，整条流水线达到 $2.46。

更大的变化藏在上下文里：每次审查的 token 从 4 月的 91 万增至 9 月的 299 万，超过三倍。优化前，代码质量审查员平均调用模型 16.6 次，写入 7.2 万缓存 token，读取 108 万缓存 token。

即使整体缓存命中率从 85.7% 升至 97%，账单仍在增长。缓存读取也收费，而且总体命中率会掩盖每个新会话首轮请求的问题。

他们的支出中，缓存写入占 43%，缓存读取占 34%，输出只占 23%。如果只盯着让模型少回答几句话，就绕过了最大的成本项。

缓存是否命中，要看每个会话的第一轮请求，不能只看全局平均值。

把稳定前缀放对位置，才能真正复用缓存

六个审查员开头都有一段跨仓库相同的内容，长达 11,000 到 21,000 tokens。但原来的第一段 system 内容混入了环境信息和日期，唯一的缓存断点又放在整个提示词末尾。

Anthropic 的提示词缓存按前缀匹配，顺序是 tools、system、messages，每个请求最多四个断点。断点之前的内容必须逐字节一致。公共说明即使完全相同，只要前面混入不同仓库的信息，就无法共享这段缓存。

9 月 16 日，他们拆开 system 内容，把断点移到公共部分之后。排列变成：固定工具定义、共享 system 内容、缓存断点，然后才是仓库上下文、日期和审查任务。首轮命中率从 14%—26% 升到 91%—99.5%。

为保持一致，他们还禁用了 skills 列表，固定工具描述。原文指出，工具定义变化会使整段缓存失效，thinking 或 effort 配置变化会使 messages 缓存失效。五分钟 TTL 每次读取时免费刷新，但从请求开始计时，生成过程也会消耗有效期；5.5 系列最低缓存长度为 512 tokens，Opus 4.7 为 2,048 tokens。

同一轮调整还把标准表、skill 文件和参考列表直接放进提示词，减少反复查资料：标准审查员调用次数从 15.9 降到 9.6，成本从 $1.12 降到 $0.72。整项优化约节省 $0.45。

这里的经验是，把必需且稳定的材料放进可复用前缀，才可能省掉后续重复读取的调用。

模型可以降档，但要逐个审查员算账

原文把模型与 effort 调整列为最大收益来源，约节省 $1.06，占总节省约 60%；代码改动贡献约 40%。

协调器统一模型和 effort 组合后，full 档任务约快了 20%。作者还报告，Claude Opus 5.5 配合 medium effort 替换 Opus 5，没有测出结果差异。

10 月 3 日，Sonnet 5.5 与 Sonnet 5 在相同 token 单价下比较，代码质量、性能、安全审查的成本分别下降 62%、58%、47%，原因是生成 token 更少。团队于 10 月 5 日切换到 5.5。

但 effort 不能一起调低。代码质量审查平均曾需 6.2 次调用，medium 降至 1.7 次，超过一半单次完成，high 则为 3.4 次。看上去 medium 很划算，质量数据却显示：相较 high，它丢掉了约四分之三后来被开发者采纳的问题。最终团队恢复 high，每次约多付两美分；在 5.5 上，high 比 medium 多报 58% 的 critical 和 warning，成本增加 61%。

9 月 21—23 日，他们还清理了不改变审查结论的工作，约省 $0.20。其中一个具体漏洞是取消任务：GitLab 的 Kubernetes executor 不会把取消信号传到审查进程，开发者点了取消，模型仍继续运行。runner 开始轮询状态后，才真正停止这笔消耗。原文没有完整列出其他调用删减项，不能据此补出一套工具优化清单。

这些调整之后，中位耗时降到 1 分 32 秒，P99 从 15 分 20 秒降至 4 分 41 秒，超过五分钟的比例从 37.9% 降到 0.7%。速度改善很明确，但是否值得降档，还得看漏掉了什么。

我的判断

我认可他们把质量测量放在降本流程里。第一种方法是看问题标记的代码行是否在下一次 push 中改变。代码质量问题的采纳率从 34% 升到 59%，全体审查员每千次审查被采纳的问题从 229 增到 321。

他们还抽取距离问题行 30—40 行的位置作参照，发现约 15% 本来就会变化。因此，「指出后代码改了」不能直接算审查贡献，必须扣住自然修改这个干扰因素。

第二种方法是盲评 657 条发现，由两家供应商的模型评分，第三个模型裁决分歧，区分重要、轻微、重复、错误、无法验证，并检查严重程度。整体重要问题维持在每次 0.28—0.30 条，严重程度高估从 0.46 降至 0.14，下降约 70%。

整体指标变好，不能证明每个专项审查都保住了质量。

性能审查员的重要发现减少约 64%，约每 24 次完整审查漏掉一个真实问题；其 critical 和 warning 减少 71%。安全发现减少约 25%，作者认为未达统计显著。代码质量自己的每千次有效发现也从 145 降到 132。原文没有说清性能审查退步后是否恢复配置。

这些结果仍有边界：每组盲评只有 35—66 条，最终比较窗口仅一天，前后对比使用工作日时段，并非受控实验。它支持继续试验，不能证明模型升级普遍保质降本。文中的 Claude Opus 5.5、Sonnet 5.5 及对应能力，也只能按该文所述理解，所给材料不足以独立核验。

账目同样存在口径差异：$2.43 到 $0.77 相减是 $1.66，文中写 $1.67；三项收益相加约 $1.71，缓存阶段又用了 $2.47 的起点。可能涉及窗口和四舍五入，但原文没解释，不能当作严格的成本对账。

与直接换便宜模型相比，这套方法更能定位损失，代价是评估工程。对自托管 vLLM，enable_prefix_caching=True 能复用公共前缀的 KV cache，但主要加速 prefill；长输出主导的 decode 开销不会因此明显下降，API 的 token 账单比例也不能照搬到 GPU 租用成本。

能拿来做什么

• 给 AI 审查或 Node agent 服务按任务记录调用次数、缓存写入、缓存读取、输出 token 和费用，并单独检查每个新会话的首轮缓存命中情况。
• 调整提示词组装顺序，把稳定工具定义和公共规则放在前面，把日期、仓库信息、diff 放在后面；每次修改工具描述后，检查缓存复用是否下降。
• 做模型或 effort 对比时，分别统计代码质量、安全、性能的有效发现，不只比较通过率和平均费用；对有真实损失的审查员保留更高配置。
• 将取消状态传递到实际模型请求和 agent 循环，并用后续 push 的代码变化衡量评论价值，同时抽取未被标记的代码行估计自然修改比例。