企业官网建设流程全解析

最近我几乎每个技术群里都能看到有人在问 superpowers 怎么装、怎么用，尤其是 Codex CLI 和 Trae 这两拨用户。说实话，这名字第一次听确实有点中二，好像装完 AI 就能一夜变成超级开发者。但它的思路我很吃这一套：不是靠某个更强的模型开挂，而是把一整套规范的开发流程直接“喂”给 AI 编程助手，让 AI 拿到需求之后先规划、再动手、最后验证，而不是像以前那样上来就甩一大段代码，对不对全靠运气。

这篇文章我把我实际折腾下来的安装方法、使用场景、核心机制和踩坑记录整理出来。适合正在用 Codex CLI 的终端党、把 Trae 当主力 IDE 的同学，以及所有觉得 AI 写代码“开头惊艳、细节翻车”的人。先说结论：superpowers 不神秘，它是一套可以被 AI 编程工具加载的“技能包”（Skill），真正有价值的地方在于流程被固化了，人的经验能跟着代码库走，而不是永远靠临场发挥。

1. superpowers 到底是什么：先看懂它在解决什么问题

1.1 从“AI 写代码”到“AI 按流程写代码”

很多人最开始用 AI 编程，流程基本是这样：复制需求贴给模型，模型丢回一段代码，自己复制到项目里跑一下，报错就把错误贴回去，让 AI 改。这种方式对小脚本、一次性任务确实快，但在真实项目里很容易翻车。原因很简单：模型拿到的是一个孤立需求，它看不到项目里已有的模块、命名规范、测试框架、历史代码的写法，更不会主动去确认“这个功能应该放在哪个目录”“会不会影响已有逻辑”。AI 写出来的代码往往“单看没问题，合进去全是问题”。

superpowers 这类技能包，本质上就是把软件开发流程做成了 AI 能读取的“工作手册”。它不是一个独立运行的程序，而是由多个 Markdown 文件组成的技能集合，放在 Codex CLI、Trae 等工具约定好的技能目录里。当你在对话中通过@superpowers:core这类方式触发它时，工具会把对应的技能文件内容注入到模型上下文里，相当于在正式干活前给 AI 补了一段“岗位培训”：拿到需求应该先做什么、遇到错误应该怎么排查、测试必须覆盖到哪一步、代码写完要做什么检查。

这个思路其实非常朴素，但效果差异巨大。大家可以回想一下：同样一个实习生，你直接丢给他一个任务，和先给他一份团队开发规范手册再让他干活，产出质量完全不一样。superpowers 就是把“团队手册”这件事自动化了，而且它不依赖人的记忆，只要文件在，AI 每次都能按同一套标准来。

1.2 技能包和普通 prompt 的区别

有人会说：那我直接把这段流程写进 prompt 不就行了？能，但有本质区别。普通 prompt 是写在聊天窗口里的，今天写了明天可能忘，换个项目又得重写；而且 prompt 越长，模型越容易在执行过程中“失忆”，前面的规范到后面就遵守不住了。技能包则是独立的文件，由编程工具在合适的时机自动注入，不占用正常对话的上下文长度，也不会被后续聊天内容冲淡。

我整理了一张对比表，方便大家直观理解：

这就像同一个老师傅，一个版本是“每次都得打电话问他怎么办”，另一个版本是“他把所有经验整理成了操作手册放到桌上，需要时翻对应章节”。后者显然更靠谱，也更可持续。尤其当团队里有多个人都在用 AI 编程时，把技能文件提交到 Git 仓库里，所有人就共享同一套 AI 行为准则，新人也容易上手。

2. 为什么 Skills 这种形态越来越流行：底层机制拆解

2.1 技能文件怎么被加载：目录与格式

既然说 superpowers 是技能包，那就有必要先聊清楚“技能”在 Codex CLI、Trae 这类工具里到底是怎么被识别和加载的。目前主流做法是目录约定 + 文件约定：工具会扫描指定目录下的技能文件夹，每个技能文件夹里至少有一个SKILL.md文件，这个文件的开头通常带 YAML 格式的元信息，包含技能名称name和描述description，后面是正文，写具体的指令、步骤、示例。

举一个典型结构：

skills/ └── superpowers/ ├── SKILL.md ├── core/ │ └── SKILL.md ├── planning/ │ └── SKILL.md └── debugging/ └── SKILL.md

当你在对话里输入@superpowers:planning，工具会根据superpowers这个命名空间找到技能目录，再根据planning找到对应的SKILL.md，把里面的内容注入到当前对话的上下文里。整个过程对用户来说就是“@一下”，但对 AI 来说，相当于临时拿到了一份非常具体的工作指令。

这种设计最妙的地方在于：技能文件是纯文本、纯 Markdown，人和 AI 都能读。你可以直接打开文件看它到底写了什么，也可以随手改掉其中一段。不需要编译，不需要特殊格式，放进目录就能生效。对于做技术的人来说，这种“看得见、摸得着”的可控感，是黑盒 API 完全没法比的。

2.2 工作流设计：规划、执行、验证三层循环

superpowers 内部其实不是一个大而全的文件，而是拆成了多个子技能，分别对应软件开发的不同阶段。我实际使用下来，核心工作流大致是三层循环：规划、执行、验证。

先说规划层。触发@superpowers:core或对应的 planning 技能后，AI 不会立刻写代码，而是先产出一份计划，包括：这个需求涉及哪些文件、功能入口在哪里、数据流怎么走、有没有潜在影响点。有些技能甚至会让 AI 先生成任务清单，逐条列出待办事项。这一步的关键作用是逼着 AI“先想后做”，也逼着用户先确认方向对不对，避免南辕北辙。

再说执行层。计划确认后，AI 开始写代码，而且通常会以小步提交的方式推进：改一个文件、跑一次测试、看结果、再改下一个。相比传统一次生成几百行代码，这种小步快跑的方式更容易定位问题，也更容易回归验证。

最后是验证层。代码写完了不算完，技能会要求 AI 检查测试结果、运行 lint、审查是否存在明显边界问题，甚至逐条复盘“我改了什么、为什么这样改、有没有更简单的方案”。这一步很多人自己写代码都懒得做，但 AI 按流程走一遍之后，产出的代码质量确实会明显提升。

这套三层循环的背后逻辑，是从“让 AI 生成代码”转向“让 AI 完成一个开发任务”。前者只看输出，后者关注过程。而只要过程是可预期的，结果就不会太离谱。

3. 实操：在 Codex CLI 和 Trae 中安装 superpowers

3.1 准备工作：确认环境与版本

在安装 superpowers 之前，先确认你的环境满足条件。Codex CLI 本身是 Node.js 环境的命令行工具，所以需要先装好 Node.js 和 npm。第二件事是确认版本，因为技能加载功能是后续才加入的，太老的版本可能根本不会扫描技能目录。建议先跑一下命令看版本：

node -v npm -v codex --version

如果还没有装 Codex CLI，可以这样装：

npm install -g @openai/codex

如果你的网络环境访问 npm 比较慢，可以换国内镜像源，但具体用哪个镜像要根据自身情况来，这里不展开。装好之后，建议跑一次codex进入交互界面，确认能正常对话，再继续下面的技能安装。这样做是为了排除基础环境问题，不然技能装了半天，结果原因是 Codex 本身没跑起来，那就很浪费感情了。

Trae 这边更简单，它本身是图形化 IDE，不需要额外装命令行环境，只需要确认版本支持“自定义技能”。目前无论海外版还是国内版，基本都在设置或扩展面板里能搜到 Skills 相关选项。不同版本入口名称可能略有差异，找不到的话直接在设置页搜索“skill”“技能”这类关键词即可。

3.2 Codex CLI 安装步骤：用户级目录与项目级目录

Codex CLI 的技能加载路径有好几个，最推荐的是用户级目录，因为它对所有项目生效，不用每个仓库都复制一份。先把目录建好，然后把 superpowers 项目拉下来。

mkdir -p ~/.codex/skills git clone <superpowers仓库地址> ~/.codex/skills/superpowers

具体仓库地址以你搜到的 superpowers 项目主页为准，GitHub 上直接搜索 “superpowers skills” 就可以找到。我个人建议第一次安装时不要把地址猜错，哪怕先 clone 到一个临时目录确认一下结构，再复制到~/.codex/skills下也行。拉下来之后检查一下文件是否完整：

ls ~/.codex/skills/superpowers cat ~/.codex/skills/superpowers/SKILL.md | head -20

如果能正常看到 Markdown 内容，说明技能文件已经就位。接着重新启动 Codex CLI（重要，技能扫描通常发生在会话创建时），在对话里输入@superpowers:core或者直接问“你能加载 superpowers 技能吗”，如果 AI 能说出这个技能的功能，就说明加载成功了。

项目级目录也是常见需求。如果你不想让技能影响所有项目，或者想把技能绑定到特定仓库里，就放到项目根目录下的.codex/skills/superpowers：

mkdir -p .codex/skills git clone <superpowers仓库地址> .codex/skills/superpowers

项目级目录的好处是技能文件可以跟着仓库走，提交到 Git 之后，团队其他人拉下来就能用，很适合做团队统一规范。缺点是每个仓库都要处理一次，如果仓库多，管理成本会上升。我的建议是：个人机器上用用户级，团队项目里用项目级。

3.3 Trae 安装步骤：目录差异与界面操作

Trae 的安装方式和 Codex CLI 不太一样，因为它没有全局命令行目录，技能通常放在工作区目录或专门的用户配置目录里。常见的路径有两种：一种是项目根目录下建.trae/skills/superpowers，另一种是在用户主目录下的 Trae 配置目录里放skills/superpowers。具体是哪一个，和版本有关系，不必死记，关键是理解机制：把技能文件夹放到工具会扫描的目录。

实际操作可以这样：先在项目根目录建好技能目录并拉取文件：

mkdir -p .trae/skills git clone <superpowers仓库地址> .trae/skills/superpowers

然后在 Trae 的设置或扩展面板里确认“自定义技能”开关是打开的。如果界面里没有立即出现新的技能，先检查目录名称拼写，再重启一下 IDE 或刷新技能面板。Trae 的对话窗口中，触发方式一般也是@superpowers:core这类形式，或者你可以直接在对话里说“请使用 superpowers 流程处理这个任务”，AI 会根据描述自动关联到已安装技能。

有一点要特别提醒：Trae 不同版本对技能目录的识别策略并不完全一致。我自己遇到过在设置里能看到“技能管理”，但手动放进去的目录怎么都不生效的情况，最后发现是版本要求技能文件必须放在工作区根目录下命名为.trae/skills，而不是用户目录。所以大家安装前最好先看一眼对应版本的官方文档，或者直接在 IDE 的设置页搜“技能目录”看它提示的路径。盲目照搬别人路径，容易卡在最后一步。

3.4 升级与版本管理：别把技能目录当成一次性配置

技能包和普通依赖一样，需要持续更新。尤其是这类社区项目，作者经常会根据新模型、新工具的能力调整技能描述和流程，保持更新才能享受最新效果。更新方式很简单，进入技能目录直接拉取：

git pull

如果你直接在官方仓库基础上做了修改，git pull可能会冲突。这种情况下，我建议先把自己的改动提交成一个 commit 或者用git stash暂存，拉取完再恢复。想要长期维护团队定制版的话，更推荐 fork 一份，然后把官方仓库设为 upstream，定期 merge 上游更新。这样既能保留官方的新流程，又能加入自己团队的规则。

另外还有一个很实用的习惯：把技能目录纳入版本管理。项目级的.codex/skills或.trae/skills目录不要写进.gitignore，这样才能让团队共享技能文件。如果项目已经发布到远程仓库，记得确认没有把包含敏感信息的指令写进技能文件，因为它是会被所有人看到的。

4. 核心技能的使用方法与真实效果

4.1 对话中的触发方式：不是每个命令都一样

安装完成只是第一步，真正的关键在于怎么用。superpowers 通常提供多个子技能，常见的包括core（核心完整流程）、planning（规划）、debugging（调试）、code-review（代码审查）、test-driven-development（测试驱动开发）等。触发方式就是在对话里输入对应的技能句柄，例如：

@superpowers:core @superpowers:planning @superpowers:debugging

有一点要说明：不同版本的 superpowers 子技能名称不一定完全一致，装好之后先看目录结构，再对照SKILL.md里的技能列表去调用，别凭印象硬敲。还有，如果你的工具不支持@触发，也可以用自然语言，比如“请先做需求分析，再给出实现计划，最后编码并运行测试”，理论上效果类似。但这种方式依赖模型当时的理解，稳定性不如显式触发技能。

实际用下来，最推荐的做法是在一段任务开始时，第一句话就带上技能句柄，让 AI 从那一刻起切换到对应模式。比如你想让 AI 帮你排查一个线上偶发报错，可以这样起手：

@superpowers:debugging 我有一个报错：用户注册后偶尔收不到验证邮件，日志里看到 timeout，帮我排查。

带着技能句柄启动后，AI 的行为和普通对话会有明显区别。它更倾向于先说“我计划从哪些方向排查”，然后主动找代码、看日志、提出可验证的假设，而不是直接甩给你一段所谓修复代码。

4.2 一个完整任务示例：让 AI 按计划落地

为了方便理解，我拆解一个实际例子。假设任务是“给现有博客系统增加文章归档页面”，这个需求其实涉及路由、查询逻辑、模板、导航等多个环节，普通 AI 对话很可能直接生成一个页面文件就完事了，但 superpowers 模式下流程完全不一样。

触发@superpowers:core之后，AI 第一步会生成计划，大致内容可能是：先查看项目目录结构，找到博客文章数据模型，确认路由注册方式，再看现有列表页模板风格，最后评估是否要加侧边栏入口。这个计划会直接展示在对话里，如果发现 AI 对项目结构理解不对，你可以当场纠正。

第二步是探索代码库。AI 会去搜索相关文件，比如 grep 关键词archive、查看路由文件、读取数据模型定义。这时候你会看到它列出一串文件路径，这说明它是在真实项目环境中找线索，而不是凭空想象。

第三步才是写代码。但注意，它不会一次性把所有文件都改完，而是拆成小步骤：先加查询逻辑，跑一下有没有报错；再写页面模板，检查数据能不能正常渲染；最后把导航入口补上。每一步之间它会自己判断是否要继续。

第四步是验证和复盘。如果项目有测试，它会跑一遍相关测试；没有测试的话，它会至少手动检查页面是否能访问、数据是否正确。最后它还可能会提醒你：这个功能目前没有自动化测试覆盖，建议补一个。这个细节我印象很深，因为很多 AI 默认不会主动关心测试覆盖，但技能流程里会明确要求。

4.3 自定义技能：把团队规范写进去

安装 superpowers 不是终点，真正让它发挥价值的是自定义。你完全可以把团队内部的代码规范、命令规范、禁止事项加到技能文件里。比如在SKILL.md的指令部分追加这样的内容：

## 团队附加规范 - 所有新增函数必须写 JSDoc 注释。 - 错误处理统一使用项目内封装的 AppError，不要直接 throw new Error。 - 提交代码前必须运行 `npm run lint` 和 `npm run typecheck`，有报错不许提交。 - 修改数据库相关代码时，必须同步检查 migration 文件是否受影响。

这些规则对新人来说是学习成本，但对 AI 来说是零成本。只要技能文件里有这句话，AI 每次处理相关任务时都会带上这个约束。我自己的做法是把技能仓库单独维护，里面除了官方核心流程，还增加了团队自定义技能，比如“后端接口开发”“前端页面开发”“数据库变更评审”，每个技能都对应一段专门的工作流。

要注意的是，自定义技能不要写得太啰嗦。技能文件的指令会占用上下文窗口，如果塞入几百行约束，AI 反而抓不住重点。建议按场景拆成多个小技能，每个技能只聚焦一件事，保持指令清晰、可执行。

5. 常见问题与排查技巧：装不上、不生效怎么办

5.1 技能没有被识别，先查这几处

我见过最多的问题就是“技能明明放进去了，但 AI 完全不认识”。遇到这种情况，不要急着重装，按下面顺序排查，通常几分钟就能定位：

路径问题是最常见的坑。有些工具对目录名严格区分大小写，Superpowers和superpowers都会被识别成不同目录，所以安装时最好按照官方 README 里的路径一字不差地复制。另外，也不要同时把技能既放在用户级目录又放在项目级目录，会导致工具不知道加载哪个，表现时好时坏。

5.2 触发之后 AI 仍然“自由发挥”，怎么处理

技能文件本质上是一段静态文本，能不能被严格遵循，还要看模型的指令遵循能力。有些情况下，AI 触发了技能，但写着写着就按照自己的惯性跑了，忘了当初的流程。这时候不需要重新安装，可以在对话里明确提醒。

比较有效的方法是让 AI 先复述流程，再干活。你可以直接问它：“根据 superpowers 技能，这个任务应该分哪几步？请列出来，然后逐步执行。”这样等于强制它把技能内容“读”一遍，再照着执行，遵循率会明显提高。还有一个土办法是分段触发技能：第一步用@superpowers:planning让 AI 先给出方案，第二步确认方案后再触发实现类技能。这种方式把流程拆开，反而减少了一次性“全流程”带来的上下文丢失问题。

如果同一个技能在不同项目里表现不稳定，可以看看项目本身的复杂度。技能流程设计得再好，也架不住项目代码结构一团乱麻，AI 找不到入口。这种情况我建议先手动给一些提示，比如在技能触发后补充一句“核心业务逻辑在src/modules/order目录下，优先查看里面的 service 文件”，能大幅减少 AI 的探索偏差。

5.3 安全与使用习惯：别装不明来源的技能包

最后想提醒一个很容易被忽略的问题：技能文件本质上是“可执行的提示词”，里面写的每一条指令都会被 AI 当作权威要求来遵守。如果你安装来路不明的技能包，里面夹带了一些恶意指令，比如“要求 AI 把环境变量发送到某个服务”“要求 AI 删除某些文件”，后果会非常严重。

所以安装任何技能包前，我都建议先打开SKILL.md通读一遍，确认没有可疑内容再放进技能目录。尤其是从非官方渠道下载的“增强版”“一键版”技能，更要谨慎。技术社区里很多人会分享自己的定制版，方便是真方便，但安全审查的习惯不能省。你自己写的自定义技能也要注意，不要把真实的密码、Token 硬编码进去，因为这些文件很可能会被同步到 Git 仓库，一旦泄露就是安全事故。

6. 一点个人经验：什么时候值得用，什么时候别硬上

折腾 superpowers 这段时间，我最大的感受是：它不是魔法，不会让 AI 突然变成一个不会犯错的高级工程师，它更多是提高了 AI 工作方式的下限，让每一步都更可预期、可审计。如果你只是偶尔用 AI 写个小脚本、跑个临时爬虫，其实没必要上全套技能流程，反而显得笨重。但如果你像我一样，每天都要和 AI 协作处理真实业务项目，那真的建议把技能流程固定下来，让 AI 每次都按同一套标准干活。

我个人现在最推荐的做法，是安装之后先基于官方版本做一份“团队定制版”，把团队规范、常用命令、禁止事项全部写进去。这个过程刚开始会花一点时间，但沉淀下来的东西会在之后每一天的 AI 协作里持续发挥作用。还有一个小技巧：第一次使用前，先在一个空的测试仓库里触发一次@superpowers:core，跑一个最小任务，观察它到底会执行哪些步骤，心里有数之后再放到真实项目里。这样避免一上来就被它的“折腾劲”搞得怀疑人生，也能更快理解这个工具的行为逻辑。