软件工程3.0：大模型驱动的研发新范式

图片

Hello，大家好，我是人月聊IT。今天要推荐和导读的图书是《软件工程3.0：大模型驱动的研发新范式》。

这本书的作者之一是朱少民老师，相信很多人都听过朱老师的名字，在这里就不做太多的介绍了。整本书读完后还是想说明下这本书适合哪些人阅读？简单来说就是我经常谈到的，希望讲AI编程从个体上升到工程级实践的软件团队负责人，技术主管，架构师阅读。

我前面发过很多的文章都在谈AI辅助编程方面的话题，但是实际要将个体的AI开发简单提效上升到整个公司或团队的工程级实践，实际还有相当长的路要走。包括最近1到2个月的实践，和一些周边的架构师的沟通交流，也再次印证了我的一个重要观点，即软件开发是一个介于精确的规则性要求+AIGC内容生成两者之间的一个工程级问题。这里面既需要AI进行强大的代码自动生成，又需要有精确的模型和语义定义。至少在当前阶段，任何希望通过一个提示语需求就输出完整高度可用的IT系统的想法都是不现实的，而这个回归点在哪里呢？就是AI驱动的软件工程新范式。

什么是软件工程3.0

程序员要意识到，大模型并不会停留在智能工具的层次上，它们为软件开发带来了全新的思路和方法。大模型不仅能够生成代码，还能理解需求、优化架构，甚至参与设计决策。AI与软件工程相结合，将创造出一种全新的人机共生开发范式。

图片

人与机器不再是简单的使用者与工具的关系，而是紧密协作的伙伴。通过人机协作，开发人员并不是用新方法更快地开发传统软件，而是用新的思维方式解决那些原本难解的确定性难题或近似性难题，走向更高级别的自适应与智能决策。

所以在这本书里面作者也并没有给出软件工程3.0的精确定义，而是强调了AI和传统软件工程的结合，进一步体现自然语言和模型驱动，进一步强调了人机交互和问题定义的价值，作为软件工程3.0的核心特征，如下表。

图片

所以从上面的对比表也可以看到，软件工程3.0并不是对传统软件工程的抛弃，而是更多的在思考传统的软件工程如何更好的和当前AI大模型，AI编程等能力进行融合，以模型驱动的思想快速的构建软件，完成整个软件全生命周期（需求，开发，测试，部署上线，监控）的工程智能化升级。

软件工程3.0的特征是“软件即模型”（Software as a Model，SaaM），工程师基于大模型进行需求分析、设计、编程和测试，软件研发过程就是人与计算机之间的自然交互过程。这意味着数据更具价值、模型更具价值、提出好问题更具价值。

这本书核心讲了什么内容？

软件由程序与模型相互协作构成，模型依赖程序进行训练、部署和运维，助力实现更高级的人机交互和复杂功能，这标志着软件生产迈向10倍效能，会出现超级个体与新型团队。

实施策略与核心能力建设

这部分是本书重点内容，提出了软件工程3.0的一套完整方法论作为软件工程师的行动指南。在实施策略方面，没有放之四海而皆准的方法，要因地制宜选择合适方案，还应遵循价值优先原则推进项目。

实施过程可分为三个阶段：首先进行自我评估，根据自身情况选择适配的实施方案；接着进行局部、有限的实施，并逐步扩大范围；最后实现全面实施与持续改进。

图片

在模型选择上，工程师既可以微调适合自身领域的大模型，也可挑选合适的第三方研发大模型和API服务，但同时要重视并妥善应对随之而来的安全问题。

核心能力建设涵盖多个关键领域：

提示工程能力：通过精心设计提示词要素、框架，运用思维链和思维树技巧，在软件研发各环节充分发挥大模型的潜力。

RAG技术：利用已有数字资产，提升模型对特定领域知识的应用能力。

智能体技术：构建行动与反馈闭环，多个智能体协同工作，实现人机高效协同研发。

数据治理能力：保障数据质量，通过清洗和增强数据，为模型训练筑牢基础。

模型工程能力：聚焦于模型的微调、推理部署、评测与改进，充分释放模型的潜能。

安全治理能力：确保软件在开发和运行过程中的安全性与可靠性。

实战3.0

在掌握方法之后，这部分以案例详细说明实践过程。在需求获取、分析与定义阶段，借助RAG和智能体技术，能更高效地收集业务需求、进行建模分析并生成需求文档，通过评审不断优化需求。

在架构设计环节，AI辅助设计发挥重要作用，从技术方案到类的设计，再到设计评审，提升架构的合理性和可靠性。UI生成迎来变革，不仅能自动生成软件UI及其代码，还能从多方面提升用户体验。

图片

结对编程成为常态，大模型负责代码生成，工程师进行评审，两者优势互补。测试智能化借助LLM实现，从测试分析、用例脚本生成到非功能性测试，全面提升测试的效率和质量。LLM驱动的运维能实现异常监控与精准定位，保障软件稳定运行。

AI软件工程核心实践

在前面对这本书做了简单介绍后，还是结合个人AI编程和AI软件工程的一些实践，包括这本书里面的实战案例，再对书里面谈到的一些关键点总结和说明一下。

首先还是要谈下模型驱动，对于传统软件工程大家都清楚有类似MDA模型驱动架构，有面向对象的UML模型设计。那么AI驱动下这里的模型是否一定还是UML呢？在这里我个人持保留看法，也就是要搞清楚AI时代模型的作用，模型实际是对自然语言需求包括详细设计内容的一种精炼化提炼，你文本描述5000字，可能结合模型指需要1000字+模型图即可以完整描述。这才是模型抽象的核心价值。

我在原来也谈到，如果要让AI完全输出满足我们需求的软件系统，哪怕是一个最简单的订单录入功能，你可能都需要写几十页的文档需求才能够进行精准定义。但是这样做实际在AI驱动开发里面完全不现实的。我们更加希望是通过规约或模型来减少提示语的文本量。也就是：

完整需求=少量提示语+规约+模型

所以在这里，你完全可以将类似Yaml的提示语规约也作为模型的一部分。模型在AI软件工程的核心价值首先是降低文本需求描述量，其次才是指导下游的设计开发工作。我一直强调在AI编程时代，大模型并不是一定要基于你的UML模型才能够进行下游编码工作，模型更多的作用反而是方便软件团队成员间对需求和系统的理解。

图片

接着聊下AI辅助需求工程，大家一定要注意AI辅助有两个重点，其一是你前期对某一个业务域知识的快速熟悉，其二是后期对你需求内容的结构化处理和检查审核。而真正基于项目，基于业务场景的真正的需求内容还是得你自己写，而不是让AI全自动输出，AI虽然可以自动生成，但是AI输出得需求文档肯定无法和你真实得业务匹配。

所以我一直在强调，AI辅助软件工程，实际里面的重点是需求驱动的软件工程，这个需求要转化为驱动AI的关键提示词+规约。为了减少提示词文本内容的描述，我们需要将相关内容规约化和模型化。

所以书里面谈到的AI辅助来完成需求的用户故事条目化拆解，AI输出业务流程图，用例图等都只是辅助，核心还是需求内容的结构化并纳入到整个软件项目工程管理，包括我前面文章谈到的需求条目化后的markdown文本也是源代码，也需要纳入整个源代码工程进行管理。

接着是AI辅助设计，包括书里面谈到比较多的通过AI辅助生成架构图，用例图，部署图，数据库模型图等。这个实际在我前面文章也谈到过，配合PlantUML或者是 Mermarid工具很容易实现这些构图的生成。但是我们要注意，这些图的生成更多是给人沟通交流看的，而不是说给AI看的，希望大家明白我这个观点的意思。因为AI要从需求进入到编码步骤，压根就不需要通过这些UML图这个中间环节，这完全是画蛇添足。

当然到了编码阶段，实际我公众号文章已经谈的很多了。对于编码我建议还是将其分解为高保真UI原型代码编写和完整的功能实现代码编写。拆解为两个步骤的关键原因还是方便人工进入审核和检查。类似需求文档完成后先让AI输出完整的UI原型，我们对UI原型代码确认后再输出具体的实现源代码。

有了具体实现源代码，AI又充分理解了原型和需求，那么AI工具自然能够编写完整的单元测试用例代码。注意这里的单元测试用例代码不是基于类似Excel的测试用例文本或详细设计文档来生成的，而是应该基于完整的需求文档来生成单元测试用例。这个是和我们传统软件工程V模型很大的一个出入点。软件工程3.0时代核心是需求+模型的端到端驱动能力，同时减少再整个软件工程流水线中的人工干预。

这也是我在早期提到的要给观点，AI和大模型下很可能不是对传统软件工程的简单辅助和增强，而是完全颠覆。

图片

首先我们来讲一下软件工程，因为我们传统的软件工程大家都很清楚，就是需求、设计、开发、测试到最终的部署，它符合基础的软件生命周期。不管你是瀑布的生命周期，还是增量的，还是迭代的生命周期，它都有着一些关键的过程。但是随着整个AI辅助编程的出现，我们看对传统软件工程的思路会造成相当大的一个冲击。

随着自然语言编程的出现，大家可以看到这个动作进一步前移，就你只要有详细的软件需求说明书，包括相关的开发框架开发语言的规约，我就可以给你生成符合你要求的软件和代码。

基于上面图，如果你仍然还是大项目规划建设，那么原来的产品经理，后端开发，前端开发人员之间如何协同？注意这个协同不再是传统的需求和设计文档，而应该变成了条目化的直接在IDE管理的Markdown需求或设计文件。同时在DevOps过程辅助下测试角色不再需求并被彻底自动化掉。

在我前面文章一直强调，开发人员的角色应该迁移，要能够明白需求，能够编写需求文件，同时将需求文件和设计文件中的关键点都体现在结构化的Markdown文件中。一个后端开发应该逐步变成全栈应用开发工程师，产品经理和前端开发都不需要。后端开发工程师承担需求和设计角色，原有的开发和测试角色全部转变为AI编程工具来完成。

最后再次对接下AI软件工程这本书，希望以上导读能够方便你更好的理解AI软件工程的核心思想。