企业官网建设流程全解析

最近我在重新梳理 AI 编程工作流的时候，被一套叫 superpowers 的技能包给“按住”了。先说结论：它不是某个语言框架，也不是代码库，而是一整套给 Claude Code 这类编程 Agent 用的行为规范。简单说，就是把你手底下的 AI 从“拿到需求就急着撸代码”的急性子，调教成“先问清楚、再列计划、最后动手”的老练工程师。如果你已经受够了 AI 写代码速度快但方向经常跑偏，或者每次都要在对话里反复强调“先别写代码，先想清楚”，那这套技能包大概率能救你。这篇文章我打算把它的具体使用、有哪些 skills、怎么引入到自己的环境里，一次讲透。

1. 先搞清楚 superpowers 到底是什么，以及为什么它能改变 AI 写代码的节奏

1.1 它不是“代码库”，而是一套行为规范

我先用一个类比来解释。你招了个能力很强但经验不足的新人，最怕什么？怕他接到需求就闷头开干，干到一半发现理解错了，又推倒重来。你给他一本工作手册，手册里写清楚“接到需求后第一步做什么、第二步做什么、什么情况下要停下来问人”，他的产出质量就会稳定很多。

superpowers 干的就是这件事。它不是给你现成的函数库，而是把工作流程写成了一个个“技能文件”。这些文件遵循目前各家 AI 编程工具都在推的 Agent Skills 规范，核心就是一个 SKILL.md 的 Markdown 文件，里面用自然语言写清楚触发条件、执行步骤、注意事项。当你在对话里输入特定命令，Agent 就会去读取对应的技能文件，然后按照里面的流程来行动。

我最早是在 Claude Code 的环境里跑起来的，后来发现 VS Code 的几个 AI 插件也能兼容。它的核心思路很简单：把“头脑风暴、写计划、按计划实现、系统化调试”这套人类工程师的工作方法，翻译成 Agent 能严格执行的流程指令。这么做的价值在于，AI 的推理能力已经够强了，缺的恰恰是稳定的“工作习惯”，而 superpowers 就是用来补这个短板的。

1.2 安装前你需要先确认自己的环境

在动手安装之前，建议先花两分钟确认三件事。第一，你用的 AI 编程工具是否支持 Agent Skills 规范。目前我实测下来，Claude Code 原生支持，VS Code 里几个主流 AI 插件也能通过读取本地技能目录来支持，但具体加载方式略有差异。第二，你的机器上要有 Git 和基本的命令行环境，因为安装本质上是把 GitHub 上的技能仓库拉到你本地。第三，最好先想清楚你是给“全局所有项目”用，还是只给“某一个项目”用，这会影响你装到什么目录。

这里有个容易踩的坑：很多人以为装完就万事大吉，结果发现对话里输入技能名没反应。大概率是因为工具没有扫描到你的技能目录，或者技能文件的路径不对。所以装完之后，第一件事就是确认技能列表里能看到对应的技能，别等到用的时候才发现压根没加载。

1.3 两种主流安装方式：图形界面装和命令行装

如果你用的是 VS Code，最省事的办法是直接在扩展市场里搜 superpowers。装好后，插件市场会有相应的技能目录，AI 插件会自动扫描到。这种方式的好处是可视化管理，适合不习惯敲命令的人。

如果你跟我一样习惯命令行，可以直接用 Git 把仓库克隆到你当前项目的.claude/skills目录里，或者放到用户级目录~/.claude/skills下，这样所有项目都能用。命令大概是：

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

装完之后，在对话里输入/skills或者直接问“你现在有哪些技能”，就能看到加载结果。如果没看到，优先检查目录名和 SKILL.md 文件是否存在，技能加载通常是靠扫描这个文件来识别的。

2. 核心 skills 逐个拆开看：每个技能到底是干嘛的

2.1 brainstorming：让 AI 先当“需求分析师”再当程序员

这个技能是我用得最多的，也是 superpowers 整套体系里最值得先掌握的一个。它的作用是在动手写代码之前，强制 AI 进入“需求澄清”模式。你给一个很模糊的想法，它不会马上说“好的，我来实现”，而是会像产品经理一样反问：你的核心用户是谁？最想解决的痛点是什么？有没有什么约束条件？

我用一个实际场景说明。有一次我让它帮我做一个“博客后台的标签管理功能”，如果我不启用 brainstorming，它可能直接就给你生成一堆增删改查的代码，界面样式、交互逻辑全靠猜，做完以后往往跟预期差很远。但启用 brainstorming 之后，它会先跟我来回确认：标签需不需要支持层级？标签关联文章后，文章页要不要展示？删除标签时，文章里已关联的标签怎么处理？这些问题问完，需求本身就被打磨得很清晰了，后面写代码反而快。

这个技能们背后的逻辑是：AI 写代码的“速度”其实不是瓶颈，真正浪费时间的是“返工”。一次需求没对齐，可能就是一两个小时白干。预先把需求边界划清楚，看起来多花了 10 分钟，实际上省了后面的几个小时。

2.2 writing-plans：把需求变成带验收标准的施工图

需求聊清楚之后，下一步就是写计划。writing-plans 这个技能会把前面的讨论结果整理成一份结构化的实施计划文档。它跟那种随便列几条 TODO 的计划完全不一样，里面会包括：整体目标、分阶段的任务拆解、每个任务的实现思路、依赖关系、以及最关键的“验收标准”。

我打个比方，brainstorming 产出的是一张“图纸”，writing-plans 就是把图纸翻译成“施工方案”：先打地基、再砌墙、最后装门窗，每一步都有明确的完成定义。有了这份文档，你后续让 Agent 写代码的时候，它就不是“凭感觉发挥”，而是严格按方案推进，做完一个阶段，对照验收标准自查一遍，再进入下一阶段。

这个技能最妙的地方在于，它生成的不只是给 Agent 看的信息，也是给你看的。你可以在计划文档里直接改，比如“我其实不需要用户注册功能，把这块去掉”，或者“数据库表结构要先设计好”。也就是说，在代码还没开始写之前，你已经通过调整计划把很多隐患排掉了。

2.3 implementing：按图施工，而不是自由发挥

从名字也能看出来，这个技能是负责“真正动手写代码”的。但它跟直接让 AI 写代码的区别在于，它会严格参照前面生成的计划文档，一步一步来。每完成一个步骤，它会停下来做检查：这个模块的代码是否符合计划里定义的验收标准？有没有引入不必要的改动？如果发现偏离，它会主动调整。

我自己用下来，implementing 解决的最大的痛点是“AI 随手乱改”。以前让 AI 干活，它经常顺手帮你重构一个不相关的函数，或者改了某个公共组件的样式也没告诉你。但有了计划约束之后，它的行动范围被锁死了，只改计划内涉及的文件，不做无关操作。这一点对于维护老项目的人来说，简直是救命稻草。

还有一个我很喜欢的细节：这个技能会让 AI 在完成关键节点之后，把改动内容、影响范围说清楚，方便你做 review。它不会一股脑把全部改动交给你，而是像同事一样“汇报进度”，你在每个节点都有机会喊停。

2.4 还有哪些值得留意的技能

除了上面三个核心技能，它里面还带了一些偏应用场景的工具型技能，我挑几个我觉得实用的列一下：

以 debugging 为例，它和普通排查的区别很明显。普通情况下，你让 AI 看个报错，它经常猜一个原因就直接给修复方案。而 debugging 技能会要求它先想办法复现问题，再提出几个可能的假设，然后通过加日志或者二分定位去验证，最后才动代码。这个过程看着好像“慢”，实际上能避免修一个 bug 引出三个新 bug。

3. 实际操作记录：从“有个想法”到“代码落地”的完整流程

3.1 先跑一遍 brainstorming，把模糊需求逼出边界

我拿一个真实的例子来走一遍完整流程。当时的需求是给一个内容管理后台加“定时发布”功能。听起来很简单对吧？但如果直接写，问题非常多：定时任务放哪一端实现？后端是用消息队列还是简单地轮询数据库？到了发布时间文章状态怎么流转？前端要展示什么？如果发布失败怎么处理？

我先输入了/brainstorming，然后把需求背景喂给 Agent。它开始逐条问我这些边界问题，并整理成“需求澄清文档”。这一步我很建议你全程参与回答，别偷懒。因为它问出来的问题，往往就是你自己没想清楚的地方。比如它问我：“定时发布的时间精度要求是多少？如果用户希望精确到秒，技术方案会复杂很多，如果只到分钟级别，实现方式会简单得多。”这类问题如果不是被它问住，我根本不会意识到还需要在这两个方案里做取舍。

3.2 拿到需求文档后，用 writing-plans 拆解任务

需求确认完，我接着输入/writing-plans。它会基于刚才的讨论，生成一份完整计划。我用简化结构展示一下计划大概长什么样：

## 目标 实现文章定时发布功能 ## 阶段一：数据模型 - Article 表增加 scheduled_at 字段 - 增加发布状态字段 status：draft / scheduled / published / failed ## 阶段二：调度逻辑 - 使用每分钟执行一次的定时任务，扫描 scheduled_at 到期的文章 - 发布失败时记录错误信息，状态置为 failed ## 阶段三：管理界面 - 列表页展示定时发布日期 - 编辑页支持设置定时发布 - 字段校验：定时时间必须晚于当前时间 ## 验收标准 - 到达发布时间后，文章状态自动变为 published - 发布时间未到前，文章不会出现在前端文章列表

这份计划里最值钱的是“验收标准”这一段。因为在没有它的时候，AI 实现完，你还需要自己想“怎么算做对了”，现在标准提前定好了，它写完代码之后会自己对照检查，你再做测试也会轻松很多。

3.3 进入 implementing，按阶段验收推进

计划确认之后，我输入/implementing，告诉它就按这份计划来。它没有像以前那样一口气创建一大堆文件，而是按照阶段一、阶段二、阶段三的顺序推进。每完成一个阶段，它会停下来总结：改动涉及哪些文件、是否满足验收标准、有没有测试建议。

这里有个小技巧我建议你记住：在对话里明确跟它说“请按计划里的阶段顺序执行，每个阶段完成后等待我确认再继续”。这样你就能卡住每一关，防止它在你没看结果的情况下继续往错方向走。我实测下来，这样虽然会多几次交互，但整体时间反而更短，因为每一步的偏差都在最小范围内被纠正了。

3.4 我在这个流程里调整过的几个小细节

用了几轮之后，我摸索出几个适合自己的使用习惯。首先是“顺序别打乱”，brainstorming 完直接写计划，计划完再实现，中间不要跳步。有一回我图省事，跳过 writing-plans 直接用 implementing，结果它拿着 brainstorming 的需求文档就开干，导致实现到一半发现还有几个边界问题没明确，只能回头补，反而更慢。

其次是在计划文档里把“不做什么”也写清楚。比如上面那个定时发布功能，我就加了一句“本阶段不做失败重试机制，失败仅记录日志”。别小看这一步，AI 经常会有“顺手做好事”的冲动，你明确画一个功能边界，它就不会越界扩展。

最后是及时清理旧的技能文件。如果你升级了 superpowers 版本，记得删掉旧目录再拉最新的，不然 Agent 读到的指令版本混杂，行为会变得不可预测。这个我踩过，新旧两版技能定义不一致，导致 AI 的响应风格一会变，排查了挺久才发现是缓存了旧文件。

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

4.1 安装了但技能没有出现在技能列表里

这个是最常见的问题。我遇到过的情况主要有三种：技能文件放错了目录、目录名不符合扫描规则、或者工具开了缓存没有重新加载。我的排查思路是这样的：先确认你选的安装方式是全局还是项目级，然后看目录结构是否在模型能扫描到的路径下，最后检查 SKILL.md 文件是否真的存在。如果用的是 VS Code 插件，试试重新加载窗口，很多次问题就出在它没有刷新技能目录。

顺便提一句，如果你是把技能放在用户级目录，改完之后最好先确认一下系统是否真的读取的是这个目录。我自己有次就是因为工具读的是另一个位置的旧配置文件，导致我改了技能目录根本没生效。

4.2 技能被触发后，AI 还是“我行我素”

这个问题比较隐蔽，表现为：你明明输入了/writing-plans，但它仍然直接开始写代码，或者边写计划边动手。我分析下来，最常见的原因是对话上下文里已经堆积了太多“历史任务”，它把这些历史指令当成了当前任务的一部分。另外，如果你在私人设置文件里写了比较强势的自定义指令，也可能覆盖技能里的流程约束。

我能给的解决办法有两个。一是尽量在干净的对话里触发技能，别让它承载太多无关上下文。二是把技能文件里的核心约束写得再直白一点，比如在步骤里加上“在任何代码生成之前，必须先输出完整计划文档并等待用户确认”。技能的加载本质上就是读 Markdown，你完全可以按自己的需求改它的文案，让它更贴合你的工作习惯。

4.3 担心技能包与自己的提示词冲突

这个顾虑很正常。因为很多人之前已经写了自己的系统提示词，怕加载 superpowers 之后两套逻辑互相打架。我的经验是：技能的优先级通常高于默认提示词，但低于你在对话里临时给的指令。所以如果你发现提示词和技能打架了，优先想想哪个对你的项目更重要。如果要让技能强制执行，就把提示词里冲突的部分改掉；如果你只是想要它偶尔遵守，那就靠每次对话里的临时指令来叠加。

我个人的建议是让技能成为主导，自己写的提示词负责补充“背景信息”和“项目规范”，而不是重复规定流程。比如我在提示词里会写清楚项目的技术栈、命名规范、测试要求，但“先计划再实现”这种流程控制全权交给技能来处理。这样两者各司其职，冲突基本就消失了。

4.4 遇到“计划不断调整但代码没跟上”时怎么处理

如果你发现计划文档改了又改，但 Agent 生成的代码始终是旧逻辑，大概率是它没有重新读取计划文件。这种情况下，我会把计划里的对应章节重新复制到对话里，直接粘贴给它，然后要求它“以这个版本为准，忽略之前的计划”。实测下来，显式粘贴的效果比让它自己去找文件要好得多。

还有一个容易忽略的点：当计划文档里出现“删除、重命名”这类破坏性操作时，Agent 往往倾向于保守执行，甚至绕开。这时候需要在对话里明确授权，比如“请严格按照计划重命名这个函数，并同步更新所有调用点”。不然它可能会给你留一堆兼容旧名字的代码，看着像实现了，其实埋了雷。

最后分享一个我总结的问题速查表，你可以直接对照排查：

这套东西我实际用了两三周下来，最大的感受是：它并没有让 AI 变得更“聪明”，但确实让 AI 变得更“靠谱”。原来需要我反复盯着的那些细小流程控制，现在都下沉到了技能文件里。你如果也想试试，建议从 brainstorming 和 writing-plans 这两个入手，先把需求澄清和计划环节跑顺，再逐步加载其他技能。别着急一次全上，等适应了这套工作节奏，你大概率会跟我一样，对“让 AI 边想边写”这个状态再也回不去了。