企业官网建设流程全解析

1. “superpowers”到底是什么：先把它当成AI的外挂技能包

1.1 给AI装“技能包”，而不是给AI写“提示词”

前阵子我换了一台工作机，折腾环境的时候顺手把这个叫 superpowers 的AI技能框架装上了。当时只是图新鲜，结果两周下来，它成了我日常用得最频繁的一个工具。今天这篇就聊聊它到底是什么、怎么装、里面有哪些 skills、以及怎么把它真正用起来——网上关于它的零碎教程不少，但把安装、技能清单、调用方式和踩坑串成一条完整线的，确实不多。

先说我自己的理解。superpowers 解决的痛点很直接：模型本身很强，但默认状态下是“通用智力”，不会自动带着某一套领域完整的工作方法去干活。你让AI帮你写市场分析，它写得出来，但如果你不告诉它“访谈对象是谁、数据口径怎么对齐、报告结构按什么标准来”，它产出的东西大概率是四平八稳、没法直接交差的模板文。superpowers 做的就是这件事——把一套套“领域工作方法”提前封装成一个个技能（skills）。

所以你可以把 superpowers 理解成一个“外挂技能包管理器”。它的基本单位不是插件，也不是工作流，而是一个个名为SKILL.md的结构化文档。每个文档对应一个技能目录，里面写了这个技能的适用场景、执行步骤、输出格式、必须避开的坑。模型在对话中读到这些内容，就像短时间内被“附体”一样，按照既定方法去执行任务。

1.2 它和普通插件的本质区别在哪

我见过不少人一上来就问“superpowers 跟某某插件有什么区别”，其实差别还挺大的。

传统插件通常绑定特定平台或IDE，比如编辑器插件、浏览器扩展，它们靠代码去接管软件行为。superpowers 走的是另一条路：核心只是一批有目录结构的 Markdown 文件。因为它是纯文本加文件夹，所以天然跨平台——命令行能用、网页版能用、自己二次开发的客户端也能用。你甚至可以把整个技能库放进 Git 仓库里做版本管理，跟同事协作时直接把技能目录推过去就行，不需要对方装同样的IDE插件。

还有一个容易被忽略的点：插件的能力边界由开发者写好，用户只能“用”，很难“改”。superpowers 的技能则完全向你开放，英语好的可以直接用现成的，想改逻辑就打开SKILL.md改几行描述，想加新技能就新建一个目录。它的核心假设是“方法本身可以被描述”，而描述的方法论，写起来比写代码门槛低得多。我做第一次实操时就被这个思路吸引了：这不只是工具，它是在给AI定义“出厂设置”。

2. 安装流程复盘：从clone到第一次run的完整记录

2.1 用三条命令把仓库拉下来

我是在 macOS 环境装的，整个安装过程比想象中简单，但前置依赖得先确认好。superpowers 本体是个脚手架，它需要你的机器上已经有 Node.js 环境（版本建议 18 以上）和 Git，这个检查建议放在第一步做：

node -v git --version

看到版本号正常输出后，直接找个工作目录把仓库拉下来：

git clone https://github.com/your-superpowers/superpowers.git cd superpowers npm install

注意npm install这一步，网络波动会导致部分依赖安装失败，我后面会专门展开讲。装完依赖后，官方推荐的做法是先把项目启动起来看一眼默认状态：

npm run setup

这个命令会做三件事：检查本地环境、生成一份默认配置文件、把技能库目录初始化出来。一切正常的话，终端里会显示类似superpowers is ready的提示。

2.2 第一次初始化：目录结构、配置文件、依赖检查

跑完setup后，你会看到项目根目录下多出来几个关键目录和文件。这里我不太建议直接跳过不看，因为后面排查问题全靠对这套结构的熟悉程度：skills/是所有技能的存放目录，每个子目录是一个独立技能，里面至少要有一个SKILL.md文件；config.json是主配置文件，控制哪些技能默认启用、哪些不启用；logs/是运行日志目录，刚开始可能为空，但踩坑时它就是救命稻草。

我第一次跑完 setup 后先做了一件事：直接打开默认的config.json看了一眼。里面最核心的字段是enabled_skills，它是一个数组，列出了当前会话中“默认加载”的技能清单。注意，这里有个设计上的关键点——不等于你装了多少技能就会全部加载，默认只加载你启用的部分，这是为了控制上下文长度。

依赖检查方面，setup 脚本会自动检测几个常见工具：git、node、npm，如果有缺失会在终端标红提示。我自己遇到过的问题是系统里同时装了多个 Node 版本，导致node命令能用但npm找不到，当时用nvm use 18切了一下就正常了。如果你用的是 Windows，建议在 PowerShell 里以管理员身份运行，避免后续技能目录创建时遇到权限问题。

2.3 安装过程中最常见的三个报错

第一个坑是npm install时卡住不动。多半是网络原因，我当时的处理方法是切换到国内镜像源再装，命令是npm config set registry https://registry.npmmirror.com，装完再切回来即可。这个问题很典型，容易让新手误以为项目本身有问题。

第二个坑是git clone下来的仓库缺少技能子模块。因为技能库往往是以 submodule 方式引用的，直接 clone 主仓库只能看到空目录。解决方法是补一条命令git submodule update --init --recursive，执行完成后skills/目录里才会真正出现技能内容。我最初没做这步，傻傻地盯着空目录看了半天。

第三个坑是权限问题。运行setup时它要写~/.superpowers/这个目录，如果系统装了严格的安全策略，会弹权限提醒。处理方式很简单：手动创建目录并授权chmod -R 755 ~/.superpowers。这几个坑都算“一次性问题”，解决过后基本不会再遇到，但第一次遇到时确实很劝退。

3. 内置技能库盘点：我拿到的这批skills，哪些真的值得用

3.1 内容创作类技能：写东西不再是“从零憋字”

我这套环境自带的技能库里，内容创作类占了大头。最常用的是blog-post，它相当于一个“长文写作流程包”：拿到题目后会先让我明确读者画像、核心论点、证据链，然后才铺开写正文，最后还要过一遍“信息密度检查”。跟 AI 直接写几千字的感觉完全不同——它多了一层层前置约束，但产出的文章结构扎实很多。

newsletter适合做邮件通讯稿，它会强制你先提供 3 个本期重点，然后按“重点-展开-行动引导”的结构生成。seo-keyword则是做选题和标题用的，它的逻辑不是让你堆关键词，而是先拆搜索意图，再判断题目的竞争度，最后给 3 个不同风格的标题方案。这套组合下来，我日常的内容工作流基本都挂在 superpowers 上。

3.2 代码与工程类技能：能落地，但不建议无脑用

代码类技能里，code-review我使用频率最高。它要求你把代码片段和对应的上下文背景贴给它，然后按“正确性-性能-可维护性-潜在风险”四个维度输出评审意见。它跟直接让 AI“帮我看看代码”最大的区别是：不会只夸“代码写得不错”，而是会主动指出边界条件漏判和异常处理缺失。

git-commit-msg是个实用小技能——你只需要把git diff的结果贴进去，它就能产出一条符合 Conventional Commits 规范的提交信息。还有个unit-test-generator，能根据函数代码生成测试用例骨架，但我的经验是复杂业务代码生成的测试意义不大，反而简单工具函数特别好用。这个取舍值得注意：技能不是越用越全就好，得学会判断什么场景值得用。

3.3 数据分析和信息处理类技能：适合把脏活累活外包

这类是我实际工作中最省心的。csv-analyzer会引导你先把数据字段说明贴上去，然后自动做数据概况分析、异常值检测、基础统计汇总，比自己写 Python 脚本快得多。sql-optimizer则是经典场景——你把慢查询语句贴过去，它会从执行计划的角度反推索引设计问题。

这里我想特别说一句：信息处理类技能的价值不在于“多聪明”，而在于“流程标准化”。手动分析时每个人的思路千差万别，但技能库里这些流程被固化下来了，输出格式一致，结果可比性很高。如果你经常要做月度数据汇报，这个特性非常友好。

3.4 生活效率类技能：被低估的一组

可能因为名字太朴素，这一类经常被忽略。我用得比较好的是meeting-notes——把会议录音转写文字贴进去，它会自动分主题、提炼结论、拆解待办事项，并且给每条待办标注负责人假设。trip-planner则会在出行前要你先给出行程偏好、预算和节奏感，然后给出一份“时间-地点-交通-备注”四段式行程表。

说实话，生活类技能的精度不如专业类高，但它们的价值在于把AI的“通用能力”框定成可复用的固定格式。一旦你决定以后都用这套模板整理会议纪要，输出的所有文档风格都会统一，检索起来非常方便。

4. 技能引入的几种正确姿势：别只会对着AI喊“使用XX技能”

4.1 自动发现模式：让系统按任务自己匹配

superpowers 最理想的用法是“你不必记得每个技能的名字”。它有一个自动发现机制：当对话中出现某个技能适用场景的关键词时，系统会主动把对应SKILL.md拉入上下文，自动应用该技能的工作方法。

我实测下来，自动发现的准确率取决于你在SKILL.md的“适用场景”里写了什么。写得太宽泛容易误触发，写得太具体又经常触发不了。一个技巧是：把触发场景描述成“用户输入里出现的具体动作”，比如对blog-post不要写“写文章的时候”，而是写“用户要求撰写长文、文章、博客内容时”。这样自动匹配的准确率会高很多。

4.2 显式引用：场景固定时的暴力解法

自动发现固然方便，但有时候你明确知道该用哪个技能，与其等系统猜，不如直接点名。superpowers 支持两种显式引用方式：一种是在输入里带@技能名，比如@blog-post 帮我写一篇关于智能家居的博文；另一种是斜杠命令，类似/code-review，后面跟上代码。

我的使用习惯是：日常新任务靠自动发现，重要且有明确产出的任务靠显式引用。原因很实际——显式引用能保证这次对话必定执行对应流程，不会因为描述的某个词没命中关键词而走回普通聊天模式。尤其是code-review这种事，走普通模式和质量差很多，我必须确保它触发。

4.3 会话内动态加载：什么时候加载最合适

superpowers 的加载机制很灵活。默认情况下，技能在会话开始时按config.json里的启用列表一次性加载；但实际上可以做到会话中动态加载——当你在聊天中突然提到一个未启用技能的名字时，它会临时拉取该技能描述并应用到后续对话。

动态加载的好处是给上下文瘦身。假设你同时启用了 20 个技能，总描述字数可能超过 1 万字，这会让模型注意力分散。我的建议是：常用技能保持启用，偶尔用一次的大块头技能保持关闭，需要时靠@技能名临时拉起来。这样既不损失能力，又能控制上下文长度。

4.4 多技能叠加与优先级：多个技能同时命中时处理顺序

典型场景是：你发了一段项目周报文本，既符合meeting-notes的“会议纪要整理”场景，又符合blog-post的“内容重组”场景。两个技能同时加载时怎么决定最终输出逻辑？我观察到的规则是：SKILL.md文件头部的元信息中如果写了priority: high，那么它会优先覆盖低优先级技能的步骤。

这个设计其实很值得玩味——它说明技能之间不是简单的并列关系，而是存在“方法竞争”。我在自己的技能里会刻意给“数据类”技能高优先级，因为如果一份周报里既有数据又有文字，数据准确性优先级理应高于文风润色。这条经验你直接用就成，不必踩一遍才知道。

5. 实测中的坑与解法：两周用下来的排错笔记

5.1 技能目录加载失败：根因竟是一个隐藏文件

有个周一，我打开项目发现blog-post技能突然不生效了。表现是：我用@blog-post显式引用，系统提示“技能不存在或已禁用”。第一反应是配置文件出问题了，翻看config.json，enabled_skills里明明还有它，加载列表也正常。

排查了两轮无果，最后去看日志才发现是技能目录读取失败。进skills/blog-post一看，目录里躺着一个.DS_Store（macOS 自动生成的隐藏文件），而SKILL.md依然完好。抱着试试的心态，我删掉.DS_Store，刷新配置，技能立刻恢复正常。

定位到最后，我很确定这是技能目录遍历逻辑的 Bug——它扫描到隐藏文件后中断了后续解析。这个坑也提醒我一件事：技能目录里别乱放非必要文件，保持目录干净，尤其别放带特殊符号的文件名。

5.2 上下文爆炸：技能描述太长，回答质量反而急剧下降

superpowers 给了我一种以前没有过的“奢侈烦恼”：技能太好用了，于是我把十几个技能全设成默认启用，结果对话质量肉眼可见地变差。表现是回答变得拖沓、抓不住重点，偶尔还会把不同技能的模板混在一起输出。

这其实是上下文被撑爆的表现。每个技能描述几百字到上千字，十几个技能叠加后，模型处理后续对话时注意力被分散。我最后的处理方案是分级启用的“三档策略”：工作流中的核心技能设为启用，经常手动调用的技能设为“按需加载”，不常用的技能彻底禁用。调整完之后，同样的任务回答质量立刻回升。

所以我的建议很直接：别贪多。技能库里值钱的不是“装了哪几个”，而是“当前上下文里到底装了几个”。

5.3 同名技能冲突：两个技能都叫report，听谁的

这个问题我是真踩过。我从两个渠道分别装了两套技能库，一套侧重数据分析，一套侧重内容运营，结果里面都有一个report技能。加载时系统没有报错，但从某次对话开始，输出的报告格式完全变了——四不像，既不像数据报告，也不像内容总结。

查看技能扫描日志后发现，同名的后者覆盖了前者，生效的只有其中一份SKILL.md。解决方法是给本地技能重命名，或者删除冗余的一套，只保留符合自己工作流的技能。如果你的技能来源比较多，建议定期用superpowers list命令把所有已加载技能列出来，对下名字和用途，减少这种无感知的覆盖。

5.4 “技能失效”的错觉：不是框架坏了，是没刷缓存

使用过程中还有一类迷惑行为：明明刚改完SKILL.md的内容，但对话里执行的还是旧逻辑。第一次遇到时我以为没保存成功，反复改了好几遍都没效果，后来才发现是有缓存。

superpowers 默认会缓存技能描述的解析结果，以加速会话启动。修改文件后需要执行刷新命令清缓存，不同发行版命令略有差异，我这边是npm run cache:clear。现在我的习惯是：每次改完技能内容，先清缓存再开新会话验证。这条经验值回票价。

好多次所谓的“技能 Bug”，最后定位都是缓存问题。诊断时先看缓存再看配置，能省下大量排查时间。

6. 从会用到用得好：把superpowers的玩法沉淀成自己的方法论

6.1 先主攻一套能力，不要全部技能一起上

如果你刚装完 superpowers，我的建议只有一个：先把一套你最高频的工作流用熟。比如你是写代码为主，就只启用code-review和git-commit-msg；你是做内容为主，就只启用blog-post和seo-keyword。

原因我在前面讲上下文爆炸时已经提到了，技能加载是有成本损耗的，十项技能只精通一样，比十样都会一点体验好得多。技能这个东西，很少是“多多益善”，更多是“合适的正好”。

6.2 手写一份自己的SKILL.md：给AI定“出厂配置”

用熟之后，你大概率会想自己定义技能。这一步不难，核心就是遵循标准模板，你完全可以拿现成技能复制一份再改。我常用的模板结构是这样的：

# Skill: 技能名称 ## 适用场景 这个技能在什么情况下被激活，描述越具体，自动匹配越准。 ## 执行步骤 1. 第一步：先做信息收集，明确目标 2. 第二步：分析约束条件，列出可选方案 3. 第三步：执行方案，输出中间结果 4. 第四步：自检，把结果与目标比对 ## 输出格式 必须包含什么字段，按什么顺序输出。 ## 注意事项 哪些情况绝对不能做，哪些边界条件需要人工确认。

自己写技能有个额外好处：你会强迫自己把“怎么做这件事”的隐性经验显性化。比如我给自己写了一个weekly-report技能，就逼着我思考每个周五做周报时真正会看什么数字、警惕什么异常。写技能的过程本身，就是一次业务方法论梳理。

6.3 一条完整的个人工作流示例：用一周的实操串联所有环节

最后给一个完整的串联示例，也是我最近一直在跑的一条工作流。新周一开始，我先新建一个会话，初始化时加载meeting-notes技能，把所有周会录音转写贴过去，产出一份结构化会议纪要。然后我会把纪要里的待办事项复制到下一步会话，用blog-post技能把其中关键项目写成一份简短周报初稿。

等周报收到反馈后，我把具体修改意见和原始稿子一起丢到code-review技能（虽然是文字不是代码，但它的审校逻辑对文本同样适用），检查逻辑漏洞和表达偏差。整套流程走完后，我再把最终稿归档。你看，一条周报从原始会议到可发布版本，中间用到了三个技能、两个会话，全是被动加载，几乎没有额外配置成本。

技能列表在网上不难找到，但怎么把技能组合成自己的工作流，才是 superpowers 真正值钱的地方。我的体会是：它让你不再“临时教AI怎么干活”，而是把一个熟练工的工作方式整个复制给AI。这套东西刚开始用会觉得是玩具，但连续用下去，你会发现它悄悄把一个人的效率底线抬高了一大截。