3.1 KiB
title, type, tags, last_updated
| title | type | tags | last_updated |
|---|---|---|---|
| Curiosity-Driven Bug Discovery | concept | 2026-05-02 |
Definition
通过主动追问系统假设（而非被动等待测试失败）来发现高危 Bug 的方法论——将"未言明的假设"显式化，并在它们导致故障前将其消灭。
Overview
大多数生产环境中的严重 Bug 并非来自代码错误，而是来自未被显式记录的假设。这些假设在代码编写时被默许存在，随着系统演进逐渐失效，最终在生产环境中引发故障。Curiosity-Driven Bug Discovery 是一套系统化的追问框架，在工作流设计阶段就将这些假设显式化。
Four Question Dimensions
1. 数据持久化假设（Data Persistence Assumptions）
- 数据存储在哪里？存储是持久化还是临时性的？
- 重启后数据是否仍然存在？
- 数据在什么条件下被清理？
追问模板：
"Where is this data stored? Is the storage durable or ephemeral? What happens on restart?"
2. 网络连通性假设（Network Connectivity Assumptions）
- Service A 能否实际到达 Service B？
- 它们在同一个网络段吗？是否有防火墙规则？
- 服务之间是否存在 DNS 解析延迟？
追问模板：
"Can service A actually reach service B? Are they on the same network? Is there a firewall rule?"
3. 时序假设（Ordering/Timing Assumptions）
- 当前步骤假设前一个步骤已完成——但它们是并行运行的吗？
- 什么机制确保时序正确？（健康检查？轮询？事件？锁？）
- 超时值是否合理？
追问模板：
"This step assumes the previous step completed — but they run in parallel. What ensures ordering?"
4. 认证授权假设（Authentication/Authorization Assumptions）
- 此端点在启动时被调用——但调用方是否经过身份验证？
- 什么防止未授权访问？
- 凭证在何时何地可用？
追问模板：
"This endpoint is called during setup — but is the caller authenticated? What prevents unauthorized access?"
Application in Workflow Architect
在 Discovery Audit Checklist 中，每发现一个隐式工作流，Workflow Architect 必须主动用四个追问维度扫描一遍。发现的高危假设记录在 Reality Checker Findings 表中，标注 severity 为 Critical 或 High。
Why "Curiosity-Driven"
"Curiosity-driven" 强调这是主动探索而非被动验证：
- 被动验证：已有 bug 报告 → 查找原因
- 主动探索：无 bug 报告 → 追问假设 → 发现潜在 bug
这套方法论的核心洞察：最危险的 bug 是那些从未有人怀疑其存在的假设。
Success Criteria
- 每个工作流的 Assumptions 表都被填满（非空白）
- 假设表中的假设在后续 Sprint 中被逐一验证或修正
- 好奇心驱动发现的 bug 数量 ≥ 被动测试发现的 bug 数量
Related Concepts
- Workflow-Tree-Spec：假设记录的载体（Assumptions 节）
- Reality-Checker：验证假设真实性的 Agent
- Discovery-Audit：发现隐式工作流的入口
Aliases
- Assumption Mining
- Hypothesis-First Bug Discovery
- Proactive Assumption Surfacing