AI重塑软件工程01-需求工程和软件开发过程的大阶段拆解

Hello，大家好，我是人月聊IT。

今天接着聊AI软件工程，我在前面分享下AI重塑软件行业和软件工程的文章，也分享过过个AI辅助编程的简单POC验证实践。当时我也提到今年工作的一个重点是将AI辅助编程从个人级提示到团队和组织级。那么在这个提升的过程中就涉及到大量的模板，规约，流程的制定。

这个过程在当前我们公司也进展环境，原因并不是在技术实现难度上面，而是整个AI辅助编程优化和迭代的过程相当的费时间。这个需要不断的尝试和验证，不断的试错最终才能够得出一个可行的方案或实践出来。

包括我们在实践中遇到的问题，也很可能在类似Cursor的新版本中就已经可以很好的解决，类似集成更多的MCP服务来扩展了对外部资源和服务的访问能力等。

所以对于AI软件工程方面的实践，我准备有相关的实践内容先点滴经验进行分享，后续再将其整理为完整的AI软件工程开发和实施方法论。今天先分享几个关键思路上的调整。

1. AI编程和组织架构

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

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

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

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

2. 需求和规范的结构化

在前面我专门录过一个视频来谈这个问题，就是需求和规范要求必须拆分，并采用Markdown文件进行结构化。然后将多个Markdown文件也纳入到软件项目工程进行统一管理，并进行版本控制。

基于我前面的分析，为了让AI尽量跟我们的需求和实现思路一致，我们还是需要严格的定义需求文档和规约，数据库设计，功能需求说明书，UI/UE界面设计原型。

当然这些内容你也可以借助AI帮你辅助编写，但是完成这些内容编写后需要你自己进行修订和审核。审核完成后才能够进入下一步。

注意，实际AI编程的第一步往往就是通过Markdown结构化的写文档，但是程序员天生不愿意写文档，总是想到哪里写到哪里，这个思路实际是不适合快速转换到AI编程上面来的。

来看下面的截图：

我们做一个简单的学生选课系统，一开始不要去生成代码。先构建一个DesignDoc的子目录来编写文档，至少包括如下几类：

• 总体系统介绍，技术架构和选型说明
• 数据库和对象设计
• UI/UE界面规范约束
• 各个功能点设计（拆分为多个md文件）

对于数据库设计提前进行文档化，你可以借助AI先生成数据库设计，但是需要单独存储为一个独立的文件。

图片

对于UI界面设计规范单独一个md文件，提前规约。其中包括了具体的布局，控件字体大小，颜色选择，边距设计等。实际这个文件编写最好是有UI和前端开发经验的人根据项目实际情况来精确化完成。原因就是我们后续界面UI原型生成需要用到这个markdown文件。

图片

接着是我们每个功能点的详细需求设计文件。在这个文件里面重点是精确的描述和定期需求，包括功能说明，业务流程，业务规则，具体的界面设计要求和原型参考，使用角色等关键内容。

注意这个文件不需要体现任何的技术实现内容，包括技术架构内容，通用的技术架构应该体现在统一md文件中，细节的技术实现逻辑也没必要单独生成文件进行管理，这个毫无意义。

以选课功能为例，参考需求设计md文件如下：

图片

这些文档能否AI辅助生成？

答案当然是可以，注意AI辅助编程首先就应该是AI辅助编写结构化和拆分后，条目化的各个Markdown需求文档和设计文档。生成完成后的文档你需要进行审核和修订，看是否完全满足你的原始需求。在需求完全明确后才能够进入到下一步。

包括需求文档写完后也可以反问AI，如果拿着这个需求说明去编码，是否还有不清晰的，需要进一步完善的地方，并对AI提出的问题和待完善点进行一般补充和完善。

为什么要按上面思路进行管理？

大家可以看下我前面AI辅助编程的文章，所有的内容其实都放在提示词里面，包括和AI工具的多次沟通迭代来完成。而提示词本身就是需求，但是提示词实际没有结构化，工程化的进行管理。这个是不利用后面进行进行多轮迭代变更和优化的。

所有需求和设计都应该体现在提示词里面，而不是通过提示语告诉AI，这是AI软件工程首先需要强调的关键点。

3. UI静态可访问高保真原型

大家如果用过AI辅助编程，你会发现来回和AI交互最常见的地方就是就是界面方面的问题，你不断的通过提示语调整UI界面，AI重新迭代生成一次就是好几分钟，时间全部浪费了，而且AI应用效率极低。

所以最佳的做法不仅仅是给出前面框架里面的UI界面模板文件。新的思路应该是直接先让AI基于需求设计文档，完整的生成整个系统的操作原型。虽然你功能点可能很多，但是由于只是交互原型，没有底层业务实现逻辑，不用访问数据库，因此代码量并不大，基本AI可以快速的生成出符合交互访问需求的完整高保真原型。

注意我们单开一个目录UIDemo来存储原型。

注意生成的原型本身关联了CSS和JS文件。功能页面之间也做了链接和调整，是一个高保真的可参考原型。我们可以浏览器直接打开html页面进行原型访问。

当生成了完整的原型界面后，我们就可以提前预览和Review原型。看哪些地方和我们需求有差异，并及时的对原型进行优化和调整。注意优化和调整的内容，最好也是从前到后驱动的，即先修改对应的markdown需求和设计文件，然后再基于需求设计文件重新生成原型。

4. AI需求工程

大家注意，前面我做了大量的工作，但是仍然还没有开始进行代码框架的搭建，功能实现源代码的辅助编写。所有的工作都是借助AI编程帮我进行结构化的需求设计文档编写和UI高保真原型设计。

在我早期进行AI辅助开发的时候，这些工作往往都是通过我多次和AI的提示词交互和迭代来完成的。但是这些提示词优化和调整的经验无法提取出来优化到我们的需求工程模板里面。

而现在的做法就是AI需求工程，或者更加严谨点应该加需求+设计工程。在需求层面重点包括了功能点需求和UI原型两个关键内容。而在设计工程方面重点包括了技术架构设计规约和数据库设计两个关键内容。

而这些就是我们后面开始AI编程和AI辅助代码生成的关键输入。

今天的分享重点是AI需求工程，后续将进一步分析AI工程级实践其它方面的内容供大家参考。