免费资源跑代码审查：48 小时复现实验

一位开发者给自己设了 48 小时限制：用免费模型额度和免费服务器，跑一个小型代码审查任务，并记录模型建议是否被人工采纳。实验提供可运行模板，但作者明确说，这只是小样本观察，不是性能基准。现有节选更有价值的部分，是预算、重试和实验记录中暴露的问题。

目前能确认什么

任务输入是 unified diff，也就是包含代码增删及上下文的差异文本，输出是简短审查意见。作者准备了空值检查、错误处理、配置修改三类固定样例，每类重复运行五次，保持提示词和 temperature 一致，尽量减少实验条件变化。

记录采用 JSONL，每行对应一次请求，分别保存输入与输出 token、耗时和人工采纳标记。接口未返回用量时保留空值，估算数据另行标注。请求次数和输入 token 上限在调用前检查。

作者发现，输入中的 diff、系统提示词和项目约定占了主要用量；空闲后的首个请求耗时变长，影响超时设置；重试则会重复消耗预算。因此，每次尝试需要单独记账，重试仅用于传输错误。节选末尾还提到，作者多次修改提示词，导致难以区分输出变化的来源。

服务器使用 MonkeyCode 的免费选项。文章披露属于该产品的推广活动，免费额度和条款不能据此认定。

我的判断

这份实验最值得借鉴的是记录方法，目前还无法据此判断自动审查的收益。

人工采纳比「看起来有帮助」更容易追踪，但采纳不等于建议正确，也无法揭示模型漏掉了多少问题。三类固定样例适合检查流程能否跑通，对真实仓库的覆盖仍然有限。

对准备接入自动审查的程序员，我会先关注每条有效建议背后的请求用量、重试次数和人工筛选成本。现有节选没有给出最终采纳结果、完整运行数据，也没交代提示词变更后如何处理已有记录。免费资源能否支撑持续运行，仍缺乏证据。