<execution domain="product-management">
  
  # Feature设计核心理念
  
  ## 🤔 Feature = 功能域问题发现
  
  ```markdown
  Feature的本质：发现用户在特定功能域遇到的问题
  核心思考：用户在这个功能域被什么困难阻碍了？
  
  问题导向框架：
  📋 提问题层: Epic → Feature → Story (需求定义)
  🛠️ 解决问题层: Task (技术实现)
  ✅ 验证层: TestCase (质量保证)  
  🎯 价值确认层: Milestone (交付确认)
  ```
  
  **Feature的职责边界**：
  - ✅ 发现用户在功能域的具体痛点和障碍
  - ✅ 识别功能缺失导致的用户任务中断
  - ✅ 定义用户在特定场景下的困难体验
  - ❌ 不设计具体功能模块实现方案
  - ❌ 不定义技术架构和接口细节
  - ❌ 不描述"用户需要什么能力"
  
  ## ⚠️ 常见陷阱与避免方法
  
  ```markdown
  陷阱1: 写成功能设计书
  错误表述: "用户角色管理功能模块，包含角色选择、配置生成、状态展示"
  正确表述: "用户无法快速识别和切换可用的AI角色，配置过程繁琐易错"
  
  陷阱2: 定义解决方案而非问题
  错误表述: "提供命令行工具让用户一键生成角色配置文件"
  正确表述: "当前角色配置需要手动操作多个步骤，新用户配置失败率高"
  
  陷阱3: 关注能力需求而非缺失痛点
  错误表述: "用户需要可视化的记忆状态监控能力"
  正确表述: "用户对记忆系统运行状态缺乏感知，无法确认功能是否正常"
  
  陷阱4: 混合问题与功能清单
  错误表述: "角色初始化复杂，需要包含别名解析、文件生成、状态反馈功能"
  正确表述: "角色初始化过程用户不知道进度，经常不确定是否成功完成"
  ```
  
  **问题导向自检清单**：
  - [ ] Feature描述中是否包含"功能"、"模块"、"提供"等解决方案词汇？
  - [ ] 是否先描述用户遇到的困难，再描述期望改善？
  - [ ] 能否用"什么问题阻碍了用户"而非"用户需要什么"来概括Feature？
  - [ ] 开发团队看到Feature能理解要解决的痛点，而非要开发的功能？

  <process>
    # Feature设计流程
    
    ```mermaid
    flowchart TD
      A[Epic问题域分解] --> B[识别功能场景痛点]
      B --> C[定义问题边界]
      C --> D[分析用户困难]
      D --> E[制定问题解决标准]
      E --> F[Story问题拆解规划]
      F --> G{问题完整性验证}
      G -->|完整| H[Feature就绪]
      G -->|不完整| I[补充问题分析]
      I --> B
      
      B1[用户旅程断点分析] --> B
      B2[任务执行障碍识别] --> B
      B3[体验缺失评估] --> B
    ```
    
    ## Feature问题识别方法
    
    ```mermaid
    mindmap
      root((问题识别))
        用户体验断点
          任务中断节点
          操作困难环节
          反馈缺失场景
        功能缺失分析
          必要能力缺失
          信息获取障碍
          操作效率低下
        技术约束导致的用户问题
          性能瓶颈影响
          兼容性问题
          稳定性缺陷
    ```
    
    ## 📊 问题影响量化模板
    
    ```markdown
    ### 用户痛点量化
    - 具体困难: [用户遇到的具体问题，如"配置角色需要10个步骤"]
    - 影响范围: [受影响用户比例，如"80%的新用户"]
    - 困难成本: [时间/错误损失，如"平均失败3次才成功"]
    - 当前缺失: [什么能力的缺失导致了这个问题]
    
    ### 功能缺失分析
    - 缺失能力: [具体缺少什么功能支持]
    - 导致后果: [缺失导致的用户困难]
    - 替代方案: [用户当前如何绕过这个问题]
    - 绕过成本: [替代方案的额外成本]
    
    ### 改善期望
    - 期望体验: [解决问题后用户应该有什么体验]
    - 成功指标: [如何衡量问题得到解决]
    - 优先级: [相对其他问题的重要程度]
    ```
  </process>
  
  <guideline>
    ### Feature问题定义建议
    
    - **问题完整性**: Feature应代表完整的问题域，用户困难有明确边界
    - **技术边界对应**: 问题域对应技术模块边界，便于解决方案设计
    - **用户可感知**: 问题是用户直接体验到的困难和障碍
    - **中等粒度**: 1-3个迭代解决，包含3-8个具体问题点(Story)
    
    ### 问题复杂度分级
    
    | 问题类型 | 复杂度 | 解决时间 | Story数量 | 影响范围 |
    |---------|-------|---------|-----------|---------|
    | 简单问题域 | 低 | 1迭代 | 2-4个Story | 单一场景 |
    | 标准问题域 | 中 | 1-2迭代 | 4-6个Story | 多个相关场景 |
    | 复杂问题域 | 高 | 2-3迭代 | 6-8个Story | 跨场景影响 |
    
    ### 问题边界定义
    
    - **包含痛点**: 列出具体的用户困难和障碍点
    - **不包含问题**: 防止范围扩散，明确排除的问题
    - **问题依赖**: 此问题与其他问题的关联和依赖
    - **影响接口**: 解决此问题对其他功能域的影响
    
    ### Story问题拆解策略
    
    ```mermaid
    flowchart LR
      A[Feature问题域] --> B[核心困难Story]
      A --> C[操作障碍Story]  
      A --> D[信息缺失Story]
      A --> E[反馈不足Story]
      
      B --> B1[主要痛点]
      C --> C1[操作困难]
      D --> D1[信息获取问题]
      E --> E1[状态不明确]
    ```
  </guideline>
  
  <rule>
    1. **四个核心原则必须遵循**
       - 问题完整性: Feature代表完整问题域
       - 用户视角: 从用户困难角度定义问题
       - 可观察性: 问题是用户直接感受到的
       - 边界清晰: 问题域边界明确不重叠
    
    2. **强制包含要素**
       - 用户痛点必须具体可观察
       - 问题边界必须明确定义（包含/不包含痛点）
       - 解决标准必须具体可验证
       - Story问题拆解必须覆盖核心困难
       - 问题依赖必须识别和记录
    
    3. **三层问题关系规则**
       - Epic → Feature: 价值问题到功能域问题的分解
       - Feature → Story: 功能域问题到具体用户困难的拆解
       - 层级间问题粒度跨度合理，避免过度拆分或粗糙
    
    4. **拆分触发条件**
       - 问题域跨越3个以上技术模块需要拆分
       - 包含不相关困难点需要重新组织
       - 解决时间超过3个迭代需要拆分
  </rule>
  
  <constraint>
    1. **技术架构约束**
       - 问题域边界受现有架构模块限制
       - 微服务边界影响问题解决方案
       - 数据模型设计影响问题解决范围
    
    2. **团队能力约束**
       - 并行解决问题数量有限
       - 团队技能影响问题解决复杂度
       - 跨团队问题需要额外协调成本
    
    3. **用户体验约束**
       - 用户旅程完整性不可打断
       - 渐进式改善对问题解决颗粒度的要求
       - 问题优先级受用户影响程度限制
    
    4. **项目约束**
       - 迭代时间盒限制问题解决范围
       - 测试资源影响问题验证
       - 发布节奏影响问题解决优先级
  </constraint>
  
  <criteria>
    | 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
    |---------|---------|---------|-----------|
    | 问题清晰度 | 用户痛点具体可观察，困难描述准确 | 问题基本清晰可理解 | 问题模糊或偏向解决方案 |
    | 边界合理性 | 问题域边界清晰，困难点内聚相关 | 边界基本清晰 | 边界模糊或问题分散 |
    | 用户视角 | 完全从用户困难角度描述问题 | 基本体现用户视角 | 偏向系统或技术视角 |
    | 影响量化 | 问题影响范围和程度量化清晰 | 影响基本明确 | 影响不明确或无量化 |
    | 可解决性 | 问题有明确解决标准和验证方式 | 基本可解决验证 | 问题过于抽象或无法验证 |
    | Story拆解质量 | 问题拆解全面，困难点粒度一致 | 拆解基本合理 | 拆解不完整或粒度不一致 |
    | 问题导向性 | 避免解决方案描述，纯问题导向 | 基本问题导向 | 混合解决方案或功能描述 |
    
    **快速检查要点**：
    📝 **问题导向**: 描述用户困难而非功能需求，避免"需要"、"提供"、"实现"等词汇
    🎯 **用户视角**: 从用户遇到的具体障碍和痛点角度定义问题
    📊 **困难量化**: 用户痛点影响范围和程度必须量化，有明确解决标准
    🔍 **边界清晰**: 问题域边界明确，困难点内聚，可独立解决和验证
  </criteria>
</execution>