---
title: "Curiosity-Driven Bug Discovery"
type: concept
tags: []
last_updated: 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