企业官网建设流程全解析

最近我在实际项目里深度用了一阵子superpowers，它不是普通的命令行工具，而是一套给 Claude Code 配的"技能扩展框架"。简单说，它解决了一个特别现实的问题：默认的 AI 编程助手像一个知识面很广但没什么章法的实习生，你让它改代码它能改，但让它按规范做代码审查、写测试、排查问题，它每次都发挥不稳定。superpowers 的想法就是把这类高频操作固化成一个个结构化的skills（技能包），让 AI 按成熟的套路执行——这就是我理解中"超能力"的来源。

如果你已经在用 Claude Code 做日常开发，或者正在琢磨怎么把团队里的编码规范、测试流程、调试思路沉淀成可复用的东西，这篇文章应该对你有用。我会从设计思路、安装引入、可用技能、实践操作到避坑记录，完整拆一遍我自己的使用过程。

1. 拆开看 superpowers：它不是插件，是一套技能加载体系

1.1 一句话说清楚它的本质

很多人第一次看到 superpowers 会以为它是一个独立的编码工具或者一个大型插件，实际不是。它的核心是一个"技能目录 + 加载机制"：项目里维护了一批 Markdown 格式的技能文件，每个文件描述一个标准工作流，Claude Code 在运行时读取这些文件，按里面定义的步骤和规范去执行任务。

这意味着你拿到手的不是一堆写死的功能，而是一套可以被阅读理解、被修改、被新增的"操作手册"。每个技能文件就是一份给 AI 看的 SOP，写清楚"当用户要求做某件事时，你应该按哪几步走、先看什么文件、输出什么格式、注意什么边界条件"。Claude Code 加载后，就像给实习生发了一叠标准作业指导书，干活质量自然稳定得多。

我把它理解成：普通的 Prompt 是给 AI 临时交代一件事，skill 是给 AI 配一份长期有效的岗位职责说明。后者显然更适合工程化地管理 AI 协作。

1.2 为什么要单独搞一层"技能层"

我先从实际对比说起。假设你直接让 Claude Code 做一次代码审查，它通常会立刻给出意见，但不会主动去查你项目的编码规范、不会先系统性地列出改动文件清单、不会按优先级组织问题列表，更可能的是凭经验泛泛而谈。

而有了技能层之后，同一个需求会变成另一番场景：AI 先读取技能文件中的审查流程，按顺序做信息收集、静态检查、测试情况核对、风险分级，最后产出一份结构化的审查报告。整个过程的差异就在于"是否有确定性流程"——技能层就是把这层确定性补上了。

还有一层更重要的价值：经验沉淀和复用。团队里最有经验的人是怎么定位 bug、怎么设计测试、怎么写提交信息的？这些原本只存在于个人脑子里，现在可以写成技能文件，让所有用 Claude Code 的人都享受到同样的水平。这比任何团队文档都更有执行性，因为 AI 会真的按它去干活。

1.3 与普通 Prompt 模板、插件方案的区别

有朋友问过我，这和把一堆 Prompt 模板存下来有什么区别？区别在于技能不只是"一段话"，它包含明确的执行步骤、判断条件、输入输出格式，甚至可以在步骤中要求 AI 调用工具、读取特定文件、生成中间产物。它是"可执行的工作流"，不是"可复制的提示词"。

和传统插件方案比，superpowers 又轻得多。插件往往需要写代码、处理 API、维护构建链路，而技能文件就是纯 Markdown，改起来就是改文档。一个会写文档的人就能维护技能库，这种低门槛非常重要，也是项目能社区化传播的关键。

2. 安装与引入：把超能力挂到你的 Claude Code 上

2.1 前置环境准备

动手之前先把基础环境确认好。我当前实测的配置是：Node.js 18+，Claude Code CLI 能正常启动并登录。你可以在终端先跑一下：

claude --version node --version

只要两个命令都有正常输出版本号，环境就算过关。如果 Claude Code 还没安装，先装好并完成登录再往下走。这里不展开 CLI 的安装过程，因为官方文档已经写得很清楚了，而且版本迭代快，照抄旧教程反而容易踩坑。

有个小提醒：尽量在干净目录里先做一次基础对话，确认 Claude Code 的 API 连通、网络请求正常，再引入 superpowers，这样后续排查时容易隔离问题。

2.2 获取 superpowers 项目并确认结构

把项目克隆到本地，我习惯放到用户目录下的.claude文件夹里统一管理：

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

克隆完成后，用ls看一下目录内容，你通常会看到这些关键部分：

• skills/：核心技能目录，里面的每个.md文件就是一个技能
• SKILLS.md/README.md：技能总索引和使用说明
• 配置文件或脚本：负责把技能目录注册给 Claude Code 使用

这里值得多看一眼skills/目录里的任意一个 Markdown 文件，你会发现它的结构非常有讲究：开头有技能的name和description元信息，description 里会写清楚"什么场景下该用这个技能"，这部分直接影响 AI 什么时候主动想起用它。正文则是步骤化的指令，比如"第一步收集需求上下文，第二步生成文件清单，第三步逐项审查并输出报告"。

为什么要先看文件结构？因为技能是文本，不是不可读的二进制，你完全可以自己审一遍里面写了什么，避免给 AI 引入你无法控制的指令。这也是它和普通插件的本质区别之一——安全性通过透明度来实现。

2.3 在 Claude Code 中挂载技能目录

挂载方式根据你的 Claude Code 版本不同略有区别。我常用的是配置文件方式：编辑 Claude Code 的配置文件（一般在~/.claude/settings.json），在插件或技能加载区域添加上面的路径。大致结构类似：

{ "plugins": { "add": ["~/.claude/superpowers"] } }

如果你在 Claude Code 交互界面里操作，也可以直接用/plugin命令，按提示输入本地目录路径来添加。具体字段名以你当前版本的交互提示为准，我第一次用旧版本时字段叫plugins，升级后变成了更细分的技能注册区，照抄老配置反而没生效。

挂载完成后，一定要重启 Claude Code 会话，因为技能的扫描加载发生在会话启动阶段。不重启的话，即使配置写对了，当前会话里也用不上新技能。

2.4 验证安装是否成功

重启后，你可以直接在对话里问一句：

你现在有哪些可用技能？请列出技能名称和用途。

正常的回答会列出 superpowers 里定义的一批技能，并且每个技能带一句话说明。如果它回答"我没有额外技能"或者答非所问，先别急着怀疑配置，按下面顺序排查：配置文件路径是否写对、目录是否真实存在、技能文件是否有语法错误、是不是忘了重启会话。

实际用下来还有一个小技巧：不要一上来就在复杂项目里验证，先新建一个临时目录，放几个测试文件，让 AI 调一个技能跑一下，确认链路通了再上真实项目。这样既快又不会污染重要代码库。

3. 核心技能拆解：装完你能拿到哪些能力

3.1 代码产出类技能：从"改得对"到"改得规范"

代码产出类技能是日常用得最多的。比如在上一个改动完成后，让 AI 按技能流程做一次"变更审查"，它不会像默认模式那样直接给几条评论，而是会先收集这次改动的文件清单和 diff，再按规范逐项检查命名、函数边界、异常处理、依赖引用，最后输出一份分优先级的审查意见。

另一个常见场景是"按计划实施重构"。你只需要告诉它"把模块 A 的重构按这个思路做"，技能会先自己梳理依赖关系、生成实施步骤、再逐步执行，每一步做完还会对照原始目标检查是否跑偏。这种多步执行能力，在没有技能的情况下很容易走着走着就忘了最初约束。

这里我想特别说一个细节：哪些"常识"其实不该假设。默认模式的 AI 很容易想当然地认为你已经有个测试框架、认为某个工具函数是存在，技能里通常会在开始步骤强制要求 AI "先读取项目结构和现有代码，确认假设成立再动手"。这个约束看起来简单，但实际能避免大量凭空发挥。

3.2 质量保障类技能：测试和审查不再是走过场

质量类技能是 superpowers 里让我最惊喜的部分。以测试生成为例，普通的"帮我写测试"往往会生成一堆 happy path、覆盖率看起来很高但价值不大。而技能化的测试生成流程会先做这几步：

1. 读取被测模块源码，梳理输入输出和异常分支
2. 找出边界条件和隐式依赖
3. 按"正常路径 + 边界条件 + 错误输入"三层结构生成用例
4. 在生成后主动检查测试是否有断言、是否有重复用例

我试过用同一段有问题的函数对比默认模式和技能模式：默认模式生成的测试全部通过，但没测出函数里的空数组越界问题；技能模式在第二步就发现边界输入没有覆盖，主动补了用例，结果真的触发报错。这就是流程约束带来的实际价值。

审查类技能还支持"只审查不出手"的模式——它只输出问题清单和修改建议，不实际改动代码。这个模式在团队协作里特别好用，因为它把 AI 定位成了认真的代码评审人，而不是越权乱改的协作者，避免了 AI 顺手改了一堆你不希望它改的地方。

3.3 调试排障类技能：把"猜"变成"查"

调试类的技能在定位疑难问题时作用最明显。一个好的排障技能不是让 AI 直接给答案，而是强制它走一套排查链路：

• 先复现问题，收集报错信息和运行环境
• 定位问题边界：是输入数据问题、逻辑问题、还是外部依赖问题
• 按可能性排序，先验证最可能、成本最低的假设
• 输出结论时说明验证过程和证据，而不是只给猜测

有一次我遇到一个偶现的并发写入问题，直接把日志甩给默认模式，它给了我五六个可能原因，每个都说得像真的。后来按技能流程走，第一步让 AI 告诉我需要补哪些日志、怎么稳定复现，我照做后拿到准确的出错堆栈，第二步它通过分析调用链锁定了共享变量没有加锁，问题当场就清楚了。

这类技能本质上是把"经验丰富的工程师排查问题时脑子里走过的路径"显性化了。如果你团队里有特别擅长排障的人，让他把思路写成技能文件，价值会非常大。

3.4 协作与文档类技能：让 AI 也讲武德

最后一个值得说的类别是协作规范类。比如写完代码后让 AI 按规范生成提交信息，它会先分析 diff 的变更范围，再参考你项目里的 commit 风格，最后输出符合规范的信息，而不是每次都在feat:和fix:之间瞎猜。

文档维护技能也很实用。项目 README 过期、接口文档缺参数说明，这类工作默认模式需要你反复喂上下文，而技能化之后 AI 会自动对比代码实现和文档内容，列出不一致的地方，甚至直接产出更新建议。它的工作流程是先摸清代码结构，再定位文档描述，最后对照分析，输出修改方案。

这类技能看起来没有"技术含量"，但反而是团队里最容易复用、最容易见效的。因为文档和规范本来就是文本活，AI 在文本处理上最擅长，缺的只是"按规范执行"的约束，技能正好补上这一环。

4. 具体使用：从普通对话到技能驱动的工作流

4.1 自然语言触发技能的正确姿势

技能并不是靠什么神秘命令触发的，它走的是"意图匹配"：AI 读到你请求中的关键词，对照技能文件里的description描述，觉得匹配就会加载对应技能。所以触发技能的关键在于你需要把请求说得足够清晰。

比如你想启动代码审查技能，最直接的说法是："使用代码审查技能审查我刚才的改动。" 而不是模棱两可地问"你看下我的代码有没有问题"——后者 AI 可能不会联想到特定技能，因为它不确定你只是要闲聊式评价还是要按规范审查。

我自己的经验是，给 AI 的请求尽量包含三要素：技能名 + 对象 + 输出预期。例如："用测试生成技能给utils/date.ts补全单元测试，覆盖正常和异常输入，输出用例清单。" 这样匹配准确率会高很多。

4.2 观察和验证技能是否真的被加载

怎么知道技能有没有被触发？最简单的办法是看 AI 的回复风格。如果它开始精确地说出"按照 xx 技能的流程，第一步我会先……"这种结构化表述，说明它确实加载了技能。如果回答还是那种泛泛而谈的风格，大概率没匹配上。

这里有个常见误区：有些人以为输入了技能名就算触发了。其实不是。我曾经遇到过 AI 明确说出技能名，但后续行为完全没按技能步骤走——它只是复述了一个名字。后来我仔细看技能文件才发现，是因为技能文件正文里的指令写得太笼统，AI 虽然识别了意图，但没有获得足够约束。所以如果你自己写技能，正文一定要细到"先做什么、再做什么、每步输出什么"。

4.3 让技能产出从"可用"到"可靠"

技能启动后并不代表你可以撒手不管。初期使用我强烈建议人机分工：AI 按技能流程产出中间结果，你来做最终判断。尤其是代码修改类的技能，执行完后最好让 AI 展示 diff，并且主动问一句"这个改动会影响哪些调用方"，而不是让它默默做完就结束。

另一个提升可靠性的习惯是让 AI 在过程里留痕。你可以在技能文件里要求它"每完成一步，用一句话总结这一步的结果"，这样它就算中途走偏，你也能在对话记录里看到是在哪一步偏的，方便回溯修复。

我还试过把人工检查点直接写进技能流程，例如"生成代码后，列出所有修改的文件并说明每处修改的原因"。这样一来，AI 每次执行都必须交一份可审计的报告，输出质量会有肉眼可见的提升。

4.4 自定义新技能：把团队经验装进 Markdown

到了进阶阶段，你大概率会想写自己的技能。其实门槛非常低，甚至比写一篇团队规范文档还简单，因为技能文件本身就是 Markdown。下面是我用过的模板：

--- name: my-review description: 当用户要求做某类专项审查时使用这个技能 --- # 流程 1. 先读取项目相关文件，列出本次审查的范围 2. 对照以下检查项逐项确认： - 是否有边界输入处理 - 是否有错误处理遗漏 - 是否有重复代码 3. 输出审查报告，包含问题清单、严重级别、修改建议

写完后把它放到skills/目录下，重启会话即可。自定义技能的关键不是格式，而是规则写得到底细不细。只写"请认真审查代码"等于没写，必须把检查项、输出格式、边界情况都写清楚，AI 才有章可循。

我的建议是：先从你踩过坑的场景写起。比如"处理日期的时候永远要考虑时区""对外接口的入参必须有校验"这类规则，写进技能后会让 AI 天然带上团队的经验，这就是最实在的效率提升。

5. 常见问题与避坑实录（FAQ）

5.1 技能没触发 / 匹配不上

现象：明确说了技能名，但 AI 没有按技能流程走，输出风格和平时没区别。

原因：大部分情况是技能文件里的description写得太宽泛或太狭窄。太宽泛让 AI 不知道该在什么场景加载它；太狭窄导致请求稍微换个说法就匹配不上。另外，当前会话没有加载新技能、多个技能描述互相覆盖也是常见原因。

处理：重启会话确认加载；然后在你的请求里把场景描述得更接近技能自身描述里用的措辞；如果是自定义技能，把 description 改成"当用户要求做 X 时使用，例如用户说……"的句式，AI 的匹配准确率会提高不少。

5.2 技能执行了一半就偏航

现象：技能开头还能按步骤走，到中后期开始自行发挥，步骤顺序乱了，或者漏掉关键检查项。

原因：技能文件正文太长，AI 在执行过程中受上下文影响，逐渐忘了最初的完整流程。尤其当对话历史里穿插了其他请求时，问题更容易暴露。

处理：把长技能拆成多个短技能，形成"主流程 + 子流程"的调用关系；或者在技能文件的关键节点加入"到这里停下来，确认用户输入再继续下一步"的强制检查点。我自己实践下来的原则是：单个技能文件尽量不超过 80 行，超过就拆。

5.3 升级 superpowers 后行为变化大

现象：更新到新版本后，原本稳定的技能行为发生改变，输出格式和原来不一样。

原因：技能文件被上游更新，流程、输出格式可能有调整。这其实是好事，但如果你在团队里长期依赖某些输出格式，就需要注意。

处理：用 Git 管理而不是直接下载压缩包，升级前先看git log和 diff，评估变化影响；关键技能可以 fork 一份到自己仓库固定版本再引入，避免上游漂移影响线上协作。

5.4 技能之间互相干扰

现象：调用技能 A 时，另一个技能 B 的流程也混了进来，AI 同时执行两套逻辑。

原因：技能文件之间描述重叠，或者共享了相近的触发关键词，导致 AI 同时加载多个技能。

处理：检查所有description，确保触发场景互斥；如果必须共享某些公共流程，可以把公共部分抽成一个"子技能"，在主技能里用"调用子技能 x"的方式引用，避免把公共流程复制粘贴到多个文件里。

最后再分享两个实用小技巧

第一，把技能文件和项目放在同一个仓库里管理。团队项目会变化，规范也会变，技能文件和代码一起走 PR 评审、版本迭代，比单独维护一份文档可靠得多。我目前的做法是在仓库里建一个.ai/skills/目录，把团队特有规范写进去，让 Claude Code 加载项目目录的技能，这样每个人 clone 完项目就能获得一致的 AI 协作方式。

第二，初期使用一定要多打断、多追问。技能不是魔法，它只是让 AI 更规范的工具。你自己仍然需要对代码负责。我现在每个技能生成的改动都会让 AI 列出 diff 和改动理由，然后我再大脑里过一遍"这个改动会不会破坏其他调用方"。人机各管一段，才是这套体系能长期跑下去的真正原因。

说到底，superpowers 给我最大的启发不是某一个技能多好用，而是它证明了"给 AI 立规矩"这件事可以脱离代码，用最朴素的文字完成。把靠谱工程师的思考路径写成 Markdown，AI 就能照着执行，这件事的门槛低到几乎任何人都能上手，但带来的稳定性提升却是实打实的。如果你也在用 Claude Code，强烈建议装一套试一试，然后从你最痛的一个场景入手写第一个自定义技能。