【深度分析】我们该怎么办？LLM带来了 “编程末日”？计算机专业教授：别做梦了！

当硅谷预言家们高呼“编程已死”时，真正的程序员正在用LLM铸造新的巴别塔——这场技术革命，暴露的恰恰是人类对代码最深的误解。

表面看，LLM生成代码的速度足以让初级工程师恐慌，但翻开计算机科学的底层逻辑，你会发现一个残酷真相：Copilot越智能，越证明人类编程能力的不可替代。哥本哈根大学教授Hans Hüttel用λ演算的PSPACE完备性定理刺破了泡沫——当自然语言描述遭遇希尔伯特第十问题时，LLM不过是穿着神经网络外衣的“高级查错工具”。

那些认为LLM将终结编程的人，或许从未理解过软件工程的本质。医疗系统的复杂合规性、金融交易毫秒级的一致性、航天器代码的零容错率...这些不是概率模型能解决的战场，而是人类工程师与混沌现实搏斗的修罗场。更讽刺的是，LLM生成代码的正确性验证成本，可能比传统编程更高——当一行AI代码导致银行系统崩溃时，法庭该审判提示词工程师，还是训练数据的标注员？

但真正的危机藏在技术平权的背面：当大学生用ChatGPT三天完成毕业设计，当外包公司用LLM批量生产漏洞代码，当“伪开发者”涌入市场稀释行业价值...我们是否正在制造一场全球性的技术通货膨胀？当LLM让代码民主化的同时，也摧毁了编程作为精密思维训练的价值根基。

更深层的冲突在于认知维度：LLM将需求分析推向了前所未有的高度，却暴露了人类最致命的弱点——90%的软件失败源于模糊需求，而自然语言与机器指令的鸿沟比想象中更深。试问哪个产品经理能用中文精准描述分布式系统的CAP定理实现？当程序员从代码劳工进阶为“需求炼金术师”，这场变革淘汰的从来不是编码能力，而是思维惰性。

在这场人机共谋的革命中，最吊诡的悖论浮现了：越是依赖LLM，越需要顶尖工程师把控核心逻辑；越是代码自动化，越需要人类突破图灵完备性的边界。当LLM把编程从重复劳动中解放，我们终于直面计算机科学最本质的命题——不是“如何让机器理解人类”，而是“如何让人类理解自己”。

此刻，每个开发者都站在历史的十字路口：你会沦为LLM提示词的傀儡，还是成为驾驭算法的新一代数字造物主？

LLM带来了 “编程末日”？计算机专业教授：别做梦了！

LLM对编程的影响

大型语言模型（LLM）对编程有着多方面的深刻影响：

编程效率方面
- LLM能极大提高编程效率。例如在代码生成上，许多LLM都可以依据少量代码或者仅仅根据要求就编写函数、完成程序的编写 [1]。像GitHub的Copilot就是专门用于编码协助的典型例子，它能够在编程过程中给予代码提示，自动补全一些常规的代码片段，这就节省了程序员逐行编写代码的时间。尤其是在处理一些较为常见和模板化的编程任务时，如简单的数据库查询语句（SQL），LLM可以快速地生成结构良好的代码段，减少人工编写的工作量，从而将更多精力投入到逻辑构建和业务需求的实现上 [2]。
- 在代码评审与重构上，LLM也能够提供智能辅助。通过分析代码的语义和结构，它可以为开发者指出潜在问题，比如代码是否符合最佳实践、是否存在性能瓶颈或者安全风险等，有助于开发者对代码进行优化和重构。在大型项目中，代码的规模和复杂度往往很高，人工进行全面审查十分耗时耗力，LLM可以作为一个初步的检查工具，快速定位可疑区域，辅助人工审查更快地发现问题并解决 [2]。
- 单元测试和接口测试代码也能够由LLM自动生成。这样做的好处是可以确保测试覆盖到代码的各种可能情况，提高代码的可靠性。LLM能够根据被测试代码的结构、输入输出等信息，生成相应的测试代码，甚至可以基于一些测试框架的规范，生成格式正确且有效的测试用例，帮助开发者更快地构建测试体系，从而提高整体的开发效率。
编程门槛方面
- 编程知识获取途径得到拓宽。过去，人们通常需要通过系统的学习，如阅读专业书籍、参加课程学习编程语言、数据结构和算法等基础知识，而现在LLM可以作为一个随时可用的知识库。如果开发者在编程过程中遇到概念不理解、某种函数或算法的用法疑问等问题，可随时向LLM提问并得到较为详细的解答，这有助于初学者快速入门和成长，也为有经验的开发者解决疑难问题提供了新的途径。
- LLM带来了基础编码能力的知识平权。以前工程师个体学习掌握一门计算机语言以及相应的数据结构和算法，需要较长的学习周期，很多经验和模式还需要个体在大量实践中总结。现在LLM让未接受过系统培训的个体也能拥有相关能力，个体之间在基础编码能力上的差异被缩小了。例如，那些想要自学编程但缺乏专业指导的人，可以借助LLM来理解难懂的编程概念、语法等知识，使得编程学习变得更加容易入手，进而吸引更多人参与到编程工作中来，降低了软件开发的门槛 [2]。

计算机专业教授对LLM和编程关系的看法

计算机专业教授对LLM和编程关系有着不同的看法。以哥本哈根大学的计算机教授HansHüttel为例，他通过分析计算理论中的定理所施加的基本限制，得出了距离编程的终结还远得很的结论 [7]。

对一些极端观点的驳斥
- 在计算社区中存在如MattWelsh这样认为“编程将成为过去”的观点。Welsh提出在非专业应用程序方面，除了非常专业的应用程序之外，大多数软件将被经过训练的AI系统所取代，手动编码不再必要。而HansHüttel认为这种观点过于绝对。例如当前的操作系统、游戏引擎和SaaS平台等系统软件算是否是所谓“简单软件”，能否被AI取代还仍然存疑。Welsh这种笼统的主张意味着如果不需要编程，连研究编程或程序的属性都不需要，这几乎是宣告计算机科学走向尽头的论断太过激 [7]。
程序合成的复杂性论证
- 从规范生成正确的程序代码，这在计算机科学中是一个核心的程序综合问题。目前很多的研究表明这个过程十分困难。例如在1979年，RichardStatman证明了，在简单类型的λ演算中是否存在具有给定类型τ项的问题是PSPACE完备（PSPACE - complete）的。而普遍的共识是，PSPACE完备问题的决策算法在运行时间上将随输入大小呈指数级增长。这意味着即使是简单的程序，从自然语言等规范去生成正确的程序代码都会面临资源占用巨大、耗时极长等问题。LLM虽然可能促进解决这一问题的讨论，但目前来看要真正取代编程根本难以实现，因为编程过程中有很多这样深层次的理论难题等待解决 [7] [15]。
软件开发仍面临诸多固有挑战
- 软件开发自身具有的复杂度不会因LLM而消失。软件的本质复杂度、问题域复杂度等依旧存在。就好比开发一个医疗管理系统，它涉及到复杂的医患数据管理、诊疗流程以及医疗制度的合规性等，LLM并不能改变这些客观存在的复杂度。另外一致性需求在软件研发中很重要，因为软件研发通常是大量开发者协作的过程，需要用相似的方式去完成相似的工作，LLM本身概率性的特性反而可能造成生成的代码存在不一致性问题。还有软件的可变性是软件开发过程中的永恒挑战，由于需求在不断演进和变化，架构设计和模块抽象总是存在局限性，在敏捷开发模式下这一问题更为凸显，LLM也无法改变这种状况。同时软件还具有不可见性，它不像实体物质可以直观地看到存在形式，不同的关注点会产生不同视图，难以可视化并且强行可视化反而会带来复杂不良的效果，限制交流沟通，LLM对这些软件工程中根本性的内在挑战几乎无能为力 [8]。

LLM会导致编程末日吗

答案是否定的，LLM不会导致编程末日。

LLM的自身局限性
- 自然语言交互的天然缺陷：虽然LLM可以实现自然语言交互，但人类口语不够简洁清晰且容易产生误解。以GPT - 3为例，人们使用时需要准确使用名词、形容词、动词等，才能获得想要的结果。在将自然语言转化为精确的程序代码时很容易出现偏差，尤其是对于较为复杂的逻辑需求。例如在实现一个企业级财务管理系统的需求时，如果用自然语言描述可能会存在多种理解方式，而编程则需要非常精确的逻辑定义，这就是LLM难以完全桥接的差距 [7] [15]。
- 代码生成的正确性挑战：从程序合成角度来看，生成正确的代码是一个计算复杂性理论上的难题。即使是所谓“简单”的程序在生成代码时面临着诸如资源占用巨大、耗时极长等问题。从约束条件（如输入输出示例、自然语言、部分程序和断言等）下生成满足需求的程序并非易事，这意味着在很多情况下LLM生成的代码目前并不能直接达到工程适用的正确性要求，还需要大量的人工校验和修正，这说明LLM远远没有达到让编程职业无用的地步 [15]。
软件工程层面的本质未变
- 需求分析的重要性与复杂性：在LLM时代需求的重要性反而被放大了。不管代码生成的方式如何改变，如果需求没有准确全面的描述，那么生成的代码也不会正确。但事实上将需求完整清晰地描述出来本身就是一门复杂的艺术和功底。因为大多数代码实现是指令性（imperative）的，而需求描述更多是声明性（declarative）的，这对人的要求截然不同。并且当前开发模式下多数是程序员默认替需求方做了很多的代偿工作去书写代码，现在要先清楚地描述需求并非易事，例如开发一个带有在线交流、文件共享和项目管理功能界面的协同办公软件，要全面描述这些功能需求达到能自动代码生成的程度非常困难。同时，LLM并不能处理软件复杂性的根源如软件工程的四大内在特性（复杂度、不一致性、可变性、不可见性），在需求不断演进、软件架构面临局限性以及软件难以有效可视化沟通时LLM无法从根本上解决这些软件工程的基本矛盾，所以编程依然是一个十分重要的环节 [2] [8]。

关于LLM与编程未来的讨论

技术融合的未来趋势畅想
- 未来LLM和编程可能会走向深度融合。一方面，LLM将继续在编程过程中扮演代码助手的角色。它不仅能够生成基础代码，可能还会更加智能地理解复杂的业务逻辑和特定的算法需求，进而生成更加符合项目需求、可靠性更高的代码片段。例如在开发人工智能视觉识别算法的软件项目中，LLM可以为项目生成一些对于图像数据处理、卷积神经网络相关功能操作的基础代码架构，并且依据项目的特殊需求，如对于特定类别的精准识别要求等，调整代码插入一些特定参数的设置。另一方面编程工具和语言也会反过来对LLM进行优化。例如可以开发出针对LLM在编程任务中的特定插件或者语法格式，使得在向LLM输入编程需求时能够更加精准地获取想要的代码结果。像是Python语言社区可能会针对LLM开发一些专属的库或者方法调用格式，让程序员可以在Python编程过程中更好地与LLM协同工作。
- 在软件工程的教育和培训方面，LLM或许会改变编程教育的模式。目前编程的教学侧重于基础的语法、算法和逻辑的系统性学习然后通过示例和项目实践巩固。随着LLM的发展，编程教育可能会更加强调如何有效地向LLM提出问题、如何准确阐述需求以及如何对LLM生成的代码结果进行评估和优化。工程实践类的课程教材可能会增加更多关于如何与LLM进行交互以完成软件项目开发的内容案例，培养新一代软件开发人才具备与LLM协同工作的能力。
面临的持续挑战展望
- 伦理道德和社会影响：LLM在编程领域的普及可能带来伦理道德方面的挑战。一个是代码的知识产权归属问题。当LLM生成代码时，这个代码的创造者是提示代码需求的人、是LLM的开发者还是别的情况难以明确界定。例如一个初创科技公司如果使用LLM生成代码构建了一个产品，但遇到其他公司侵权时，很难拿出有力说明代码属于自己公司的原创内容。另一个是算法决策背后的公平性和透明性问题。LLM很多时候是基于复杂的深度学习机制，可能会在代码生成、功能实现上产生一些歧视性或不公平的内容。像如果使用LLM开发一个招聘软件，可能会因为LLM潜在算法偏见对特定性别或种族的求职者在简历筛选功能代码生成时产生不公平对待，而这种情况很难被察觉和纠正。
- 安全性问题：由于LLM是基于大量的数据进行训练的，这就可能存在数据泄露的风险。例如如果外部恶意攻击者破解了LLM系统，获取到训练数据中的代码库或者企业私密业务逻辑代码样本等，这对于使用LLM辅助编程的企业来说是巨大的数据安全和商业机密的威胁。并且LLM可能会生成带有安全漏洞的代码，如果直接使用这些代码整合到软件项目中，例如在开发银行金融交易系统时，可能会导致恶意用户利用代码漏洞进行非法转账或者数据窃取等危害金融安全的行为。

LLM时代编程行业的发展趋势

工具和技术的演进
- 开发环境的融合：随着LLM在编程中的应用深入，开发环境将可能出现融合趋势。传统的集成开发环境（IDE）会集成LLM相关的功能，例如在IDE中直接调用LLM进行代码提示、代码生成、代码审查等操作。这样程序员无需在不同工具和界面之间切换，就能在熟悉的开发环境中享受LLM提供的便利。例如，Eclipse或IntelliJ等流行的IDE，可能会内置LLM服务，当程序员输入代码时会自动根据代码上下文提供改进建议或者代码片段补全。
- 自动编程能力的提升：LLM朝着提高自动编程能力方向发展。通过持续的预训练和模型优化，能够理解更多的领域特定知识和需求。例如在金融科技领域，能够理解金融相关的逻辑（如精确的利率计算、风险评估模型等）并生成与之相关的精准代码。同时，在代码准确性上不断提升，减少生成的代码中存在的错误和不规范之处，通过更为先进的算法和训练机制减少目前自然语言处理和代码转换中容易出现的偏差。
人才需求的转变
- 对程序员技能要求的新变化：对程序员而言，除了具备传统的编程知识（如编程语言、数据结构、算法）外，与LLM交互的能力变得更加重要。这包括如何准确地用自然语言表述编程需求以得到期望的代码结果，以及如何对LLM生成的代码进行评估和优化。例如，要开发一个具有复杂交互界面的电商网站，程序员不但要清楚网站的功能逻辑，还要能把这些逻辑通过LLM能理解的方式表述给它，并且对LLM给出的构建购物车、用户登录、商品展示等功能模块等代码有评估能力。
- 新职业角色的出现与旧角色的转型：随着LLM与编程的结合深入，会产生新的职业角色。像LLM训练专员，专门负责对LLM进行特定领域数据的预训练，使得LLM在该领域能够生成更符合需求的代码。同时，传统的编程角色如代码编写员等可能需要转型为代码架构师，不仅仅关注代码的实现细节，更多地负责整体软件架构的规划、模块划分等高层次设计工作，确保整体软件系统在基于LLM辅助代码生成的情况下保持高效、稳定、可维护。