为人类维护而写代码

背景

在大型语言模型（LLM）辅助编程日益普及的今天，许多开发者开始依赖 AI 自动生成代码。这种做法看似提高了效率，却也悄然催生了一种“代码质量放任”的倾向。Hacker News 上的一篇讨论文章（标题：Write code like a human will maintain it）揭示了这一现象背后的隐性风险：当开发者把维护责任“外包”给 LLM，而不再主动遵守最佳实践时，AI 反而会模仿并固化代码库中的坏模式，最终导致代码难以维护。

核心内容

文章以第一人称叙述了一个真实场景：作者在一个用 AI 辅助构建的项目中，发现自己在代码质量上“放水”了。他需要多次进行相同的权限检查——分别在路由处理、后台任务、API 端点、webhook 等多个地方。每次他都直接描述需求，让模型生成可用的代码，然后合并。最终，每个位置都出现了几乎相同的条件语句：

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

本质上就是重复的四个条件，变量名略有不同，逻辑几乎复制粘贴。作者清楚有更好的做法——比如提取一个共享辅助函数。但他没有这样做，因为“代码能跑通，测试能通过，而且反正以后改代码也不用我动手，让 LLM 去处理就行”。

然而，LLM 并非在真空中写代码。它会读取你的代码库——当前打开的文件、已有的模式、最近的更改。每一次你在代码库中合入的“捷径”，都会成为 LLM 理解“这里做事风格”的信号。下次你再要求 LLM 为另一个端点编写相同的权限检查时，它不会从头开始推导最佳方案，而是参考代码库里已有的四个副本。于是，第五个端点得到第五份重复的条件判断。当你要求重构时，模型会保留全部五个，因为你的代码看起来就是那样——坏模式不再是偶然，而是被视为你的“风格”。

作者指出，如果放任这种情况持续，当你想修复时，真的能指望 LLM 捕捉到每一个实例吗？几个重复条件可能不算灾难，但代码坏味道会累积。每个复制的条件、每个“上帝函数”、每个“以后再来清理”的合并，都在为下一次提示增加一层不良信号。最终，你将无法轻易通过提示词摆脱困境——除非亲自撸起袖子动手清理。

最令人沮丧的是：作者原本以为自己在把维护工作外包给 LLM，但实际上，他正滑向一个“训练 LLM 越来越坏习惯”的斜坡。

关键要点

• 依赖 AI 生成代码会让开发者降低对代码质量的要求，尤其是当“以后改代码由 AI 负责”的心态出现时。
• LLM 会观察并模仿代码库中的现有模式，即使这些模式是坏的。重复的代码块会被视为“规范”，后续生成会继续复制。
• 代码坏味道（如重复条件、过长函数）会累积，每次合入一个“捷径”都增加了未来提示词的噪声，使 AI 更难生成干净的代码。
• 将维护责任完全“外包”给 LLM 是一种错觉：实际上你正在训练 AI 学习并强化坏习惯，最终导致代码库难以修复。
• 核心原则：Write code like a human will maintain it（像人类要维护它一样写代码）。因为 LLM 是一块海绵，它会吸收你的一切做法，并重复输出给你——所以请确保输出的是好的代码。

意义与影响

这篇文章揭示了一个在 AI 辅助编程时代容易被忽视的教训：代码质量不会因为“由 AI 生成”而自动消失，反而可能因为开发者的惰性而加速恶化。LLM 的“学习-模仿”机制使得任何短期的偷懒都会变成长期的陷阱。将最佳实践（如 DRY、单一职责、可读性）抛诸脑后，等于在为未来的自己和协作者埋下隐患。

对开发者而言，这意味着需要重新审视与 AI 的协作方式：AI 是效率工具，不是质量保险。合理的做法是在编写代码时依然应用人类应有的质量标准，因为 AI 无法替你承担“代码的可维护性债务”。对团队而言，应当建立代码审查机制，确保 AI 生成的代码也符合项目规范，防止坏模式通过“复制-粘贴-换词”的方式蔓延。

长远来看，这一观点也提醒 AI 工具的设计者：未来的编码助手不仅要能生成正确代码，还应主动检测并拒绝延续代码库中的坏模式，甚至建议重构方案。但在那之前，责任仍然在开发者自己手中——写代码时，想象一下最终维护它的是另一个人类（甚至未来的自己）。