code-problem-analyzer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Code Problem Analyzer

Code Problem Analyzer

使用前提

Prerequisites

使用此 skill 时,用户必须提供以下信息:
When using this skill, users must provide the following information:

必需信息

Required Information

  1. 问题背景
    • 预期行为:应该发生什么
    • 实际现象:实际发生了什么
  2. 问题相关信息
    • 相关日志(如果有的话)
    • 执行的命令
    • 崩溃栈或错误信息
    • 配置信息(如果相关)
  1. Problem Context
    • Expected behavior: What should happen
    • Actual behavior: What actually happened
  2. Problem-Related Information
    • Relevant logs, if available
    • Executed commands
    • Crash stack or error message
    • Configuration information, if relevant

分析流程

Analysis Workflow

步骤1:理解问题

Step 1: Understand the Problem

  1. 仔细阅读问题背景,明确预期行为和实际现象的差异
  2. 识别关键信息:命令、日志、错误信息、配置相关项
  3. 确定分析重点:是执行流程问题、状态问题、还是配置问题
  1. Carefully read the problem context and identify the difference between the expected and actual behavior
  2. Identify key information: commands, logs, error messages, and configuration-related items
  3. Determine the analysis focus: execution flow, state, or configuration

步骤2:代码探索

Step 2: Code Exploration

根据问题类型,使用以下策略探索代码:
执行流程问题:
  • 从用户命令或入口点开始追踪
  • 使用
    grep
    搜索关键函数、参数、标志位
  • 使用
    read
    阅读关键文件,理解调用链
  • 追踪关键变量的传递和修改
状态管理问题:
  • 搜索状态相关的变量和函数(如
    isDebugApp
    、
    isStartWithDebug
    )
  • 查找状态设置和读取的位置
  • 分析状态的生命周期和清理逻辑
配置问题:
  • 查找配置相关的代码(如
    GetBoolParam
    、
    GetApplicationInfo
    )
  • 分析配置的来源和优先级
  • 检查配置的缓存和更新机制
Depending on the type of problem, use the following strategies to explore the code:
Execution-flow issues:
  • Start tracing from the user command or entry point
  • Use
    grep
    to search for key functions, parameters, and flags
  • Use
    read
    to examine key files and understand the call chain
  • Track the passing and modification of key variables
State management issues:
  • Search for state-related variables and functions, such as
    isDebugApp
    and
    isStartWithDebug
  • Find the locations where state is set and read
  • Analyze the state lifecycle and cleanup logic
Configuration issues:
  • Find configuration-related code, such as
    GetBoolParam
    and
    GetApplicationInfo
  • Analyze the sources and precedence of configuration values
  • Check the configuration caching and update mechanisms

步骤3:构建流程图

Step 3: Build a Flowchart

在分析过程中,构建清晰的执行流程:
入口点 → 函数A → 函数B → 关键决策点 → 结果
对于每个关键点,记录:
  • 文件路径和行号
  • 函数名和关键代码片段
  • 状态变化或条件判断
During the analysis, construct a clear execution flow:
Entry Point → Function A → Function B → Key Decision Point → Result
For each key point, record:
  • File path and line number
  • Function name and key code snippet
  • State changes or conditional checks

步骤4:识别可能的根因

Step 4: Identify Possible Root Causes

根据流程分析,列出所有可能导致问题的原因:
  1. 代码逻辑错误:条件判断、循环、状态转换等
  2. 状态管理问题:状态未正确初始化、清理或同步
  3. 配置问题:配置来源错误、优先级混乱、缓存失效
  4. 时序问题:异步操作、竞态条件、回调顺序
  5. 边界条件:空指针、越界、未处理的异常情况
Based on the flow analysis, list all causes that could potentially lead to the issue:
  1. Code logic errors: Conditional checks, loops, state transitions, and similar issues
  2. State management issues: State not being properly initialized, cleaned up, or synchronized
  3. Configuration issues: Incorrect configuration sources, unclear precedence, or invalid cache behavior
  4. Timing issues: Asynchronous operations, race conditions, or callback ordering
  5. Boundary conditions: Null pointers, out-of-bounds access, or unhandled exceptional cases

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

Step 5: Determine the Most Likely Root Cause

根据以下标准排序可能的原因:
  1. 证据强度:有多少代码和日志支持这个假设
  2. 逻辑合理性:这个原因是否能解释所有观察到的现象
  3. 发生概率:这类问题在实际开发中是否常见
  4. 影响范围:这个原因是否涉及用户提到的所有关键点
Rank the possible causes according to the following criteria:
  1. Strength of evidence: How much code and log evidence supports the hypothesis
  2. Logical plausibility: Whether the cause can explain all observed behavior
  3. Likelihood: Whether this type of problem commonly occurs in real-world development
  4. Impact scope: Whether the cause covers all the key points mentioned by the user

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

Step 6: Pause When User Confirmation Is Needed

如果存在以下情况,使用
question
工具暂停并询问用户:
  1. 多个可能根因:无法确定唯一根因时时
  2. 缺少关键信息:需要更多日志或配置信息
  3. 需要验证假设:需要用户测试或检查特定条件
询问示例:
question:
  questions:
    - question: "我发现了两个可能的原因:[原因1] 和 [原因2]。为了进一步确认,请提供:"
      header: "需要更多信息"
      options:
        - label: "检查配置文件"
          description: "查看应用配置文件中的 debug 字段值"
        - label: "查看完整日志"
          description: "提供应用启动的完整日志"
        - label: "检查等待调试列表"
          description: "运行 aa appdebug get 命令查看等待调试状态"
If any of the following applies, use the
question
tool to pause and ask the user:
  1. Multiple possible root causes: A unique root cause cannot be determined
  2. Missing key information: More logs or configuration information are required
  3. Hypothesis validation: The user needs to test or inspect specific conditions
Example:
question:
  questions:
    - question: "I found two possible causes: [Cause 1] and [Cause 2]. To confirm further, please provide:"
      header: "More information needed"
      options:
        - label: "Check the configuration file"
          description: "Check the debug field value in the application configuration file"
        - label: "View the full logs"
          description: "Provide the full application startup logs"
        - label: "Check the pending debug list"
          description: "Run the aa appdebug get command to view the pending debug status"

输出格式

Output Format

标准输出

Standard Output

undefined
undefined

问题分析结果

Problem Analysis Results

所有可能的流程

All Possible Flows

  1. 流程1: [流程描述]
    • 文件:file.cpp:行号 - [关键代码片段]
    • 文件:file.cpp:行号 - [关键代码片段]
    • ...
  2. 流程2: [流程描述]
    • 文件:file.cpp:行号 - [关键代码片段]
    • ...
  1. Flow 1: [Flow description]
    • File:file.cpp:line number - [Key code snippet]
    • File:file.cpp:line number - [Key code snippet]
    • ...
  2. Flow 2: [Flow description]
    • File:file.cpp:line number - [Key code snippet]
    • ...

最有可能的根因

Most Likely Root Cause

根因: [明确的根因描述]
原因解释:
  • [解释1]
  • [解释2]
建议的解决方案:
  1. [解决方案1]
  2. [解决方案2]
Root Cause: [Clear root-cause description]
Explanation:
  • [Explanation 1]
  • [Explanation 2]
  • [Key code location]: file.cpp:line number
Suggested Solution:
  1. [Solution 1]
  2. [Solution 2]

需要进一步确认

Further Confirmation Required

[如果需要,说明需要用户做什么]
undefined
[If needed, explain what the user needs to do]
undefined

简洁输出(如果如果问题明确)

Concise Output (if the issue is clear)

undefined
undefined

问题分析结果

Problem Analysis Results

最有可能的根因

Most Likely Root Cause

根因: [明确的根因描述]
原因: [简短解释]
关键代码位置: file.cpp:行号
解决方案: [具体操作步骤]
undefined
Root Cause: [Clear root-cause description]
Reason: [Brief explanation]
Key Code Location: file.cpp:line number
Solution: [Specific action steps]
undefined

最佳实践

Best Practices

代码搜索策略

Code Search Strategies

  1. 从关键参数开始:如果用户提到某个参数或标志,先搜索它
  2. 追踪调用链:从入口点开始,逐层深入
  3. 关注状态变化:查找状态变量的设置、读取、修改位置
  4. 查找条件判断:条件分支通常是问题的关键点
  1. Start with key parameters: If the user mentions a parameter or flag, search for it first
  2. Trace the call chain: Start from the entry point and work through each layer
  3. Pay attention to state changes: Find the locations where state variables are set, read, and modified
  4. Look for conditional checks: Conditional branches are often the key to the problem

阅读代码技巧

Code Reading Techniques

  1. 先读函数签名和注释:理解函数的输入输出和目的
  2. 关注关键逻辑:条件判断、循环、状态转换
  3. 追踪数据流:变量如何传递和修改
  4. 理解上下文:函数在什么场景下被调用
  1. Read function signatures and comments first: Understand the inputs, outputs, and purpose of each function
  2. Focus on key logic: Conditional checks, loops, and state transitions
  3. Trace the data flow: Follow how variables are passed and modified
  4. Understand the context: Determine the circumstances under which a function is called

构建流程图

Building a Flowchart

  1. 从用户命令开始:这是最明确的入口点
  2. 标记关键决策点:条件判断、状态检查
  3. 记录状态变化:变量值如何改变
  4. 标注文件位置:每个步骤都标明文件和行号
  1. Start from the user command: This is the clearest entry point
  2. Mark key decision points: Conditional checks and state inspections
  3. Record state changes: How variable values change
  4. Annotate file locations: Include the file and line number for every step

验证假设

Validating Hypotheses

  1. 检查所有观察到的现象:假设是否能解释所有现象
  2. 寻找反例:是否有证据与假设矛盾
  3. 考虑边界情况:假设在特殊情况下是否成立
  4. 评估影响范围:假设是否涉及用户提到的所有关键点
  1. Check all observed behavior: Determine whether the hypothesis explains all observations
  2. Look for counterexamples: Check for evidence that contradicts the hypothesis
  3. Consider boundary cases: Determine whether the hypothesis holds under special conditions
  4. Evaluate impact scope: Check whether the hypothesis covers all key points mentioned by the user

常见问题模式

Common Problem Patterns

状态管理问题

State Management Issues

  • 状态未初始化就使用
  • 状态更新后未同步到相关组件
  • 状态清理不彻底导致残留
  • 多个地方修改同一状态导致不一致
  • State is used before being initialized
  • State changes are not synchronized with related components
  • State is not thoroughly cleaned up, leaving residual data
  • Multiple locations modify the same state, resulting in inconsistency

配置问题

Configuration Issues

  • 配置来源不明确(命令行参数 vs 配置文件 vs 默认值)
  • 配置优先级混乱
  • 配置缓存未及时更新
  • 配置验证缺失
  • The configuration source is unclear, such as command-line arguments versus configuration files or default values
  • Configuration precedence is confused
  • Configuration caches are not updated in a timely manner
  • Configuration validation is missing

时序问题

Timing Issues

  • 异步操作未正确等待
  • 回调函数执行顺序不符合预期
  • 事件触发时机错误
  • 资源释放时机不当
  • Asynchronous operations are not awaited correctly
  • Callback execution order does not match expectations
  • Events are triggered at an incorrect time
  • Resources are released at an inappropriate time

参考资料

References

如需更详细的分析方法论,请参阅:
  • ANALYSIS_METHODOLOGY.md - 深度代码分析方法
  • OUTPUT_FORMAT.md - 输出格式规范和示例
For a more detailed analysis methodology, see:
  • ANALYSIS_METHODOLOGY.md - In-depth code analysis methodology
  • OUTPUT_FORMAT.md - Output format specifications and examples