通用修复闭环

它要解决的问题

日常修 bug 的典型路径是：看一眼报错 → 猜个原因 → 改两行 → 跑一次测试，通过就算完事。问题在于「猜」这一步没有任何约束，同一批错误模式（module not found、配置改完不生效、lint 警告）反复靠 AI 临场发挥，修法不稳定，也留不下可复用的经验。更麻烦的是，AI 经常给出「看起来修好了」的改动——没跑验证器、没有回滚边界，下次遇到同类问题一切重来。

核心循环：六步

这个技能把修复抽象成固定闭环，关键在于顺序有约束：

• 捕获问题：整理报错原文、复现步骤、期望行为和环境信息。信息不足时只问最关键的 1–2 个问题，不做压迫式盘问。
• 确定性扫描优先：先跑错误模式匹配、重跑测试/lint、校验配置和依赖树。references/rule-patterns.md 预置 15 条高频启发式，命中即进修复，不调 AI。
• AI 推理兜底：仅在确定性扫描低置信时启用，按「假设 → 验证 → 结论」记录轨迹，避免乱猜。
• 最小修复：改动能小则小，用 git 或备份建立可回滚边界，不夹带无关重构。
• 验证闭环：修复后强制重跑验证器（测试、lint、规则重扫）。失败则回到扫描环节，默认上限 3 轮；超限停止并如实报告，不谎称修好。
• 经验沉淀：把「信号模式 → 根因 → 修复」写入经验库并标注置信度，下次同类信号直接命中，跳过推理。

适用边界

• 触发条件是出现可观察的偏差信号：报错、测试失败、构建挂、流程卡住。没有「现状 vs 期望」偏差的主观创作类任务不适用。
• 不可逆且未确认的操作——删库、强推、生产写入、清空目录——必须先显式询问并获得确认。
• 验证器与规则库都是可插拔配置，放在 references/ 而非写死在正文，按问题类型分别对应测试、校验命令或 dry-run。