你打开一个 PR，diff 头部写着 +2,847 −193。commit message 是 update。
【评审席灯光亮起，人类作者露出那种"我知道你要说什么"的表情】
这画面熟得让人想叹气。不用点开我都知道里面长什么样：改了三个文件的那部分是重构，改了五个文件的那部分是顺手，剩下八百行是"先这样，回头再拆"。
二十年了，我们一直这么干。理由千奇百怪：忘了、懒得拆、拆到一半发现拆不动、反正 squash 合并。所以我看到 10 月 8 号 arXiv 上那篇《Runnable Commit Untangling for Coding Agents》的时候，第一反应不是"AI 又来抢活"，是——哦，它把我们这点破习惯学得挺到位。
论文说的现象本身平淡得很：编码智能体倾向于产出又大又杂的补丁，几种不同目的的改动搅在一块，评审的人看不出哪行是为了什么改的。
这不叫 AI 的问题，这叫 AI 学会了人类的问题。区别在于，人搅成一坨是有心理负担的，AI 没有。它一口气吐八千行，语气还特别坦然。
最狠的不是方法，是那个对照组
作者提了个方法叫 RucTangle，卖点是拆解大补丁的同时，保证每一步提交之后代码都还能跑。然后在 131 个智能体生成的补丁上，跟四种已有的解缠方法做了对比。
RucTangle 这边，生成的所有提交历史都可以运行。
基线那边，不可运行的提交历史占比落在 20.6% 到 37.4% 之间。
我盯着这组数字看了很久。你品一下这个含义：这些工具是专门做"把大补丁拆成小提交"的，拆完之后，最差的情况里超过三分之一的历史连跑都跑不起来。
它把一坨能跑的屎，拆成了一串跑不起来的屎。
原来那个 +2,847 −193 虽然丑，它是绿的。拆完变成七个小提交，第三个之后测试就红了，你想 rebase 到那儿验证中间行为，直接卡死。
（友情提示：如果你正在用某个自动拆 commit 的工具，并且从来没在中间那步跑过测试——建议今天别跑，明天再说。）
那条被写进论文的常识
论文里有句话我读了三遍。
大意是：实际工程中，维护者通常不会接受导致代码无法运行的提交。
【掌声，稀疏，礼貌，带一点点心酸】
这句话被写进一篇 2026 年的论文，作为一条需要被明确陈述的前提。它的地位约等于"维护者通常不会接受一个把数据库删了的提交"。
我不是在笑作者。我笑的是这个领域——我们得靠一篇 arXiv 论文提醒整个赛道：喂，中间那步得能跑。
这就像有人发明了一种自动切菜机，论文的创新点是"切完之后菜还是能吃的"。然后这条真的成了 novelty：作者说 RucTangle 是首个在解缠的同时保证每次提交后代码仍可运行的智能体化方法。我信。如果它是第二个，第一个应该早就被人知道了。
第二块实验才让我坐直
他们另外收了 453 个智能体生成的、会引入回归的补丁——回归的意思是原本绿的测试变红了。然后让另外两个编码智能体去修。
把 RucTangle 生成的那套提交历史塞进上下文之后，修复任务的 pass@1 涨了 5.2 个百分点，绝对值。
5.2 个点。
不是那种让人想站起来鼓掌的数字，是那种让人点点头、然后心里算一下"这个量级是真的吗"的数字。我个人更信后者。那些动辄写着"提升 40%"的摘要，我一般读到就滑过去了——分母是什么，只有作者知道，我不点名，反正你都见过。
5.2 个点意味着什么？意味着智能体修 bug 的时候，你给它一份"哪一步干了什么、每一步当时是绿的"的历史，它找问题找得更准。
这事放在人身上叫，翻 git log。
哦。
所以我们花了这么大劲，做出一个让 AI 学会用 git log 的方法。
打住，这句有点损，其实不是这样。人翻 git log 大多数时候也翻不明白，fix、fix2、fix again、修复若干问题，四连击下去信息量为零。RucTangle 的价值不是教 AI 翻 log，是让它自己产出的 log 值得被翻。这俩是两回事。
论文最后还分析了智能体的执行轨迹，看它到底怎么用这些解缠后的提交去定位问题。这段我没法展开——我又不是审稿人，我只看摘要和结论，硬讲细节就成编了。但它至少说明一件事：那 5.2 个点不是瞎猫碰上死耗子，是有路径的。
我想说的那点
论文的结论落在"编码智能体时代引入成熟软件工程实践有价值"，后续议题是"智能体如何主动利用软件历史做出更好的决策"。
这话没毛病，但我总觉得顺序反了。
我们现在讨论的是：AI 怎么利用软件历史。现实里更急迫的是：AI 先把软件历史写得像个人样。一个 agent 一晚上能给你提交四十次，四十一次里有一次能跑，剩下的你在 review 的时候全靠猜。
以前我们担心 AI 写的代码看不懂。现在这个担心可以升级一下了：AI 写的代码不但看不懂，还是以每天四十个 commit 的速度看不懂。
（郑重声明：本文中"一天四十个 commit"为修辞，你的 agent 可能更勤快。评论区报个数，我看看谁的最离谱 🫠）
所以这篇论文真正让我高兴的地方不是 RucTangle 本身，是它把"可运行的中间状态"当成一条硬约束写进了评测里。以前这类工作比的是"拆出来的提交跟人类原始提交像不像"，比的是语法层面的形状。形状像有什么用？像归像，跑不起来。
这一步迈得不小，虽然它迈的方向，是"每次提交都得能跑"。
一个 1972 年就该有的要求。
算了，不纠结年份，我瞎说的，那天我还没出生。