Docker7530
65 lines
6.1 KiB
Markdown
65 lines
6.1 KiB
Markdown
# 任务
|
||
|
||
- [x] 开发：IBS 7.15.0 版本需求梳理。（跨客户订购迁移流程自动化（涉及子系统与CPID字段解耦）页面接口，已完成页面校验逻辑重构，待优化返回域名详情。）
|
||
|
||
# 日志
|
||
|
||
我现在拥有了很完整的提示词管理，提示词存储，和功能对提示词映射关系。FunctionPromptMapping、PromptTemplate。我现在需要你帮我重构我的提示词使用模块。将原来读 resources 的相关逻辑，都改为通过功能查询提示词。因为后期可能并发访问 AI，所以做好对提示提的缓存，但是逻辑要设计的合理，不冗余。优雅易懂健壮。加油。是个艰巨的任务。历史提取提示词的一些逻辑在 PromptService。如果这个不适合新的查库框架可以直接干掉，这个看你怎么设计。
|
||
|
||
很好，我现在要做样式设计上的一些调整，大方向是做减法。主要是后台管理中心，首先就是进入之后这些模块就一个图标加一个功能标题就行了。没必要解释太多。比如 AI 模型厂商管理，就是一个图标右边带着一个标题 AI模型厂商管理。这个页面的几个模块一样。不要下边的描述信息和进入管理。直观一些。因为这样打打的减少了内容，帮我设计一个不错的排列方式。比较优雅，看着舒适，但是不复杂的。
|
||
|
||
只有一个冲突域名：下发时真实域名转为冲突域名下发，查询查到冲突域名。（但是此时域名没有了，无法知道是否时冲突域名。）
|
||
|
||
只有一个冲突域名：下发时真实域名转为冲突域名下发，查询查到冲突域名。（但是此时域名删了又引进已经不是一个配置，无法知道是否时冲突域名。）
|
||
|
||
一真、一冲突：客户都会以 domain 字段下发，但是返回都无法有唯一的依据。
|
||
|
||
一真、两冲突：客户都会以 domain 字段下发，但是返回都无法有惟一的依据。
|
||
|
||
我们时一个域名管理系统，一条域名的两个属性 domain cp_domain。这里其实我们之前只有 domain 字段。但是后来有了冲突域名的概念。引申出了 cp_domain，当普通域名时只有 domain 字段（baidu.com），当有一个冲突域名的时候 domain 字段（baidu.com.houzhui.com）cp_domain（baidu.com）
|
||
|
||
我们对运营经理都是显示 domain 字段，以及下发任务时运营经理用 domain就可以了。
|
||
|
||
但是对于企业客户就有场景了。如果一个企业下有冲突域名（baidu.com.houzhui.com - baidu.com）又有真实域名（baidu.com），或者两个冲突域名对应一个真实域名（baidu1.com.houzhui.com - baidu.com、baidu2.com.houzhui.com - baidu.com）这时候客户看到的时 domain 字段。如果客户只有一个冲突域名（baidu.com.houzhui.com - baidu.com）客户看到的是 baidu.com。此时客户下发任务就用他看到的域名。
|
||
|
||
但是我们收到运营经理或者客户的任务后，需要转化为 domain 字段下发。我们从下游查询，下游给我们就是我们下发的时候的字段。但是我们企业客户转不转是根据企业存在的域名的情况来转的。如果客户删除了域名，或者二次引入了。这时候查询任务的时候是不是就会出错，不准确。请帮我列出来会造成转换的错误的场景。以及是否有什么合理的方案进行处理这个事情。
|
||
|
||
```
|
||
refactor(prompts): 重构提示词管理系统并统一后台管理页面样式
|
||
|
||
- 将提示词从文件系统迁移到数据库管理
|
||
- 新增 PromptTemplate 和 FunctionPromptMapping 完整 CRUD
|
||
- 删除旧的 PromptConstants 和静态 prompt 文件
|
||
- 更新 CosmicService 和 VacationService 适配新的提示词服务
|
||
- 新增提示词模板管理页面（支持 Markdown 编辑和预览）
|
||
- 新增功能-提示词映射管理页面
|
||
- 统一后台管理中心、AI厂商管理、功能映射管理页面样式
|
||
- 简化页面设计，移除冗余描述和装饰元素，提升视觉一致性
|
||
- 新增 prompt_template 和 function_prompt_mapping 表
|
||
|
||
```
|
||
|
||
我现在 build 感觉这两个很大，帮我解决这个不好的问题，按理说不会这么大：
|
||
|
||
dist/assets/css/index-HSCbE80M.css 341.17 kB
|
||
|
||
dist/assets/js/element-plus-5d8TLeyV.js 1,005.07 kB
|
||
|
||
com.cmcc.cdn.platform.selfservice.service.impl.ContentManageServiceImpl#getValidDomainAndSubdomainList 帮我优化这个方法，要求清理掉现有的查询缓存的逻辑。为我后边优化做铺垫。注意只是清理缓存相关的逻辑，清理后其他逻辑保持原意。
|
||
|
||
很好，现在要进行下一步了，对这个方法进行全流程性能优化，和代码接口优化工作，要求必须必须保持原意，和原来的逻辑。重点优化所有查询。不要用全字段返回或`List<Object> getValidSubdomain(String tenantId);`这种，统一使用 Springdata jpa 投影 (基于接口)的方式。原则是用什么查什么。让整体代码结构优雅。记住必须保持原意的条件下优化性能和语法。
|
||
|
||
作为产品分析师、mermaidchart 时序图设计大师，精通 mermaid 语法。请根据我提供的内容给我生成一个 mermaid 语法时序图，尽量用标准语法。最多 4 层交互。有相近语义的可以精简到一个流程中。
|
||
|
||
子账号：泛域名查询逻辑未加状态。
|
||
|
||
运营经理账号：domain_approve_relation没加状态过滤、cache 没加状态过滤、泛域名过滤状态4且查找泛域名依赖extensive_domain。
|
||
|
||
企业账号：泛域名没加状态过滤。
|
||
|
||
我发现现在后台管理重四个功能：AI 模型厂商管理、功能-模型映射管理、提示词模板管理、功能-提示词映射管理。其实AI 模型厂商管理和提示词模板管理就是为了功能服务的。其实功能-模型映射管理和功能-提示词映射管理可以以功能的维度放到一个页面管理。为每个功能配置模型和提示词。请帮我进行合并。这样可以少一个前端页面。也更方便操作。注意保证功能的可用性。修改完后如果有遗留的没用的前后端逻辑可以顺手清理下，保持代码干净。
|
||
|
||
# 总结
|
||
|
||
推进了需求开发，这次一定要稳重一些。
|