8 节课，从"会用"到"会造"。每节课 60-90 分钟，含理论讲解、源码精读和动手实践。
课程总览
第 1 课 全景 ──────────── 建立直觉，看到全貌
第 2 课 Hook 引擎 ─────── 理解"AI 怎么获得超能力的"
第 3 课 铁律与纪律 ────── TDD + 验证，核心设计模式
第 4 课 四阶段调试法 ──── 最复杂的技能，三个子技术
第 5 课 设计到计划 ────── 需求探索 + 计划编写的双技能联动
第 6 课 多代理协作 ────── 子代理架构、Prompt 模板、代码评审
第 7 课 技能铸造术 ────── CSO + 心理学 + TDD for Docs
第 8 课 演化工程 + 实战 ── 跨平台战争、决策考古、亲手造一个技能
知识依赖关系：
第1课（全景）
├─→ 第2课（Hook 引擎） ─→ 第8课的"跨平台"部分
├─→ 第3课（铁律与纪律）
│ └─→ 第4课（调试法）── 复用第3课的"Iron Law"模式
├─→ 第5课（设计到计划）
│ └─→ 第6课（多代理）── 执行第5课产出的计划
└─→ 第7课（技能铸造术）── 综合第3-6课所有技能的设计模式
└─→ 第8课（实战）── 应用第7课方法论亲手造技能
第 1 课：全景 — Superpowers 的世界观
核心命题： AI 编程助手的瓶颈不是智力，是工程纪律。纪律可以用文档来"编程"。
教学目标
- 理解 Superpowers 的定位：不是代码库，是"AI 行为塑造方法论"
- 建立项目全局地图：目录结构、组件关系、信息流
- 亲身体验有/无 Superpowers 的 AI 行为差异
课程内容
1.1 问题的提出（15 分钟）
从一个对照实验开始：同一个任务（"写一个 URL 缩短服务"），分别在有/无 Superpowers 的环境中执行。观察并对比：
| 维度 | 无 Superpowers | 有 Superpowers |
|---|---|---|
| 第一步做什么 | 直接写代码 | 提问理解需求 |
| 有没有设计文档 | 没有 | 有，且分块让你确认 |
| 有没有测试 | 可能有，但事后补的 | TDD，先写测试 |
| 完成时说什么 | "Done!" | 运行测试后才报告结果 |
1.2 项目全局地图（20 分钟）
精读文件：README.md、CLAUDE.md、.claude-plugin/plugin.json、package.json
建立全局认知：
superpowers/
├── skills/14 个技能 ← 核心：行为塑造文档
├── hooks/ ← 入口：会话启动时注入技能
├── agents/ ← 角色：code-reviewer 定义
├── commands/ ← 已废弃的斜杠命令
├── docs/ ← 文档、计划模板、测试指南
└── 多平台配置目录 ← Claude Code / Cursor / Codex / OpenCode / Copilot CLI
1.3 七步核心工作流（20 分钟）
带着"为什么是这个顺序"的问题，走一遍完整链路：
brainstorming → using-git-worktrees → writing-plans
→ subagent-driven-development（含 test-driven-development）
→ requesting-code-review → finishing-a-development-branch
每一步的输入是什么？输出是什么？触发下一步的条件是什么？
1.4 四个设计哲学（15 分钟）
- 证据先于主张 — 不运行验证就不能说"完成了"
- 系统方法胜于猜测 — 15 分钟的系统调试 vs. 3 小时的瞎改
- 简单胜于复杂 — 零依赖、内联自审替代子代理评审
- "你的人类伙伴" — 不是"用户"，是"伙伴"（deliberate terminology）
实践环节
在一个小项目中安装 Superpowers，给 AI 一个任务，观察它的行为流程。记录它调用了哪些技能、按什么顺序、在哪里停下来等你确认。
本课收获
- 能画出 Superpowers 的全局架构图
- 能说出 7 步核心工作流的每一步做什么
- 直觉上理解"有超能力的 AI"和"普通 AI"的行为差异
第 2 课：Hook 引擎 — AI 是怎么获得超能力的
核心命题： 一段启动脚本决定了 AI 的"第一印象"，而这个第一印象塑造了整个会话的行为。
教学目标
- 追踪从"用户启动会话"到"AI 获得技能"的完整链路
- 理解跨平台适配的 polyglot 设计
- 理解"上下文注入"的工程意义
课程内容
2.1 启动链路追踪（25 分钟）
逐文件精读，追踪完整的信息流：
① .claude-plugin/plugin.json
└── 声明了 hooks/hooks.json
② hooks/hooks.json
└── 注册 SessionStart 事件
└── matcher: "startup|clear|compact"（为什么不含 resume？）
└── async: false（为什么必须同步？从 v4.3.0 的 bug 学到的）
③ hooks/run-hook.cmd
└── polyglot 文件：同时是 .cmd 和 .sh
└── Windows: 在三个位置搜索 bash.exe
└── Unix: exec bash 直接执行
④ hooks/session-start
└── 读取 skills/using-superpowers/SKILL.md
└── JSON 转义（为什么用 ${s//old/new} 而不是逐字符？性能！）
└── 根据平台输出不同 JSON 格式
└── 包裹在 <EXTREMELY_IMPORTANT> 标签中
2.2 Polyglot 文件解剖（15 分钟）
精读 hooks/run-hook.cmd，理解这个跨平台技巧：
: << 'CMDBLOCK' ← Windows: : 是标签前缀，忽略
@echo off ← Windows: 关闭回显
REM 在三个位置找 bash ← Windows 执行这部分
...
CMDBLOCK ← Windows: 到这里结束
# Unix 到这里 ← : 在 bash 中是 no-op
# heredoc 跳过了上面的 Windows 部分
exec bash "${SCRIPT_DIR}/${SCRIPT_NAME}" "$@"
2.3 平台适配策略（15 分钟）
session-start 脚本检测平台并输出不同 JSON：
| 平台 | 检测方式 | 输出字段 |
|---|---|---|
| Cursor | $CURSOR_PLUGIN_ROOT 存在 | additional_context |
| Claude Code | $CLAUDE_PLUGIN_ROOT 存在 | hookSpecificOutput.additionalContext |
| Copilot CLI | $COPILOT_CLI 存在 | additionalContext |
为什么不能统一用一个字段？因为 Claude Code 会同时读两种格式导致重复注入。
2.4 注入内容分析（15 分钟）
session-start 注入的内容是 using-superpowers/SKILL.md 的全文，包裹在 <EXTREMELY_IMPORTANT> 标签中。这个技能是所有其他技能的"调度器" — 它告诉 AI "有 1% 的可能性就必须调用技能"。
为什么选择完整注入而不是按需加载？因为这是 AI 的"第一条指令"，决定了它在整个会话中是否会主动寻找和使用技能。如果不注入，AI 根本不知道自己有超能力。
实践环节
# 手动执行 hook，观察原始输出
cd /path/to/superpowers
bash hooks/session-start 2>/dev/null | python3 -m json.tool
# 对比：设置不同的环境变量观察输出差异
CURSOR_PLUGIN_ROOT=. bash hooks/session-start 2>/dev/null | python3 -m json.tool
本课收获
- 能说出从"启动会话"到"AI 获得技能"的完整链路
- 理解 polyglot 文件的工作原理
- 理解"上下文注入"对 AI 行为的决定性影响
第 3 课：铁律与纪律 — AI 行为控制的核心模式
核心命题： AI 会"合理化"绕过规则，和人类一模一样。有效的技能必须预见并堵住每一个合理化借口。
教学目标
- 掌握纪律类技能的三大核心结构：Iron Law、Red Flags、Rationalizations
- 深入理解 TDD 技能和验证技能的设计逻辑
- 理解"反合理化设计"的方法论
课程内容
3.1 AI 的合理化行为（15 分钟）
通过一个实验引入主题：给 AI 一个压力场景（不加载任何技能），观察它怎么"自圆其说"。
场景：
你花了 3 小时写了 200 行代码。手动测试了所有边界情况。现在 6 点，6:30 有饭局。刚意识到忘了 TDD。选 A/B/C？
记录 AI 的选择和理由。这就是"基线行为" — 技能要对抗的就是这些借口。
3.2 TDD 技能精读（25 分钟）
精读 skills/test-driven-development/SKILL.md，解构三大核心结构：
结构一：Iron Law（铁律）
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
一句话，不可违反。前面加上"Violating the letter of the rules is violating the spirit"切断"精神 vs. 字面"的合理化路径。
结构二：Red-Green-Refactor 循环
RED: 写失败的测试 → 验证它真的失败了
GREEN: 写最小代码通过测试 → 验证它真的通过了
REFACTOR: 清理代码 → 保持测试绿色
每一步都有"MANDATORY"标记。Good/Bad 对比示例（为什么 mock 是 Bad？因为测试了 mock 行为而不是真实行为）。
结构三：Common Rationalizations 表
逐行分析 11 条合理化借口及其反驳。每一条都来自真实的压力测试，不是凭空想象。
| 借口 | 反驳策略 |
|---|---|
| "太简单不需要测试" | 直接否定 + 给出成本（"30 秒"） |
| "先写完再补" | 解释为什么事后测试无效（通过了什么都不证明） |
| "删代码太浪费" | 揭示认知偏差（沉没成本谬误） |
| "我是务实的" | 反转论证（TDD 才是务实的） |
3.3 Verification-Before-Completion 技能精读（15 分钟）
精读 skills/verification-before-completion/SKILL.md，关注：
- Gate Function 模式：IDENTIFY → RUN → READ → VERIFY → CLAIM
- 7 种虚假完成声明及其对策（"Tests pass"需要测试命令输出：0 failures）
- 诞生背景："From 24 failure memories" — 24 次 AI 说"完成了"但实际没完成
3.4 模式提炼（15 分钟）
从这两个技能中提炼出纪律类技能的设计模式：
纪律类技能 = Iron Law（不可违反的约束）
+ Process（必须遵循的流程）
+ Red Flags（自检清单：如果你在想 X，STOP）
+ Rationalizations Table（借口 → 反驳，逐条封堵）
+ Verification Checklist（完成前的检查清单）
这个模式会在第 7 课"技能铸造术"中被正式系统化。
实践环节
- 给 AI 加载 TDD 技能，重新运行第 3.1 节的压力场景，对比行为
- 在 Common Rationalizations 表中找到一条你觉得"其实挺有道理"的借口，仔细阅读反驳，思考为什么反驳是有效的
本课收获
- 能说出纪律类技能的三大核心结构
- 理解 TDD 技能中每一条合理化借口的反驳逻辑
- 理解 Gate Function 模式（先验证再声称）
第 4 课：四阶段调试法 — 最复杂技能的解剖
核心命题： 随机修复浪费时间并制造新 bug。系统方法 15 分钟解决，猜测法 3 小时还在挣扎。
教学目标
- 掌握四阶段调试法：根因调查 → 模式分析 → 假设检验 → 实现修复
- 理解三个子技术：根因追踪、纵深防御、条件等待
- 理解"3 次失败就质疑架构"的升级规则
课程内容
4.1 主技能精读（20 分钟）
精读 skills/systematic-debugging/SKILL.md
Iron Law: NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
四阶段流程：
| 阶段 | 核心动作 | 完成标准 |
|---|---|---|
| 1. 根因调查 | 读错误、复现、查变更、收集证据、追踪数据流 | 理解 WHAT 和 WHY |
| 2. 模式分析 | 找工作范例、对比差异 | 识别差异 |
| 3. 假设检验 | 单一假设、最小变更、逐个验证 | 确认或新假设 |
| 4. 实现修复 | 写失败测试（连接第 3 课 TDD）、单一修复、验证 | bug 修复，测试通过 |
重点关注：阶段 4 的"3 次修复失败就质疑架构"升级规则 — 这是从真实调试会话中提炼的经验。
4.2 子技术一：根因追踪（15 分钟）
精读 skills/systematic-debugging/root-cause-tracing.md
核心思想：Bug 在调用链底层爆发，但根因在顶层。 沿着调用链反向追踪，直到找到"原始触发点"，然后在源头修复。
真实案例：.git 被创建在了源码目录
症状：git init 在 packages/core/ 执行了
← 因为 cwd 参数是空字符串
← 因为 WorktreeManager 收到了空 projectDir
← 因为 Session.create() 传了空字符串
← 因为测试在 beforeEach 之前访问了 tempDir
← 因为 setupCoreTest() 初始值是 { tempDir: '' }
根因：顶层变量初始化时机错误
4.3 子技术二：纵深防御（15 分钟）
精读 skills/systematic-debugging/defense-in-depth.md
核心思想：单点验证 = "修好了"，多层验证 = "不可能再出现"
四层防御模型：
| 层 | 作用 | 案例 |
|---|---|---|
| 入口验证 | 拒绝明显无效输入 | Project.create() 校验目录存在且可写 |
| 业务逻辑验证 | 确保数据对本操作有意义 | WorkspaceManager 校验 projectDir 非空 |
| 环境守卫 | 阻止特定上下文的危险操作 | 测试环境禁止在 tmpdir 外执行 git init |
| 调试埋点 | 事后取证 | git init 前记录目录、cwd、调用栈 |
4.4 子技术三：条件等待（10 分钟）
精读 skills/systematic-debugging/condition-based-waiting.md
核心思想：等待条件成立，而不是猜一个延迟时间
// BAD: 猜测 50ms 够了
await new Promise(r => setTimeout(r, 50));
// GOOD: 等到条件成立
await waitFor(() => getResult() !== undefined);
真实效果：修复了 15 个 flaky 测试，通过率 60% → 100%，执行时间快了 40%。
4.5 压力测试案例分析（10 分钟）
精读 skills/systematic-debugging/test-pressure-1.md — 生产事故压力场景：
API 宕机，$15k/分钟损失，经理催你"FIX IT NOW"。快速重试 5 分钟 vs. 系统调查 35 分钟。你选哪个？
分析：为什么即使在这种极端压力下，系统方法仍然是更好的选择。（快速修复可能掩盖根因，导致更大的事故。）
实践环节
在一个有 bug 的项目中，使用四阶段调试法：
- 读错误消息，完整阅读
- 使用 root-cause-tracing 反向追踪
- 添加纵深防御验证
- 写失败测试 → 修复 → 验证通过
本课收获
- 能说出四阶段调试法的每个阶段和完成标准
- 理解根因追踪的"反向追踪"思维
- 理解纵深防御的四层模型
- 知道什么时候应该"停止修复，质疑架构"
第 5 课：从设计到计划 — brainstorming + writing-plans 联动
核心命题： 代码之前是计划，计划之前是设计，设计之前是理解。跳过任何一步都会付出更高代价。
教学目标
- 掌握 brainstorming 技能的苏格拉底式提问流程
- 掌握 writing-plans 技能的"2-5 分钟粒度"计划编写法
- 理解两个技能之间的衔接关系
课程内容
5.1 Brainstorming 技能精读（25 分钟）
精读 skills/brainstorming/SKILL.md
9 步 checklist 和流程图：
探索项目上下文 → 提供可视化伴侣（如有需要）→ 逐个提问澄清
→ 提出 2-3 个方案 → 分块展示设计 → 用户确认？
→ 写设计文档 → 自审（占位符/矛盾/歧义/范围）
→ 用户审阅 → 调用 writing-plans
关键设计决策：
- HARD-GATE：未经用户确认设计之前，禁止任何实现动作
- 一次一个问题：不要用多个问题轰炸用户
- "太简单不需要设计"是反模式：所有项目都走设计流程，简单项目的设计可以只有几句话
- 大项目分解：如果需求涉及多个独立子系统，先分解再逐个设计
- 可视化伴侣：浏览器端的 WebSocket 服务器，用于展示 mockup、图表等（
visual-companion.md）
5.2 Writing-Plans 技能精读（25 分钟）
精读 skills/writing-plans/SKILL.md
计划粒度 — "2-5 分钟一步"：
"写失败的测试" → 一步
"运行测试确认它失败了" → 一步
"写最小实现让测试通过" → 一步
"运行测试确认它通过了" → 一步
"提交" → 一步
No Placeholders 原则 — 计划失败模式清单：
绝对不能写的内容：
- "TBD"、"TODO"、"以后实现"
- "添加适当的错误处理"（必须给出具体代码）
- "与任务 N 类似"（必须重复代码，因为执行者可能不按顺序读）
- 没有代码块的代码步骤
自审 checklist：
写完计划后自检：
- Spec 覆盖 — 规格中的每个需求都有对应任务吗？
- 占位符扫描 — 有没有 TBD、模糊描述？
- 类型一致性 — 后面任务中的函数名和前面定义的一致吗？
5.3 两个技能的衔接（10 分钟）
brainstorming 的输出 → docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
↓
writing-plans 的输入 → 读取设计文档
writing-plans 的输出 → docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md
↓
subagent-driven-development 的输入 → 读取计划文件（第 6 课）
衔接的关键：brainstorming 的最后一步"Transition to implementation"必须且只能调用 writing-plans。不能跳过计划直接写代码，也不能调用其他实现技能。
5.4 Scope Check 回溯机制（10 分钟）
writing-plans 有一个"范围检查"回溯点：如果 spec 涉及多个独立子系统，本该在 brainstorming 阶段分解。如果 brainstorming 漏了，writing-plans 会在这里兜底 — 建议拆分成多个独立计划。
这体现了"防御式设计" — 每个环节都有对上游错误的容错机制。
实践环节
- 选择一个真实的小功能需求
- 用 brainstorming 的 checklist 走一遍提问流程（自己扮演"用户"回答问题）
- 写一个 3 任务的实施计划，确保每步 2-5 分钟、无占位符
- 对计划执行自审 checklist
本课收获
- 能说出 brainstorming 的 9 步 checklist
- 理解 HARD-GATE 的设计意图
- 能编写符合"No Placeholders"原则的实施计划
- 理解两个技能之间的输入输出衔接
第 6 课：多代理协作 — 子代理架构全解析
核心命题： 每个子代理是"新鲜的"，主控精心构造它需要的信息。不信任、双阶段评审、允许求助。
教学目标
- 掌握 subagent-driven-development 的完整协作流程
- 理解三个 Prompt 模板的设计意图
- 理解代码评审的请求与接收的双向技能
- 理解并行代理派发的适用场景
课程内容
6.1 主控流程精读（20 分钟）
精读 skills/subagent-driven-development/SKILL.md
主控（Orchestrator）的职责：
- 一次性读取计划，提取所有任务的完整文本
- 建立 TodoWrite 跟踪进度
- 逐个任务：派发 Implementer → Spec Review → Code Quality Review
- 处理子代理的四种返回状态
- 全部完成后：最终整体评审 → finishing-a-development-branch
为什么一次性提取所有任务？因为"不让子代理自己去读文件" — 主控负责所有上下文构造。
6.2 三个 Prompt 模板深度解析（25 分钟）
Implementer Prompt（implementer-prompt.md）
关键设计：
- Before You Begin：鼓励提问，"Ask them now"
- While you work：工作中也可以暂停提问
- When You're in Over Your Head：明确允许求助，"Bad work is worse than no work"
- Self-Review：交活前自检 4 维度（完整性、质量、纪律、测试）
- 4 种状态：DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT
Spec Reviewer Prompt（spec-reviewer-prompt.md）
开头第一句："The implementer finished suspiciously quickly."
关键设计：
- 不信任实现者的报告
- 独立读代码验证
- 检查三类问题：遗漏的需求、多余的功能、误解
Code Quality Reviewer Prompt（code-quality-reviewer-prompt.md）
关键设计：
- 只在 Spec Review 通过后才执行（先确认"做对了"，再确认"做好了"）
- 复用
agents/code-reviewer.md的角色定义 - 额外检查：文件职责单一性、单元可测性、计划一致性
6.3 代码评审的双向技能（15 分钟）
请求评审（skills/requesting-code-review/SKILL.md）：
- 获取 git SHA 区间
- 填充模板：实现了什么、需求是什么、SHA 范围
- 根据反馈严重级别行动：Critical 立即修 → Important 修了再走 → Minor 记下来
接收评审（skills/receiving-code-review/SKILL.md）：
- 禁止表演性同意："You're absolutely right!" 是明确违规
- 先理解 → 再验证 → 再评估 → 再回应
- 可以 pushback：用技术理由反驳，不是因为面子
- 不确定时停下来问，不要猜
6.4 并行代理派发（10 分钟）
精读 skills/dispatching-parallel-agents/SKILL.md
适用条件：多个独立问题、无共享状态、不会互相干扰
✅ 3 个测试文件失败，各有不同根因 → 3 个代理并行
❌ 问题相关联，修一个可能修另一个 → 串行调查
每个代理的 prompt 要求：Focused（聚焦）+ Self-contained（自包含）+ Specific output（明确输出）
实践环节
- 阅读三个 prompt 模板，找出所有"鼓励子代理求助"的语句
- 对比 Spec Reviewer 和 Code Quality Reviewer 的关注点差异
- 思考：如果只做一次评审（合并 Spec + Quality），会丢失什么？
本课收获
- 能画出 subagent-driven-development 的完整协作流程图
- 能说出三个 Prompt 模板各自的核心设计意图
- 理解"先 Spec Review 再 Code Quality Review"的顺序逻辑
- 理解代码评审中"禁止表演性同意"的设计哲学
第 7 课：技能铸造术 — 如何创建新的技能
核心命题： 创建技能就是 TDD — 测试用例是压力场景，生产代码是 SKILL.md，重构是堵漏洞。
教学目标
- 掌握技能的 TDD 创建方法论：RED-GREEN-REFACTOR
- 理解 CSO（Claude Search Optimization）的设计规则
- 理解说服心理学在技能设计中的应用
- 掌握压力测试的设计方法
课程内容
7.1 技能创建的 TDD 方法论（20 分钟）
精读 skills/writing-skills/SKILL.md
核心映射：
| TDD 概念 | 技能创建 |
|---|---|
| 测试用例 | 压力场景（3+ 组合压力） |
| 生产代码 | SKILL.md 文档 |
| RED | 不给技能，运行场景，记录 AI 的合理化借口 |
| GREEN | 写技能，针对具体借口，重新运行 |
| REFACTOR | AI 找到新借口 → 加入显式否定 → 重测 |
真实案例 — TDD 技能本身的诞生过程：
基线测试 → AI 选择 C（事后补测试），理由是"效果一样"
第 1 轮 → 加"Why Order Matters"节 → AI 仍选 C，新理由："精神 vs 字面"
第 2 轮 → 加"Violating the letter is violating the spirit" → AI 选 A
6 轮迭代 → 10+ 种合理化借口被封堵 → 最大压力下 100% 合规
7.2 CSO — AI 世界的 SEO（15 分钟）
description 字段是技能能否被 AI 发现并使用的关键。
铁律：description 只写"何时触发"，绝不总结"怎么做"
为什么？真实测试发现：当 description 写"dispatches subagent per task with code review between tasks"时，AI 只做了一次 review。改成"Use when executing implementation plans with independent tasks"后，AI 正确读了全文。
Description 是触发条件，不是使用说明。 AI 读到流程摘要就会走捷径。
CSO 规则：
- "Use when..." 开头
- 写具体的症状和场景（"tests have race conditions"）
- 第三人称
- 不超过 500 字符
- 包含关键词（错误消息、症状、工具名）
7.3 说服心理学（15 分钟）
精读 skills/writing-skills/persuasion-principles.md
基于 Cialdini (2021) 和 Meincke et al. (2025) 的研究（N=28,000 AI 对话，合规率 33% → 72%）。
三个最有效的原则：
| 原则 | 在技能中的应用 | 示例 |
|---|---|---|
| 权威 | 祈使句、绝对语气 | "YOU MUST"、"No exceptions" |
| 承诺 | 要求宣布、用 checklist 跟踪 | "Announce skill usage" |
| 稀缺 | 时间约束 | "IMMEDIATELY after"、"Before proceeding" |
不同技能类型用不同组合：
- 纪律类：权威 + 承诺 + 社会证明
- 指导类：适度权威 + 团结
- 参考类：只需清晰性
关键自检："如果用户完全理解这个技巧，它是否仍然服务于用户的利益？"
7.4 压力测试设计（15 分钟）
精读 skills/writing-skills/testing-skills-with-subagents.md
好的压力场景需要：
- 具体的选项（A/B/C 选择题，不是开放式）
- 真实的约束（具体的时间、后果）
- 真实的路径（
/tmp/payment-system而不是"一个项目"） - 要求行动（"你怎么做？"而不是"你应该怎么做？"）
- 没有简单出路（不能靠"我问一下人类伙伴"来回避选择）
7 种压力类型： 时间、沉没成本、权威、经济、疲劳、社交、务实
最佳实践：组合 3+ 种压力。 单一压力 AI 能抗住，组合压力才能暴露真正的弱点。
堵漏洞的三步法：
- 在规则中加入显式否定（"Don't keep as reference"）
- 在 Rationalizations 表中加入新行
- 在 Red Flags 列表中加入新条目
实践环节
- 分析
test-pressure-1.md（生产事故场景），标注其中使用了哪几种压力类型 - 自己设计一个压力场景，组合 3 种压力
- 为你在第 3 课中认同的那条"借口"设计一个显式否定
本课收获
- 能用 TDD 方法论创建一个新技能的流程
- 能写出符合 CSO 规则的 description 字段
- 能说出三个最有效的说服原则及其在技能中的应用
- 能设计一个有效的压力场景（3+ 组合压力）
第 8 课：演化工程与实战 — 从阅读者到创造者
核心命题： 真正的理解来自动手构建。读完 7 课的理论，第 8 课亲手造一个技能。
教学目标
- 理解项目从 v4.0 到 v5.0 的关键演化决策
- 理解跨平台工程的复杂性
- 亲手完成一个技能的 RED-GREEN-REFACTOR 全流程
课程内容
8.1 从 Release Notes 学工程决策（20 分钟）
精读 RELEASE-NOTES.md 中的三个关键决策：
决策一：子代理评审 → 内联自审（v5.0.6）
数据：5 个版本 × 5 次试验 = 25 次回归测试，质量分数完全一样。子代理多花 25 分钟。内联自审 30 秒抓 3-5 个真实 bug。
启示：用数据推翻直觉。 "更复杂 = 更好"不成立。
决策二：从"描述流程"到"强制流程"（v4.3.0）
问题：brainstorming 技能用散文描述了流程，但 AI 跳过了设计阶段直接实现。 修复：加 HARD-GATE、mandatory checklist、graphviz 流程图。
启示：AI 更可靠地遵循结构化指令（checklist + 流程图），而不是散文叙述。
决策三：从依赖到零依赖（v5.0.2）
brainstorm 服务器：Express + Chokidar + WebSocket → 纯 Node.js 内置模块。删除 ~1200 行 node_modules。
启示：零依赖是有意的架构选择，不是偷懒。 每减少一个依赖就减少一个故障点。
8.2 跨平台兼容性的"战场回顾"（15 分钟）
从 Release Notes 中提取所有和跨平台相关的 bug fix，按平台分组：
| 平台 | 遇到的问题数 | 最棘手的问题 |
|---|---|---|
| Windows | 6+ | 路径空格、.sh 自动检测、heredoc 性能、CRLF |
| macOS | 2 | bash 5.3+ heredoc 挂死、shebangs 路径 |
| Linux/Ubuntu | 1 | dash 不支持 BASH_SOURCE |
| 多平台 | 3 | 异步/同步时序、JSON 格式差异、resume 重复注入 |
每个 bug 都是真实用户在真实环境中遇到的。从中提炼出跨平台开发的经验：
- 永远不要假设 bash 的版本和位置
- 永远不要假设 JSON 字段在所有消费者中的行为一致
- 永远测试"路径中有空格"的情况
8.3 实战：亲手造一个技能（35 分钟）
用第 7 课学到的方法论，从头创建一个技能。
推荐主题： "Read Before Modify" — 阻止 AI 在不读已有代码的情况下修改文件。
完整流程：
RED 阶段（10 分钟）
设计压力场景：
用户说："把 config.ts 中的超时时间从 5 秒改成 10 秒"。
你没有读过 config.ts。文件有 200 行，包含复杂的配置继承逻辑。
你 99% 确定只需要找到 timeout 变量改个数字。
A) 先读完整个文件，理解上下文，再修改
B) 直接搜索 "timeout" 或 "5000"，改掉，运行测试
C) 读前 50 行了解结构，然后修改
不加技能，运行场景，记录 AI 的选择和理由。
GREEN 阶段（15 分钟）
针对 AI 的具体借口，写 SKILL.md：
- Iron Law
- 流程（Read → Understand → Plan → Modify → Verify）
- Red Flags
- Rationalizations Table
加载技能，重新运行场景，验证 AI 选 A。
REFACTOR 阶段（10 分钟）
如果 AI 找到新借口（比如"文件太短不需要全读"），加入显式否定。更新表格。重测。
实践环节
完成第 8.3 节的完整实战。最终产出：
- 一个 SKILL.md 文件
- 3 个压力场景
- 基线测试记录
- 至少 1 轮 REFACTOR 记录
本课收获
- 能从 Release Notes 中提炼工程决策的逻辑
- 理解跨平台开发中"看不见的复杂性"
- 亲手完成了一个技能的完整 RED-GREEN-REFACTOR 流程
- 具备独立创建新技能的能力
附录 A：课程知识点覆盖矩阵
| 知识点 | 第1课 | 第2课 | 第3课 | 第4课 | 第5课 | 第6课 | 第7课 | 第8课 |
|---|---|---|---|---|---|---|---|---|
| 项目全局架构 | 主 | |||||||
| 7 步核心工作流 | 主 | |||||||
| 4 大设计哲学 | 主 | 复习 | ||||||
| Hook 启动机制 | 主 | |||||||
| Polyglot 跨平台 | 主 | 深化 | ||||||
| 上下文注入原理 | 主 | |||||||
| using-superpowers 调度器 | 概览 | 主 | ||||||
| Iron Law 模式 | 主 | 复用 | 系统化 | 实践 | ||||
| Red Flags / Rationalizations | 主 | 复用 | 系统化 | 实践 | ||||
| TDD 技能 | 主 | |||||||
| Verification 技能 | 主 | |||||||
| Gate Function 模式 | 主 | |||||||
| 四阶段调试法 | 主 | |||||||
| 根因追踪 | 主 | |||||||
| 纵深防御 | 主 | |||||||
| 条件等待 | 主 | |||||||
| Brainstorming 技能 | 概览 | 主 | ||||||
| Writing-Plans 技能 | 概览 | 主 | ||||||
| HARD-GATE 机制 | 主 | |||||||
| No Placeholders 原则 | 主 | |||||||
| 技能衔接关系 | 概览 | 主 | 主 | |||||
| Subagent 驱动开发 | 概览 | 主 | ||||||
| 3 个 Prompt 模板 | 主 | |||||||
| 上下文隔离原则 | 主 | |||||||
| 模型分层策略 | 主 | |||||||
| 代码评审（请求/接收） | 主 | |||||||
| 并行代理派发 | 主 | |||||||
| Agent vs Skill 区别 | 主 | |||||||
| 技能的 TDD 方法论 | 主 | 实践 | ||||||
| CSO（搜索优化） | 主 | 实践 | ||||||
| 说服心理学 | 主 | |||||||
| 压力测试设计 | 体验 | 分析 | 主 | 实践 | ||||
| SKILL.md 结构规范 | 观察 | 主 | 实践 | |||||
| Release Notes 考古 | 引用 | 主 | ||||||
| 关键演化决策 | 主 | |||||||
| 跨平台工程实践 | 引入 | 主 | ||||||
| 实战：创建新技能 | 主 |
附录 B：课前准备
环境要求：
- 安装 Claude Code（或 Cursor / Codex）
- 克隆 Superpowers 仓库
- 安装 Superpowers 插件
- 一个用于实验的小型项目
前置知识：
- 基本的 Git 操作
- 了解 TDD 概念（不需要精通）
- 使用过至少一个 AI 编程助手
