软件工程史上最大实验：当没人读懂代码，系统还能长期运行吗

注意：如果你不喜欢读文字，我在这里的感受可以用这首出奇高质量、绝对洗脑的AI垃圾来精准概括。

披露

我明天开始在OpenAI工作，所以我的观点仅代表我个人，等等等等。

你会发现无数网络评论员迫不及待地宣称，再也没有人需要阅读代码了。你也会发现差不多同样多的人持完全相反的观点——那些不理解自己代码的人将遭遇难以言喻的灾难。那么，到底是哪一种？

我认为现在下结论还为时过早，软件工程领域正在进行其历史上最大规模的实验。它将回答的问题大致是：

即使没有人知道代码如何运作，软件系统能否长期持续运行？

我们很可能在未来一两年内得到某种接近答案的东西。

LLM的局限

我认为非技术人士使用LLM进行编程是一个有趣的案例研究，是软件工程可能发生之事的一个缩影。

我有一群极具创造力和智慧的朋友，他们在商业/产品等领域工作，现在第一次能够做那些以前专属于程序员的魔法般的事情^[1]——比如制作计算机艺术、为想法做原型，或者构建个人工具。我认为这种软件的“民主化”很可能带来积极的连锁效应。

但我反复看到的一个模式是，超过某个临界点后，这些项目往往会在某种无形的重压下自行崩溃。提示会话开始耗时更长、成本更高。添加一个新功能会破坏两个其他不相关的功能。这种“无形的重压”当然就是技术债务。它的效果是给整个努力泼了一盆冷水，因为到那时非程序员还有什么办法呢？等待更强的模型出现？

更新、更强大的模型可能会把这个崩溃点推后，但可能永远无法推到无穷远。

垃圾的谱系

我认为同样的事情正在专业软件工程中上演，只是时间线更长、更缓慢。LLM的使用存在一个谱系：肯定有一些保守的角落要么完全不用，要么只用AI做小的、范围明确的修改^[2]，其余则走“正常”的软件开发生命周期（包括“正常”的人工代码审查）。而在另一端，有些组织中几乎100%的代码是AI编写且AI审查的，可能没有人看过大部分代码。

我认为这个谱系或多或少给了我们对照组，以及接受不同剂量待研究药物的队列。实验成功看起来没什么特别令人兴奋的：业务照常运转，很可能软件开发周期大大加快。

实验失败则要难定义得多，因为它可能呈现多种不同形态：

开发速度变慢
token成本飙升
生产环境频繁宕机
安全漏洞增加

它很可能看起来不像是突然的、不可恢复的灾难性故障，而更像是千刀万剐式的慢性死亡^[3]。

LLM的问题（当你不阅读代码时）

TL;DR——你需要阅读代码，才能判断你是否给了LLM足够的信息来正确实现你真正想要的东西。

你只需随便哪天打开 Hacker News 的首页，就能感觉到程序员们过得并不好。其中许多帖子都讲述了那些享受专业软件开发中编码环节的开发者所经历的倦怠。^[4] 我打算完全忽略这个角度，因为企业从来就不是为了写代码而雇佣软件工程师的，他们雇佣工程师是为了解决问题并提供商业价值，无论那意味着什么。代码充其量始终只是附带产物，而平均而言则是一种负担。

我想讨论的问题是使用 LLM 时遇到的实际问题，即便是无限智能的 LLM 也不例外。这些问题困扰着我那些非技术背景、使用 LLM 的朋友们，而且我预计在足够长的时间跨度内，它们也会困扰软件工程师。

问题一：字面意义上的字面

我觉得最容易的描述方式是，这些模型经过了“指令微调”，这往往使它们在解读用户提示时非常字面化。默认情况下，如果你让它们做 <X>，它们就会去做 <X>，无论上刀山下火海。它们不会说“嗯，当前的抽象并不真正支持 <X>，如果我们把数据模型重构为 […] 怎么样。”它们会找到一个大致合理的地方把 <X> 塞进代码库，然后就这么做了。

这并不是说我们不能换一种方式使用 LLM。我相信即使在今天，它们也完全有能力认识到什么时候重构更有利于整体的长期可维护性和可扩展性，但这需要改变我们的提示、我们的工具、我们的态度，以及我们对速度的期望。

而且更深层地说，这要求我们对代码的结构有一个可运作的心智模型，而当我们不亲自编写代码、也几乎不（甚至完全不）审查代码时，这正是我们首先失去的东西。再说一遍，即使拥有一个完美的 LLM，你仍然需要判断重构是否合理，因为 LLM 并不知道你期望代码库如何随时间演进。

……这恰好把我们引向了问题二。

问题二：缺乏上下文

不是指“上下文窗口”意义上的上下文，而是指一项变更所处的背景环境。

除非你明确告诉 LLM 关于你项目和情况的具体信息，否则它并不知道。它不知道一项任务有多紧急，也不知道这个代码库是不是一个用完即弃的原型，或者你打算下个月从 MySQL 切换到 Postgres，又或者别处的另一个服务依赖于你以某种非常特定的方式发出这个事件。

有时候，极端的权宜之计是最合理的做法。另一些时候，它们会让你多花 1000 万美元的 AWS 费用，或者因为额外的认知负担而降低开发速度。^[5] 除非你告诉 LLM，否则它无法评估这些权衡。

但很多时候，这些权衡已经被我们内化到甚至没有意识到它们是权衡的程度。要发现我们做出了这些权衡，唯一的办法就是——你猜对了——阅读 LLM 的输出，以此作为它是否理解了你意图的合理性检查。

综合起来看

导致长期不稳定的主要原因不仅仅是这些问题的存在，而是它们会随着时间推移不断累积（呈指数级？）。如果不阅读代码，你就不知道 LLM 是如何解读你的请求的。它可能做出了一些完全合理、但根本不适用于你情况的假设。而未来的会话会看到那段代码，同样缺乏你的上下文，然后在此基础上继续构建，如此循环。最初的小错误会像滚雪球一样，最终演变成更大的错误。

我在这里纠结的是，这到底在多大程度上算是个真正的问题。大型代码库一直都是洛夫克拉夫特式的^[6]恐怖存在，而大多数时候，它实际上并不会对在生产环境中运行它的组织构成生存威胁。他们可能不得不宣布进入“红色警戒”，或者推出某个路线图，或者为某些违规行为支付罚款，或者献祭解雇一些象征性的员工，但通常不会就此完蛋。

那为什么这次会有所不同呢？在我看来，区别在于它发生的规模，以及纠正这些错误所需的机构知识的丧失。

针和针风扇

我自己经历中的一个近期（小）例子：我一直在做一个个人硬件项目，^[7]并且用 LLM 来设计控制板的硬件。^[8]我告诉它我打算使用一款特定的 3 针 Noctua 风扇来散热。它尽职尽责地设计了一个可变电压功率级，将微控制器的 PWM 输出转换为风扇的供电电压。这需要一大堆乱七八糟的元件，^[9]大概是我实际所需的两到三倍。

下一次会话开始时我说：

在 fw/design.md 中，我们为灯的固件和硬件控制板制定了设计方案。我意识到 4 针风扇（即内置 PWM 控制）和 3 针风扇价格相同。如果我们使用 4 针风扇，能否简化电路？

4 针风扇的数据手册可在 […] 获取

果然，它移除了所有那些额外元件，并对固件做了几处小调整，为我节省了大量（电路板制造方面的）复杂性、（额外元件方面的）金钱和（我非常不擅长焊接的）时间。

如果我完全没有阅读 LLM 的输出，我就不会意识到自己的错误——主要是我没有让它知道我可以在风扇元件的选择上灵活变通，以及 4 针风扇和 3 针风扇价格相同。它会继续在无效假设的基础上构建，最终损害最终结果。

竞赛开始了

对我来说，整件事感觉就像一场竞赛：一边是一个团队能以多快的速度把代码库糊弄出来，另一边是模型以及（也许更重要的是）围绕它们的工具能以多快的速度改进。

试图用 GPT-3.5（2022 年）完成 100% 的软件开发，很可能会是一场短暂的灾难。而在 2026 年用前沿^[10]模型完成所有开发，也许就完全没问题？

现在，我们都还在摸索如何使用这些工具，^[11]而工具本身又在不断变化和改进，这让事情变得更加复杂。我认为，要等到我们能有把握地称之为“最佳实践”的东西，还需要相当长一段时间（如果真有那么一天的话），但这正是这个实验如此值得关注的部分原因。

或者愿意掏钱雇佣程序员的人 ↩
例如编辑器自动补全、从非 IDE 聊天会话中复制粘贴 LLM 代码输出 ↩
说的就是你，GitHub ↩
如果这能安慰那些受此困扰的人，世界上大多数工人都不喜欢自己的工作，所以你并不孤单。当然，如果这能带来快乐，我们仍然可以在空闲时间徒手写代码。 ↩
即使由 LLM 来编程，认知负担仍然很重要。更多附带复杂性会让事情更慢、更昂贵、更容易出错。 ↩
或者说是卡夫卡式的，随你选 ↩
这是一盏非常亮的灯，像 Brighter 或 Rhythm。但不是那种几千美元的。 ↩
如果用 LLM 来设计电力电子听起来是个糟糕的主意……那它很可能就是。但我的背景理论上是电气工程，所以这应该不会是一场彻底的、毫无缓解的灾难。只是部分的、有缓解的灾难。 ↩
放大器、分压器、平滑滤波器、几个额外的晶体管等等 ↩
或者见鬼，甚至比前沿低一档也行，因为 Opus 5.5/GPT-6.1 Sol 是极其强大的工具 ↩
任何声称已经搞明白的人，很可能是在试图向你推销什么。 ↩