“由 AI 生成的代码，从诞生那一刻起就是「遗留代码」！”

【编者按】如今生成式 AI 逐渐融入软件开发流程，越来越多 AI 生成的代码出现在实际工程中——但你有没有想过，这些由 AI 写出来的代码，从一开始就可能被视为“遗留代码”？本文作者从工程经验出发，结合 AI 的生成机制，提出一个颇具启发性的观点：AI 生成的代码缺乏上下文记忆和维护连续性，因此一诞生就处于“他人旧作”的状态。这不仅是对当前 AI 编码能力的冷静观察，也为我们理解未来软件开发形态提供了一种新视角。

原文链接：https://text-incubation.com/AI+code+is+legacy+code+from+day+one

翻译 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

在软件开发中，代码的“可改进性”往往取决于其所处的生命周期阶段。通常可以分为以下几类情况：

• 当某段代码是你自己刚写的：“哦，确实可以改成那种写法，应该不难。”

• 当某段代码是别人刚写的：“可能是出于最近的一些临时情况才这么写的吧。如果真有需要，我可以考虑调整一下。”

• 当某段代码是你以前写的：“嗯，其实当时应该那样写。如果有必要，等忙完手头工作了我再优先处理吧。”

• 当某段代码是别人以前写的：“他为什么要这么写呢？不过应该没必要动，等真的出问题再说。”

总的来看，代码的演进速度，通常取决于离它的编写时间有多近、维护者是不是原作者。

其实，这种状态是合理的：对于一个运行稳定、经过验证的软件系统而言，贸然进行“改进”往往带来额外风险，尤其是当你对系统的整体脉络不甚了解时，原作者通常才最清楚其潜在逻辑和开发背景。

AI 生成的代码，处在什么阶段？

那么换个角度看，AI 生成的代码具体处在什么阶段呢？在我看来，它有几个关键的特点：

（1）即使AI拥有上下文窗口，它也是“无状态”的（stateless）。也就是说，AI 可以推测一段代码为什么这样写，但它无法真正“知道”作者当时的具体意图，也无法像人类维护者那样拥有真实的时间点记忆。

（2）每一次 AI生成的代码，其实都是“由别人写的”。AI 就像一个第一次阅读你代码的新人，从零构建对上下文的理解，它不会真的“记得”当初的输入是如何经过某种“电路”转化为某个输出。

（3）AI 生成的代码，一出生就已经“变老”了。它跳过了“新代码”的阶段，直接进入了“别人写的旧代码”的模式——没有时间上的“新鲜感”，也没有原作者持续维护的加成。这种代码，从一开始就可以被视作“遗留代码（legacy code）”。

当然，也有熟练 AI 的开发者在尝试解决这个问题。比如通过精心构造的提示（prompts）、设计合理的上下文窗口、详细注释等手段，来弥补 AI 缺乏状态记忆的问题。但总体上，这些做法更像是顺应惯性、朝着某一个方向在缓慢优化。

不过我个人的猜测是——或许这根本不算大问题，因为代码本身就是一种“静态状态”。随着提示工程（prompting）和上下文窗口的能力增强，代码会被越来越多地“提示生成”，而非长期维护。未来“复杂软件”的代码量可能会更少，更多的逻辑会依赖于模型推理、提示而非静态结构。

在此背景下，AI 提示生成的代码，更像是一个短期/中期的“过渡桥梁”。

一些值得细品的高赞评论

我把以上的观点整理成稿并发布后，在Hacker News 上引发了热烈讨论。以下是几条高赞评论，我觉得都值得细品：

（1）@dang：文章的开头实际上可以追溯到 Peter Naur 在 1985 年发表的经典论文《Programming as Theory Building》。顺带补充一下，Naur 正是 ALGOL 语言和 BNF 语法的核心人物之一。

Naur 的观点是，复杂的软件系统，本质上是开发者集体心智中构建起来的“理论”。源码和文档只是这种理论的低保真表达（lossy representation）——因为你永远无法仅凭代码和注释，完整还原构建这个系统时的全部思维脉络。

在这种意义下，遗留代码（legacy code）指的是：虽然你还保留着代码和文档这些“文物”，但支撑它们的那套“理论”已经随着原作者的离开而失传了。这也就意味着，你不再有权限对系统进行“深层改进”，只能做些修补和维护。

那么，这种思想对于大语言模型（LLM）时代意味着什么呢？

从 Naur 的角度来看，LLM 是否也必然缺乏“程序背后的理论”？这并不是一个有定论的问题，可能存在以下几种可能性：

• LLM 在生成代码时，其实已经隐含某种“理论”，只是我们还没看懂；

• 也许 LLM 可以从已有代码中逐步构建这种理论，或者未来能做到；

• 或许 LLM 根本不需要人类工程团队那样的“理论”；

• 如果代码是由 AI 生成的，那么或许 AI 才是唯一掌握了理论的存在，而不再是人类；

• 又或者，这套“理论”其实是掌握在写 prompt 的人手中，而不是写代码的人手中。

（2）@mrweasel：我和老板总会对新来的年轻同事“辩解”说：“这就是我们那时的写法”——多数情况下，这只是用来掩饰一些写得不咋地的代码的接口，而“那时”可能也就是两周前。

不过有时候我们也确实没错。因为有些奇怪的写法，是为了适配一些极端边界场景，或者是为了集成一些老旧系统——它们本来就是那个时代的产物。所幸我们还在团队里，所以能判断哪些代码可以删、或者至少可以试着删。

我认为，如果 LLM 辅助编程可以记录下 Prompt，并与生成的代码一起保存，那它或许比人类更能管理技术债。举个例子：

如果你能知道某段代码是由这样一个 Prompt 生成的——“确保处理客户端运行 AIX 6 时的边界情况”，这就能回答很多问题。虽然你依然不知道当初是谁在用 AIX，但你至少知道为什么这段代码存在，也能判断是否还能删。

（3）@TZubiri：原文中提到，“即使 AI 拥有上下文窗口，它也是“无状态”的（stateless）。也就是说，AI 可以推测一段代码为什么这样写，但它无法真正“知道”作者当时的具体意图，也无法像人类维护者那样拥有真实的时间点记忆。”

对于这句话，我想说：Chain of Thought（思维链）技术能搞定这个问题。

甚至就算是没有 CoT 的模型，也能通过“阅读”原有代码重新激活上下文。其实这一点跟人类工程师很像——我们也不是永远都能记得所有的代码背景，但重新看一遍代码，通常就能想起当时的上下文。