diagnosing-bugslisted

# Diagnosing Bugs（bug 诊断） 针对硬 bug 的规范流程。只有在明确有理由时才跳过某个阶段。 探索代码库时，阅读 `CONTEXT.md`（如果存在）以建立相关模块清晰的 mental model，并检查你正在改动的区域附近的 ADR。 ## 阶段 1 — 构建 feedback loop **这就是本 skill 的核心。** 其他一切都是机械性的。如果你有一个针对 _这个_ bug 的**紧的**通过/失败信号——一个能在此 bug 上变红的信号——你就能找到原因；bisection、hypothesis 检验和 instrumentation 都只是消耗这个信号而已。如果没有这样一个信号，再怎么盯着代码看也救不了你。 在此投入不成比例的努力。**要激进。要有创造力。拒绝放弃。** ### 构建 feedback loop 的方法——大致按这个顺序尝试 1. **失败的测试** —— 在能触及 bug 的任意 seam 上：unit、integration、e2e。 2. **Curl / HTTP 脚本** —— 针对正在运行的 dev server。 3. **CLI 调用** —— 使用 fixture 输入，将 stdout 与已知正确的 snapshot 进行 diff。 4. **无头浏览器脚本**（Playwright / Puppeteer）—— 驱动 UI，对 DOM/console/network 做断言。 5. **重放捕获的 trace。** 把真实的网络请求/载荷/事件日志保存到磁盘；在隔离环境中通过代码路径重放它。 6. **一次性 harness。** 启动系统的一个最小子集（单个服务、mocked 依赖），用一次函数调用触发 bug 代码路径。 7. **Property / fuzz 循环。** 如果 bug 是"有时输出错误"，运行 1000 个随机输入并寻找失败模式。 8. **Bisection harness。** 如果 bug 出现在两个已知状态之间（commit、数据集、版本），把"在状态 X 启动、检查、重复"自动化，这样你就能 `git bisect run` 它。 9. **差分循环。** 对旧版本 vs 新版本（或两种配置）运行相同的输入并 diff 输出。 10. **HITL bash 脚本。** 最后手段。如果必须由人来点击，用 `scripts/hitl-loop.template.sh` 驱动_他们_，让循环仍然保持结构化。捕获到的输出反馈给你。 构建出正确的 feedback loop，bug 就修好了 90%。 ### 收紧 feedback loop 把 feedback loop 当产品来对待。一旦你有了一个循环，就**收紧**它： - 能更快吗？（缓存设置、跳过无关的初始化、缩小测试范围。） - 能让信号更锐利吗？（对具体症状断言，而不是"没崩溃"。） - 能更 deterministic 吗？（固定时间、给 RNG 播种、隔离文件系统、冻结网络。） 一个 30 秒的 flaky feedback loop 几乎不比没有 loop 强多少；一个 2 秒的 deterministic feedback loop 才是紧的——这是调试领域的超能力。 ### Non-deterministic bugs（非确定性 bug） 目标不是干净的 repro，而是**更高的 repro rate**。把触发循环 100 次、并行化��