硬核缺陷诊断流程提示词

请按一套纪律化的诊断流程排查难缠的 bug 或性能回退：复现→最小化→提出假设→插桩→修复→回归测试。非必要不跳阶段；探索代码时先用项目术语建立模型、查看相关 ADR。

阶段 1——建立反馈环（这是关键）：为这个 bug 建立一个快速、确定、可自动跑的通过/失败信号。有了它，二分、验证假设、插桩都只是消费这个信号；没有它，光盯代码没用。请积极、有创意、绝不放弃。可尝试（大致按序）：失败测试；curl/HTTP 脚本；带夹具输入的 CLI 并对比快照；无头浏览器脚本；回放捕获的真实请求/负载/事件；一次性最小化 harness；属性/模糊测试循环；二分 harness；差分对比（新旧版本/两套配置）；实在不行才用有人参与的脚本。并持续打磨这个环：更快、信号更锐、更确定。对非确定性 bug，目标是提高复现率（循环、并行、加压、收窄时序）而非一次干净复现。若确实建不出环，明说、列出已尝试的，并向用户索要可复现环境、捕获物（HAR/日志/core dump/带时间戳录屏）或加临时生产插桩的许可，不要在无环的情况下贸然提假设。

阶段 2——复现：跑通反馈环，亲眼看到 bug 出现。确认它就是用户描述的失败（别修错 bug）、可多次复现、并已捕获确切症状。

阶段 3——提出假设：在动手前给出 3~5 个按可能性排序的可证伪假设，每个说明其预测（"若 X 是原因，则改 Y 会让 bug 消失/改 Z 会更糟"）。把排序清单先给用户看，他们的领域知识常能瞬间重排（AFK 则按你的排序继续）。

阶段 4——插桩：每个探针对应阶段 3 的某个预测，一次只改一个变量。优先用调试器/REPL，其次是边界处的定向日志，别"全量打印再 grep"。每条调试日志加唯一前缀（如 [DEBUG-a4f2]），收尾时一次 grep 清干净。性能回退用基线测量+二分，先测量后修复。

阶段 5——修复+回归测试：若存在正确的测试接缝，先写会失败的回归测试→看它失败→改→看它通过→再对原始（未最小化）场景跑一遍反馈环。若没有正确接缝，这本身就是一个发现，记下来。

阶段 6——清理与复盘：确认原始复现不再出现、回归测试通过（或记录接缝缺失）、所有 [DEBUG-...] 插桩已删、临时原型已清理、把最终成立的假设写进提交/PR 说明。最后问：怎样才能从源头预防此类 bug；若涉及架构改动，在修复落地后再提出建议。

要诊断的问题：____