用 spec + plan 锁死验收标准、用子代理拆分任务清空上下文、用 TDD 红绿灯约束写代码环节的 Agent 工作流插件，代价是时间和 token 成倍上涨。
来源：让 harness 减少 AI 写的屎山 | 果穗也能看懂的名片网页制作教程【EP7.superpowers 是什么 为什么要用】 UP 主：咲凌_Arisa｜时长：13:34｜整理日期：2026-08-30 本笔记基于字幕整理。ASR 转写有明显错别字，涉及专有名词处已按上下文还原并标注。
Superpowers 是一套把 harness engineering 落到实处的 Agent 工作流插件：用 spec + plan 锁死验收标准，用子代理拆分任务清空上下文，用 TDD 红绿灯约束写代码环节。代价是时间和 token 成倍上涨，而且装上后需要手动改 using-superpowers 的 description，否则连改个 README 都会走一遍完整流程。
作者的前提判断（字幕已验证）：
背景补充：harness engineering 是继 prompt engineering、context engineering 之后的说法，指的是围绕模型搭建的「支架/约束层」——调度、上下文管理、工具权限、验收机制等。视频推荐了两篇博客：OpenAI 官方的和 Anthropic 官方的，作者更推荐 Anthropic 那篇（发布时间更新），OpenAI 那篇更通俗易懂。
任务一（探索代码库 → 调工具 → 写代码）
↓ 同一个 session，上一轮的任务记忆仍在
任务二 ← 模型注意力被干扰 → 漂移（drift）不拆分任务、所有任务丢给同一个 agent 且都在一个 session 里，上一轮对话的任务记忆会影响模型注意力，导致漂移。而且上下文终究是有限的，还会抬高成本。
Anthropic 博客里提到的两种常见故障模式（字幕已验证）：
对应解法很直接：
一个任务一个新 agent，做完清空上下文，下一个任务再开一个。
作者的比喻（字幕已验证）：像安排一个实习生打工，他觉得「我做的没问题」，但人一看「还有各种各样的问题」。原文表述是「在人类观察者眼（中）其质量明显平庸」。
所以必须引入外部审查机制，或者是强 CI——不依赖大模型自己去评判的工具。
作者借 Claude Code 源码泄露后的一篇文章（视频里未点名）给出的「省流」结论：
| 要点 | 字幕原文（含 ASR 噪声） |
|---|---|
| 模型提出动作 ≠ 用户已授权 | 「模型提出动作不等于让（任何）人（拥）有授权」 |
| 工具调度必须拥有因果秩序 | 同上 |
| 中断要保持一致性 | 「中段要有一等于一」 |
| 不能靠异常兜底 | 同上 |
| 工具系统同时保护用户和运行 | 「工具系统保护（用）用户也（保护）运行」 |
⚠️ 「中断要保持一致性」这条字幕为「中段要有一等于一」，无法确认原词，推测是中断的幂等性/一致性。其余四条语义可辨。作者自己也说这块「讲得省去了很多，不一定准确，建议去看博客原文」。
主流程：brainstorm → spec → plan → 调度子代理执行
主 agent
├─ brainstorm 追问细节、补充上下文（类似 Claude Code 的 plan mode）
├─ spec 文档 ← 关键差异点：定义「达到什么标准才算完成」
├─ plan 文档
└─ 你确认满意 → 开始调度子 agent和一般 plan mode 的核心区别：多了一个 spec 文档。 原因就是上面说的「代理自评偏乐观」——必须先把验收标准写死，而不是让 agent 自己判断做没做完。
作者实际观察到每个 task 下大概有三个主要子代理（字幕已验证）：
| 子代理 | 职责 |
|---|---|
| explore | 探索代码库 |
| 重构 | 探索完之后写代码 |
| 验收 | 审查代码过不过关 |
三步走完没问题才交回主 agent。而且主 agent 并不完全信任子代理——即使三个子代理都回报通关，主 agent 还会自己再审查一遍；不接受就整个流程重走。
| 耗时 | 成本 | |
|---|---|---|
| full harness | 6 小时 | 约 200 刀 |
| solo | 20 分钟 | 约 10 刀 |
（数据为视频中引用的 Superpowers 官网示例。）作者的评价：原来改个小任务十几分钟，用这套可能蹦到几小时；但对代码库的代码风格和代码质量确实很有帮助。
写代码这一步内部又是三层（字幕已验证）：
1. 红 —— 先写一个会失败的测试
2. 绿 —— 写 just enough 的最小改动让测试跑起来
（Superpowers 会把验证脚本存起来）
3. 重构 —— 检查边缘条件、删掉不必要的兜底机制
→ 再跑一遍测试确认作者强调的理念是 just need enough（刚刚好够），写完最小实现后要回头审视是否有过度设计、是否有不必要的兜底。
背景补充：这就是经典的 red-green-refactor。视频还提到 Superpowers 官方列了几个原则（拆小片段、写 plan、TDD、不要重复自己等），作者只展开讲了 TDD，说「因为 TDD 比较重要」。
官方对 Claude、Cursor、Codex 都提供了一段可直接复制的配置，粘进去即可。
using-superpowers 的 description这是视频里最实用的一条经验（字幕已验证）。
问题：using-superpowers 这个 skill 的 description 写的是 when starting any conversation，并且明确写了**「哪怕只有 1% 的可能性适用，你也必须调用这个技能」。结果就是任何一次对话都会被强制触发一次技能调用**。
Codex 上尤其严重——视频的说法是 GPT 训练时似乎对技能调用做了额外训练，调用技能比 Claude 还积极。「改个 README 这种小工作也会走一遍这个流程」，而你明明知道哪里出错了。
改法：把 description 里的 1% 去掉，改成——
只有当需要调用 Superpowers 或用户明确使用 superpowers 指令的时候，才进行调用。
这样整个开发流程才可控，小改动不会被拖进完整流程。
Superpowers 是很好的 harness engineering 实践，但 Anthropic 官方博客也说了：
作者的结论：harness engineering 是当前条件下的较好实践，未来可能会变。举的例子是以前很火的 sequential thinking（顺序思考）MCP，「现在好像已经没有看到多少人用了」——模型能力的进步会带来框架的改变。
| 场景 | 建议 |
|---|---|
| 改 README、改个小 bug、已知问题位置 | ❌ 别用，光流程就比改动本身贵 |
| 从零搭一个功能/小项目，要求代码质量 | ✅ 适合，spec 先行能省掉返工 |
| 长任务、多步骤、容易跑偏 | ✅ 适合，子代理拆分天然解决上下文污染 |
| token 预算紧张 / 赶时间 | ❌ 慎用，视频给的参照是 10 刀 → 200 刀 |