Adversarial scenarios

Adversarial Scenarios

通过逆向推导，从正常用户路径中找到最不符合直觉的失效路径。

When to Use

• 需求文档完成后，需要推导功能分支和异常场景
• 架构设计前，需要识别关键的风险路径
• 安全设计前，需要知道哪些路径一旦失效影响最大
• 任何时候需要"如果坏了怎么坏"的系统思考

NOT When to Use

• 正常功能路径已经清晰，不需要推导
• 项目是 greenfield，核心功能尚未定义
• 已有完整的 FMEA 或故障树分析

Input

来源	内容
user-stories.md	用户故事（正常路径）
assumptions.md	项目假设（约束条件）
system-design.md	系统架构（用于识别组件边界）

Output Schema

文件	类型	说明
wiki/03-architecture/threat-scenarios.md	对抗性场景文档	失效路径清单、影响分析

Minimum Viable Output

• 至少 5 个对抗性场景
• 每个场景的触发条件、失效路径、影响程度
• 至少 2 个需要架构层面响应的场景

Complete Output

• 完整对抗性场景清单（覆盖所有核心 US）
• 每个场景的详细失效路径描述
• 影响程度和可能性评级
• 对应的架构响应（需要改设计 vs. 记录风险 vs. 可接受）
• 测试用例映射（每个场景对应至少一个测试用例）

Dependencies

类型	说明
前置	requirements-spec（user stories 已输出）
前置	assumptions-tracking（假设清单已输出）
后置	architecture-decisions（对抗性场景作为架构约束）
依赖读取	user-stories.md、assumptions.md

Procedure

Phase 1: 提取核心功能路径

从 user-stories 中提取所有"正常路径"——用户预期怎么用这个功能。

## 核心功能路径清单

从每个 US 中提取：

| US-ID | 功能 | 正常路径 | 用户预期结果 |
|-------|------|---------|------------|
| US-001 | 提交业务记录 | 打开页面 → 填写信息 → 提交 → 显示成功 | 记录被保存并可再次查询 |

Phase 2: 逆向推导 — "如果坏了，怎么坏？"

对每个正常路径，问三个通用问题：

问题 A（角色反转）：用户会不会故意绕过这个流程？
问题 B（边界踩踏）：在流程的哪个节点踩进去会引发意外？
问题 C（依赖断裂）：这个功能依赖什么？这个依赖消失会怎样？

然后问一个项目相关问题：

问题 D（换位）：如果我是这个产品最不满意的用户，我会怎么滥用它？

Phase 3: 场景推导模板

使用以下模板系统化推导：

## 对抗性场景模板

### 场景命名：`<功能>_<失效方式>`

- **所属 US**：[正常路径的 US-ID]
- **触发条件**：[什么动作/输入/时间触发这个失效]
- **失效路径**：
  1. [步骤1]
  2. [步骤2]
  3. [步骤3]
- **用户预期 vs 实际结果**：
  - 预期：[用户以为会怎样]
  - 实际：[实际发生了什么]
- **影响程度**：🔴 高 / 🟡 中 / 🟢 低
- **可能性**：🔴 高 / 🟡 中 / 🟢 低

### 影响程度评级标准

| 等级 | 标准 | 示例 |
|------|------|------|
| 🔴 高 | 用户数据丢失/泄露、或核心业务流程完全中断 | 业务记录全部丢失、用户账号被劫持 |
| 🟡 中 | 部分功能失效或性能显著下降，用户体验受损 | 搜索结果丢失 50%、签到通知延迟发送 |
| 🟢 低 | 轻微问题，不影响核心功能，有 workaround | 界面显示轻微错位、非关键通知发送慢 |

### 可能性评级标准

| 等级 | 标准 | 判定依据 |
|------|------|---------|
| 🔴 高 | 在正常或轻度异常使用下很容易触发 | 用户操作失误、网络波动、单机故障 |
| 🟡 中 | 需要特定条件或较难遇到 | 并发竞争、大数据量边界、第三方服务异常 |
| 🟢 低 | 极端条件或多重故障叠加才会发生 | 数据中心级故障、全部依赖同时不可用 |
- **架构响应**：
  - 需改设计：[需要架构层面修改]
  - 记录风险：[不影响当前架构，记录]
  - 可接受：[故意设计的降级行为]

Phase 4: 分类整理

将所有场景按影响程度分类：

## 对抗性场景矩阵

### 🔴 高影响 × 🔴 高可能性（必须解决）

| 场景 | 失效路径 | 建议架构响应 |
|------|---------|------------|
| | | |

### 🔴 高影响 × 🟢 低可能性（记录风险）

| 场景 | 失效路径 | 建议架构响应 |
|------|---------|------------|
| | | |

### 🟢 低影响 × 🔴 高可能性（可接受或简单修复）

| 场景 | 失效路径 | 建议架构响应 |
|------|---------|------------|
| | | |

Phase 5: 映射到测试用例

每个高影响场景必须至少对应一个测试用例：

## 测试用例映射

| 场景 ID | 对应测试用例 | 测试类型 |
|---------|------------|---------|
| AS-001 | TC-xxx: [描述] | Unit/Integration/E2E |

通用对抗性问题清单

以下问题适用于任何项目，触发项目相关的具体场景：

#	问题	推导方向
1	如果用户重复这个操作 100 次，会怎样？	资源泄漏、状态累积
2	如果用户在操作过程中强制退出，会怎样？	中断处理、数据一致性
3	如果依赖服务/模块不可用，会怎样？	降级策略、超时处理
4	如果用户输入完全不符合预期，会怎样？	输入校验、错误提示
5	如果两个用户同时做同一件事，会怎样？	并发控制、数据竞争
6	如果数据被篡改（非攻击），会怎样？	校验机制、备份恢复

Target Pages

• <项目根目录>/wiki/03-architecture/threat-scenarios.md

Changelog

日期	变更	原因
2026-07-15	示例改为领域无关的业务记录场景	避免示例成为隐含需求
2026-04-30	修复：新增影响程度评级标准表（🔴高/🟡中/🟢低，含判定标准和示例）；新增可能性评级标准表（🔴高/🟡中/🟢低，含判定依据）	影响程度和可能性评级无明确定义标准
2026-04-30	新建 skill	对抗性场景推导是识别架构风险的关键，需要独立 skill