Diagnosing Bugs
查明用户描述的异常,交付根因证据、影响范围和最小修复建议。根据已有证据选择调查路径。
按项目知识协议使用相关 CONTEXT 与当前适用的 RULE;同一任务已有知识足够时复用。
诊断
- 确认具体症状、触发输入和预期行为;已有错误、业务单据、日志和运行结果直接作为调查起点。
- 沿真实调用路径检查代码、配置和数据。数据库查询问题优先执行与实际查询等价的 SQL,并追溯命中的业务记录和状态。
- 对证据尚不能解释的部分提出可证伪假设,用最小查询或实验区分。假设数量由实际分歧决定;读取代码可以帮助建立假设,结论需要相应证据。
- 已有代码与数据足以说明原因时交付诊断。缺少运行环境时继续能完成的静态分析,区分已证实内容与待运行验证的判断。
难复现、间歇性故障或性能回退需要进一步实验时,读取 INVESTIGATION.md,用能变红的循环、最小化、假设和插桩区分原因。没有能变红的信号时,不要靠读代码锁定根因。
修复与验证
只要求诊断时保持应用代码和环境不变。需要会修改应用或环境的临时插桩时,先确认该操作已在授权范围内。
用户要求修复时,在根因的所有者处完成最小改动,检查受影响的调用者。沿用项目已有验证;当回归测试能够覆盖真实故障且有必要保留时,把复现转为测试。接缝太浅、测试无法执行真实 bug 模式时,记录为发现,不制造虚假信心。
验证应直接回答原异常是否消除、相关既有行为是否保留。只报告实际执行和观察到的结果;无法运行的部分明确说明。清理本次临时插桩,保留必要证据。
交付
说明根因、证据位置、受影响场景,以及修复建议或已完成的修复与验证。仍有不确定性时指出能够区分原因的下一项证据;只将必须由用户提供的访问、业务判断或授权交回用户。