直接回答原版教 Agent 严谨地查困难 Bug；改造版进一步决定什么时候该查、能不能改，以及如何安全处理日志、HAR 和不完整证据。
Agent 调试最像魔术的时刻，是它刚看完报错，三十秒后就告诉你：“根因找到了。”
然后改三个文件，补一个测试，顺手说问题已经解决。
唯一缺少的步骤是：那个 Bug 从头到尾都没有被复现过。
这也是 diagnosing-bugs 需要改造的原因。原版在技术上已经很强，问题不在于步骤太多，而是 Agent 进入真实项目后还要判断：什么时候需要重流程，什么时候可以直接处理，以及用户到底有没有让它改。
原版最强的部分被完整保留
Matt Pocock 的原版 有一条很硬的纪律：先建立一个能稳定观察故障的反馈回路，再谈根因。
这个判断是对的。
没有复现，你就不知道补丁修的是用户看到的问题，还是旁边另一个刚好也报错的东西。没有同一个判定信号，修改前后也无法比较。
反馈回路、最小复现、可证伪假设、定向探针和回归验证因此全部保留。这些不是原版的负担，是它最值钱的部分。
调整发生在它进入日常工作以后的适配方式。
第一处改动：不是每个 Bug 都值得开庭
原版是一套为困难 Bug 设计的强纪律流程。可 Agent 每天遇到的不全是困难 Bug。
编译器已经指出具体类型错误，失败断言已经暴露错误条件，或者用户已经知道修法，只是让你执行。这些场景还要求先列五个假设、建立完整实验，很容易把严谨做成仪式感。
改造版会先分类。
明显错误走短路径，直接说明证据，再按用户要求处理。只有间歇性故障、远程环境问题、性能回退、修过又复发，或者当前原因不明时，才进入完整诊断循环。
原版保证困难 Bug 不被草率处理；改造版再加一层路由，避免简单问题被过度处理。
第二处改动：复现不了，也不能原地装死
理想状态当然是本地一条命令稳定复现。但真实问题经常只在生产环境、某个账号、某段网络条件下出现。
如果把“没有本地复现”直接等同于“不能继续”，Agent 最后只会把问题退回给用户。
改造版允许继续缩小证据范围：重放真实请求，检查日志样本、HAR 或 Trace，提高偶发问题的触发频率，或者提出最小的临时观测需求。能确认到哪一层，就写到哪一层。
它可以说“这是当前最受支持的假设”，但不能把这句话偷偷升级成“根因已经确认”。
这点对 Agent 很重要。它们通常不怕信息不够，怕的是自己显得没有答案。结果就是把最顺眼的解释写得像事实。
证据不完整时，正确动作不是编一个完整结论，而是把缺口缩小到下一步可以验证。
第三处改动：会修，不代表有权修
这是原版没有重点解决、却很容易在真实 Agent 工作里出事的一层。
用户说“帮我诊断”，意思是找原因，不是默认授权修改代码。更不包括提交、推送、创建 Issue、修改线上系统，或者往生产环境加埋点。
所以改造版会先判断任务边界：只诊断，还是诊断并修复。
只诊断时，项目文件和外部系统保持只读。可以读代码、跑已有测试、看日志和使用已有复现，但不能顺手新建测试、脚本、临时 Harness 或埋点。
如果复现必须新增文件或观测代码，Agent 要先说清楚准备创建什么、放在哪里、什么时候清理，等用户批准以后再动。这样“只诊断”才不是一句口号。
日志、HAR、Trace 和请求样本也不等于可以直接贴进对话或 Issue。Cookie、Authorization Header、Token、个人信息和无关客户数据必须先移除，只保留能证明判断的最小片段。
诊断需要更多证据，但更多证据不等于可以扩大权限或扩大暴露面。
即使允许修，也要先看工作区里有没有别人的未提交修改。修自己的 Bug，顺手覆盖用户正在做的东西，这种“成功”没有意义。
两个版本放在一起，差异其实很直接
| 原版重点 | 改造版增加了什么 |
|---|---|
| 为困难 Bug 建立严格反馈回路 | 先判断是否真的需要完整流程 |
| 没有可靠信号就不草率下结论 | 无法完整复现时，允许基于分层证据继续推进 |
| 围绕技术诊断和修复展开 | 明确区分只读诊断与允许修改 |
| 用实验排除错误假设 | 同时保护脏工作区和外部写入边界 |
| 允许使用日志、HAR 与 Trace | 默认本地处理，引用前先脱敏 |
| 完整保留调查过程 | 默认只交付症状、原因、证据、行动和不确定性 |
所以它不是一个“更精简的 Matt Pocock Skill”。精简只是表面。
真正的变化是，它从一套困难 Bug 的调试纪律，变成了可以放进日常 Agent 工作里的诊断层。技术上保持严谨，行动上知道分寸。
diagnosing-bugs 直接改造自 Matt Pocock 的 MIT 开源版本，来源标记为 OPEN-SOURCE ADAPTATION。
公开说明这篇文章来自真实工作。客户信息、数据和未公开的实现细节已经移除。