企业官网建设流程全解析

Claude Code 用熟了之后，你会发现一个挺尴尬的事实：模型很聪明，但它不太“靠谱”。让它写个简单函数没问题，可一旦任务复杂起来，它经常做着做着就忘了最初的约束，或者一头撞进死胡同死活不回头，更别提跨多个对话才能做完的活了。superpowers 这个技能库，就是专门治这个毛病的。它不是一个大模型，也不是一个 IDE 插件，而是一套给模型“装技能”的规则集合——用一批流程写好的 markdown 文件，告诉模型什么场景下该用什么方法干活。这篇文章我会把它的来龙去脉、安装方法、技能清单和实际使用姿势完整过一遍，适合刚开始接触 Claude Code、想让 AI 干活更稳的开发者。

1. 认识 superpowers：它到底解决什么问题

1.1 从“会聊天”到“会干活”

很多人第一次打开 Claude Code，都会惊叹于它的对话能力。但真让它完整实现一个功能、重构一个模块、或把一个需求从分析推到上线，问题就全冒出来了：它经常“高开低走”，开头思路很漂亮，干到一半逻辑就开始混乱；它还很“健忘”，聊了二十轮以后，早忘了第一轮定的技术方案。模型的上下文窗口再大也有限，它本质上还是“看完眼前这段话再决定下一句”，并没有稳定的长期记忆。

superpowers 的出现，就是把“干活”这件事流程化。它不改变模型本身，而是通过一批预先写好的技能文件，给模型提供一套能够按步骤执行的行为模板。比如面对一个新需求时，模型会自动进入“头脑风暴 → 方案收敛 → 制定计划 → 拆解任务 → 逐个执行 → 测试验证”这样的流程，而不是想到哪写到哪。这个变化是质变：同一个模型，装技能前像一个聪明但散漫的新人，装技能后像一个有章法的老手。

1.2 superpowers 的核心设计理念

superpowers 的设计哲学，用一句话概括就是“让模型学会自我管理”。具体体现在三个点上。

第一，技能文件化。每个技能都是一个 markdown 文件（通常叫 SKILL.md），里面写清楚这个技能是干什么的、什么情况触发、执行步骤是什么、有哪些注意事项。模型只要读到这个文件，就能按里面的流程走。

第二，触发自动化。模型在对话中根据你的描述自动判断该加载哪个技能，不需要你手动切换。你说“这个 Bug 不确定怎么复现”，它就倾向加载调试类技能；你说“功能方案还没定”，它就进入头脑风暴流程。

第三，状态持久化。这是它和很多零散技能库最大的区别。superpowers 会鼓励模型把当前工作状态、待办事项、已完成内容写入文件，这样哪怕对话中断，下次新开会话也能接着干。这就是“超级能力”的真正含义——它让模型跨越了上下文窗口的限制。

这套思路放到人身上很好理解：一个再聪明的程序员，接到需求也得先理解需求、再设计方案、拆任务、写代码、做测试。superpowers 就是把这些“职业素养”写成了模型能读的说明书。

2. 安装前的准备：前置环境与思路

2.1 需要准备哪些东西

在动手安装之前，先把前置环境理清楚。superpowers 不是独立软件，它依赖一个能读取技能文件的 AI 编程环境，目前最常见的就是 Claude Code。你需要准备的东西有：

• 一个能正常运行的 Claude Code 环境（一般通过 npm 安装，官方文档写得很详细，这里不展开）。
• 一个空项目目录，最好先建一个测试专用文件夹，别直接往正式项目里装。技能文件会出现在项目里，正式项目里混着一堆技能文件，后期清理起来很烦。
• 能访问 GitHub 的网络条件，因为 superpowers 的仓库在 GitHub 上，无论用插件方式还是手动克隆，都得先把代码拉下来。

2.2 两种安装方式的取舍

目前主流的安装方式有两种：一种是走 Claude Code 的插件机制，一条命令装完，全局生效；另一种是手动把 skills 目录复制到项目里，灵活可控。

插件方式适合“想快速体验、让所有项目都能用上”的人。手动方式适合“只想给某个项目加技能、或者想自己改一改技能内容”的人。我建议新手第一次用插件方式跑通全流程，之后再研究手动方式。因为插件方式帮你处理好了目录位置、路径引用这些细节，踩坑成本低很多。等你理解技能文件是怎么被加载的以后，再手动定制才有意义，否则一开始就被目录结构绕晕，很容易放弃。

3. 实操：把 superpowers 引入项目的完整过程

3.1 方式一：通过插件机制安装

以我手头的环境为例，在 Claude Code 的交互界面里，输入插件安装命令：

/plugin install obra/superpowers

命令执行后，Claude Code 会从 GitHub 拉取仓库，并把其中的技能注册到插件系统里。装完以后务必重启会话，让插件真正加载进上下文。这一步经常有人漏掉，结果装完发现模型没反应，就以为自己装错了。

注意：不同版本的 Claude Code，插件命令格式可能略有差异。如果/plugin不可用，先在交互界面输入/help，看看当前版本支持哪些命令，找到插件管理的准确写法，别硬套网上的旧教程。

3.2 方式二：手动拉取 skills 目录

如果你想清楚地看到技能装在哪、想改里面任何一个流程，手动方式更合适。先把仓库克隆下来：

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

仓库拉下来以后，里面会有一个专门放技能的目录。把这个目录里的技能，复制到你的项目技能目录下。Claude Code 默认的约定是技能放在项目根目录的.claude/skills/下，每个技能一个独立子目录，里面包含 SKILL.md：

mkdir -p /path/to/your-project/.claude/skills cp -r superpowers/skills/* /path/to/your-project/.claude/skills/

执行完以后，你的项目里应该出现类似.claude/skills/brainstorming/SKILL.md、.claude/skills/debugging/SKILL.md这样的文件结构。Claude Code 在读取项目配置时，会扫描这个目录并发现这些技能。

3.3 验证技能是否生效

装完别急着干活，先验证一下。打开一个新的 Claude Code 会话，直接在输入框里问：

你会哪些技能？如果遇到复杂需求，你打算怎么处理？

如果安装成功，模型会提到它看到项目里配置了若干技能文件，并且能说出类似“我手头有 brainstorming、debugging 等技能可以调用”这样的话。想更直接一点，可以输入一个典型的触发场景：

我需要做一个新功能，但方案还不清楚，先帮我梳理一下思路。

如果模型开始用结构化方式引导你补充背景、列出候选方案、收敛结论，而不是直接甩一个实现代码，那说明头脑风暴类技能已经被加载并生效了。这个验证步骤非常关键，能帮你区分“装好了”和“没装好”，避免后面所有操作都建立在错误前提上。

4. 技能清单：superpowers 里有哪些 skills

4.1 规划类技能

规划类技能是整个技能库的地基，负责解决“动手之前想清楚”的问题。

brainstorming（头脑风暴）是需求模糊时最先触发的技能。它会让模型先收集背景信息，再提出多个候选方案，最后和你一起收敛到一个主方案。这个技能能有效治住模型“第一个方案就开干”的冲动。我遇到很多需求其实自己也没想明白，这个技能逼着我把约束条件说清楚，反而省了后面大量返工。

planning / writing-plans（计划制定）在方案定了之后登场。模型会按照固定结构输出计划，包括目标、约束、步骤、验收标准。计划不是写给你看热闹的，它是后面任务拆解的依据。你可以在对话里直接要求“把这份计划写成文件”，它会生成一个可复用的文档，后续执行阶段随时对照。

cognitive-remodeling 这个技能比较特殊，简单说是让模型“调整自己的思考方式”。如果模型发现自己钻进死胡同，或者你反馈它思路不对，它会读这个技能，重新组织认知框架，换个角度再试。它不是具体干活用的，更像是模型的自救工具。

4.2 执行类技能

执行类技能负责“动手干活”环节，是把计划变成代码的关键。

todo 拆解与任务管理是执行阶段的核心。模型会把大任务拆成一个一个小的待办项，维护一份待办清单文件，每完成一项就更新一次。这个机制最大的好处是跨会话续接——哪怕对话中断，下次新开会话，模型读一下清单就知道干到哪了。我强烈建议所有超过半小时的任务都强制要求模型开这个清单，治“断线失忆”特别有效。

test-driven-development（测试驱动开发）是写代码前先写测试。模型按照“红-绿-重构”的循环推进，先让测试失败，再写实现让测试通过，最后优化代码结构。如果你受够了模型“产出一大堆没测试的代码”，这个技能值得第一个体验。它会让模型的产出质量明显上一个台阶，但代价是速度变慢、更啰嗦。

debugging（调试）在程序报错时接管。模型不再直接瞎猜，而是按“复现问题 → 缩小范围 → 定位根因 → 修复 → 回归验证”的流程走，每一步都有明确的输出要求。过去我遇到报错，经常让模型连续猜好几轮，浪费不少 token；用这个技能以后，它第一步会先让我提供复现步骤和完整报错上下文，后续猜测少了很多。

4.3 元技能：教模型怎么用技能

最让我觉得有意思的是元技能。库里有一类技能不是直接干活的，而是“教模型怎么用其它技能”。

using-skills 这个技能会告诉模型技能的加载机制、触发条件和使用礼仪，相当于一份用户手册。新装完技能后，让模型先读一遍这个，它对接下来的技能调用会更规范。我第一次装完直接干活，模型确实会读技能，但很多细节执行得不到位，比如该写状态文件的时候不写；后来先花两分钟让它过一遍使用规则，表现立刻不一样了。

技能间的编排能力也很关键。库里还有一些技能负责在多个技能之间做编排，比如先触发 brainstorming 收敛方案，再自动转交 planning 生成计划，接着进入 todo 拆解执行。这种流水线式的衔接，比每次手动指定技能自然得多，也更能还原一个资深开发者真实的工作节奏。

5. 具体使用姿势：日常工作里怎么调用这些技能

5.1 触发机制：模型怎么知道该用哪个技能

很多人误以为用了 superpowers 就要手动输入技能名，其实不用。正常使用中，你不需要记技能名，只需要正常提需求。模型拿到你的输入后，会先判断这个需求对应哪个技能的使用场景，然后自动加载并执行。比如你说“报表数据生成完了但邮件一直发不出去”，它会倾向加载 debugging 技能，而不是直接开始改邮件代码。

当然，如果你想强制指定，也可以在提问里点名。比如：

用 brainstorming 技能，帮我想想办法把首页加载速度提上去。

这种写法适合你明确知道该用哪个技能的场合。日常我更推荐让模型自己判断，因为技能库里本身就包含判断逻辑，比人手工指定更不容易出错。手动指定容易犯一个毛病：你以为是 A 技能，实际场景更适合 B 技能，强行指定反而把流程带偏。

5.2 一个完整实战示例

我拿一个真实场景演示整个链路。假设我要给项目加一个“每日报表自动发送”功能，需求很模糊，就一句话：

我想加个功能，每天自动把报表发到指定邮箱，具体怎么做你帮我规划。

模型合理表现应该是这样的。

第一步，加载 brainstorming 技能，先问我几个问题：报表数据从哪来？发送时间定在几点？收件人列表是固定的还是动态的？邮件是抄送还是附件？这个环节看起来“啰嗦”，但非常关键，能避免后面返工。如果模型不问直接给方案，多半会漏掉某个关键约束。

第二步，信息齐了以后，加载 planning 技能，输出一份计划，写明数据源、生成逻辑、邮件通道、定时任务、异常处理这几大块。你这时候应该能看到一份结构清晰的方案，而不是代码。

第三步，把计划拆成 todo 清单，写入文件。然后按顺序执行：写数据读取代码、写报表生成代码、写邮件发送代码、配置定时调度。

第四步，每完成一个 todo，更新一次清单，顺手跑一遍测试，真的把邮件发出去验证一次再收尾。

整个过程里，模型像一个有项目管理意识的程序员，而不是一个“你说一句它写一句”的对话框。这是 superpowers 最有价值的地方——把一锤子买卖的对话，变成了可持续推进的工程项目。

5.3 跨会话续接的正确打开方式

很多人没意识到 superpowers 真正厉害的地方还不在单次对话，而在多会话续接。比如今天做到一半下班了，明天想继续，你只需要新开一个会话，然后说：

继续昨天的工作，先看一下项目里的 TODO 清单和状态文件。

模型会去读待办清单、计划文档、状态记录，然后准确告诉你“代码已经写到哪、还差哪几项”，直接接着干。要做到这一点，前提是前面的会话里模型真的把状态写进了文件，而不是只存在对话里。我踩过坑以后，现在都会在任务开始前明确要求一句：“把进度记录到项目目录的文件里。”

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

6.1 问题速查表

实际操作中容易踩的问题，我整理成了一张速查表，方便你按图索骥。

6.2 我踩过的坑和一些心得

装完技能后，强烈建议先让模型跑一遍 using-skills 这个元技能。我第一次装完直接干活，模型确实会读技能，但很多操作细节执行不到位，比如该写状态文件的时候不写，该拆分步骤的时候偷懒合并。后来我先花了两分钟让它把技能使用规则过一遍，后面明显规范很多。这个步骤看起来多余，实际能省你后面大量纠错时间。

不要把整个技能库一股脑塞进一个用了很久的老项目。技能目录里文件多了以后，模型每次加载上下文都会变重，还容易在技能判断上犹豫不决。我的做法是新建一个干净的工作目录，只复制这次任务相关的三五个技能，用完即走。项目里只留当前需要的技能，模型判断起来果断很多。

还有一个容易忽略的点：待办清单和状态文件一定要让模型写进项目目录，而不是只存在对话里。有一次我没注意，让模型把进度记在会话里，结果对话一断，所有进度归零，第二次新开会话它完全不记得干到哪。从那以后我养成了习惯：凡是超过十分钟的活，坚决要求模型把状态落盘。

最后分享一个进阶技巧。如果你发现模型在某次任务里特别高效、流程走得特别顺，可以让它把这次的处理步骤总结成一个自定义技能文件，放进你的技能目录里。下次遇到类似任务，它就能复用这套流程。superpowers 本身就是这么长出来的——把一次好的实践固化成技能，再不断积累，你的模型会越用越顺手，最后变成真正属于你自己的“超级能力库”。