[译] 我知道你在 Vibe Coding
我本不应该在乎这件事。我一点也不想关心别人的代码究竟是怎么进入 IDE 的——不管是手写的、从技术论坛复制的、通过提示词让大模型生成的，还是跑了一场“给无限只猴子无限时间敲出解决方案”的模拟实验。
我真正在乎的，是到底有什么东西被合并进了代码库。
每当我按下“Approve”按钮时，我心里关心的其实就只有这几件事：它运行出的结果是否正确？下个季度其他人还能看懂吗？之后如果需要修改，别人改得动吗？
但最近，我开始频繁注意到一些细节，这些细节无不反应这段代码出自 LLM 之手。我说的不是那些啰里啰嗦、重复冗余的注释（这些我还能忍受），甚至不是它们特别钟爱的 switch 语句。
我知道它是由 LLM 生成的，因为它的写法是团队里任何一位人类开发者都绝不会写出来的。
它功能正常、逻辑清晰、有测试覆盖，甚至单看代码本身也是可维护的。但它的写法完全没有遵循我们团队公认的项目规范。我一眼就能看出它不是人类写的。
Vibe Coding 的坏味道
因为当项目里明明已经有一套现成的数据请求库时，没有任何人会从零手写一套兜底了所有边界情况的 HTTP 请求逻辑。
没有任何人会重新实现一堆在另一个模块里早就存在过的工具函数。
当系统本身就支持在模块级别进行配置时，没有任何人会直接去修改全局配置。
当我们全盘都在使用函数式风格时，没有任何人会突然写出一个 Class。
我并不想打探你是怎么写出来的。我只是希望你能对自己从模型里导出的东西负点责。这种代码，在两年前你自己是绝不可能写出来的。
我们花费了数十年时间摸索出的设计模式与开发标准，正是为了构建可维护的软件。
这从来都是软件开发中最大的挑战——把一套系统推上线，并且在此后数年里你依然有能力去维护它。任何人都能够胡乱堆砌出一套勉强跑得通的实现，缝合出一个弗兰肯斯坦式的代码怪物来应付差事。
但我们真正苦苦挣扎的阶段，始终是在代码推向生产环境之后，该如何对其进行演进和修改。
速度是最崇高的美德吗？
几天前，我去了一家社区咖啡馆，店里正好在培训一名新咖啡师。外面排着长队，这位新人手忙脚乱，急急忙忙地赶着做下一杯，把咖啡和牛奶洒得到处都是。
如今的我们也退回到了这个阶段：只顾着仓促推出下一款软件，误以为“快”就是最崇高的美德。
可人们真正想要的，是一杯好喝的咖啡，哪怕需要为此稍微多等片刻。
我原本以为自己未来只会对财务人员发火——因为他们总在想方设法压缩预算报表上的数字；可如今让我深感失望的，却是身边的同行开发者：为了在软件开发中“速通”，他们轻而易举地将曾经坚守的所有工程原则通通抛诸脑后。
我真正想要的是什么
我不在乎代码是怎么进到你的 IDE 里的。
我只想看到你在乎。
我希望大家能在乎代码质量，在乎一致性，在乎自己的工作所带来的长期影响。大语言模型是工程史上的奇迹，我对创造它们的人怀有无比崇高的敬意。但我们的本职依然是构建软件，而不是把未经雕琢的原型直接搬上生产线。
去写更好的提示词。提供更详尽的上下文与描述。明确告诉模型该使用哪些既有库。提供可供参照的代码范例。拆分出更小、更专注的文件。这里没有什么全新的魔法原则——遵循那些早已存在的工程准则即可。
千万不要把代码库的可维护性，拱手托付给模型的神经网络权重。