编者按：当业界沉迷于用AI提效的幻象，本文以程序理论与熵增原理揭穿残酷真相：过度依赖LLM正加速工程师批判性思维退化，而重塑技术敬畏已成生存必修课。文章来自编译。


越依赖LLM，智商越低

自2022年末AI浪潮席卷公众认知以来，相关讨论已汗牛充栋。作为从业二十年的软件工程师，我想谈谈观察到的两种危险认知。

“LLM是我的好搭档”
不会真的有人把程序当成自己的伙伴，这话的潜台词其实是：LLM能给用户带来巨大收益。

把LLM当盟友的工程师，往往被迫或主动追求速度至上——对他们而言，交付速度比思考深度更重要。虽然LLM确实能快速生成代码，但也会伴随着各种长尾风险：

使用LLM的风险
输出风险：LLM可能给出明显错误的代码（比如无法编译的），更危险的是生成看似正确实则暗藏逻辑漏洞的代码。如果使用者缺乏判断能力（比如让项目经理生成源代码），风险将陡增。

输入风险：LLM不会质疑存在诱导性、前提错误或语境缺失的指令。例如工程师要求“用C#实现线程安全的列表”，得到200行完美代码——但这仍是错误答案，正确问题应是“如何让这段代码线程安全”，正确答案只用加一行代码"System.Collections.Concurrent"。LLM无法识别这种XY问题，因为你没要求它这么做。

未来效率：这是升级版“技术债”问题。AI能以惊人速度摧毁代码质量。见过囤积癖患者的屋子吗？外表光鲜，内里却污秽不堪。开发者正发现：缺乏严格约束时，LLM生成的代码正是如此。

能力退化：当个人或组织将思考外包给LLM，人才将迎来灭绝：

资深工程师失去在攻坚中成长的机会，现有能力逐渐萎缩：

“微软研究发现：AI带来的自信常以牺牲批判性思维为代价”

“在这个推崇‘条件反射式AI使用’的世界，我主张保留编程的手艺本质”

 “LLM直接给我成品结论，却剥夺了思维成长的过程”

初级工程师永远无法建立核心能力，更遑论培养下一代。

创造剥夺：众多开发者反馈AI夺走了心流状态和创造乐趣。

“我会变成多余的吗”
答案是不会。当然，有些举措能让你在LLM时代更具不可替代性，这将另文探讨。

LLM永远无法具备两种编程核心能力：程序理论（program theory）与程序熵（program entropy）。

程序理论
......严格来说，编程应该看作是一种程序员对手头事务形成或达成某种洞察、理论的活动

——彼得·诺尔《编程即理论构建》(1985)

这位计算科学泰斗指出：程序不是源代码，而是大家分享的心智建构：一种理论或设计。工程师从中衍生出代码，但真正有价值的产物是设计而非代码。

理解程序理论与代码文本差异的实验：让水平相当的两组工程师隔离工作。A组开发终端象棋程序，B组等待。完成后将A组代码交给B组，要求两队同时添加人机对战功能。

问：哪队能交出更优方案？

答：A组。因为他们刚构建完程序心智模型，B组则从零开始。

诺尔认为，程序终需维护改造。如果只是掌握代码而无设计洞察，改造成本将倍增。回想我们初次接触大型代码库时，效率总是从零开始爬升——这正是心智模型加载的过程。

LLM与程序理论

现有LLM受限于上下文窗口，永远无法掌握程序理论。唯有人类能构建并保有这种心智模型。

程序熵
复杂性是编程一个基本的反作用力。

......程序开发是熵减过程... ...维护则是熵增过程，再精妙的维护也只能延缓系统沦为不可修复废品的进程

——弗雷德·布鲁克斯《人月神话》(1975)

这位计算机先驱断言：开始开发程序后，任何修改都必然增加复杂度。但符合设计理念的改动能延缓熵增。

LLM与程序熵

LLM本质是token预测器，仅工作在文本层面。它无法进行概念性思考——不会推理理念、图表或需求文档。所有用过LLM修改过大段代码的人都目睹过：它常进行诡异的多余改动，对话越久偏离越远。诸位见过几次LLM真正降低来代码复杂度的？

唯有人类能对抗熵增。

结语
两位先驱对软件设计与复杂性的洞见，恰是这个时代的解药。

若你期待AI助推职业生涯，警惕它可能适得其反——LLM正在加速能力退化。

若你已是资深工程师却担忧失业，请建立更辩证的认知：LLM永远无法取代人类工程智慧。

企业追逐AI旨在通过工程标准化降本，但正如离岸开发的经验所示，LLM不仅难达预期更衍生新风险。眼下滥用AI的企业必将承受长尾成本，要么转型要么消亡。人类工程师的长期价值从未改变——世界始终愿为技术实力与深度思考买单。

AI不会消失，但请把它当成工具，而不是拐杖。持续深耕2019年就被珍视的那些工程核心能力吧。

译者：boxi