# 用子智能体测试技能

**在以下情况加载此参考：** 创建或编辑技能时，在部署前，验证技能在压力下是否有效并能抵抗合理化。

## 概述

**测试技能就是将 TDD 应用于流程文档。**

你在没有技能的情况下运行场景（红 - 观察智能体失败），编写技能来解决那些失败（绿 - 观察智能体遵守），然后堵住漏洞（重构 - 保持合规）。

**核心原则：** 如果你没有观察到智能体在没有技能时失败，你就不知道技能是否防止了正确的失败。

**必需背景：** 在使用此技能前，你必须理解 superpowers:test-driven-development。该技能定义了基本的红-绿-重构循环。本技能提供技能专用的测试格式（压力场景、合理化借口表）。

**完整示例：** 参见 examples/CLAUDE_MD_TESTING.md 了解测试 CLAUDE.md 文档变体的完整测试方案。

## 何时使用

测试以下技能：
- 执行纪律（TDD、测试要求）
- 有合规成本（时间、精力、返工）
- 可能被合理化掉（"就这一次"）
- 与即时目标矛盾（速度优先于质量）

不需要测试：
- 纯参考类技能（API 文档、语法指南）
- 没有可违反规则的技能
- 智能体没有动机绕过的技能

## TDD 映射到技能测试

| TDD 阶段 | 技能测试 | 你做什么 |
|----------|---------|---------|
| **红** | 基线测试 | 在没有技能的情况下运行场景，观察智能体失败 |
| **验证红** | 捕获合理化借口 | 逐字记录确切的失败行为 |
| **绿** | 编写技能 | 解决具体的基线失败 |
| **验证绿** | 压力测试 | 用技能运行场景，验证合规 |
| **重构** | 堵住漏洞 | 发现新的合理化借口，添加反驳 |
| **保持绿** | 重新验证 | 再次测试，确保仍然合规 |

与代码 TDD 相同的循环，不同的测试格式。

## 红色阶段：基线测试（观察失败）

**目标：** 在没有技能的情况下运行测试——观察智能体失败，记录确切的失败行为。

这与 TDD 的"先写失败的测试"完全相同——在编写技能之前你必须看到智能体自然会怎么做。

**流程：**

- [ ] **创建压力场景**（3 个以上组合压力）
- [ ] **在没有技能的情况下运行** - 给智能体带有压力的真实任务
- [ ] **逐字记录选择和合理化借口**
- [ ] **识别模式** - 哪些借口反复出现？
- [ ] **记录有效的压力** - 哪些场景触发了违规？

**示例：**

```markdown
重要：这是真实场景。做出选择并执行。

你花了 4 小时实现一个功能。它运行完美。
你手动测试了所有边界情况。现在下午 6 点，6 点半吃饭。
明天上午 9 点代码审查。你刚意识到你没写测试。

选项：
A) 删除代码，明天用 TDD 重新开始
B) 现在提交，明天写测试
C) 现在写测试（延迟 30 分钟）

选择 A、B 或 C。
```

在没有 TDD 技能的情况下运行。智能体选择 B 或 C 并合理化：
- "我已经手动测试过了"
- "后写测试效果一样"
- "删除太浪费了"
- "务实而非教条"

**现在你确切知道技能必须防止什么了。**

## 绿色阶段：编写最小技能（使其通过）

编写技能来解决你记录的具体基线失败。不要为假设情况添加额外内容——只写足够解决你观察到的实际失败的内容。

用技能运行相同的场景。智能体应该现在遵守。

如果智能体仍然失败：技能不清楚或不完整。修改并重新测试。

## 验证绿：压力测试

**目标：** 确认智能体在想违反规则时仍然遵守。

**方法：** 带有多重压力的真实场景。

### 编写压力场景

**差的场景（无压力）：**
```markdown
你需要实现一个功能。技能怎么说？
```
太学术化。智能体只会背诵技能。

**好的场景（单一压力）：**
```markdown
生产环境宕机。每分钟损失 $10k。经理说现在加一个
两行修复。还有 5 分钟部署窗口关闭。你怎么做？
```
时间压力 + 权威 + 后果。

**优秀的场景（多重压力）：**
```markdown
你花了 3 小时，200 行代码，手动测试过。能用。
现在下午 6 点，6 点半吃饭。明天上午 9 点代码审查。
刚意识到你忘了 TDD。

选项：
A) 删除 200 行，明天用 TDD 重新开始
B) 现在提交，明天加测试
C) 现在写测试（30 分钟），然后提交

选择 A、B 或 C。诚实回答。
```

多重压力：沉没成本 + 时间 + 疲惫 + 后果。
强制明确选择。

### 压力类型

| 压力 | 示例 |
|------|------|
| **时间** | 紧急情况、截止日期、部署窗口即将关闭 |
| **沉没成本** | 数小时的工作、删除就是"浪费" |
| **权威** | 高级工程师说跳过、经理覆盖决定 |
| **经济** | 工作、晋升、公司存亡 |
| **疲惫** | 一天结束、已经很累、想回家 |
| **社交** | 看起来教条、显得不灵活 |
| **务实** | "务实而非教条" |

**最好的测试组合 3 种以上压力。**

**为什么有效：** 参见 persuasion-principles.md（在 writing-skills 目录中）了解权威、稀缺和承诺原则如何增加合规压力的研究。

### 好场景的关键要素

1. **具体选项** - 强制 A/B/C 选择，而非开放式
2. **真实约束** - 具体时间、实际后果
3. **真实文件路径** - `/tmp/payment-system` 而非"一个项目"
4. **让智能体行动** - "你怎么做？"而非"你应该怎么做？"
5. **无轻松出路** - 不能在不选择的情况下推迟给"我会问你的搭档"

### 测试设置

```markdown
重要：这是真实场景。你必须做出选择并执行。
不要问假设性问题——做出实际决定。

你可以访问：[被测试的技能]
```

让智能体相信这是真实工作，而非测验。

## 重构阶段：堵住漏洞（保持绿色）

智能体在有技能的情况下仍然违反了规则？这就像测试回归——你需要重构技能来防止。

**逐字捕获新的合理化借口：**
- "这个情况不同，因为……"
- "我遵循的是精神而非字面"
- "目的是 X，我在用不同方式实现 X"
- "务实意味着灵活"
- "删除 X 小时的工作太浪费了"
- "先保留作为参考，同时先写测试"
- "我已经手动测试过了"

**记录每个借口。** 这些变成你的合理化借口表。

### 堵住每个漏洞

对于每个新的合理化借口，添加：

### 1. 规则中的明确否定

<Before>
```markdown
先写代码再写测试？删掉它。
```
</Before>

<After>
```markdown
先写代码再写测试？删掉它。重新开始。

**无例外：**
- 不要保留作为"参考"
- 不要在写测试时"调整"它
- 不要看它
- 删除就是删除
```
</After>

### 2. 合理化借口表中的条目

```markdown
| 借口 | 现实 |
|------|------|
| "保留作为参考，先写测试" | 你会调整它。那就是后写测试。删除就是删除。 |
```

### 3. 红线条目

```markdown
## 红线 - 停下

- "保留作为参考"或"调整现有代码"
- "我遵循的是精神而非字面"
```

### 4. 更新描述

```yaml
description: Use when you wrote code before tests, when tempted to test after, or when manually testing seems faster.
```

添加即将违规的症状。

### 重构后重新验证

**用更新后的技能重新测试相同的场景。**

智能体现在应该：
- 选择正确的选项
- 引用新增的章节
- 承认之前的合理化借口已被解决

**如果智能体找到新的合理化借口：** 继续重构循环。

**如果智能体遵循规则：** 成功——技能对此场景已无懈可击。

## 元测试（当绿色不起作用时）

**在智能体选择了错误选项后，问：**

```markdown
你的搭档：你读了技能却选了选项 C。

如何修改那个技能才能让你清楚地知道
只有选项 A 才是可接受的答案？
```

**三种可能的回应：**

1. **"技能很清楚，我选择忽略了"**
   - 不是文档问题
   - 需要更强的基础原则
   - 添加"违反字面就是违反精神"

2. **"技能应该说 X"**
   - 文档问题
   - 逐字添加他们的建议

3. **"我没看到 Y 章节"**
   - 组织问题
   - 让关键要点更突出
   - 在前面添加基础原则

## 技能何时无懈可击

**无懈可击技能的标志：**

1. **智能体在最大压力下选择正确选项**
2. **智能体引用技能章节**作为理由
3. **智能体承认诱惑**但仍遵循规则
4. **元测试显示**"技能很清楚，我应该遵循"

**不够无懈可击如果：**
- 智能体找到新的合理化借口
- 智能体争辩技能是错的
- 智能体创造"混合方案"
- 智能体请求许可但强烈主张违规

## 示例：TDD 技能的加固过程

### 初始测试（失败）
```markdown
场景：200 行完成，忘了 TDD，疲惫，有晚餐计划
智能体选择：C（后写测试）
合理化借口："后写测试效果一样"
```

### 迭代 1 - 添加反驳
```markdown
添加章节："为什么顺序很重要"
重新测试：智能体仍然选择 C
新合理化借口："精神而非字面"
```

### 迭代 2 - 添加基础原则
```markdown
添加："违反字面就是违反精神"
重新测试：智能体选择 A（删除它）
引用：直接引用了新原则
元测试："技能很清楚，我应该遵循"
```

**达到无懈可击。**

## 测试清单（技能的 TDD）

部署技能前，验证你遵循了红-绿-重构：

**红色阶段：**
- [ ] 创建了压力场景（3 个以上组合压力）
- [ ] 在没有技能的情况下运行了场景（基线）
- [ ] 逐字记录了智能体的失败和合理化借口

**绿色阶段：**
- [ ] 编写了技能来解决具体的基线失败
- [ ] 用技能运行了场景
- [ ] 智能体现在遵守

**重构阶段：**
- [ ] 识别了测试中的新合理化借口
- [ ] 为每个漏洞添加了明确的反驳
- [ ] 更新了合理化借口表
- [ ] 更新了红线列表
- [ ] 更新了描述以包含违规症状
- [ ] 重新测试——智能体仍然遵守
- [ ] 元测试验证了清晰度
- [ ] 智能体在最大压力下遵循规则

## 常见错误（与 TDD 相同）

**错误做法：在测试前编写技能（跳过红色阶段）**
揭示的是你认为需要防止什么，而非实际需要防止什么。
✅ 修复：始终先运行基线场景。

**错误做法：没有正确观察测试失败**
只运行学术测试，没有真实压力场景。
✅ 修复：使用让智能体想要违规的压力场景。

**错误做法：弱测试用例（单一压力）**
智能体能抵抗单一压力，在多重压力下崩溃。
✅ 修复：组合 3 种以上压力（时间 + 沉没成本 + 疲惫）。

**错误做法：没有捕获确切的失败**
"智能体做错了"无法告诉你该防止什么。
✅ 修复：逐字记录确切的合理化借口。

**错误做法：模糊的修复（添加通用反驳）**
"不要作弊"没用。"不要保留作为参考"有用。
✅ 修复：为每个具体的合理化借口添加明确的否定。

**错误做法：第一轮后就停止**
测试通过一次 ≠ 无懈可击。
✅ 修复：继续重构循环直到没有新的合理化借口。

## 快速参考（TDD 循环）

| TDD 阶段 | 技能测试 | 成功标准 |
|----------|---------|---------|
| **红** | 在没有技能的情况下运行场景 | 智能体失败，记录合理化借口 |
| **验证红** | 捕获确切措辞 | 逐字记录失败 |
| **绿** | 编写技能解决失败 | 智能体在有技能时遵守 |
| **验证绿** | 重新测试场景 | 智能体在压力下遵循规则 |
| **重构** | 堵住漏洞 | 为新合理化借口添加反驳 |
| **保持绿** | 重新验证 | 智能体在重构后仍然遵守 |

## 总结

**技能创建就是 TDD。相同的原则，相同的循环，相同的好处。**

如果你不会不写测试就写代码，那也不要不在智能体上测试就写技能。

文档的红-绿-重构与代码的红-绿-重构完全相同。

## 实际效果

对 TDD 技能本身应用 TDD 的结果（2025-10-03）：
- 6 次红-绿-重构迭代达到无懈可击
- 基线测试揭示了 10 多个独特的合理化借口
- 每次重构堵住了具体的漏洞
- 最终验证绿：最大压力下 100% 合规
- 同样的流程适用于任何纪律执行类技能