在软件工程中，对大语言模型（LLM）的过度依赖，会加速工程师的无能。大语言模型无法取代人类的批判性思维。
本文内容未使用任何AI生成。
2022年底以来，AI和大语言模型（LLM）的浪潮席卷全球。作为一名资深的软件工程师，我想谈谈我观察到的两个令人担忧的观点。
“LLM是我的朋友”
当然，没有人真的会把一个程序当作朋友，但这句话的潜台词是：大语言模型对使用者有巨大帮助。
那些将LLM视为盟友的工程师往往会特别强调速度，或者因为环境压力而被迫追求快速交付。对他们来说，生产速度比深度思考更加重要。的确，LLM能够快速生成大量代码，但同时也带来了巨大的风险。
使用LLM的风险
输出风险。LLM可能给出明显错误的代码，比如无法编译；更严重的风险是，它们可能生成看似正确但实际存在逻辑错误的代码，且难以发现。如果使用者没有足够能力评估输出（例如让项目经理来请求代码），风险会进一步加剧。
输入风险。LLM不会质疑带有误导性或假设有误的提问。例如，一个工程师问：“请给我提供一个线程安全的C#列表实现”，LLM可能会返回200行完美的代码，但其实正确的问题应该是：“如何让现有的代码线程安全？”，正确的答案只需一行代码（System.Collections.Concurrent）。LLM无法识别这种经典的XY问题。
未来开发速度。这就是典型的“技术债务”问题，但更加紧迫。AI可能迅速降低代码质量。想象一下一个囤积狂的家，外表可能看起来正常，但内部肮脏凌乱、功能瘫痪。如果没有有效的管理，由LLM生成的代码库就像这样，表面正常而内部混乱。
用户的技能退化。当个人和组织把思考和问题解决完全外包给LLM时，人才的灭绝就会发生：
失去创造的乐趣。很多开发者发现，使用AI之后，失去了进入“心流”状态和创造的快乐。AI生成的代码通常难以阅读和维护，令人感到沮丧。
“我会变得多余吗？”
不，你不会。但你确实需要一些方法，让自己更好地与LLM区别开来。具体的方法，我会在后续文章再做介绍。
有两个编程的核心能力，是LLM无法提供的：程序理论（Program Theory） 和 程序熵（Program Entropy）。
程序理论（Program Theory）
……程序设计本质上是一种建立或达成特定理解（理论）的活动。
—— Peter Naur，《程序设计即理论构建》（1985）
Naur是计算机历史上的重要人物，他提出，一个程序并不是代码本身，而是人类头脑中共同构建的一种理论或设计。这种理论远比代码本身更有价值。
我们来进行一个思维实验，说明程序理论与代码文本之间的区别：
假设有两个实力相当的开发团队A和B，被隔离在不同房间。团队A负责从零开发一个简单的终端棋类游戏，团队B则等待或玩真实的棋类游戏。等A团队开发完毕后，把代码交给B团队，并同时要求两个团队给游戏增加一个新功能，比如电脑自动对弈功能。
问题：哪个团队的表现更好？
答案：团队A更好，因为他们刚刚构建了对程序的清晰理解，而团队B并没有。
Naur强调，这种理论至关重要，因为程序最终总需要被维护。如果你只有代码，而缺乏对设计的理解，维护成本就会极高。 相信每个程序员都有过类似经历：第一次接触一个庞大的代码库时，生产力几乎为零，直到逐渐构建出对程序的内部理解。
LLM与程序理论
当前的LLM无法掌握理论或设计，因为它们缺乏长期记忆。只有人类才能获得并保留程序理论。
程序熵（Program Entropy）
复杂性是程序设计中最根本的阻力，它与熵相关。
程序构建是一个降低熵的过程，而程序维护则是熵增的过程。 即便是最高效的维护，也只能延缓系统滑向无法修复的过时状态。
—— Fred Brooks，《人月神话》（1975）
Brooks也是计算机领域的传奇人物，他指出程序在初次开发后，每次修改只会让代码变得更复杂。如果修改符合原始设计，则复杂性的增加速度会稍慢。
LLM与程序熵
LLM本质是一个文本预测器，仅仅在文本层面工作，不具备概念层面的推理能力。它无法理解想法、图示或需求规范。当你用大段代码提示LLM时，它往往会生成一些莫名其妙的变化，随着对话持续，代码越来越偏离初始意图。
你几乎不可能见到LLM降低代码复杂性。只有人类才能主动降低或抵抗复杂性。
结语
我们通过回顾两位软件工程先驱的智慧，获得了适用于LLM时代的洞见：
AI带来的商业吸引力是降低成本，但就像外包工程师一样，AI的应用也存在巨大风险。AI的热潮终将降温，滥用AI的公司将面临长期成本，不是转型就是消失。人类工程技能的长期价值始终如一，世界依旧需要深厚的技术能力和深入的思考。
AI不会消失，但请把它当成工具，而不是拐杖。持续投资于真正有价值的工程技能。
