6.7 KiB
6.7 KiB
type, keywords, priority
| type | keywords | priority | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| feature_update |
|
high |
功能优化/更新项目配置
本配置用于已有项目的功能优化、更新迭代、bug 修复等场景。
模板路径
templates/feature_update_template.md
核心问题配置
问题 1：当前问题识别
question: "请描述当前功能存在什么问题或不足？"
type: "text"
prompt: |
比如：
- 功能不完善，缺少某些能力
- 性能不好，速度慢
- 用户体验差，操作复杂
- 经常出错
- 维护困难
问题 2：优化目标
question: "优化后，您希望达到什么效果？"
type: "text"
prompt: |
请尽可能具体地描述，比如：
- "查询速度从 3 秒缩短到 1 秒以内"
- "增加批量导入功能"
- "优化操作流程，减少点击次数"
- "降低出错率"
问题 3：影响范围
question: "这次优化会影响哪些功能或用户？（或在'其他'中描述；需要帮助请输入'需要帮助'）"
options:
- label: "只影响这一个功能"
description: "局部优化，不影响其他功能"
- label: "会影响相关的几个功能"
description: "需要同步调整其他功能"
- label: "会影响整个系统"
description: "架构或核心功能的调整"
问题 4：兼容性要求
question: "优化后，原有的功能和数据是否需要保持兼容？（或在'其他'中描述；需要帮助请输入'需要帮助'）"
options:
- label: "必须完全兼容，不能影响现有用户"
description: "向后兼容，不需要数据迁移"
- label: "可以有小的调整，但要保证数据不丢失"
description: "需要数据迁移，但应该简单"
- label: "可以重新设计，旧数据可以手动迁移"
description: "不保证兼容，手动或复杂迁移"
问题 5：性能指标（如涉及性能优化）
question: "如果涉及性能优化，请描述当前速度和期望速度。"
type: "text"
prompt: |
比如：
- "现在加载需要 10 秒，希望 2 秒以内"
- "现在只能处理 100 条数据，希望能处理 10000 条"
- "高峰期经常卡顿，希望流畅运行"
问题 6：测试与验收
question: "如何验证优化是成功的？"
type: "text"
prompt: |
请列出具体的验收标准，比如：
- "查询 1000 条数据在 1 秒内返回"
- "批量导入 10000 条数据无报错"
- "用户操作减少到 3 步"
通用映射规则
# 问题类型 → 优化重点
issue_type_mapping:
"速度慢|性能差|加载时间长":
focus: "性能优化"
metrics: "响应时间、吞吐量"
approaches: ["缓存", "索引优化", "异步处理", "数据库优化"]
"功能不完善|缺少能力|用户需求":
focus: "功能增强"
metrics: "功能完整度、用户满意度"
approaches: ["需求分析", "功能设计", "API 扩展"]
"操作复杂|体验差|难用":
focus: "用户体验优化"
metrics: "操作步骤、用户反馈"
approaches: ["交互优化", "流程简化", "UI 改进"]
"经常出错|不稳定|bug":
focus: "稳定性提升"
metrics: "错误率、可用性"
approaches: ["异常处理", "边界检查", "测试覆盖"]
"代码混乱|难维护":
focus: "代码重构"
metrics: "代码质量、可维护性"
approaches: ["架构优化", "代码清理", "文档完善"]
# 影响范围 → 测试策略
scope_mapping:
"局部优化":
testing: "单元测试 + 功能测试"
risk: "low"
rollout: "直接发布"
"中等范围":
testing: "集成测试 + 回归测试"
risk: "medium"
rollout: "分阶段发布"
"大范围":
testing: "全面测试 + 压力测试"
risk: "high"
rollout: "灰度发布 + 回滚预案"
# 兼容性要求 → 实现策略
compatibility_mapping:
"完全兼容":
strategy: "增量优化"
migration: "不需要"
risk: "low"
"需要迁移":
strategy: "版本升级 + 迁移脚本"
migration: "自动迁移"
risk: "medium"
"不保证兼容":
strategy: "重新设计"
migration: "手动迁移或弃用旧数据"
risk: "high"
文档结构建议
# {功能名称}优化 - 需求文档
## 1. 现状分析
- 当前问题描述
- 问题影响和严重程度
- 问题根因（如已知）
## 2. 优化目标
- 功能目标
- 性能目标
- 质量目标
- 优先级
## 3. 优化方案概述
- 主要优化方向
- 技术方案（如已明确）
- 预期效果
## 4. 功能变更
- 新增功能
- 修改功能
- 废弃功能
## 5. 技术变更
- 架构调整
- 数据库变更
- API 变更
- 依赖更新
## 6. 兼容性与迁移
- 向后兼容性
- 数据迁移方案
- 回滚策略
## 7. 影响范围
- 受影响的模块
- 受影响的用户
- 风险评估
## 8. 测试策略
- 测试范围
- 测试用例
- 性能测试（如需要）
## 9. 发布计划
- 发布方式（灰度/全量）
- 发布步骤
- 监控指标
## 10. 验收标准
- 功能验收
- 性能验收
- 稳定性验收
特殊场景处理
性能优化项目
额外关注：
- 性能基线测试
- 瓶颈分析
- 优化前后对比
- 性能监控方案
架构重构项目
额外关注：
- 架构演进路径
- 服务拆分/合并
- 技术债务清理
- 团队能力评估
紧急 Bug 修复
额外关注：
- 问题复现步骤
- 临时解决方案
- 根因分析
- 防止复发措施
选项设计规范
互斥性原则
单选问题（multiSelect: false）：
- ✅ 选项应完全互斥，无重叠
- ✅ 边界清晰，用户能明确判断属于哪一个
- ❌ 避免数量范围重叠（如"1-10人"和"5-20人"）
- ❌ 避免概念包含关系
多选问题（multiSelect: true）：
- ✅ 选项可从不同角度切分，允许合理组合
- ✅ 每个选项应代表独立的需求维度
- ❌ 避免选项之间有逻辑依赖
维度统一原则
同一问题的所有选项应属于同一分类维度。
❌ 错误示例（维度混乱）：
question: "用户如何使用这个工具?"
options:
- 输入问题主动调用 # 维度：触发方式
- 命令行/编程接口 # 维度：交互界面
- Web界面 # 维度：交互界面
multiSelect: false
✅ 正确做法：拆分为两个问题，或统一到同一维度
边界清晰原则
数量范围：避免重叠，如"个人使用（1-5人）"、"小团队（6-50人）" 概念分类：确保平级，避免包含关系
完备性检查
- 2-4个选项应覆盖80%的常见场景
- 长尾场景通过"其他"覆盖
- 当不确定时，优先设计偏通用的选项+依赖"其他"