代码生成更快之后，审查怎样跟上？

最容易误读的是“审查时间”。论文把它定义为 PR 提交到合并的日历时长，其中既有检查，也有排队和返工。它不能直接换算成审阅者多花了多少小时。若生成速度提高而审阅容量不变，队列就可能变长；若改动更难理解，也可能变长。要区分两种解释，需要人的实际操作时间与缺陷记录，单看合并时间还不够。

双重差分比只问开发者“觉得快了多少”更有约束力，但仍依赖采用前后可比的趋势。采购时点、团队制度和未被检测到的个人使用都可能影响分组。数据来自分析平台客户，结果也不能直接搬给个人项目。没有显著增加不等于效果严格为零，更不意味着十月新模型已被这份研究测过。

Vapi 提供了另一种实际设置：生成之外，把审查也交给能跑复现的 Agent。它的前后变化没有随机对照，却足以让“AI 一定拖慢审查”这句泛化站不住。两份材料更值得共同追问的是：哪类改动适合自动核验，哪类检查只是把更多解释工作转给人。

先把日志变成统计、把文档索引后按需读取，确实能避免反复把无关内容塞进提示。这种收益不应被一概否定。不过，摘要缩短只是输入变化；最终费用还取决于追问、回读、缓存和是否修对问题。一个找不到关键记录的便宜答案，不是同等质量下的节省。

3 月 mergeconflict 的分析已追问检索往返成本。今天补查当前网关文档，发现它已有成对任务费用与成功检查，不能继续写成“项目从未测过任务成本”。相反，这些结果也不能自动批准仓库里的全部功能：文档测试的是网关、多机制组合与特定 Claude Code 版本，订阅用量按标价换算，并非实付账单；同一脚本任务重复多次，也不是多种真实任务。

具体失败比抽象怀疑更有帮助。候选 PR 1295 的作者用基准和改后版本比较俄文记忆检索，但明确没有完成真实模型调用循环。它支持检查多语言召回，不证明所有中文请求失效。我们应把节省的输入、额外检索次数、目标信息命中和最终验收一起测，保留失败运行的费用。

这份材料最有价值的工程细节，是把“模型装得起来”与“整条链能接续”分开。跨硬件的安装和故障排查可以成为能力门槛；拿到执行权的难度、复制后靠什么资源运行、断点如何恢复，仍是别的问题。实验中人为简化的步骤必须保留，否则标题会让读者以为已经观察到现实网络感染。

HN 的 dvt 质疑开放端口和指令执行足以解释演示。这个批评准确提醒了实验范围，但也不能抹掉跨环境建立推理服务需要连续排错的事实。与其争论模型是否“有意图”，更有用的是检查：未简化的访问边界、算力与时间预算是否足以让同一链条完成。

Memento 会定期换一个新实例，继承工作目录和短笔记，以减少困在错误想法里的循环。它是值得注意的恢复设计，却还不能从这一个场景推成所有长任务的最佳方案。应在同等总预算下比较换实例与保留上下文，同时记录成功与丢失关键信息的情况。

这项设置把写出的代码与留下的经验分开评价。源尝试通过不代表它的建议更适合目标：目标原本已能做到的程度也影响增益。匹配目标尝试的预算，并没有抹掉生产源skill的那次额外实验成本，所以不宜把配对收益直接换算成整体省算力。