Domů Procházet Nápověda
Přihlásit se
WangKang
/
okr-performance
1
0
Rozštěpit 0
Soubory Úkoly 0 Pull Requesty 0 Wiki
Strom: e888d29550
Větve Značky
okr-performance
/
.claude
/
skills
/
writing-skills
/
testing-skills-with-subagents.md

testing-skills-with-subagents.md 12 KB
Historie Surový

用子智能体测试技能

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

概述

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

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

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

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

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

何时使用

测试以下技能：

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

不需要测试：

  • 纯参考类技能（API 文档、语法指南）
  • 没有可违反规则的技能
  • 智能体没有动机绕过的技能

TDD 映射到技能测试

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

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

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

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

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

流程：

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

示例：

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

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

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

选择 A、B 或 C。

在没有 TDD 技能的情况下运行。智能体选择 B 或 C 并合理化：

  • "我已经手动测试过了"
  • "后写测试效果一样"
  • "删除太浪费了"
  • "务实而非教条"

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

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

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

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

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

验证绿：压力测试

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

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

编写压力场景

差的场景（无压力）：

你需要实现一个功能。技能怎么说？

太学术化。智能体只会背诵技能。

好的场景（单一压力）：

生产环境宕机。每分钟损失 $10k。经理说现在加一个
两行修复。还有 5 分钟部署窗口关闭。你怎么做？

时间压力 + 权威 + 后果。

优秀的场景（多重压力）：

你花了 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. 无轻松出路 - 不能在不选择的情况下推迟给"我会问你的搭档"

测试设置

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

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

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

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

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

逐字捕获新的合理化借口：

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

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

堵住每个漏洞

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

1. 规则中的明确否定

先写代码再写测试？删掉它。


先写代码再写测试？删掉它。重新开始。

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

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

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

3. 红线条目

## 红线 - 停下

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

4. 更新描述

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

添加即将违规的症状。

重构后重新验证

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

智能体现在应该：

  • 选择正确的选项
  • 引用新增的章节
  • 承认之前的合理化借口已被解决

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

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

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

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

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

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

三种可能的回应：

  1. "技能很清楚，我选择忽略了"

    • 不是文档问题
    • 需要更强的基础原则
    • 添加"违反字面就是违反精神"

  2. "技能应该说 X"

    • 文档问题
    • 逐字添加他们的建议

  3. "我没看到 Y 章节"

    • 组织问题
    • 让关键要点更突出
    • 在前面添加基础原则

技能何时无懈可击

无懈可击技能的标志：

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

不够无懈可击如果：

  • 智能体找到新的合理化借口
  • 智能体争辩技能是错的
  • 智能体创造"混合方案"
  • 智能体请求许可但强烈主张违规

示例：TDD 技能的加固过程

初始测试（失败）

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

迭代 1 - 添加反驳

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

迭代 2 - 添加基础原则

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

达到无懈可击。

测试清单（技能的 TDD）

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

红色阶段：

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

绿色阶段：

  • 编写了技能来解决具体的基线失败
  • 用技能运行了场景
  • 智能体现在遵守

重构阶段：

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

常见错误（与 TDD 相同）

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

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

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

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

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

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

快速参考（TDD 循环）

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

总结

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

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

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

实际效果

对 TDD 技能本身应用 TDD 的结果（2025-10-03）：

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