Negative Requirement

---
name: negative-requirement
description: 从正向需求出发，分析用户错误使用、中途放弃、状态异常等负向场景，设计程序的检测、恢复和引导策略。当需求挖掘完成后需要补充负向场景分析，或用户提到"错误处理"、"异常场景"、"边界情况"、"用户犯错"时使用。
---

# 负向需求设计

从正向需求出发，系统性分析用户可能的错误使用路径，设计程序在这些情况下的预期行为。

## 概述

**目的**：补充需求挖掘中容易被忽视的负向场景，确保程序在用户犯错、状态异常等情况下的健壮性

**功能**：分析负向场景分类、评估风险等级、设计检测/恢复/引导策略、输出负向需求清单

**使用场景**：
- 当 `requirement-mining` 完成后需要补充负向场景时
- 当用户提到"错误处理"、"异常场景"、"边界情况"时
- 当用户说"用户可能犯什么错"、"如果中途放弃怎么办"时

## 核心原则

- **从正向推负向**：基于已确认的正向需求，推导可能的负向场景，而非凭空想象
- **用户视角优先**：优先分析用户行为相关的负向场景（误操作、放弃），再分析系统状态异常
- **概率与影响并重**：同时考虑发生概率和影响程度，高概率+高影响的场景优先处理
- **可操作的策略**：每个负向场景必须给出具体的程序行为设计，不能只列问题不给方案
- **不重复正向需求**：负向需求是补充，不重复正向需求已覆盖的内容

## 负向场景分类

| 类型 | 描述 | 典型场景 |
|------|------|----------|
| **用户误操作** | 用户操作错误但非故意 | 选错选项、填错内容、点错按钮、操作顺序错误 |
| **参数输入错误** | 接口/命令参数层面的错误 | 函数参数类型错误、API参数格式错误、CLI参数拼写错误、必填参数缺失、参数值超出范围 |
| **中途放弃** | 用户主动中断流程 | 关闭页面、切换任务、超时离开、放弃当前操作 |
| **状态异常** | 系统或环境状态异常 | 网络中断、服务超时、并发冲突、数据不一致 |
| **权限问题** | 权限相关异常 | 越权访问、权限变更、会话过期、token失效 |
| **数据异常** | 数据层面的异常 | 无效输入、格式错误、数据冲突、重复提交、数据丢失 |
| **外部依赖** | 第三方服务异常 | API不可用、响应超时、返回异常、资源不足 |

## 分析框架

对每个负向场景，按以下维度分析：

### 1. 场景识别

- **触发条件**：什么情况下会发生
- **用户意图**：用户原本想做什么
- **实际行为**：用户实际做了什么（或发生了什么）

### 2. 风险评估

| 维度 | 评估标准 |
|------|----------|
| **发生概率** | 高（>30%用户可能遇到）/ 中（10-30%）/ 低（<10%） |
| **影响程度** | 严重（数据丢失/资金损失）/ 中等（体验受损）/ 轻微（可快速恢复） |
| **可检测性** | 程序能否自动检测到此场景 |

### 3. 策略设计

| 策略类型 | 说明 | 适用场景 |
|----------|------|----------|
| **预防** | 在用户犯错前阻止 | 高风险操作、不可逆操作 |
| **检测** | 及时发现异常状态 | 状态异常、数据异常 |
| **恢复** | 从异常状态恢复 | 网络中断、服务超时 |
| **引导** | 引导用户回到正确路径 | 用户误操作、操作遗漏 |
| **容错** | 宽容处理用户输入 | 格式不规范、大小写不一致 |

### 4. 用户体验设计

- **感知方式**：用户如何知道发生了什么（提示、高亮、震动等）
- **操作路径**：用户应该如何处理（重试、修改、跳过等）
- **情绪安抚**：如何减少用户的焦虑感（友好的提示、进度展示等）

## 执行流程

### Step 1：输入确认

确认输入的正向需求清单。输入来源可以是：

1. `requirement-mining` 输出的需求清单
2. 用户直接提供的需求描述
3. 已有的需求文档

如果用户没有提供正向需求，提示用户先执行 `requirement-mining` 或提供需求描述。

**输入格式**：
```markdown
请提供正向需求清单，格式如下：

| 需求 ID | 需求描述 | 预期效果 |
|---------|----------|----------|
| REQ-01  | ...      | ...      |
| REQ-02  | ...      | ...      |

或直接提供需求描述文本。
```

### Step 2：场景推导

基于正向需求，按场景分类推导可能的负向场景。

**推导方法**：

1. **用户误操作**：
   - 需求中涉及的表单、选择、点击操作 → 可能选错/填错/点错
   - 多步骤流程 → 可能跳步/乱序
   - 相似选项 → 可能混淆

2. **参数输入错误**：
   - 函数/方法调用 → 参数类型错误、顺序错误、缺失、多余
   - API调用 → 请求参数格式错误、必填参数缺失、参数值超出范围
   - CLI命令 → 参数拼写错误、选项组合错误、缺少必需参数
   - 配置文件 → 配置项格式错误、值类型不匹配、必填项缺失

3. **中途放弃**：
   - 长流程 → 可能中途离开
   - 需要等待的操作 → 可能超时
   - 需要外部配合的操作 → 可能无法继续

4. **状态异常**：
   - 涉及网络请求 → 可能中断
   - 涉及并发操作 → 可能冲突
   - 涉及状态保存 → 可能丢失

5. **权限问题**：
   - 涉及多角色 → 可能越权
   - 长时间操作 → 可能会话过期
   - 涉及敏感操作 → 可能需要二次验证

6. **数据异常**：
   - 用户输入 → 可能无效/格式错误
   - 唯一性约束 → 可能重复提交
   - 关联数据 → 可能冲突

7. **外部依赖**：
   - 第三方API → 可能不可用/超时
   - 文件/资源 → 可能不存在/无权限

### Step 3：风险评估

对每个场景评估风险等级：

| 风险等级 | 条件 | 处理优先级 |
|----------|------|------------|
| **P0** | 高概率 + 高影响 | 必须处理 |
| **P1** | 高概率 + 中影响 或 中概率 + 高影响 | 应该处理 |
| **P2** | 中概率 + 中影响 或 低概率 + 高影响 | 建议处理 |
| **P3** | 低概率 + 低影响 | 可选处理 |

### Step 4：策略设计

对每个场景设计具体的程序行为：

```markdown
### NEG-XX：[场景名称]

**场景描述**：[什么情况下会发生]

**触发条件**：[具体的触发条件]

**风险等级**：[P0/P1/P2/P3]

**程序行为**：

#### 预防策略（如有）
- [如何在用户犯错前阻止]

#### 检测策略
- [如何检测到此场景]
- [检测时机：实时/延迟/轮询]

#### 恢复/引导策略
- [检测到后程序应该做什么]
- [用户应该看到什么]
- [用户应该如何操作]

#### 用户体验设计
- **提示方式**：[弹窗/Toast/内联提示/状态栏]
- **提示内容**：[具体的提示文案]
- **操作选项**：[重试/修改/跳过/取消]
- **情绪安抚**：[友好的语气、进度展示等]
```

### Step 5：输出负向需求清单

输出结构化的负向需求清单：

```markdown
## 负向需求清单

### 风险概览

| 风险等级 | 场景数量 | 说明 |
|----------|----------|------|
| P0       | N 个     | 必须处理 |
| P1       | N 个     | 应该处理 |
| P2       | N 个     | 建议处理 |
| P3       | N 个     | 可选处理 |

### 负向场景清单

| 场景 ID | 类型 | 场景描述 | 风险等级 | 程序行为概述 |
|---------|------|----------|----------|--------------|
| NEG-01  | 用户误操作 | ... | P0 | 二次确认弹窗 |
| NEG-02  | 中途放弃 | ... | P1 | 自动保存草稿 |
| NEG-03  | 状态异常 | ... | P0 | 自动重试+手动查询 |

### 详细场景分析

#### NEG-01：[场景名称]

**场景描述**：...

**风险评估**：
- 发生概率：[高/中/低]
- 影响程度：[严重/中等/轻微]
- 风险等级：[P0/P1/P2/P3]

**程序行为设计**：

[按Step 4格式输出]

---

#### NEG-02：[场景名称]

[同上格式]

---

### 与正向需求的关联

| 负向场景 | 关联的正向需求 | 关联说明 |
|----------|----------------|----------|
| NEG-01   | REQ-01         | 用户在执行REQ-01时可能误操作 |
| NEG-02   | REQ-02         | 用户在执行REQ-02时可能中途放弃 |

### 设计建议

1. **优先级建议**：建议优先实现P0场景的处理
2. **交互建议**：[基于场景特点的交互设计建议]
3. **测试建议**：[需要重点测试的场景]
```

### Step 6：用户确认

请用户确认负向需求清单：

```markdown
以上是基于正向需求推导的负向场景，请确认：

1. **场景完整性**：是否遗漏了重要的负向场景？
2. **风险评估**：风险等级划分是否合理？
3. **策略可行性**：程序行为设计是否可行？
4. **优先级**：处理优先级是否符合预期？

请确认或提出修改意见。
```

根据用户反馈迭代修改，最多迭代2次。

## 报告模板

```markdown
# 负向需求设计报告

## 1. 输入需求

### 1.1 正向需求清单
[粘贴输入的正向需求清单]

## 2. 风险概览

| 风险等级 | 场景数量 | 说明 |
|----------|----------|------|
| P0       | N 个     | 必须处理 |
| P1       | N 个     | 应该处理 |
| P2       | N 个     | 建议处理 |
| P3       | N 个     | 可选处理 |

## 3. 负向场景清单

| 场景 ID | 类型 | 场景描述 | 风险等级 | 程序行为概述 |
|---------|------|----------|----------|--------------|
| NEG-01  | ...  | ...      | ...      | ...          |

## 4. 详细场景分析

### 4.1 NEG-XX：[场景名称]

**场景描述**：...

**风险评估**：
- 发生概率：...
- 影响程度：...
- 风险等级：...

**程序行为设计**：
- 预防策略：...
- 检测策略：...
- 恢复/引导策略：...
- 用户体验设计：...

---

[重复每个场景]

## 5. 与正向需求的关联

| 负向场景 | 关联的正向需求 | 关联说明 |
|----------|----------------|----------|
| ...      | ...            | ...      |

## 6. 设计建议

1. **优先级建议**：...
2. **交互建议**：...
3. **测试建议**：...
```

## 后续步骤建议

负向需求清单输出完成后，提示用户选择后续行动：

```text
🚀 后续行动选择
━━━━━━━━━━━━━━━━

负向需求设计已完成，报告已输出。请选择后续行动：

1. 📁 落盘归档
   将负向需求报告保存到 .requirements/ 目录，便于后续引用和管理

2. 📋 合并到需求文档
   将负向需求清单合并到正向需求文档中，形成完整的需求规格

3. 🎨 进入交互设计
   使用 interaction-design 技能基于负向需求设计具体的错误处理交互流程

4. 🧪 进入测试计划
   使用 test-planner 技能基于负向需求设计测试用例

5. 📐 进入技术设计
   使用 design-craft 技能基于负向需求设计技术实现方案

6. ⏭️ 跳过
   不进行后续操作，结束负向需求设计流程

请选择 [1/2/3/4/5/6]：
```

### 选项1：落盘归档

用户选择落盘归档时，引导用户确认落盘内容，然后按 **`requirement-doc-store`** skill 的流程执行：

1. 确认落盘：提示用户落盘内容为负向需求报告（`negative-requirement.md`），确认后继续
2. 创建文档：使用 `req create` 命令创建目录并注册到 meta.json
3. 写入文档：使用 `write_to_file` 按 frontmatter 模板写入 `negative-requirement.md`
4. 验证：使用 `req list --id {REQ-NNN}` 确认

> 详细步骤、frontmatter 模板和命令参数见 `requirement-doc-store` skill。

### 选项2：合并到需求文档

用户选择合并到需求文档时：

1. 确认合并目标：提示用户选择要合并的正向需求文档
2. 读取正向需求文档：使用 `read_file` 读取目标文档
3. 合并负向需求：将负向需求清单追加到正向需求文档的"潜在风险与注意事项"部分
4. 更新关联关系：在文档中添加正向需求与负向场景的关联说明
5. 验证合并结果：使用 `read_lints` 检查文档格式

### 选项3：进入交互设计

用户选择进入交互设计时，调用 interaction-design 技能：

**输入准备**：

将负向需求报告作为输入传递给 interaction-design 技能：

```text
📋 传递给 interaction-design 的输入
━━━━━━━━━━━━━━━━

来源：negative-requirement 输出的负向需求报告

负向场景清单：
| 场景 ID | 类型 | 场景描述 | 风险等级 | 程序行为概述 |
|---------|------|----------|----------|--------------|
| NEG-01  | ...  | ...      | ...      | ...          |

正在调用 interaction-design 技能进行交互设计...
```

**技能调用**：

使用 `use_skill` 工具调用 `interaction-design` 技能，传入负向需求报告内容。

**输出衔接**：

interaction-design 技能输出交互设计文档后，提示用户：

```text
✅ 交互设计完成
━━━━━━━━━━━━━━━━

交互设计文档已生成，共 N 个交互场景。

下一步建议：
- 可以进入 design-craft 进行技术设计
- 可以将交互设计文档落盘归档

是否需要将交互设计文档保存到文件？[是/否]
```

### 选项4：进入测试计划

用户选择进入测试计划时，调用 test-planner 技能：

**输入准备**：

将负向需求报告作为输入传递给 test-planner 技能：

```text
📋 传递给 test-planner 的输入
━━━━━━━━━━━━━━━━

来源：negative-requirement 输出的负向需求报告

负向场景清单：
| 场景 ID | 类型 | 场景描述 | 风险等级 | 程序行为概述 |
|---------|------|----------|----------|--------------|
| NEG-01  | ...  | ...      | ...      | ...          |

正在调用 test-planner 技能进行测试计划设计...
```

**技能调用**：

使用 `use_skill` 工具调用 `test-planner` 技能，传入负向需求报告内容。

**输出衔接**：

test-planner 技能输出测试计划后，提示用户：

```text
✅ 测试计划完成
━━━━━━━━━━━━━━━━

测试计划已生成，共 N 个测试用例。

下一步建议：
- 可以将测试计划落盘归档
- 可以开始编写测试代码

是否需要将测试计划保存到文件？[是/否]
```

### 选项5：进入技术设计

用户选择进入技术设计时，调用 design-craft 技能：

**输入准备**：

将负向需求报告作为输入传递给 design-craft 技能：

```text
📋 传递给 design-craft 的输入
━━━━━━━━━━━━━━━━

来源：negative-requirement 输出的负向需求报告

负向场景清单：
| 场景 ID | 类型 | 场景描述 | 风险等级 | 程序行为概述 |
|---------|------|----------|----------|--------------|
| NEG-01  | ...  | ...      | ...      | ...          |

正在调用 design-craft 技能进行技术设计...
```

**技能调用**：

使用 `use_skill` 工具调用 `design-craft` 技能，传入负向需求报告内容。

**输出衔接**：

design-craft 技能输出技术设计文档后，提示用户：

```text
✅ 技术设计完成
━━━━━━━━━━━━━━━━

技术设计文档已生成。

下一步建议：
- 可以将技术设计文档落盘归档
- 可以开始编码实现
- 可以进行设计评审

是否需要将技术设计文档保存到文件？[是/否]
```

### 选项6：跳过

用户选择跳过时，直接结束负向需求设计流程：

```text
✅ 负向需求设计流程结束
━━━━━━━━━━━━━━━━

负向需求报告已输出，后续行动已跳过。

如需后续操作，可随时：
- 执行落盘归档：保存报告到 .requirements/ 目录
- 合并到需求文档：将负向需求合并到正向需求文档
- 进入交互设计：调用 interaction-design 技能
- 进入测试计划：调用 test-planner 技能
- 进入技术设计：调用 design-craft 技能
```

## 行为边界

- **基于正向需求推导**：负向场景必须基于正向需求推导，不凭空想象不相关的场景
- **不重复正向需求**：负向需求是补充，不重复正向需求已覆盖的内容
- **可操作的策略**：每个场景必须给出具体的程序行为设计，不能只列问题不给方案
- **用户确认**：输出后必须请用户确认，根据反馈迭代修改
- **不涉及技术实现**：只描述程序应该做什么，不涉及具体的技术实现细节
- **概率与影响并重**：风险评估必须同时考虑概率和影响，不能只看单一维度

## 与其他skill的关系

- **输入来源**：`requirement-mining` 输出的需求清单
- **下游应用**：
  - `interaction-design`：基于负向需求设计具体交互流程
  - `test-planner`：基于负向需求设计测试用例
  - `design-craft`：基于负向需求设计技术方案
  - `requirement-doc-store`：负向需求报告落盘归档