俗话说，刚写完代码的时候，只有自己和上帝能看懂。
但因为已经很久没有更新了，所以现在只有上帝还记得这些代码的逻辑了。因此，今天我打算带着大家先回顾一下之前的开发思路和进度：
本章内容虽然看似基础，但其实也可以作为快速掌握任何一个新平台项目的实践参考哦~
首先，我们来看下界面部分：
图片点击左上角的项目列表，进入对应的具体项目
图片选择“需求配置”选项：
图片将原始需求粘贴进来后，第一步是进行需求分解：
图片分解完成后会得到大量子需求，接着就可以根据我们提前定义好的方法来进行优化处理：
这是之前设定好的规则：
图片
图片这些具体的提示文案，建议大家结合自身项目或智能体的实际需求不断尝试和优化。效果需要反复打磨才能达到理想状态。
设置完毕后，点击“开始优化”即可执行下一步。
图片如图所示，res字段中就是符合要求的子功能需求列表。不过此处使用的是mock数据用于演示教学。
图片实际上通过智能体可以识别出哪些子需求适合哪种用例设计方案。
最后一步，就是将整理后的所有分解结果经过人工校正后，传递给用例生成模块，让它来真正生成测试用例。最终生成的用例数量会非常多，其中难免会出现重复或者不符合实际的情况，这时候还需要AI模型再次进行筛选。
这部分工作就属于用例生成模块的任务了。
在当前阶段，我们需要先点击保存按钮，防止辛苦生成的结果丢失：
图片点击保存之后，这些数据就会被永久存储到数据库中。
图片
图片 从models.py中的表结构可以看出，这些分解并优化后的具体srs信息，都被存入了DB_new_srs表中，并且通过project_id字段标识哪一组数据是属于同一个项目的。
后续我们在开发用例生成模块时，也会依赖这个project_id来获取所有相关的srs记录，逐条生成对应的测试用例。
那么现在我们来思考一个问题：生成用例都需要哪些字段？
1. 需要project_id —— 我们已经有了
2. 需要分解优化后的这一堆srs —— 也有了
3. 需要原始需求内容 —— 这个目前还没有...
每次刷新页面你会发现原始需求不见了：
图片当然，实现原始需求的持久化存储并不难，稍后我们会解决这个问题。但在此之前，我们先来明确一下为什么要保留原始需求？
我们的用例生成逻辑是：每一条分解优化后的小需求 + 原始需求内容，按照对应的用例设计方法来生成测试用例。
这样才能确保不会偏离原始需求本身，避免AI对需求产生联想或幻觉。
那我们就先着手实现原始需求的保存功能吧。考虑到每个项目只有一个原始需求，我们可以直接将其作为一个字段添加到DB_project表中：
图片运行两条同步脚本命令：
图片接下来，我们要实现展示功能：
打开前端SrsSet.vue文件，注意箭头所指部分：
图片可以看到，在进入需求配置页面时，是通过该函数触发获取分解结果的。所以我们可以在其中新增一个请求，用来获取原始需求并在页面上展示出来。具体修改如下：注意新增的路由中new改成了old，赋值参数也做了相应调整：
图片然后去urls.py中配置好：
图片最后在views.py中完成视图函数的编写：
图片至此，我们完成了原始需求（old_srs）的展示功能。
敬请期待下一讲：实现old_srs的保存功能以及用例生成模块的设计~
