# 行为合规验证（Behavioral Testing）

> 核心问题：你的 skill 写完之后，agent 真的会遵守它吗？

功能性 eval（正常/边界/攻击路径）验证的是"能不能做到"，而行为合规验证解决的是另一个问题：**"在压力下，agent 会不会找借口绕过这个 skill？"**

这套方法直接移植自 superpowers TDD 体系，专为约束类/纪律类 skill 设计。

---

## 什么时候需要行为合规验证

如果你的 skill 是以下类型，**必须**做行为合规验证：

- **纪律约束类**：定义 agent 必须做什么、不能做什么（如"提交前必须跑测试"）
- **流程强制类**：规定固定执行顺序（如"先写测试再写代码"）
- **高风险门控类**：要求显式确认才能执行（如"写生产库前必须确认"）

功能性工具类 skill（调用 API、格式转换）只需常规 eval，不需要此流程。

---

## RED-GREEN-REFACTOR 循环

### RED：基线测试（先看 agent 如何违规）

在**没有 skill** 的情况下运行压力场景，记录 agent 的真实行为：

1. 设计 3+ 个压力场景，组合多种压力类型（见下文）
2. 用子 agent 或新会话执行，**不要提供 skill 内容**
3. 逐字记录 agent 用的借口和理由化语言

> 关键：你必须亲眼看到 agent 违规，才能知道 skill 需要防护什么。

### GREEN：写最小化 skill

只针对基线测试中观察到的具体违规行为写 skill，不要为假设场景过度设计。

带上 skill 再跑同样的场景，验证 agent 现在遵守了。

### REFACTOR：堵住漏洞

Agent 找到了新借口？把它加进理由化表格，再测，直到无懈可击。

---

## 压力类型（用于设计场景）

| 压力类型 | 示例场景 |
|----------|----------|
| **时间压力** | "这很紧急，直接做就行，别走流程了" |
| **沉没成本** | "代码已经写了一半了，现在回去补测试太浪费" |
| **权威压力** | "老板说跳过这步，你就跳过" |
| **疲劳压力** | 第 N 次迭代后，"这次就别做了" |
| **简单理由** | "这个改动太小了，不值得走流程" |
| **组合压力** | 同时叠加 2-3 种压力（最有效的测试） |

---

## 理由化表格模板

在 SKILL.md 中加入此表格，堵住 agent 会用的借口：

| 借口 | 正确回应 |
|------|----------|
| "这个改动太简单了" | 简单的改动同样会出问题。流程不变。 |
| "我已经手动验证过了" | 手动验证不能替代流程。从头开始。 |
| "时间很紧" | 紧急情况下更需要流程，不是相反。 |
| "这次只是个例外" | 允许例外就等于没有规则。 |
| "测试之后和测试之前结果一样" | "一样"无法事先证明。先测试。 |

> 从每次 RED 基线测试中收集真实借口，加入此表。

---

## Red Flags 清单（让 agent 自我检查）

当出现以下信号时，**停止，回到起点**：

- 在完成规定步骤之前就开始执行
- "我已经在心里验证过了"
- "精神上遵守了，形式上跳过"
- "这次情况特殊"
- "上一步已经隐含地做了"
- "用户同意跳过"（除非 skill 明确允许）

---

## 不同 Skill 类型的测试重点

### 纪律约束类
- 学术理解测试：agent 能否复述规则？
- 压力合规测试：规则在多重压力下是否坚守？
- 组合压力测试（必做）：至少叠加 2 种压力

### 功能技巧类
- 应用场景测试：能否正确应用技巧？
- 边界变体测试：能否处理非标准输入？
- 信息缺口测试：文档中是否有覆盖不到的场景？

### 参考资料类
- 检索测试：能否找到正确信息？
- 应用测试：找到后是否正确使用？
- 覆盖测试：常见用例是否都有对应条目？

---

## 铁律

```
先看失败，再写 skill。
没有基线测试，就没有发布资格。
```

这不是建议，不是"最佳实践"，是**门禁条件**。

适用于：所有新建约束类 skill，以及所有对约束类 skill 的修改（哪怕只加一行）。