企业官网建设流程全解析

用过 Claude Code 一段时间的人，多少都会有同一种感觉：模型本身是很强，但真正拉开效率差距的，是“怎么干活”这套方法论有没有被提前讲清楚。拿到一个含糊的需求，是先追问还是直接开写？写完代码要不要补测试？报错之后是瞎试还是有套路地定位？这些看着都是常识，可真到实操里，大多数人是凭感觉走，AI 也只能跟着你的感觉走。

superpowers 就是冲着这个问题来的。它是 Jesse Vincent（GitHub 上叫 obra）开源的一套 Claude Code skills 技能包：装上之后，Claude Code 会多出一整套带明确触发条件、按场景组织的工作技能——帮你做头脑风暴、写 PRD、拆实施计划、按 TDD 节奏写代码、系统化排错、做代码审查和项目复盘。社区里聊 Claude Code 插件化、技能加载、Agent 工作流的时候，这个项目被反复点名，不是没有原因的。

这篇文章按实际使用顺序来讲：它到底解决了什么问题、怎么安装、里面有哪些 skills、日常怎么把这套技能“引入”到项目里并组合着用，最后是我自己踩过的坑和排查记录。不管你是刚听说这个词，还是已经装完想深挖，读一遍应该都能找到能直接抄的东西。

1. superpowers 是什么：给 Claude Code 补上一套“职业级工作法”

1.1 为什么需要 skills：先搞懂技能是怎么工作的

装 superpowers 之前，得先明白 Claude Code 的 skills 机制到底是怎么运作的。简单说，它就是在约定好的目录里放“说明手册”，Claude 在会话启动时会扫一遍每本手册的名字和适用场景（也就是 YAML 头里的 description 字段），然后在任务命中场景时把对应手册的全文读进来，按里面的步骤执行。

这跟直接把提示词塞进 CLAUDE.md 是两回事。CLAUDE.md 是“每次会话都要读的长期记忆”，写太长每轮对话都会占用上下文；skill 是“按需加载的操作手册”，平时只占一行描述，用到的时候才把全文翻出来。打个比方：CLAUDE.md 像是贴在工位上的岗位职责，skills 像是一整排放在旁边的 SOP 手册，遇到对应场景才抽出来读。所以它既省 token，又不会被模型当成日常背景噪音忽略掉。

superpowers 本质上就是往这个技能目录里放了一批编写质量很高的 SOP。它没有动模型本身，也没有改 Claude Code 的源码，纯粹是用一套精心组织的说明文档，改变了模型的工作习惯。这也是为什么它对新手和老手都友好：你不需要理解复杂机制，装上就能感受到行为变化。

1.2 设计哲学：把资深工程师的习惯变成可复用流程

我特意去翻过它的源码。作者是 Perl 社区的老牌维护者，所以这套技能的编写思路跟普通“AI 提示词合集”很不一样，不是那种“你要好好干”的空话，而是非常具体的、甚至有点“轴”的操作规程。三个特点让我印象很深。

第一，步骤具体到有点反直觉。比如 brainstorming 技能里有一条硬性要求：一次只问一个问题，不要上来就给方案。单独看你会觉得啰嗦，可实际协作里这正是防“AI 抢答”的关键——用户还没想清楚，模型就急着抛方案，最后只会把需求带偏。第二，每个技能都解释了“为什么”。SKILL.md 里除了步骤，还有设计理由，告诉模型这一步是为了防什么。这个设计很妙，因为模型遇到边界情况时，能根据“为什么要这么做”合理变通，而不是机械执行。第三，技能之间有明确的衔接关系。brainstorming 的产物刚好喂给 writing-prd，writing-prd 的产物给 writing-plans 拆步骤，计划再交给 executing-plans 执行。它们不是孤立的提示词，而是一条流水线。

把它的任何一个 SKILL.md 打开看一遍，都比看十篇“怎么写提示词”的文章有用。这也是我推荐所有想深入玩技能系统的人先读源码的原因。

2. 安装 superpowers 的两种方式：插件安装与手动复制，附验证方法

2.1 方式一：通过插件机制安装（推荐）

Claude Code 最近几个版本支持插件机制，superpowers 也走这条路。在会话里打开插件面板（输入/plugin），然后添加 obra 的插件源并安装；新版 CLI 也可以直接执行claude plugin install obra/superpowers。不同小版本的命令措辞会有一点差异，如果你那边命令对不上，以仓库 README 为准。

插件方式的好处是升级省心。装完之后，插件会负责把技能同步到正确位置，后续作者更新也能直接通过插件管理拉取，不会在本地留下一堆再也更新不了的旧副本。如果你只是想试试水，我建议优先用这种方式。

需要提醒一句：如果你的 Claude Code 版本比较老，可能根本没有插件入口。遇到这种情况别急，下面的手动方式一样能装，不挑版本。

2.2 方式二：手动克隆并复制到 skills 目录

手动装一共三行命令：

git clone https://github.com/obra/superpowers.git mkdir -p ~/.claude/skills cp -R superpowers/skills/* ~/.claude/skills/

~/.claude/skills是用户级技能目录，只要账号在这台机器上登录，所有项目都能用。如果你只想给某个项目装，把技能放进那个项目的.claude/skills/目录即可。

这里必须强调一个细节：目录结构必须长成下面这样，多一层少一层都不行。

~/.claude/skills/ brainstorming/ SKILL.md writing-plans/ SKILL.md ...

很多人栽在cp -R superpowers ~/.claude/skills/这种写法上，结果变成了~/.claude/skills/superpowers/skills/brainstorming/SKILL.md，多套了一层目录，Claude 根本扫不到。要复制的是仓库里skills/这个子目录下的内容，不是整个仓库。

2.3 装完怎么验证：三步确认技能真的被加载

装完别急着开干，先花一分钟确认加载状态，避免后面浪费几分钟才发现没装上。我的验证顺序是：

1. 在终端里跑ls ~/.claude/skills/，看是不是有一串技能目录名。
2. 新开一个 Claude Code 会话，直接问“你现在有哪些可用的 skills？”，它应该会列出各个技能的名称和适用场景。
3. 手动点名测一个：“请用 brainstorming 技能和我讨论一个想法。”如果它真的按技能套路走，比如一次只问一个问题而不是直接给方案，说明加载正常。

注意，如果是在会话进行中才完成安装的，必须重启会话再验证。技能的扫描发生在会话启动阶段，中途装的在本会话里不会生效。

3. superpowers 里有哪些 skills：按需求、编码、复盘三阶段整理的清单

3.1 需求期的三件套：把“想法”变成“能执行的东西”

**brainstorming（头脑风暴）**是入口技能。它专门处理“我有个模糊想法”的场景。它会用连续提问把需求边界一点点勾出来，而且严格执行一次一问，绝不一口气抛一堆问题或用五页分析砸晕你。用的时候你会觉得节奏慢，但需求质量明显比裸聊高。

**writing-prd（写产品需求文档）**负责把聊清楚的想法落成结构化文档，通常包含背景、目标、用户故事、验收标准和边界反例。有了这份 PRD，后面不管是自己手写还是让 Claude 实现，都有一个能对齐的标的。我习惯把 PRD 直接存在项目里当文档用，写代码时随手翻。

**writing-plans（写实施计划）**是把 PRD 变成一步步的施工图：拆解任务、标注依赖、写明每步产物和测试思路。它的输出格式带着编号和检查点，是下一步执行阶段的直接输入，不是给人肉眼看个大概的。

3.2 编码执行期：从计划到代码，再到排错

**executing-plans（执行计划）**是配合 writing-plans 使用的主执行技能。它会按计划逐步推进，每完成一步就检查产物、更新进度，不跳步、不擅自扩大范围。长任务里模型特别容易做着做着跑偏，这个技能就是用来拴住它的。

**tdd（测试驱动开发）**把红绿重构循环固化成了操作流程：先写一个失败的测试，再写最小实现让它通过，最后重构。技能里还嵌入了驱动者、导航者这类分工模式的建议，处理复杂功能时很实用。

**debugging（系统化排错）**是让我对这套技能路转粉的那一个。遇到 bug 时，它会强制 Claude 先稳定复现，再缩小范围、列出假设、逐个验证、找到根因，最后才动手修复。整个过程核心思想是“不猜，按流程走”，比让模型瞎试高效太多。

3.3 审查与复盘期：做得完不等于做得好

**system-critic（系统批评）**适合在动手之前用。它会刻意站在反面给方案挑刺：边界没覆盖、依赖选得重、风险点没列全。有句话叫“先让 AI 批评你一次，再让它帮你写代码”，就能少很多返工。

**code-review / requesting-code-review（代码评审）**把代码审查变成有维度的检查：正确性、可读性、边界条件、依赖影响、性能隐患都要过一遍。提交大改动之前走一轮，能抓住不少肉眼容易漏的问题。

**retrospective（复盘）**在阶段收尾时用，回顾哪些做法省了时间、哪些坑浪费了生命，总结成改进项。短期看它不产出代码，时间拉长，它才是提升人机协作效率最关键的一环。

老实说，技能清单会随版本变化，上面列的是我当前环境里实际在用的核心项。给我的整体感觉是：这不是一堆命令，而是一个经验丰富的工程师把工作习惯拆成了教学手册，每个手册解决一类高频场景。

4. 怎么引入这些技能：自动匹配、手动点名和一条完整使用链路

4.1 自动匹配机制：把“说明”写清楚，技能才会被召唤

Claude 每次会话启动时，会读取可用技能的 name 和 description，形成一张“技能索引”。之后你说的每一句话，它都会拿去和索引里的描述做匹配，匹配上了就加载技能全文，按里面的流程走。

所以 description 的写法直接决定技能触发率。superpowers 的写法是很好的模板：主语是“什么时候用”，而不是“这个技能是什么”。比如某个技能的描述写“当用户需要将模糊想法梳理成清晰需求时使用”，比“这是一个头脑风暴工具”要有效得多。如果你以后想写自己的技能，description 是第一个要认真打磨的地方。

这里还有个常被忽略的点：技能索引本身是要占上下文的，装得越多，索引越大。技能不是越多越好。我的建议是先全量安装，跑两三周后，再把不常用的裁剪掉，只留真正高频的那几个。

4.2 手动点名：把技能名直接写进你的话里

自动匹配再好，关键时刻都不如手动点名稳。实用说法参考这些：

• “用 brainstorming 把‘每周自动汇总阅读笔记’这个想法聊清楚。”
• “把刚才聊的内容用 writing-prd 写成需求文档。”
• “按 PRD 用 writing-plans 出计划，先控制在 8 步以内。”
• “动手写之前用 system-critic 把方案批一遍。”
• “这个 bug 用 debugging 技能排查。”
• “今天的工作收个尾，用 retrospective 复盘一下。”

我的经验是，一旦明确点名，Claude 基本不会跑偏；靠它自己猜场景，偶尔会漏。不确定用哪个技能的时候，直接问“我现在这种情况应该用哪个 skill”，它也会根据描述给你建议。

4.3 一条完整链路：从“我有个想法”到“能跑的代码”

拿我最近做的一个小工具举例。我想做一个“阅读笔记周报生成器”，但需求很毛糙。整个流程是这样的：

第一步，我跟 Claude 说：“用 brainstorming 帮我”理一个想法：每周自动汇总本周的阅读笔记，生成一份周报。“它开始提问：周报给谁看？想包含哪些字段？数据源是什么？输出格式是 Markdown 还是邮件？一次一个问题，聊了大概十分钟，需求就清晰了。

第二步，我说：“把刚才的内容用 writing-prd 写成 PRD。”它输出了一份文档，里面写了目标、用户故事、验收标准，还补了两条我自己没想到的边界场景，比如“某周没有笔记时应该怎么样”。

第三步，说：“用 writing-plans 出实施计划。”它把任务拆成了获取笔记数据、定义周报模板、生成 Markdown、输出归档路径、写测试等几个步骤，每步还标了依赖关系。

第四步，说：“从第一步开始用 executing-plans 执行。”它按顺序实现，每完成一步会停下来确认再继续。中途遇到一个日期解析的 bug，我切到 debugging 技能，它按流程定位到是时区边界问题，而不是库本身的问题。

最后，让 Claude 用 retrospective 复盘了整个开发过程，沉淀了几条对下次有用的经验。这条链路才是 superpowers 真正值钱的地方：它把一次开发从头到尾编排成了标准动作，每一步都知道自己在哪里、要产出什么、接下来干什么。

5. 常见问题与避坑记录：技能不生效、命名冲突、自定义自己的 skill

5.1 技能装了却没生效，按顺序查这四件事

目录层级是我见过最多人踩的坑。正确的检查命令是find ~/.claude/skills -name SKILL.md，如果输出里出现superpowers/skills/这种多余层级，就是复制时把整个仓库拷进去了，重新按 2.2 的cp -R superpowers/skills/*来一次就行。

5.2 命名冲突与覆盖规则：项目级说了算

技能也有优先级问题。项目级.claude/skills会覆盖用户级~/.claude/skills里的同名技能。如果你给某个项目放了自己写的同名技能，行为会整个替换成你的版本，superpowers 的原始技能在这个项目里就等于不生效。

另一个坑是卸载不干净。插件安装后如果手动改过目录，移除插件时可能会在~/.claude/skills里留下软链或副本。删了插件但技能还在，是很常见的“幽灵”现象。清理时先把两个目录都看一眼，别只处理一边。

5.3 进阶玩法：以 superpowers 为模板，写一个你自己的 skill

技能系统最大的乐趣在于可以自己扩展。借鉴 superpowers 的格式，一个最小的自定义技能长这样：

--- name: commit-message description: 当用户需要生成 git commit message 时使用。 --- 生成 commit message 的步骤： 1. 先运行 `git diff --stat` 和 `git diff` 查看改动范围。 2. 用“一句主标题 + 必要时补充正文”的结构。 3. 主标题不超过 50 个字符，动词开头，使用现在时。

把它保存到~/.claude/skills/commit-message/SKILL.md，重启会话就能用。

写自定义技能有四个经验值得记下来。第一，description 决定触发率，要写“什么时候用”，触发条件越具体越好。第二，正文用编号步骤加示例，别写“写得清楚一点”这种空原则。第三，长度控制在能一口气读完的范围内，每触发一次都消耗 token，太长的技能不划算。第四，拿不准格式时，直接打开一个 superpowers 的 SKILL.md 照着抄字段结构，是最快的上手方式。

最后说点我自己的体会。最初装完 superpowers，翻了一遍技能清单，第一反应是“就这？这些常识我也能写”。真正用起来之后才发现，常识和“可执行的常识”之间差着十万八千里。最让我改观的一次，是一个 flaky 测试反复失败，我自己看半天没头绪，让 Claude 用 debugging 技能走了一遍流程：先最小复现，再列假设，再二分定位，最后发现是异步状态没等到位。整个过程它没有“猜”，而是顺着流程一点点逼近。从那以后我才真的把技能当回事。

给还没试过的人一个建议：别想着一次性把所有技能都用熟，先挑三个——brainstorming、writing-plans、debugging——放进自己的真实项目里跑两周。等你体会到“它居然会按流程来”的感觉之后，自然会想把剩下的技能也打开看看。技能不是魔法，它只是把一个资深工程师该有的工作习惯，原原本本地教给了模型。