企业官网建设流程全解析

1. superpowers 到底是什么，它和普通插件有什么区别

1.1 一个仓库，几十个“技能包”

如果你最近在看 AI 编程助手的使用技巧，大概率会刷到 superpowers 这个词。我第一次看到这个仓库时，以为它又是一个“一键生成项目”的脚手架，用了一段时间才发现，它其实是一套给 Claude Code 这类 AI 工具准备的技能包合集，安装之后，AI 不再是只会顺着你话说的通用模型，而是一个能走完头脑风暴、写计划、TDD、复盘全流程的虚拟同事。

它最核心的东西是 Skills 概念。每一个技能本质上就是一个文件夹，文件夹里有一个SKILL.md文件。这个文件先通过 YAML 头告诉 AI：我叫什么、什么时候该用我；再用一段正文写出完整的工作流程、执行步骤、注意事项。举个例子，brainstorming技能会在正文里要求 AI 先澄清目标，再做发散、收敛、风险评估，最后给出方案对比，而不是直接甩一个答案。

把整个 superpowers 装好之后，你的 AI 手里就有了一批可以随取随用的“操作手册”：做计划、拆步骤、写测试、跑复盘、写文档、做代码审查。需要注意，这些技能不是普通提示词模板，而是通过框架约定被 AI 自动识别并加载的。当你问的话命中某个技能的场景时，AI 会主动读取对应的SKILL.md，然后照着上面的流程执行。整个过程不需要你在每次提问时复制粘贴一堆规则。

作者是 Jesse Vincent，仓库在 GitHub 上叫obra/superpowers。这个项目早期主要面向 Claude Code，后来因为很多支持 Agent Skills 的工具都兼容同一套格式，适用范围也跟着扩大了。

1.2 为什么“给 AI 发技能手册”比调 prompt 更靠谱

以前调 AI，大家习惯在 system prompt 里堆规则：你要先分析、再规划、然后写代码，最后检查。但 prompt 越长，AI 越容易把关键约束忽略掉，有时候甚至前后矛盾。superpowers 的核心思路完全不同：它把任务拆成独立的小手册，按需使用，而不是让 AI 在几万字的 prompt 里大海捞针。

这就像你给一个新同事发了一本《常见问题手册》，遇到纠纷翻第 3 页，遇到客户投诉翻第 7 页，而不是让 TA 把整本手册倒背如流。只有遇到对应场景时，AI 才会去翻那一页，这样上下文更干净，执行也更稳定。

另一个优势是技能之间可以编排。brainstorming 先把需求想清楚，writing-plans 把方案落地成可执行计划，executing-plans 负责按计划逐项推进，test-driven-development 保证每一段代码都有测试兜底。技能串联起来之后，整个开发流程会像一条流水线，AI 也很少再出现“答了一半突然跑偏”的问题。

这套东西对谁最有价值？我觉得是两类人。一类是重度使用 Claude Code 的开发者，想在项目里建立一套稳定的 AI 工作流；另一类是刚接触 Agent Skills 的新手，想搞明白“给 AI 安装技能”到底是什么体验。如果你只是偶尔让 AI 写一段一次性脚本，那可能用不上全家桶，但挑几个常用技能装上，也能明显提升回答质量。

2. 安装前的准备和目录约定

2.1 环境要求：哪些工具能跑这套技能

我目前用得最顺的是 Claude Code，superpowers 对它的支持也最完整。其实只要是能识别 Agent Skills 目录的工具都可以尝试，比如 Cursor 的较新版本也对SKILL.md有兼容。你在安装之前，最好先确认你用的工具到底读取哪个目录，不同工具的约定并不完全一样。

以 Claude Code 为例，它支持两个位置的技能目录：用户级目录~/.claude/skills和项目级目录.claude/skills。前者对所有项目生效，后者只对当前项目生效。Cursor 通常读取项目里的.cursor/skills或者对应版本的 agent 配置目录，具体路径要以官方文档为准，因为这类目录结构更新得很快。

我的建议是：第一次玩，直接用 Claude Code 跑通。它的路径明确、日志清晰，报错也直观。等你在一个工具上把机制理解透了，再迁移到其他工具上，本质上只是把技能文件夹复制到对应目录的事情，没有太多学习成本。

2.2 全局技能目录和项目技能目录怎么选

选全局还是项目级，取决于这个技能是不是和特定代码库强绑定。像 brainstorming、writing-plans、test-driven-development 这类通用技能，放~/.claude/skills更合适，因为你在任何项目里都可能用到。而某个项目特有的数据库操作约定、部署脚本、代码风格规范，就应该放.claude/skills，这样团队成员一起维护时，行为才一致。

还有一点需要注意：同一个技能如果同时存在全局和项目级，不同工具的优先级可能不一样。我遇到过项目级覆盖全局的情况，也遇到过反过来。最稳妥的做法是不要同时放着同名但内容不同的技能，否则 AI 可能加载到一份你根本不想用的旧版本。

注意：在动手安装之前，先想清楚你的使用场景。如果你只在一个项目里试验，先放项目级目录；如果确定希望所有项目都拥有这套能力，再放全局目录。不要一上来就全盘复制，后面维护起来会有点乱。

3. 安装 superpowers 的两种实操方式

3.1 最稳妥：手动 clone 并平铺技能目录

安装其实不复杂，但有几个细节很容易踩坑，我一个个说。第一步，把仓库克隆到本地临时目录：

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

克隆完成之后，先不要急着复制，打开看下目录结构：

find /tmp/superpowers -maxdepth 2 -name SKILL.md

正常情况下，你会看到仓库里有一个skills/文件夹，里面的每个子目录都是一个独立技能，每个技能目录下都包含一个SKILL.md。正常的技能目录结构是：skills/brainstorming/SKILL.md、skills/writing-plans/SKILL.md，以此类推。

接下来，创建一个全局技能目录，并把skills/下面的一级子目录全部复制过去：

mkdir -p "$HOME/.claude/skills" cp -r /tmp/superpowers/skills/* "$HOME/.claude/skills/"

如果你只想安装其中几个技能，不要用*，直接逐个复制目录就行，比如：

cp -r /tmp/superpowers/skills/brainstorming "$HOME/.claude/skills/" cp -r /tmp/superpowers/skills/writing-plans "$HOME/.claude/skills/"

为什么强调“平铺”？因为 Claude Code 在识别技能时，会扫描技能根目录下的第一层子目录，每个第一层子目录必须直接包含SKILL.md，它才认为这是一个技能。如果你直接把整个 superpowers 仓库文件夹丢进~/.claude/skills，路径就变成了~/.claude/skills/superpowers/skills/brainstorming/SKILL.md，技能层级深了一层，AI 很可能识别不到。这个坑我在第一次安装时就遇到过，装完之后怎么调都不生效，后来才发现是目录层级的问题。

3.2 更省心：用软链实现“一次安装，随时更新”

手动复制有个问题：上游仓库更新了，你只能再拉一次、再复制一次。有些技能迭代很快，频繁复制比较麻烦。我的做法是使用软链接，把克隆目录固定放在一个地方，技能目录通过链接指过去，这样只要在仓库里git pull，所有技能自动更新。

git clone https://github.com/obra/superpowers ~/repos/superpowers mkdir -p "$HOME/.claude/skills" for d in ~/repos/superpowers/skills/*; do ln -s "$d" "$HOME/.claude/skills/$(basename "$d")" done

这段脚本会在~/.claude/skills下生成一堆指向~/repos/superpowers/skills/下各子目录的符号链接。之后每次想更新，直接：

cd ~/repos/superpowers && git pull

所有软链接指向的内容会同步更新，不用再手动复制。Windows 用户可以打开 PowerShell，用New-Item -ItemType SymbolicLink -Path ... -Target ...逐个创建链接，也可以直接用cmd /c mklink /D，效果一样。

软链接的方式也有代价：如果你把克隆目录删了或者移动到别处，技能也跟着失效。所以克隆目录的位置最好固定，别今天放桌面、明天放临时目录。另外，如果是团队共享项目，我不建议用软链，直接把技能放到项目目录里提交到 git 更可控，团队别人 clone 下来就能用，不需要各自配置。

4. 到底有哪些 skills，怎么按需选配

4.1 常用技能清单与使用场景

我在实测中比较常用的几个技能，大致可以分成下面几类。不同版本清单会有些增删，但核心思路是一样的，每个技能都针对一个特定任务场景。

这些技能并不是互相独立的。比如你接到一个需求，先让 AI 用 brainstorming 发散思路，确定方案后，再用 writing-plans 生成计划文件，最后用 executing-plans 把计划拆成具体任务逐项执行。整个过程像是把几个技能拼成了一条工作流。

4.2 单项目引入还是全家桶引入

有些朋友装完 superpowers 会很兴奋，把所有技能全塞进目录，然后发现 AI 反而变笨了：你让它改一段代码，它可能会先跑出一个 investigation 流程，搞得像要破案一样。原因很简单，技能太多，每个技能都有自己的 description，AI 在匹配时会出现“选择困难”，甚至把不相关的技能读进上下文，既浪费 token，又拖慢响应。

我的建议是：按当前阶段挑 6-10 个最常用的装全局，其余暂时不装。比如这一周在写新功能，那就装 brainstorming、writing-plans、executing-plans、test-driven-development、code-review、debugging；下周转去做文档整理，就把 writing、documentation 也放进项目级目录。

按需引入有两种方式。第一种是只复制你需要的技能目录，不要让多余技能出现在扫描范围内。第二种是即使技能目录存在，也要在提示语里强制指定，比如直接说“使用 test-driven-development 技能来完成这个功能”，这通常比让 AI 自己猜更稳。

5. 让 AI 真正调用技能：一次完整工作流演示

5.1 核心工作流：从头脑风暴到执行计划

只看不练没法真正理解这套东西，我带大家走一遍真实场景。假设我要给博客加一个 RSS 输出功能，以前的我会直接问 AI“怎么给博客加 RSS”，它大概率会噼里啪啦给出一堆方案。现在有了 superpowers，流程完全变样。

第一步，我先输入：“帮我想想给博客加 RSS 的方案，使用 brainstorming 技能。”AI 会先加载 brainstorming 技能，然后按照技能文档里的流程走：先问我目标读者是谁、希望输出格式是什么、是否需要按分类聚合；再让我补充现有博客的技术栈；最后给我两到三个方案做对比，并标出每个方案的优缺点。

第二步，我输入：“把选定的方案用 writing-plans 技能写成执行计划。”这时 AI 会生成一份 markdown 计划文件，放到类似plans/的目录里。计划里的每个任务都有一个编号和完成状态，比如“第一步：创建 RSS 生成模块”“第二步：添加路由”“第三步：编写测试”，每项都可以单独勾选，方便后续跟踪。

第三步，我输入：“按计划执行，使用 test-driven-development 技能。”AI 就会回到计划文件里，从第一个任务开始，先写失败测试，再写实现代码让测试变绿，然后再进入下一个任务。如果中途某个测试一直不过，它可能会自动调用 debugging 技能去排查，而不是硬着头皮把代码写完。

这里最关键的一点是：不要指望 AI 自动跑完整条流水线。你需要逐步指定当前阶段使用哪个技能，或者在第一句话里把整条链路说清楚。如果一句话包含全部需求，AI 有时会跳过计划环节直接动手，反而把系统设计初衷给丢了。

5.2 怎么判断 AI 有没有用上技能

很多人在安装后最困惑的是：我怎么知道 AI 到底有没有真的加载技能？在 Claude Code 里，当某个技能被加载时，界面上会有比较明显的提示，类似Loading skill: brainstorming。如果你使用过程中完全没看到这类提示，说明技能可能没有被触发。

如果你用的是其他兼容工具，可以打开 verbose 模式，或者在日志里查看技能加载记录。还有一个笨但有效的测试方法：安装一个只有几行内容的自定义测试技能，SKILL.md 中强制要求 AI“每次回答前先输出一个固定字符串，比如 SUPER_POWER_OK”。之后你随便问一个问题，如果 AI 输出了这个字符串，就证明技能机制已经生效。这个方法我在排查问题时经常用，能快速区分“技能没装成功”和“技能没被触发”。

5.3 写一个自己的 SKILL.md 示例

理解了机制之后，你完全可以写自己的技能。下面是一个最小可用的SKILL.md示例，用于让 AI 生成规范化 Git 提交信息：

--- name: commit-message description: 当用户要求写 Git 提交信息，或者需要根据暂存区改动生成 commit message 时使用。适用于任何包含 version control 的代码库。 --- # Commit Message Skill 1. 先运行 `git diff --staged` 查看暂存区改动。 2. 分析改动涉及的功能模块、修改类型和影响范围。 3. 按 Conventional Commits 规范生成提交信息，格式为 `type(scope): subject`。 4. 输出 3 条候选信息，并说明推荐哪一条、为什么。

注意几个细节。name要短，最好用英文小写和连字符，不要有空格。description是整个技能的灵魂，它决定了 AI 什么时候会读这个技能，所以要把触发场景写清楚，甚至可以写上“当用户说‘帮我写 commit’、‘生成提交信息’时使用”这类具体表达。YAML 头下面的正文，步骤要明确、可执行，也可以引用项目内的文件路径，但不要依赖太强的假设，否则换一个项目就不适用了。

把这段内容保存到某个目录，比如~/.claude/skills/commit-message/SKILL.md，再重启会话，你的 AI 就多了这个技能。之后只要涉及提交信息，它就会自动按这个规范输出。

6. 常见问题与排查技巧实录

6.1 装完没反应的 4 个检查点

安装后最常遇到的问题就是：明明装了，AI 却没有任何反应。根据我的经验，按下面四个检查点排查，基本能解决九成问题。

第一，目录位置对不对。Claude Code 认的是~/.claude/skills和项目下的.claude/skills，不是别的自定义目录。检查命令：

find ~/.claude/skills -maxdepth 2 -name SKILL.md

正常情况下应该能看到每个技能目录下的 SKILL.md 文件。如果输出为空，说明目录层级不对或者根本没有复制进去。

第二，文件名是不是SKILL.md。这里的文件名必须全大写，不能写成skill.md或SKILL.MD。很多工具在匹配时区分大小写，文件名不对就会直接跳过。

第三，有没有重启会话。技能目录的扫描通常发生在会话启动阶段，如果你是在当前会话中间安装的，AI 可能不会立刻感知到。新开一个会话再去提问，往往就正常了。

第四，触发词有没有对得上。技能是靠description里的关键词匹配的，如果你问“帮我想几个思路”，但技能描述里写的是“当用户要写详细计划时使用”，AI 就不会加载。遇到这种情况，直接在问题里加上“使用 brainstorming 技能”这种明确指示，比让它自己猜要可靠得多。

提示：如果你装了技能但效果不明显，先不要怀疑工具坏了。很多时候是技能本身没有触发，但 AI 依靠通用能力也能完成简单任务，所以你看不出差别。先用测试技能验证机制是否生效，再回到真实业务场景。

6.2 技能冲突、更新覆盖与自定义

superpowers 更新频率不算低，直接git pull固然方便，但如果你改过技能内容，更新时可能会被上游覆盖。我的做法是：把自定义技能放在单独目录，比如~/.claude/skills-custom/，不跟 superpowers 混在一起。需要保留原版技能时，就复制一份出来，改名为brainstorming-custom，再调整里面的流程。这样即使上游更新，也不会把你改过的版本冲掉。

如果你发现 AI 行为很奇怪，也可以检查是不是存在同名技能冲突。比如全局目录有一个writing，项目目录又有一个writing，这两个内容不一致时，工具加载哪个完全看它的优先逻辑，结果很可能不可控。检查方法很简单：

ls ~/.claude/skills ls .claude/skills

看到同名目录后，要么删除一个，要么把其中一个重命名。团队协作时，建议固定技能版本，并把项目级技能目录纳入 git 管理，这样大家都用同一套规则，不会出现“同一个功能，AI 在不同人手里行为不一样”的尴尬。

6.3 安全提醒：第三方技能别盲装

最后聊一个容易被忽视的问题：安全。技能的本质是给 AI 一段“操作手册”，里面很可能包含建议执行的命令、建议修改的文件路径。如果它来自不可信的第三方，等于你把 AI 的操作许可交给了一份你不了解的手册。安装前，花几秒钟打开SKILL.md看看它要 AI 跑什么命令、读写什么路径，再决定要不要用。

我在安装任何第三方技能前，会在沙箱项目里先调用一次，确认它不会执行危险命令、不会向外部接口发送数据，然后才放进主力目录。这个习惯和安装 npm 包前看一眼 package.json 是一个道理。像 superpowers 这种社区热度高的项目，相对可信度会高一些，但依然建议你保持这个审阅习惯。

我个人在实际操作中体会最深的一点是：superpowers 的价值不只是让 AI 多会几个技巧，而是逼着你把“你想让 AI 怎么做”这件事想清楚。每装一个技能，你都在定义一类任务的标准流程。装多了以后，你会慢慢形成自己的工作流体系，而不是让 AI 每次随机应变。这也是为什么我更推荐你从最小集合开始，把几个核心技能用熟，再决定要不要扩充。