企业官网建设流程全解析

1. 先搞清楚：superpowers到底是什么，为什么大家都在装

如果你最近在逛开发者社区，大概率会频繁刷到 superpowers 这个词。很多人问 superpowers 具体怎么使用、有哪些 skills、怎么引入这些技能，还有人上来就直接问怎么安装。我一开始也以为是某个游戏模组，后来发现它其实是给 Claude Code 这类 AI 编程助手准备的一套技能库（skill library），能让助手从"你问我答的聊天机器人"变成"有标准开发流程的结对程序员"。

先说痛点。裸装的 AI 编程助手其实有个很明显的问题：你让它"写一个登录功能"，它能给你吐出一大段代码，但遇到真正的项目级任务——比如一个新模块从需求分析到上线、一个历史遗留 bug 的排查、一次跨文件的代码重构——它就容易东一榔头西一棒子。原因是它默认没有"流程意识"，不知道要先澄清需求、再拆任务、再写代码、再验证，你问什么它答什么。superpowers 干的事情，就是把这些工程实践固化成一个个可调用的skill，让助手在接到任务时，像人一样按步骤推进。

所以这套东西最适合谁用？正在用 AI 编程助手做实际项目开发的工程师，尤其是经常要独立完成小需求、改 bug、写单测的同学。它不是给你加一两个 cool 的功能，而是把"需求分析—方案设计—任务拆解—编码实现—调试审查"这一整套工作流灌进助手脑子里。下面我把安装、技能清单、实操流程和踩坑记录一次说清楚，照着做就行。

提示：superpowers 本身是开源项目，社区迭代很快，skill 的具体名称和数量会随版本变化，但核心设计思路和用法是稳定的。我下面写的以当前主流版本为准，安装后如果发现个别 skill 名字不一样，别慌，去技能列表里翻一下对应功能就行。

2. 安装与引入：把技能包接到 Claude Code 里

2.1 方法一：通过插件市场一条命令装完

最省事的安装方式是利用 Claude Code 自带的插件市场功能，不需要手动下载文件，整个过程在对话交互里就能完成。

在 Claude Code 的输入框里依次执行两条命令：

/plugin marketplace add obra/superpowers-marketplace /plugin install superpowers@superpowers-marketplace

第一条命令是把 superpowers 对应的插件市场源加入你的本地配置，第二条才是真正把技能包装进去。注意命令里的@superpowers-marketplace不能漏，它指定了从这个市场源拉取，否则会提示找不到插件。

装完之后，建议立刻验证一下。你只需要在输入框里输入/，正常情况下会自动弹出插件命令列表，能看到以 superpowers 开头的条目。如果看不到，先重启一下 Claude Code 会话，再输入/plugin查看已安装列表，确认 superpowers 在列表里并且状态是 enabled。

2.2 方法二：手动 clone 进插件目录

插件市场偶尔会抽风，或者你用的 Claude Code 版本比较旧、还没适配市场功能，这时候手动克隆就是最稳的方案。

在终端里执行：

git clone https://github.com/obra/superpowers.git ~/.claude/plugins/superpowers

然后重启 Claude Code，让它重新扫描插件目录。这里有个小细节：先把仓库 clone 到临时目录，确认内容完整后再移动进插件目录。我踩过一次坑——大文件没拉完就被我中断了，结果目录里只有一半 skill，看起来装了但一个都用不了。用 git 的话，保险起见可以加--depth 1只拉最新版本，速度更快，也不容易出问题：

git clone --depth 1 https://github.com/obra/superpowers.git ~/.claude/plugins/superpowers

2.3 装完怎么验证、怎么唤起这些技能

验证安装成功最直观的方法是：在新会话里输入/superpowers，如果它能列出全部 skill 清单，说明装载成功。输入superpowers加空格再加一个关键词，比如superpowers debugging，可以直接唤起对应的调试技能。

这里要特别强调 skill 的唤起方式，因为这决定了你用得顺不顺手。技能不是靠普通对话聊天来触发的，而是走斜杠命令（slash command）机制。只要输入/，Claude Code 会弹出自动补全列表，按 Tab 键可以循环切换候选，回车就是选中执行。日常用的时候，我基本是/superpowers后面跟 skill 名，或者直接输 skill 名让补全帮忙，效率比翻文档高得多。

注意：普通地问助手"你能帮我调试一下吗"和调用 debugging skill 是两回事。前者是自由发挥，后者是执行一整套结构化的调试流程。很多人装了技能觉得没用，其实是因为全程在聊天，根本没用斜杠命令去唤起它。

3. 有哪些skills：核心技能分类与各自适用场景

3.1 需求与规划类：brainstorming、creating-plan

brainstorming是这个技能包里的门面担当，专门用来把模糊想法理成清晰需求。它不会让你直接写代码，而是通过一连串提问把需求边界、用户场景、验收标准一条条问清楚。典型的使用场景是产品给你丢过来一句话"把列表页加个筛选功能"，你要是直接开写，大概率写错方向，但用 brainstorming 跑一轮，它会逼着你去确认筛选条件、交互方式、默认状态、性能要求这些原本含糊的细节。

creating-plan则是把已经确定的需求拆成可执行的实施步骤。它输出的计划通常是一份带顺序的任务清单，每个任务明确到文件级别，比如"第一步修改api/schema.py增加字段，第二步更新views.py的查询逻辑……"。这个 skill 的价值在于，它把"整个项目"拆成了"一个接一个可以验证的小步骤"，让 AI 助手和你都能随时知道现在做到哪了，不会中途跑偏。

3.2 编码实现类：implementing、generating-unit-tests

implementing是真正的"写代码"技能，但它不是无脑生成代码。它要求先读取计划、明确当前步骤的目标，然后一个步骤一个步骤地实现，每完成一小块就停下来确认，而不是一次性甩给你几百行代码。这种风格很像真人结对编程里的"小步提交"，好处是出问题了能立刻定位到具体步骤，排查成本低很多。

generating-unit-tests是我个人认为性价比最高的技能之一。很多人写完代码懒得写单测，或者不知道从哪下手，这个 skill 会针对你刚实现的功能模块，按照"正常输入—边界输入—异常输入"的思路生成测试用例。它还能识别应该 mock 掉的外部依赖，避免单测变成"测了个寂寞"。我用它给一个支付回调模块补过测试，半小时前还是测试覆盖率 0，跑完它生成的用例直接到 80% 以上，对回归保护非常有帮助。

3.3 质量保障类：debugging、code-review

debugging技能解决的问题是"代码为什么行为不对"。它的流程设计得很讲究，不是上来就猜，而是先复现问题、再缩小范围、再形成假设、再验证假设。比如线上反馈某个接口偶尔超时，它会引导你先找出稳定复现的条件，再根据调用链路把怀疑范围从"整个服务"缩小到"某个第三方调用"，每一步都有明确目的。这套方法论你在书本里也能看到，但它把步骤固化成了助手的行为轨迹，真的会一项项问你、逼你补充信息。

code-review则是把代码审查变成清单式检查，从逻辑正确性、边界条件、安全性、性能、可读性几个维度过一遍。我一般是在实现完一个功能后直接调它，让它以审查者视角挑毛病，效果约等于多了一个不客气的 code reviewer。它挑出来的问题不一定都对，但绝大多数是真实的隐患。

3.4 技能之间的组合逻辑

单独看每个 skill 可能觉得平平无奇，但 superpowers 真正值钱的地方在于技能之间的组合关系。一个标准开发流程里，brainstorming 负责想清楚做什么，creating-plan 负责决定怎么做，implementing 负责做，generating-unit-tests 负责验证做的对不对，debugging 负责出了问题怎么办，code-review 负责最后把关。

它们不是孤立的工具，而是一条完整的流水线。你完全可以跑完 brainstorming 后让它基于结论直接生成 creating-plan，再让计划驱动 implementing 干活。这种"技能链"的设计很聪明：每一步的输出都是下一步的输入，上下文是连续的，助手不会因为跨了多个对话就丢失前面的决策依据。我第一次意识到这一点，是看着它从一份粗糙的需求描述一路走到带单测的成品代码，中间的衔接几乎不需要我重复强调任何需求细节。

4. 具体怎么用：一个真实需求走完整套流程

4.1 第一步：brainstorming 把需求聊到透

我拿最近一个实际需求当例子：要往现有的用户系统中加一个"登录提醒"功能。如果直接写代码，我可能十分钟就写完，但产品要求其实有一堆没说清楚的地方——提醒方式是站内信还是邮件、登录异常到什么程度才算提醒、要不要支持用户自助关闭。

我直接输入/superpowers brainstorming，然后给它一句话需求。这个技能会开始连环提问，第一个问题就是"这个功能希望解决的核心问题是什么"，接着会追问"你设想的用户使用流程是怎样的""有哪些明确的边界条件需要排除"。整个对话大概持续了十几轮，最后输出一份结构化的需求说明，包含背景、目标、范围、非目标、验收标准。光这一步就帮我排除掉了两个我原本完全没考虑到的情况：比如"忘记密码后的登录成功"到底算不算异常登录，后来跟产品确认，这个确实不用提醒。

4.2 第二步：creating-plan 输出可执行计划

需求确认后，我没有直接写代码，而是调/superpowers creating-plan。它会基于 brainstorming 的结论生成实施计划。这份计划分了几步：先是后端新增登录日志表并记录登录事件，然后是规则判断模块决定哪些事件要触发提醒，最后是通知发送和用户设置页的开关。

每一步都标注了要动的文件、改动内容和验证方式。比如其中一步写着"在auth/service.py增加record_login_event()，记录成功与失败两类事件，后续用单测验证事件落库"。拿到这样的计划，我就能评估工作量，还能直接拿着它跟产品对进度。这种"先计划后执行"的方式，比我以前想到哪写到哪要可控得多。

4.3 第三步：implementing 逐步落地

计划确认后，我输入/superpowers implementing，告诉它"按计划开始"。它会先读取计划文件，然后从第一步开始执行，每完成一个步骤就停下来汇报结果、等待确认。第一个步骤是后端日志表，它把建表 SQL、模型定义和事件记录函数都写好了，还顺手加了两个基础单测。我检查完没问题，回复"继续"，它才进入下一步。

这个过程体验很好的一点是：它不会一口气改完全部文件，而是像真人结对一样一小步一小步来，每一步改动我都能审查。实际操作中有一步它打算直接改数据库表结构，我让它先检查一下线上有没有存量数据需要迁移，它意识到问题后修改了方案，改用兼容性更好的增量方式。这种"每步可控"的模式，真的能避免 AI 撸一大坨代码最后没法 review 的尴尬。

4.4 第四步：debugging 与 code-review 收尾

实现过程中遇到一个 bug：邮件提醒偶尔重复发送。我直接唤起/superpowers debugging，它没有让我反复描述，而是先问"能不能稳定复现"，然后引导我检查发送逻辑里有没有并发导致的幂等问题。最后定位到是回调重试机制和定时任务之间缺了一个去重标志，修复方案只改了一小段代码。

全部完成后我又跑了一遍/superpowers code-review，它以审查者身份把这次新增的代码过了一遍，挑出两个值得改的点：一个是提醒开关的默认值应该由配置中心控制，而不是写死在代码里；另一个是新增的查询缺少索引，数据量大时会慢。这两个问题如果只靠我自己 review，大概率会忽略掉索引那条。

5. 常见问题与避坑经验

5.1 技能装了却不生效

这是问得最多的问题。装完插件后/superpowers没反应，90% 的原因是Claude Code 没有重启，插件缓存没刷新。先重启会话，再输入/plugin检查状态；如果插件列表里根本没有 superpowers，就回头看安装命令是不是执行成功、目录路径对不对。手动 clone 方式还要注意目录结构，插件根目录下必须直接是 skill 文件或者约定好的子目录，如果多包了一层，比如~/.claude/plugins/superpowers/superpowers/，扫描器就识别不了。

5.2 上下文过长、输出被截断

技能会生成结构化的长文档，尤其 brainstorming 和 creating-plan，一轮跑下来输出很占上下文。遇到长对话场景，建议把前一步生成的文档写进项目里的独立文件，比如docs/plan.md、docs/requirements.md，然后用普通对话让助手去读文件，而不是把整份文档留在聊天记录里。这样既保证后续步骤能访问到信息，又不会让上下文窗口早早爆掉。

5.3 什么时候不该用技能

不是所有任务都适合调 skill。那种一句话能说清的小改动，比如"把按钮颜色改成蓝色"，直接让它改就行，走完整套 brainstorming 流程纯属浪费时间。我的经验是：改动涉及多个文件、需求有歧义、或者要排查定位阶段的问题时，才值得动用对应技能。另外，调试类技能在你完全没思路时帮助最大，如果你已经有了明确的怀疑对象，直接让它按你的假设去验证反而更快，不用强行走一遍全流程。

5.4 一组值得记住的小技巧

还有一个关于debugging的细节：它给出的修复建议，我一般不会直接全盘接受，而是让它把"问题根因分析"和"修复改动"分开输出，先看分析是否合理，再应用改动。这个习惯帮我挡住了至少两次它"误诊"的情况——都是它把表象当成了根因。

最后再分享一点个人体会

我一直觉得 AI 编程助手最大的问题不是不够聪明，而是太顺着用户——你说什么它做什么，从来不主动纠正方向。superpowers 这套技能库的底层逻辑，其实是把现实中好的工程习惯（先澄清需求、再拆步骤、小步验证、审查收尾）强行注入到助手的对话习惯里。装上它不是多了几个炫酷命令，而是让 AI 从"打下手"变成了"有章法的协作者"。

如果你刚装好，建议第一件事别急着在真实项目上用，先拿一个小 demo 需求把 brainstorming → creating-plan → implementing → code-review 完整跑一遍，感受一下每步之间的衔接和输出结构。跑完这一圈，你对"怎么引入这些技能"的理解会比看十篇文章都深。我唯一想提醒的就是开头那句话：技能列表会随版本变，但"让 AI 按流程做事"这个核心思想，是这套工具真正值得你花时间去掌握的东西。