技能介绍

先有能变红的命令，再谈修复

大多数 AI 调试失败的方式惊人地一致：读到报错信息，扫一眼代码，直接改一版「看起来对」的补丁。问题在于，没有一条真正运行过且失败过的反馈命令，任何「修复」都只是基于直觉的猜测。tri-fix 把这条规则上升为第一性原则——没有能变红的反馈循环，就没有假设阶段。「红」指一条已真实运行过、且在当前 bug 上失败的命令（测试、curl、CLI 调用、无头浏览器脚本等）。在这之前，不允许跳到根因结论或补丁。

六阶段方法论与双审批门

核心方法论分六个阶段，阶段号是全文唯一的编号体系：

阶段 1 建立反馈循环：按优先级尝试十种构造方式，从失败的测试到 HITL 脚本，并持续收紧循环——更快、更确定、信号更尖锐
阶段 2 复现 + 最小化：确认失败模式与用户描述一致，逐步切除无关输入，直到每个剩余元素都起支撑作用
阶段 3 假设生成：强制 3-5 个可证伪假设并按可能性/验证成本排序，防止单假设锚定
阶段 4 插桩验证：每个探针对应一条预测，一次只改一个变量，最后做「去掉→消失→加回→重现」的因果确认
阶段 5 修复 + 回归测试：先写回归测试再改代码，变更仅落在根因处
阶段 6 清理 + 复盘：移除全部 [DEBUG-...] 插桩，把被证实的假设写进 commit message

执行链路上设有两道落盘审批门加执行前确认：bug-report.md（故障报告）→ diagnosis.md（根因诊断）→ fix-tasks.md（原子化任务）→ 执行 → fix-report.md。任一门未通过则携反馈回炉，禁止跳门抢跑。

适用范围与注意点

tri-fix 负责「读取快照 → 建立反馈循环 → 复现最小化 → 根因诊断 → 修复执行 → 回归验证」全链路，但不负责意图识别（tri-intent）、新功能编码（tri-coding）、代码审查（tri-review）和架构规划（tri-plan）。独立使用时会先检测上游依赖，用户拒绝安装时进入降级模式。

性能回归走专门的测量分支（基线测量 + 二分，不打日志）；偶发 bug 的目标不是干净复现而是提高复现率。若穷尽阶段 1 仍无法让循环变红，必须停下索取环境权限、抓取产物或生产插桩许可——不允许「先猜一个方向试试」。版本检查是第零步硬门，由 scripts/check_update.py 统一判定，prompt 层不做任何内联推断。