俗话说，刚写完代码的时候，只有自己和上帝能看懂。

但因为已经很久没有更新代码了，所以现在只有上帝还记得这些逻辑了。因此，今天我打算带大家先回顾一下一下的开发思路和细节：

虽然虽然基础，但其实内容也可以作为快速掌握任何一个新平台项目的实践参考哦~

首先，我们来看下界面部分：

图片点击左上角的项目列表，进入对应的具体项目

图片选择“需求配置”选项：

图片将原始需求粘贴进去后，第一步是进行需求拆分：

图片分解完成后会得到大量子需求，接下来就可以根据我们提前定义的好的方法来进行优化处理：

这是之前设定好的规则：

图片图片这些具体的提示文字案例，建议结合大家自身项目或智能体的实际需求不断尝试和优化。效果需要反复反复才能达到理想状态。

设置完毕后，点击“开始优化”即可执行下一步。

如图图片所示，res字段中就是符合要求的子功能需求列表。不过这里使用的是模拟数据进行教学教学。

图片实际上通过智能体可以识别出哪些子需求适合哪种场景设计方案。

最后一步，就是将整理后的所有分解结果经过人工校正后，传递给生成一个模块，使得来真正生成测试用例。最终生成的数量会非常多，其中难免会出现重复或者不符合实际的情况，这时候还需要AI模型再次进行筛选。

这部分工作就属于一个生成模块的任务了。

在当前阶段，我们需要先点击保存按钮，防止辛苦生成的结果丢失：

图片点击保存之后，这些数据就会被永久存储到数据库中。

图片图片从models.py中的表结构可以看出，这些拆分并优化后的具体srs信息，都被存入了DB_new_srs表中，并且通过project_id字段标识哪一组数据是属于同一个项目的。

后续我们在开发示例生成模块时，同时依赖这个project_id来获取所有相关的srs记录，逐条生成对应的测试示例。

那么现在我们来思考一个问题：生成示例都需要哪些字段？

1. 需要project_id——我们已经有了2。 这个堆之后需要进行重组优化——也有了3。 需要原始需求内容——目前还没有...

每次刷新页面你会发现原始需求不见了：

图片当然，实现原始需求的持久化存储并不难，稍后我们解决这个问题。但是这里，先来明确一下为什么我们要保留原始需求？

我们的生成逻辑是：每一条之前优化后的小需求原始需求内容，按照对应的示例设计方法来生成测试示例。

这样才能保证不会再原始需求本身，避免AI对需求产生联想或幻觉。

那我们就先着手实现原始需求的服务功能吧。

考虑到每个项目只有一个原始需求，我们可以直接将其作为一个字段添加到DB_project表中：

图片运行禁用同步脚本命令：

图片 接下来，我们要实现的展示功能：

打开前面SrsSet.vue文件，注意箭头所指部分：

图片可以看到，在进入配置需求页面时，是通过该函数触发获取下游结果的。所以我们可以在其中新增一个请求，用于获取原始需求并在页面上显示出来。具体如下：注意新增的路由中new改旧了，赋值参数也做了相应调整：

图片然后去urls.py中配置好：

图片最后在views.py中完成视图函数的编写：

图片至此，我们完成了原始需求（old_srs）的展示功能。

班级下一期期待讲：实现old_srs的保存功能以及实例生成模块的设计~

以上就是【deepseek生成平台-32】相关平台项目代码和原始需求需求仓库的详细内容，更多请关注乐哥常识网其他相关文章！