每次 push 都在烧钱的 CI 机器人：五个常见误用与修法
每次 push 都触发全量模型评审，钱从哪来
很多 CI 机器人的初衷很好：有人 push，就让模型把改动读一遍，写几条评论，顺手补一段测试。跑通之后没人再回头看账单，直到月底才发现一个仓库的机器人调用比开发者本地用掉的还多。问题通常不出在模型本身，而是触发条件、输入规模和重试策略叠在一起之后的放大效应。
先算一笔具体的账：一次 push 触发三个 job，每个 job 调一次模型，每次输入八千 token 的 diff 加日志，再输出几百 token。一个仓库一天推二十次，就是几百次调用，一个月轻松超过百万 token。这些数字在 CI 日志里只是一行 JSON，出现在账单上却是真金白银。
把触发条件收紧是性价比最高的一步，它不改任何提示词，也不影响评审质量。
- 只在主分支合并或者打发布标签时才调用模型评审，普通分支推送用静态检查和单测兜底。
- 给模型调用加上最小改动门槛，比如只有改动超过五十行或者触及核心目录时才让模型介入。
- 把评审结果直接写成提交注释或者合并请求评论，避免为了格式化输出再追加第二次调用。
- 在流水线里为模型调用设置每日和每月 token 上限，超过阈值就跳过并留下一条警告日志。
忽略缓存读写，同样的上下文被反复计费
最大的一块浪费来自重复上下文：仓库的编码规范、目录结构说明、接口约定，每次调用都被原样塞进提示词一遍。缓存机制能替你省下这部分钱，但它要求调用方把稳定前缀和变化部分拆开，并且保持顺序一致。很多 CI 脚本是直接拼字符串的，每次顺序略有不同，缓存命中率因此接近于零。
在 Fluxo 上按真实 token 计费，缓存读和缓存写都按实际用量结算，没有月租，缓存命中就是直接省钱，缓存失效就是直接多花。接入只有一件事：把 base URL 换成 https://api.fluxorelay.com，再配上一个 key，Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen、Grok 等模型就在同一个入口后面，Claude Code、Codex、Gemini CLI 和任何 OpenAI SDK 都能直接用。
举个例子：让 Claude Haiku 4.5 做第一遍改动分类时，把仓库规范放在提示词最前面当稳定前缀，每次只替换末尾的改动摘要，缓存读的部分会被反复命中，账单比每次都从零开始便宜一截。
- 把系统提示、仓库规范和输出格式固定在提示词开头，变化的改动摘要统一放在最后面。
- 同一个任务内的多次调用尽量复用同一份上下文，不要每一步都重新拼一遍完整背景。
- 注意缓存写本身也计费，稳定前缀别做得过长，只有两次以上调用才用得上的内容可以直接删掉。
把整段构建日志和完整 diff 灌进提示词
CI 环境里最不缺的就是文本：构建日志、测试输出、依赖树、覆盖率报告，随手一抓就是几万 token。很多脚本把这些内容一股脑塞给模型，希望它自己找出重点，结果输入占了成本的九成，输出只有一句建议。模型读不读得完是能力问题，你付不付这笔钱是工程问题。
先在 CI 侧做裁剪：只保留失败用例的堆栈、与改动相关的文件差异，以及最后一百行构建输出。依赖树和完整覆盖率表留在流水线产物里，需要时再单独取。裁剪之后的输入通常能压到原来的十分之一，而模型给出的建议质量几乎不变。
- 只保留失败用例的报错堆栈和相关文件差异，成功用例的输出一律不要送进提示词。
- 对构建日志做去重和折叠，重复的警告行合并成一行带计数的摘要再交给模型处理。
- 把大文件的完整内容换成关键函数签名和改动点附近那几十行代码，其余部分留给模型按需引用。
- 让流水线先把原始日志整理成结构化摘要，再让模型基于摘要做判断而不是直接啃原文。
失败重试与并发把一次调用放大成十次
模型接口会超时，会限流，会偶发返回不完整，于是重试逻辑被写得很慷慨：失败三次，指数退避，再整轮重跑。在本地这只是多等几十秒，在流水线上是同一份输入被计费四遍；如果同一提交还有多个 job 并发评审，放大倍数还要再乘一次并行度。
更隐蔽的放大来自循环：脚本让模型自己判断是否需要继续修改，直到它输出通过为止。没有上限的循环等于把预算交给一个不确定的终止条件。所有模型调用都要有硬性的轮数上限和 token 预算，超限就带着已完成的部分收工。
- 给重试加上总次数和总 token 双重上限，退避之后仍然失败就降级成静态检查结果。
- 把幂等的模型调用结果缓存在流水线产物里，同一提交的重复运行直接复用上次结论。
- 任何由模型输出驱动的循环都要写死最大轮数，绝不依赖模型自己宣称任务已经完成。
- 并发评审时按仓库或者按分支限流，避免同一时刻把多个 job 的输入一起推给上游。
一个模型打天下，让旗舰模型去做分拣
很多流水线从头到尾只配一个模型，而且下意识挑了最贵的那个。其实 CI 里的任务分层很清楚：先筛选出可疑改动，再深入分析少数几处，最后只对高风险部分写详细建议。把这三层交给同一个模型，等于让旗舰模型去干搬运工的活。
做法很简单：第一层用便宜快速的模型做分类和打分，比如 Claude Haiku 4.5 处理常规 diff，只有被判定为高风险的改动才升级到更强的模型，例如 Claude Opus 5.5 做深度审查。因为 Fluxo 背后是同一个 key 和同一个 base URL，切换只是改一个字段，计费依旧按真实 token 走，没有月租或者套餐门槛。你邀请来的人付费之后，你还会拿到一份推荐分成。
把这五类问题逐个修掉之后，CI 机器人的账单通常会掉到原来的三分之一以下，而评审覆盖面反而更稳定。如果手上正好有一条每次 push 都在烧钱的流水线，欢迎注册一个 Fluxo 账号，把调用切过去看看真实的 token 明细。接入或者调参时遇到问题，登录后在联系页面留言即可。