企业官网建设流程全解析

你有没有遇到过这种情况：跟Claude Code聊了近一个小时，技术方案、接口设计全都定了，第二天打开终端，它像失忆了一样把昨天的决定全忘了。我被这种“金鱼记忆”折磨了两个月，直到开始折腾superpowers。说白了，superpowers就是把Claude Code变成一个带着完整技能库的协作系统——它不再是一问一答的聊天框，而是一个会自己规划、自己拆任务、自己验收的“老工程师”。这篇文章我从安装讲起，把具体怎么使用、内置有哪些skills、怎么引入这些技能，以及最关键的“怎么写自己的skills”都过一遍，适合所有被Claude的健忘和无组织搞到崩溃的人。

1. superpowers是什么：一套让Claude自主管理技能库的插件体系

1.1 为什么需要技能系统而不是堆提示词

很多人给Claude Code“调教”的方式，是在CLAUDE.md里写一大段规则：“每次都要先问需求”“不要急着写代码”“写完必须自测”。这么做不是没用，但有三个硬伤。

第一，上下文窗口是有限的。规则写多了，模型真正用来思考的注意力被稀释了，规则之间还可能互相打架。第二，提示词本质上是“要求它做什么”，而不是“告诉它怎么做”。同一句规则，在不同场景下的执行质量波动很大。第三，提示词是一次性的，每次开新会话，这些“调教成果”能不能稳定生效，全看运气。

superpowers换了个思路：把一次完整的工作方法封装成独立技能模块。“头脑风暴”是一个技能，“写实施计划”是一个技能，“按TDD流程实现”是一个技能。每个技能都有自己的SKILL.md文件，里面有明确的触发条件、执行步骤和产出物。Claude读到这些技能，就像拿到一本带详细批注的工作手册，而不只是收到一张写着“你要靠谱”的纸条。

我习惯打一个比方：提示词是给新人的一张纸条，上面写“你要细心一点”；superpowers的技能，是给新人一套标准作业程序，每步干什么、卡住了怎么排查、做完怎么验收，都写得清清楚楚。纸条靠自觉，SOP靠流程，这是本质区别。

1.2 核心设计：SKILL.md、custom command与agent三件套

superpowers不是单个脚本，而是一套组合拳，拆开看是三块拼起来的。

第一块是SKILL.md。每个技能对应一个目录，目录里至少有一个SKILL.md文件。文件头部是YAML格式的元信息，正文是这个技能的具体操作指引。你可以把SKILL.md理解成技能的“说明书+操作手册”。以后你自己写技能，写的也是这种文件。

第二块是custom command，也就是斜杠命令，比如/plan、/brainstorm。它是人主动触发技能的入口，适合“我明确知道现在要进入哪个环节”的场景。你敲下/plan，Claude就进入规划模式，按规划技能的整套流程走。

第三块是agent，也就是子任务执行器。superpowers会创建一些专门的子任务执行器，负责写代码、负责走查、负责跑测试。它们可以在后台独立执行较长任务，主会话负责统筹调度。三者的关系我用一句话总结：custom command是点单，SKILL.md是菜谱，子任务执行器是后厨里照着菜谱做菜的厨师。你点完单，后厨按菜谱出菜，而不是临时现编。

2. 安装superpowers：插件市场、重启、授权三步走

2.1 先用插件市场装核心插件

安装本身不复杂，但很多人第一步就卡住了——不知道该在哪里输命令。superpowers的安装命令不是shell命令，要在Claude Code的交互界面里输入，命令以斜杠开头。

大致流程是这样：打开Claude Code会话，依次输入：

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

第一条命令把官方插件市场源加进来，第二条命令从源里安装superpowers插件。装完之后，最好执行一下/plugin update superpowers@superpowers-marketplace确认拉到的是最新版本，然后完全退出Claude Code，再重新启动。

装完看不到任何变化是正常的。插件本身只是一层壳，真正发挥作用的，是它随后带来的skills和custom commands。如果输入/plugin status能看到superpowers标记为enabled，就说明壳装好了，可以进入下一步。

2.2 首次启动：授权Claude自己管理技能库

重启之后，你会发现Claude的行为跟之前不太一样。它会主动跟你确认：检测到superpowers插件，希望把推荐的skills安装到~/.claude/skills目录下，同时会请求允许它自己管理技能文件。

这一步我建议直接同意。很多人的第一反应是“让AI自己改自己的技能文件，靠谱吗”，我一开始也犹豫过。但superpowers的核心设计恰恰就是“让Claude对自己的技能库拥有读写权”。它只有能自己增删改SKILL.md，才能在发现你重复某个工作流的时候，主动提议把流程固化成技能。如果你不给这个权限，插件就只剩一堆静态文档，价值大打折扣。

授权之后，它会根据当前项目和你的对话历史，推荐一组初始技能。比如你经常写Python，它可能会装代码评审、TDD一类的技能；你经常处理数据分析，它可能会装数据清洗相关的技能。这个推荐名单不是固定的，你随时可以增删。

2.3 版本与路径：两个容易翻车的细节

第一个细节是版本。superpowers迭代很快，对Claude Code的版本有隐性要求。装之前先用claude --version看一眼，太旧的版本容易出现“插件显示已安装但技能不生效”的诡异问题。遇到这种情况，不要急着翻配置文件，先执行/plugin update把两端都升到最新。

第二个细节是技能文件的存放路径。全局技能放在~/.claude/skills/，项目级技能放在项目根目录的.claude/skills/。两边同名技能冲突时，项目级优先。这一点务必记住，因为你给插件加的skills和项目里自定义的skills如果重名，行为会以项目级为准，排查问题的时候这条最容易被忽略。

3. 内置skills全景：从头脑风暴到调试的完整链路

3.1 启动链路：brainstorming和planning先让需求落地

superpowers内置的技能很多，但没有一个技能是“万能钥匙”，它更像一条流水线，每个环节有专门的技能。按我实际使用频率排序，最常用的是项目启动链路，也就是brainstorming和planning。

brainstorming，直译是头脑风暴，作用是帮你把模糊想法变成清晰需求。我实测下来的感受是：它比我自己逼问自己还有用。你给它一句话“我想做个静态博客”，它不会马上推荐框架，而是先抛出十几个问题，覆盖目标用户、内容形态、发布频率、是否需要搜索、部署环境偏好等等。这些问题会把你的隐性假设一个个逼出来，产出是一份需求摘要和一组待决策点。

然后是planning。需求清晰之后，planning把大任务拆成可执行步骤，输出一份plan文档。注意，这里不是简单列一个to-do list，而是会标注每步的输入输出、依赖关系、验收标准。我在实际使用中，通常把Claude产出的plan当成“合同”，动手写代码之前先跟它把plan对齐，后续执行基本就不用操心了。

3.2 执行与验收链路：implementing、TDD到reviewing

需求定了、计划有了，接下来就是implementing。这个技能会把plan里的步骤一个接一个落地。它跟普通对话写代码的差别在于：每完成一步，它都会回头对照plan里的验收标准，而不只是“代码能跑就行”。

如果项目对质量要求高，可以打开test-driven-development技能。它的流程是死的：先写一个会失败的测试，再写最小实现让测试通过，然后重构。这套流程人类程序员讲了二十年，真正坚持下来的团队不多，但让Claude执行起来反而干脆，因为它没有“嫌麻烦”的情绪。

代码写完不等于结束，reviewing技能负责走查。它会按内置的checklist逐项检查：有没有未处理的错误分支、日志打得到不到位、命名是否一致、有没有明显的性能隐患。我把它当第二双眼睛用，经常能抓到我漏掉的问题。

3.3 排查链路：debugging不靠猜，靠流程

日常开发里最耗时间的其实是排错，superpowers在debugging这个技能上花了不少心思。它的核心流程是：先收集现象、再复现、二分定位、修复、最后回归测试。看着平平无奇，但它强制Claude在动手改代码之前先回答三个问题：问题能稳定复现吗？最小复现路径是什么？这段代码最近的变更是什么？

举一个真实例子。有一次构建脚本在CI上偶发失败，本地怎么跑都是好的。Claude没有上来就猜是缓存问题，而是先让我把所有环境变量差异列出来，再逐步在本地模拟CI环境，最后定位到是一个未设置的环境变量导致某条命令走了不同分支。先复现、后定位、再修复，这个顺序省了我大半天。

4. 技能是怎么被调用的：读frontmatter、匹配场景、按步骤执行

4.1 读取驱动：SKILL.md的frontmatter是触发开关

要真正用好superpowers，必须理解它的调用机制。每次请求进来，Claude会扫描技能目录，读取每个SKILL.md头部那段YAML元信息。触发开关就是两个字段：description和when_to_use。前者说明这个技能是干什么的，后者说明什么场景下该用它。

很多人自己写技能之后反馈“Claude从来不主动调用”，十有八九是这两个字段写得不够精准。比如描述写“帮助用户更好地完成工作”，这种话等于没写，模型无法判断什么时候该用它。好的写法是“当用户要求创建新的React组件时”“当用户提到构建速度变慢时”。描述越像一条具体的检索条件，触发的准确率越高。

4.2 从场景匹配到按步骤执行，Claude经历了什么

为了让你直观理解，我把一次调用拆成四个环节。第一步，用户输入一段话；第二步，Claude在上下文里加载技能目录的索引，比对description和when_to_use；第三步，匹配到一两个技能后，它读取对应的SKILL.md正文，把正文里的步骤当成执行指令；第四步，按步骤执行，并把结果写回项目，通常是把中间产物存成文档，方便下一个技能接着用。

这也是为什么superpowers擅长处理长任务。brainstorming的产物是一份需求文档，planning读了这份文档才能写出计划；计划写完了，implementing照着计划执行。每一个技能都是上一环的消费者、下一环的生产者，环环相扣，信息不会丢。

4.3 让Claude自己装技能、卸技能，是这套体系最关键的设计

前面我提到授权Claude管理技能库，这里展开说。superpowers内置了一个叫Project_Management的元技能，它让Claude有能力创建、修改、删除SKILL.md文件。也就是说，当它发现你反复做某类事情，可能会主动问：“我注意到你每次发布前都要跑一遍这三个脚本，要不要我生成一个release-prep技能？”

这种“AI反过来优化自己的工作方法”的能力，实际体验相当微妙。我最早觉得它有点越权，后来发现真香——它提议生成的技能，往往比我自己写的更贴合我的操作习惯，因为它是在观察了我大量行为之后总结出来的。当然，你也可以手动删掉不想要的技能，每次操作都有确认环节，掌握权始终在你手里。

5. 手把手自定义一个skill：把反复做的工作流固化下来

5.1 最小可用的SKILL.md长什么样

自己写技能才是这套体系的完全体。先给一个最小示例。假设你希望Claude在提交代码时，统一按Conventional Commits规范生成提交信息，可以新建目录~/.claude/skills/conventional-commit/，在里面放一个SKILL.md：

--- name: conventional-commit description: 按Conventional Commits规范生成git提交信息 when_to_use: 当用户要求提交代码、生成commit message或执行git commit时 version: 1.0.0 --- # 生成规范化的提交信息 1. 运行 `git status` 和 `git diff --staged` 查看变更内容。 2. 根据变更类型选择前缀：新功能用feat，修复用fix，文档用docs，重构用refactor，测试用test，杂活用chore。 3. 特殊情况：破坏性变更必须在说明中标注BREAKING CHANGE。 4. 输出完整的提交信息，等用户确认后再执行 commit。

保存后重启Claude Code，这个技能就生效了。元信息的作用很清晰：name是唯一标识；description说明用途；when_to_use告诉Claude什么场景激活；version方便追踪修改历史。

5.2 三个字段写得好不好，直接决定技能是不是废技能

自定义技能时最忌讳的是把SKILL.md写成一篇小作文。我见过有人把正文写到两千字，结果Claude执行的时候上下文被占满，反而更容易跑偏。正文应该只保留关键步骤和判定规则，细节在步骤里按需展开。

再强调一遍description和when_to_use。我自己的经验法则：把when_to_use当成一个“搜索索引词”，想象用户可能会怎么触发这个技能，把高频说法都列上。比如上面的例子，“提交代码”“commit message”“git commit”都写了进去，覆盖不同表达方式。描述写得不好，技能就是躺在目录里的死文件。

5.3 从纯流程到可执行：三种进阶做法

纯文本流程是最简单的技能形态，但它只能约束Claude的行为，不能扩展它的能力。想做得更深入，有三种进阶方向。

第一种，在正文里引用外部脚本。比如技能正文写“先运行python scripts/analyze.py读取报告，再根据报告生成总结”，Claude会按步骤调用脚本，把脚本输出当成后续判断的依据。这是把本地工具链接入技能的最直接方式。

第二种，把技能设计成团队SOP的载体。我在团队里用过一个“评审前置检查”技能，里面列的是团队约定俗成的二十条检查项，Claude每次提交评审前自动过一遍。这种技能看似简单，价值在于让团队经验不随个人离开而流失。

第三种，结合子任务执行器实现半自动执行。superpowers支持把技能内容作为子任务执行器的指令，复杂技能交给它在后台跑，主会话继续处理别的事。这种玩法适合耗时较长的多步骤任务，比如全量回归检查。

6. 用了三个月的几点体会和常踩的坑

6.1 四个高频问题，对应四条解决路径

我把自己和身边朋友踩过的坑汇总成一张表，遇到同样情况可以直接对照处理。

还有一类问题容易被忽视：技能的正文指令与CLAUDE.md的全局规则冲突。比如全局规则要求“回答尽量简短”，而某个技能要求“输出完整分析报告”，Claude会陷入两难。遇到这种情况，我的建议是在技能正文开头加一行“本技能优先于全局通用规则”，把冲突明确化。

6.2 什么时候不该用superpowers

工具不是越多越好，superpowers也有明显不合适的场景。一是纯粹的一次性小任务，比如改个文案、查个接口文档，没必要触发一整套头脑风暴和规划流程，直接对话反而更快。二是模式还没稳定下来的探索期项目，过早把工作流固化成技能，后面需求一变，技能内容就得反复改，维护成本比收益还高。

我给自己定了一条判断标准：同一个操作，如果一周内重复超过三次，才值得固化成技能。低于这个频率，直接用普通对话处理，性价比更高。

6.3 把技能库当代码管理，才不会变成垃圾场

最后说说维护。superpowers用久了，技能库会越来越庞杂，尤其是你允许Claude自己创建技能之后。我现在的习惯是每周抽十分钟做一次整理：删掉不再用的，合并功能重叠的，给改动过的技能更新version。全局技能在~/.claude/skills，项目技能在项目根目录.claude/skills，都建议纳入git管理，哪天改坏了可以回滚。

如果要跟团队共享，把这些技能目录提交到仓库里，其他人clone下来就能获得一致的流程。这比我以前在群里发“大家注意，提交信息格式是xxx”有效得多——规则从人嘴里的叮嘱，变成了Claude每步都会执行的SOP。

我在实际使用中最深的一点体会是：superpowers的价值不在于某一个技能多惊艳，而在于它把“靠谱”变成了默认选项。以前我开新会话总要反复叮嘱Claude“先想清楚再动手”，现在装上superpowers，它会自动进入brainstorming和planning的流程，主动性完全不一样。最后分享一个小技巧：每次让Claude跑完一个复杂任务后，顺手问它一句“刚才这个过程，有什么值得固化成技能的吗”，它的建议往往比我自己的抽象总结更实用。这套东西不是银弹，但如果你也受够了AI的健忘和不可控，值得花一下午把它跑起来试试。