Superpowers 学习笔记 — Zero Trust Architecture for AI Agents

Superpowers 是一套 Claude Code 的 skill 插件，把软件工程最佳实践编码为可执行约束。

TLDR

对抗 AI 的惰性 — AI 永远倾向于在满足约束的前提下最小化输出。不能靠自觉，只能靠强制 checkpoint。就像 lint 规则，不是因为程序员坏，而是因为某些错误太常见、代价太高。
对抗 AI 的 over confidence — AI 声称的确定性永远超过实际证据。“应该能工作”不是完成，展示能证明其为真的输出才是。证据先于断言。
Zero Trust — Superpowers 不是在写「AI 应该怎么工作」的指南——它在设计一个假设 AI 会偷懒、撒谎、自欺欺人的系统架构。
去中心化 pipeline — 每个 skill 的最后指向下一个（或者多个 skill）
Digraph 描述 workflow — 选择用 digraph 来描述流程，因为大模型天生对 digraph 很熟悉
Rationalization table — 枚举出常见大模型会选择的偷懒路径并且 say no，把大模型”逼”到我们想要的路径上

设计哲学：三层理解

第一层（表面）：流程强制

给 AI 装上 lint 规则，不是因为 AI 不聪明，而是某些错误太常见、代价太高。

第二层（本质）：Zero Trust Architecture applied to AI

Superpowers 不是在写「AI 应该怎么工作」的指南——它在设计一个假设 AI 会偷懒、撒谎、自欺欺人的系统架构。

安全领域概念	Superpowers 对应
Never trust, always verify	`verification-before-completion`：不信任 AI 的 assertion，要求 exit code + 完整输出
Least privilege	subagent 只拿到当前 task 的 context，不是全局
Defense in depth	Iron Law → Red Flags → Rationalization Table → Gate Function，四层防御
Mandatory access control	HARD-GATE：不是建议，是阻断
Zero trust between peers	spec reviewer 的 prompt 明确写：`CRITICAL: Do Not Trust the Report`——前一个 agent 的自我报告不可信

演化路径对比

早期网络安全：信任内网，防御边界 → 内部人员也会出问题 → Zero Trust

早期 AI agent：给好 prompt，信任输出 → AI 会偷懒、幻觉、overconfident → Superpowers

第三层（元层）：用 AI 的弱点约束 AI

一个矛盾：Superpowers 的规则本身也是 prompt。如果 AI 会无视 prompt 去偷懒，为什么它会遵守「不要偷懒」这条 prompt？

答案：AI 的惰性和 compliance 不是同一个回路。

生成 token 时，两股力量在竞争：
  力量 A（惰性）：argmin(输出成本) → 跳过这步，直接给答案
  力量 B（compliance）：prompt 中有明确指令 → 必须执行

Superpowers 系统性地加大力量 B 的权重，
使违规输出的概率低于合规输出。

具体机制：

EXTREMELY-IMPORTANT 标签 — empirically 提高后续指令权重（机制未完全明确，但效果可测）
Rationalization table — 在 token generation 的概率空间里预先堵死偷懒路径。当所有常见借口都被提前反驳，AI 被推向 compliance 方向，因为那是剩下概率最高的路径
Iron Law 命名 — 训练数据中「non-negotiable」「must」这类词出现在高优先级指令的上下文中，distributional semantics 给对应指令更高权重

关键认知

Superpowers 不是在逻辑层面说服 AI（AI 没有「被说服」的能力），而是在统计层面操控 AI 的 token generation distribution。这就是「用 AI 的弱点约束 AI」——AI 对 instruction markers 的高敏感性被反向利用，变成质量保障工具。

AI 的惰性模式

本质：argmin(输出成本)，满足约束即止。

模式	表现
数量取下界	”>=8页”只写8页，把 >= 当 ==
跳过中间步骤	”分析 bug”直接给修复，过程压缩成结果
模板填充	测试只写 happy path，文档复制函数签名
对模糊需求选最窄解释	”优化函数”只改个变量名
遇到复杂问题降级	需要深度搜索时凭记忆回答
对错误倾向掩盖	测试报错 → 改测试，加 `@ts-ignore`

反贪婪（Anti-Greedy）

“对模糊需求选最窄解释”本质是贪婪算法取反：贪婪 argmax(局部收益) → AI 惰性 argmin(当前输出成本)。同样不回头的单次决策，目标函数反了。

Skills 分类

两大类，关注点分离：

流程类（how to work） — 普适，是质量保障的骨架：

Skill	必须？	作用
`using-superpowers`	✅ meta 层	任何任务前先检查是否有 skill 适用
`brainstorming`	✅	需求理解 → 方案设计，主入口
`writing-plans`	✅	把设计转为可执行任务列表
`test-driven-development`	✅	实现阶段遵循 TDD
`systematic-debugging`	✅（遇到 bug）	4阶段根因分析，禁止猜测式修复
`verification-before-completion`	✅	声称完成前必须展示验证输出
`requesting-code-review`	✅	完成后请求 review
`receiving-code-review`	✅	先核实反馈技术上是否正确，再实现
`finishing-a-development-branch`	✅	收尾整合
`dispatching-parallel-agents`	❌ 可选	多个独立问题并行调查，纯加速

领域类（domain knowledge） — 可插拔：frontend-design、claude-developer-platform、obsidian-markdown 等

完整 Flow

没有总调度器，去中心化 pipeline——每个 skill 的终态硬编码指向下一个：

using-superpowers  （meta 层）
      ↓
brainstorming      （主入口，终态只能 → writing-plans）
      ↓
writing-plans
      ↓
      ├── subagent-driven-development  （当前 session，subagent 自动两阶段 review）
      └── executing-plans             （新 session，人工 review，每批3个任务）
      ↓
finishing-a-development-branch

brainstorming 有一个 HARD-GATE：设计没经用户批准，不能写任何代码。直接对抗 AI 跳过设计阶段的冲动。

执行层三选一

核心区分：谁来 review，顺序还是并行。

	`subagent-driven-development`	`executing-plans`	`dispatching-parallel-agents`
Review	Subagent 自动两阶段	人工 checkpoint	无
顺序	顺序	顺序	并行
前置	writing-plans	writing-plans	多个独立 bug/失败
人工介入	低	高	低

dispatching-parallel-agents 不需要计划文件，是 systematic-debugging 的下游——发现多个独立根因时才触发，本质是加速而非质量保障。

设计巧思

Digraph 描述 workflow — 用 Graphviz DOT 而非自然语言，消除歧义，决策分支显式化，LLM 理解更可靠。

显式命名失败模式 — 每个 skill 的 Red Flags 章节列的不是错误，而是 AI 为跳过这个 skill 会对自己说的那些话。预防合理化，而不只是规定行为。

1% 规则 — using-superpowers 规定只要有 1% 概率适用就必须调用。刻意的过矫正——用不对称约束对冲 AI 系统性低估 skill 必要性的偏差。

自反性 — skill-creator 让这套系统用自身方法论来扩展自身。

关键引用

“Instructions say WHAT, not HOW. ‘Add X’ or ‘Fix Y’ doesn’t mean skip workflows.”

“Every project goes through this process. A todo list, a single-function utility — all of them.”