企业官网建设流程全解析

superpowers这个词在AI编程工具圈子里最近确实很火。我第一次看到这个项目的时候，第一反应是“这不就是个技能包合集吗”，但实际用了两个星期之后，我得承认它改变了我和AI协作的方式。简单说，superpowers是一套可以安装到AI助手（比如Claude Code这类工具）里的skills集合，每一个skill都是一份结构化的指令文件，告诉AI在特定场景下该按什么流程干活。它的价值在于：把“AI很有潜力但常常不会干活”这个问题，变成了“让AI按照你的套路来干活”。

这篇内容我打算从零开始讲清楚三件事：superpowers到底解决什么问题、有哪些核心skills、以及怎么在你的环境里安装和真正用它干成事。无论你是刚接触AI辅助开发的新手，还是已经在深度使用AI编程工具的老手，这套东西都值得你花半小时试一试。

1. 先搞清楚superpowers到底是什么

1.1 它解决的是“AI有潜力但不会干活”的尴尬

用过AI编程助手的人应该都有过这种体会：刚装好的时候觉得它神了，能写代码、能解释报错、能帮你重构。但用着用着就会发现，它在处理小任务时很聪明，一遇到稍微复杂一点的需求就开始“自由发挥”——写出来的代码能用，但不是你想要的风格；改动了一个文件，却忘了关联的测试；让你审查代码，它泛泛而谈说“代码质量不错”，一句有用的都没有。

问题出在哪？出在AI缺少“工作方法”。它知道的东西很多，但它不知道你的团队约定、不知道你想要的输出格式、不知道一个完整的代码审查该分几步走。你每次都要在对话里重复交代这些背景，一旦漏了，它就给你一个“正确但没用”的答案。

superpowers的思路是：把这些工作方法沉淀成一个个“技能卡”。每张卡里写清楚这个技能适用的场景、执行步骤、输入输出要求、以及常见坑。AI在执行任务前先读取对应的技能卡，然后按卡上的流程来干活。你不需要每次重新教它，技能卡就是它的“操作手册”。

1.2 核心设计：skills就是最小可用的“技能卡片”

这个项目的核心概念就是skills。一个skill本质上是一个目录，里面至少包含一个SKILL.md文件。这个文件采用Markdown格式，用结构化的方式描述技能的名称、描述、使用场景、步骤、示例和注意事项。

举个例子，一个名为code-review的技能卡，它的SKILL.md里面会写：这个技能用于AI辅助代码审查；触发条件是用户要求审查代码变更；执行步骤是先读取diff、再检查逻辑正确性、然后检查边界条件、最后输出带有严重级别标记的审查意见清单；输出格式是列表，每条意见包含问题描述、所在文件、风险等级、修改建议。

你可能会说，这不就是提示词吗？对，本质上就是比普通提示词更规范、更模块化、更可复用的提示词。但关键区别在于：superpowers不是让你把一大堆提示词堆在系统提示里，而是让AI按需加载。用哪个技能就调用哪个技能，不用的不占上下文空间。这一点在实际使用中非常重要——上下文窗口是有限的，一次性塞入所有提示词只会浪费token，还会导致AI抓不住重点。

2. 怎么安装superpowers，以及两种引入方式

2.1 安装前先确认你的运行环境

在动手之前，先确认你用的AI编程工具支持自定义skills。目前主流的Claude Code、Cursor这类工具基本都支持通过目录结构加载自定义技能。如果你用的是其他工具，建议先查一下文档里有没有类似“skills directory”或“commands”的配置项。

另外要注意，superpowers本身是社区驱动的开源项目，安装方式一直在迭代。我用的版本是基于Git仓库直接克隆的，整个安装过程不需要编译，也不需要装额外的运行时依赖，只要你的机器上有Git和基本的命令行环境就行。

我个人建议在安装之前先创建一个干净的测试目录，比如~/superpowers-test，在里面做实验。这样做的好处是：万一装坏了或者不满意，直接删掉这个目录就恢复原状，不会污染你平时的工作项目。

2.2 方案A：用安装器一键装

这个项目提供了一个安装脚本，适合大多数使用者。打开终端，执行以下命令：

git clone https://github.com/example/superpowers.git cd superpowers ./install.sh

安装脚本会做三件事：第一，把skills目录拷贝到你当前用户目录下的AI工具配置目录（比如~/.claude/skills）；第二，创建一个环境变量文件，记录skills的根路径；第三，在终端里输出一行提示，告诉你安装完成。

装完之后可以验证一下：

ls ~/.claude/skills

正常情况下，你会看到一堆以技能名命名的目录，比如brainstorming、code-review、git-workflow这些。看到这些目录，就说明安装成功了。

注意：如果你之前已经在~/.claude/skills里放了自己的技能，不要直接跑./install.sh，它可能会覆盖同名目录。先备份，再安装。

2.3 方案B：手动克隆并软链（适合定制）

一键安装省事，但如果你像我一样有定制需求，我推荐手动方式。手动方式就是把skills目录软链到你的项目里，这样你可以随时改技能内容，而且改动对所有项目生效。

步骤很简单：

# 1. 克隆仓库到你喜欢的位置 git clone https://github.com/example/superpowers.git ~/superpowers # 2. 在你的项目里建立软链 ln -s ~/superpowers/skills ~/my-project/.claude/skills

这种方式的优势是“所见即所得”。你想修改某个技能，直接打开~/superpowers/skills/code-review/SKILL.md编辑即可，下次AI加载的就是新版本。而且不同项目可以链接到同一份技能目录，维护起来很省心。

2.4 环境变量与配置项

不管用哪种方式安装，都要确认AI工具能读到技能目录。以Claude Code为例，它会在启动时扫描当前工作目录下的.claude/skills，以及用户目录下的~/.claude/skills。两边都会加载，但优先级不同：项目目录下的技能会覆盖用户目录下的同名技能。

如果你想自定义技能的扫描路径，可以设置环境变量：

export SUPERPOWERS_SKILLS_DIR="$HOME/superpowers/skills"

设置了之后，确保AI工具的配置里包含了这个路径。具体怎么加，看工具文档，一般是写进配置文件里。

3. 有哪些实用的skills，以及各自的使用场景

3.1 技能清单概览

superpowers里到底有多少个skills？我数了一下我本地这个版本，大概是二十多个。数量不算多，但每个技能的定位都很明确。下面我把最常用的几个列成一个表，方便你对照查看：

每个技能都不是孤立的。实际使用的时候，它们经常组合出现。比如接到一个新需求，你可能先用brainstorming梳理方案，再用writing-plans生成执行计划，然后用executing-plans逐步落地，最后用code-review检查成果。整套流程走下来，就像带了一个很懂规矩的实习生。

3.2 重点skills的实操演示：以code-review为例

光看清单还是不够直观，我拆一个大家最有感知的code-review技能，看看它的SKILL.md是怎么组织内容的。

--- name: code-review description: 对代码变更进行结构化审查，输出严重级别标记的审查意见 --- # Code Review ## 触发条件 - 用户要求审查代码、检查PR、review diff - 用户提供了一段待审查的代码或指出了变更范围 ## 执行步骤 1. 获取要审查的代码diff或文件列表 2. 逐文件阅读，重点检查逻辑正确性、边界条件、安全风险 3. 对照项目的编码规范检查风格问题 4. 汇总问题清单 ## 输出格式 - 输出为Markdown列表 - 每条意见格式：`[级别] 文件:行号 - 问题描述` - 级别分为：Critical（必须修复）、Warning（建议修复）、Nit（可选优化） ## 注意事项 - 不要只做语法检查，要关注逻辑层面 - 不要输出“代码整体不错”这类空洞结论 - 如果问题数量超过15条，按严重级别排序后只输出前15条

这个技能卡的精髓在于最后那两条注意事项。没有这一条，AI往往会输出一堆正确的废话。有了这一条，AI才会真正去抠逻辑漏洞，并且控制输出量，不会让你陷入信息过载。

实际用的时候，我会在对话里告诉AI：“请用code-review技能审查一下src/utils.ts的改动”。AI就会按照技能卡的流程去执行，最终给出的意见是分级的、带文件位置的、可操作的。那种“这里可能有问题，但我不确定”的模糊话术明显变少了。

3.3 自己写一个skills要遵循的要点

用了一段时间之后，你大概率会想写自己的技能。我建议先模仿现有技能的结构，不需要从零发明。记住几个要点：

第一，技能描述要写清楚触发条件。AI判断该用哪个技能，主要靠的就是description字段里的关键词。描述越具体，召唤的成功率越高。比如“用于审查代码变更”就比“代码审查”好用，因为后者太宽泛，AI无法判断什么时候该触发。

第二，步骤要写“可执行的动词”，不要写“思考性的形容词”。与其写“仔细分析问题”，不如写“列出输入的所有边界值”。AI对具体指令的遵循程度远远高于抽象指令。

第三，一定要写“不要做什么”。这个技巧很反直觉，但效果出奇地好。因为AI模型本身倾向于讨好用户、说好话，如果你不明确禁止，它很容易输出“代码质量较高，但有一些地方可以优化”这种彬彬有礼的废话。在技能卡里明确写入“不要输出空洞结论”之后，输出质量会立刻上一个台阶。

4. 真正上手：我用superpowers完成一个实际任务的完整过程

4.1 任务定义

说了一堆概念，我们来走一个真实场景。假设我手上有一个Python脚本data_cleaner.py，负责清洗CSV数据。这个脚本有一个bug：当输入文件包含空行时，会导致索引错位，最终输出结果不对。我决定用superpowers帮我修掉这个bug，并且顺便补上测试用例。

这个任务正好可以用到两个技能：debugging用于定位根因，test-driven-development用于补测试。

4.2 运行过程记录

我先在AI工具里发起请求：“请用debugging技能帮我排查data_cleaner.py中的空行处理问题”。

AI读取了debugging技能卡，然后按步骤执行。第一步是复现问题：AI先阅读了脚本，找到了读取CSV的部分，接着自己生成了一个带空行的CSV测试文件并运行脚本，成功复现了索引错位。第二步是定位根因：AI发现脚本在处理每一行数据时，直接用row[0]取值，但如果这一行是空行，row就是一个空列表，索引访问就会跳过这一行但索引计数却仍然增加，导致后面的数据全部对不上。第三步是修复：AI把原先“逐行索引取值”的逻辑改成先用列表推导式过滤空行，再统一处理。修复之后重新跑测试，数据输出正常了。

这个过程中最有价值的部分是：AI没有上来就改代码，而是先复现、再定位、最后才动手。这就是技能卡里“执行步骤”的约束力。

接下来我要求“用test-driven-development技能为修复后的脚本补充测试用例”。AI先读取技能卡，然后按照“先写失败测试、再写实现、最后让测试通过”的流程来操作。它生成了三个测试用例：空行文件、包含空行但不以空行结尾的文件、全空文件。第一个用例在修复前会失败，修复后通过；第二个用例验证了中间空行不会破坏索引；第三个用例验证了极端情况下不会抛异常。

最终，脚本修复完成，测试全部通过。整个过程中，我只需要在关键节点说几句话确认方向，其他都是AI按照技能卡自动执行的。

4.3 效果与对比

如果不用superpowers，同样的任务，AI大概率会直接读一遍代码然后给出一个修复建议。运气好的时候，它一次改对了；但更多时候，它改完代码不会主动去验证，也不会想到要补测试用例。有了技能卡，AI的行为模式从“快问快答”变成了“按流程办事”。

我自己最直观的感受是：返工率明显降低了。以前让AI改代码，经常要来回好几轮；现在它按流程走，一次通过的概率高了很多。而且因为过程规范了，最终产出也更可控，代码风格和你预先定义的规范更一致。

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

5.1 安装后AI找不到技能

这是出现频率最高的问题。症状是：技能卡明明已经放进目录了，但让AI执行某个技能时，它说“我不知道这个技能”或者“没有找到相关技能”。

排查思路按顺序来。先检查技能目录的路径是否在AI工具的扫描范围内。用ls命令确认目录结构，重点看看是不是多套了一层目录。比如你把skills放在~/.claude/skills/superpowers/skills下面，AI扫描的是~/.claude/skills，那它看到的是一堆子目录，而不是技能目录，自然加载不到。

再检查一下SKILL.md的文件名是否正确。有些工具对技能文件的命名有严格要求，必须是SKILL.md，大小写都不能错。如果是skill.md或者skills.md，AI也识别不了。

最后一个容易忽略的地方：修改技能卡之后，需要重启AI工具或重新发起一个新的对话才能生效。有些工具会缓存技能内容，如果没重启，你改的东西不会立即加载。

5.2 技能加载了但没按技能执行

有时候AI能“看到”技能，但在执行任务时没有严格按照技能卡里的步骤来做。比如技能卡要求“先写测试再写实现”，但AI还是直接写了实现。

这种情况大概率是技能卡的指令和用户当前提示词发生了冲突。AI倾向于优先响应用户的最新指令。如果你在对话里说“先帮我改一下代码”，AI就会直接改，哪怕技能卡里写着要先写测试。

解决办法有两种。第一种是严格约束AI的启动流程：在对话最开头明确说“请使用test-driven-development技能执行，并且严格按照技能中的步骤顺序来做，不要提前写实现代码”。第二种更稳妥：把对步骤顺序的要求直接写进技能卡的第一句，比如“这是唯一可接受的执行顺序。开始执行时，先展示你对步骤的理解，然后按步骤操作”。把“唯一”“必须”这类强约束词写进去，AI遵循的可靠性会高很多。

5.3 上下文被大量技能卡占满，效果反而变差

我刚接触superpowers时犯过一个错误：把二十多个技能全部塞进系统提示词里。结果AI变得非常“啰嗦”——它总是试图在回答里体现自己“记得”很多技能，实际有效地执行反而变差了。

原因很简单：上下文窗口是有限的。技能卡是给AI学习用的“操作手册”，不是给用户看的“产品目录”。把几十个技能说明一起塞进去，AI会迷失在“我有哪些能力”的自我展示中，而忽略了“我现在该执行哪一项”。

正确的做法是“按需加载”。superpowers的设计本来也是按需加载的——你让AI用哪个技能，它才去读取对应的技能卡。不要试图把所有技能混在一起全局加载。如果某些技能的使用频率特别高，可以考虑单独建立一个精简版技能卡，只保留最核心的步骤。

5.4 版本更新时技能内容变化，旧项目失灵

superpowers更新比较活跃，有些技能的内部结构会调整。我之前有一个自动化脚本，依赖git-workflow技能卡里的某个输出格式。结果技能更新之后，输出格式变了，脚本解析就崩了。

这个问题的解决方案其实很朴素：把技能目录锁定在一个固定的commit版本上，不要总是拉最新代码。改用软链管理的话，在克隆仓库之后执行一次git checkout指定到你验证过的commit即可。新版本可以先在测试环境里跑几天，确认没问题再切过去。

6. 一些来自实际使用的避坑心得

最后聊点书本上看不到的体会。

superpowers最核心的价值，不是“让AI更聪明”，而是“让AI更听话”。它把模糊的协作过程变成了明确的执行流程。但这也意味着，技能卡本身的质量直接决定了AI的执行质量。如果你只是从仓库里拉下来就直接用，效果可能并不会立竿见影——因为通用技能卡面向的是大多数人的场景，你的项目可能有自己的编码规范、自己的Git工作流、自己偏好的文档风格。建议你先跑通默认技能，然后挑最影响你效率的一到两个技能，花点时间做定制。

定制时不要贪多。先改一个，比如把code-review的输出格式改成你们团队提PR时的模板格式。用两周，感受一下变化，再决定下一个改哪个。一上来就大改特改，很容易失去重点。

另外，提醒一点：技能卡里的“负面约束”比“正面指令”重要得多。AI天然有讨好用户的倾向，如果你不在技能卡里明确写“不要说什么”，它就会输出一堆正确的废话。我见过的最实用的技能卡，往往有一半篇幅都在写“不要做什么”。这条经验值得你写第一个自定义技能时重点参考。

superpowers这套东西后续能怎么扩展？我自己在尝试的方向是：把团队的经验文档、Code Review规范、发布检查清单都整理成技能卡，让每个接手项目的AI都能快速进入状态。等积累到一定量之后，新同事入职培训的很多内容都可以交给AI来执行。这个思路，比让AI记住一堆公司文档要有用得多。