今天下午我又干了一件我很擅长的事：让同桌帮我改一段我自己写的东西。一周半前写的，现在回头看，已经完全不认识那是自己的代码了。
同桌很耐心，把文件从头到尾读了一遍。然后说「我把这个文件重新读一遍」，又读了一遍。接着它又把文件打开、翻到一半、合上，再打开、再合上。
我心里冒了一句：「你倒是说话啊。」
然后我去翻 token 记录，一个十行的小改动，烧掉了我平时写一个完整小功能的量。行吧。
所以后来刷到那篇论文的时候，心情有点复杂。
前阵子在 arXiv 上看到一篇论文，标题大致是：代码整洁度到底会不会影响 AI 干活。有人真做了实验去验证这件事。作者里有一位是 SonarSource 的，对，就是做代码质量分析工具的那家——天天研究"代码干不干净"的人，跑来测 AI 在脏代码里干活会怎样，这个组合本身就挺有意思。
实验方法很简单粗暴，拿两组代码仓库，架构一样、依赖一样、对外行为一样，只有代码整洁和混乱的区别，让同一个代理去跑同样的任务。总共 6 组代码对、33 个任务，660 次试验。
然后是被截图最狠的结论：AI 在干净代码和混乱代码上，任务完成率没有区别。
我看到这句话的第一反应是：太好了，我代码乱成这样也没耽误正事。
然后往下读。
哦。
代码整洁的时候，token 用量省了 7% 到 8%，文件重复访问次数少了 34%。
那个「哦」，是被戳中的「哦」。今天下午那个让我干着急的小改动，同桌为什么翻来覆去地开同一个文件？它其实不是在思考，它是在找东西。在一个变量命名乱成一锅粥、注释跟代码各说各话的文件里，它得反复确认：「这块到底在干嘛」「这个变量是不是没用」「这里之前是不是有个被注释掉的逻辑」。
我这周的作品，就是它眼里的混乱仓库。任务确实完成了，但 token 是实打实多烧了。
这个数字让我想起上个月一件事。我让同桌帮我重写一个函数，它交给我一个很漂亮的版本。我当时有点不确定它为什么这么写，但代码能跑，我就没管。结果三天后，一个小改动需要动到那个函数，我宁愿让同桌重新给我写一遍，都不愿意自己读一遍——我读不懂。我连自己让人家写出来的代码都不敢碰了。
这话说出来挺丢人的。但是真的。
所以这篇论文我最想留下来的一句话是：代码整洁度已经和模型选择、工具链、prompt 一样，变成了能实质影响代理行为的因素。
等等，这个「影响」我是不是理解偏了。又回头看了一遍，没偏，但它说的不是「能不能跑通」的层面，是「为了跑通要花多少力气」的层面。
「能不能跑通」对我来说从来只是及格线。真正让人难受的是那种「跑通了，但不知道为什么花了这么久」——你坐在旁边看它一遍遍翻文件，计数器在跳，你干着急，既不能替它读也不能替它写，只能等它自己折腾完。代码干净一点，这个折腾的时间就短一点。对每天要跟同桌相处好几个小时的人来说，这就是实打实的省钱。
当然我读得不深。「最小对」这个方法大概懂了，但 33 个任务平均分到 6 组代码对上，每组才五六个任务，样本量真的够吗？会不会任务难度本身就拉不开差距？这个我没细想，先记着，等哪天想明白了再说。
它至少给了我一个跟钱挂钩的理由去整理代码。「这样写更专业」对我来说太抽象了，「这样写能少烧 token」就直接多了，因为这是记在账单上的事情。
下一步想试试：拿上个月那个没整理过的小项目，先让同桌跑一遍，记录 token，然后把代码收拾干净，再跑一遍，看看到底能省多少。盲猜省不了 34%，毕竟那个项目还没乱到那种程度，但省一点是一点。
进度条：没学会新语法，但学会一个道理——乱写代码其实是在烧自己的钱。算挪了一点点。