企业官网建设流程全解析

如果你也在用 Claude Code 这类 AI 编程助手，应该会注意到一个高频词：superpowers。它不是什么超级英雄皮肤，而是可以装进 Claude Code 的一套“技能包集合”，目的就是给 AI 补充可复用的工作流能力。最近社群里的讨论集中在“具体怎么用”“有哪些 skills”“怎么引入”，我干脆把自己从安装到上手的完整过程写出来，给想尝试的人一条顺畅路径。

先说清楚：Superpowers 不是某个模型，也不是一个“提示词模板”那么简单。它更像是一套打包好的技能目录，每个技能都有独立文件，Claude Code 读到对应场景后会自动把技能内容加载进上下文，从而改变 AI 的执行方式。也就是说，装上它之后，AI 做任务时会开始有章法：先想清楚目标，再拆任务，再动手，再验证。对于日常写脚本、改 bug 和做小需求的人来说，这种变化最直观的感受就是“AI 终于不再急着甩代码了”。

1. 先搞清楚：Superpowers 到底给你的 AI 助手加的是什么

1.1 原生编码能力与“技能”本质上是两回事

很多人刚开始以为“给 Claude 装 superpowers”就是让 AI 变得更聪明，这个理解方向不对。大模型本身的代码能力，在它被训练出来那天就固定了；真正可以改的是“它在项目中如何工作、按什么顺序工作、输出前需要检查什么”。打个比方：一个新人能力很强，但你给他一台电脑他未必知道公司流程；Superpowers 做的是把一套工作流程写进文件，让 AI 在特定场景下自动遵守。

Claude Code 原生也能写代码、读文件、执行命令，但它的默认行为更像是“即时响应”：你说改什么，它就直接改。这种模式对简单任务没问题，可一旦需求稍微复杂，AI 就会开始猜，甚至连续改好几轮都打不中要点。技能包解决的是“行为约束”，不是“智力提升”。

1.2 技能在 Claude Code 里的实际加载方式

Superpowers 的设计很直白：每个技能一个目录，目录里有一个SKILL.md文件作为入口。文件头部是 YAML 格式的描述信息，说明这个技能什么时候该触发；文件正文是具体操作方法，可以是分阶段步骤、检查清单、编码规范，甚至可以直接让 AI 启动子代理去干某件事。

当我在对话里说“帮我想个方案”时，Claude Code 会去扫描当前环境里所有可用技能，看描述符是否匹配。如果匹配到 brainstorming 技能，它就会把该技能文件里写的那套“发散思路、评估候选方案的流程”注入到当前上下文中，然后按这套流程执行。

这里有个关键点：技能不是常驻指令，它更像“按需执行的 SOP”。你不需要每次手动喊它，但也可以显式指定“用某个技能来干活”。这种按需触发机制的好处是省上下文，坏处是你得理解每个技能的触发条件，不然会以为技能没装上。

1.3 为什么它在近期成了搜索热点

最近“superpowers”这个词频繁出现在开发者讨论区，直接原因有两个。第一，越来越多团队开始把 Claude Code 纳入日常开发，但他们很快发现每个人用 AI 的方式差异很大，有人用得好有人用得差，差就差在“流程意识”。Superpowers 把流程做成了可复制的技能包。第二，Claude Code 的插件机制日趋成熟，装技能不再需要手写一堆系统提示词，几条命令就能搞定。于是大家开始找“有哪些 skills”“安装路径是什么”，其实就是想把这套工程化的工作法搬到自己项目里。

2. 打开技能清单：Superpowers 里那些值得认识的 skills

2.1 核心“工作流型”技能

我在仓库的 skills 目录里翻到过不少技能，这里只挑几个让我印象深刻的。

• brainstorming：需求很模糊的时候，它会要求 AI 先列出多种解决思路，再对比每个方案的副作用、成本和验证方式，而不是马上写代码。这个技能对我特别有用，因为很多时候我还没想清楚自己要什么，就让 AI 开写，写一半才意识到方向错了。
• planning：把一个大目标拆成可执行、可验证的小任务，并标注依赖关系。它和直接给 AI 说“写个计划”不同，它有一套固定的格式，拆完之后还要让 AI 自己检查每个步骤是否真的可执行。
• tdd：测试驱动开发。技能会要求 AI 先写失败的测试，再写最小实现，最后跑测试和重构。这个流程单独看没什么稀奇，但让 AI 长期稳定遵守就很有价值，尤其是改别人项目里的老代码时，能倒逼 AI 不做无边界的大改。
• debugging：它不是让 AI 盯着报错信息瞎猜，而是先收集现象、建立假设，再逐步隔离代码路径。实际用下来，这个技能能明显减少“改一行跑一次，再改一行再跑一次”的循环。

2.2 偏工程化的“组合型”技能

Superpowers 里还有一些偏工程编排的技能，比如 subagent-driven development。大意是：当任务规模较大时，主代理先写计划文件，然后派多个子代理分别去执行不同子任务，最后统一汇总验证。这种做法在 Claude Code 的多代理机制下效果不错，适合做并行开发或者长任务。

这类技能不会在每次对话中主动触发，因为场景比较重。但它给出了一个很好的思路：AI 编程不只是“单兵作战”，还可以把任务拆给多个子代理，各自带上下文，互不干扰。对于有复杂项目的团队，这种技能的价值会更高。

2.3 技能不是越多越好：选择策略

这里我必须泼一盆冷水：不要装完全部技能就觉得自己无敌了。技能包的核心是“行为控制”，控制得太多，AI 反而会在简单任务上变得啰嗦。

我自己的策略是“按项目选技能”。比如一个快速脚本项目，只需要保留 debugging 和基础的执行能力；一个需要长期迭代的功能模块，就加上 brainstorming、planning 和 tdd。你可以直接编辑技能目录，把不用的技能文件移出当前项目，或是在SKILL.md的描述里写清楚触发边界，避免 AI 动不动就把简单请求拽进全套流程。

3. 从零安装 Superpowers：我跑通的两种方式

3.1 方式一：通过 Claude Code 插件市场安装

在 Claude Code 里输入/plugin，界面会弹出插件面板。选择添加 marketplace，填上 Superpowers 的 GitHub 仓库地址，然后执行安装。我当时用的命令大致是这样：

/plugin marketplace add https://github.com/obra/superpowers /plugin install superpowers

如果你的 Claude Code 版本对命令格式有调整，不要硬背，直接去仓库 README 的 Installation 部分复制最新命令。这个项目迭代是真的快，我一个月前装的版本和两个月前看到的文件结构已经有差异了。

装完之后，重启 Claude Code，再输入/skills或者问一句“当前环境里有哪些可用技能”，就能看到 Superpowers 带进来的技能列表。正常的话，你会看到若干个带独立命名的技能，名称旁边通常还有简短描述。

3.2 方式二：手动拉取仓库并注册为技能目录

如果你所在的开发环境不方便用插件市场，或者你想完全掌控技能文件的位置，可以手动拉仓库：

git clone https://github.com/obra/superpowers.git

拉下来之后，把仓库里的 skills 目录链接或复制到 Claude Code 的全局技能目录：

mkdir -p ~/.claude/skills cp -r superpowers/skills/* ~/.claude/skills/

这样做的优点是目录结构一目了然，想删哪个技能直接删文件夹。缺点是没有自动更新，上游仓库更新后你需要手动git pull，再把变更同步到本地技能目录。个人项目我推荐插件方式，团队统一管理时手动方式更可控。

3.3 安装后第一件事：验证技能真的被读到了

很多人装完技能后发现自己让 AI 做某件事，AI 好像还是老样子，于是以为装失败了。其实多数情况是触发条件没匹配上。装完后不要急着做复杂任务，先花一分钟做验证：

• 在 Claude Code 里输入/skills，看技能列表里是否出现了 brainstorming、planning 等条目。
• 直接说“请使用 brainstorming 技能，帮我梳理这个需求”，观察 AI 是否切换成“分阶段输出”的模式。
• 打开一个简单的报错场景，让它用 debugging 技能排查，看它是否先问现象、收集信息再动手改代码。

如果名字出现在列表里但行为没变化，多半是当前对话上下文过长，或者技能描述里限定了触发场景。这时你可以手动指定技能名，让 AI 强制参考对应文件。

4. 引入技能的实操案例：让 AI 按你的流程而不是它的习惯工作

4.1 一个最小示例：改造排查崩溃 bug 的方式

我之前遇到一个偶发性崩溃，项目里没有技能时，AI 的做法是直接读相关文件，然后给出一个自认为最可能的修复点。装上 debugging 技能后，我会显式说：“用 debugging 技能帮我查一下这个崩溃。”它会先去定位最小复现路径，分析调用链，用日志输出关键变量，再定位疑似模块，最后才动手改。这一步对效率和失误率的影响都很大，尤其是在老项目里。

如果你已经装了 tdd 技能，它还会在修完 bug 后主动补一条回归测试。以前这些是人为提醒的，现在技能文件里写明了步骤，AI 不执行反而像漏了步骤一样。

4.2 主动调用技能的最直接句式

技能包不是魔法开关，但它确实提供了稳定的触发入口。最直接的方式就是一句话：“用某个技能做某件事”。比如：

• “用 brainstorming 技能先帮我列三个可能的方案，再评估。”
• “用 planning 技能把这个功能拆成 5 个以内的子任务。”
• “用 tdd 技能给这个函数补测试。”

这种写法等于告诉 Claude Code“这个任务有专门工具，请翻对应文件”。实测下来，AI 的响应结构会变得非常清晰，不会东拉西扯。

4.3 把团队规范写成自定义技能

Superpowers 最好的扩展方式，不是囤别人的技能，而是把自己的团队工作流也做成技能。比如你可以在~/.claude/skills/code-review/SKILL.md里写死一套代码评审标准：先看安全风险，再看可读性，再看性能，最后检查测试覆盖。Claude Code 在收到“帮我 review 这段代码”时会自动按这个顺序走。

这种做法相当于把经验沉淀成“团队记忆”，不管谁用 AI，都会按同一套规则执行。这也是我最终觉得 Superpowers 这类设计有意思的地方：它本质上是让每个人都能给 AI 写标准作业流程。

5. 我踩过的坑和现在的使用习惯

5.1 坑一：全量加载后，AI 开始“过度规划”

我第一次安装时直接保留了所有技能，结果 AI 连“帮我改个变量名”这种操作都想先开 planning。它甚至给我列出一个三步计划，再问我“是否继续”。表面上流程很规范，实际上把简单事搞复杂了。后来我把触发描述改窄，并且只保留当前项目需要的技能文件，情况才正常。

5.2 坑二：多台机器之间的技能配置不一致

我家里和办公室各有一台开发机，一开始只在一边装了技能，另一边没装，导致两边行为差异很大。后来我把技能目录纳入 dotfiles 管理，每次同步配置时一起推送。如果你和队友协作，最好在项目仓库里保留一份技能文件路径说明，或者在文档里写清安装命令，避免有人“裸奔”有人“满配”。

5.3 坑三：上游更新太快，改造本地文件容易冲突

Superpowers 的更新频率不低，我自己也忍不住改过技能文件里的细节。结果下一次同步时，本地 git 冲突搞得我很头疼。现在我的习惯是：不直接改上游文件，如果需要定制，就在自己的技能目录里新建一个技能，引用上游思路但写成适合自己的版本。这样既保留了我的定制，又不影响拉取更新。

5.4 我目前实际使用的技能子集和工作流

现在我的项目里只保留了四个技能：brainstorming、planning、tdd、debugging。需求特别模糊时先过一遍 brainstorming；复杂度较高的功能才用 planning；涉及核心逻辑修改时强制走 tdd；线上问题只用 debugging。这样一个配置既不会让 AI 在简单需求上长篇大论，又能在关键环节稳住节奏。

在我自己实际使用的过程中，最明显的体感是“AI 说人话的时间变多了，瞎写代码的时间变少了”。技能包不会让 AI 突然变成架构师，但它能够把你平时需要反复在提示词里强调的规范，变成一套稳定的、可复用的文件结构。如果你正准备尝试 superpowers，我的建议是先装最小的子集，严格验证一条流程，跑顺了再逐步加。这比一口气把全套技能都塞进去，更容易看清它到底值不值得留在你的工具箱里。