Nick Nisi：果蝇代码审查实验如何启发人工审查

我是 Nick Nisi，WorkOS 的软件工程师兼工程经理，负责开发者与智能体体验团队。代码写得越来越快，拉取请求越来越多，但即使有 CI、代码检查和自动化智能体，变更仍在等我审查。我成了瓶颈。如果我们不再亲手写下所有代码，就应当追问：为什么人必须审查每一行，而不是着重确认功能是否正确？

编程智能体让我们更像工作的管理者。我们早已在拉取请求上运行 CI，以及 Graphite、CodeRabbit 这样的审查工具；当这些检查让我有信心时，我最关心的是变更是否达到了预期。我认为人工审查会越来越侧重于理解变更及其目的，而不是只为发现所谓机器无法发现的缺陷。

1947 年一只飞蛾卡在继电器里的故事，让软件 bug 和真正的虫子有了一个有趣的联系。我打算用一只虫子寻找软件缺陷：一只模拟果蝇。其他人曾用果蝇神经连接图玩游戏，我决定让它审查 JavaScript。

神经连接图是大脑的线路图。研究人员把雄性果蝇的大脑和神经索切片、成像并追踪神经元及其连接：我使用的图包含 176,422 个神经元、630 万条连接和超过 1.25 亿个突触。我让模拟运行起来，并调整了一小部分负责保存记忆的神经元，使它能学习好代码和坏代码的关联。

果蝇不知道代码是什么。它的感觉毛相当于鼻子，因此我用一个小型 AI 模型充当鼻子：模型针对一次变更回答 30 个尽量避免偏向的是非问题，再把答案变成模拟大脑可以接收的气味。这个演示让“代码异味”成了字面意义上的气味。

审查拉取请求之前，果蝇先用代码库中的例子训练。好的例子关联类似糖水的奖励，坏的例子关联苦味惩罚。这些强化信号影响记忆回路中的连接。不同变更产生不同组合的感官输入，训练后的回路则产生接近或回避反应。

反应会变成一票：伸出“舌头”代表变更闻起来可以接受，缩回则表示需要修改。我把这种记忆想成一个有意让键发生碰撞的哈希表，测试结果负责写入值。奖励和惩罚会调整与接近或回避气味相关的通路。

我担心实际做决定的是语言模型，果蝇只是多余的环节。在我的实验中，移除习得的记忆后，模拟果蝇的反应变得混乱：它不再知道哪些感官模式带来了奖励或惩罚。这种消融实验表明习得回路对判断有所贡献，但这并不意味着果蝇成了传统意义上的代码审查员。

我们用项目代码库中的三个变更玩了一场游戏。第一个例子中，观众要求修改，果蝇却批准；测试表明其中有缺陷，因此果蝇判断错了。第二个 PKCE 例子是无害变更，观众和果蝇都批准了。最后一个例子中，双方都拒绝了有缺陷的变更。

观众三题全对，果蝇答对两题。我自己的测试准确率约为 88%，但这并不意味着应该让果蝇审查生产代码。我还现场尝试审查自己一个扩展的真实拉取请求，但演示和备用方案都没有得出明确结论。大家可以在 fruitfly.review 上体验这个演示。

我还给它出了更难的题。在我报告的两个例子中，它分别有 96% 和 98% 的概率要求修改。这个系统能够捕捉与条件判断变化或逻辑被删除相关的模式，但果蝇不理解 JavaScript，也不会解释如何修复；它最多只能表示某个变更闻起来不对。

现有自动审查工具可以更好地完成这类分析。更值得关注的问题是为什么要做这个变更，以及为什么行为应该改变。我认为人仍然需要掌握这些背景，同时我们也应重新考虑，是否每个拉取请求都需要人逐行检查。

我提出的流程从团队审查技能开始。在 WorkOS，GitHub 代码所有者机制可以识别涉及我所在开发者体验团队的变更。我们可以维护一个脚本或技能，写明 DX 工程师至少会检查什么，并随着团队要求变化持续更新。

接下来，轻量级分类器可以判断变更是否过于复杂、是否存在重大风险，以及它是否完成了声称的工作。专门的自动审查工具再增加一层检查。如果任何环节失败，就将拉取请求交给人工；如果全部通过，我建议让足够安全的变更自动合并，避免阻塞另一位工程师。

出了问题，就审计整个流程：团队技能或自动审查工具下次能否捕捉到？修复代码并更新防护措施。同时向人工提供变更内容及原因的摘要，包括业务逻辑是否变化、考虑过哪些替代方案。

审查还应提供证据，证明变更做到了承诺的事。证据可以是截图、视频、测试结果、命令输出、冒烟测试，或清晰的手动复现步骤。随着我们对这些检查建立有依据的信任，日常人工验证可能会逐渐减少。

具体的审查技能取决于团队。DX 团队和平台团队的标准不同，每个团队都可以定义自己负责范围内哪些情况需要人工关注。团队维护这些标准，据此决定哪些变更需要升级处理。演示、幻灯片和参考资料都可以在 fruitfly.review 找到。