Code Problem Analyzer
使用前提
使用此 skill 时，用户必须提供以下信息：
必需信息
-
问题背景
- 预期行为：应该发生什么
- 实际现象：实际发生了什么
-
问题相关信息
- 相关日志（如果有的话）
- 执行的命令
- 崩溃栈或错误信息
- 配置信息（如果相关）
分析流程
步骤1：理解问题
- 仔细阅读问题背景，明确预期行为和实际现象的差异
- 识别关键信息：命令、日志、错误信息、配置相关项
- 确定分析重点：是执行流程问题、状态问题、还是配置问题
步骤2：代码探索
根据问题类型，使用以下策略探索代码：
执行流程问题：
- 从用户命令或入口点开始追踪
- 使用
grep搜索关键函数、参数、标志位 - 使用
read阅读关键文件，理解调用链 - 追踪关键变量的传递和修改
状态管理问题：
- 搜索状态相关的变量和函数（如
isDebugApp、isStartWithDebug） - 查找状态设置和读取的位置
- 分析状态的生命周期和清理逻辑
配置问题：
- 查找配置相关的代码（如
GetBoolParam、GetApplicationInfo） - 分析配置的来源和优先级
- 检查配置的缓存和更新机制
步骤3：构建流程图
在分析过程中，构建清晰的执行流程：
入口点 → 函数A → 函数B → 关键决策点 → 结果
对于每个关键点，记录：
- 文件路径和行号
- 函数名和关键代码片段
- 状态变化或条件判断
步骤4：识别可能的根因
根据流程分析，列出所有可能导致问题的原因：
- 代码逻辑错误：条件判断、循环、状态转换等
- 状态管理问题：状态未正确初始化、清理或同步
- 配置问题：配置来源错误、优先级混乱、缓存失效
- 时序问题：异步操作、竞态条件、回调顺序
- 边界条件：空指针、越界、未处理的异常情况
步骤5：确定最可能的根因
根据以下标准排序可能的原因：
- 证据强度：有多少代码和日志支持这个假设
- 逻辑合理性：这个原因是否能解释所有观察到的现象
- 发生概率：这类问题在实际开发中是否常见
- 影响范围：这个原因是否涉及用户提到的所有关键点
步骤6：需要用户确认时暂停
如果存在以下情况，使用 question 工具暂停并询问用户：
- 多个可能根因：无法确定唯一根因时时
- 缺少关键信息：需要更多日志或配置信息
- 需要验证假设：需要用户测试或检查特定条件
询问示例：
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:行号
**解决方案**: [具体操作步骤]
最佳实践
代码搜索策略
- 从关键参数开始：如果用户提到某个参数或标志，先搜索它
- 追踪调用链：从入口点开始，逐层深入
- 关注状态变化：查找状态变量的设置、读取、修改位置
- 查找条件判断：条件分支通常是问题的关键点
阅读代码技巧
- 先读函数签名和注释：理解函数的输入输出和目的
- 关注关键逻辑：条件判断、循环、状态转换
- 追踪数据流：变量如何传递和修改
- 理解上下文：函数在什么场景下被调用
构建流程图
- 从用户命令开始：这是最明确的入口点
- 标记关键决策点：条件判断、状态检查
- 记录状态变化：变量值如何改变
- 标注文件位置：每个步骤都标明文件和行号
验证假设
- 检查所有观察到的现象：假设是否能解释所有现象
- 寻找反例：是否有证据与假设矛盾
- 考虑边界情况：假设在特殊情况下是否成立
- 评估影响范围：假设是否涉及用户提到的所有关键点
常见问题模式
状态管理问题
- 状态未初始化就使用
- 状态更新后未同步到相关组件
- 状态清理不彻底导致残留
- 多个地方修改同一状态导致不一致
配置问题
- 配置来源不明确（命令行参数 vs 配置文件 vs 默认值）
- 配置优先级混乱
- 配置缓存未及时更新
- 配置验证缺失
时序问题
- 异步操作未正确等待
- 回调函数执行顺序不符合预期
- 事件触发时机错误
- 资源释放时机不当
参考资料
如需更详细的分析方法论，请参阅：
- ANALYSIS_METHODOLOGY.md - 深度代码分析方法
- OUTPUT_FORMAT.md - 输出格式规范和示例