这套代码不是这里的人写的。
但录制仍然知道哪里坏了。

在你接手的代码上，一个 bug 最贵的部分不是那处改动，而是找到这处改动该落在哪里——在一个系统里，而它当初的种种理由，已经随着当初的那些人一起离开了。

问题

陌生代码里的一个症状，可能来自四个地方中的任何一个，而排除掉其中三个的唯一办法，是把四个都读一遍。这是慢活，很难在路线图面前说得过去，也正是那种悄悄被跳过的活：一份扛过了一下午搜索的报告，往往被标成无法重现而关掉，而不是被修好。安全网通常也很薄——接手来的系统很少会带着一套谁都信得过的测试——所以哪怕看起来正确的改动，也是一处没人能证明无害的改动。而真正能让这一切一下子塌缩的上下文，也就是那个分支为什么在那里、上一位维护者当时在绕开什么，恰恰是交接时没有一起交过来的东西。

Snag如何提供帮助

这次尝试是分级的，而不是一锤子买卖，而在答案并不显然的时候，这一点最要紧。先是一遍廉价的初筛，读取捕获到的内容，判断这件事到底能不能在代码里修好，于是没有精力被花在一次第三方故障上。挺过初筛的那些，进入一个按代码仓库实际使用的技术栈搭出来的沙盒，代理可以在那里搜索代码，并把录制的会话一步步回放，亲眼看着故障发生——正是这一步把一个症状变成一个位置。当一份报告很严重，或者分流的置信度很低，或者根本没有明显的代码区域可看时，流程会把它交给一个能力更强的模型，而不是接受第一个看起来合理的答案；证据和沙盒都是同一套，无论走哪条路都只算一次修复运行。然后，在这些东西送到你面前之前，还有一遍独立的复核，拿这处改动去对照证据，并且可以把它打回去重做。

你得到的回报

一处改动，连同它的推理和背后的证据一起送来——在一个没有人拥有完整心智模型的系统上，这份推理差不多和那份差异一样值钱。审阅也不会被白白丢掉：你的团队合并掉的那些修复，以及审阅者一路上做出的修正，会变成后来的尝试在同一个工作区里查得到的材料——所以当那个角落再坏第二次时，尝试是从你的团队当初的判断开始的，而不是从零开始。没有人点头就不会合并，而在接手来的代码上，这恰恰是要紧的那一半：对一个你还在学的系统，判断权留在必须住在里面的那些人手里。

人们实际会问的问题

我们的堆栈比较老旧，而且有点特殊。沙盒环境能应对吗？

部分如此，关键就在这里。如果技术栈被识别，沙箱就会构建成与之匹配的状态——安装依赖项，配置测试运行器——并且在提供任何修复方案之前，会先将更改与你的测试套件进行比对。如果技术栈未被识别，代理仍然会读取和搜索代码，并提出修复方案；但它目前还无法在沙箱内运行你的测试，因此验证步骤需要由你来完成。

是什么阻止它给我们提供一个看似合理的解决方案，却应用到错误的地方？

它得先过两关。第一关是你自己的测试，如果有的话，必须先通过，任何东西才会被开出来。第二关是一遍独立的复核：它拿这处提议的改动去对照捕获到的证据，可以通过，可以带着具体意见要求返工，也可以整体否定这个思路，把报告退回分流。这个回路是有上限的，所以一份它拿不定的报告最后会落到人的面前，而不是一直打转。

我们的源代码最后会进到某个模型里吗？

不会。工作发生在代码仓库的一份私有副本里，而这份副本在运行结束时销毁。留下来的是报告里的证据，以及开过些什么的历史——从来不是你的源代码——你的代码里也没有任何东西被用来训练模型。后来的尝试确实会在你的代码库上做得更好，但靠的是到你自己已合并的修复里去查，而不是从中学习：按工作区各自进行，绝不跨工作区。

这些细节的来源

本页面不涉及任何其他产品——所有信息均为Snag原创。如有信息过时，请发送邮件至 admin@dvcllc.io，我们将予以更正。