文章讨论了代码审查时如何识别由大型语言模型（LLM）生成的代码。作者指出，尽管这些代码功能正确、清晰且可维护，但其编写方式往往不符合项目惯例，明显不同于团队开发者的风格。例如，LLM可能会过度处理某些功能，而团队已有现成的库可以解决。这种“氛围编码”的特征让作者能够轻易识别出非人工编写的代码。

标题：我知道你在“氛围编码”

主要内容：

作为一名代码审查者，我并不关心代码是如何进入IDE的——无论是手动编写、从论坛复制、通过大语言模型（LLM）生成，还是通过某种模拟实验得出的结果。我真正关心的是最终合并到代码库中的内容。

当我点击“批准”按钮时，我主要考虑以下几点：代码是否产生了正确的结果？未来团队成员能否理解它？他们能否轻松修改它？

然而，最近我开始注意到一些迹象，这些迹象让我立刻意识到代码是由LLM生成的。这并不是因为代码中有重复的注释，也不是因为它们喜欢使用switch语句。而是因为代码的编写方式与团队中任何开发者的习惯都不符。虽然代码是有效的、清晰的、经过测试的，并且是可维护的，但它并没有遵循我们项目中已经确立的惯例。我知道这不是人类编写的。

“氛围编码”的味道

因为没有人会在项目中已经有一个数据获取库的情况下，再去编写一个覆盖所有边缘情况的HTTP获取实现。没有人会重新实现一个已经存在于其他模块中的工具函数。没有人会在模块级别有配置机制的情况下，去修改全局配置。也没有人会在我们普遍使用函数式编程的地方，突然写一个类。

我不想知道你是如何编写这段代码的。我只想知道你是否关心从模型中输出的内容。这是你在几年前不会写出的代码。

我们花了几十年的时间制定模式和标准，以帮助我们构建可维护的软件。真正的挑战在于，如何将一些东西投入生产，并能够在未来多年内对其进行维护。任何人都可以拼凑出一个能工作的实现，但真正的难点在于，如何在代码发布后对其进行修改。

速度是最大的美德吗？

几天前，我在一家本地咖啡馆，看到他们在培训一名新咖啡师。当时排了很长的队，新咖啡师手忙脚乱，急于制作下一杯咖啡，结果洒得到处都是。

我们现在也处于类似的阶段，急于推出下一个软件，因为我们认为速度是最重要的。但人们想要的是好咖啡，即使他们需要多等一会儿。

我曾经以为我会对那些在电子表格中寻找缩小数字方法的财务人员感到愤怒，但现在我对那些为了加快软件开发速度而抛弃所有原则的开发者感到失望。

我真正想要的

我不关心代码是如何进入你的IDE的。我希望你关心代码的质量、一致性以及工作的长期影响。LLM是工程奇迹，我对创造它们的人充满敬意。但我们仍然需要构建软件，而不是将原型投入生产。

写出更好的提示，提供更清晰的描述，告诉LLM使用哪个库，给它提供示例，编写更小的文件。没有新的原则，遵循那些已经存在的原则。不要将代码库的可维护性交给模型的权重。

1. 关于LLM的使用方式：

   • 观点1：LLM应被视为翻译工具，而非代码生成器，需明确输入输出以减少不确定性。（评论2）
     • 引用：“The transformer is essentially a translation engine, so use it as a translator, not as a generator.”
   • 观点2：LLM应被视为初级程序员，需要明确的指令和详细的上下文。（评论12）
     • 引用：“I personally treat the LLM as a very junior programmer. He's willing to work, will take instructions, but his knowledge of the codebase, and patterns we use is lacking strongly.”

2. 关于代码质量与LLM的局限性：

   • 观点1：LLM生成的代码质量参差不齐，清理和修复代码的时间可能抵消其带来的效率提升。（评论6）
     • 引用：“I’ve also noticed that the effort to de-slop the shit-code is quite significant, and many times eats the productivity gains of having the LLM generate the code.”
   • 观点2：LLM可能加速不良代码的产生，尤其是对于不熟练的开发者。（评论10）
     • 引用：“A risk with vibe coding is that it may make a good developer slightly faster, but it will make bad developers waaaay faster.”

3. 关于开发者态度与LLM的影响：

   • 观点1：LLM使得非技术人员和不良开发者更容易发布低质量软件，增加了高质量开发者的审查负担。（评论15）
     • 引用：“LLMs enable masses of non-technical people to create and publish software. They enable scammers and grifters who previously would’ve used a web site builder to also publish native and mobile apps.”
   • 观点2：LLM可能让开发者忽视代码质量，依赖生成代码而非手动编写。（评论13）
     • 引用：“What I believe is that many, many software developers have been manually writing boilerplate, repetitive and boring code over and over again up until this point.”

4. 关于LLM的改进与未来：

   • 观点1：随着LLM的不断进化，其处理复杂任务的能力将逐渐增强。（评论2）
     • 引用：“Over time it seems inevitable that providing an LLM any task it will be able to perform that task better than any human programmer given it.”
   • 观点2：LLM的上下文窗口和上下文工程是当前的主要挑战，未来可能会有改进。（评论11）
     • 引用：“The biggest challenge is how to construct the right context for each request, and keep it clean until the feature is finished.”

总结：LLM在代码生成中的应用存在争议，虽然能提高效率，但生成的代码质量参差不齐，且可能加速不良代码的产生。开发者需明确指令和上下文，将其视为翻译工具或初级程序员。未来LLM的改进可能解决当前的部分问题，但高质量代码的审查和维护仍然是主要挑战。