Files
AIEC_Skills/.claude/skills/requirement-generator-v1/assets/feature_update.md

292 lines
6.7 KiB
Markdown
Raw Normal View History

---
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%的常见场景**
- 长尾场景通过"其他"覆盖
- 当不确定时,优先设计偏通用的选项+依赖"其他"