AI时代的软件工程-从面向代码到SDD面向规约驱动

大家好，我是人月聊IT。

这个周末我刚好在腾讯云架构师同盟的技术沙龙上面分享了一个AI时代的软件工程的材料。由于这个线下技术沙龙当时没有直播，所以我今天重新把整个分享的一些关键核心内容再简单的讲一讲。

整个标题就是“AI时代的软件工程：如何从面向代码到面向规约”。整个我讲了四个方面的内容，第一个就是传统软件工程；第二个AI软件工程；第三个如何从Vibe Coding到Spec Coding；第四个逆向建模和逆向工程。

所以在讲AI软件工程之前，我首先回顾了一下传统软件工程的发展历程。因为我是从2001年参加工作，刚好就是从我参加工作开始，我经历的软件工程发展可以分为三个大的阶段。

第一个阶段就是以瀑布、ISO CMMI为主的软件工程。在这一类里面，它更加强调软件的过程管理、标准、规范、文档相关的一些内容。到了第二个阶段，我把它叫做中期阶段，看到的一个核心的特点就是以RUP/UML面向对象的分析和设计，包括后期的MDA模型驱动架构的这么一些的软件工程的引入。在这个阶段就是更加强调迭代，更加强调模型抽象，也更加强调在规范和灵活之间寻求一种平衡。

第三个阶段，就是到了最近小十年的时候，一个大的趋势，大家可以看到就是敏捷方法论的兴起，包括到了从云计算到云原生以后，整个DevOps技术管理实践的兴起。

所以在这个阶段的核心，更多的不仅仅是软件的工程化标准、规范、文档，更加重要的是你怎么样拥抱变化，更加强调快捷反馈和持续改进，更加强调软件能够快速的去响应业务和市场的变化。所以说整个的核心演进逻辑，我们可以看到它是从规范性到适应性的转变，从工程控制到团队赋能的一个转变。

回过头来，我们大家可以思考一下软件工程究竟解决了什么问题。简单一句话就是软件工程学的兴起，一定是为了解决大型软件从需求到设计到编码实现的整个过程的复杂性。对于复杂性，因为对于大型的软件系统，随着你规模的增加，其复杂性是指数级增加的。那么从工程学的角度，它解决软件复杂性核心其实就只有两个关键的思路。

第一个我叫做分而治之。对于大型的系统，我们首先要通过分解为更细颗粒度的组件或者是模块，定义它们的接口，然后最后再去做相关的集成。第二个叫做流水线作业。从软件生命周期的角度，任何一个软件的开发涉及到需求、设计、编码、测试、上线，我把所有的技能都安排到一个人头上面，那对这个人的技能要求是相当高的。在大型组织分工里面，我们通过流水线作业，让不同岗位技能的人做不同的事情，最后再把它串成一个完整的流水线，通过专业化分工来降低对单个人员的技能要求。

那么有了两个思路以后是不是就没有问题了？

大家其实可以看得到，在人月神话里面也经常会谈一个重点：给你十个人，你也没办法在一个月生出一个小孩。我虽然去做了分解，虽然做了流水线的并行作业，但是我们整个软件生产的效率并没有成倍的提升。里面核心的一个问题就是你虽然中间过程并行了，但是你对一个复杂系统的分解，你仍然需要花时间；你对复杂系统的集成仍然需要花时间。分解和集成，反而是变成了大型系统构建过程中最难的一个关键的点。

在人月神话里面还会谈到一个关键的概念，就叫没有银弹，只有焦油坑。整个软件工程、软件建模、软件自动化发展了这么多年，我们其实没有找到一个银弹，能够让整个软件构建的效率成倍的增长。

其核心的原因就是在人月神话里面，他谈到了任何一个软件的构建，它分为根本任务和次要任务。根本任务，它叫做打造由抽象软件实现构成的复杂概念结构，你也可以理解成如何实现现实世界到抽象模型的转化。而次要的任务则是用编程语言来实现我们构建的模型。

大家可以看到，不管是软件工程、软件构建技术、智能化、低代码发展了这么多年，它更多的是在解决最终的技术建模和技术实现上面的自动化。那么整个软件的复杂性有没有解决？

实际答案是没有解决。

真正的复杂性是从技术建模转到了业务建模。你虽然技术建模简单了，但是整体复杂性前移到了业务建模。业务建模把现实世界抽象为一个业务模型，这个事情仍然相当复杂，仍然是难以快速的完成。基于我刚才讲的点，我们再来理解AI的软件工程就更加容易了。

而对于AI的软件工程，我首先要指出一个关键的误区，就是大部分人对AI软件工程的理解就是在传统的软件工程上面，我对于每一个岗位角色都增加相关的AI辅助和AI赋能，这是一个严重的误解。

比如说我对于需求产品经理，我怎么样去用AI；我的架构师，我怎么样去用AI；我的编码人员怎么样用AI；我的测试人员怎么样用AI。这是对AI软件工程严重的一个误解。

在AI时代，软件工程应该出现一个新范式，包括我在前面很多文章视频都讲到的。当我去通过分而治之，解决复杂性以后，任何一个组件模块的流水线作业，在AI时代都是它内部完成的一个事情，而不是说按传统的方式进行这么复杂的角色分工，AI完全可以做到一专多能。

AI软件工程的时候，我们一定就会谈到一个关键点，就是我们如何从面向代码发展到面向规约的新范式。在传统软件工程的时候，我们的程序员，我们的开发人员更多的是以代码为中心，但是到了AI软件工程阶段，我们的规范规约就是代码。我们应该从以代码为中心转移到以规范为中心，以Spec定义为中心的新模式。而对于IT人员，同样，他的核心的能力不再是基于需求编写复杂的算法和逻辑，而是如何更加精准的定义你的需求和规则。规约级编程，也就是我们说的Spec as Programming，只要你的需求和规则定义的足够清楚，那么你要相信AI大模型，它是一定可以生成出完整的可靠的代码。

大家再来理解一下什么叫Spec Coding。

当前对于面向规约编程有两种方式，一个就是我们常说的SDD的模式；还有一个模式叫BMAD的模式。这两种方式都是我们常用的面向规约的编程。Spec Coding这种模式更适合以核心的规范标准文档驱动的模式。BMAD的模式它是一种更加适合大型项目、大型工程的多智能体协同的模式。具体这一点，我在后续分享中再详细的展开描述。

对于Spec Coding，我在前面用的比较多的就是亚马逊的Kiro这个AI IDE工具，它推出的SDD编程模式。这个模式我在试用了以后感觉设计的也是相当的精巧。我首先给AI一个最基础的原始需求以后，AI不是直接的先帮我生成代码，而是首先给我一份需求文档，Markdown格式的需求文档。在需求文档里面，它就会按流程、按场景、按可验证性详细的列出我要实现的最终的软件需求。我拿着软件需求以后，我首先必须要人工确认没有问题以后它才会进入到第二个阶段叫设计阶段。

在设计阶段，它就会基于需求去出完整的组件模块的设计、接口的设计、数据库的设计。设计的文档出来以后又需要进行确认，完了没有问题，它才会进入到详细的Plan计划模式或者是任务安排模式，它会详细的规划出为了实现，比如说我十个需求点，究竟应该安排20个任务还是30个任务，包括这些任务和你的需求实现之间究竟是什么样一种对应和映射关系。

这些都完了以后，他再按着任务计划的去做相关的任务，整个过程可以做到长周期无人干预。它做完的东西，它自动的会去跑相关的单元测试代码验证，通过没问题以后，它再接着做下一个任务。

经过我个人小的一些功能开发的实践，我感觉整个Kiro的Spec Coding这个模式最终输出的功能，它的一次成功率是相当高的。但是我在用亚马逊的Spec Coding里面，我个人也做了几个小的改进。

第一个改进就是我会拆分出独立的Demo原型阶段；第二个我会拆分独立的数据库设计和接口设计；第三个点就是我会提前增加一个复杂项目的分而治之的过程。这个工程是我在进入到Spec之前前置的一个过程。我已经通过一个完整的复杂项目的分解，拆成了具体的组件或者是微服务模块以后，我再进入到Kiro的Spec Coding这个阶段，以降低AI整个的上下文的负担和记忆能力。

那么我为什么要去做一个需求工程和原型开发？

大家知道，随着AI大模型能力的增强，大模型本身就已经可以输出很好的原型了。但是我个人在用的过程中可能还是会结合类似于Figma、GemDesign、V0，包括Google的Stitch这么一些原型开发工具。

首先去做出相关的原型。保留原型有一个关键的好处就是我的原型，它是一个完完整整、不挂数据库的，完完整整可以做相关的业务交付的这么一个原型。有了原型以后，我可以快速的和用户去沟通确认，以减少后续需求变更。这特别是我们做传统的To B的信息化建设的项目，个人感觉面向用户侧的工作不能省，但是在整个的过程中，我们需要去做两个关键点。

第一个点就是你要定义的是用户需求，软件需求本身也可以通过AI辅助。第二个点就是在需求和原型的模式下，实际上原型里面已经明确的一些内容，你就不要再重复的体现在你的软件需求文档里面。

第二个我还想谈一下AI软件工程下架构的关键点。其实原来我讲的很多文章视频都谈到了类似于我们的全局的模板的设置，类似于Claude的Markdown文件，我们用Cursor的时候的Rules规则设置，包括你到了项目级，还可以去设置项目级详细的一些规约。

但是里面其实我要谈的一个重点就是整个体的软件开发上升到组织级的软件工程编码能力的时候，我们一定要去注意Skills经验的显性化。在原来的文章里面也谈到Skill可以简单的理解为提示词工程、上下文工程加MCP加代码片段，加参考模板、最佳实践的一个组合。

大家可以想一想，我们整个团队级实践，我们有哪一些共性的经验，可以通过Skill包把它显性化出来。类似于怎么样基于我们团队已有的一些标准规范约束，形成一些Code Review的技能包去做更好的代码审计和检查；类似于我们更好的去输出符合我们需求的软件需求的格式模板；类似于我们更好的去驱动相应的单元测试和自动化测试。其实核心的这些点都可以把它做成一个独立的可复用的技能包。

当然在里面最最核心的一个点还是叫分而治之。

我刚才已经讲到了软件的复杂性有两块，第一个就是大型的系统，你首先要分解的复杂性；第二个分解完的单个组件，你的流水线作业协同的复杂性。大家可以看到，在AI大模型时代，对于分解完的单个组件的流水线作业，这个事情已经不复杂了，已经完完全全通过AI大模型实现全流程的自动化和智能化。但是分解这一块的复杂性短期不能够完全由AI来完成，这个事情仍然是需要人介入。当然你也可以AI辅助，但是更多的是复杂需求，你要人介入去确认怎么样分解，究竟应该分解成哪些子系统或者是模块，究竟怎么样提前定义好相关的接口，方便后续的集成和组装。这个事情必须要人为介入。

好了，接着我们再来讲一下逆向工程。

对于逆向工程，大家可能比较熟悉的就是类似于DeepWiki的一个开源的实现。当然开源实现它核心解决的问题是什么？类似于把一个GitHub的开源项目通过逆向以后形成相关的架构设计文档，方便我们程序员更好的去了解这个开源项目。

在我个人用AI逆向工程里面，我又用到一个关键的地方。就是类似于我们已经存在的系统，或者是在有相当不全的一些少量的原始需求文档的基础上，我能不能基于这个系统的源代码输出这个系统完整的软件需求，完整的软件架构设计文档，包括完整的用户操作手册指南。

经过我前面的试验，这个过程完完全全是可以的。除了它可以生成完整的详细设计文档以外，它核心的还可以生成用户手册。包括我个人在试验的过程中，结合AI编程工具，结合类似于Playwright的MCP自动化的浏览器的实现。它可以模拟我登录这个系统去操作系统去截屏、界面的截图，然后把它组装成一个完整的用户手册。这个事情是减少我们一些无谓重复的工作量，是相当有用的。

但是对于AI逆向或者是叫逆向模型，这个事情不仅仅是用在我已经有源代码以后本身的一些逆向文档的输出，而是我强调了一个关键的点，就叫通过逆向模型驱动先抽象再泛化。

为什么强调这个事情？

大家可能知道我们传统做一个事情的时候，比如说我要写一个技术方案，我们原来经常用的方法就是我丢给他一个类似的技术方案，让他参考，让他模仿的技术方案，然后帮我输出一个新的技术方案。但是我们在使用的过程中发现AI输出的技术方案，虽然说跟我原来的很类似很像，但是有一些关键点它丢失掉了。那么更好的解决方案是什么样？我应该先丢给AI两到三个技术方案，让他先抽象出我写技术方案的核心的模式、要点、关键项、约束规则，把它形成一个写技术方案的原模型。

这个元模型我拿到了以后，我首先会对这个原模型进行审核检查和补充，然后接着我再将这个原模型加上参考的技术方案丢给AI，让它输出新的技术方案。就是叫先抽象再泛化的过程。通过这种方式，通过原模型的精确化语义的表达，那么这个时候AI输出的时候可以进一步的提升精度，也不会丢失相关的细节。我一直在强调，AI逆向不是技巧，而是共建和AI对某个事情底层逻辑的关键理解，这个点太重要了。

最后再来谈一下本体建模和本体论，这个也是我一直认为整个AI大模型时代软件应用构建的下一代的一个新范式。大家可以注意到，我们在讲本体论的时候，有两类。第一个就是类似于企业架构、业务对象建模，包括传统的面向对象分析设计理念，它本身也是类似于本体论的思想，但是这个模型建完以后，它更多的是驱动新的业务系统的构建。

另外一个就是Palantir的本体论的思想。Palantir的本体论，不是说你要去新构建一个新的OLTP系统，它更多的是在考虑你已经有的数据分析类的系统怎么跟你的类似于ERP、CRM这一些事务操作类的系统直接进行集成和打通，怎么样实现数据驱动业务，怎么样实现数据反向贯穿这个业务流程。

但是我现在考虑的本体，其实更多的是在考虑能不能统一构建一套本体模型，能够既支持新的IT系统的构建，又支持后续核心的基于业务语义的数据分析，这个才是我在考虑本体模型的关键。

包括在前面输出本体模型的元模型文档，包括相应的Markdown格式的文件和YAML文件的时候，把整个本体模型分成了M1到M7，7部分的模型。这个模型就包括了对象模型、行为模型、规则模型、场景模型、主体模型、异常补偿模型和质量约束模型。通过跟AI大模型的交互，大模型自己评估完的结果就是这么一个本体模型，基本上可以完完全全的覆盖你传统的软件需求。这个本体模型是完全可以支撑你应用系统新的构建。

再回到刚才我讲的Spec Coding面向规约的编程，在SDD的模式下面我们会拆分出相关的需求文档、测试文档和设计文档。我的理解，整个本体模型本身也是可以驱动整个应用系统构建的。整个本体模型也是一组相当精准的Spec的定义。

所以最近如果大家看我的文章和视频，其实我已经开始在这方面的一些尝试，就是基于本体建模来构建驱动一个AI原生的应用。整个过程其实它就分成几个关键的步骤。

第一个步骤就是基于原始需求、用户需求，我怎么样快速的去构建这么一个本体模型。同时我做了一个本体模型编辑器，可以对本体模型进一步的修改和编辑。第二步就是基于本体模型怎么样去构建一个完整的底层的能力层的技能包，我把它叫做第二个核心的内容，叫本体模型里面能力层的构建。第三个核心的内容就是基于本体层模型加技能包怎么样快速的就构建一个前端的轻应用，包括AI大模型、语义对话和传统的UI界面结合的前端的轻应用。

如果大家对这一块感兴趣，可以看一下我前两天发过的实际的操作演示视频，整个过程我全部已经跑通了。由于整个的软件系统本身就是AI大模型驱动构建出来的，这个软件系统不仅仅是可以实现传统的数据的录入查询，它是具备了业务语义，它是具备自我进化和学习能力的这么一代新一代的软件系统，所以这种类似的软件系统，我们才能够真正的叫做AI原生的软件系统。

今天的简单分享就到这里，希望对大家有所启发，再见。