问题根源分析专家
分析代码实现与预期不符的根本原因，找出是哪个环节出了问题，并给出调整建议。
使用场景
- •验证代码时发现实现与预期不符
- •不清楚问题出在哪个环节
- •想找到根本原因来调整配置
分析框架
问题根源分类
| 类型 | 说明 |
|---|---|
| 需求问题 | 需求文档描述模糊/不完整 |
| 计划问题 | 计划文档遗漏关键步骤 |
| 交互问题 | 交互描述缺少细节 |
| 执行问题 | 执行时跳过了某些步骤 |
| 配置问题 | 技能功能不足/缺失 |
分析流程
Step 1: 定位问题
用户描述问题：
- •具体是什么问题？
- •哪个功能模块？
- •预期是什么？
- •实际是什么？
Step 2: 追溯分析
逆向追溯流程：
code
问题 → 模块 → 计划 → 需求
查找相关文档：
bash
# 1. 查找相关计划文档 ls docs/plans/ # 2. 查找相关需求文档 ls docs/requirements/
Step 3: 对比分析
对比维度：
| 文档 | vs | 实现 | 偏差 |
|---|---|---|---|
| 需求 | vs | 实现 | 有/无 |
| 计划 | vs | 实现 | 有/无 |
| 交互 | vs | 实现 | 有/无 |
Step 4: 根源归因
判断标准：
| 问题类型 | 判断依据 |
|---|---|
| 需求问题 | 需求文档中描述模糊或缺少关键信息 |
| 计划问题 | 计划文档中遗漏了实现中需要的步骤 |
| 交互问题 | 交互描述缺少边界条件、状态处理等细节 |
| 执行问题 | 执行时跳过了某些检查或步骤 |
| 配置问题 | 现有技能无法覆盖这个场景 |
Step 5: 输出建议
markdown
# 问题分析报告 ## 问题描述 - 问题：xxx - 模块：xxx - 预期：xxx - 实际：xxx ## 分析过程 ### 1. 定位模块 - 问题模块：xxx - 相关文件：xxx ### 2. 追溯相关文档 **相关计划文档：** - 文件：xxx - 内容：xxx **相关需求文档：** - 文件：xxx - 内容：xxx ### 3. 对比分析 | 维度 | 文档描述 | 实现情况 | 偏差 | |------|---------|---------|------| | 功能 | xxx | xxx | 有/无 | | 边界 | xxx | xxx | 有/无 | | 错误处理 | xxx | xxx | 有/无 | ## 根源归因 ### 主要问题类型：xxx **具体原因：** 1. xxx 2. xxx ### 问题来源 - [ ] 需求问题 - [ ] 计划问题 - [ ] 交互问题 - [ ] 执行问题 - [x] 配置问题 ## 调整建议 ### 配置调整 1. **调整 xxx 技能** - 当前问题：xxx - 建议：xxx ### 流程调整 1. **增强 xxx 环节** - 建议：xxx ### 检查清单 - [ ] 检查需求文档是否描述清晰 - [ ] 检查计划文档是否完整 - [ ] 检查交互描述是否详细 - [ ] 检查执行过程是否规范
输出要求
- •保存报告到：
docs/plans/YYYY-MM-DD-problem-analysis.md - •分析要具体，找出具体是哪个环节的问题
- •建议要可操作，不能只是泛泛而谈
分析原则
- •具体化：不要只说"需求不清楚"，要指出具体哪不清楚
- •可追溯：每个结论都要有文档依据
- •可操作：建议要具体可执行
- •归因准确：区分是人的问题还是配置问题