Systematic Debugging 是一套面向调试场景的方法论技能，核心目标是让调试过程以根本原因为先，而不是先尝试修复。它适用于遇到任何 bug、测试失败或异常行为时，在提出修复方案之前使用。
用途
该技能用于约束调试行为，防止随机试错式修复。它明确规定一条铁律：在没有查明根本原因之前，绝对禁止尝试修改。
主要能力
技能提供了一套四阶段调试流程。
第一阶段：调查根本原因
在尝试修改之前必须完成以下事项：
- 通读错误信息：完整阅读堆栈跟踪，记录行号与文件路径。
- 复现问题：确认是否能一致触发，明确精确步骤。
- 检查最近变更：查看 git diff、最近提交、新增依赖、配置变更。
- 追踪数据流：找出错误值从何处开始，进行逆向追踪。
- 多组件系统：在各边界添加诊断日志，运行一次，确认在哪一环节出错，然后只调查该组件。
第二阶段：模式分析
- 寻找可正常工作的示例：在同一代码库中寻找相似的可用代码。
- 与参考对比：实现某种模式时完整阅读参考文档，禁止只浏览。
- 识别差异：列出可用与不可用实现之间的所有差异。
- 梳理依赖：明确所需的其他组件、配置与环境。
第三阶段：假设验证
- 建立单一假设：“X 是根本原因，因为 Y”。
- 用最小改动测试：一次只改一处。
- 验证：若有效则进入第四阶段，否则提出新假设。
- 不知道就承认不知道，不要猜测。
第四阶段：实施
- 先编写失败测试用例。
- 实施单一修复：只解决根本原因，禁止“顺便一起”改进。
- 验证：测试是否通过，其他测试是否未被破坏。
- 若修复失败三次以上，应怀疑架构问题。
- 若每次修复都发现新问题，或需要“大规模重构”，应停止并讨论根本设计是否错误。
使用方式
该技能以规则与检查清单的形式嵌入调试流程，在遇到 bug、测试失败或异常行为时触发。它通过危险信号列表提醒立即停止并回到第一阶段，例如：“先改改看能不能行”“一次性测试多个改动”“快速修复，以后再调查”“大概就是这里的问题”“手动验证过应该没问题”“未调查就提出修复方案”“修复尝试失败两次以上”。
适用场景
适用于任何需要定位并修复缺陷的软件开发场景，尤其是多组件系统、难以复现的问题、以及容易陷入反复试错的调试过程。
限制
资料未提供该技能的具体安装方式、支持平台、收费模式或价格信息。技能内容以韩文呈现，未提供其他语言版本说明。