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

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

代码的“可改进性”在软件开发中往往取决于其生命周期阶段。一般可分为以下几种情况：

• 你刚刚写了一段代码：哦，的确可以改成那种写法，应该不难。
• 别人刚刚写了一段代码：也许是因为最近的一些暂时的情况才写出来的。要是真的需要，我可以选择调整一下。
• 在你之前写的某一段代码："嗯，事实上，那时候应该这样写。如有必要，等忙完手头的工作，我再优先考虑。"
• 在某一段代码是别人之前写的："他为什么要这样写？但是应该没有必要动，等真的出了问题再说。"

总的来看，代码的演变速度，一般取决于它的编写时间有多近，维护者是否是原作者。

其实这种状态是合理的:对于一个性能稳定、经过验证的软件系统来说，贸然“改进”通常会带来额外的风险，尤其是当你对系统的整体脉络了解不多的时候，原作者一般最了解它的潜在逻辑和发展背景。

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 2008年发表的经典论文《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 模型也可以通过“阅读”原始代码重新激活前后文本。其实这和人类工程师很像——我们并不总是记住所有的代码背景，但是如果我们再看一遍代码，我们通常可以记住当时的前后文本。

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

本文来自微信微信官方账号“CSDN"，翻译：郑丽媛，36氪经授权发布。

本文仅代表作者观点，版权归原创者所有，如需转载请在文中注明来源及作者名字。

免责声明：本文系转载编辑文章，仅作分享之用。如分享内容、图片侵犯到您的版权或非授权发布，请及时与我们联系进行审核处理或删除，您可以发送材料至邮箱：service@tojoy.com