Hypothesis loop：用 AI 做假设循环，而不是一次性回答
Page card
- Part：Part 1 / 通用分析
- 适用角色：开发、产品、QA
- 使用场景：复杂 bug、线上异常、指标或反馈归因不明确时
- 输出物：候选假设、验证动作和收敛结论
Related jumps
Back to AI Workflow Sharing。相邻主题：Evidence-first · Context building · Minimum viable change · Knowledge capture
Summary
重点：AI 的强项不是一次猜中，而是帮助我们快速设计和执行验证循环。
复杂问题不要让 AI 直接给唯一 root cause。更好的方式是让它列出候选假设，并为每个假设设计最小验证动作。
适用场景
- 复杂 bug
- 线上异常
- 性能问题
- 间歇性失败
- 数据不一致
- 难以从单个 diff 看懂的问题
工作方式
- 让 AI 明确列出 2-3 个候选假设。
- 为每个假设设计最小验证动作。
- 先验证最容易排除或最能缩小范围的假设。
- 每轮验证后更新判断：排除了什么、确认了什么、下一步是什么。
- 收敛后再写修复方案或对外结论。
假设循环模板
Hypothesis 1:
Evidence for:
Evidence against:
Fastest validation:
Expected result:
Decision after validation:
可分享案例
- Audio issue：是录音内容问题、上传 metadata 问题、播放器解析问题，还是错误映射问题？
- CI failure：是 secret 缺失、token 无权限、workflow 没传入，还是 package registry 配置问题？
Editorcrash：是 FE renderer 缺失、AI 生成 schema 错误，还是数据迁移不完整？
可复用规则
每个假设必须配一个验证动作。 没有验证动作的假设只是猜测。
- 不让 AI 只给一个 root cause，除非已经有证据闭环。
- 验证后要更新假设列表，而不是继续堆更多可能性。
- 对外结论要说明“排除了什么”和“确认了什么”。
References
- Hypothesis-driven debugging — 直接支撑本页的核心方法：把 debugging 当作观察、假设、预测、验证的循环。
- Ruling Things Out: Hypothesis-Driven Debugging, Kepner-Tregoe, and the Art of Structured Root Cause Analysis — 强调“排除假设”本身就是调查进展，适合讲复杂问题如何收敛。
- A Grounded Theory of Debugging in Professional Software Development — 关于专业软件开发中 debugging 行为的研究材料，可用于支撑 root cause analysis 不只是直觉，而是可观察的工作模式。
- How to Build Human-in-the-Loop Oversight for AI Agents — 虽然偏生产 AI agent，但其中 confidence-based escalation 和 human review points 适合连接“假设循环”和“人工判断”。