企业官网建设流程全解析

如果你最近在折腾 Codex CLI，或者正在用 Trae 的 Agent 模式写代码，大概率在社区里反复看到一个词：superpowers。这个名字确实有点唬人，听起来像个营销概念，但真把它的安装向导跑完、再打开生成的技能文件看一眼，你会意识到它跟那些收藏吃灰的"高质量Prompt模板"完全是两码事。

先给一个结论：superpowers 是一套跑在 AI 编码工具之上的"技能包"，它通过 SKILL.md 这类技能清单 + 配套脚本的方式，改变 AI 在处理编码任务时的"行为方式"。换句话说，它不替 AI 写代码，它教 AI 怎么像有工程纪律的人一样处理需求、理解源码、分步执行、验证结果。本文我按自己的实操路径把三件事讲透：Codex CLI 怎么装、Trae 工作区怎么接、装完之后哪些技能值得用、哪些坑你大概率也会踩。

1. 为什么一套"技能包"能改变编码 AI 的上限

很多人在用 Codex CLI 这类工具时有个感受：让 AI 写一个独立函数、写一段脚本，它表现很好；一旦让它在一个几万行的仓库里改一个牵连多个模块的功能，它就容易"自由发挥"——没有先理解现状就开写，没有验证就交差，甚至会把项目里已有的工具函数重新造一遍轮子。

superpowers 解决的就是这个问题。它的底层思路非常朴素：给 AI 配置一套"工程流程规范"，让它在动手之前先做信息收集，在生成代码之前先建立代码映射，在交付之前先跑测试。技能包不等于提示词，提示词是"语气和约束"，技能包是"行为协议 + 任务分解策略 + 可执行的检查清单"。

1.1 有知识但没方法：AI 编码的真实短板

我拿 Codex CLI 做过一个对比实验：同一个仓库，同一个需求，不挂技能，AI 直接给出一个 200 行的补丁；挂上 superpowers 里的对应技能之后，它的回答变成了"先梳需求 → 定位相关文件 → 列出约束 → 给出最小改动方案 → 验证路径"。改动量小了一半，且没有出现之前那种"顺手把无关代码重构了"的行为。

这不是模型变聪明了，是它被"流程"约束住了。对于一个刚入门的开发者来说，你在提示词里狂写"请认真思考，仔细检查"效果很差；但技能包会把"仔细"拆成可执行的步骤。AI 哪怕不懂你的项目，也会按步骤做信息收集。这就是我说它改变的是"工作方式"，而不是"回答长度"。

1.2 技能包的内部结构：一套可以被挂载的指令体系

superpowers 的细节在不同月份变化很快，但它核心的组织方式相对稳定：分为行为技能（behavior skills）和编码技能（coding skills）两大类。每个技能是一个独立文件夹，里面有 SKILL.md 说明文件、可选的脚本目录和资源文件。SKILL.md 的开头有一段 frontmatter，包含 name 和 description，AI 就是靠 description 来判断"什么场景下应该调用这个技能"。

这个"命中场景才加载"的设计很关键。它不是把所有内容都塞进上下文，而是让 AI 在收到任务后先判断"现在属于哪个场景"，再读取对应的 SKILL.md 来约束自己的执行方式。这就解释了为什么安装技能包之后，AI 的日常短问答并没有明显变慢，但复杂任务的完成质量上了一个台阶。

2. Codex CLI 安装 superpowers 的完整链路

如果你已经在用 Codex CLI，安装 superpowers 其实没有想象中复杂。整个过程可以概括为：跑一个配置向导，选择 AI 工具，选择要安装的技能，生成项目记忆文件夹。下面按我的实际操作顺序拆开讲。

2.1 安装前的准备：环境要求与目录规划

先确认基础环境。Codex CLI 本身需要 Node 环境，建议 Node 18 以上。安装之前打开终端跑一下codex --version确认版本不是太旧。如果之前已经用 Codex 做过不少项目，注意你的全局配置里可能带了自定义的 AGENTS.md 规则，这会影响 superpowers 的安装结果——不是冲突，而是它会把内容合并进现有项目记忆文件，合并顺序对技能触发时有影响。

我个人的习惯是建一个干净的试验目录来跑首次安装，例如~/projects/superpowers-lab。在这个目录里先初始化一个 git 仓库，因为技能包的安装向导会检测当前目录是否在 git 仓库内，它生成的某些脚本和文档链接依赖仓库根目录做路径解析。没有 git 仓库也能装，但生成的"项目地图"类技能在后续代码定位时可能会找不到根路径，所以先git init是值得的。

2.2 运行配置向导：从零到技能就绪

在干净的试验目录里执行安装命令。不同版本可能用到的包名有差异，以当前网络的公开资料来看，比较常见的入口是：

npx @superpowersapps/superpowers

第一次执行时 npx 会问你"OK to proceed?"，继续就好。接着进入一个交互式配置界面，主要有三个维度的选择：

1. 目标 AI 工具：选择 Codex CLI（如果你的场景是 Trae，选择对应的 Agent 模式，或先选 Codex 再手动改路径，这一点在本文第 4 部分细说）。
2. 安装哪些技能：安装向导会列出行为技能、编码技能、语言相关技能的清单。新手建议全装，跑通验证之后再按需裁剪。
3. 项目记忆文件的位置：向导会在当前目录生成.superpowers文件夹，并在AGENTS.md或SKILLS.md中写入技能索引。

配置完成后，向导会给出一个验证提示。最直接的方式是重启 Codex CLI，然后用斜杠命令查看已加载技能：

codex /skills

如果能列出你刚安装的技能清单，说明加载成功。注意这里是"重启会话"后再验证，旧的会话里技能索引可能不会自动刷新。

2.3 安装后我第一次踩的坑：技能列表为空

我第一次装完，/skills返回空列表，当时差点以为是装坏了。后来排查发现，问题出在我没有从 Codex 的旧的交互会话退出，直接在会话里跑/skills，而 Codex 读取 AGENTS.md 的时机是会话启动时。也就是说，会话创建之后安装技能，当前会话是感知不到新技能存在的。

另外还有一个权限问题值得注意：如果当前目录在~/或某些受系统保护的位置，生成的.superpowers文件夹可能没有写权限，导致技能脚本无法执行。我当时在/Users/用户名/下直接跑安装，脚本部分失败。后面把项目挪到普通用户目录下的独立文件夹再装，一切正常。

这些和"教程对不对"无关，纯粹是环境细节。装完后想快速确认目录形态，可以打开.superpowers看看里面是不是每个技能都包含一个SKILL.md，如果某些技能只有目录没有文件，大概率是安装的中途遇到了文件写入失败，重新执行一次安装向导通常能补齐。

3. 核心技能拆解：哪些 skill 真正值回票价

装了技能包之后，下一步是理解它到底给了 AI 什么新的能力。superpowers 的技能数量不少，我都过了一遍，但真正在日常开发中高频触发、改变了我工作习惯的是下面这几个。

3.1 copy-coding：让 AI 先"读"再"写"的范式转变

这是我对 superpowers 评价最高的技能，没有之一。它的切入点是解决一个被很多人忽略的问题：当你说"把这个页面复制过来"或"把这段逻辑搬到新模块"，AI 往往会直接生成一段"看起来很像"的代码，但实际上跟你项目里的类型定义、路由方式、状态管理完全对不上。

copy-coding 的执行流程大致分四步：

• 先解析你的输入，拆出你要求的"页面/功能/数据流"核心概念
• 在代码库里做地图扫描，找到相关的入口文件和依赖链
• 把代码库里的实现方式映射到输入概念里，识别出哪些是死代码、哪些是待修改部分
• 起草代码时遵循最小改动原则，而不是整体重写

我在一个 Vue 3 项目里实际用了一次，需求是"把用户列表页复制成项目列表页，字段不同"。没有技能时，AI 给我生成了一份全新的文件，和原来的代码风格割裂；用了 copy-coding 之后，它自动查找了原有的列表页组件、路由配置、API 封装，然后告诉我"建议修改 5 处，新增 1 个文件"，交付结果基本符合预期。

3.2 multi-step-thinking：让推理链显式化

multi-step-thinking 是一个行为技能，它的作用是强制 AI 在开始回答问题前，先把"任务拆解步骤"写出来，并在执行过程中逐步验证中间结果。乍听起来像"让我想想"的 Prompt 加强版，实际差别在于：它要求每一步的推理结果必须对应到仓库里的文件、代码片段或命令输出，而不是抽象的"我觉得应该这样"。

实操下来这个技能是"双刃剑"。在 Codex 配合较强推理模型时，它能显著减少 AI 胡说八道的概率；但在一些小参数模型上，它反而会让 AI 的思考变得冗长且离题。最典型的表现是：模型硬套多步推理模板，输出大量"第 1 步、第 2 步"的空泛描述，却没有真正的代码改动。所以这个技能不是给所有模型都用同一个配置，后面第 5 部分我会专门讲模型门槛。

3.3 code-review 系列：把人工检查清单交给 AI

superpowers 里还有一组编码技能跟代码审查有关，比如对改动代码做审查、对补丁做检查、以及为提交信息生成结构化描述。这类技能的价值不在"找到 bug"，而在于它提供了一套可复现的审查视角：

• 改动是否越过了需求边界
• 是否有重复的工具函数可以复用
• 类型的变更是否同步到了调用方
• 错误处理是否覆盖了失败分支

这套审查框架本身并不稀奇，但以技能形式挂载后，你可以随时对任意一次改动触发它，而不是靠自己的记性去提醒每一次都让 AI 检查。我一般会在生成补丁后、提交合并前用一下，当天的改动就会少很多"低级但影响面大"的问题。

4. Trae 工作区接入实践：把技能挂进 Agent 项目

Trae 的 Agent 工作区是我日常主力。很多人在 Trae 里装 superpowers 会觉得不顺畅，原因是 Trae 的配置路径和 Codex CLI 不完全一样，它更强调"工作区"的概念。下面是我的接入方法。

4.1 Trae Agent 工作区如何加载技能

Trae 的 Agent 模式在项目中有自己的一套指令文件读取机制，常见的是读取项目根目录下的说明文件（类似 AGENTS.md 的项目指令），这些指令文件会在 Agent 启动或新会话创建时被载入。superpowers 生成的技能索引如果能被这个指令文件引用，Agent 就能在需要时读取对应的 SKILL.md。

所以接入的本质是：把技能包的文件放到工作区目录里，再让 Trae 的 Agent 在启动时"看得到"那份技能索引。在这个基础上有两条路：

• 方法一：直接在工作区根目录用 CLI 生成技能包，让安装向导选择 Trae 对应的选项（如果有），自动写入该项目使用的说明文件。
• 方法二：手动创建技能目录，并在 Trae 的项目指令中引用技能索引。

4.2 我的配置步骤与验证方法

我实际用的是方法一，但做了一点调整。因为当时安装向导里对 Trae 的支持还不够直观，我先按 Codex 的方式把 superpowers 生成到项目根目录，再在工作区的项目指令文件里追加了一行配置，指向生成的技能索引文件。

大致路径形态如下：

project-root/ ├── .trae/ │ └── rules/ │ └── project_rules.md # Trae 项目指令 ├── .superpowers/ │ ├── SKILLS.md # 技能索引 │ └── skills/ # 各技能目录 └── AGENTS.md

然后将技能索引引用追加到项目指令文件里：

## Skills 当任务涉及编码实施、代码理解、审查等场景时，应首先读取 .superpowers/SKILLS.md 中的技能列表，并加载对应的 SKILL.md 作为执行约束。

配置完成后，重开一个 Trae Agent 会话，在对话里直接问："你能列出当前工作区加载了哪些可用的技能吗？"如果回答中提到了 copy-coding、multi-step-thinking 等技能，说明安装成功。如果没有，检查一下 Trae 工作区对项目指令文件的读取时机，一般需要新建会话，不能复用旧会话。

4.3 在 Trae 上复现的一个高频问题

我在 Trae 工作区里刚开始也遇到过一个很诡异的现象：技能索引已经写进来了，项目指令也引用了，但 Agent 在编码时完全不按技能流程走。后来发现原因是 Trae 的 Agent 内置了多档模型，我默认用的那档小模型虽然能看到技能文件，但没有足够的推理能力去执行多步技能流程。切换成最强的推理模型档位之后，同样的配置立即生效。

这个问题的根源在于"技能包改变的是 AI 的执行策略，不是 AI 的理解能力"。如果模型本身缺乏长上下文推理能力，它读到了 SKILL.md 也相当于没读到。后面我在项目里就固定了"复杂编码任务用推理模型，简单问答用小模型"的使用习惯。

5. 安装成功只是开始：模型门槛、token 成本与触发逻辑

很多帖子只讲"怎么装"，不讲"装完怎么用"，更不讲"为什么不同人装同样的技能包效果天差地别"。这一节把这些容易被忽略的问题讲清楚。

5.1 模型档位决定了技能包的天花板

我分别在 Codex 里用不同档位的模型跑同一个技能包，结果差异非常大：

所以如果你装完之后觉得"没什么用"，不要急着卸载。先把默认模型切到你当前可用配置里最强的推理档，再跑一次之前觉得失败的任务，大概率感受完全不同。这不是玄学，是模型的执行能力差异。

5.2 技能不是越多越好：一份真实的 token 观察

superpowers 支持全量安装，我一开始也全装了，然后很快就发现一个现象：每次新会话启动时，AGENTS.md 和 SKILLS.md 的索引信息都要进入上下文，技能数量多的时候会占掉不少 token，简单任务还没开始干，几百个 token 就烧掉了。

对高频小任务来说这个成本有点高。我后来做了裁剪：行为技能保留 multi-step-thinking 和测试相关，编码技能只保留 copy-coding、code-review 和提交信息生成。会话启动开销降了接近一半，而日常任务该触发的技能一个没少。

另外，SKILL.md 文件本身也建议保持精简。一个技能文件如果在 100 行以内，AI 在命中场景时能快速读取；如果写得像一本书，AI 反而会在冗长上下文里丢掉重点。这个原则同样适用于后面你要自己写技能的场景。

5.3 描述越精确，触发越稳定

技能里的 frontmatter 是 AI 判断何时调用的唯一依据，但它有三个字段比较关键：name 是技能的标识，description 是触发条件描述，allowed-tools 可选地限制技能内部可以访问的工具。很多人不注意 description 的写法，导致 AI 频繁误触发或从不触发。

我给你一个对照：

# 不推荐的 description description: 用于代码生成和修改任务。 # 更合理的 description description: 当用户要求复制现有页面、组件或功能到新位置，且需要保持代码库一致性时使用。不适用于从零开始的新功能开发。

第一版描述过于笼统，AI 会在"帮我写个函数"这种简单需求时也尝试加载技能，白白消耗上下文；第二版把触发窗口写清楚了，命中率高，且明确排除了不适用场景。装完技能之后花几分钟检查一下 description，是回报率很高的调优。

6. 把 superpowers 改成你的形状：编写私有 skill 的框架

技能包用得越久，我越意识到它的真正价值不是那几十个预置技能，而是它提供了一个"把团队规范沉淀成 AI 可执行指令"的框架。到了这个阶段，你会开始想写自己的技能。

6.1 什么场景值得写一个私有技能

三个判断标准：一，团队里的代码规范文档写了但人记不住；二，你的项目技术栈或目录结构很特殊，AI 每次都要靠试错才能理解；三，你发现自己在重复给 AI 粘贴同一段长指令。满足其中一个，就值得把这段"经验"打包成一个技能。

我写过的第一个私有技能是关于一个遗留项目的：那个项目里每个模块都要同步改三处文件，否则运行时报错藏得很深。第一次让 AI 帮我改，它只改了主文件，我反复纠正了三次。后来我把这个逻辑写成了技能，再让 AI 处理同类需求，它第一步就会检查另外两个文件是否同步更新了。

6.2 一个私有技能的最小骨架

在.superpowers/skills/下创建以技能名命名的文件夹，里面放一个SKILL.md：

--- name: sync-legacy-module description: 当在 legacy 项目中修改模块时，必须调用此技能以确保三处文件同步更新。适用于员工模块、订单模块，不适用于新增模块。 --- # 同步遗留模块三处文件 ## 背景 遗留模块的每次改动必须同时更新以下三处： 1. 主入口文件 `src/modules/{name}/index.js` 2. 路由映射文件 `src/router/{name}.js` 3. 侧边栏配置文件 `src/config/sidebar.js` ## 执行步骤 1. 先定位被修改的模块名 2. 检查上述三处文件当前内容 3. 按需求改动主入口文件 4. 同步更新路由映射和侧边栏配置 5. 检查是否存在对旧路径的引用，如有则一并修正 ## 验证清单 - [ ] 三处文件均已更新 - [ ] 不存在旧路径引用 - [ ] 本地运行无报错

这样一个技能，写得很简单，但它解决了 AI"不知道你项目里有暗线依赖"的问题。写完以后，在 SKILLS.md 索引里加一行指向新技能的路径，然后新建一个会话触发测试。

6.3 验证与迭代：从技能消费到技能维护

验证技能是否生效，不要只问"你加载了技能吗"，要实际给它一个该技能覆盖的任务，观察它的第一步是否按照技能的约束进行。如果没有，多半是 description 的触发条件没写好，或者当前模型没有足够推理能力执行多步流程。迭代时优先改 description，而不是急着改正文步骤。

我现在的做法是每两周会整理一次技能列表，删掉那些从没触发过的，优化那些触发过但执行偏离的。技能是活的，隔一段时间不维护，它也会过期——比如依赖包升级了、目录结构调整了，技能里的路径就失效了，这时要及时同步更新。

用 superpowers 一段时间后，我对"AI 编程工具的天花板在哪里"有了新的理解。真正拉开差距的不是工具本身，而是你是否给了工具一套可执行的工程流程。技能包提供的是起点，持续维护和自定义技能才是让它真正适配你项目的关键。希望这篇实操记录能让你少走几步弯路。