整理完这些观点并发布到网上后，Hacker News 上迅速涌现出激烈的讨论。其中，有几条评论获得了众多点赞，我认为它们都值得一读。

文章的起始点实际上可以回溯至1985年Peter Naur所发表的具有里程碑意义的论文《作为理论构建的编程》。值得一提的是，Naur是ALGOL语言及BNF语法的关键人物之一。

Naur认为，那些结构复杂的软件系统，其本质是由开发者群体共同心智所构建的“理论”。而源代码与文档，不过是这种理论的低保真呈现——因为单靠代码与注释，我们无法完全恢复出构建该系统时所蕴含的全部思维过程。

在这种语境中，所谓的遗留代码是指：尽管你依然保存着那些代码和文档等“历史遗物”，然而支撑这些内容的“理论基础”却随着原作者的离去而逐渐消失。因此，你将无法对系统进行“根本性”的改进，而只能进行一些修复和日常维护工作。

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

从Naur的视角出发，LLM是否必定缺少“程序运作原理”这一要素？这并非一个确凿无疑的结论，或许存在以下几种不同的情形：

在生成代码的过程中，LLM 实际上已经融入了一种“理论”，然而我们尚未完全理解其内涵。

或许 LLM 能够逐步在现有代码的基础上形成此类理论，抑或将来能够实现这一目标。

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

若代码系人工智能所创造，那么或许唯有AI真正精通了相关理论，而非人类。

或许，这一理论体系实际上是由负责撰写提示信息的人所掌控，而非编写代码的程序员。

我和上司经常向新入职的年轻员工解释道：“我们以前就是这样编写的”——这种说法通常是为了掩盖那些编写得不够出色的代码接口，而所谓的“以前”，实际上可能仅仅是指两周前的事情。

然而，我们确实有时并无过错。这其中的某些奇特表述，是为了适应那些极为罕见的边界情况，亦或是为了与那些陈旧的系统相兼容——这些系统本身便是那个时代的遗留。庆幸的是，我们身处团队之中，因此能够判定哪些代码可以被删除，或者至少尝试进行删除。

我坚信，若能实现LLM辅助编程对提示信息的记录，并将这些提示与生成的代码一同保存，那么它或许在处理技术债务方面，相较于人类，将展现出更出色的能力。以一个实例来说明：

若你知晓该段代码系依据“保障客户端在运行AIX 6操作系统时应对边界问题”的提示所生成，那么便能解答诸多疑问。纵然你尚不清楚是谁当初在采用AIX系统，但至少你能明确这段代码存在的缘由，并作出是否可以删除的判断。

@TZubiri：即便AI具备上下文视野，它仍属于“无状态”类型。这意味着AI能够推断出代码为何如此编写，但无法确切地明白作者在特定时刻的真实想法，更无法像人类维护者那样保留具体的时间记忆。

关于这句话，我想表达的是：运用思维链技术，我们能够有效解决这一问题。

即便是没有CoT功能的模型，它们也能通过“阅读”既有的代码来重新唤醒上下文信息。实际上，这一点与人类工程师颇为相似——我们并非总能回忆起所有代码的背景知识，但重新审视代码，往往便能唤起当时的情境。

从最初起，该代码便源自遗留代码。

本篇内容源自微信公众号“CSDN”，由郑丽媛进行翻译，现经36氪的授权予以公开发布。