用途：定位代码、配置、数据流或环境中的缺陷，找出故障背后的机制；用户要求修复时给出修复，并证明修复消除了用户报告的症状。最终结果有两种：一是经检查确认的根因（症状出现、仅改变该原因后症状消失），二是证据受限的诊断（给出最可能原因、置信度及可定论所需证据）。
适用与分流：本技能处理机械性缺陷，如工具结果被截断、解析器丢字段、超时、重试发送过期状态。若问题是“输出是否足够好”属评估设计；若是跨随机样本、模型、提示或数据的比率或比较属 ML 实验；若质疑结果或基准数值是否可信属评估审计；评估活动中的运行失败或停滞属评估运维。
主要做法：先固定用户报告的症状（确切错误、错误值、时间、行为、输入与环境、期望结果、起始时间与相关变更），并作为后续所有步骤的目标。展示命令、日志或请求前先脱敏，凭据放环境变量。尽可能建立反馈回路：一条驱动失败路径并报告症状是否出现的命令，要求针对症状、可重复、足够快、可由智能体独立运行。回路失败后逐步删减输入、步骤、配置和调用方，缩小复现范围，同时保留原始场景用于最终验证。
无回路时：说明尝试过什么、为何无回路，再从日志、追踪、记录、指标、保存的输入、版本与配置差异，尤其是失败与成功案例的对比中推理；最早出现分歧处通常最有信息量。可请求低成本增强证据的访问权限或临时插桩，重复昂贵运行、生产插桩或改动共享系统需用户批准。置信度分三档：confirmed（检查显示症状且仅改变疑似原因后消失）、likely（证据符合一个假设并排除主要对手，但无此检查）、possible（对手尚无法区分）。
假设与插桩：测试前写出三到五个竞争解释并排序，每个假设须有可区分预测；按能区分多少假设选择下一步检查，记录哪条观察排除了哪个假设。探针只针对特定预测、每次只变一个因素，优先在分歧边界用调试器或 REPL，否则加少量定向日志；临时日志加唯一标签（如 [dbg-7f3a]）便于搜索清除。性能回退先测量基线，用计时工具、分析器或查询计划对比并二分定位。
修复与验证：修复证据支持的根因，而非症状最后可见步骤；在原始未缩小场景重跑回路确认症状消失，并检查依赖该行为的其他调用方。遵循项目自身测试政策，在合适接缝加回归测试；接缝过浅会带来虚假信心。证据受限时说明当前可做的验证与遗留项。收尾时按标签清除插桩、删除或标记临时工具、恢复为复现改动的配置，并在提交信息中写明确认的根因。报告应包含症状、原因与证据、被排除的假设及方式、修复、验证命令与输出、残余不确定性。
限制：资料未提供安装命令、平台支持、收费或价格信息。