企业官网建设流程全解析

最近被一个叫 "superpowers" 的项目勾起了兴趣。起初我以为又是某个开发者搞出来的新框架，直到自己装完、跑通、把几个技能真正用进日常开发，才发现它解决的其实是一个特别实际的问题：AI 助手能力再强，如果没有一套清晰的工作方法，做起具体任务来还是会随性发挥。Superpowers 的做法很朴素——把专业领域的方法论拆成一个个可复用的 Skill，用 Markdown 文件写清楚目标、边界、步骤和质量标准。AI 在执行任务时读到这些 Skill，就像有个老师傅在旁边按步骤指导它干活。

我之所以想把它整理成一篇笔记，是因为这玩意儿第一次用的时候确实有点门槛。光看仓库说明，你只知道它叫"超级能力"，但不知道它到底能干什么、装好之后怎么让 AI 调用、里面那些 Skills 之间有什么区别。这篇文章我打算从一个真实使用者的角度，把安装过程、Skills 清单、调用方式、以及我自己写 Skill 的经验都过一遍。无论你是想在 Claude Code 这类终端 AI 工具里提升生产力，还是单纯好奇"给 AI 装上技能"这件事怎么落地，这篇都能给你一个能直接上手的路径。

1. Superpowers 到底是什么：它不是插件，是 AI 的"技能操作系统"

1.1 为什么叫"超级能力"

先聊个直觉。我们平时用 ChatGPT、Claude 这类 AI，多少都会遇到一种情况：它什么都能聊，但你要让它规规矩矩做一件事，比如"帮我写一个符合项目规范的单元测试"，它可能会写，可写出来的东西要么风格不对，要么漏掉了边界条件。问题出在哪儿？出在"知识"和"能力"之间缺了一层东西——方法论。

Superpowers 补的正是这一层。它把某个领域的专家做法，比如怎么拆解复杂问题、怎么审查代码、怎么设计系统，写成结构化的 Skill 文件。每个 Skill 不是简单的提示词，它包含触发条件、执行流程、质量标准、输入输出格式。AI 在运行到这个 skill 的时候，会像切换了工作模式一样，不再自由发挥，而是按这套方法论来。

我试过一个最直观的例子：让 AI 分析一个需求时，如果直接问，它会给你一堆通用建议；但如果它先调用"设计思维"这个 Skill，它会先帮你澄清用户、问题、约束，再逐步收敛方案。结果完全不一样。所以 Superpowers 的"超级能力"，本质上是把隐性的人类工作经验变成了 AI 可以按需加载的显式技能。

1.2 它和插件、Prompt 模板的区别

很多人会问：这不就是插件吗？不完全是。插件通常是从外部给 AI 工具加功能，比如接入某个数据库、增加一个代码解释器。而 Superpowers 的 Skill 不直接改工具本身，它改的是 AI 的"处理逻辑"。它更像是一套 SOP（标准作业程序），告诉 AI 遇到某类任务时应该怎么思考、怎么安排步骤、怎么输出结果。

那它和普通 Prompt 模板的区别又在哪里？普通 Prompt 是一段一次性的话，你复制进去，AI 按这段话执行，作用是瞬时的。Skill 则是放在项目里的一个文件，AI 会在合适的时机自动读取，或者由你主动指定。它带有"身份定义"、"触发条件"和"检查清单"，AI 在执行过程中还会自查，相当于把一个经验丰富的老手拆成了可复用的文档。

所以我的理解是：插件是给 AI 换工具，Prompt 是给 AI 递纸条，Skill 是给 AI 做培训。Superpowers 这个项目的核心价值，是建立了一套标准化的"培训教材"体系，让 AI 能稳定地表现出专家的水准。

2. 安装 Superpowers：从零到能调用的完整流程

2.1 环境准备：先确认你的终端 AI 用的什么内核

Superpowers 的 Skills 机制目前最成熟的载体是终端类 AI 编程工具，尤其是 Claude Code。安装之前，先确认几个基础条件：

• 终端 AI 工具已装好，并且能正常对话。
• 本机有 Git，因为 Skills 文件需要从仓库拉取。
• 知道项目的CLAUDE.md或者对应的配置文件放在哪。这个文件通常放在项目根目录，AI 会把它作为项目的"长期记忆"。

如果你用的是别的支持 Skill 机制的 AI 工具，原理一样，只是配置文件路径和加载命令可能略有不同。我的建议是第一步先别想着一步到位，先用一个空项目验证"能不能跑通"，再去现有项目里引入。

2.2 拉取与加载：具体操作步骤

安装 Superpowers 通常不是"下载一个 exe"那种思路，而是把 Skills 文件放到你的 AI 工具能读取的目录里。以 Claude Code 为例，常见流程是：

1. 在项目根目录下建一个.claude/文件夹（如果还没有的话）。
2. 用 Git 把 Superpowers 仓库克隆到某个本地目录，比如~/.superpowers。
3. 将仓库里的skills/目录复制或软链到项目的.claude/skills/下。
4. 修改项目的CLAUDE.md，告诉 AI"项目里有一批技能文件在.claude/skills/下，遇到相关任务时主动读取并遵循对应 Skill 的指导"。

如果你看到某个安装命令可以一键完成，通常也是在做上面这几件事的自动化。我建议动手做一遍，因为只有理解了文件放哪，后面调试才知道去找谁。

有个细节比较容易忽略：很多仓库里的 Skill 文件不是直接放在skills根目录下的，而是按类别分了子目录，比如skills/Think/、skills/Engineering/。Claude Code 默认会递归扫描这些子目录，但有些工具不会，所以装完后第一件事就是确认 AI 能不能"看见"全部技能。

2.3 验证安装：怎么知道它已经生效

装完别急着开工，先做一个快速验证。最简单粗暴的办法是直接问 AI：

"你支持哪些 skill？如果你是 Superpowers 用户，请把你当前可用的技能列出来。"

如果 AI 能给出一个列表，说明配置文件生效了。如果它答非所问，大概率是CLAUDE.md里的引导写得不够直白。这时我会再补一句：

"请先读取.claude/skills/目录下所有文件，然后总结每个 skill 的功能。"

这一步很关键。因为 AI 只有在上下文里真实读到过这些文件，后面才会调用。有些安装失败不是文件放错了，而是 AI 压根不知道有这堆文件存在。你可以在CLAUDE.md里写清楚"在开始任何任务之前，扫描 skills 目录并选择匹配的 skill"，这样就能避免"技能在手却不会用"的尴尬。

3. 内置 Skills 大盘点：拿到手先该试哪几个

Superpowers 仓库内置的 Skills 数量不少，我按自己用下来的感受分成三类，每类挑几个有代表性的，这样你拿到手之后不至于迷路。

3.1 思维类技能：设计思维与系统思维

第一个值得优先尝试的是 Design Thinking（设计思维）。这个 Skill 会强制 AI 在动手之前先围绕"用户是谁""要解决什么问题""约束是什么"展开一轮结构化提问。举个例子，我让它帮我规划一个博客系统的功能，它没有直接列功能列表，而是先模拟了三种不同身份的角色，分析他们各自的核心诉求，最后再回到系统设计上。这个流程会让你意识到：平时我们太急着要答案，反而忽略了最前置的问题定义。

另一个是 System Thinking（系统思维）。这个 Skill 主要用于处理边界模糊、因素多、相互关联的问题。它会让 AI 列出影响系统的关键变量、因果关系、潜在反馈循环，最后再给干预点建议。我第一次用它分析一个架构升级方案时，AI 突然变得像一个资深架构师，不是简单给方案，而是先画了一张"影响链路图"（当然，是文字描述的），指出数据库写入瓶颈很可能不在 SQL 本身，而在调用链上的缓存过期策略。这种视角，靠普通 Prompt 很难稳定出现。

这两个技能合用效果很好：Design Thinking 解决"做不做、做什么"的问题，System Thinking 解决"怎么做、先动哪里"的问题。

3.2 工程类技能：代码审查与测试生成

代码相关是我用得最频繁的领域。Superpowers 里有个 Code Review（代码审查）Skill，它不是你让它"Review 这段代码"它就给反馈那种，而是有一套完整的检查清单：可读性、边界条件、性能隐患、安全风险、依赖合理性、测试覆盖。AI 会逐项排查并给出严重程度标记。我用它审过一段刚写完的接口代码，还真抓出了一处并发场景下可能出现的数据竞争——这要放在平时，我可能得等测试环节才能发现。

还有 Unit Test Generation（单元测试生成）这类 Skill。它的特色是不会无脑生成 20 条重复用例，而是先分析代码分支、边界、异常路径，再挑选最优覆盖集合。而且它会把测试设计和实现分开：先给出测试计划，让你确认，再生成代码。这个"先计划后执行"的习惯很值得学习。

3.3 写作与解释类技能

不要以为 Superpowers 只服务程序员，写作和解释类的 Skill 对日常办公同样有用。比如 Explain Like I'm Five（面向新手解释复杂概念），AI 会主动切换比喻和分层讲解策略。我有一次让它解释"进程与线程的区别"，它用"厨房、厨师、菜谱"做类比，同时保留了一小段面向工程师的精确术语，效果比我自己写强不少。

还有 Requirements Clarification（需求澄清）这类 Skill，它在收到一个模糊需求时会先输出一份"需求澄清清单"，包括目标、用户、验收标准、排期约束、风险假设。我在项目启动会上试过一次，直接把需求讨论从"各说各话"拉到了"逐项对齐"的节奏。这个技能后面我会在自定义部分再展开，因为它非常适合扩展成你自己的日常工具。

4. 怎么把 Skill "引入"实际工作流

4.1 触发方式：自动触发与手动唤起

安装完成后，最关心的问题就是怎么让它干活。Superpowers 的 Skill 有两种触发方式。

第一种是自动触发。靠的是 Skill 文件里定义的trigger字段，比如某个技能设置了"当用户请求包含'代码审查'四个字时自动激活"。这种方式适合高频、标准化的任务，能减少你的显式指令成本。但缺点是如果触发词设置得太宽泛，AI 容易误激活。这时你会看到它突然开始按某个流程走了，反而显得笨拙。所以我在实际使用中，更习惯用第二种方式。

第二种是手动唤起。在对话里明确指定，比如"请使用 Code Review Skill 处理这段代码"。这相当于你主动按下某个工具的开关。默认场景下，我建议先手动唤起几次，确认 AI 的行为符合预期后，再考虑把某些高频场景改成自动触发。

还有一个小技巧：Superpowers 允许在同一段对话里叠加多个 Skill。比如我先用 Requirements Clarification 澄清需求，再用 Design Thinking 确定方案，最后用 Code Review 检查落地代码。AI 会依次执行，不会混乱。

4.2 多技能串联：处理一个复杂需求的标准姿势

单技能调用很简单，但要让它们发挥最大价值，学会串联才是关键。我一般遵循这个流程：

1. 拿到需求，先手动唤起 Requirements Clarification，让 AI 把需求边界、验收标准、隐含假设问清楚。
2. 需求明确后，调用 Design Thinking 或 System Thinking，对解决方案做发散和收敛。
3. 确定技术方案，进入编码阶段，让 AI 按项目内约定写代码。
4. 写完代码，自动或手动触发 Code Review，让 AI 按检查清单自查。
5. 最后调用测试生成技能，补上关键测试用例。

这套流程跑下来，你会感觉 AI 不是一个"问答机器人"，而是一个有章法的协作者。它输出的每个阶段产物都可以作为下一步输入，整个链路是顺滑的。新手容易犯的错是：只把 Skill 当一个"格式化输出器"，却忽略了前后顺序。技能和技能之间是有依赖关系的，先用哪个、后用哪个，直接决定了产出的质量。

4.3 让 Skill 常驻项目的配置技巧

如果你已经在某个项目里跑顺了，想让它长期生效，可以从两个层面入手。

第一层是项目级配置。在CLAUDE.md里明确写出"本项目已启用.claude/skills/下的技能库，具体技能清单包括……"。这样每次新起一个会话，AI 都会重新读取项目记忆，知道有哪些技能可用。注意，CLAUDE.md不要写得过长，AI 的上下文窗口有限，你把技能清单列清楚就够了，没必要把每个 Skill 的内容都抄进去。

第二层是个人级配置。如果你每天都想用某个技能，可以把它放到全局配置目录（默认在~/.claude/下），这样无论你打开哪个项目，AI 都能看到这些技能。我习惯把思维类和需求澄清类的通用技能放全局，把代码审查这种和项目强相关的留在各个项目的本地目录里。

还有一点值得提醒：技能文件多了以后，AI 每次扫描都会消耗 token，并增加响应延迟。我自己的经验是，一个项目里放 15 到 25 个技能就是比较舒适的上限，再多反而会让 AI 在"选哪个技能"上纠结，甚至选错。定期清理不用的技能，和清理代码依赖一样重要。

5. 自己写一个 Skill：技能文件的最小可复现模板

Superpowers 真正的自由度在于：你可以自己给 AI 加技能。写一个 Skill 没有想象的那么难，本质就是按约定格式写一个 Markdown 文件。

5.1 Skill 文件结构拆解

一个标准的 Skill 文件通常包含两部分：YAML frontmatter 和正文。

YAML frontmatter 负责定义元信息和触发逻辑。常见字段有：

• name：技能名，AI 会凭这个字段识别。
• description：给 AI 看的描述，写清楚这个技能解决什么问题，什么时候用它。
• trigger：触发条件，可以是一个关键词方式，也可以留空只做手动唤起。
• version：版本号，方便你后续迭代。

正文部分是核心，建议按下面几个小节组织：

• 背景说明：这个技能为什么存在，适用场景和不适用场景。
• 输入要求：需要调用方提供哪些信息，最好有模板或示例。
• 执行步骤：步骤要尽可能地结构化，大步骤下拆小步骤，让 AI 一步步执行。
• 检查清单：AI 完成输出后，需要自我对照哪些质量标准。
• 输出格式：定义最终输出的结构，方便下游继续处理。

有一个比较容易犯的错误：把执行步骤写得太抽象，比如"分析用户需求"这种一句话。AI 确实能理解，但效果跟普通 Prompt 没什么区别。好的 Skill 应该写清楚"分析用户需求时至少要考虑以下五个维度：……，并且每个维度都要用一个小标题单独展开"。步骤写得越像操作手册，最终输出就越稳定。

5.2 写一个"需求澄清"技能的实战

为了让你能直接照抄，我分享一下我自定义的"需求澄清"技能，它是我用的最多的技能之一。

frontmatter 部分：

--- name: requirements-clarification description: 当用户提出一个模糊或复杂的需求时，主动引导用户澄清目标、场景、验收标准和边界，输出一份结构化的需求说明。 trigger: 需求澄清 version: 1.0.0 ---

正文部分，我要求 AI 按以下步骤执行：

1. 先复述一遍你对需求的理解，并要求用户确认或纠正。
2. 依次询问这些信息：业务目标是什么；目标用户是哪些人；核心场景是哪一个；可接受的验收标准是什么；不能动的边界条件有哪些；有哪些隐藏假设。
3. 如果用户给的信息不足，不要硬猜，使用"如果确认不了，我们可以先用默认假设"的方式推进。
4. 输出格式固定为：目标、用户、场景、验收标准、边界、假设、待确认问题，七个部分。
5. 最后给出一个"下一步建议"，比如建议先做原型，还是先写接口文档。

这个技能写完后，我把它放到.claude/skills/目录里，并在CLAUDE.md里加了一行"当用户说'帮我理清需求'时，使用 requirements-clarification 技能"。实际效果非常好，AI 不会再随便抛出一堆泛泛的功能列表，而是像项目经理一样逼着你去想清楚。

5.3 调试 Skills 的常见问题和性能建议

写 Skill 时最常遇到的问题是"AI 不按我写的步骤执行"。我的排查思路是这样的：

• 先确认 AI 真的读到了这个文件。可以在对话里问它"requirements-clarification 这个技能的执行步骤是什么"，如果它答不出来，说明文件路径或索引有问题。
• 再检查 frontmatter 格式。YAML 对缩进特别敏感，一个空格错位会导致整个字段解析失败。建议写完先本地校验一遍 YAML 格式。
• 最后是描述写得是否清楚。有时候 AI 不是不执行，而是不知道什么时候该用。把 description 里那部分"什么时候用它"写得再具体一些，触发率会明显提升。

性能方面，我前面提过技能数量不宜太多。另外还有个细节：每个 Skill 文件本身可以适当控制篇幅，我一般控制在 500 到 1000 字。太短了说明步骤不够细，太长了你每次使用都要消耗大量 token，而且 AI 可能只记忆开头，忽略后面的细节。如果确实需要长步骤，可以拆成多个 Skill，让它们按顺序调用，而不是塞在同一个文件里。

6. 用了一段时间后的实战心得

如果你已经看到这里，说明你大概也想装一套试试。我分享一下自己踩过坑之后的一些体会，希望能帮你少走点弯路。

首先，别一口气打满。刚开始用 Superpowers 时，我一股脑把仓库里所有 Skill 全塞进项目里，结果 AI 每次响应慢了不少，还经常选错技能。后来我砍到只剩 15 个左右，并且把最常用的几个设置为手动唤起，情况立刻好转。技能这东西，贵精不贵多。

其次，自己写 Skill 才是精髓。内置技能帮我们解决了"从 0 到 1"的问题，但真正好用的往往是针对自己工作流定制的那几个。比如我给自己的写作流程写了一个"博客文章生成"技能，规定开头必须用场景切入、每个小节要有具体案例、结尾必须给可操作建议。每次让 AI 写初稿，它都能稳定产出我想要结构的内容，不再需要我在 Prompt 里反复啰嗦。

最后，Skill 的维护也很重要。我每隔两周会过一遍自己写的技能文件：有没有哪个触发条件和现在的习惯冲突了？哪个技能的输出格式可以优化？把技能当成活文档来维护，AI 配合你的能力才会越来越强。

Superpowers 给我的感觉不像是一个普通工具，更像是一套"让 AI 学会专业人士思考方式"的框架。它没有把"智能"直接堆给你，而是给了你一个组织经验、流程、标准的结构。安装和使用都不难，难的是你愿不愿意花一点时间，把你脑子里那些"只有我知道怎么做"的东西，写成一个 AI 也能读懂的流程单元。一旦做完，你会发现手里的 AI 真的多了一层"超级能力"。