大型工程里 AI 编码困境重重，未来如何破局？

“未来不是一个我们要去的地方，而是一个我们要创造的地方。通向它的道路不是人找到的，而是人走出来的。走出这条道路的过程既改变着走出道路的人，又改变着目的地本身。”——约翰·舒尔茨

在今日的早会上，一位同事分享了一个运用 AI 进行编码的实际案例。当时，他面临一项艰巨任务：对数千行的 Java 代码进行修改，以实现特定功能。他满怀期待地向 AI 输入提示词，清晰明确地提出修改需求。然而，代码运行仅仅几分钟后就戛然而止。经过一番分析，我们推测这可能是由于文件过大，超出了 AI 当时的处理能力。

于是，他决定换一种策略，让 AI 在新文件中实现该逻辑。这一次，AI 看似完成了任务。但当同事打开新文件查看时，却发现代码质量良莠不齐。部分代码编写得中规中矩，可圈可点；然而，部分代码却出现了 AI 的“幻觉”现象——无端添加了一些与需求无关的代码。权衡之下，他最终认为手动修改更为高效，无奈之下放弃了 AI 辅助编码，选择亲力亲为完成任务。

总结这次经历，他认为当前 AI 编码仅适用于小型代码片段。一旦涉及大型工程和复杂任务，AI 的表现便差强人意。这不禁引发了我的深入思考：为何大型工程复杂度提升后，AI 就难以胜任了呢？究竟什么才是真正的“复杂”？如果单纯认为代码数量多就等同于复杂，那么或许是大模型在处理长上下文时存储能力有限，导致任务无法顺利完成。不过，我坚信随着大模型对长上下文处理能力的不断增强以及算力的持续提升，这一问题在未来有望得到妥善解决。

实际上，复杂并不简单等同于规模庞大。一个系统即便整体规模较大，但如果各个组成部分都相对简单，其复杂度也不会显著提高。因此，我们有必要将规模和复杂度区分开来。倘若只是代码规模大的问题，我相信随着 AI 技术的不断发展，一定能够得到有效解决。

那么，真正的复杂度究竟体现在哪里呢？为何现有的代码工程如此复杂？我认为其中一个重要原因在于现有代码库的可读性普遍较低。目前，大多数企业的代码由人工编写，而要编写出易于理解、结构清晰的代码，对开发者的要求极高。当下的软件工程师往往更侧重于代码的可运行性，而忽视了代码的可维护性和可读性。有时候，即便经验丰富的开发者面对某些代码库，也可能需要花费大量时间才能理解其逻辑，更不用说 AI 了。

AI 是基于语义来理解代码的，如果代码本身晦涩难懂，AI 自然难以理解其含义。当 AI 无法理解代码时，就很难有效地辅助编码工作。尤其是在嵌入现有复杂代码工程时，稍微有难度的任务就会让 AI 束手无策，根本原因就在于它无法读懂这些代码。这些代码中常常包含大量的私有领域知识，也就是所谓的“黑话”，就如同互联网大厂内部使用的特定术语，只有身处特定语境的人才能理解其确切含义。

在我们的代码库中，变量命名、方法命名、函数构造及调用关系等方面，都充斥着类似互联网大厂内部术语的“黑话”。这些内容缺乏统一标准，AI 模型自然难以解读。因此，代码的复杂性在很大程度上源于其中包含的大量 AI 无法理解的“黑话”，而事实上，这些“黑话”有时连人类程序员都难以捉摸。

在这种情况下，人类程序员通常需要通过逐步调试、反复摸索，历经诸多波折后，才能洞悉代码的实际功能。这正是 AI 在辅助大型工程代码时面临的主要难题。

那么，这一难题能否攻克呢？我认为关键在于变革整个软件开发的模式。未来，程序员或许无需亲自编写代码，而是将编码任务交由 AI 完成。程序员的核心职责将转变为精准提出需求、清晰描述问题，由 AI 负责具体的实现工作。这种开发模式的转变将带来颠覆性的改变。

我们不妨大胆设想一下，若一款软件从最初的构思到最终的成型完全由 AI 进行编码，人类仅需提出需求，那么 AI 在进行任何调整时都不会遭遇现有的这些阻碍。我们应该坚信，AI 的编码能力远超人类。毕竟，现实中的程序员水平参差不齐，而 AI 却能始终保持稳定且高效的编码质量。

实际上，具备顶级程序员编码素养的人少之又少，这也导致代码质量参差不齐。编码本身就是一项极具挑战的工作，要严格遵循可读性和可维护性的标准进行编码，往往需要投入大量的时间和精力，从时间成本的角度来看并不经济。

倘若让 AI 承担编码工作，它必定会表现得更为出色。AI 擅长合理添加变量、规范命名以及详细注释，一切都能处理得井井有条。因此，AI 未来的使命便是为程序员减负，使他们能够将精力集中于问题的本质，而非陷入繁琐、重复的编码工作中。这或许就是 AI 编码的未来发展方向，它将引领软件开发行业迈向一个全新的时代