OpenRouter · 教程与作者小样本测试 · 阅读原文
发现渠道：社区讨论与聚合入口
OpenRouter 的教程用一个 233 行的 Python 脚本演示代码审查：收集文件、差异和测试，交给模型；模型可以在托管 Linux 沙箱里运行短检查，再提交发现的问题和补丁。它试图解决的痛点很具体——一条说得像真的审查意见，未必能复现，更未必附带正确修复。
脚本区分已经确认与尚未确认的发现，也报告补丁是否成功应用。这里有一个容易漏掉的边界：沙箱中的复现针对原代码，补丁写入另一个临时工作副本。补丁“应用成功”只是文件修改成功，不表示修改后的代码已经再次通过测试。沙箱默认没有外网，缺少依赖时也可能无法复现；不能把这类受阻直接判为没有缺陷。
作者人为放入五个缺陷，给四种模型各跑三次。Sonnet 5.5 在三次中都修好五项，平均调用费约 0.0447 美元；这是这份玩具任务的记录。Haiku 有两次用错误的索引方式修补判断，反而破坏了字典调用者。DeepSeek 三次有一次到八轮上限仍未提交，另外两次完成；只统计完成轮次会掩盖这种失败。
教程的价值是展示如何留下复现与修改记录。五个植入缺陷不能代表真实仓库，也没有证明它在没有问题的变更上不会误报。本期阅读流程、代码相关段落和结果限制，没有调用模型、运行沙箱或复测这些补丁。
可信度 65 · 重要性 76 · 新颖度 77
技术与主题
Agent 系统 · AI 编程 · 评测与基准 · 沙箱复现 · 补丁回归 · 代码审查
编辑评读
“找到错误”和“修好错误”应该是两个验收点。审查者可能正确指出身份比较有问题，却用只适合元组的方式修补，破坏原来允许的字典输入。要保护既有行为，补丁后的检查必须包括发现缺陷的反例，以及本来就应该成立的调用方式；只重跑一个新反例可能再次漏掉退化。
这也给此前关于干净变更误报的观察补上了一种工程入口。能够执行证据，比仅给置信度更便于核查；但执行过某条命令，并不自动表示检查覆盖了声称的行为。可以让每条意见指向具体输入、预期结果和实际结果，再分别保存原代码与补丁后结果。还要核对命令实际读取的文件位置，避免日志里虽有测试成功，运行的却仍是旧副本。随后加入本来正确的变更，统计错误建议是否会被执行、是否造成损害，才能接近审查的净收益。这是可继续做的比较，教程并未完成。