企业官网建设流程全解析

1. Superpowers 是什么：不是提示词合集，而是一套技能系统

如果你已经用 Claude Code 写过一阵子代码，应该会发现一个很微妙的现象：同一个需求，上午问它，它给出一套非常规范的步骤，先梳理需求、再列计划、最后动手；下午再问一次，它可能就直接甩代码了。模型没有变，变的其实是上下文里那一段提示词带来的随机性。提示词写得细，输出质量就稳；提示词写得糙，输出全靠运气。这种不确定性，用一次两次还能忍，天天用就会变成一种折磨。

Superpowers 解决的就是这个问题。它是一个开源项目，作者是 Jesse Vincent，圈子里一般喊 Obra。项目的核心不是给你一堆花里胡哨的快捷指令，也不是一个封装好的安装包，而是一整套可以被 Claude Code 自动加载、自动匹配的技能文件。每个技能就是一个结构化的 Markdown 文件，里面写清楚：这个技能在什么场景下触发、按什么步骤执行、执行过程中要守哪些规则、最后要输出什么结果。Claude Code 会在你发起任务的时候，先扫描并匹配这些技能，匹配上了，就按照技能里的协议来干活。

我把这套东西装进 Claude Code 之后，最直观的感受是：Claude 的行为变得有章法了。让它写功能，它会先出计划；让它修 bug，它会先复现、再假设、再动手；让它做代码审查，它会按一套固定清单逐条核对。这些不是它碰巧做到的，而是技能文件里的协议在约束它。对于我这种天天和 AI 协作写代码的人来说，这种"稳定"比"偶尔超常发挥"重要得多。

这篇文章我打算用最实在的方式，把 Superpowers 的方方面面讲清楚：它内部到底有哪些 skills、每个技能是干什么的、怎么安装引入、日常怎么用、哪些坑我踩过以及怎么绕开。无论你是刚接触 Claude Code 的新手，还是已经在折腾技能的老手，看完之后应该都能直接上手复现。

2. 为什么需要技能化：从每次从零开始到按流程办事

在讲具体技能之前，我想先聊一下为什么需要技能化这个底层问题。很多人觉得，AI 编程助手不就是写提示词吗？提示词越详细，结果越好。这个说法没毛病，但问题在于，靠临时写提示词来维持质量，成本太高了。你今天写了一段非常详细的提示词，让 Claude 先做计划再写代码，你花了不少时间；明天你又得重新组织一遍。每个人的提示词风格不一样，同一个人的状态还不一样，这样就导致输出质量波动大。

Superpowers 的思路是标准化。它把那些经过验证的、有效的工作方法，比如测试驱动开发、系统化调试、小步重构、代码审查，全部写成固定的技能协议。协议一旦写好，Claude 每次在对应场景下都会走同样的流程。这就是一种肌肉记忆。好比老司机开车，不需要每次都在脑子里过一遍先踩离合、再挂挡、再松离合，动作已经固化了。AI 编程也是这个道理，把高质量的做事流程固化下来，剩下的就是稳定输出。

技能化还有一个好处，就是把专家经验外置了。比如 TDD（测试驱动开发）这套流程，很多人知道它好，但真要动手时总是忘了写测试。有了技能文件之后，Claude 会在你提出写代码的需求时主动要求先写测试。它等于随身带了一个流程监理人，提醒你按纪律干活。我自己用下来的感觉就是，以前是我催着 Claude 补测试，现在是它拦着我别跳过测试，这个反转很有意思。

另外，技能系统的匹配机制也值得多说一句。Claude Code 在匹配技能时，主要靠技能文件 description 字段做语义匹配。你提的需求和哪个技能的描述在语义上接近，哪个技能就可能被激活。所以写技能的时候，description 不是随便填的，它决定了技能在什么场景下能被捞出来。如果描述写得太宽泛，Claude 可能什么都匹配不上；写得太窄，该触发时又触发不了。这也是很多自建技能不生效的常见原因，后面我会专门讲到。

3. 核心技能拆解：Superpowers 里到底有哪些 skills

Superpowers 默认带一批技能，覆盖了从规划、编码、测试、调试到审查、重构的完整开发链路。我把里面最常用、最值得关注的技能逐个拆开讲一下。这里我不会逐字复刻仓库里的原文，而是按它们的核心协议和适用场景来解释，这样你能更快理解每个技能是干什么的。

3.1 规划与执行：Writing Plans 与 Executing Plans

Writing Plans（写计划）这个技能解决的是"任务还没想清楚就动手"的问题。它适用于任何有一定复杂度的编码任务，比如要改多个文件、要调整数据结构、要对接外部接口。触发这个技能后，Claude 会先收集任务的约束条件，包括现有代码结构、依赖关系、验收标准，然后产出一份分步执行计划。计划里每一步都标注了要改什么、为什么改、怎么验证。Claude 通常还会把计划保存成一个文件，比如plan.md，方便后续跟踪。我一般会在任务描述里直接说"先写计划"，它就会按技能协议把计划拆给我看，而不是马上开始改代码。

Executing Plans（执行计划）是跟 Writing Plans 配套的技能。它约束的不是怎么写计划，而是怎么执行计划。核心规则就是：按计划顺序执行，完成一步检查一步，不要跳步，不要中途顺手改无关代码。假如执行过程中发现计划里有错，先停下来更新计划，再继续。这个技能看起来很朴素，但它对防止 Claude 跑偏非常有效。我自己遇到最多的情况就是，让它改 A 模块，它顺手把 B 模块也重构了，动机是好的，但风险不可控。有了 Executing Plans 的约束，它就能管住手。

这两个技能配合起来，就是一套"先谋后动"的工作流。我自己的习惯是：让 Claude 先出计划，确认没问题后再让它执行。某种程度上，这等于把 Claude 从一个喜欢抢答的助手，变成了一个先交方案再施工的工程师。尤其在做跨模块改造的时候，提前看到计划可以省掉后面大量返工。

3.2 编码质量：TDD、Code Review 与 Refactoring

TDD（测试驱动开发）技能可能是 Superpowers 里价值最高的一个。它的协议非常明确：先写一个失败的测试，再写最少量的代码让测试通过，最后重构。整个过程循环往复。Claude 在 TDD 技能约束下，不会一上来就给你甩一大段实现代码，而是先问你：这个功能的核心行为是什么？我先写个测试。写完测试跑一遍，确认它是红的，再去补实现。这能逼着开发流程把测试戴上，而不是最后补作业。我自己在时间紧的时候经常跳过测试，但 Clude 按技能执行时不会让步，这种"死板"反而是好事。

Code Review（代码审查）技能给 Claude 定义了审查代码时该看什么。按我的理解，它的核心检查点包括：代码意图是否清晰、边界条件和异常处理是否齐全、有没有重复逻辑、改动是否影响了既有行为、测试覆盖是否跟得上。技能协议会要求 Claude 在审查时先读关键上下文，再逐条输出发现的问题，并且每个问题都要给出严重级别和修改建议。相比你自己对着 diff 发呆，Claude 按这套技能审查出来的结果更有条理，也更像同行评审，而不是客套表扬。

Refactoring（重构）技能的核心价值观是小步、安全、随时可回退。触发重构场景后，Claude 被要求把一个大的重构拆成若干个小步骤，每步只改变一类结构，改完立刻跑测试。如果测试挂了，马上回退到上一个安全状态。它还要避免在重构过程中顺手加新功能，保证"重构不改变行为"这条铁律。对于接手老代码的人来说，这个技能在很大程度上避免了"重构五分钟，爆炸俩小时"的局面。我在一次重构历史模块的任务里，Claude 执行的每一步都在我能接受的范围内，这个体验是非常舒服的。

3.3 调试与兜底：Systematic Debugging 和 Root Cause Undo

Systematic Debugging（系统化调试）是针对"乱猜瞎试"这个坏习惯设计的。调试场景里，Claude 容易犯的毛病就是一上来给出一堆可能的原因。系统化调试技能会强制它把调试当成科学实验来做：先稳定复现 bug，再收集环境信息，然后提出一个假设，设计最小实验去验证，根据实验结果修正假设，最后修代码并跑回归。整个过程像剥洋葱一样层层逼近根因，而不是靠玄学撞大运。有一次线上有个偶发问题，如果按以前的方式，Claude 会给出五个可能原因，让人无从下手；但启用这个技能之后，它先要求我把一句关键日志加上，跑一遍复现，直接就定位到了并发时序问题，效率完全不一样。

Root Cause Undo（根因回滚）是一个很实用的兜底技能。假设你做了好几轮改动，项目突然跑不起来了，这时最急需的往往不是接着分析，而是快速回到上一个能跑的状态。这个技能训练 Claude 用 Git 历史定位根因，找到导致问题的那个最小改动集，然后做精准回滚，而不是无脑 reset。它本质上是把后悔药这件事做得更科学。我遇到过一次改依赖配置引发的连锁报错，Claude 通过对比几个 commit 之间的差异，只回滚了那一个配置，没有影响同批次的其他功能改动，这种精度靠手工敲命令很难达到。

3.4 辅助技能：Brainstorming、Communicating 与其他

除了上面这些硬核开发技能，Superpowers 还附带一些辅助类技能。Brainstorming（头脑风暴）在需求还不明确、方案还没定型时触发，Claude 会先发散出多个候选方案，并列出每个方案的优劣势、成本和风险，而不是直接选一个就开干。这个技能特别适合用来做技术选型。我跟它讨论过几次日志方案，它对比了 JSON 格式化、结构化日志、集中采集三种路线，最后还给出了推荐顺序，比我自己调研省时间。

Communicating（沟通）这个技能我更习惯叫它汇报规范，它约束 Claude 在回答时怎么组织语言，比如先给结论、再给理由、复杂内容拆结构，避免一句话糊一脸。说实话，这个技能适合用在给非技术同事解释问题的时候。如果没有它，Claude 很容易滔滔不绝讲一屏幕底层原理，有了它之后，输出会变成"先告诉你怎么处理，再解释为什么"，可读性高很多。

此外还有一些更细分的技能，比如围绕 Git 操作、文档维护、问题拆解等场景的技能。不同版本里技能组团会略有差异，所以我更建议把它当成一个技能工具箱来看：里面装的工具会更新，但核心的设计思想是一致的，就是让 Claude 在每种典型场景下都有一套标准打法。这也意味着，你不必记下每个技能的名字，只需要知道它存在，到了该用的时候告诉 Claude 一声就行。

4. 安装与配置：怎么把 Superpowers 跑起来

说完了理论，接下来是最实在的部分：怎么安装、怎么引入、怎么验证。网上关于 Superpowers 安装的讨论不少，但很多帖子只说一句跑安装脚本，实际上安装过程中有不少细节值得展开。

4.1 安装前置条件

安装 Superpowers 之前，你至少要满足两个条件：一是已经装好 Claude Code，并且能正常对话；二是机器上有 Node.js 环境，因为安装过程和后续的管理命令都依赖 npm 生态。满足这两条，剩下的就是执行命令的事。

需要说明的是，Superpowers 依赖 Claude Code 对 Agent Skills 的支持。如果你用的 Claude Code 版本比较老，可能压根不会读取技能目录。建议在动手之前先把 Claude Code 升级到最新版，避免装完之后发现技能完全不生效，然后在版本问题上折腾半天。这个前置条件是最容易被人忽略的，我见过不少人在群里问"为什么技能不生效"，最后一看是 Claude Code 一个月没升级。

4.2 安装步骤

Superpowers 的安装方式大致有两条路线，一条是用 npm 工具直接拉起安装流程，另一条是 clone 仓库后跑安装脚本。我实测下来，前者更省事，后者更可控，适合想仔细看看技能源码的人。

# 方式一：用 npx 直接拉起安装流程 npx superpowers # 方式二：clone 仓库本地安装 git clone https://github.com/obra/superpowers.git cd superpowers ./install.sh

npx 方式执行之后，命令行会进入一个交互式的安装流程，你根据提示做选择即可。clone 方式则更透明，安装脚本会把各个技能文件复制到用户级技能目录，也就是~/.claude/skills下。这个目录是 Claude Code 默认会扫描的用户级技能位置，技能装在这里，意味着你所有项目里都能用到。

安装完成后，还可以在项目层面做引入。项目级技能目录是.claude/skills，放在项目根目录下。如果你只想让某个技能在这个项目里生效，把技能目录复制进去就行。用户级和项目级可以同时存在，Claude Code 会合并加载，项目级技能具有更高的优先级。举个例子，团队规范要求必须在提交前跑某个检查，那你就可以把对应的技能放到项目级目录里，强制所有参与这个项目的人遵守。

4.3 验证安装是否成功

装完最怕的就是看似装好了，实际没生效。我的验证方法很简单：先在终端看一眼技能目录，确认里面确实有对应的技能文件夹，每个文件夹下都有一个SKILL.md文件。

ls ~/.claude/skills

如果列表里空空的，那大概率是安装脚本没跑完或者路径不对。目录没问题的话，再打开一个 Claude Code 会话，随便提一个跟某个技能匹配的任务，比如让它帮我梳理一下这个模块的重构思路。如果它能在回答里主动展开计划、提到"我将按照重构流程来执行"之类的表达，说明技能已经进入它的视野了。要是任务和技能都匹配上了，Claude 却完全没反应，则要回到技能文件的 description 字段上找原因。

4.4 如何在会话中主动引入技能

技能系统的一个特点是自动匹配，但这不代表你只能被动等 Claude 自己发现技能。实际上，你完全可以在对话里明确指出让它使用某个技能。例如你可以直接说："请用 systematic-debugging 技能来排查这个问题。"这么做的效果是强制锁定协议，不依赖语义匹配的运气。尤其当任务描述模糊、Claude 在多个技能之间犹豫的时候，点名比听天由命靠谱得多。

另外，如果你自己有固定的工作习惯，想把这些习惯也固化成技能，完全可以手动创建。格式不复杂，在技能目录下新建一个文件夹，里面放一个SKILL.md，文件顶部用 YAML frontmatter 写明name和description，正文写协议步骤。下面是一个简化示例：

--- name: writing-plans description: 在开始写代码之前，为任务创建分步执行计划。适用于多文件改动、复杂功能开发等场景。 --- # 写计划协议 1. 收集任务需求与约束条件。 2. 拆解为可独立验证的步骤。 3. 标注每个步骤的输入、动作与验收标准。 4. 将计划写入文件，并询问用户确认。

技能文件写好后，Claude Code 下一次启动就能扫到。这算是 Superpowers 给我带来的另一个隐性价值——它让我理解了 Claude Code 技能机制本身，从而可以自己定义适合团队或者个人项目的技能。你会发现，一旦掌握了 SKILL.md 的写法，你就不再只是使用别人做好的技能，而是能造自己的技能。

5. 实际使用体验：技能生效的典型场景

装了 Superpowers 几个月，我有几个印象很深的典型场景，写出来你就知道这套东西在实际项目里是怎么发挥作用的。

第一个场景是新功能开发。以前我让 Claude 写一个复杂功能，它经常直接给出完整代码，代码是正确的，但完全没有设计痕迹。引入 Writing Plans 技能之后，对话流程变成了：我先描述需求，Claude 先梳理约束，再产出计划文件，然后询问是否开始执行。我在计划里能直接看到它对任务的理解和拆解方式，有不对的地方先在计划阶段修正，而不是等写完代码再返工。这个体验非常接近跟一个靠谱工程师协作，而不是跟一个代码生成器对话。

第二个场景是修 bug。之前遇到问题，我习惯性把报错一贴，Claude 随口给一个答案。有了 Systematic Debugging 技能后，它会先复现，再让我提供更多上下文，然后一步步缩小可能原因。有一次线上有个偶发问题，Claude 没有尝试一次给出一堆猜测，而是先让我把一个可疑条件的日志加上，再跑一遍，就这一步就把问题锁定在了并发时机上。那个排查过程让我真正意识到，技能不只是约束行为，它还在教 Claude 一种思考方法。

第三个场景是代码审查。以前让 Claude 看一段代码，它总是客客气气地说"整体不错，建议考虑一下边界情况"，输出偏含糊。启用 Code Review 技能后，它的审查方式变成了带着检查清单逐项过：输入校验、异常捕获、状态变更、测试覆盖、兼容性影响。每个问题都标了严重级别，并给出对应的修改建议。这才是我需要的代码审查。现在每次想找人 review 代码，我基本都先让 Claude 过一遍，自己再人工复核关键逻辑，效率高很多。

第四个场景是重构老代码。Refactoring 技能让我最舒服的一点是它真的能做到小步快跑。它不会一口气改几十个文件，而是先把阶段性的改动列出来，改一个验证一个。中间测试挂了，它会主动停下，分析是重构引入的问题还是原本就存在的，然后做精准回退。对比我以前让它"顺手把这段逻辑重构一下"之后提心吊胆等结果的经历，这套流程可以说是天壤之别。

6. 踩坑记录：安装与使用中的七个常见问题

再好的工具，实操起来总会碰到意外。下面这些问题是我自己或者身边朋友在安装、使用 Superpowers 过程中真实踩过的，整理成了速查表，方便你遇到同样问题时能直接对症下药。

这里面我想重点强调两个点。第一是 description 字段的措辞。我发现很多人自建技能时，description 写得太抽象，比如"这个技能用于提升代码质量"，这种描述 Claude 根本没法判断什么时候该调用。正确做法是把触发场景写具体，比如"当用户要求实现一个新函数、并且该函数需要经过测试验证时使用"。第二是会话缓存。Claude Code 在会话启动时读取技能，如果你在会话中途改了技能文件，它读取到的很可能还是旧版本。改完技能记得重开会话再做测试，否则你会误以为自己的修改没生效。

除了表格里的问题，还有一个我特别想提醒的坑：不要一次把技能装太全。技能目录里的技能越多，Claude 匹配时被干扰的概率越大，尤其是一些职责相近的技能，可能同时被激活，最后输出里混着两套协议的影子。我的做法是按需安装，平时只保留规划、TDD、调试、重构、审查这几个主力技能，策展式的维护比贪多求全要靠谱得多。技能这个东西不是装得越多越强，而是匹配得越准越好用。

7. 个人体会：一个月使用下来的一些真实感受

最后说点只有长期用才会知道的东西。Superpowers 表面上是给 Claude Code 装了一堆技能，实际上它改变的是你和一个 AI 编程助手之间的协作方式。以前我的角色更像个质检员，等 Claude 交代码然后我再去检查；现在我的角色变成了评审员，在计划和步骤阶段就介入。协作节奏提前了，返工自然就少了。这种转变带来的效率提升不是某一次写了多少行代码，而是整个工作流的稳定性上来了。

我也遇到过技能过度约束的情况。某些简单任务被技能协议搞得很重，比如让我随手改一行配置也要先写计划，那就有点教条了。后来我的处理方法是：简单任务直接对话搞定，复杂任务才启用重技能。工具是为人服务的，别被工具带节奏。这个度需要你在实际使用中慢慢把握，每个项目的特点不一样，同样的技能在不同团队里的适用性也不一样。

如果你也想试，我建议从两个技能入手：Writing Plans 和 TDD。先让 Claude 学会先计划再动手，再让它在写代码前写测试，这两个习惯养成了，其余技能完全可以按需再加。最后再推荐一个小技巧：不要把 Superpowers 当成固定安装包，装完就不管了。有空的时候打开SKILL.md文件看看它内部是怎么组织协议的，参考它的写法去定制你自己的技能，才是这套框架真正值钱的地方。毕竟，技能的本质是把你相信的工作方法写下来，让 AI 照着执行，而每个人值得相信的方法，终究是不同的。