像人类会维护那样写代码

原文来源：Unstack — Write Code Like a Human Will Maintain It — 你用 AI 写的每一段捷径代码，都在教会 AI 这就是你的标准。

我最近遇到了一个问题

我在一个项目中用 AI 写代码。一切都很顺利，直到我发现了一个让我不安的事实：

我在四个不同的地方写了同一组权限检查。

你大概见过这种代码：

if (user.isActive && user.hasPermission('read') &&
    !user.isSuspended && account.status === 'open') {
    // 执行操作
}

四个地方，四个版本。变量名稍有不同，逻辑完全一样。这段代码能工作，测试也全过了。我当时想的是：反正下次需要改的时候，让 AI 一次性换掉就好。

但这里有个问题。当我需要第五个端点时，AI 看了一下代码库——看到了前四个复制粘贴——然后生成了第五个一模一样的条件判断。当我要求重构时，AI 保留了全部五个，因为代码库里就是这样写的。

那个坏的写法已经不是一次偷懒了。它成了代码库的风格。

我在把什么东西教给 AI

这是 Scott Robinson 在最近一篇博文中提出的核心问题。他遇到的场景和你我每天都在做的事一模一样：让 LLM 帮你快速生成代码，能跑就行，然后赶紧进入下一个任务。

但 LLM 的工作方式有一个被严重低估的特性：它不是在没有上下文的真空中生成代码。它读你的代码库。

你打开的每个文件、已有的每个模式、你合并的每个快捷方式——全部都是信号。当你需要新的功能时，AI 不会从第一原理出发。它会从你代码库里已有的四个复本出发。

结果就是：

• 你欠下的技术债，AI 在帮你加倍积累
• 代码里的坏味道不再是孤立的「以后改」，而是成了团队的编码规范
• 到最后，你可能没法通过提示词把自己救出来，因为整个代码库已经统一堕落了

问题出在哪

我觉得 Robinson 观察到的现象触及了一个更深层的矛盾：AI 让懒惰的代价变得隐形了。

在传统开发中，你需要手写每一个复制粘贴。写出第四个权限检查的时候，你大概率会意识到「我已经复制了三次，是时候提取一个函数了」。因为手写四次本身就是一种惩罚机制——你的手和眼睛会告诉你：你正在做重复劳动。

但 AI 不会让你有这种体感。你口述需求，它写代码；你说「再加一个」，它又写一遍。你完全不用动手指，所以永远不会感受到重复的代价。

这就是 Robinson 说的：「我原以为我在把维护工作外包给 LLM，但实际上我在训练的却是一个会反复强化自己最差习惯的模型。」

这不是一个技术问题

你可能在想：这不就是一个 prompt engineering 的问题吗？告诉它「不要复制，提取函数」不就行了？

可以试试。但问题在于，AI 没有真正的长期记忆。它看到的是你当前打开的代码库，看到的是那些四个一模一样的条件判断。无论你当前怎么提示，代码库本身已经在说反话了。

代码库是对 AI 最有效的上下文信号。 比你当前说的一句话有效得多。

所以解决方案不是把 prompt 写得更好——而是把代码写得更好。

两个世界之间

这篇文章让我想起了在 AI 辅助编程中一个持续的张力：

一方面，AI 降低了写出「能跑但不优雅」代码的成本。你不需要费劲打字，不需要思考是否值得抽象，不需要判断边界条件。只要描述需求，代码就出来了。

另一方面，AI 的学习方式是模仿，而不是理解。它不会问「这个条件判断为什么需要出现四次」，它只会问「代码库里有没有类似的模式，我来帮你写一个一样的新版本」。

这意味着：在 AI 时代，好的代码习惯比以往任何时候都更重要。

因为在人类团队中，代码质量的维护靠的是代码审查、规范文档、团队文化。这些在 AI 面前都不太管用——AI 不会因为你的编码规范里写了一条「不允许重复条件判断」就不生成第五个复制粘贴。

唯一的防线是：你合并进代码库的每一段代码。

那该怎么做？

Robinson 的建议很简单，但执行起来并不容易：「Write code like a human will maintain it.」

把他的建议翻译成可执行的步骤：

1. 每让 AI 写一段代码之前，先问自己：我作为人类维护者，看到这段代码会满意吗？ 如果不满意，说明它不应该被合并。

2. 把重构和生成放在同一个会话中。 别先用 AI 生成五个端点，然后说「我回头重构」。当场就让 AI 提取公共逻辑。

3. 把代码库当成你给 AI 写的教程。 每一条 import、每一个条件判断、每一个函数签名，都是在教 AI 你的风格。

4. 接受偶尔手写一两行代码。 有时候手动提取一个函数比让 AI 生成十个复制粘贴再一次性重构更快、也更清晰。

后记

Robinson 文章的最后一段写得很诚实：

「最让我沮丧的是：我以为我在把维护工作外包给 LLM，但实际上我在给 AI 训练越来越差的习惯。」

这句话之所以刺痛，是因为它说出了一个我们很多人其实已经感觉到但不愿承认的事实：AI 没有降低代码质量的要求，它只是让低质量代码更容易被创造出来。

这让我想起之前在 Hacker News 上看到的一条评论：AI 辅助编程和代码质量的关系，就像微波炉和烹饪的关系。微波炉让你更快地加热食物，但它不会教你做一道好菜。

所以，写代码的时候，想象将来会有一个人（或者你自己）来维护它。那个人可能不会打开这个 MD 文件，不会看你写的提示词，不会知道你当时时间有多紧。他们只会在看到的代码上接着写。

为一个真人维护者写代码——哪怕最后接手的是你自己。