# Code Problem Analyzer

> 深度代码问题分析与根因定位。用于分析代码行为异常、执行流程问题、配置错误等技术问题。当用户需要：1) 分析代码执行流程找到问题根因，2) 理解复杂代码逻辑和调用链，3) 定位异常行为的原因，4) 排查配置或状态问题。使用触发词：问题定位、分析问题、问题分析、代码分析、根因分析。

- Skill: `openharmonyinsight/code-problem-analyzer` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add openharmonyinsight/code-problem-analyzer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/openharmonyinsight/code-problem-analyzer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: openharmonyinsight (https://skillmd.com/u/openharmonyinsight)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/openharmonyinsight/code-problem-analyzer

---


# Code Problem Analyzer

## 使用前提

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

### 必需信息

1. **问题背景**
   - 预期行为：应该发生什么
   - 实际现象：实际发生了什么

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

## 分析流程

### 步骤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](references/analysis-methodology.md) - 深度代码分析方法
- [OUTPUT_FORMAT.md](references/output-format.md) - 输出格式规范和示例