工程师小帮手？瑞典团队开发出有人类修Bug 水准的机器人

软件开发过程中Bug 的存在无可避免。对工程师来说，「找Bug 修Bug」是一趟没有终点的旅程，工作中必须为此消耗大量时间与资源，因此开发者多半都非常期望能有快速、高质量的机器人来搜寻错误代码并协助修补。

修Bug 是所有软体开发计画的常见过程，电脑科学家早就知道自动化编写修补程式理论上可行，但不清楚的是机器人程式能否像人类一样快速完成这项工作并达到相同的品质。以目前来说，尽管许多研究人员已开发出可自动完成这项过程的机器人，但不是速度太慢就是写的代码不够好到能用。

经过数年努力下，瑞典皇家理工学院（KTH）团队成功测试出有人类竞争力的机器人「Repairnator」，团队认为这是自动化修复研究的里程碑。

但团队如何证实Repairnator「具人类竞争力」？其实答案很简单，那便是让Repairnator 伪装成人类开发员，在GitHub 协助产生修补程式来修复漏洞，看看人类开发者能否接受其为对代码库的有效贡献。

团队为Repairnator 建了一个名为Luc Esape 的GitHub 用户，看起来似乎就是研究实验室的软体工程师。为了让Luc 的存在更真实，团队还上传了一张个人照片，让它看起来就像初级开发人员渴望在GitHub 对开源大力贡献。

2017 年2~12 月，团队进行第一次实验，让Repairnator 原型持续在14,188 个GitHub 项目的固定列表寻找错误；Repairnator 每天约能执行30 次修Bug 尝试，在这段期间，Repairnator 分析超过11,500 个漏洞，并能在3,000 多个案例中重现失败，最终开发了15 个案例的修补程式。

但这些修补程式最终都没有被接受，因为Repairnator 不是花太长时间开发，就是编写修补程式的品质过低而没有被使用者接纳。

相较之下，第二次实验就较成功。虽然团队并未具体说明改进Repairnator 哪些地方，但2018 年1~6 月期间，团队让它透过Travis 持续向开发者提供协助。而在1 月初，Repairnator 编写的修补程式首次被人类开发者接受。

接下来6 个月里，Repairnator 继续制作的5 个修补程式也都顺利被人类使用者接纳。团队认为这项令人印象深刻的工作为新一代软件开发奠定了基础，同时也引申出一些有趣的问题。

5 月12 日Repairnator 为GitHub 项目「eclipse/ditto」开发修补程式后，收到开发人员的讯息：「我们只能接受签署Eclipse Contributor Agreement 协议用户的协助修订（Pull Requests）。」

开发者之一的Martin Monperrus 认为，这引申出一个有趣的问题，因为机器人无法签署许可协议。「谁有机器人贡献的知识财产权和责任──机器人操作员，机器人执行者还是修复演算法的设计师？」

在人类和机器人更密切合作之前，这类问题必须解决。但Monperrus 对此非常乐观。「我们相信Repairnator 预先展示了软体开发的某种未来，机器人和人类将会好好合作，甚至携手开发软体。」

*为了让评估者判断能公平，隐瞒Repairnator 身分是必须的，实验结束后，Monperrus 也告知涉及相关内容的开发者。