code-problem-analyzer（代码问题分析器）

Code Problem Analyzer

使用前提

使用此 skill 时，用户必须提供以下信息：

必需信息

1. 问题背景

- 预期行为：应该发生什么 - 实际现象：实际发生了什么

1. 问题相关信息

- 相关日志（如果有的话） - 执行的命令 - 崩溃栈或错误信息 - 配置信息（如果相关）

分析流程

步骤1：理解问题

1. 仔细阅读问题背景，明确预期行为和实际现象的差异
2. 识别关键信息：命令、日志、错误信息、配置相关项
3. 确定分析重点：是执行流程问题、状态问题、还是配置问题

步骤2：代码探索

根据问题类型，使用以下策略探索代码：

执行流程问题：

• 从用户命令或入口点开始追踪
• 使用 grep 搜索关键函数、参数、标志位
• 使用 read 阅读关键文件，理解调用链
• 追踪关键变量的传递和修改

状态管理问题：

• 搜索状态相关的变量和函数（如 isDebugApp、isStartWithDebug）
• 查找状态设置和读取的位置
• 分析状态的生命周期和清理逻辑

配置问题：

• 查找配置相关的代码（如 GetBoolParam、GetApplicationInfo）
• 分析配置的来源和优先级
• 检查配置的缓存和更新机制

步骤3：构建流程图

在分析过程中，构建清晰的执行流程：

入口点 → 函数A → 函数B → 关键决策点 → 结果

对于每个关键点，记录：

• 文件路径和行号
• 函数名和关键代码片段
• 状态变化或条件判断

步骤4：识别可能的根因

根据流程分析，列出所有可能导致问题的原因：

1. 代码逻辑错误：条件判断、循环、状态转换等
2. 状态管理问题：状态未正确初始化、清理或同步
3. 配置问题：配置来源错误、优先级混乱、缓存失效
4. 时序问题：异步操作、竞态条件、回调顺序
5. 边界条件：空指针、越界、未处理的异常情况

步骤5：确定最可能的根因

根据以下标准排序可能的原因：

1. 证据强度：有多少代码和日志支持这个假设
2. 逻辑合理性：这个原因是否能解释所有观察到的现象
3. 发生概率：这类问题在实际开发中是否常见
4. 影响范围：这个原因是否涉及用户提到的所有关键点

步骤6：需要用户确认时暂停

如果存在以下情况，使用 question 工具暂停并询问用户：

1. 多个可能根因：无法确定唯一根因时时
2. 缺少关键信息：需要更多日志或配置信息
3. 需要验证假设：需要用户测试或检查特定条件

询问示例：

question:
  questions:
    - question: "我发现了两个可能的原因：[原因1] 和 [原因2]。为了进一步确认，请提供："
      header: "需要更多信息"
      options:
        - label: "检查配置文件"
          description: "查看应用配置文件中的 debug 字段值"
        - label: "查看完整日志"
          description: "提供应用启动的完整日志"
        - label: "检查等待调试列表"
          description: "运行 aa appdebug get 命令查看等待调试状态"

输出格式

标准输出

## 问题分析结果

### 所有可能的流程

1. **流程1**: [流程描述]
   - 文件:file.cpp:行号 - [关键代码片段]
   - 文件:file.cpp:行号 - [关键代码片段]
   - ...

2. **流程2**: [流程描述]
   - 文件:file.cpp:行号 - [关键代码片段]
   - ...

### 最有可能的根因

**根因**: [明确的根因描述]

**原因解释**:
- [解释1]
- [解释2]
- [关键代码位置]: file.cpp:行号

**建议的解决方案**:
1. [解决方案1]
2. [解决方案2]

### 需要进一步确认

[如果需要，说明需要用户做什么]

简洁输出（如果如果问题明确）

## 问题分析结果

### 最有可能的根因

**根因**: [明确的根因描述]

**原因**: [简短解释]

**关键代码位置**: file.cpp:行号

**解决方案**: [具体操作步骤]

最佳实践

代码搜索策略

1. 从关键参数开始：如果用户提到某个参数或标志，先搜索它
2. 追踪调用链：从入口点开始，逐层深入
3. 关注状态变化：查找状态变量的设置、读取、修改位置
4. 查找条件判断：条件分支通常是问题的关键点

阅读代码技巧

1. 先读函数签名和注释：理解函数的输入输出和目的
2. 关注关键逻辑：条件判断、循环、状态转换
3. 追踪数据流：变量如何传递和修改
4. 理解上下文：函数在什么场景下被调用

构建流程图

1. 从用户命令开始：这是最明确的入口点
2. 标记关键决策点：条件判断、状态检查
3. 记录状态变化：变量值如何改变
4. 标注文件位置：每个步骤都标明文件和行号

验证假设

1. 检查所有观察到的现象：假设是否能解释所有现象
2. 寻找反例：是否有证据与假设矛盾
3. 考虑边界情况：假设在特殊情况下是否成立
4. 评估影响范围：假设是否涉及用户提到的所有关键点

常见问题模式

状态管理问题

• 状态未初始化就使用
• 状态更新后未同步到相关组件
• 状态清理不彻底导致残留
• 多个地方修改同一状态导致不一致

配置问题

• 配置来源不明确（命令行参数 vs 配置文件 vs 默认值）
• 配置优先级混乱
• 配置缓存未及时更新
• 配置验证缺失

时序问题

• 异步操作未正确等待
• 回调函数执行顺序不符合预期
• 事件触发时机错误
• 资源释放时机不当

参考资料

如需更详细的分析方法论，请参阅：

• ANALYSIS_METHODOLOGY.md - 深度代码分析方法
• OUTPUT_FORMAT.md - 输出格式规范和示例