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