企业官网建设流程全解析

1. superpowers到底解决了什么问题

先说结论：如果你已经在用 Codex CLI、Claude Code 这类 AI 编程工具，但总觉得 AI 写代码“脑子跟不上手”——让写就写，改个需求就推倒重来，复杂一点的跨文件改动动不动改崩一片——那 superpowers 就是冲着这个痛点来的。

1.1 为什么普通的“AI 帮我写代码”不够用

我最早用 AI 编程工具的时候，体验大致是：提一个需求，它哗啦啦生成一坨代码，我看着好像挺对，一跑就报错。让它改，它再糊一版。来回几次，代码里已经堆满了补丁式的 if 分支和临时变量，比我自己手写还难维护。为什么？因为大多数 AI 编程工具的本质是“单轮对话驱动的代码生成器”，它没有项目上下文、没有执行计划、没有验证步骤，更没有一个“发现问题后如何收敛”的兜底机制。

你要让它开发一个功能，它不会先问清楚边界条件，不会先考虑现有架构怎么融入，更不会主动写测试来证明自己写的东西是对的。它只是按概率把下一个 token 预测出来，仅此而已。

1.2 superpowers 的工作哲学：技能不是命令，是流程

superpowers 的思路完全不一样。它不是一个“更强的代码生成器”，而是一套**技能包（skills）**体系。每个技能是一个带明确指令的 SKILL.md 文件，定义了某一类工作的完整流程。比如“头脑风暴”技能会引导你先把需求聊透，“写计划”技能会要求它产出一份可执行的分步计划，“TDD”技能会强制它先写测试再写实现。

说白了，它是给 AI 装了一套“工作方法论”。就像你带了一个新人，你不指望他第一次就写出完美代码，但你希望他拿到需求之后知道先问什么、先做什么、怎么验证。superpowers 就是把这套“带人流程”固化成了 AI 能读、能执行、能按顺序调用的指令集。

这套东西最早是 Jesse Vincent（Perl 社区那个 obra）开源的，核心文件就躺在 GitHub 仓库里，全部是 Markdown，没有任何魔法。它支持的也不只是 Codex CLI，Claude Code、Roo Code 这类支持 skills 机制的终端型 AI 工具都能用。最近国内不少人在 Trae Work CN 里折腾怎么挂载这套 skill，说明它已经不局限于某一个工具了。

2. 安装前置条件：给 superpowers 一个能跑的家

说句实话，我见过很多人在装 superpowers 的时候卡住，不是因为项目本身难装，而是前置环境没准备好。它本质上是一包“让 AI 按流程工作”的指令文件，必须寄生在一个支持 skills 机制的 AI 编程工具里。所以第一步不是装 superpowers，而是确认你的“宿主”够不够新。

2.1 Codex CLI 的安装与初始化

如果你走的是官方推荐路线，那宿主就是 Codex CLI。它是 OpenAI 出的命令行编程代理，跑在终端里，能读你的仓库、调你的编辑器、执行命令。装它之前，有几个硬性条件你得先确认：

• Node.js 版本不能太低，建议 18 以上，20 LTS 最稳；
• 本机要有可用的终端环境，Windows 用户建议直接用 Windows Terminal 而不是老旧的 cmd；
• 你得有一个能访问 Codex 服务的账号，并且完成 CLI 登录。

安装命令很简单，一行搞定：

npm install -g @openai/codex

装完以后先跑一下：

codex --version

能输出版本号，宿主就位了。然后进行初始化登录：

codex login

它会拉起浏览器，完成 OAuth 授权。这块要注意，登录成功以后，Codex CLI 会把这个会话信息存在本机配置里，后续用的时候不要反复登出登入，否则容易触发风控。

2.2 验证运行环境与模型配置

环境装好之后，别急着装 superpowers，先随便提一个简单问题验证整个链路通不通：

codex "用 python 写一个阶乘函数"

它能正常回复，说明网络、认证、模型调用这些底层环节都是好的。如果这一步就挂了，得先排查代理、网络策略或者账号权限，因为大概率不是 superpowers 的问题。

还有一点，Codex CLI 支持通过配置文件指定模型。不同型号的模型对复杂指令的执行能力差异非常大，我建议至少用 Codex 系列里偏强的那档模型，便宜的老模型在跑多步骤 skill 流程时经常“中途失忆”——前面让它做的计划，写到后面就忘了。

3. 安装 superpowers 的完整步骤

前置环境没问题之后，安装 superpowers 本身其实很快。官方仓库里有两种装法：一键脚本和手动 clone。两条路我都走过，分别说下适用场景。

3.1 官方一键脚本安装

官方推荐的方式是直接跑安装脚本：

curl -sSL https://install.superpowers.dev | bash

执行完这个脚本，它会把整个技能包下载到你用户目录下的~/.superpowers文件夹里。这个文件夹里装的是所有技能的定义文件，以及配套的 agent 定义、工作流模板。装完之后脚本一般会提示你，下一步需要去~/.codex/config.toml里确认相关配置有没有被自动写入。

这个方式最省心，适合第一次装、不想跟文件结构较劲的人。脚本会做几件事：拉取最新仓库、把 skills 目录放到约定位置、在 Codex 配置里注册技能路径。整个过程一两分钟，失败率很低。

3.2 手动 clone 方式的适用场景与目录结构

如果你是想改技能包源码、甚至自己往里面加技能的进阶玩家，建议手动 clone：

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

手动装的话，你需要自己处理两件事：一是把技能目录告诉 Codex CLI，二是确认 Codex 的 skills 开关是开着的。打开~/.codex/config.toml，里面至少要有类似这样的内容：

[skills] enabled = true superpowers_path = "~/.superpowers/skills"

这里有一个我在社区里反复看到的问题：很多人手动 clone 之后忘了改superpowers_path，导致 Codex 一直报“找不到 skills 目录”。如果你也是手动装的，装完第一件事就是打开配置文件看一眼路径对不对。

3.3 在 Trae Work CN 中挂载 skills 的注意事项

最近不少人在搜 Trae Work CN 安装 superpowers skill，这块我也顺手测过。Trae Work CN 本身支持 skills 机制，但它的技能目录和 Codex 不在一起。你需要把~/.superpowers/skills里的技能文件，复制或者软链到 Trae 的 skills 目录下。

我建议用软链而不是复制，原因很简单：superpowers 这个仓库更新很勤，作者会经常调技能的提示词和流程，你用软链的话，每次git pull之后 Trae 里自动就是最新版；复制的话，每次更新完你还得手动再拷一遍，极易遗忘。具体软链命令在 macOS/Linux 下是：

ln -s ~/.superpowers/skills /path/to/trae/skills/superpowers

Windows 下没有直接等价命令，可以右键目录创建符号链接，或者干脆复制一份，毕竟你是手动更新仓库的话，多复制一份也没多大事。

4. 核心技能包拆解：每个技能都在什么时候派上用场

装好只是开始，真正需要花时间的，是理解这套技能包在设计上是怎么分层的。很多人装完只会用“让它写代码”这一个对话入口，那和没装区别不大。

4.1 brainstorm 与 planning：开工前的两次深呼吸

superpowers 流程里最容易被跳过、但恰恰最值钱的两个技能，就是 brainstorm（头脑风暴）和 writing-plans（写计划）。

我见过太多人——包括以前的我——让 AI 干活的时候上来就是一句“帮我实现一个 XX 功能”，然后 AI 直接开写。问题是什么？需求里的歧义太多了。“用户登录”这四个字在不同项目里含义完全不同：是 JWT 还是 Session？刷新逻辑要不要？第三方 OAuth 接不接？错误提示做到什么程度？AI 一旦在模糊需求下开写，后续的返工基本是注定的。

superpowers 的 brainstorm 技能强制 AI 在动手前先做一个“需求澄清会话”：它会主动向你提问，把边界条件、约束、异常场景都问清楚，甚至会把几个可能方向摆出来让你选。你会发现一个神奇的变化：AI 从“你说一句它写一坨”变成了“你说一句它问三句”。这不是它变聪明了，而是技能文件里就是这么写的——它必须走完这个对话流程，才能进入下一步。

等需求聊透了，再调用 writing-plans 技能，让 AI 把整个实现过程拆成分步计划，每一步包含文件路径、改动内容、验证方式。这一步的作用是强制 AI 在动手前把整个地图画完，而不是走一步看一步。我实测下来，这个计划文件简直是无价之宝——后面执行出任何问题，你都可以回头对着计划看是哪一步跑偏了。

4.2 TDD 与 subagent-driven-development：让 AI“自己检查作业”

计划写完，进入执行阶段。superpowers 在这里的设计尤为激进：它默认的工作流是先写测试，再写实现。这其实就是 TDD（测试驱动开发）的工程实践，被固化成了技能指令。

TDD 技能会要求 AI 针对计划里的每个功能点，先写出失败用例，然后跑一次测试确认用例确实是失败的（这叫“验证测试的有效性”），再写实现代码直到测试通过。这一套流程人为跑都觉得麻烦，让 AI 跑反而成了优势——它不嫌烦，它只是以前没人要求它这么干。

subagent-driven-development 就更进一步了：它会让主导的 AI agent 把具体开发任务拆给子 agent 去做，每个子 agent 只负责一个文件或一个模块的改动，主导 agent 负责审查和集成。这就像项目经理把活分给不同工程师，每个人提交代码后，项目经理做 Code Review 再合并。好处是：每个子 agent 的上下文窗口都很干净，不会被整个项目的无关文件干扰；主导 agent 又能保持全局视角，防止各个子 agent 的改动互相打架。

4.3 troubleshooting 与 pre-flight：出问题时的兜底机制

写代码不可能不报错。superpowers 里专门有 troubleshooting（故障排查）技能，定义了 AI 面对报错时的一整套排查流程：先复现、再定位、查日志、缩小范围、验证修复、回归测试。它相当于强制 AI 用“结构化排障法”而不是“瞎猜法”来工作。

pre-flight 技能则是提交代码前的最后检查。它会要求 AI 站在“马上就要发布”的角度审视改动：有没有没删掉的调试代码？有没有硬编码的敏感信息？测试覆盖了哪些分支？配置文件改对了没？这些检查项不是靠 AI 的“责任心”，而是靠技能文件里写死的流程一步步执行出来的。

我个人的感受是，troubleshooting 和 pre-flight 这两个技能，单拎出来任何一个都值得长期使用。因为人类工程师最容易在一天高强度工作后犯低级错误，而 AI 是从来不累的，让它做机械式的逐项检查，反而是它最擅长的事。

5. 从“装了”到“会用”：一种更高效的协作模式

技能包备齐之后，真正的问题在于你的工作习惯能不能跟得上。很多人装完之后依然是“需求一句话、代码一大片”的用法，那就等于买了个工具箱但只用螺丝刀捅人。我下面用一个完整的功能开发流程，演示一下正确姿势长什么样。

5.1 会话启动时如何召唤技能

superpowers 的技能调用有两种方式：一种是你直接在对话里点名，比如：

请使用 brainstorm 技能，和我一起理清这个需求的细节。

另一种是它根据你的描述自动匹配技能。不同版本的 Codex CLI 对自动调用的策略不太一样，早期版本是偏自动的，后来版本慢慢改成偏保守，宁可不调也不乱调。所以最稳的方式，还是你在会话里主动指示它调用哪个技能。

有几个高频启动话术你可以直接拿去用：

• “用 brainstorm 技能，我们先把需求聊透。”
• “整理一份实施计划，用 writing-plans 技能。”
• “按 TDD 流程实现这个功能，先写测试。”
• “跑一下 pre-flight，检查这次改动有没有问题。”

这里有个技巧：你不需要一次只调一个技能。官方设计的完整流程是 brainstorm → writing-plans → TDD → subagent-driven-development → pre-flight。你可以在一开始就说“请按标准流程处理这个需求”，它会自动走完整个技能链。

5.2 一次完整功能开发的对话流拆解

我拿一个真实场景举例：给我的博客系统加一个“文章浏览量统计”功能。

第一轮，我输入：

用 brainstorm 技能，我要给博客加一个浏览量统计功能。

它会开始提问一系列问题：“浏览量是每个用户访问都加一，还是需要去重？”“需不需要展示热门文章排行？”“统计维度是只按文章维度，还是按天归档？”“要不要做防刷限制？”

这一轮对话结束，一个模糊的需求已经变成了可执行的规约。

第二轮，我输入：

计划没问题，用 writing-plans 技能生成实施计划。

它会产出类似这样的分步计划：

• 新增views.py，定义浏览量记录的模型；
• 新增views_middleware.py，在每次文章详情请求时触发计数；
• 编写test_views.py，覆盖正常访问、重复访问、并发访问三个场景；
• 修改详情页模板，展示浏览量；
• 运行全量测试，确保旧功能不受影响。

第三轮，我输入：

按这个计划，用 TDD 流程实现。

它就会先去写测试用例，跑失败，再实现逻辑，再跑测试直到通过，整个过程它会自己循环，不需要你每一步都催。

第四轮，功能跑通了，我再输入：

run pre-flight

它会对整个改动做收尾检查：确认没有把测试文件里的临时数据写进数据库、确认没有硬编码用户 ID、确认接口没有暴露不必要的信息。

你会发现，整个流程里我作为一个“甲方”，只干了提需求和做决策两件事，剩下全部由技能流程驱动。这才是这套东西真正值钱的地方——它让 AI 从“写代码工具”进化成了“带流程的开发者”。

5.3 什么情况下不需要用 superpowers

但我也得说句公道话：不是所有场景都适合上全套技能。

一个典型例子是：你只是想改一个按钮的颜色、调一个 CSS 间距、或者加一个文案。这种平凡改动如果也走 brainstorm → plan → TDD 的完整流程，纯属杀鸡用牛刀。你光等它问完那一堆需求问题，自己手动改都已经改完了。

正确做法是：小改动直接普通对话让它改，改完自己肉眼验证一下；只有涉及多个文件、有业务逻辑、需要长期维护的功能开发，才启动完整技能链。这样安排，你是用它的方法论管住复杂项目，而不是让简单任务被流程拖死。

6. 安装与使用中频繁踩坑的排查记录

每次有新工具出来，社区里最常见的声音就是“装完了不好用”“为什么我的不行”。我在各个群里观察了很久，superpowers 的“翻车”案例基本逃不出下面几类。我把它们按出现频率排个序，你对照排查，能省下半天时间。

6.1 模型能力不足导致技能“失效”

最隐蔽也最坑的一种，就是表面上看技能都装了、也都调用了，但输出质量非常差：计划写得很空洞，测试用例没有覆盖关键分支，改着改着把前面的计划忘了。

根源基本都在模型选择上。superpowers 的技能文件本质是“高负载的上下文指令”，它对模型的指令遵循能力和长上下文保持能力要求很高。如果你用的模型偏弱，它读得懂“要写计划”这句话，但执行起来就像实习生背了流程却不知道每个环节该怎么深挖。

我的建议很直接：这类场景别心疼钱，用你账号里能调用的最强模型。一次复杂功能开发的 token 消耗，相比它帮你省下的返工时间，完全不值一提。

6.2 skill 文件未被识别时先查会话开关与版本

这种情况的表现是：你明确说了“用 brainstorm 技能”，但它完全无视你的指令，或者回复“我现在无法使用这个技能”。

排查链路其实很短，按这三步走基本能定位：

第一步，确认宿主工具的 skills 功能是开着的。Codex CLI 在某一段较新的版本里默认关闭了自动技能调用，你需要去config.toml里确认配置没问题；

第二步，确认 superpowers 的技能目录能被找到。手动安装最容易在这里踩坑——路径写错、没有权限、目录名不对，都会导致加载失败；

第三步，确认你的 Codex CLI 版本够新。技能机制本身也在迭代，旧版本可能根本不认识这些新目录结构。如果你已经用了一两个月没升级，先更新再说：

npm update -g @openai/codex

这套排查顺序，是“先看配置、再看路径、最后看版本”，不要一上来就怀疑技能包坏了。superpowers 仓库本身维护很活跃，真有重大 bug 半天之内就会被社区喷爆，不太可能是它的锅。

6.3 与 AGENTS.md、MCP 共存时的优先级混乱

还有一个进阶坑。很多人不是裸用 Codex CLI，仓库里既有 AGENTS.md（项目级 AI 指令文件），又配了 MCP 服务，还装了超多个 skills。这几个信息来源如果不一致，AI 就会陷入“到底听谁的”的混乱。

我遇到过的情况是：项目 AGENTS.md 里写了“所有文件改动必须附带变更日志”，但 superpowers 的执行计划里没有这一步，结果 AI 在走完技能流程后压根没更新日志，被 CI 流程拦下来。问题看起来像是 superpowers 不听话，实际上是 AGENTS.md 和技能流程之间缺少一个“统一指令口”。

我的解法是：在 AGENTS.md 里显式写一条“所有工作必须遵循 superpowers 工作流”，然后在技能调用时再口头强调项目的特殊要求，比如“执行计划里加上变更日志更新步骤”。相当于在两层指令之间搭一座桥，AI 就不会精神分裂了。

7. 关于 superpowers 使用边界的一些个人体会

写到这，我想说点纯主观的东西。

superpowers 不是万能药，它改变不了模型的智力上限。模型本身不够强，再好的技能流程也只是“把烂活干得更有条理”而已。但反过来讲，模型能力到位之后，决定 AI 产出质量上限的，反而就是这个流程框架了。这就像一支球队，球员个人能力再强，没有战术体系，场上还是踢成一盘散沙。

我用了几个月，最大的感受是：它改变了我对“用 AI 写代码”这件事的预期。以前我觉得 AI 是个“高级自动补全”，它更多地像一个插上流程就靠谱的初级工程师。你不需要永远盯着它看，但它每一步干了什么、下一步打算干什么，你随时都能打开计划文件看清楚。这种可追踪性带来的安心感，比它偶尔写出一段惊艳代码更值得。

如果你现在还在“AI 写代码一时爽，上线之前火葬场”的循环里，真心建议把这套技能包装上，耐着性子走完一个完整流程试试。前面可能会觉得对话轮数变多了、效率变慢了，但等它把一套复杂功能稳稳当当跑通、测试全绿的时候，你会发现——之前的“快”，都是假快。