2026-10-17

本期研究想法

让审查机器人交证据,而不只是交意见

工程方向 · 人机协作 · Code Review / Human-AI Interaction / Executable Evidence

机器人发现问题之后,人的工作才刚开始。把改动、复现、检查范围和责任人放在同一条阅读路径里,可能比增加评论数量更值得做。

他们已经做了什么

Vapi 的审查机器人会追踪代码、运行测试或小复现,再决定是否评论。团队的经验里,一个很重要的调整是提高误报的代价:每条多出来的意见,无论真假都需要人处理。因此,“让机器人提供可执行证据”已经有工程实践,不是新的概念。

这次还找到 10 月 15 日的 Plausible Is Not Enough。作者调查了 31 个国家的 239 位从业者,讨论 AI 生成的 PR——也就是待合并代码变更——怎样取得审阅者信任。论文不仅提到测试与上下文,也强调人要知道谁负责、哪些主张经过独立核验。它已明确建议研究证据包如何影响人的决定,所以不能把“给审阅者更多证据”本身包装成原创想法。

CHI 的 When Help Hurts 则把注意力放到使用编程助手时的核验负担,比较不同界面并记录行为。这些工作支持把人的检查过程当作设计对象,而不是只看模型输出是否漂亮;它们并没有替我们证明某一种代码审查页面一定更省事。

为什么把这些线索放在一起

这个方向不是从一篇新论文单独生长出来的。10 月 11 日的观察里,Simon 用语音完成一部分开发后仍要回到键盘审查;几天后,Vapi 的经验又说明大量建议可能增加核验工作。两者共同指出一种交接问题:机器知道自己刚才做过什么,人接手时却要重新拼上下文。

我更感兴趣的不是继续缩短摘要,而是减少人为了判断一条意见而来回找东西。比如“这个 PR 破坏了重复输入处理”是一句话,但审阅者还需要知道哪组输入能复现、父版本怎样、候选版本怎样、测试是否真的运行,以及这个缺陷是否本来就存在。把这些材料接起来,才可能减少一段真实工作。

可以往哪些方向走

可以先做“可复查的审查卡”。每条重要意见直接连到相关改动、最小复现和父/新版本差异,明确哪些是运行结果,哪些只是机器人推测。修复建议可以保留,但不必抢在证据前面;审阅者首先需要决定问题是否成立。

第二个方向是按风险组织交接,而不是把所有发现平铺。普通样式建议与数据迁移、权限、并发错误需要的证据不同;把必须阻断合并的问题与顺手可修的问题分开,可能比给每条意见再加一个置信度更有用。

第三个方向可以从一次小型复现开始:让相同的发现分别以普通评论、完整证据页、先看关键差异的方式呈现,观察人在哪里来回翻页、哪些信息反而妨碍判断。这里值得积累的是具体交互经验。愿意进一步研究时,再讨论哪些人和哪些任务真正受益。

值得做在哪里

工程上可以把它做成 PR 模板、审查机器人插件,甚至只是一个静态报告生成器。它不要求新模型,价值来自更好的交接。研究上则可以继续追问“增加证据”和“增加阅读负担”之间的分界,但不必现在就把实验设计钉死。若只能完成一件事,我会优先做一份维护者能直接拿来核查的真实变更报告。

从哪里开始看

先读 Vapi 的实践文章,再看 Plausible Is Not Enough 的工作流讨论。挑一个可公开的小 PR,把父版本和候选版本的复现放在一起,问熟悉项目的人:哪些材料让你少找了一次上下文,哪些只是重复了你已经知道的事。若采用代码执行,分析环境与发布评论的权限应分开,不让待审代码拿到发布凭据。

暂时不往哪里走

不把“用户更喜欢这个界面”直接写成“审查更准确”,也不把合并等待时间等同于人的实际工作时间。最新问卷已经提出证据包的研究议程;本方向的吸引力在具体实现、使用体验和可复查材料,而不在抢占一个全新的概念。

回看线索

来源与查新记录

回看:10 月 11 日:完成任务后,人还剩多少工作

回看:10 月 13 日:Vapi 的实践与不同统计口径

回看:10 月 13 日:生成、审查和交付