type
status
date
slug
summary
tags
category
icon
password
今天我做了一个实验。
让 Claude Code 为一个 iOS 应用实现"全局搜索笔记"功能，全程不介入，只看结果。最后代码跑起来了，但有一个 Critical bug：搜索激活时滑动删除笔记，删的是错误的那条。数据会静默丢失，用户毫不知情。
这种 bug，靠 review 很难发现，靠测试要刚好踩到场景，靠运气基本没戏。
但如果装了 Superpowers，这个 bug 在合并之前就被专职的审查 agent 揪出来了。

Superpowers 是什么

Claude Code Superpowers 是一套运行在 Claude Code 上的 skill 插件集。
所谓 skill，本质上是一段结构化的"工作指南"——告诉 Claude 在特定场景下应该按什么流程、什么原则来工作。Claude Code 本身就有 skill 机制，而 Superpowers 在这个机制上封装了一套完整的软件工程最佳实践。
它不是一个命令行工具，不是一个 IDE 插件，也不修改 Claude 的模型能力。它做的事情更像是给 Claude 配了一本《工程师行为准则》：你来了，先看需求，再设计，再写计划，再实现，实现完了要审查，审查通过才算完。
安装之后，Claude Code 在接到任务时，会先判断是否需要调用某个 skill，然后照着那个 skill 的流程走，而不是直接开始写代码。
notion image

安装 Superpowers

Superpowers 通过 Claude Code 的插件机制安装，整个过程不超过 5 分钟。
方式一：通过 Claude Code 插件市场（推荐）
方式二：手动安装
安装完成后，重新启动 Claude Code 会话即可生效。可以用 claude plugin list 确认已启用。

核心 Skill 有哪些

Superpowers 包含一组相互配合的 skill，覆盖软件开发的完整生命周期。
brainstorming — 接到需求后，先探索代码库、提问澄清、给出 2-3 个技术方案、呈现设计，用户确认之后才进入实现阶段。禁止在设计未确认前写任何代码。
writing-plans — 把确认后的设计拆解成 bite-sized 的任务清单，每个任务包含精确的文件路径、代码示例、编译命令、commit 格式。
subagent-driven-development — 按计划逐任务派发独立的 subagent 实现，每个 subagent 完成后走两阶段审查（Spec 合规审查 + 代码质量审查），不通过不合并。
systematic-debugging — 遇到 bug 时强制走四步流程：根因调查 → 模式分析 → 假设验证 → 实现修复。禁止在没有根因的情况下提出修复方案。
code-reviewer — 对整个实现做最终审查，按 Critical / Important / Minor 分级，给出具体行号和修复方向。
writing-skills — 创建和维护 skill 本身，支持团队扩展自定义流程。
这些 skill 之间有明确的调用顺序和转接关系：brainstorming 结束后调用 writing-plans，writing-plans 结束后调用 subagent-driven-development，全部任务完成后调用 code-reviewer。整个链路形成闭环。
notion image

装了和没装，差在哪里

notion image
不装 Superpowers，Claude Code 的默认行为是：收到需求 → 直接写代码 → 给你结果。
这种模式在小改动时够用。但稍微复杂一点的功能，问题就来了。
第一，需求理解靠猜。 Claude 会对模糊的需求自行假设，方向对了是运气，方向错了你要么不知道，要么改到一半才发现。装了 brainstorming 之后，Claude 会在动手之前把关键决策问清楚，比如"搜索要不要包含 AI 增强内容？""结果展示用就地过滤还是全屏搜索页？"确认之后再写。
第二，实现质量不稳定。 没有 skill 约束时，Claude 有时写得很好，有时漏掉边界情况，有时过度工程化，完全取决于当次对话的上下文质量。Subagent-driven-development 强制让每个任务经过 Spec 审查和代码质量审查，不达标的直接退回修复，等于给每个函数都配了两个 reviewer。
第三，bug 只能靠运行时发现。 没有系统审查时，数据损失类的 bug（比如搜索时删错笔记）很可能跑到生产才暴露。有了 code-reviewer skill，它会主动分析数据流，指出"搜索激活时 indexPath.row 指向的是 filteredNotes，但 deleteNote 里用的是 notes，这是数据损失风险"。
第四，debug 靠灵感。 遇到 bug，没有 skill 约束时 Claude 容易直接猜原因开始改，改一处发现新问题再改，改三次可能把原来好的代码也破坏了。systematic-debugging 强制先找根因再动手，比如我这次添加了全局搜索大功能，产生了一个笔记首bug，Claude Code 读了 configure 方法前 10 行就定位了：attributedText = nil 写在 text = title 之后，UILabel 的底层存储被后者清空，一行移位解决。

一次完整开发的对比

以本次"全局搜索笔记"功能为例，完整流程走下来大概是这样的节奏：
阶段
没有 Superpowers
有 Superpowers
需求确认
Claude 自行假设，直接开写
brainstorming 问了 3 个关键问题才开始
技术选型
给一个方案，不解释为什么
给 3 个方案 + 权衡分析 + 推荐理由
实现过程
一次性输出所有代码
11 次 commit，每次小步验证
审查
无
Spec 审查 2 次退回修复，代码质量审查 1 次退回修复
Critical bug 发现时机
上线后
合并前（最终代码审查阶段）
Title 消失 bug
可能靠多次尝试修复
systematic-debugging 一次定位，一行修复
notion image
最值得说的是那个 Critical bug。搜索激活时删除笔记，indexPath.row 来自 filteredNotes 的行序，但 deleteNote 内部用 notes[indexPath.row]，数组不同，删错笔记，数据静默丢失。这是一个逻辑层面的 bug，编译不报错，普通测试很难覆盖，代码 reviewer agent 通过分析数据流发现了它。
如果没有这个流程，这个 bug 大概率会进入生产。

为什么值得装

Superpowers 的本质，是把软件工程行业沉淀多年的最佳实践——需求确认、技术评审、增量实现、代码审查、系统化调试——封装进了 AI 的工作流里。
AI 写代码的速度已经很快了。但"快"不等于"可靠"。没有约束的 AI，它的产出质量就像没有 code review 的团队：有时很好，有时留下隐患，你不知道哪次是哪次。
Superpowers 解决的不是速度问题，是一致性问题。让 AI 的每一次输出都经过相同的质量门控，而不是靠运气。
对于独立开发者来说，这个价值尤其明显——你既是产品经理，又是工程师，又是 QA，精力有限，review 往往流于形式。有了 skill 做流程守护，至少 AI 那部分的质量是可预期的。

安装之后怎么用

装完基本不需要专门学。Superpowers 的 using-superpowers skill 会在每次会话开始时自动加载，Claude 会主动判断当前任务是否需要某个 skill，并在调用前告知你。
几个日常触发场景：
  • 说"实现 XX 功能" → Claude 先用 brainstorming 确认需求再动手
  • 说"修复这个 bug" → Claude 先用 systematic-debugging 找根因
  • 功能实现完说"完成了" → Claude 用 code-reviewer 做一次审查
  • 说"帮我做计划" → Claude 用 writing-plans 输出任务清单
你也可以直接调用：/brainstorming、/systematic-debugging、/writing-plans 等斜杠命令。
唯一需要注意的是：如果你习惯说"直接帮我写代码"，Claude 可能会跳过 brainstorming。最好的触发方式是说"帮我实现"或"帮我做"，让它自己判断需不需要先设计。
装不装 Superpowers，短期看不出差异。做一个两行改动的 bug fix，有没有 skill 流程无所谓。
但做一个稍微复杂的功能，几个小时之后，没装的可能在改一个改出来的新 bug，装了的已经 merge 完在喝茶了。
这种差距，积累几次之后，会让你再也不想回到没有 skill 的状态。
2026.03.08 20:36 沪 · 汇金路KFC
📌 声明：本文由 AI 辅助完成