企业官网建设流程全解析

superpowers 这个词第一次出现在我工作流里的时候，我以为是哪个同事偷偷把游戏 Mod 装进了终端。后来真正跑起来才发现，它不是游戏里的金手指，而是一套把零散效率技巧、AI 提示词、开发工具配置打包成标准化“技能包”的开源框架。你可以一次性引入几十个 skill，也可以只要两三个；它解决的最大痛点就是：明明知道有更好的做法，却总因为配置成本太高而放弃。这篇文章我会把 superpowers 到底能干什么、有哪些 skills、怎么安装、怎么用、踩过哪些坑，全部摊开讲一遍，内容偏实操，适合那些已经厌倦了“收藏夹吃灰”的开发者、博主和效率工具重度用户。

1. superpowers 到底是个什么：不是玄学，是一套技能集合

1.1 为什么叫“超能力”：它的设计理念

我第一次看到 superpowers 的仓库说明时，里面有一句话我记得很清楚：不要制造新工具，要给现有工具装上超能力。它本质上是一个基于 YAML 和 Markdown 的技能定义体系，每个 skill 就是一组结构化的指令、脚本、上下文模板，可以被 AI 助手或命令行工具加载。你可以在里面定义一个“git 工作流”技能，告诉模型遇到冲突时先检查什么、再执行什么；也可以定义一个“周报生成”技能，把你的写作偏好、数据来源、固定格式全部封装进去。

它跟普通 dotfiles、脚本仓库最大的区别在于，它把“能力”做成了可安装、可组合的单元。传统做法是往.zshrc里堆 alias，或者把一大段提示词复制到聊天框里，时间一长又乱又没法维护。superpowers 的做法是每个 skill 自带元数据、触发条件和调用方式，你可以用命令单独启用或禁用，甚至让它在特定场景下自动加载。设计理念很像乐高：你不需要整个城堡，你只需要几块能拼出日常需求的积木。

这里我解释一下它和“插件”的区别。插件通常是某个宿主软件的扩展，必须依附在特定编辑器或框架里。superpowers 的 skill 是半自包含的，它以一个标准目录结构存在，里面有SKILL.md、config.yaml、scripts/等目录。无论是通过 CLI 直接调用，还是接入 AI 助手的上下文，它都共享同一份定义。所以你可以把它从一个工具迁到另一个工具，成本几乎为零。这也是为什么它看起来概念简单，但用起来后劲很足。

1.2 如果你还在犹豫，这套东西适合谁

我用了大概三周后，才逐渐摸清它的舒适区。如果你属于下面这几类人，superpowers 对你来说价值会很大。

第一类，日常需要和 AI 助手反复周旋的人。你每天要写邮件、写周报、写代码注释、整理会议纪要，但每次都重新写提示词，得到的回答像抽卡一样不稳定。superpowers 可以把这些重复劳动固化成 skill，每次调用都是同一套高质量指令，输出风格也统一了。

第二类，需要带团队或做知识沉淀的人。新同学入职，你不用再发一长串文档链接，直接给他一个 skill 包，代码审查规范、提测流程、环境配置说明全部内置。想规范团队输出的时候，这件事特别有用。

第三类，对终端和效率工具有探索欲的人。哪怕你暂时不接入 AI 助手，superpowers 自带的一批本地脚本也能帮你压缩日常操作，比如批量重命名、日志分析、端口清理，都封装好了，不用自己写。

当然，它不适合所有人。如果你平时工作流非常简单，只有两个固定操作，花半小时去配置一套技能框架确实是负担。工具是为复杂场景准备的，别为了炫技硬上。我的建议是，至少你已经意识到自己在做大量重复工作，再开始折腾它。

2. superpowers 的 skills 盘点：先搞清楚能拿到哪些能力

2.1 常用技能分类清单

打开 superpowers 的技能仓库，你会看到几十个甚至上百个 skill，名字五花八门。如果不做分类，第一次逛的人很容易看花眼。我按实际用途把它们分了五类，这里列一份我常用的清单。

光看这些名字，你可能觉得“这不就是一堆命令和模板吗？”对，本质上就是这样。但关键在于它们的可编程性。以code-review为例，它不只是给你一句“请审查代码”，而是内置了：审查看什么重点、安全红线有哪些、性能问题从哪几个角度切入、如何输出结构化结论。当你把这些都写进 skill 定义，AI 给出的回答自然比裸提示词高出一大截。

2.2 每个 skill 背后解决的真实问题

我详细拆解三个我目前每天都在用的技能，你看完就能理解它的颗粒度。

第一个是git-commit-message。我过去提交流程很随意，经常被同事吐槽 commit 信息写得像暗号。这个 skill 内置了 Conventional Commits 规范，把它加载到 AI 助手后，我只需要把git diff的结果贴过去，它会自动判断类型（feat、fix、docs、refactor），生成一句简洁的提交信息，还会检查有没有敏感信息混进 diff。它输出的内容比我手写要稳定得多。

第二个是weekly-report。这个 skill 的应用场景是每周五下午。它要求我先提供本周的事项列表，然后自动按“项目进度、问题风险、下一周计划”三段式整理。最有用的细节是它内置了“结果导向”的改写规则，会把“写了接口文档”这种描述自动改成“完成支付接口文档，覆盖 3 个异常场景”，对比感极其明显。

第三个是code-review。它不是简单地说“检查代码”，而是会先从 diff 里筛选出真正变更的文件，忽略无关格式改动；接着按业务逻辑、性能、安全性、可维护性四个维度分别打分，最后用“问题-影响-建议”的格式输出。这意味着同样的 AI 模型，加载了这个 skill 后，代码审查质量明显提升了一个档次。

你可能会问，这些 skills 是哪里来的？官方仓库提供了一批经过社区验证的通用技能，同时你也可以把个人沉淀的模板提交上去。我自己的经验是，真正好用的往往不是官方预置的那些，而是你根据自己的工作流微调过的版本。这个后面讲自定义时再展开。

3. 想装 superpowers？完整安装与初始化步骤

3.1 安装前的环境准备

安装 superpowers 之前，你需要确认三件事，避免装到一半发现缺依赖。

第一，操作系统。目前它官方支持 macOS 和主流 Linux 发行版，Windows 用户建议用 WSL2 或 Git Bash。我自己在 macOS 和 Ubuntu 上都跑过，流程一致。第二，运行时依赖。核心 CLI 需要 Node.js 18 以上版本，因为底层用到了较新的文件系统 API；如果你只打算以“技能包”形式配合 AI 助手使用，对 Node 版本的要求可以放宽，但要从源码跑起来还是建议装齐。第三，包管理器。它可以通过 npm、Homebrew 或直接拉源码安装，至少保证其中一个可用。

这里有个容易忽略的点：superpowers 的“安装”和你平时装软件不太一样。它包含两层，一层是命令行工具本身，另一层是技能内容仓库。工具负责管理和调度，技能仓库才是你真正要用的能力。很多人装完之后发现sp list看不到任何 skills，就是因为只装了工具、没拉取技能源。官方安装脚本通常会把两层一起处理，如果你是手动安装，记得单独执行技能源初始化。

检查环境时，我一般会跑这样一组命令：

node -v npm -v git --version

这三个命令的输出只要不是逻辑混乱的报错，基本上就可以往下走了。如果 Node 版本太低，建议直接用 nvm 装一个 LTS 版本，不要为了贪图系统自带版本而跳过升级，后面加载技能时很容易踩到语法不兼容的坑。

3.2 三种安装方式与选型建议

我实际用下来，主流安装方式有三种，适用场景不同，我一个个说。

方式一，npm 全局安装。这是最干净的方式，适合已经依赖 Node 生态的人。命令很简单：

npm install -g @superpowers/cli

装完直接执行sp --version，能输出版本号就说明工具层通了。npm 方式的优点是升级方便，一条命令搞定，卸载也干净；缺点是如果你的 Node 环境本身很乱，全局目录权限冲突会很折腾。

方式二，Homebrew 安装。macOS 用户如果不想让 npm 参与太多，可以用这条：

brew install superpowers

Homebrew 会把可执行文件放到独立目录，依赖管理更清晰。我个人对 brew 版本的评价是“省心但可能滞后”，因为有些技能更新很快，而 brew 公式的维护者不一定同步得那么及时。如果你是尝鲜型用户，推荐 npm 源。

方式三，源码安装。适合要二次开发的人，直接克隆仓库：

git clone https://github.com/superpowers/superpowers.git cd superpowers npm install npm run build npm link

这种方式最灵活，你可以改源码后立即生效。代价是你要主动跟进上游更新，否则本地分支容易和官方版本产生较大偏离。我建议只有准备提交 PR 或深度定制的人采用源码模式，日常使用选前两种就够了。

3.3 初始化与引入第一个 skill

工具装好后，接下来要初始化技能源。执行：

sp init

这个命令会做三件事：创建配置目录~/.superpowers/、拉取默认技能仓库到本地缓存、生成一份config.yaml。初始化完成后，我们可以先确认当前有哪些技能可用：

sp list

如果你能看出一列技能名称和描述，就说明整个链路已经通了。接下来引入第一个 skill，比如我想装weekly-report：

sp install weekly-report

装完之后，你可以用下面的命令查看这个 skill 的详细说明，里面会列出适用场景、输入要求和输出格式：

sp show weekly-report

所有安装动作结束后，配置文件里会多出active_skills列表，默认情况下新装的技能是启用的。如果不想一个个手动装，也可以直接在一条命令里声明多个技能名，空格分隔即可。我自己的习惯是先把常用的五六个一次装上，然后两周内逐步精减，最终留下真正高频的。

4. 具体使用：怎么把“超能力”变成日常习惯

4.1 命令行调用与交互操作

技能装好之后，最直接的使用方式是通过 CLI 调用。它的通用语法是：

sp run <skill-name> --input "<你的问题或数据>"

举个例子，我用code-review技能审查一段代码时，会先拿到改动差异，然后执行：

sp run code-review --input "$(git diff HEAD~1 --stat)"

它输出结果的格式通常分两部分：先是结论摘要，再是逐条问题列表。每条问题都带严重级别和修改建议，可以直接复制到代码评审平台。上述命令里，我用$(...)嵌套了 git 命令，省去复制粘贴的步骤，这也是这类 CLI 工具最舒服的地方——它不排斥 Unix 生态的组合，你可以把 superpowers 的命令和 grep、jq、awk 串成一条流水线。

除了整体调用，也可以进入交互模式：

sp chat weekly-report

它会启动一个带上下文的会话，你可以连续给多条信息，技能会记住之前的内容，不断修正输出。比如你先把本周事项列给它，它会先给一版草稿，你觉得某一部分太啰嗦，直接说“把风险部分再精简”，它会基于同一份上下文重新生成。这个体验比每次重复贴入同样背景信息舒服很多。

4.2 与主流 AI 助手配合使用

如果你更习惯在 AI 助手的对话框里工作，superpowers 也能融入进去。目前主流的接入方式有两种：提示词注入和 MCP 调用。

提示词注入最轻量。你只需要把某个 skill 对应的SKILL.md内容复制到对话的开头或者系统提示词里。很多 skill 的说明书都写得很完整，包括角色设定、输出规范、示例输出，复制进去后模型立刻能表现得像换了个人。缺点是每次会话都要粘贴，比较繁琐。

MCP 调用是更推荐的方案。通过配置 MCP server，AI 助手可以动态加载本地已安装的 skill。这里我在配置文件中加入下面这一段：

mcpServers: superpowers: command: "sp" args: ["mcp"]

重启 AI 助手的连接后，它会多出一个工具列表，里面就是所有已激活的 skill。模型在对话中判断你需要哪个能力时会自动调用，你甚至不需要感知到技能的存在，回答质量就上去了。这个方案对使用者最友好，但配置门槛稍高，需要你所在的 AI 客户端原生支持 MCP。好在目前主流的几款助手都已经或者正在加入这个协议，兼容性不是大问题。

4.3 让技能自动触发的小技巧

用了一周之后，我发现它的上限不在于“手动调用”，而在于“自动触发”。这里分享几个让我效率明显提升的配置方式。

第一个是别名映射。在配置文件里把长命令缩短：

aliases: review: "code-review" log-analy: "log-reader" week: "weekly-report"

之后执行sp run review即可，少敲不少字符。第二个是文件监听。你可以在某个目录下配置autotrigger，当检测到特定文件类型变化时自动执行某个技能。比如我在docs/目录下监听*.md文件修改，自动触发校对技能，调整语气和错别字。第三个是把 superpowers 接入到 shell 的 zsh 函数里，例如每次提交前自动调用 commit 信息生成器，我做了个微调：在pre-commit钩子里跑sp run git-commit-message --input "$(git diff --cached)"，它生成的提交信息直接写到临时文件，只等我确认。这样等于把规范长在了流程里，不需要依赖人的自觉。

5. 实操中踩过的坑：常见问题排查实录

5.1 安装失败的三类高频原因

安装阶段最常见的报错首推权限问题。npm 全局包默认安装到系统目录，如果你用普通用户执行，可能会看到EACCES错误。解决办法是不要急着加sudo，建议先检查 npm 的全局目录是否归属当前用户，重新配置 prefix 到用户目录下才是一劳永逸的做法。

第二个高频问题出在技能源拉取失败。superpowers 的默认技能仓库托管在 GitHub 上，国内部分网络环境访问不稳定，导致sp init一直卡在克隆阶段。这里的处理思路是配置代理或者更换加速镜像，但别去碰任何不该碰的软件，换用可信的镜像地址是最稳妥的。如果不行，也可以手动克隆技能仓库到本地缓存目录，再执行sp index --local重建索引，完全绕开实时网络依赖。

第三个坑是版本不匹配。比如 npm 上的 CLI 已经更新到 2.x，而技能仓库里的某个 skill 还依赖 1.x 的配置格式。症状是安装成功后sp run报“unknown field”或“missing config”错误。排查时先看 CLI 版本和技能要求的版本是否兼容：

sp --version sp outdated

如果确实存在大版本差异，优先升级 CLI，而不是手动改技能配置文件。

5.2 技能加载异常或响应不符合预期

有时候技能装上去了，但输出效果完全不是想象中那样。我碰到过一次最典型的情况是：加载了meeting-notes技能后，它生成的会议记录仍然没有结构，和普通对话一样杂乱。排查后发现，原因是我的配置文件里启用了多个写作类技能，它们对 AI 的提示词产生了互相干扰。多个 skill 同时被注入上下文时，某些互相冲突的指令会把模型弄糊涂。

解决方法是先做减法。在配置文件中临时禁用其他写作相关技能，只保留meeting-notes，对比输出结果。确认单独使用时效果正常后，再逐步开启其他技能，找出冲突的那一个。

另一个常见问题是技能输入格式不符合要求。很多 skill 在说明文档里规定了输入格式，比如必须传 JSON 或者 Markdown 列表，如果你传了一堆自由文本，parse 阶段就会报错，甚至直接放弃处理。这种情况下要先执行sp show <skill-name>查看示例输入，把内容按标准格式调整好再跑一遍。

5.3 权限、版本和网络问题速查表

我把平时运维和排障用到的关键检查项整理成了一张速查表，遇到问题先按表格逐项排查，不要一上来就重装。

这张表不是万能的，但它覆盖了我在社区里见到的大部分求助帖。记住一个原则：出现问题时先看日志，CLI 通常会把错误写入~/.superpowers/logs/目录，信息足够定位八成的问题。

6. 我的实操心得与后续扩展建议

6.1 从只装不用到深度融合的转变

如果你问我 superpowers 用了三个月最大的变化是什么，我会说不是某一个技能带来的效率提升，而是我评估工具的方式变了。以前装东西都是“这个看起来不错，装上再说”，结果装了一百个东西，每天用的还是那几个。superpowers 的 skill 机制让我开始认真审视：我手上的这套流程，是不是真的有必要存在？它能不能被拆成一个可复用的模块？

我现在的用法是：每周五下午花十分钟检查一次技能使用频率。如果某个 skill 已经连续三周没有调用了，我会先把它禁用而不是删除，以免后面突然需要时又要重新配置。这个习惯让我维护的技能数量一直控制在十到十五个之间，质量明显高于广度。

6.2 自研一个 skill 的完整路径

最后说一个很多人都会感兴趣的话题：怎么编写自己的 skill，把它发布给团队或社区使用。其实门槛不高，核心就是按规范建目录和文件，下面是一个最小示例。

你只需要创建一个这样的文件结构：

my-skill/ └── SKILL.md

然后在SKILL.md中写入：

--- name: my-skill description: 用于生成每日工作记录 version: 1.0.0 parameters: - name: input type: string required: true --- ## 角色 你是一名经验丰富的职场复盘教练。 ## 任务 根据用户输入的工作内容，生成一份结构化的每日工作记录。 ## 输出格式 - 今日完成： - 未完成与原因： - 明日计划： - 今日思考：

用以下命令安装到本地：

sp add ./my-skill

立即就能通过sp run my-skill --input "今天处理了..."调用。如果要发布给别人用，可以把目录推到 Git 仓库，其他用户只需要sp install git@github.com:xxx/my-skill.git即可。

这里我个人的建议是，编写 skill 时最难的不是格式，而是配置描述。描述信息越具体，AI 在什么场景下触发它就越准确。比如“生成工作记录”和“在每天下班前，根据用户列出的工作事项和遇到问题，生成一份简洁的日记录”是完全不同的清晰度。把描述定义得详细，这个 skill 才算真正有了灵性。

关于后续扩展，我觉得 superpowers 最有想象力的方向是把不同技能组合成完整的工作流，比如“读取日志 -> 定位异常 -> 生成修复建议 -> 起草 commit message”这条路。它不是某个单一技能能做到的，但通过脚本编排四个技能的顺序，就有点接近自动化解决一个真实问题的雏形了。我目前还在探索这一层，等跑顺了再单独写一篇分享。