企业官网建设流程全解析

1. superpowers 究竟是什么：先跑起来再理解的安装路径

我最初看到 superpowers 这个项目名时，第一反应是"又一个名字唬人的工具"。直到有一天发现朋友圈里好几个人在说"今天让 Claude 用 superpowers 帮我重构了整个模块"，我才认真去翻了仓库。坦白讲，它确实配得上这个名字——它把 Claude Code 的能力从"一问一答的对话式工具"变成了"可调用的技能库"，这是两者之间最本质的差别。

如果你现在打开 Claude Code，输入"帮我把这个项目里所有的 TODO 都找出来"，它能做到，但每次都要重新解释一遍需求。而装了 superpowers 之后，你可以直接说"用 read_files 技能扫描项目中的 TODO 标记并按模块输出报告"，它就知道该读哪些文件、按什么格式汇总、要不要生成 Markdown 表格。省掉的不只是打字时间，而是你反复描述上下文的整个沟通成本。

这篇文章我会按照自己实际入手的顺序来写：先讲怎么装，再拆解它到底自带了哪些 skills，然后讲清楚"引入一个技能"这件事背后的文件级原理，最后把我踩过的坑和一套推荐用法分享出来。适合正在用 Claude Code、但觉得"总差那么点意思"的人，也适合刚接触技能概念、想做自定义扩展的小白。

1.1 先搞明白它是"技能包"而不是"插件"

很多人习惯把它类比成 VS Code 插件，这个类比部分正确但会误导你。VS Code 插件是一段常驻的程序，装了就一直在后端跑。superpowers 不一样，它本质上是一堆结构化的 Markdown 文件，外加少量配套脚本。每个技能就是一个目录，目录里有一个SKILL.md作为入口说明，Claude Code 在对话中根据你的指令动态决定要不要去读这个文件、读完再决定是否调用。

这个"动态读取"的设计是 superpowers 的灵魂。你装完它，系统不会变卡，也不会抢占上下文窗口——只有当技能被显式或隐式触发时，对应的SKILL.md才会被读入对话上下文。这就像你书架上多了几十本手册，平时不占桌面空间，需要查的时候才抽出来翻。

理解了这一点，后面"怎么引入技能"的所有操作就都好懂了：所谓引入，本质上就是写一个符合规范的SKILL.md，再把它放到读得到的位置。没有魔法，纯粹是文件约定。

1.2 安装前的环境确认：三件事没到位先别动手

我的建议是安装前先花三分钟确认环境，不然中途报错会浪费很多时间。需要检查的就三样：

这三项里最容易出问题的是 Node 版本。我早期装的时候用的还是 Node 16，安装脚本跑到一半会因为某些语法不兼容直接中断，报错信息也不直观。如果你的环境是 18 或 20 就没有这个烦恼了。另外建议在干净的目录下操作，别刚开一个大型项目就直接装，我见过有人在某个项目目录里执行安装脚本，结果把一堆技能文件混进了项目仓库，让 Git 状态变得很难看。

2. 完整安装流程：两种方式都跑一遍，总有一种适合你

superpowers 的安装路径不复杂，官方提供了两种方式：git clone本地安装，以及远程管道直接执行脚本。我两个都试过，这里把关键细节和差异说清楚。

2.1 方式一：git clone 本地安装（推荐，可控性最强）

这是我最推荐的方式，因为你拿到的不只是安装结果，还有整个项目源码，方便你看结构、改配置、甚至二次开发。步骤很简单：

# 找一个你打算长期存放工具的目录，比如 ~/tools cd ~/tools # 克隆仓库 git clone https://github.com/obra/superpowers.git # 进入目录 cd superpowers # 执行安装脚本 ./install.sh

安装脚本运行期间，终端会打印出"正在创建技能目录""正在复制技能文件"之类的日志。我建议先别急着做别的事，盯一下输出，一旦有permission denied的报错就说明该chmod +x install.sh了。全程耗时一般在几十秒内，取决于你的磁盘速度。

需要注意：这个目录一旦装上就不要随便移动。我吃过一次亏，装完后觉得 ~/tools/superpowers 不舒服，把它挪到了 ~/dev/tools/ 下，结果发现它通过绝对路径或固定相对路径引用了技能源文件，移动之后重跑一次 install 才恢复。别折腾路径，装在哪就让它待在哪。

2.2 方式二：远程管道安装，适合快速上手验证

如果你只想先看看效果、不打算研究源码，远程安装会更省事。官方推荐的命令大致是：

curl -fsSL https://superpowers.obra.dev/install.sh | bash

这行命令把安装脚本拉下来直接执行。两分钟就能装完，然后你可以马上开 Claude Code 试一个技能。

但这其中有三个值得注意的地方。第一，管道执行第三方脚本本身就是一种信任行为，我只有在确认项目社区活跃、反馈良好的情况下才敢这么干，你要提前看一下这个 URL 是否可访问，别在任何不确定环境里盲跑。第二，远程安装默认也会把仓库克隆到本地某个位置，所以最终还是需要 Git，环境检查那一步省不掉。第三，如果你所在网络访问该域名慢或不通，就老老实实走 git clone 那条路，没必要死磕。

2.3 安装完成后的验证与技能目录结构

装完之后，怎么确认真的成功？你只需要打开 Claude Code，直接问一句："你现在知道 superpowers 吗？如果你有 skills 就列出来。"

如果它回答出技能名称（比如read_files、browser），说明安装生效了。另一个更硬性的确认方式是直接看磁盘：

ls ~/.claude/skills/

正常情况下你会看到一排技能目录，每个目录对应一个技能。我机器上大致是这个样子：

~/.claude/skills/ ├── read_files/ ├── write_files/ ├── run_commands/ ├── browser/ ├── screenshot/ ├── create_skill/ ├── improve_skill/ └── ...

这个目录是所有技能生效的关键位置。Claude Code 在会话中会感知到这个目录的存在，当你的指令命中某个技能的关键描述时，它就会去对应目录读取SKILL.md，然后按里面的指引执行。如果你将来想手动加技能，往这个目录塞一个新文件夹就行，完全不需要改注册表、不需要刷新服务——下次对话自动生效。

3. 技能清单与我的使用排序：哪些 skills 值得第一时间用起来

很多人装完 superpowers 后的第一个问题是："这么多技能，我到底该先用哪个？"这题没有唯一答案，但我可以根据自己的实际使用频次，给你一个足够靠谱的优先级参考。

3.1 第一梯队：read_files、write_files、run_commands，三个就够日常工作

这三个技能是整个技能库的地基。它们干的事情，本质上是让 Claude Code 的"文件读写和命令执行"从随机应变变成稳定流程。

read_files让你的对话中"帮我看看某个文件"变成结构化行为：Claude 会按设定的行数范围、分批读取，而不是一次性把巨大文件塞进上下文。我自己维护一份几千行的日志和配置文件时，让 Claude "分段读完 Rewrite 一遍并标注风险点"，它靠的就是这个技能，读一半不会把上下文堵死，也不会莫名其妙漏掉中段内容。

write_files负责把 Claude 生成的内容落地到文件里。听起来简单，但没它的时候，Claude 经常把整段代码丢在小窗里让你手动复制——有了这个技能，你可以直接说"把刚才的重构结果写回 src/utils/parser.ts"，它自己知道怎么处理路径、要不要保留原文件备份、怎么处理已有文件冲突。这个技能配合权限确认，实操体验会好非常多。

run_commands则是让 Claude 能在你的批准下执行终端命令，自动跑测试、装依赖、查进程。我会让它跑npm test和git diff，测试返回结果后马上做下一步修复，整个循环非常顺。你一开始可以只给它开放白名单里的命令，例如测试和构建相关的，降低风险。

这三个技能一起用的时候，会形成很完美的闭环：读入代码 → 分析问题 → 修改代码 → 跑测试 → 根据测试结果再读再改。我在一个中型 Node 项目里修一个核心模块的 bug，全靠这个循环，整个过程中 Claude 几乎不需要我额外解释什么。

3.2 第二梯队：浏览器、截图，让 Claude 长出一双眼睛

我第一次用browser技能的时候真是有点惊喜。之前的 Claude Code 是完全"看不见"界面的，我给它一个报错截图，它只能根据我描述来猜。有了browser和screenshot技能，它能打开指定的网页，截图给你看，甚至能返回页面的 DOM 结构信息。

于是有些以前很烦人的操作就变得自然了：我写前端布局总是对不齐，现在直接让 Claude 用 browser 打开 localhost 页面，自己看一眼渲染结果，然后回来告诉我"左侧导航宽度溢出，栅格类没生效"，接着它自己写 CSS 修复，改完再截一张图确认。这个"看-改-验"闭环省掉了我无数来回切窗口的时间。

browser和screenshot一般是一起用的。前者负责打开和交互，后者负责截取当前浏览画面。注意，两者都依赖本机有可用的浏览器环境，如果你用的是无头服务器，要提前配好 Chromium 之类的基础环境，不然技能会自动失败，报错还可能让你一头雾水。

3.3 第三梯队：create_skill 与 improve_skill，把 Claude 变成你的 "技能作者"

真正让我觉得 superpowers 这个项目了不起的，是它内置了"制造技能"的技能。create_skill让你用对话的方式生成一个全新的技能模板；improve_skill能根据你日常使用反馈来迭代已有技能。这两个算是元技能，用得好，你的技能库就会随着使用越来越多、越来越好用。

我第一次用create_skill做了一个"代码审查"技能：告诉 Claude 我希望它按安全、性能、可读性、边界条件四个维度审查代码，输出格式是表格，每条都要给出修改建议。结果它自动生成了一套目录和SKILL.md，放在~/.claude/skills/code_review/下面，之后我随时说"用 code_review 技能看下这段代码"，它就会按我定义的维度执行。这个体验太好了，等于把自己的隐性知识沉淀成了可复用的资产。

improve_skill则适合在你使用过程中发现问题时用，比如"read_files 读大文件时有时候会截断，加一个自动判断文件大小的前置步骤"，它会同步更新技能定义，这种"用后即改"的感觉非常舒服。

4. 技能引入链路拆解：从 SKILL.md 到实际生效

前面讲过，superpowers 的本质是文件级的技能约定。但你光知道这个还不够，想真正灵活运用，还得理解一个技能从创建到实际生效的完整链路，以及为什么有些技能"引不进去"。

4.1 一个标准技能目录的组成与最小示例

我自定义过不少技能，可以给你一个最精简的模板。假设我想给 Claude 定义一个"生成项目周报"的技能：

~/.claude/skills/weekly_report/ ├── SKILL.md └── templates/ └── weekly_report_template.md

核心是SKILL.md，它用 Markdown 书写，包含 frontmatter（元信息区）和正文。frontmatter 里至少要指明技能名称和描述，这个描述是 Claude 判断"什么时候该调用我"的关键。下面是一份极简示例：

--- name: weekly_report description: When the user asks to generate a weekly progress report, scan the git log and project files, then create a Markdown report with completed items, in-progress items, risks, and next steps. --- # Weekly Report Skill Follow the template in `templates/weekly_report_template.md`. Use `git log --since=7.days --pretty=format:"%h %s"` to collect recent commits. Categorize each commit by area (feature, fix, refactor, docs). Identify risks based on any TODO/FIXME markers introduced this week.

生成技能后，重启或继续当前 Claude Code 会话，然后你说"生成这周的周报"。Claude 看到"周报"这个词，匹配到description里写的 "weekly progress report"，就主动去读~/.claude/skills/weekly_report/SKILL.md，接着按里面的步骤执行。整个过程不需要你手动加载任何东西，它自动完成"匹配-读取-执行"三连。

4.2 为什么技能一直不被触发？排查思路很重要

这是我在实践中遇到最多的问题：技能装了，放的位置也对，但 Claude 就是不调用。经过反复实验，我总结出四个高频原因，按出现概率排序：

1. description写得不够具体，匹配不上你的口语化指令。比如你把 description 写成 "Generate report"，但它实际应该是 "Generate a weekly status report including commits, issues, and next steps"。Claude 是语义匹配的，描述里有关键词越贴近用户的自然表达，触发越准。
2. 技能目录名和技能名称不一致。目录名weekly_report，但 SKILL.md 里的name写成weeklyreport，会导致引用错乱。保持两者一致是最稳的策略。
3. ~/.claude/skills/下有同名冲突。如果你装了两个同名技能，Claude 可能不知道选哪个，最后哪个都不触发。我建议安装前先确认目录中是否已有同名的旧目录，有就先备份再替换。
4. 在一次对话中反复引用同一种技能但一直失败，这时候 Claude 可能已经忘了这个技能。建议新起会话后再试一次，或者直接说"重新读取一下 xxx 技能的说明"来强制刷新。

排查这件事，最有效的手段是把 Claude 的思考过程打开，也就是 verbose 模式，观察它读到哪一步停止了。我曾经发现我的技能触发失败，是因为对话中途 Claude 尝试读了SKILL.md，但里面某个相对路径写错了，导致后续执行失败——这种报错不打开内部输出根本看不到。

4.3 子步骤与依赖：SKILL.md 里的脚本怎么管理

复杂技能往往需要调用外部脚本，或者分成多个子步骤执行。这时候最好不要把所有逻辑都堆在SKILL.md描述里，而是把脚本放到scripts/子目录，然后在文档中给明确指令。比如一个技能要执行数据处理：

skills/data_processor/ ├── SKILL.md └── scripts/ ├── transform.py └── validate.py

SKILL.md里只需要说明"先用 python scripts/transform.py 处理输入，再用 validate.py 验证输出"。这样做的好处是：文档负责"指挥"，脚本负责"干活"，Claude 在理解执行逻辑时不会被大段代码淹没。脚本路径尽量写相对路径，配合技能目录本身，这样技能包整体就能随意搬迁、拷贝到其他机器，不用担心硬编码路径失效。

5. 权限配置与安全边界：放开技能之前想清楚这几件事

superpowers 天然允许 Claude 调用你的文件系统和终端命令，这个能力有多强，风险就有多大。我的原则是：从最小权限开始，按需逐步放开，绝对不图省事直接给"完全自由"。

5.1 理解权限机制的默认逻辑

Claude Code 对命令执行是有确认机制的——默认情况下，危险操作会询问你。装了技能之后要注意一个坑：技能里的脚本会经由 Claude 去执行，而你看到的是"Claude 想运行 xxx 命令的提示"，不是"用户运行了 xxx 命令"。如果你习惯不看确认提示就一路回车，技能的风险会随之放大。

我自己的做法是：在本地环境使用--dangerously-skip-permissions这类模式时非常谨慎，宁可多几次确认，也不希望它擅自改动我却没察觉。日常开发只需要在配置里把特定命令或目录加入白名单（比如只允许它修改工作区里的 src 目录），这比完全放开安全得多。白名单配置可以写在~/.claude/settings.json里，针对项目目录再覆盖一份配置文件，这样不同项目之间的权限边界也很清晰。

5.2 允许的技能哪些可安全白名单化

根据我的实战经验，下面这几类命令白名单化以后，收益远大于风险：

我记忆里最惨的一次，是让 Claude 帮我换个端口配置，结果它把settings.json整个覆盖了，我本地折腾半天的环境配置全部丢掉。往事不堪回首，从那以后我对写文件类技能一律严格审查，重要文件强制先备份。

5.3 团队协作时的技能管理建议

如果你所在的团队也打算推广 superpowers 共享技能，可以建立一个私有的技能仓库（普通 Git 仓库即可），把标准技能目录~/.claude/skills/下的内容作为仓库内容管理，成员统一拉取。每个技能目录里的SKILL.md就是天然文档，新人看一眼就能理解这个技能定义了什么。版本管理上的习惯，我对技能的变更也会像代码一样走 PR 流程：改动技能描述、增加脚本、修正路径，都在分支上做，合并前让另一个成员审一下。

技能是有生命周期的。用了两三次后发现某个技能基本没被触发过，我就会清理掉或合并进其他技能。太多不用的技能只会增加上下文匹配的噪音——Claude 在判断该不该读你的SKILL.md时，会参考所有技能目录的 description。保持技能库的精简，就是在提高触发准确率。

6. 把它用出真正"超级能力"的几个习惯

最后聊一些更偏方法论的东西。工具和技能都是中性的，能发挥多大价值，取决于你怎么把它嵌入到日常工作流里。我自己总结出三个习惯，分享出来供你参考。

6.1 把"一次性指令"变成"可复用技能"

大多数人的用法是直接在对话里描述需求："帮我检查这份 JSON 的结构和类型定义是否一致。"说完就完了。但高价值的做法是，当你发现自己反复在向 Claude 提同一类需求时，就应该使用create_skill把这个需求固化成技能。

我举个真实例子。我每周都要整理项目依赖的版本更新情况，一开始我每次都要解释："检查 package.json 里的依赖，看看有没有新版本，有就列出差异和建议。"频率高了之后，我花十分钟用create_skill定义了一个dependency_checker技能，之后每周只有一句话："用 dependency_checker 检查一下。" 减少的不只是打字量，而是把"我怎么思考这件事"这个方法本身也固化下来了。

6.2 不定时用 improve_skill 给技能做版本升级

技能不是写完了就完事。我一般会在用技能遇到不满意时，直接说："这个技能输出的报告没有统计 xx 指标，improve_skill帮我升级一下。"然后它会根据我的建议调整SKILL.md里的步骤和输出格式，并提醒我下次生效需要新会话。整个过程像是对自己的助手做小步迭代，非常上瘾。

6.3 技能与场景的组合拳

单个技能往往解决单点问题，但我慢慢体会到，真正的高效率来自"技能的组合编排"。比如我之前接手一个遗留旧项目，流程是先run_commands跑一遍测试看现状，再用read_files读核心代码，然后用自定义的code_review技能分析隐患，最后用write_files一次性输出修复后的代码，期间发现需要新的方法，就用create_skill现场做一个。

这套组合打下来，以前需要周末加班梳理的工作，一个下午能梳理完大半。而且因为每个步骤都有明确的技能规范，Claude 的输出质量比临时发挥要稳定得多。

在我个人的实际体验里，superpowers 最让我惊叹的地方不是它提供了多少现成技能，而是它把"让 AI 按你的方法做事"这件事的门槛降到了极低。它给你的不只是几把好用的锤子，更是一个能造锤子的工作台。喜欢折腾的人，完全可以在它的基础上搭出一套专属于自己的 AI 工作流。

最后再分享一个细节。技能库成长到一定规模后，我养成了一个习惯：每个季度给~/.claude/skills/做一次整体梳理——删掉三个月没用过的、合并功能重叠的、把几个相关技能组织成技能组。这个梳理过程本身就是对自己工作方式的一次回顾。工具会越来越强，但真正让它发挥价值的，仍然是你对自己工作流的认识。