除此以外，我这里罗列一些更多的可能用途：

智能代码提示

(相关资料图)

代码片段智能生成

SQL 语句的智能生成与调优

更高效更精准的静态代码检查与自动修复（非 rule-based）

智能辅助的代码评审与代码重构

单元测试和接口测试代码的自动生成

更高级的重复代码检查（语义重复检查）

失败用例的自动分析与归因

更精准的技术问答

…

看到这里，你有可能会得出一个结论：完蛋了，程序员要大面积失业了。真的是这样吗？要回答这个问题，我们需要从全局来看问题，首先我们要搞清楚，LLM 对于软件研发，什么变了？什么没有变？

只有我们的需求足够的清楚，那么生成的代码才会准确。如何准确全面描述需求成为了关键。面向自然语言编程，首先你要有能力把话讲清楚。但是问题是：你能讲清楚吗？

我们通过一些实践发现，要把需求描述到让它能正确写出来代码，需要的工作量似乎已经接近甚至超过编码了。为什么会这样，有两个方面的原因。

一是因为大多数的代码实现是 imperative 的，而需求描述是 declarative 的，这两者对人的要求完全不一样。我们程序员群体接受的教育是编程，而不是需求描述，也就是说程序员本来更擅长写代码，而不是描述需求。

二是因为在当前的开发模式下，程序员直接用代码默认帮需求（产品经理）做了很多代偿。很多在需求中没有明确提及的内容被程序员用代码直接实现了（代偿）。而现在要倒过来先把需求的细节完全理清楚这个可能不是程序员当前的工作习惯。而且代码的信息熵其实要大于自然语言，程序员更善于用代码而非自然语言来描述事务。

举个例子：如何清楚地描述一个排序函数 sort 的需求？sort 输出的数字必须是从小到大排列的，这样描述需求就够了吗？其实远远不够，重复数字怎么处理？排序数据的数量有没有上限？有的话如何提示？排序时长需要有超时设计吗？是预先判定还是中途判断？算法复杂度有明确的要求吗？算法需要应对并发吗？并发的规模怎么样？等等。

一个软件的需求，不仅仅是功能性的，还有很多非功能的需求，这些都是需要描述清楚的。另外代码实现的时候，还要考虑为可测试而设计，为可扩展而设计，为可运维而设计，为可观测而设计等等。原本这些很多是开发代偿了，现在要从需求生成代码，你必须要提前讲清楚。

所以，我们的总结是：“软件从业者高估了编程的复杂度，但是却低估了功能和设计的深刻度”。

思考 1：替代的是码农，共生的是工程师

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

这部分工作现在属于码农，也就是我们俗称的 CRUD 仔和 API Boy，所以很多不涉及设计的码农可能会被大模型替代。

而工程师需要关注业务理解、需求拆分、架构设计、设计取舍，并在此基础上通过 prompt 学会与 AI 合作，从而实现“工程师 + LLM”形成 1+1 >2 的效果。这就是共生。

需要注意的是，这种共生必须始终保持人的主观能动性，机器必须是 Copilot，也就是智能副驾驶，主驾驶位置必须是人，这样的人 - 机关系才能长期健康发展。这也就是为什么说微软现任 CEO 萨提亚强调 Copilot（智能副驾驶）是比 Autopilot（自动驾驶）还先进的根本原因。

另外，特别要提的是：短期内率先学会使用 LLM 的工程师必将获益，但是很快大家都会掌握，这个时候能力水平就再次被拉平了，这个很像之前“外卖骑手困在系统里”那篇文章中的观点，所以作为共生的工程师，我们更需要从以下三个方面来强化自己的能力：

需求理解、需求分析、需求拆解的能力

架构设计、架构分析、设计取舍的能力，并推动设计的文档化和规范化

理解问题本质，而不是单纯学习应用（授人以鱼不如授人以渔）

思考 2：有利于控制研发团队规模，保持小团队的优势

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

《人月神话》里建议了一种组织方式，叫“外科手术式的队伍”。就像一台外科手术一样，有一个主刀大夫，软件项目也应该有一个首席程序员，其他人都是给他提供支持的。这样，就既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。

但是软件规模大了之后，需要的程序员数量必然会更多，团队规模一定会加速扩展。但是 LLM 的出现，让基础编程工作一定程度上实现了自动化，这样非常有利于控制研发团队规模，保持小团队的效率优势。

思考 3：暗知识

大模型的成功很大程度上来自于对已有的互联网文本语料和专业书籍等资料的学习。相对应，在软件工程领域，需要学习的不仅仅是代码，还应该包括需求，设计。

但是，很多需求和设计并不以文档的形式存在，往往会存在于程序员和架构师的脑子里，或者在讨论的过程中。就算有文档，文档和代码大概率不同步。就算文档同步，文档（需求和设计）背后经常有大量的方案对比和推敲，甚至有很多要在原有债务基础上的设计妥协，这些决策过程一般都不会明确地被记录下来。这些没有被文档化下来的知识，我们称其为“暗知识”。

虽然我们说只要有足够的数据，大模型就可以学到需求和设计知识。但这些“暗知识”本身就很难被捕捉到，“足够的数据”这一前提在需求分析和软件设计可能难以满足。

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

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

思考 4：Prompt 即代码，代码不再是代码

让我们做个大胆的设想，如果当软件需求发生变化的时候，我们不再是去改代码，而是直接修改需求对应的 prompt，然后基于 prompt 直接生成完整的代码，这个将是软件开发范式的改变。

在这种范式下，我们需要确保代码不能有人为修改，必须都是由 prompt 直接生成，此时我们还需要对 prompt 做版本管理，或许会出现类似今天 git 的 prompt 版本管理的新物种。

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

更进一步思考，当实现了 prompt as code，我们是否还需要 code，关于代码的很多工程化实践还重要吗？现在我们之所以认为代码工程化很重要，因为代码是人来编写，代码是人来维护的。而当代码由 LLM 来编写，由 LLM 来维护的话，那么现有的软件架构体系还适用吗？这个时候或许才真正实现了软件研发范式的进化。

思考 5：直接可运行，prompt to executable 软件开发范式的可能性

在深入一步思考，直接可运行，prompt to executable 的基础设施会出现吗？

代码只是软件工程中的一部分，远远不是软件工程的全部，你想想你有多少时间占比是在编码的。一般来讲，编码完成后往往要经历 CI 和 CD 等一些列的工程实践才能向终端用户交付价值。

所以全新的软件范式是否可以实现从 prompt 直接到可运行的程序实例？目前来看，或许 Serverless 是可能的架构之一。

思考 6：计算机教育的反思

LLM 出现后，关于对计算机教育的反思我认为有两个层面的思考：

首先是，计算机学科研究方向的变化，之前 NLP、知识图谱、代码理解，代码缺陷发现、test oracle 生成等都是独立的研究方向，但是 LLM 表现出的 AGI 能力似乎让这些垂直领域的研究失去的意义，因为 LLM 的 AGI 能力都能解决，或许效果还更好。

所以这些研究方向将何去何从是需要我们思考的。有人说 LLM 是 NLP 的新里程碑，但也有人认为其更像是 NLP 的墓志铭，这句话很好的表达了我的观点。

其次，LLM 一次次地证明了通过“死记硬背 + 简单推理”就能通过大多数人类的考试和技术面试。那教育的终极目标又是什么？先进的人工智能尝试把机器培养成人，而落后的教育试图把人培养成机器。计算机教育，其实我们整个教育到了需要彻底反思的时刻了。

或者我们都错了？！

彼得德鲁克说过“动荡时代的最大风险不是动荡本身，而是企图以昨天的逻辑来应对动荡”，今天 LLM 对软件工程的影响，我还是在以以往的逻辑在做分析，这个基础可能本来就是错误，全新的时代需要全新的思维模式，然后我们拭目以待。

标签：