企业官网建设流程全解析

如果你最近在用 Claude Code 这类 AI 编程助手，应该有过这种抓狂时刻：代码它能改，测试它能跑，但你让它"自己起个服务看看页面效果"，它却只会给你打一段文字描述，完全指望你手动操作。Superpowers 就是冲着这个痛点来的。它是一个开源技能包安装器，专门给 Claude Code、Cline 这类 AI 编码助手补上"动手能力"，把浏览器操作、本地服务管理、Git 提交整理这些能力封装成一个个 skills，一条命令就能装进开发环境。装完之后，AI 助手不再只是"能聊代码的聊天框"，而是真的具备把活干完的工具链。

写这篇东西之前，我特意在一个真实的前端项目里从零装了一整套，翻过报错，也对比过不同技能的触发方式。这篇文章会把 Superpowers 是什么、有哪些核心 skills、怎么安装，以及更关键的"怎么把这些技能真正引到日常开发流程里"讲透。如果你正在用 Claude Code、Cline 这类 AI 编码工具，又觉得它们目前还只是"高级代码补全"，那这篇应该能帮你把它们往上推一个台阶。

1. Superpowers 到底是什么，为什么值得给 AI 助手装一套

1.1 它解决的核心问题

普通 AI 编程助手和"能干活"的代码 Agent 之间，真正的差距并不在于模型参数，而是工具调用能力。模型再强，本质也只是在上下文里生成文本；让它真正操作文件、执行命令、启动服务、控制浏览器，依赖的是外部工具接口。Claude Code、Cline 这些工具之所以好用，是因为它们已经内置了文件编辑和命令执行能力。可这种内置能力相当有限——你想让 AI 自己把网页打开截个图，或者生成一条符合规范的中文提交信息，它就没有对应的工具了。

Superpowers 做的事情，是把这些高频能力抽象成技能包。所谓技能包，实际就是一个目录，里面放一份SKILL.md说明文件和若干个配套脚本。SKILL.md用 AI 能理解的格式描述技能触发条件、使用步骤和边界；配套脚本负责真正的执行。任务到来时，AI 会读取技能清单，判断当前任务和哪个技能匹配，然后按说明调用脚本。它不是在教模型变得更聪明，而是给模型配上趁手的工具，让模型知道"遇到这类活，该走这套流程"。

以前我在终端里让 AI"跑个服务看一下"，它只能回复"你可以自己运行 npm start 然后访问 http://localhost:3000"——等于啥也没干。现在同样的指令，AI 会自己找入口、装依赖、起服务，把能访问的地址交到我手上。这个差异，就是有没有工具链的区别。对于刚接触这个概念的人来说，你可以把技能理解成给 AI 配的一把把专用螺丝刀，模型是那只手，没有螺丝刀，手再灵活也拧不开螺丝。

1.2 它与普通规则文件、插件的区别

很多人第一反应是：这不就是一堆 prompt 规则吗？我自己写个 markdown 文件让 AI 读，效果不会一样吗？这个理解很常见，但不对。普通规则文件只有文本，AI 读了以后知道"应该做什么"，却没有"能用来做这件事的工具"。你想让它开浏览器，规则文件写得再详细，它也开不了，它只能建议你来开。

Superpowers 的技能包把"说明"和"可执行能力"绑在一起，这是一般提示词规则做不到的。SKILL.md说明配合对应脚本，AI 才能在对话中真正调用一个能跑的函数。而且它带有技能管理和分发机制——更新、禁用、查看清单都很直接，更像一个插件市场，而不是一份备忘录。

打个比方，普通规则文件像一本《新员工工作手册》，里面写着"遇到投诉要先安抚、要记录工单"，新员工读完知道流程方向，但手里没系统账号；Superpowers 则像是把业务系统也装好了，员工按手册点两下，工单就办完了。我自己装完之后最明显的感受是：以前让 AI 做"验收页面渲染结果"这类事，得反复给指令、贴报错；装上 browser 技能后，它自己能把页面打开截图回传，我再也不用在终端和浏览器之间来回倒腾。这种体验差异不是靠调 Prompt 能弥补的——模型推理能力再强，缺了执行通道就等于有力使不出。

2. 安装前准备：环境和版本踩坑指南

2.1 需要准备的运行环境

Superpowers 是用 Node.js 写的，所以要跑起来，环境先要满足几个条件。这是我在装完以后整理的最基础清单。

1. Node.js 版本不低于 18。它的安装和运行依赖 npx 以及较新的 fetch 能力，Node 16 以下跑到依赖解析阶段就很容易报错；
2. 一台已经装了 Claude Code 或 Cline 的设备。它的技能调度依赖 AI 助手对技能目录的识别，只装 Superpowers 不装 AI 助手是没有意义的；
3. Git。安装技能包需要拉取模板仓库，没 Git 会卡在 clone 阶段。

检查环境可以一条命令搞定，在项目终端里执行：

node -v && git --version && claude --version

如果第三行提示找不到 claude，说明 Claude Code 还没装。你可以先执行：

npm install -g @anthropic-ai/claude-code

装完再回到上一条检查命令。别小看这一步，我遇到过不少卡在"装完 Superpowers AI 不识别"的朋友，最后排查一圈，基本都是 AI 助手没提前装好。顺序搞反了，后面全得重来。如果你用的不是 Claude Code，而是 Cline 之类的工具，那就把检查命令里最后一段换成对应命令，思路是一样的。

2.2 一条命令装完：安装过程实录

环境确认没问题之后，进入项目目录，执行：

npx superpowers@latest

注意我用了@latest，这样保证拉取的是最新版本，避免本地缓存了旧包名。首次运行时会提示选择初始化选项，比如是否创建示例技能、技能目录放哪，默认值一般直接回车就行。装完后项目根目录会出现一个.superpowers目录，按skills/技能名/结构存放各个技能包。

安装期间有几个细节值得留意。如果提示command not found: npx，说明 Node 的 PATH 没配好，只能先解决 Node 环境；如果长时间卡在网络请求上，多半是拉取模板仓库的问题，检查下网络连接，不用怀疑是 Superpowers 本身坏了。整体安装过程很轻，几十秒就能跑完，不像装某个重型依赖一样让人焦虑。

装完先别急着开始干活，做一次自检：

ls .superpowers/skills

正常情况下你能看到browser、server这些文件夹。看到这些，安装才算是真正完成了。我第一次装完的时候想当然地以为要在全局目录装，结果项目里一直识别不到，后来才发现这东西要装在项目根目录下才能被 AI 助手发现，这个坑后面专开一节讲。

2.3 安装后的目录结构说明

看一眼实际安装后的目录，你就能对它是怎么工作的有个直观印象。我把一个真实项目的简化结构贴出来：

.superpowers/ ├── skills/ │ ├── browser/ │ │ ├── SKILL.md │ │ └── browser.js │ ├── server/ │ │ ├── SKILL.md │ │ └── server.js │ ├── sudo/ │ ├── modular-commit/ │ ├── chrome-debugging/ │ └── codespaces/ └── superpowers.json

每个技能目录里，SKILL.md是灵魂。它以一种 AI 能解析的格式记录触发条件、使用步骤和注意事项；配套脚本则提供真正可以执行的能力。superpowers.json是技能清单，AI 助手启动时读取它，决定当前环境可用哪些技能。举个例子，如果 AI 接到的任务是"打开页面截图"，它读superpowers.json发现有 browser 技能，再读browser/SKILL.md知道该用什么命令，最后调用browser.js真正完成操作。搞懂这个结构之后，你再排查"AI 为什么没调用某个技能"就会快很多——先看清单里有没有，再看 SKILL.md 触发条件对不对，最后看脚本执行是否报错，三步走完基本定位。

3. 核心技能清单：哪些 skills 值得优先用起来

3.1 server 技能：让 AI 自己把服务跑起来

server 技能是我最常用、也是收益最大的一个。它能帮 AI 在项目里启动本地 HTTP 服务，并把访问地址交给你。典型场景是这样：代码改完了，想验证效果，以前你得手动npm run dev，然后把 localhost 地址发给 AI，让 AI 基于地址继续干活；现在你只需要说"用 server 技能把项目跑起来，把预览地址给我"，AI 就会自己分析 package.json 里的 scripts，找到启动入口，起服务，监听一个不冲突的端口，最后返回类似http://localhost:5173的地址。

这里有一个隐性能力值得展开：AI 是真的会读配置文件。比如一个 Vite 项目，它会识别dev脚本并执行；如果是一个 Python FastAPI 项目，它会改用 uvicorn 来启动。它甚至会在端口被占用时自动换一个，整个过程你基本不用管。有人会觉得"这不就是把 npm run dev 换个说法吗"，但实际上区别很大，因为它是整个自动验证链路的第一环。服务起不来，后面的 browser 技能就没法干活，所以这个技能的作用非常基础却极其关键。

3.2 browser 技能：让 AI 自己去看页面

browser 技能是把无头浏览器能力打包给 AI 使用的关键。它有三大常见用途：打开指定 URL 截图回传、读取 DOM 验证元素是否渲染、在页面里执行 JavaScript 测试交互。因为是用无头浏览器在后台运行，它不会打扰你正在用的日常浏览器窗口。

我个人觉得这个技能最大价值在于"把验收环节还给代码 Agent"。以前改完页面要自己开浏览器看效果，现在 AI 可以自己打开、截图、检查样式，甚至连按钮文字有没有错位都能发现。它解决了很多人不敢让 AI 改前端的问题——不是怕 AI 改错，是怕改完不知道变什么样。有 browser 技能兜底，AI 改完可以自己验一圈，再把结果拿给你看，信任感会明显不一样。比如我之前让 AI 调一个响应式布局，它改完样式后自己开了个 375px 宽度的窗口截图，发现导航栏折叠有问题，又回头改了第二版。整个过程我只是在最后看了一眼最终截图，省了不少事。

3.3 modular-commit 与 sudo 技能

modular-commit 解决的是提交信息混乱。以前 AI 生成的 commit message 经常是一句话"update files"，放进历史记录里根本没法看。这个技能会把提交信息整理成符合约定式提交规范的结构，比如feat: add user profile page，或者fix: resolve null pointer in cache。装上以后，你可以让 AI 在每次修改完代码自动生成提交信息，连带自动提交，历史记录质量会一下子上来。对写周报或者回看排期的人来说，这种信息结构能帮你少做很多考古工作。

sudo 技能则是处理权限问题的。它允许 AI 在限定的授权范围内执行管理系统级命令，而不是把所有管理员权限一股脑交给它。对本地开发来说，这一点让人安心很多——毕竟凌晨三点你不会想去检查 AI 有没有动系统全局配置。它本质上是一个权限收口工具，让 AI 能做的事情变多，但步子被限制在一个可控范围内。此外还有 chrome-debugging（连接现有 Chrome 实例做调试）、codespaces（配合云端开发环境）这类按需启用的技能，名气不如前几个，但碰到对应场景时都非常顺手。

3.4 技能的工作方式

好多人搞不明白的一个点是：技能到底是怎么被唤起？官方文档写得很克制，我的理解是这样：AI 助手启动后会读取superpowers.json和各个SKILL.md，把技能说明作为上下文的一部分。当任务目标符合某个技能的触发条件时，模型就会按 SKILL.md 里的指引来执行。它并不是一个手动点拨的按钮，而是一个自动匹配的能力包。

所以，正确用法不是对话里喊"请使用 X 技能"，而是清楚描述任务目标。你把目标说得越接近技能的预设场景，AI 就越容易选对技能。比如"帮我起个服务，然后打开浏览器验证登录页"这句，就会同时触发 server 和 browser 两个技能。它是隐式调度，不是显式命令，这一点我用了好一阵子才真正想明白。如果你带着"我要看技能列表才能用技能"的思路去操作，很容易觉得这工具不通透，其实是理解方向搞反了。

4. 怎么把技能引入到日常开发流里

4.1 给 AI 下指令的正确姿势

很多人的误区是问"你能用 Superpowers 吗"，AI 回一句"可以"，然后就没了。其实那只是模型理解到你在问能力，并不会真正去调技能。正确姿势是把任务目标拆细，给 AI 明确上下文，让它自己判断该用哪个技能。我贴一个我自己常用的指令模板：

请对这个 React 项目做一次前端验收： 1. 先用 server 技能把项目跑起来； 2. 用 browser 技能打开首页并截图确认； 3. 检查顶部导航和设计稿是否对得上； 4. 发现问题就直接改，改完重新截图。

这种指令的效果比"帮我看看这个项目怎么样"好得多。因为它把"验收"这个大目标拆成了小步骤，每个步骤都有明确可调用的技能。反过来说，指令太泛，AI 既不知道要起服务，也不知道要截图，最后只会给你一段泛泛的建议，技能完全没被触发。经过一段时间的训练，模型其实也会慢慢习惯你这种"目标+步骤"的表达方式，后续响应速度和质量都会更好。

4.2 技能组合使用的典型工作流

我最常用的一套流程是这样的：先 server 起服务，再 browser 打开页面做验证，接着让 AI 根据页面反馈改代码，然后用 modular-commit 生成规范的提交信息，最后再跑一轮验证确认没问题。这个闭环走下来，一个"改代码—验效果—提交"的完整链路就通了。

对个人开发者来说，这套流程最大的意义是省时间。你不再需要在终端、编辑器、浏览器三个窗口之间来回切，AI 自己就把完整流程跑完，你只负责验收结果。对团队来说，这就相当于给代码 Agent 装了半套前后端验收能力，人肉重复验收的活会少很多。我甚至习惯在午餐前把一个任务丢给它，让它自己折腾，回来直接看结论。当然，第一轮我一般还是会在旁边盯着点，确认它没有朝着奇怪的方向狂奔，毕竟 AI 再强，任务拆解和最终拍板还是自己的活。

4.3 团队协作中的引入方式

如果要在团队里推广，我建议先一个人试点，跑通后再逐步铺开。原因很简单：技能会改变 AI 助手的行为习惯。比如装了 modular-commit 之后，所有经由 AI 生成的提交信息都会变成约定式提交风格，这需要团队先认可这套规范，不然反而会被当成噪音。

还有一点值得注意：.superpowers目录要不要提交到 Git 仓库。我个人的建议是个人项目无所谓，团队项目建议加入.gitignore，因为不同人的技能版本可能不一致。如果你确实想让团队统一使用一套技能，可以锁版本，或者约定从同一个发布版本安装。让团队在可控预期里享受工具红利，比一键全员安装稳得多。这套思路放在任何工具引入里都适用，先改变自己的习惯，再去改变团队的习惯，节奏对了才不容易反弹。

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

5.1 装完没效果：技能没有被识别

这是排在第一的高频问题。装完以后你问 AI"现在有哪些技能"，它还是只能说"我可以用工具帮忙"，再问细一点就卡壳。99% 的情况是项目目录不对。Superpowers 要在 AI 助手实际工作的那个项目根目录里安装，如果 AI 的工作目录和安装目录不在一起，它读不到.superpowers，自然就什么技能都没有。解决办法很直接：回到安装目录，重启 AI 助手，确认工作路径里直接包含.superpowers。

还有一个比较隐蔽的情况：有些终端工具打开时会自动切换到其他目录，比如 home 目录，导致 AI 根本不在项目里跑。这种问题不看日志根本发现不了，排查时留意一下当前工作目录就行。我自己的习惯是装完后先故意问一句"你当前的工作目录是哪里"，确认路径对了再继续，这个习惯帮我避免了好几次白忙活。

5.2 技能脚本执行报错：环境依赖不完整

browser 技能会报"找不到浏览器"，server 技能会报端口占用，这些都很常见。先说 browser，它依赖本机的无头浏览器运行库，如果你用的设备从来没装过相关依赖，首次运行大概率会报错，装一下基础运行库就好。server 技能报EADDRINUSE，几乎都是端口被占用，可以让 AI 换个端口，或者手动排查占用进程。

这种问题其实不是 Superpowers 本身的问题，是技能在执行时依赖了外部环境，而外部环境没就绪。遇到问题先看脚本抛出的错误信息，再顺藤摸瓜，别一上来就把技能配置删了重装。我见过有人因为一个小报错把整个目录删掉重来，最后折腾一小时发现只是缺了个 Chromium 依赖，挺亏的。

5.3 问题速查表

我整理了一张速查表，方便你遇到问题时直接对照：

实际用下来，你会发现绝大多数问题都能在上表里找到影子，剩下少部分偏门的场景，去技能目录里看日志基本就能定位，没必要硬啃文档。

5.4 几个值得记住的实用技巧

最后分享三条我个人的经验。第一，先把 server 和 browser 练熟，再研究其他技能。这两个是使用频次最高、收益最大的起点，打通它们，你对整套机制的理解会快很多。第二，多去.superpowers/skills目录里读 SKILL.md，比看宣传文章有用得多。你能从中看到技能的触发规则，理解了就能自己照着写一个私有技能。第三，不要完全依赖 AI 自动选技能。在复杂任务里，你可以像我前面示例那样，在指令里明确写出技能名，这是最稳的用法，重复几次之后模型也会更自然地按你习惯的路线走。

我在实际使用中发现，Superpowers 真正让我停不下来的，不是某一个技能本身，而是那种"把活交给 AI，它在后台自己折腾，我只需要验收结果"的松弛感。装好的第一周，我还会时不时打开它的日志，怕它乱动东西；用久了你会发现，它的出错模式相当稳定，几乎所有问题都能从脚本日志里找到线索。如果你也在用 Claude Code 这类工具，建议别只停留在让它改代码这一层，按这篇文章的步骤先把 server、browser 两个技能跑通，再试着把一串任务连起来让它独立跑一趟。等你在终端里看到 AI 自己起了服务、自己开了浏览器、把 commit 信息也写得整整齐齐，那种"拿到超级力量"的感觉还是很真实的。