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