Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

引言 — 智能体时代被重写的老格言

“写代码时，要当作将来由人来维护”是软件领域最古老的建议之一。它的道理一向很简单：一行代码只写一次，却会被读上几十次，所以要为读代码的人优化，而不是为写代码的人优化。

精巧的一行技巧、省下的按键、对机器友好的小聪明，全都会输给那种下一个人一眼就能看懂的、平凡、乏味、显而易见的代码。几十年来，那个“下一个人”毫无疑问就是人。

2026 年 7 月 10 日，Scott Robinson 以正是这个标题发表了一篇短文，并因为把这句老话带到了一个新的场景而引发热议。他的观点，并非对匠人精神的那种常见怀旧。

它讲的是，当这条建议里的“下一个维护者”是大语言模型时，会发生什么。而正因为如今我们中的很多人，已经把要发布的大部分代码交给智能体来编写和修改，这个问题与其说是感伤，不如说显得迫切。

Robinson 先以反讽的口吻抛出一套听起来颇有道理的自我开脱：“LLM 最棒的一点，就是它整天替你写代码。谁还在乎 DRY 呢？”

如果 AI 会自动更新分散在四个文件里的同一段冗长条件判断，那还有必要费劲抽取出一个公共辅助函数吗？用他的话说，“以后真要改什么，出手的是 LLM，而不是我”。

他举的具体例子，是一段需要出现在路由处理器、后台任务、API 端点、Webhook 这四个地方的访问权限检查。他没有写一个公共辅助函数，而是让模型把几乎一模一样的副本粘贴到每一处。

if (user.isActive && user.hasPermission('read') &&
    !user.isSuspended && account.status === 'open') {
    // do a thing
}

接着，让这篇文章值得一读的转折来了。LLM 并不是孤立运作的。它会读你已有的代码，并把它当作风格指南。用 Robinson 的话说，“你合并进代码库的每一条捷径，都是在暗示：这里就是这么干活的”。

所以那段重复的条件判断，并不只是日后要偿还的技术债。它是此时此刻你正喂给模型的训练数据。模型看到四份副本，得出“重复就是这里的惯例”的结论，然后一丝不苟地造出第五份、第六份。

坏味道不断累积，而模式一旦固化，就更难扭转，因为模型会看着周围的例子，持续把它复制下去。Robinson 收尾的那句话一针见血：“LLM 是一块海绵，把你做的一切都吸进去，再原样返还给你。所以，务必让它吸到的是好东西。”

这是个诚实的问题，我的答案是“成立”。只不过，理由要比“整洁的代码是一种美德”更锋利一些。

先从一个事实说起：维护者绝不会只有机器。总得有人来评审 diff，而如今评审才是真正的瓶颈——因为智能体产出代码的速度，远快于人类能够审阅的速度。

易读的代码，本身就是易评审的代码。清晰的命名和短小的函数，能让评审者在凌晨两点处理故障时，几秒钟就确认意图，而不必去逆向拆解那堵由“聪明”砌成的墙。所谓为读代码的人优化，从一开始关乎的就不是写代码者的舒适，而是评审者的舒适——而这位评审者，哪儿也没去。

接着，Robinson 自己的论点比 DRY 又深挖了一层。由于 AI 会原样映照它所读到的东西，你的代码仓库不知不觉间就成了你在不停书写的提示词。一致且拆分得当的代码库，会把下一代输出引向好的方向；而一团糟的代码库，则会以机器规模把自己的混乱返还给你。

在围绕这篇文章的讨论中，实践者们指出了一种相关的退化：在反复迭代的过程中，模型对代码的把握与代码本身的简洁性会一同崩塌，输出质量也随之下滑。失败的形态并非某一个糟糕的函数，而是模型把你的坏习惯，放大到成百上千个文件之中。

对于把“为人类而写”读得过于随意的做法，我想提出异议。它并不是一张许可证，让你可以凭个人喜好把一切都手工打磨一遍。在同一场讨论里，有一点说得很清楚：否定式的指令，或是冗长的风格检查清单，反而可能拉低智能体的表现。

像 linter、格式化工具、类型检查器、静态分析这类确定性的护栏，比提示词里的散文能更稳定地强制一致性。“为人类而写”和“让工具来强制执行”，并非彼此竞争，而是同一项工程。

那些经典做法，没有一条被废弃。恰恰相反，智能体时代抬高了这些习惯的回报率——因为你留下的每一个模式，都是日后会被复制的模式。

清晰的命名：这是杠杆最大的习惯。名字是一段代码被压缩后的意图，无论是人类评审者还是模型，在第一次猜测某样东西是做什么的时候，最先看的线索就是它。
小而单一职责的函数：易读、易测试，也让智能体更容易复用它，而不是在旁边另造一个略有差异的变体。
解释“为什么”而非“是什么”的注释：代码本身已经说明了它在做什么。好的注释捕捉的是：为什么放弃了那个显而易见的做法。这是无论人还是机器，都无法仅凭语法复原的上下文。
只在能消除真正分歧之源时才 DRY：Robinson 的例子就是一个教科书级的好范例。一条访问规则，在一处修改，处处正确。
把枯燥的一致性交给确定性工具：工具不会疲倦，不会顶嘴，还能给智能体一个必须对齐的明确标靶。

有一句诚实的但书：DRY 并非免费，“为人类而写”也不是说一有机会就去做抽象。过早的抽象本身就是一种维护负担，硬把两段互不相干的代码塞进同一个辅助函数，比一点点诚实的重复还要糟。

判断这究竟是同一条规则，还是今天恰好长得相似的两条规则——这正是留给我们、而非留给模型的那份关于意图的工作。这种判断，是任何海绵都吸不进去的、为人类而写的一部分。

“写代码时要当作将来由人来维护”这条建议，在 AI 智能体登场后依然存活，但它的重心发生了转移。从前，它讲的是几个月后端详你的代码、皱起眉头的那个未来的人。

而如今，它也讲的是今天下午读你仓库、并断定“这里的常态就该是这样”的那个模型。这两位读者，奖赏的是同样的东西：清晰、一致的结构，以及不借助调试器也能复原的意图。

机器并没有让这句格言退休。它只是用一种更快、也严苛得多的方式，逼问我们究竟有没有真心实意地遵守过它。