企业官网建设流程全解析

我一直觉得，AI 编程助手这两年最尴尬的地方不是“不会写代码”，而是“写得太快”。你问它一个需求，它刷刷刷给你整出一大段，语法没错、结构也对，但你仔细一看——全是套路代码，变量命名莫名其妙，边界条件一个没处理，测试更是想都别想。你让它改，它又刷地给你重写一遍，改了开头坏结尾。这种“看起来很能干、实际上要你返工”的状态，业内现在有个专门的说法叫slop，AI 垃圾产出。

最近我上手了一套叫superpowers的技能包，专门治这种病。它本质上是一组给 AI 编程助手用的“操作手册级”技能文件，通过一套强约束的工作流，让 AI 先规划、再动手、每步自检，而不是上来就放飞自我。目前它已经能直接安装在 codex CLI、workbuddy、trae work cn 这些主流工具上，GitHub 上热度和讨论度都很高。这篇文章就围绕我实际安装和使用的过程来写，从核心设计思路、安装步骤到踩坑记录，一次性讲清楚这套东西到底值不值得装。

先说结论：如果你受够了 AI 给你生成“四不像”的样板代码，或者你想让 AI 从“代码生成器”变成“能和你一起做事的协作者”，superpowers 值得花半小时折腾一下。它改变的不是模型能力，而是你调用模型的方式——让散兵游勇式的 AI 写作变成有组织、有纪律的工程流程。

1. 理解 superpowers：它不是插件，是一套“工作方法论”

在讲安装之前，我觉得有必要先搞明白一件事：superpowers 到底是什么。因为如果你只把它当成一个普通的插件或者工具包来装，装完之后大概率会觉得“就这？”，然后就搁置了。

1.1 AI 编程“快而烂”的根源在于缺少流程约束

我们平时用 AI 写代码，默认的模式是“你问我答”：你给一个 prompt，它回复一段代码。这种模式对简单功能没问题，但一旦需求稍微复杂一点，问题就暴露了。

首先是上下文碎片化。你让 AI 改 A 模块，它根本不记得 B 模块和 A 模块之间的耦合关系；你让它新增一个功能，它不知道你项目里已经有的工具函数、命名规范、错误处理风格。所以它生成出来的代码，单看好像还行，放回项目里就是一股“外来的味道”。

其次是缺乏规划。人类开发者接到一个复杂需求，会先拆解任务、梳清依赖、评估风险，然后才动手。AI 没有这个习惯，它会直接跳到写代码那一步，把所有逻辑在一大段回复里全部倒出来。结果就是代码冗长、结构混乱、注释还写得特别“AI”——满屏“这是一个用于计算总价的函数”这种毫无信息量的话。

superpowers 的核心思路，就是针对这两个痛点做了一套约束。它用 Markdown 文档定义了一个个“技能”，每个技能本质上是一套 AI 可以遵循的指令流程。比如其中一个核心技能叫deep-planning（深度规划），它强制 AI 在写代码之前，先和用户反复确认需求、拆解任务、输出一份详细的实施计划，等用户点了确认，才开始动手。

用大白话说，这就是给 AI 立规矩。你不再问它“给我写一个登录功能”，而是让它先花十分钟搞清楚你的用户体系、数据库结构、安全要求、已有代码风格，然后列一个三步五步的计划，你审核完了它再动手。这个体验上的差异，用过一次基本就回不去了。

1.2 “手把手的操作手册”比“灵光一现”更可靠

superpowers 这套技能包还有一个很特别的设计：它把“技能”做成了文件。每一个技能就是一个带有特定格式的 Markdown 文档，里面写了完整的触发条件、执行步骤、输出格式、质量要求。AI 在对话中读到这些文档，就像人拿到了一本 SOP（标准作业程序）手册，知道什么场景该走什么流程。

我举一个实际的例子。它的code-editing（代码编辑）技能里明确要求：AI 在修改代码前，必须先找出所有受影响的调用点，并且列出测试计划；修改完之后，要逐条对照需求给出变更清单，而不是一句“已完成修改”就糊弄过去。这个约束本身不涉及具体技术栈，但它在所有项目里都适用。

这也是为什么它能适配多个不同的 AI 工具——因为它不依赖某个特定工具的 API 或 UI，纯粹靠“喂给模型的文本指令”来工作。你可以在 codex CLI 里用，可以在 workbuddy 里用，也可以在 trae work cn 里用，原理一模一样。

1.3 核心收益：减少返工、提升代码质量、建立项目上下文

我实际用了两周，最大感受是返工率明显下降。以前让 AI 写一个接口，它直接丢过来一大段，我看完还要逐行改。现在它先问清楚参数校验规则、错误码规范、日志输出格式，然后给出计划，我再让它动手。写完的代码基本一次通过，偶尔有问题也是小修小补。

另一个隐形收益是项目上下文被真正带起来了。superpowers 里有一套约定，叫conventions（项目约定），你可以把项目的编码规范、目录结构、命名规则写进去，AI 在每次任务开始前会自动加载这些约定。也就是说，它对“你项目的规矩”是有记忆的，不会这次用 camelCase、下次用 snake_case。

所以，我理解 superpowers 的本质不是“更聪明的 AI”，而是一套“把 AI 当人看”的管理方法。它假设 AI 的能力是有边界的，但通过规范流程可以把边界内的能力发挥到最大。你不需要反复念咒一样地给 AI 补充背景信息，它会自己去读该读的文件，问该问的问题，做该做的计划。

2. 核心技能拆解：deep-planning、code-editing 和规范约定

如果说 superpowers 是一个工具箱，那这个工具箱里最常用、最核心的几件工具就是deep-planning、code-editing以及绑定的规范约定机制。我在实战里几乎每一次任务都会触发这三个技能，所以想单独拿出来拆开讲讲它们各自怎么工作，以及为什么它们能提升 AI 的产出质量。

2.1 deep-planning：先让 AI 学会“想清楚再动手”

我先讲讲 deep-planning。这是 superpowers 里我最喜欢，也是改动最明显的一个技能。以前我让 AI 干活，最怕它“听不懂人话还硬干”：你明明说先看一下 xxx 文件再改，它根本不看，直接按通用模板给你写一段。

deep-planning 的运作方式是什么？我简化描述一下它的执行流程：

1. AI 收到一个任务时，先不着急写代码，它会先向你提澄清问题。比如“这个功能需要兼容哪些浏览器？”“这个接口的鉴权方式是 token 还是 cookie？”“需要新增数据库字段吗，还是复用已有字段？”
2. 等关键信息确认后，它会输出一份分步骤的实施计划，包括每一步要改哪些文件、涉及哪些函数、需要哪些测试。
3. 计划里还会标注“依赖风险”，比如某个改动会影响其他模块，或者某项需求目前还不明确、需要进一步确认。
4. 计划得到你的确认后，它才会进入执行阶段。

听起来很简单对吧？但这套流程放在 AI 编程里，效果是革命性的。因为绝大多数 AI 代码翻车，都翻在“需求理解不准”上。你让 AI 改 A 逻辑，它顺手把 B 逻辑也改了；你想做分页查询，它默认给你按 ID 倒序排。这些问题的根子都在于 AI 没有形成“先对齐需求再编码”的习惯。

deep-planning 把这种习惯变成了强制的流程，AI 不遵守流程，就无法进入下一阶段。有一次我让它写一个数据导入功能，它按惯例先问了三个问题：导入的数据来源格式是 CSV 还是 Excel？重复数据是覆盖还是跳过？导入过程要不要支持断点续跑？我一看这三个问题就知道，这套流程是真的在帮我省时间，因为它问的全是我容易忽略的需求细节。

2.2 code-editing：改代码也有“纪律要求”

如果说 deep-planning 管的是“动手前”，那 code-editing 管的就是“动手时”和“动手后”。

这个技能设计了一套非常严格的代码修改纪律，核心有这么几条：

• 动手改代码之前，必须先定位所有可能受影响的调用点。也就是说，你不能只盯着自己要改的那一个函数看，必须全局搜索一下谁调用了它、依赖了它，把影响面先摸清楚。
• 修改完成后，要输出一份“变更清单”，逐一列出改了哪些文件、每个文件改了什么、为什么这么改。这有点像我们平时提 MR 时的描述，但 AI 会做得更细。
• 如果不是专门处理测试任务，改动后还必须补充或更新相关的测试。这不是可选项，是必选项，哪怕改动很小。

这套纪律解决了我一个很头疼的问题：AI 改代码像“打地鼠”。你让它修 bug，它修好了，但多了一个新 bug——原来它只盯着出错那一行，没看上下游。code-editing 强制它做影响面分析，这个“只看局部”的问题就被从流程层面规避掉了。

而且它输出的变更清单非常有用，等于帮你免费做了一轮代码审查。以前我让 AI 改一个方法，它洋洋洒洒改了一大堆，我还得自己 diff 一下看到底改了什么。现在它自己会列出来，我扫一眼就知道是不是有越权改动，审查效率高了一大截。

2.3 规范约定：把项目规矩写进技能里

最后是conventions（规范约定）。这个机制虽然不像前面两个那么“抢戏”，但它是整个 superpowers 体系能够跨项目复用的基础。

你可以把它理解成给 AI 写的一份“入乡随俗”手册。比如我手头有个后端项目，我就把这么几条写进项目约定的文件里：

• 项目使用 Python 3.11，代码风格遵循 Black 格式化规范。
• 所有新增接口必须遵循 RESTful 风格，并补充 OpenAPI 文档。
• 数据库操作使用 SQLAlchemy 2.x 的 ORM 方式，禁止写裸 SQL。
• 错误处理统一返回 { "code": xxx, "message": "xxx" } 结构。
• 日志使用 loguru，禁止使用 print 输出。

写完之后，AI 在这个项目里工作，每次动手前都会先去读这个约定文件。它生成的代码就会自动符合你项目的风格，不需要你每条都写在 prompt 里反复强调。这个机制在多个项目之间切换时尤其好用——每个项目有自己独立的一份约定，AI 会识别当前项目并自动加载对应的规范。

所以总结下来，deep-planning 管“想清楚再做”，code-editing 管“做的时候有章法”，conventions 管“做的结果符合项目习惯”。三个技能叠加起来，AI 的输出质量从一个“不稳定发挥的实习生”变成“遵守流程的资深工程师”，差的就是这套规范和流程的距离。

3. 实操记录：codex CLI、workbuddy、trae work cn 的安装与验证

讲完理念，该动手了。我前后分别在三个环境里装过 superpowers：codex CLI、workbuddy、trae work cn。如果你用的是其中某一个工具，可以直接跳到对应小节。三个环境里安装方式不完全一样，但核心逻辑是相通的。

3.1 准备阶段：检查环境与必备条件

安装前我建议你先确认三件事：

• 你的 AI 工具版本是否支持自定义技能加载。以 codex CLI 为例，需要比较新的版本才支持 skills 机制；workbuddy 也是一样，旧版本可能没有 marketplace 或 skill 目录选项。
• 本地是否安装了 Git。因为主流安装方式是从 GitHub 拉取超级技能仓库，没有 Git 就得手动下载压缩包，稍微麻烦一点。
• 你的模型需要支持比较长的上下文窗口。superpowers 的技能文件本身不长，但它会引导 AI 进行多轮规划和逐项实施，如果模型上下文窗口太小，很容易聊着聊着就“失忆”。我个人建议至少 128K 以上，再低的效果会打折扣。

准备好之后，下一步就是拉取 superpowers 的仓库到本地。在任意一个目录下执行：

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

这个仓库里就是全部的技能文件，里面会有 skills 目录，包含我们要用的 deep-planning、code-editing、conventions 等技能。接下来要做的，就是让各个工具能“看到”这个目录。

3.2 codex CLI 安装 superpowers 的完整流程

我自己日常主力就是 codex CLI，所以先讲它。codex CLI 加载技能的方式，是通过skills 目录来发现的。你需要把这个仓库里的 skills 目录，链接或复制到 codex 的全局技能目录下。

我的做法是进入 codex CLI 的配置目录，并在里面创建一个软链接：

# 进入 codex 配置目录 mkdir -p ~/.codex/skills ln -s /path/to/superpowers/skills/* ~/.codex/skills/

注意把/path/to/superpowers换成你实际克隆的路径。如果你用的是 Windows，可以用命令提示符的管理员模式执行mklink /D来做目录链接，或者直接把整个 skills 文件夹复制到对应目录，效果相同。

配置好之后，验证是否加载成功。在 codex CLI 里输入：

codex command list

或者直接起一个新会话，问一句“你现在可以使用哪些超级技能？”如果 AI 能列出 deep-planning、code-editing、conventions 等名称，就说明安装成功了。

另一个更精准的验证方式是直接让 AI 执行一个简单的规划任务，比如“帮我规划一下给某个函数增加缓存功能的步骤”。如果它能按 deep-planning 的流程先反问你几个需求问题，说明技能是真的加载生效了，而不只是“看到了文件”。

3.3 workbuddy 安装 skill superpowers 的注意事项

如果你用的是 workbuddy，安装流程稍微有点不同。workbuddy 对 skill 的支持是通过marketplace 或本地导入来做的，我更推荐用本地导入。

workbuddy 的安装界面上通常有一个“添加 skill”或“导入 skill”的入口，你直接选择克隆下来的 superpowers 仓库目录，它会自动识别里面的 skill 结构并导入。如果你的版本没有这个入口，也可以手动把它仓库里的 skills 目录，放到 workbuddy 的工作区自定义技能目录里，再重启一下工具就能识别。

我这个环境的实际操作中，唯一遇到的坑就是路径问题。workbuddy 有时候不认带~符号的路径，需要你用完整的绝对路径。比如：

C:\Users\你的用户名\.workbuddy\skills

或者 mac 上的/Users/你的用户名/.workbuddy/skills。放好之后重启 workbuddy，然后在对话里输入类似“/skills 列表”这样的命令，看能不能列出 superpowers 的技能。

这里我额外提一句：workbuddy 安装成功后，最好在项目的默认设定里写一行“开始每个任务前，请先加载 deep-planning 技能”，这样能强制每次对话都走规划流程，而不是偶尔被模型“跳步”。

3.4 trae work cn 安装与验证：一次走通的清单式记录

trae work cn 是很多国内开发者用得比较多的环境，它的技能加载机制和 codex 类似，也是通过目录识别。安装过程我总结成了一串清单，你照着走就行：

1. 克隆 superpowers 仓库：git clone https://github.com/obra/superpowers.git
2. 找到 trae work cn 的技能目录。一般在用户目录下的.trae/skills或者项目目录下的.trae/skills，具体以你本机实际路径为准。
3. 把仓库中的 skills 文件夹里的内容，复制或链接到上述目录。
4. 重启 trae work cn，确保主进程重新扫描技能目录。
5. 新建一个对话，输入“使用 deep-planning 技能来规划这个任务：给订单模块添加导出功能”。观察 AI 是否会先问澄清问题，而不是直接写代码。

我在这套流程里有一次卡了很久，原因是我把整个 superpowers 仓库直接复制到了 skills 目录，导致技能嵌套了一层子目录，trae work cn 扫不到。后来改成只复制仓库里skills这个子目录下的内容，就正常了。所以这里特别提醒一下：复制的是skills目录内的内容，而不是superpowers仓库本身。

三个环境我都装完之后，日常使用体验上没有感觉到明显差异，因为底层调用的是同一批技能文件，差异主要体现在入口和配置方式上。核心逻辑记住就行：让 AI 工具能找到技能目录，技能就生效。

4. 实战过程：我从需求到代码完整跑了一遍 superpowers

为了让你更直观地看到这套技能包是怎么工作的，我拿自己最近一个真实的小需求来做演示：给项目里的用户模块增加一个“批量导出 CSV”的功能。不用复杂的技术栈，重点看流程。

4.1 第一步：AI 开始反问需求，而不是先写代码

我在 codex CLI 里输入：

使用 deep-planning 技能，我需要给用户模块增加一个批量导出 CSV 的功能。

如果没装 superpowers，AI 大概率会直接说“好的，我来为你添加导出功能”，然后哐哐哐写一堆代码。但装完之后，它先返回的是几个问题，我贴一下我当时收到的提问（大意）：

1. 导出范围是支持按条件筛选后的导出，还是只支持导出全部用户？
2. CSV 文件需要的字段有哪些？导出字段和列表展示字段是否一致？
3. 这个功能需要做权限控制吗？比如只允许管理员导出？
4. 导出的文件是直接在浏览器下载，还是先生成到服务器再提供下载链接？

这四个问题，每一个都命中我之前容易忽略的细节。比如我之前做导出，经常会遇到超大数据量导出的问题，但 AI 提前问了“范围”和“方式”，就逼着我把方案想清楚，而不是等到代码写一半再返工。

4.2 第二步：输出了分步实施计划，我确认后才动手

我逐个回答了问题，告诉它：支持按条件筛选导出、字段包含姓名/邮箱/注册时间/状态、仅管理员可操作、先写到服务器再提供链接下载。它接着输出了一份实施计划，大致是：

1. 创建导出任务数据表，用于记录导出操作的任务状态。
2. 新增后端接口/api/admin/users/export，接收筛选参数和用户 token。
3. 在接口内部先用筛选条件查询用户 ID 列表，再批量生成 CSV 文件到临时目录。
4. 生成完成后，创建一个下载链接记录，并返回给前端。
5. 前端在用户管理页添加“导出 CSV”按钮，调用接口并轮询任务状态。
6. 补充单元测试，覆盖权限校验、筛选条件、CSV 生成格式三个场景。

我对比了一下自己的方案，发现它比我原本想象的还多考虑了一层“导出任务表”——因为大数据量导出可能是耗时操作，不能同步返回文件，必须先建任务异步处理。这个细节在我以前让 AI 直接写代码时，它很少主动想到。

计划确认后，它才开始分步执行。每执行完一步，它会停下来汇报“已创建任务表结构，下一步创建接口”，然后继续。整个过程我可以随时打断、提意见，而不是一次性把代码全吐出来，让我在长长的对话流里翻找中间的逻辑。

4.3 第三步：变更清单与测试，收尾不拖泥带水

全部代码写完后，它按 code-editing 的纪律输出了一份变更清单：

• 新增文件：migration/2025_xxx_add_export_task.py（创建导出任务表）
• 修改文件：controllers/admin/user.py（新增导出接口）
• 修改文件：services/export.py（新增 CSV 导出逻辑）
• 修改文件：frontend/src/pages/UserList.vue（新增导出按钮）
• 新增测试：tests/test_admin_export.py（覆盖三个场景）

我照着这份清单快速 code review，发现它把 CSV 的 Excel 兼容处理都想到了——在 BOM 头前面加了\ufeff，避免 Excel 打开乱码。这个细节以前我都要自己加注释提醒它，这次它主动处理了。

整个流程跑下来我最大的感受是：AI 的产出质量和“可控感”完全不一样了。它不再是黑盒里冒出一大段代码，而是像团队里的一个同事，先问清楚需求、给出计划、按部就班地执行、最后交一份清晰的变更说明。

5. 常见问题与防坑指南：我安装使用中踩过的坑

任何工具都不是完美的，superpowers 也不例外。我在安装和使用过程中遇到过一些比较典型的问题，单独整理出来，希望能帮你少走点弯路。

5.1 技能加载不生效，AI 还是“裸奔”状态

这是最常遇到的问题。你已经把技能文件放到对应目录了，但 AI 的行为完全没变化，还是你问一句它答一段，根本不走规划流程。

我的排查顺序是这样的：第一步，确认技能文件路径是否正确，目录结构不能多嵌套一层。第二步，确认工具的版本是否支持 skills 机制，有些旧版本根本不扫描技能目录，你放再多文件也没用。第三步，看工具是否有独立的技能开关或者命令，比如 codex 里有时需要执行codex command list刷新一下。

最后，还有一个最容易忽略的：即使技能加载了，模型也可能不走流程，因为它把这当成“建议”而非“指令”。解决办法是在项目约定文件里写死一句“执行本项目的任何编程任务前，必须先调用 deep-planning 技能，没有例外。”用强指令约束，模型就会老实很多。

5.2 模型忽视频繁提问，直接开写

有些模型为了追求“效率”，会跳过澄清问题，直接按默认假设开写。这通常是模型自己的行为偏好，superpowers 的技能文件只能引导，不能完全控制。

这种情况下我会在 codex CLI 的配置里，把温度调低一些，并把“严格遵循技能流程”写进系统提示词。实测下来，像 Claude 和 GPT 系模型在低温度下会更愿意遵循流程，而 DeepSeek 等开源模型则需要你在对话里稍微盯紧一点，如果发现它跳步了，就明确说“按照 deep-planning 的流程重新来”。

5.3 自定义技能：如何把团队规范做成专属 skill

superpowers 的魅力在于它不只是别人定义的技能，你也可以把自己团队规范做成一个专属技能。我建议你把团队的 Code Review 清单、上线检查列表、部署规范这些内容，做成一个team-rules技能，放到 skills 目录下，内容用 Markdown 写好，开头备注触发条件就行。

比如我给自己团队写过一个database-review技能，内容是要求 AI 在改动数据库表结构前，必须列出影响表、索引变更、数据迁移脚本、回滚方案，然后再动手。这个技能运行起来，比我开十个评审会都管用。

做自定义技能的门槛很低，会写 Markdown 就会写。核心就是要把“步骤”“要求”“输出格式”写清楚，尽量不要留模糊地带。

5.4 踩坑后的总结

我实际用下来的体会是，superpowers 不是“装上就有魔法”的工具，它更像是一个流程管理的框架。它的上限取决于你怎么用它：如果你只是装完不管，AI 还是会偷懒；如果你配合项目约定、配合自定义技能、配合流程引导，它就能把你的标准执行得很好。

另外提一个建议：别一开始就把所有技能全部启用，很容易造成冲突和混乱。我的做法是先只用 deep-planning，等习惯了这个节奏，再把 code-editing 加上，最后再根据项目情况补自定义技能。循序渐进，比一步到位稳得多。

如果你也是被 AI 代码“又快又烂”困扰的人，我建议你花一个下午把 superpowers 装上，别急着让它写业务代码，先拿一个小功能跑一遍流程。我敢说你体验过“先规划、再动手、带变更清单”的协作方式之后，就很难再回去用那种“一句话生成一百行”的用法了。这套东西目前在 GitHub 上迭代也很快，社区还在不断给它的场景加新技能，后续能玩出什么花样，我挺期待的。