办公提效免费复制
硬核缺陷诊断流程提示词（办公）
碰上难缠的 bug 或性能回退时用这条：它按复现、最小化、提假设、插桩、修复、回归的流程推进，先帮你搭一个稳定可跑的通过或失败信号，再逐阶段缩小范围。适合反复出现却找不到原因的问题。
适合做什么
- 运营周报 / 复盘 / 会议纪要要提速
- 要把散乱信息整理成可执行清单
- 跨同事交接对话上下文或项目说明
不太适合
- 替代公司内部审批与权限系统
- 处理含机密数据时未脱敏就整段粘贴
提示词正文
请按一套纪律化的诊断流程排查难缠的 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；若涉及架构改动，在修复落地后再提出建议。
要诊断的问题：____
【输出要求】请用中文回答；结构清晰；不确定处明确标注假设；给出可直接落地的版本。复制后粘贴到 AI 对话框，按填空补全即可。
使用步骤
- 先写清 bug 症状、影响版本和触发条件
- 粘贴提示词，把症状与已有信号附在后面
- 按它给的建环建议先做出通过失败信号
常见问题
非确定性 bug 能诊断吗？
可以试。提示词把提高复现率当作目标，会建议循环、并行、加压、收窄时序等做法。你需要在输入里说明大致复现频率和已观察到的现场条件，才好判断信号是否可靠。
搭不出失败信号时怎么办？
把已尝试的手段和环境一起写给它，请它列出还缺哪些条件，并明确说出暂时建不出环。这时能拿到的多是排查方向，具体验证仍要你在真实环境里做。
能直接让它改代码吗？
可以提出修复建议，但要它标明是针对根因还是权宜之计，以及剩余风险。上线前仍需你在本地跑一遍回归测试，别把未验证的改动直接合入主线。
来源说明
整理自公开提示词站点素材，经 52运营 筛选与页面改写，便于运营场景检索。 原始参考：来源链接