#LLM 的局限

如果说 ChatGPT 实现了数字时代知识的平权，codex 类的代码语言大模型实现了基础编码能力的知识平权，进而带来软件研发的局部效率提升。可以说，LLM 降低了软件开发的门槛，可以让更多对软件开发感兴趣的人更加轻松地参与到软件开发工作中，同时，LLM 提高了编程的效率和质量，使我们可以在更短的时间内完成更多的工作，因而能留出更多的时间让我们思考。

我们面对的是软件工程的问题，编程不等于软件工程，编程只是软件工程的一部分。软件工程的四大内在特性（复杂度、不一致性、可变性、不可见性）并没有因为 LLM 的出现而发生本质上的变化，这才是软件工程面临的主要矛盾。这四点再叠加上大型软件的规模效应，其中包含软件系统本身的规模和软件研发团队的规模，问题就更严重了，即会显著提升软件研发过程中的沟通成本、决策成本、认知成本和试错成本，而这些才是软件工程问题的本质，这些本质问题自始至终都没有变过，LLM 对此也基本无能为力。

#复杂性

LLM 让局部编码变简单，或者说更高效了，但是需求分析和软件设计并没有因为 LLM 而变得简单。

只有我们的需求足够的清楚，那么生成的代码才会准确。如何准确全面描述需求成为了关键。面向自然语言编程，首先你要有能力把话讲清楚。但是问题是：你能讲清楚吗？我们通过一些实践发现，要把需求描述到让它能正确写出来代码，需要的工作量似乎已经接近甚至超过编码了。为什么会这样，有两个方面的原因：

因为大多数的代码实现是 imperative 的，而需求描述是 declarative 的，这两者对人的要求完全不一样。我们程序员群体接受的教育是编程，而不是需求描述，也就是说程序员本来更擅长写代码，而不是描述需求。
在当前的开发模式下，程序员直接用代码默认帮需求（产品经理）做了很多代偿。很多在需求中没有明确提及的内容被程序员用代码直接实现了（代偿）。而现在要倒过来先把需求的细节完全理清楚这个可能不是程序员当前的工作习惯。而且代码的信息熵其实要大于自然语言，程序员更善于用代码而非自然语言来描述事务。
- 在当前的开发模式下，程序员直接用代码默认帮需求（产品经理）做了很多代偿。很多在需求中没有明确提及的内容被程序员用代码直接实现了（代偿）。而现在要倒过来先把需求的细节完全理清楚这个可能不是程序员当前的工作习惯。而且代码的信息熵其实要大于自然语言，程序员更善于用代码而非自然语言来描述事务。
- 一个软件的需求，不仅仅是功能性的，还有很多非功能的需求，这些都是需要描述清楚的。另外代码实现的时候，还要考虑为可测试而设计，为可扩展而设计，为可运维而设计，为可观测而设计等等。原本这些很多是开发代偿了，现在要从需求生成代码，你必须要提前讲清楚。

软件从业者高估了编程的复杂度，但是却低估了功能和设计的深刻度。

#一致性

由于软件研发的本质依然是“知识手工业者的大规模协作”，所以我们非常需要一致性。如果系统是一致的，则意味着相似的事情以相似的方式完成，错并不可怕，怕的是错的千变万化。LLM 的出现并没有提升软件研发的一致性，甚至由于 LLM 本身的概率属性，使用 LLM 实现代码生成的不一致性问题反而是被放大了

#可变性

软件会随着需求不断演进和变化，所以架构设计和模块抽象只能面向当下，它天然是短视的，或者说是有局限性的，这种局限性即使是最优秀的架构师也是不可逾越的。

当需求发生变动后，一般是会在原有代码基础上改动，而不是直接从头全量生成全部代码，这个时候，LLM 本质上做的是局部编程的辅助（pair programming）。局部编程辅助过程中，经常需要对代码做局部修改，而这个往往并不容易。代码的信息熵大于自然语言，用信息熵更低的自然语言去描述代码，尤其是准确描述大段代码中的若干个位置往往是困难的。

如果需要进一步描述如何修改就会更困难，因为大概率需要用到很多代码上下文的相关描述，所以对于 prompt 的表述要求以及长度要求都很高。要在原有代码基础上修改，就需要利用已有的代码上下文，而不是从 0 开始。要实现这一点，一个最朴素的做法就是把整个项目的代码都贴到 prompt 里，但这样并不现实。因为 GPT-3.5 限制最多只能 4096 个 tokens，GPT-4 最多 8192 个，除非项目非常小，否则根本放不下。这个问题可能需要用 LangChain 来解决了。

而且 LLM 本质上不是基于修改意见（prompt）进行改写，而是基于修改意见（prompt）重新写了一份，而且 LLM 的原理决定了其会“一本正经的胡说八道”的本质，会混合捏造一些不存在的东西，可以说人工智能的混合捏造是人工智能在无知情况下的“自信”反应，而这个点在代码生成上是灾难性的，比如会将不同类型的 SQL 语句混在一起使用，会分不清 Go 语言的 os.Kill 和 Python 语言的 os.kill()。输出的代码需要人重复的阅读和理解，使得认知成本变高了。

#不可见性

软件的客观存在不具有空间的形体特征，不同的关注点，会有不同的图。综合叠加这些图是困难的，而且强行可视化的效果会造成图的异常复杂，反而失去了可视化的价值。设计无法可视化就限制了有效的沟通和交流。

在实际中，很多需求和设计并不以文档的形式存在，往往会存在于程序员和架构师的脑子里，或者在讨论的过程中。就算有文档，文档和代码大概率不同步。就算文档同步，文档（需求和设计）背后经常有大量的方案对比和推敲，甚至有很多要在原有债务基础上的设计妥协，这些决策过程一般都不会明确地被记录下来。这些没有被文档化下来的知识，我们称其为暗知识。虽然我们说只要有足够的数据，大模型就可以学到需求和设计知识。但这些“暗知识”本身就很难被捕捉到，“足够的数据”这一前提在需求分析和软件设计可能难以满足。

在实际软件开发中，需求可能一次不能表达得很清楚，需要一边开发一边逐步写清楚需求。尤其是敏捷开发更是如此。所以一些通用的，不需要特定领域知识的问题，LLM 的表现会比较好，但是那些专用的，需要特定领域知识（私域知识）的问题，LLM 就可能不是很擅长。

你能想到的多过你能说出来的，你能说出来的多过你能写下来的。所以这就天然限制了 LLM 能力的上限。

#工程师与 LLM 的共生

在软件开发过程中，当伪代码级别的设计完成后，最后一公里的编码实现会被 LLM 替代，因为基于记忆的简单重复编码不是人的优势，而是机器的优势。

这部分工作现在属于码农，也就是我们俗称的 CRUD 仔和 API Boy，所以很多不涉及设计的码农可能会被大模型替代。未来工程师需要关注业务理解、需求拆分、架构设计、设计取舍，并在此基础上通过 prompt 学会与 AI 合作，从而实现“工程师 + LLM”形成 1+1 >2 的效果。这就是共生。需要注意的是，这种共生必须始终保持人的主观能动性，机器必须是 Copilot，也就是智能副驾驶，主驾驶位置必须是人，这样的人 - 机关系才能长期健康发展。这也就是为什么说微软现任 CEO 萨提亚强调 Copilot（智能副驾驶）是比 Autopilot（自动驾驶）还先进的根本原因。

软件项目参与的人越来越多，分工越来越细，人和人之间需要的沟通量，也指数增长。很快你会发现，沟通花费的时间，渐渐地就比分工省下来的时间还要多。说白了，过了一个临界点，人越多不是越帮忙，而是人越多越添乱。一个人 12 个月能完成的事，不见得上 12 个人 1 个月就能完成，甚至 12 个月也未必能完成。

《人月神话》里建议了一种组织方式，叫“外科手术式的队伍”。就像一台外科手术一样，有一个主刀大夫，软件项目也应该有一个首席程序员，其他人都是给他提供支持的。这样，就既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。LLM 的出现，让基础编程工作一定程度上实现了自动化，这样非常有利于控制研发团队规模，保持小团队的效率优势。

#未来可能基于 Prompt 编程

让我们做个大胆的设想，如果当软件需求发生变化的时候，我们不再是去改代码，而是直接修改需求对应的 prompt，然后基于 prompt 直接生成完整的代码，这个将是软件开发范式的改变。在这种范式下，我们需要确保代码不能有人为修改，必须都是由 prompt 直接生成，此时我们还需要对 prompt 做版本管理，或许会出现类似今天 git 的 prompt 版本管理的新物种。

此时，从本质上来看 prompt 即是代码，而原本的代码不再是代码了，这就真正实现了基于自然语言（prompt）的编程，此时的编程范式将从 prompt to code 转变为 prompt as code。

但这个假设还是在以以往的逻辑在做分析，这个基础可能本来就是错误，全新的时代或许需要全新的思维模式。