82 lines
4.1 KiB
Markdown
82 lines
4.1 KiB
Markdown
|
## Context
|
|||
|
|
|
|||
|
|
当前系统使用 AI 服务生成分类图标，但生成的图标过于复杂，用户难以识别图标与分类名称的对应关系。问题根源在于 AI 提示词缺乏对简约风格的明确约束，导致生成的图标细节过多、视觉杂乱。影响范围涉及 Service 层的 AI 调用逻辑、Application 层的提示词配置以及前端的图标展示效果。
|
|||
|
|
|
|||
|
|
## Goals / Non-Goals
|
|||
|
|
|
|||
|
|
**Goals:**
|
|||
|
|
- 优化 AI 图标生成的提示词，确保生成简约、清晰的图标
|
|||
|
|
- 建立图标与分类名称的明确视觉关联规则
|
|||
|
|
- 提升图标生成的一致性和可识别性
|
|||
|
|
- 改善用户体验，降低识别成本
|
|||
|
|
|
|||
|
|
**Non-Goals:**
|
|||
|
|
- 不改变现有的 AI 服务提供商
|
|||
|
|
- 不重构整体的图标生成流程架构
|
|||
|
|
- 不涉及图标存储或缓存机制的变更
|
|||
|
|
- 不改变分类数据模型
|
|||
|
|
|
|||
|
|
## Decisions
|
|||
|
|
|
|||
|
|
**提示词策略选择**
|
|||
|
|
- **决策**: 采用分层提示词策略，在基础提示词中明确"简约、扁平、单色"等风格约束，在动态部分注入分类名称的语义信息
|
|||
|
|
- **替代方案**: 考虑过完全重写提示词模板，但风险较大，可能影响现有其他功能的稳定性
|
|||
|
|
- **理由**: 分层策略既能控制生成风格，又能灵活适配不同分类，改动范围小、风险低
|
|||
|
|
|
|||
|
|
**提示词模板化**
|
|||
|
|
- **决策**: 将提示词抽象为可配置的模板，支持通过配置文件调整生成风格参数
|
|||
|
|
- **替代方案**: 考虑过硬编码简化提示词，但缺乏灵活性，后续调整需要重新部署
|
|||
|
|
- **理由**: 模板化便于 A/B 测试不同提示词效果，快速迭代优化
|
|||
|
|
|
|||
|
|
**生成参数调整**
|
|||
|
|
- **决策**: 在 AI 服务调用中增加风格强度参数（如 style_strength），控制简约程度
|
|||
|
|
- **替代方案**: 完全依赖提示词控制，但部分 AI 服务支持通过参数微调生成风格
|
|||
|
|
- **理由**: 结合参数调优能更精准控制生成效果，提升成功率
|
|||
|
|
|
|||
|
|
## Risks / Trade-offs
|
|||
|
|
|
|||
|
|
**风险**: 简约提示词可能导致部分抽象分类（如"其他"、"通用"）生成的图标过于相似，难以区分
|
|||
|
|
- **缓解**: 针对抽象分类添加特殊的视觉元素（如特定的几何形状或颜色编码）
|
|||
|
|
|
|||
|
|
**风险**: 提示词优化需要多次迭代，可能影响用户体验一致性
|
|||
|
|
- **缓解**: 采用灰度发布策略，逐步验证新提示词效果，必要时支持回滚
|
|||
|
|
|
|||
|
|
**权衡**: 简约风格可能牺牲图标的细节表现力，但可识别性更重要
|
|||
|
|
- **决策**: 优先保证可识别性，后续可考虑提供可选的详细风格模式
|
|||
|
|
|
|||
|
|
**权衡**: 模板化提示词增加了配置复杂度，但提升了可维护性和灵活性
|
|||
|
|
- **决策**: 通过默认配置降低使用门槛，仅在需要调整时暴露模板参数
|
|||
|
|
|
|||
|
|
## Migration Plan
|
|||
|
|
|
|||
|
|
**第一阶段：提示词模板化**
|
|||
|
|
1. 在 Application 层创建图标提示词配置类（如 `IconPromptConfig`）
|
|||
|
|
2. 将现有提示词提取为模板，支持风格参数替换
|
|||
|
|
3. 实现模板引擎（可使用字符串插值或轻量级模板库）
|
|||
|
|
|
|||
|
|
**第二阶段：提示词优化**
|
|||
|
|
1. 设计简约风格提示词模板，明确约束：扁平化、单色、少细节、高对比度
|
|||
|
|
2. 建立分类名称到视觉元素的映射规则（如"餐饮" → 餐具形状）
|
|||
|
|
3. 集成 AI 服务调用时的风格强度参数
|
|||
|
|
|
|||
|
|
**第三阶段：测试与验证**
|
|||
|
|
1. 对现有分类批量生成新图标，对比可识别性
|
|||
|
|
2. 邀请用户进行 A/B 测试，收集反馈
|
|||
|
|
3. 根据测试结果微调提示词和参数
|
|||
|
|
|
|||
|
|
**第四阶段：灰度发布**
|
|||
|
|
1. 先在测试环境验证新图标生成效果
|
|||
|
|
2. 灰度发布到生产环境（如 10% 用户）
|
|||
|
|
3. 监控用户反馈和图标生成成功率，逐步扩大比例
|
|||
|
|
|
|||
|
|
**回滚策略**
|
|||
|
|
- 保留旧提示词模板的备份，通过配置开关快速回滚
|
|||
|
|
- 灰度期间出现异常立即回滚并分析原因
|
|||
|
|
- 记录每次提示词迭代版本，支持追溯和对比
|
|||
|
|
|
|||
|
|
## Open Questions
|
|||
|
|
|
|||
|
|
- 当前使用的 AI 服务是否支持风格强度参数？需要查阅 API 文档或进行技术验证。
|
|||
|
|
- 现有分类中是否有语义特别抽象的分类，需要特殊处理？（需要统计分类名称分析）
|
|||
|
|
- 用户对图标风格的偏好是否有特定趋势？（可以通过历史用户行为数据或调研获取）
|