企业官网建设流程全解析

1. 先搞清楚 Superpowers 到底解决什么问题

1.1 一个让我转型的痛点场景

说实话，我第一次听到 "superpowers" 这个名字的时候，第一反应是"又一个 AI 插件"。但真正把我拉进去的，是一次让我印象深刻的失败经历。

当时我在用 Claude Code 做一个中型重构任务。代码库大概二十万行，涉及多个模块的依赖调整。我给了 AI 一个很明确的需求："把支付模块的接口从同步改成异步"。结果它二话不说就开始改文件，改到一半我发现它对全局的影响完全没有评估——有些调用方还在用同步方式等待返回值，有些测试直接编译不过。最后我只能回滚，重新用非常详细的提示词一步一步引导它：先分析调用链、再列出影响面、再写方案、最后才动手。

那次之后我意识到一个核心问题：AI 编码助手最大的短板不是"不会写代码"，而是没有一套稳定的工作方法。它像一个很聪明但毫无经验的新同事——你问它什么它都能答，但你让它独立负责一个任务，它就容易凭直觉横冲直撞。

Superpowers 就是冲着这个问题来的。

1.2 SKILL.md：把经验固化成流程的核心设计

Superpowers 是 Jesse Vincent（也就是 Perl 社区的老熟人 obra）发起的开源项目。它的核心思路非常朴素：把资深工程师的工作方法，写成 AI 可以稳定执行的"技能说明书"。

在 Superpowers 里，每个技能（skill）就是一个包含SKILL.md文件的目录。这个文件用 Markdown 编写，头部带 YAML 格式的元信息——技能的名称、描述、适用场景。正文部分则是非常具体、非常啰嗦的操作步骤，告诉 AI"接到这个任务之后，第一步做什么、第二步做什么、每一步要输出什么"。

你可以把它理解为给 AI 写的一本"岗位 SOP"。比如"调试"技能，它不会只说"请修复这个 bug"，而是会指导 AI：

• 先复现问题，拿到可重复的最小触发条件
• 再用二分法或日志插桩定位根因，而不是猜测
• 每次只验证一个假设，明确记录证据
• 修复后补充回归测试，防止问题复发

听起来很基础对吧？但问题就在于，这些基础方法 AI 不是不知道，而是不会主动想起。你直接问 Claude"帮我修个 bug"，它可能跳过复现直接开始改代码。而一旦你加载了调试技能，它就会严格按照这套流程走。技能的本质，就是把人类工程师"理所当然的常识"显式地写进提示词里，让模型每次都照着执行。

1.3 技能不是插件，是"操作手册"

这里要纠正一个常见的误解：很多人把 Superpowers 理解成类似"插件市场"的东西，装一个技能就等于给 AI 加了一个新功能。实际上不太一样。

插件通常意味着"模型本身做不了这件事，需要外部程序来帮忙"。而 Superpowers 的技能，绝大多数是"模型本来就能做，但做得不稳定、不系统"的事情。比如头脑风暴、写实施计划、做代码评审——这些Claude模型本身完全会，但让它自由发挥的时候，质量随缘。技能的作用是把高质量的做法固定下来，让 AI 每次都以同样的标准完成。

打个比方：你可以让一个厨师自由发挥做一道菜，味道时好时坏；但如果你给他一本菜谱，写明食材比例、火候时间、装盘步骤，他做出来的东西就会稳定得多。Superpowers 就是这本菜谱集，而且菜谱的撰写者是一群有多年一线经验的工程师。

搞清楚这一点很重要，因为它直接影响你后续怎么使用这个工具——你不只是在"装软件"，你是在给 AI 注入一套工作方法论。

2. 安装 Superpowers：完整实操记录

2.1 环境准备与版本要求

在动手之前，先确认你的环境满足基本条件。Superpowers 目前主要面向 Claude Code 这类基于 agent 模式的 AI 编程工具，也就是你的 AI 助手需要具备自主执行命令、读写文件的能力，而不只是聊天窗口里的问答。

我实测的环境是这样的：

• macOS（Linux 同理，Windows 建议用 WSL）
• Claude Code 已安装并完成登录
• 系统里有curl和bash，版本不太老就行

如果你用的是其他支持 MCP 或技能机制的 agent 工具，安装路径可能略有出入，但核心思路一致。这个项目本身不挑语言环境，它生成的技能文件就是纯 Markdown 加少量脚本，任何能读取技能的 agent 都可以用。

2.2 一键安装脚本做了什么

官方推荐的安装方式是一条命令：

curl -sL https://superpowers.obra.io/bootstrap.sh | bash

我在本地执行的时候，脚本大概做了这么几件事：

1. 检测你的~/.claude目录是否存在，不存在就创建
2. 创建skills子目录，也就是技能的存放位置
3. 从项目仓库拉取一批默认技能，每个技能一个子目录
4. 配置让 Claude Code 在启动时能发现这些技能

整个过程不到一分钟。装完之后我特意看了一下目录结构：

~/.claude/skills/ ├── brainstorming/ # 头脑风暴技能 ├── implementing/ # 功能实现技能 ├── debugging/ # 调试技能 ├── TDD/ # 测试驱动开发技能 ├── subagents/ # 子代理管理技能 └── ...

每个目录下面都至少有一个SKILL.md，有些还带着辅助脚本和示例文件。

提示：curl | bash这种安装方式，圈内一直有争议——它意味着你把系统权限交给了远程脚本。我的做法是先下载脚本看一眼内容再执行，或者用curl -sL URL -o install.sh保存下来检查。对于开源项目这个级别的东西，风险通常可控，但好习惯还是要有的。

2.3 安装后的验证

装完之后怎么确认它真的生效了？我的验证方法很简单。

打开 Claude Code，直接问它："你有哪些 skills 可以使用？"如果安装成功，它会列出从技能目录里读取到的技能清单，并附上一句话描述。

我第一次跑这个验证的时候，Claude 的回答是：

• brainstorming：帮助你在动手前充分探索和评估想法
• writing-plans：把需求拆解成可执行的实施计划
• implementing：按照计划逐步实现功能
• debugging：系统化地定位并修复问题
• TDD：用测试驱动的方式开发
• subagents：管理异步和同步子代理，并行推进任务

看到这个清单，基本就可以确认技能已经被正确加载了。

另一个验证角度是试着触发一个技能。比如你描述一个模糊想法，说"我想给这个工具加一个命令行交互模式"，然后问它应该怎么开始。如果它没有直接甩给你一堆代码，而是先问你几个澄清问题、帮你梳理思路，那说明brainstorming技能已经被正确调用了。

2.4 安装失败与权限问题的处理

我周围有不少朋友在安装时踩过坑，主要集中在两种情况。

一种是权限问题。脚本需要写入~/.claude目录，如果目录被其他进程占用，或者归属权限不对，会报Permission denied。这个好解决，手动把目录所有权改回来就行：

chown -R $(whoami) ~/.claude

另一种是网络问题。仓库拉取失败，典型的报错是Could not resolve host。这种情况多半是网络环境受限，需要你配置代理或者换个网络再试。这里不再展开，属于常规排查手段。

还有个隐藏很深的坑：如果你之前手动创建过~/.claude/skills目录，里面放着一些同名技能，bootstrap 脚本默认可能会跳过或覆盖，导致新旧技能混杂。我建议安装前先看一眼目录里有没有同名文件夹，做好备份再动手。

3. 自带 skills 全景：这些技能分别解决什么问题

3.1 工作流类技能：从灵感到落地的完整链路

Superpowers 默认带的技能里，最核心的一组是围绕"一个功能是怎么从想法变成代码"这条链路设计的。

brainstorming（头脑风暴）负责最前端的环节。它的价值在于阻止 AI"想到就做"。当你抛出一个模糊需求时，这个技能会把过程拆成几步：先澄清目标、列出各种可行方案、对每个方案做成本收益分析、最后收敛出一个推荐方案。它的输出通常是一份结构化的文档，而不是代码。

writing-plans（编写计划）接在头脑风暴后面。它把确认好的方案变成可执行的步骤清单，明确"先改哪个文件、后改哪个文件、每个步骤的验收标准是什么"。这份计划会成为后续实施阶段的行为约束。我在用的时候发现，只要计划写得足够细，实施阶段的返工率会明显降低。

implementing（实施）负责实际动手。它会要求 AI 严格按照已有的计划执行，每完成一步就停下来验证，而不是一口气改十个文件。这个技能还包含"发现计划有漏洞时怎么办"的处理流程——先停下来重新评估，而不是硬着头皮继续。

三个技能放在一起，其实就是一套完整的"先想清楚再动手"的开发方法论。如果你经常觉得 AI 写代码"跑得太快、想得太少"，这组技能就是解药。

3.2 工程实践类技能：把基本功夫刻进提示词

第二组技能对应的是工程师日常的基本功：调试、测试、代码评审。

debugging（调试）是我个人用得最多的技能之一。它的核心原则是"定位根因之前不要改代码"。技能文档里会引导 AI 先建立可复现路径、再通过二分排除缩小范围、每次修改前先记录当前行为、用证据驱动判断。这听起来像废话，但如果你让 AI 直接改过 bug 就会知道——它非常容易"看到一个可疑点就立刻改"。这个技能就是用来压制这个坏习惯的。

TDD（测试驱动开发）也不是什么新鲜概念，但把它变成技能之后效果很有趣。AI 会被引导着先写一个失败测试、再写最小实现让它通过、然后重构，小步快跑。对于生成型模型来说，这种方式反而更稳，因为每一步的目标都非常明确，模型犯错的概率比"一次性写完整个功能"低很多。

code-review（代码评审）则是把评审标准标准化。它不会只丢一句"代码写得没问题"，而是从正确性、可维护性、安全性、性能等维度逐个过一遍，最后输出一份带严重级别标记的问题列表。

这三项技能放到一起，覆盖了"写完代码之后怎么保证质量"的整个链路。

3.3 协作效率类技能：让 AI 学会并行工作

第三组技能围绕的是 agent 之间的协作，最典型的是subagents（子代理管理）。

单个 AI 会话执行任务时是串行的——写一个文件、等它返回、再写下一个。但对于大型重构任务，完全可以拆分给多个子代理同时推进。subagents 技能定义了同步和异步两种子代理模式：

• 同步子代理：主代理等待子代理完成，适合需要立刻拿结果做判断的场景
• 异步子代理：主代理先派发任务，子代理在后台执行，主代理同时做别的事，最后统一收拢

这个技能最大的价值在于让 AI 学会合理的任务拆解。它会指导主代理判断哪些任务可以并行、哪些任务存在依赖必须串行、每个子代理的上下文边界在哪里。我第一次用异步子代理跑一个跨三个模块的重构，时间节省了将近一半，但那是我已经把任务边界想得很清楚的情况下。如果你任务本身耦合度高，硬拆反而会更慢。

3.4 理解类技能：先读懂再动手

最后一类技能面向的是"阅读代码"这个场景。

reading（阅读）技能会引导 AI 系统性地理解一段陌生代码：先看入口、再看数据结构、追踪调用链、最后总结模块的职责和边界。它输出的通常是一份代码说明文档。

这个技能看起来最不起眼，但实际用途非常大。AI 在没有引导的情况下读代码，经常东看一眼西看一眼，总结出来的东西是碎片化的。用 reading 技能之后，它的分析结构会清楚得多，而且在读完之后你可以直接让它基于这份理解去改代码，准确性比"上来就改"高不少。

4. 实战：怎么真正把这些技能用起来

4.1 自动调度：每个技能就是挂在提示词后面的"默认动作"

第一次接触 Superpowers 的人，最常问的问题就是"怎么引入这些技能"——是需要在提示词里手动写"请使用 brainstorming 技能"吗？

其实不用这么麻烦。Superpowers 的机制是：技能描述会出现在 AI 的上下文里，AI 会根据任务内容自动判断该调用哪个技能。你什么都不用做，只要正常描述需求就行。

比如你直接说"我想给我的脚本加一个自动重试机制"，不需要强调"请先头脑风暴"，AI 看到这个需求后，会觉得这属于"方案探索"类任务，自动走到 brainstorming 的流程里去。它会先问你重试的触发条件、最大次数、退避策略，而不是直接帮你把代码写了。

这个自动调度机制是 Superpowers 设计里最精妙的部分。它不强制你改变使用习惯，只是在后台默默给 AI 加了一套行为准则。

4.2 手动召唤：精确控制 AI 进入特定模式

自动调度虽然方便，但 AI 的判断偶尔会跑偏。尤其是你明确想让 AI 干某件事的时候，自动调度反而多此一举。

这时候就需要手动指定技能。方法也很直白，在提示词里直接写明：

请使用 debugging 技能，帮我分析这个报错：<粘贴错误信息>

或者：

请使用 code-review 技能，审查我刚才提交的那段代码。

"使用某某技能"这个短语会精确触发对应的SKILL.md流程。我实测下来，这种显式指定比自动调度的可靠性高很多，尤其是在多个技能都可能匹配的情况下。AI 一旦进入指定技能模式，就会严格按文档里的步骤走，且通常会先简述它接下来的行动顺序，让你有机会在中途纠正方向。

4.3 把多个技能串成一条完整流水线

Superpowers 里单个技能虽然好，但真正的威力在于串起来用。

我在做一个新功能模块的时候，典型的工作流是：

1. 用 brainstorming 梳理需求，确定方案
2. 用 writing-plans 把方案拆成实施计划
3. 用 TDD 指导开发，先写测试再写实现
4. 用 code-review 对最终代码做一遍自查
5. 遇到问题插队使用 debugging 定位根因

你可以直接一次性把整条链路告诉 AI：

我们按这个流程来：先 brainstorming 确定方案，再 writing-plans 做实施计划，然后 TDD 开发，最后 code-review。

AI 会很自然地按顺序切换技能，每个环节结束时主动汇报当前状态，再进入下一个环节。我实际用下来的感受是：当 AI 知道自己在一条流程的哪个位置时，它的输出质量会稳定很多，因为每一个独立步骤的目标都变小了、更清晰了。

4.4 一个真实项目里的技能调用顺序

拿我之前一个实际项目举例：我要给内部工具加一个导出报表为 Excel 的功能。

如果按照传统方式直接让 AI 写，它会立刻去查库、写代码、引入依赖，然后可能卡在某个文件权限或者依赖版本的问题上。而用 Superpowers 的流程跑下来，节奏完全不一样：

第一步，brainstorming 让 AI 反问了我几个问题：报表字段是固定的还是动态的？导出的数据量级有多大？Excel 格式有没有版本要求？要不要支持模板？这些问题我之前根本没想过，但它们直接决定了技术选型。

第二步，writing-plans 给出了详细的实施计划：先定义导出数据模型、再写序列化逻辑、最后接入 CLI 命令入口，每一步都标注了验收标准。

第三步，TDD 阶段按照计划先写了针对导出函数的单元测试，然后一步步实现，每次跑测试确认绿灯。

第四步，code-review 阶段 AI 自己发现了一个我没有注意到的隐患：大数据量下一次性构建整个 Excel 对象可能导致内存溢出，于是建议改成流式写入。

整个过程下来，我基本没有"返工"，只在小细节上调整了几次。这在以前用裸 Claude Code 的时候是不可想象的——以前它的代码我总要自己再检查一遍，因为不确定它有没有跳过什么关键步骤。

5. 编写与引入自定义技能：把团队经验沉淀成 SKILL.md

5.1 技能目录的规范结构

Superpowers 的价值不止在于内置技能，更在于它提供了一套低成本的自定义技能机制。你完全可以把自己团队的工作规范、项目特有的操作流程，写成自己的 skill。

一个标准的技能目录结构长这样：

my-skill/ ├── SKILL.md # 技能说明文件，必填 ├── scripts/ # 可选，辅助脚本 ├── resources/ # 可选，参考文档或模板 └── skills/ # 可选，嵌套子技能

重点是SKILL.md这个文件。它的 YAML frontmatter 一般长这样：

--- name: my-skill description: 这个技能用于处理某某类型的任务。当用户提出某某需求时使用。 ---

name是技能的标识，description是 AI 判断何时调用该技能的依据。description 写得好不好，直接决定了自动调用的准确率——写得太笼统，AI 容易在无关场景里触发它；写得太狭窄，AI 又会在该用的时候忽略它。

5.2 一个完整 SKILL.md 的字段拆解

正文部分，就是我前面说的"岗位 SOP"。拿一个简单的例子来说，假设我想给 AI 定义一套"发布前检查清单"技能：

## 执行流程 1. 读取当前分支的变更文件清单，确认没有未提交的临时文件 2. 检查所有新增的环境变量是否已在配置文档中登记 3. 运行测试套件，确认全部通过 4. 扫描代码中是否残留调试输出（console.log、print、debugger） 5. 确认 CHANGELOG 已更新，并写明变更描述 6. 输出一份发布检查报告，标明每项检查的结果：通过/未通过/跳过 ## 注意事项 - 第 2 项如果发现未登记的变量，不要直接修改代码，先询问我是否需要补充登记 - 第 4 项扫描结果里包含误报时，逐一说明理由，不能静默跳过 - 所有检查项必须给出明确的证据，不要使用"看起来没问题"这种模糊结论

把文件保存到~/.claude/skills/release-check/SKILL.md，然后重启 Claude Code，这个技能就被加载了。我在自己的团队里做过类似的东西，把代码风格规范、数据库迁移步骤、接口设计约定都写成了技能，效果比发文档给同事背好得多。

5.3 依赖、资源与子技能的组织方式

进阶用法是给技能配置资源和子技能。

比如你的技能在执行过程中需要参考一份公司内部的编码规范文档，可以放在resources/目录下，并在SKILL.md里用相对路径引用。AI 需要的时候会主动去读这份文档。

如果某个流程足够复杂，可以拆成多个子技能，形成层级关系。例如主技能"发布流程"可以拆成"测试检查""构建打包""部署验证"三个子技能，每个子技能一个目录，主技能的文件里按顺序调用它们。

这种组织方式的好处是可复用性。子技能可以在不同主技能之间共享，比如"构建打包"既可以被"日常开发"流程调用，也可以被"发布流程"调用。不用重复写，修改时也只需要改一处。

5.4 从"能用"到"好用"的迭代方法

自定义技能想写得好，我自己的经验是：不要一次追求完美，先写一版能跑的，然后靠实际使用反馈迭代。

第一版技能往往写得过于理想化——步骤很多、条件很多，但你很快会发现 AI 在某个环节频繁卡住，或者某个检查项根本不适用。这时候就回来改SKILL.md，把它变得更精简、更贴合实际。

我有个自己写的"数据库迁移"技能，改了七八个版本才稳定下来。第一版我写了一大堆安全检查和备份步骤，结果 AI 每跑一次都要问我两三个问题，烦得很。后来我把一些明确可以默认的值写死在技能里，只在真正出现模糊性的地方才提问，效率立刻上来了。

这个迭代过程本身就是 Superpowers 的核心理念：你通过不断编辑技能文件，把对 AI 的调教结果沉淀下来。今天你为了让 AI 正确完成某个操作而额外补充的那句提示，完全可以写进技能里，让它明天自动照做。

6. 用了两个月的教训与心得

6.1 这些坑我真实踩过

将近两个月用下来，有四个问题我认为值得单独拎出来讲。

第一个坑：技能描述太宽泛，导致 AI 频繁误触发。我有个同事给技能写的 description 是"处理任何与代码质量相关的事情"。结果 AI 几乎每个任务都会调用这个技能，然后技能本身又什么都管，反而把简单的事情搞复杂了。后来我把 description 改成非常具体的触发条件，比如"当用户要求审查代码、重构代码或者评估技术方案时使用"，误触发率明显下降。

第二个坑：技能步骤要求太死板，AI 会"为了走流程而走流程"。我一开始写的技能里要求 AI 每步都输出详细报告，结果它花大量时间生成格式完美的报告，却忽略了实际任务。后来我在技能里加了一条规则："如果某一步的结论不影响后续决策，可以一句话带过，不用展开"。

第三个坑：旧技能没有及时清理。项目迭代之后，某些技能描述的技术方案已经过时，但 AI 还是会调用它，导致给出的建议跟当前代码架构不匹配。这块儿没有银弹，只能靠定期回顾技能目录，删掉没用的、更新过时的。

第四个坑：并行子代理的资料共享问题。异步 subagents 之间如果存在共享数据依赖，容易出现"各改各的、最后合不上"的情况。用 subagents 技术之前，务必确认任务之间的边界足够清晰。

6.2 什么项目最适合用它

基于我的使用体验，Superpowers 最适合的场景是中等以上复杂度、需要多步骤完成的工程任务——功能模块开发、代码重构、bug 系统排查、代码评审。这些任务里 AI 最大的问题是"缺乏节奏感"，而技能恰好能补上节奏。

反而不太适合的场景是那种一次性小任务，比如"把这个字符串格式改一下"“给这个函数加个参数”。这种场景下技能反而显得累赘——AI 花在走流程上的精力比干活还多。

另外一点，如果你是团队负责人，Superpowers 的价值会被放大。因为它把"个人经验"变成了"团队资产"。团队里任何一个人踩过的坑、总结出的写代码规范，都可以固化成技能文件，其他同事的 AI 就能直接复用。这比发文档、开分享会要有效得多。

6.3 我的个人使用建议

最后聊几个具体操作层面的建议。

第一，装完之后先别急着干活，花十分钟把自己常用的几个技能看一遍，了解每个技能大致干什么、什么时候触发。你越了解它，你越知道怎么指挥 AI 切换技能。

第二，手动指定的优先级永远高于自动调度。当你带着明确目的使用 AI 时，直接说出要用的技能名称，不要依赖 AI 自己判断。自动调度属于兜底方案，适合你也不太确定该怎么下手的时候。

第三，把技能文件纳入你的版本控制。我的~/.claude/skills目录是挂在 Git 仓库里的。改坏了可以回滚，跟同事同步也方便。尤其是自定义技能，一旦丢失重写一遍的成本很高。

第四，保持简单。技能的价值在于稳定复现，而不是功能大而全。一个技能如果超过十个步骤，我建议拆成两三个子技能，否则 AI 执行到后面容易丢掉开头的上下文。

我现在的日常节奏已经完全是"技能驱动"的了：任何开发任务进来，先让 AI 跑 brainstorming 理清思路，再 writing-plans 出计划，然后 TDD 一步步实现。AI 还是那个 AI，代码能力没有变强，但因为每一步都按流程走，输出质量肉眼可见地稳定了下来。如果你也在用 agent 模式写代码，并且经常被"AI 太着急动手"困扰，我建议你花十分钟装一下 Superpowers，然后试着让它在某个中等任务上全流程跑一遍——你大概率会刷新对 agent 能力的认知。