企业官网建设流程全解析

最近AI编程圈子里，superpowers这个名字出现的频率相当高。如果你在用Claude Code、Cline这类带“技能系统”的AI编码助手，大概率刷到过它：一套开箱即用的工程技能包，目标是把“AI很勤快但总在错误方向上跑得飞快”这个问题按下去。很多朋友在问，它到底有哪些skills、怎么安装、怎么引入到自己项目里。这篇就结合我自己折腾的实操经验，把这套东西从设计思路到配置步骤、再到实际使用中的坑，一次讲清楚。不管你是刚接触AI编程工具的新手，还是已经用它写了不少代码、想升级工作流的老手，这篇都能给你一条可以直接照着做的路径。

1. superpowers是什么，为什么它能解决AI编程的核心痛点

1.1 一个很尴尬的现状：AI太“手快”，但想得太少

用过AI编码助手的人都体会过这种场面：你在终端里敲了一个任务描述，它立刻开始读文件、改代码、创建新文件，五分钟内给你产出一大坨“看起来能用”的东西。你满怀期待地跑测试，结果直接报错，或者更糟，逻辑和你的需求完全两码事。问题不在于AI不勤快，恰恰相反，它太勤快了——你刚说个大概，它已经冲出去写了三百行代码，方向却跑偏了。

这就像你请了个特别积极的实习生，你还在讲需求背景，他已经把方案写完了，结果和你心里想的那套完全不一样。你说“重做”，他还委屈：我明明很努力。现实中优秀的工程师不会这么干，他一定会先追问几句：你这个需求的边界是什么？用户到底是谁？有没有历史包袱？后续会不会扩展？想清楚这些再动手，写代码反而只占最后一小部分时间。

传统AI编码助手恰恰缺的就是这种“先想清楚再动手”的工程纪律。它不是不会写代码，而是缺少一套强制性的流程约束。superpowers就是冲着这个痛点来的。

1.2 superpowers的解法：给AI注入一套结构化工程流程

superpowers是一个开源项目，作者是长年在开源社区活跃的Jesse Vincent（GitHub上叫obra）。它做的事情从表面上看非常简单：通过一个CLAUDE.md文件加一堆SKILL.md文件，把一套完整的工程工作流“教”给Claude Code这类AI编码助手。

核心哲学可以概括成六个字：先思考，再动手。具体展开就是：接到需求先进入头脑风暴环节，把问题问清楚；然后写实施计划，拆解任务步骤；计划确认后再进入执行阶段，并且强制执行测试驱动开发；遇到问题走专门的调试流程，而不是让AI自己瞎试。

它不是传统意义上的“插件”，不会注入什么运行时，也不会包一层API。它的本质是一批精心编写的Markdown指令文件。AI编码助手本身就有“技能”机制：把写好的SKILL.md放到特定目录，模型在遇到相关任务时就会读取这些指令并按照里面的流程行事。superpowers相当于把“技能的写法”发挥到了极致，做了一套完整的、有方法论支撑的技能集合。

1.3 目录结构：CLAUDE.md加skills，每个文件都有明确职责

我第一次克隆这个仓库的时候，第一反应是：就这？一个CLAUDE.md，一个skills目录，没了。但仔细看完每个文件，才明白这套设计的分量。

superpowers/ ├── CLAUDE.md └── skills/ ├── brainstorming/ │ ├── SKILL.md │ └── templates/ ├── planning/ │ ├── SKILL.md │ └── ... ├── executing/ ├── debugging/ ├── test-driven-development/ └── ...

CLAUDE.md相当于给AI的“员工手册”，它不教你“怎么写if-else”，而是定义了一整套工作流：接到任务后第一步做什么、第二步做什么、在什么情况下必须停下来问用户、什么时候才能进入写代码阶段。它是整个流程的总纲。

skills目录下的每个子目录是一个技能，每个技能的核心是SKILL.md。这个文件通常以YAML格式的frontmatter开头，里面有这个技能的名字和触发描述；正文部分才是真正的“干活指南”。当Claude Code收到一个任务时，它会扫描这些技能描述，判断哪个技能和当前任务匹配，然后按照对应的SKILL.md来执行。说白了，CLAUDE.md定流程，SKILL.md定具体动作，两者配合才能跑起来。

2. 有哪些核心skills，每个技能管什么

2.1 先看总览：六类核心技能

superpowers仓库里不同版本列出的技能可能略有差异，但核心的六类基本不变。我用一张表先让你有个整体印象，后面再逐个展开。

2.2 流程类：brainstorming、planning、executing

这三个技能是一条完整主链。brainstorming是我个人觉得最值的一个技能。它的作用不是天马行空地“发散创意”，而是反过来：通过一连串提问，把模糊的需求收敛成明确的边界。比如我让它写一个博客标签统计脚本，它不会直接写代码，而是先问：统计维度是什么？按标签统计还是按文章数排序？输出格式要JSON还是Markdown？要不要考虑历史文章的迁移？这些问题看着琐碎，但答完之后，任务的方向已经很清晰了。

planning技能在需求收敛后介入。它会把大任务拆成一张清晰的实施清单，每一条都有明确的依赖关系和验收标准。并且它会特别关注风险点，比如“这里需要读写文件，谁来负责测试数据准备”这类容易被忽略的事情。planning输出的结果以计划文件形式保存，执行阶段可以随时对照，避免AI写着写着就跑到计划外去了。

executing技能反而是我印象中最“克制”的一个。它的SKILL.md强调：只按计划执行，不擅自扩大改动范围，每完成一步就向用户汇报。这在团队协作时尤其重要，AI一旦被允许自由发挥，改动范围就会像滚雪球一样膨胀，executing的存在就是为了给AI套上缰绳。

2.3 工程实践类：TDD、debugging、subagent-driven-development

test-driven-development技能是superpowers里执行力最强的一个。它不会温和地建议你“最好写测试”，而是直接给出流程：先写一个会失败的测试，跑一遍确认它在失败，然后写最小实现让测试通过，最后重构。这个方法单个来看并不新鲜，但关键是它被写成了AI的行动准则，不再依赖用户手动提醒。实测下来，AI在这个技能引导下写的代码，质量确实更稳，因为每次改动都有测试用例在背后兜底。

debugging技能解决的是“测试红了怎么办”的恐慌问题。传统的AI遇到bug会开始瞎猜：换个参数试一下、把某个模块重写一遍、甚至完全推翻重来。debugging技能要求它冷静下来，先读报错信息，再复现问题，通过二分定位可疑代码，最后才动手修。整个流程走一遍，修bug的成功率高得多，而且不会引入新的“灵机一动”式改动。

subagent-driven-development是这套技能里比较进阶的东西。它利用了Claude Code的subagent机制，让AI在处理大任务时派多个子代理并行干活，每个子代理独立完成一块，最后汇总验证。比如让它重构一个项目的测试框架，它会派一个子代理去梳理现有测试用例，另一个子代理去调研兼容性问题，自己在主线程汇总方案。这套机制用得好，大任务的完成速度和可靠性都会明显提升。

2.4 看懂一个SKILL.md内部长什么样

想看透superpowers的秘密，最好找一个SKILL.md直接读。以最简单的brainstorming为例，它的结构大致是这样：

--- name: brainstorming description: 当用户提出一个模糊的想法、需要探索不同方向时使用。如果需求已经明确，请改用planning技能。 --- # Brainstorming 技能 ## 你的目标 通过结构化提问帮助用户澄清需求，输出一份明确的需求说明。 ## 工作流程 1. 先简要复述你对需求的理解，不超过三句话。 2. 逐条提出澄清问题，每次最多三个，避免让用户感到负担。 3. 根据回答刷新理解，直到你可以在五分钟内说清这个需求要解决什么问题。 4. 输出一份需求文档草案，包含目标、非目标、成功标准。 ## 注意事项 - 不要在brainstorming阶段提出具体技术方案。 - 如果用户明确表示想直接写代码，立即结束并进入planning阶段。

看到没有，它不是一句抽象的“好好思考”，而是把思考拆成了可检查的动作序列。AI能直接照做。这就是superpowers这套技能包的精髓：把方法论转换成机器能读懂的行为指令。

3. 5分钟完成安装：从拉取仓库到引入技能

3.1 安装前需要准备什么

安装本身不复杂，但先确认两件事。第一，你的Claude Code版本要能支持skills机制，建议保持最新版，这个功能迭代得很快，旧版本可能路径都不对。第二，想清楚你到底要装到用户全局还是单个项目里。

全局安装就是把技能复制到用户级别的配置目录（通常是~/.claude/），所有项目都能用。项目级安装则是放到项目的.claude/目录下面，只有当前项目生效。我的建议是：第一次体验先全局装，用顺手了再决定要不要在特定项目里做定制。全局装的好处是任何时候新开一个项目，这套流程都在，不用重复折腾。

3.2 具体安装步骤

整个安装过程按下面的命令顺序来就行：

# 1. 克隆仓库到本地 git clone https://github.com/obra/superpowers.git # 2. 进入仓库目录，看看文件结构 cd superpowers ls -la # 3. 把skills目录复制到用户级skills目录 mkdir -p ~/.claude/skills cp -R skills/* ~/.claude/skills/ # 4. 把CLAUDE.md合并到用户级CLAUDE.md # 如果文件不存在，直接复制 if [ -f ~/.claude/CLAUDE.md ]; then cat CLAUDE.md >> ~/.claude/CLAUDE.md else cp CLAUDE.md ~/.claude/CLAUDE.md fi

注意第三步的cp -R skills/*是把所有技能文件夹复制过去，每个技能文件夹必须保持独立目录结构，不能把它们打散了。复制完成后，可以顺手确认一下目录长这样：

ls ~/.claude/skills/ # 你应该能看到 brainstorming、planning、executing 等目录

如果你只想在某个项目内使用，把上面命令里的~/.claude替换成你项目的.claude即可。注意项目级目录如果不存在，记得先mkdir -p .claude/skills。

做完这些，重启你的Claude Code会话，让配置重新加载。在Claude Code里执行/skills命令（如果你的版本支持），应该能看到系统列出了刚装进去的这些技能，说明安装成功了。

3.3 安装后怎么快速验证

安装完成别急着开干。我建议用一个最简单的、肯定不会出错的任务测一下技能有没有真正被加载。

你可以在对话里输入：“我想做一个命令行小工具，用来统计当前目录下所有Python文件的行数，但我还没想清楚具体要什么，我们聊聊思路。”

正常情况下，Claude不会直接撸起袖子写代码，而是会先进入brainstorming的状态，反问你几个问题：统计的是物理行还是非空行？要不要排除注释？输出格式要表格还是纯文本？要不要递归子目录？此时说明技能已经被正确触发了。如果它直接开始写代码，那就是技能没生效，继续看后面的排查部分。

4. 实操一把：让技能包带你跑一个完整开发流程

4.1 我实际跑的一个练手任务

为了写这篇分享，我没有纸上谈兵，专门把一个旧项目翻出来重新过了一遍。任务是给一个纯静态博客写一个“文章阅读量统计”的生成脚本。需求本身很简单：解析某个目录下的Markdown文件，提取每篇文章的标题、日期和假阅读量，然后生成一张排名表。传统模式下，直接把需求丢给AI，它大概率十分钟就能给我一个能跑的脚本，但我决定全程开着superpowers的流程走一遍。

第一轮对话中，Claude读了我的需求后没有直接写代码，而是进入了brainstorming状态。它先复述了一下它对我的需求理解，然后问了我两个问题：阅读量是存在文章frontmatter里还是从外部JSON文件读取？排名表需要输出成Markdown还是HTML？我当时其实没想过第二个问题，凭直觉选了“Markdown格式”，并且补充了“阅读量存在frontmatter里”。这个信息后来证明至关重要，直接决定了脚本的数据来源设计。

4.2 计划阶段：拆到能直接动手的粒度

几个来回之后，Claude表示需求已经清晰，建议进入planning阶段。它生成了一份计划文件，拆成了四步：

• 第一步：写一个函数，解析指定目录下的所有Markdown文件，读取frontmatter中的title和reading_count字段；
• 第二步：写一个排序逻辑，按阅读量降序排列；
• 第三步：写一个生成器函数，把排序结果渲染成Markdown表格；
• 第四步：把脚本接入命令行入口，支持指定目录参数。

每一条步骤都带着验收标准，比如第一步的验收标准是“函数返回一个列表，每个元素包含title、date、reading_count三个键”。这份计划的粒度恰到好处——不是细到没法执行，也不是粗到无从下手。此时我确认了计划，它才进入执行阶段。

有意思的是，执行阶段它没有像以前那样一次性把所有代码写完然后交差，而是严格按照计划一步一步来。先写好文件解析函数，再跑一个简单的单元测试，确认通过了，才继续下一步。这种“步步有验证”的节奏，和我平时自己写代码的方式已经很接近了。

4.3 TDD到底带来了什么改变

这个练手任务里最让我惊喜的部分，是test-driven-development技能起了作用。到了第二步排序逻辑，Claude没有直接写实现，而是先写了一个测试用例：构造三个阅读量分别为100、300、200的字典，断言排序后中间那本应该是200那篇。测试先跑了一次，结果是红的，它确认了失败信息，然后才动手写实现。等实现写完再跑，测试变绿。

这个看起来有点“绕”的过程，带来的实际收益非常明显。如果你允许AI直接写实现，它很容易凭经验写得“差不多能用”，但边界情况全是坑。现在它先在测试里把你对函数行为的预期固定下来，实现只要保证测试通过就行。对于我这个博客统计脚本来说，排序逻辑本来就不算复杂，测试案例也不多，但这种“这次改动有没有破坏已有行为”的安全感，是直接用传统模式完全感受不到的。后来我故意把排序需求从“降序”改成“按月份分组再降序”，AI能很快通过新增测试来完成重构，而不是把原有逻辑推倒重来。

4.4 整条流程走完后的感受

整套流程跑完，最直观的感受是：过程变慢了，但返工变少了。用传统对话模式，AI十分钟给脚本，但接下来可能是一小时调错。superpowers模式下，前期的问答和计划占了二十分钟，后面写代码反而很快，而且几乎没出什么幺蛾子。特别值得注意的是，planning阶段已经提前标注了一个风险点：“Markdown文件变动而frontmatter缺失时，脚本应给出警告而非崩溃。”如果没有这一步，这个边界情况大概率要到线上脚本真实跑的时候才会暴露。

还有一个体会是：这套流程不是死的，可以灵活调整。如果只是一个很小的改动，比如改某个函数的签名，完全可以跳过完整的brainstorming流程，直接进入执行阶段。superpowers的CLAUDE.md里本身就留了这种灵活性：根据任务大小和不确定程度，决定走到哪个阶段为止。对于大需求走全流程，对于小改动走简化流程，这才是它设计的初衷。

5. 常见问题与排查技巧实录

5.1 技能没生效怎么办

这是我被问得最多的问题，也是我自己踩过的坑。装完之后发现Claude还是老样子，你让它写代码它立刻写。排查顺序按下面这个方向来：

先看路径。~/.claude/skills/目录下每个技能必须是一个独立文件夹，里面直接放SKILL.md。如果复制时多包了一层目录，变成~/.claude/skills/技能名/SKILL.md/那就错了，该是文件的地方变成了文件夹，系统根本识别不了。我有一次就是因为复制时路径多加了一层，折腾了半天。

再看frontmatter。SKILL.md开头的---之间必须有name和description，这是技能被发现的关键。如果描述写得像“这是个技能”，模型根本不知道它在什么场景下该用这个技能。描述要具体，包含触发条件，比如“当用户需求模糊、需要反复澄清时使用”。这也解释了为什么superpowers里每个技能的description都写得那么长，不是废话，而是为了触发准确。

最后考虑重启。Claude Code在会话启动时才扫描技能目录，如果你装完技能没有重启当前会话，自然看不到变化。执行/skills命令可以直接确认哪个技能被加载了。

5.2 和已有CLAUDE.md配置冲突怎么处理

很多人不是第一次用Claude Code，自己已经写了一份CLAUDE.md，里面可能有“永远用Python写代码”这类偏好。这时把superpowers的CLAUDE.md直接append进去，就可能出现指令打架的情况。比如你自己的配置说“立即开始实现”，而superpowers的流程说“先澄清需求”，AI会迷茫。

我的处理办法是：保留自己的偏好，但把superpowers的流程性指令放在更靠前的部分。因为Claude Code读取指令时，前面的内容对行为的影响偏大。或者更省事一点，在CLAUDE.md开头加一句话：“除非用户明确说‘快速处理’，否则一律先走superpowers的完整流程。”这样两套配置就各安其位了。另外注意项目级CLAUDE.md优先于用户级，如果你在某个项目里只想关掉superpowers，右键退出技能目录即可。

5.3 几个提升实际效果的小技巧

第一个技巧是“显式提及技能名”。虽然superpowers已经尽量按照描述做自动匹配，但在对话里直接说“请按brainstorming流程帮我梳理这个需求”，命中的概率和准确度都会大幅提升。命令系统本身是模糊的，显式点名相当于给了导航，AI会立刻定位到对应技能。

第二个技巧是“自己改造技能”。superpowers的价值不只在开箱即用，更在于它展示了SKILL.md的正确写法。我后来照着它的格式给自己写了一个“代码审查”技能，放在~/.claude/skills/code-review/下，正文列了五条审查要点：是否可读、边界case、测试覆盖、是否有性能隐患、是否符合项目风格。效果出乎意料地好，它真的会在触发代码审查时逐条对照。看懂这套格式之后，你就解锁了无限可能。

第三个技巧是“不要贪多”。技能多了，模型每次扫描description的负担会变大，而且有可能在多个技能之间犹豫不决。我一开始把网上各种别人分享的技能打包全装了，结果AI在一个简单任务上反而犹豫了十分钟，不知道怎么选择。后来清掉一批明显不符合我开发习惯的技能，只留下刚好覆盖我工作流的那些，效率马上回来了。技能这东西，贵精不贵多。

最后再说个小事。如果你和我一样经常改代码，强烈建议装完之后花半小时通读一遍superpowers仓库里的CLAUDE.md，别只是复制粘贴了事。看一遍之后，你会彻底明白AI为什么会在某些时刻停下来问你问题，也会更懂这套技能包的设计意图。用顺了之后，你甚至可以把它当成一个“方法论工具箱”，把里面的思路迁移到自己写的技能里。到那时候你会发现，superpowers真正给你的不是某个技能，而是一套“怎么思考”的框架。这大概就是它能火起来的原因。