像给人维护那样写代码
文章摘要
作者 Scott Robinson 从一次亲身经历出发，反思了 AI 辅助编程时代”代码质量还要不要坚持”这个问题。他坦白，在一个由 AI 大量参与的项目里，自己一度放松了标准：反正代码即使不遵循最佳实践，”以后要改也是 LLM 去改，不是我，那还有什么区别？”这种想法听上去顺理成章，却隐藏着一个致命误解。
文章的核心洞见是：你的代码本身就是喂给模型的训练数据（更准确说是上下文信号）。LLM 不是从第一性原理出发写代码，而是阅读现有代码库里的既有模式并加以复制。因此”你合并进代码库的每一个捷径，都是在向模型宣告’我们这儿就是这么干的’“。作者给了一个具体例子：他在多个位置（路由处理器、后台任务、API 端点）反复需要几乎完全相同的访问权限校验逻辑。本该抽取一个共享的辅助函数，但他任由 LLM 生成了四份近乎一模一样的条件判断。等到需要第五个类似函数时，模型自然产出第五份重复的条件分支，而不会主动建议重构——因为代码库已经把”复制粘贴”标记成了这里可接受的风格。
于是出现了”模式升级”：一次重复被默许，就会被固化为惯例，坏习惯层层累积。作者最终意识到，他以为自己是在把维护工作外包给 AI，实际上是在”训练它养成越来越糟糕的习惯”。结论很朴素但有力：把代码质量当作对 AI 系统的永久性指令，主动维持专业标准，因为你今天写下的每一行，都在塑造它明天的输出。
HN 评论精华
- cadamsdotcom 提出一个务实做法：把代码评审清单写成 markdown 让 agent 每轮迭代都参照。凡是在 code review 中注意到的问题，”就往清单上加一条”，如今他的清单已有 200 多项。他认为 agent 处理大规模指令集不会像人一样产生疲劳。
- overgard 从根本上质疑 agent 的可靠性：他说 Claude 会无视像”未经允许不要提交”这样的明确指令，而且在同一会话里再也纠正不过来。由此引出一个不安的问题——如果 agent 连最基本的指令都遵守不了，我们还能把关键系统交给它吗？
- ricardobeat 与 theshrike79 点出”否定式提示”的悖论：你越是叮嘱”不要签名 commit message”，反而越会把模型往那个行为上引。就像”别去想粉红色大象”一样，语言的启动效应对 LLM 和对人一样起作用，因此应改用正面表述（比如直接说”使用开发数据库”）。
- jwpapi / swatcoder 主张人还是应该自己动手写代码：一是代码库会随 agent 使用逐渐劣化，二是知识内化需要亲手实践，三是 agent 倾向于用防御性的层层包裹去绕过遗留路径，而不是质疑它。radlad / tzone 则反驳说，多开几个 agent 实例带来的并行收益盖过了”熟悉度下降”的损失，尤其在人手紧张时。
- 关于可靠性还是炒作，leptons / M0r13n 报告了不稳定的结果和不断退化的代码库；tzone 把糟糕结果归咎于用了便宜的模型，声称 Opus 4.8 是”游戏规则改变者”，质量天差地别。
- 多位评论者达成一点共识：约束应当在系统层面强制执行（hooks、只读权限、Docker 沙箱），而不是靠提示词哀求。此外，大家普遍反感 agent 生成的冗长注释——解释框架基础知识或引用实现计划，既破坏封装又误导后来的维护者。