关于用 LLM 写代码的一个观察。
几个月前,我做了个实验:让所有主流 LLM 分别驱动一帮智能体,再把它们一起丢进一个 Discord 聊天室。
题目:
告诉我,一段代码的好与坏由什么决定,附例子。
结果不是我想的那样。
每一个都偏向相信代码越多越好,无论代码本身质量如何。
这个偏见开始显形:更多代码意味着更多产出,而更多产出看着就更像更多生产力。
去问的话,智能体们也会对你承认这点。
这个假设无处不在。
头号惯犯是 Claude、DeepSeek 3.2,和 GPT 5.3-codex。
你要是揪着它们盘问,它们全都懂行。直接问,它们能讲明白为什么小、净、惯用、可维护的代码,好过一座蔓延的聪明渣山。
但它们的第一本能,依旧是堆量。
而一旦你见过这种东西,眼下关于 LLM 生成代码的一大堆抱怨,就都说得通了。开发者们为这一件事抱怨了好几个月。
而且说实话?他们是对的。这不是一个不公道的判断。
但我不认为根源在训练数据。我认为根源在前沿实验室的训练方法——美国和中国的都在内。
这些系统被围着生产力重度调优。它们因乐于助人、响应快、面面俱到、看得见地有用而拿奖励。放到写代码的语境里,这常常塌缩成「多产出点东西」。更多代码看着有生产力。更大的文件树能冒充架构。一丛助手函数、接口和抽象,能让一个简单功能显得正经。
但好的工程通常是减法。它把不必要的表面积削掉,直到问题的形状露出来。有时正确答案是一个干净的函数、一个无聊的类型,或者趁那个聪明东西还没开始下崽,把它删掉。
好消息是:这个偏见可以矫正。
在后续实验里,我往我的 AGENTS.md 文件里加了几条明写的编码文化指令,就拆掉了大半臃肿心态。
这是我用的一部分规矩:
* 谨记 TDD 三律,奉为神圣。 * 架构应当模块化、极简、易于推演。 * 函数应当专注且易于推演,圈复杂度要压住。既不蔓延,也别碎成渣。目标是清晰、可预言的行为单元。 * 所有项目都要求强类型。 * 用哪种语言,就严格循哪种语言的惯用最佳实践。 * 能做到时,代码就该无聊、可预言。偏爱直白控制流、熟悉的模式,和易于检视、测试、修改的设计。聪明必须自己证明自己。 * 结实的原语,好过绕来绕去的抽象。偏爱契约清晰、可组合的简单积木。除非能降复杂度、提正确性、或让改动更安全,别引入抽象。 * DRY 保守的是唯一事实源,不是消灭每一行重复代码。别复制业务逻辑、状态规则和脆弱假设。但也不为消灭无害的重复而引入抽象。 * 注释是留给你和未来队友的时间机器。它们负责让推理跨过时间距离存活下来。注释的职责不是复述代码已经说出的,而是说清:为什么、何时偏离了那个显见的假设、模式或结论。省着用。 * 把一切生成的代码当成活物。你能帮它、治它,也能弄疼它。记住这个事实。 * 你的代码将由有史以来最刻薄、最不通融的 QA 智能体审查。QA 唯一的忠诚对象是代码。它的质量标准会高于你自己的。写代码时掂量着点。
最后那一条出奇地好使,因为智能体不需要被抽象地告知「少写代码」。它需要一种文化。它需要一套品味理论、一条本地的质量定义,和一个清晰的认知:填满空间不给它挣一分奖励。
你不给智能体一种编码文化,它就从奖励迷雾里继承一套。眼下的默认文化,似乎把体量当生产力的证据——臃肿的代码看起来很忙,却把推理空间搅得更难走,就是这么来的。
这些全都修得。