企业官网建设流程全解析

先说个现象：我把 codex 这类终端里的 AI 编程工具当成主力辅助之后，最大的感受不是"它不会写代码"，而是"它经常想都不想就开始写"。你丢给它一个需求，它啪地给出一大段自以为是的实现，碰到边界又不改，最后绕了个大圈子。直到我在 GitHub 上翻到superpowers这个项目，才发现问题不在模型能力，在于——我们根本没给 AI 一套"先思考、再动手"的工作流程。

这篇东西不是项目说明书，是我自己从装到用、从踩坑到沉淀的一手记录。主要围绕三件事：superpowers到底是什么、怎么装、装上之后怎么让自己的工作流真正受益。如果你已经在用 Codex CLI 这类工具，或者在想为什么别人用 AI 写代码像开了挂而自己却频繁翻车，这篇应该对你有用。而且我还会把最新折腾出来的 Trae 接入方案放在后面，尽量把从codex cli 安装 superpowers到superpowers skill的使用链路一次性说清楚。

1. AI 编码助手为什么"时而聪明时而智障"——superpowers 要解决的痛点

我相信不只是我一个人有这种体验：同一个模型，在网页版对话里表现得像个资深架构师，但一放进终端里干活，就变成一个"催一推动一动"的初级程序员。代码照写，测试照补，可只要需求描述稍微含糊一点，它就开始自由发挥，方向跑偏了还能嘴硬。

1.1 从"一问一答"到"带流程干活"的差距

根源在于大部分 AI 编程工具把"回答问题"当成了核心任务，而不是把"完成一个工程目标"当成核心任务。两者看似差不多，实际区别大了。

你问它"帮我实现一个用户登录功能"，它给你 100 行代码——这是回答问题。但真实工程里，这个需求背后应该有一连串追问：登录是用 Session 还是 JWT？密码重置走邮件还是短信？失败次数要不要限制？前端需不需要接入第三方登录？接口鉴权怎么设计？这些问题如果没人提，AI 不会主动想，它就照着一个"最普通的登录功能"给你写出来，而你真正要的可能是一个带审计、带多因素认证、带设备管理的高级登录体系。

superpowers解决的就是这个问题。它给 AI 装上了一套"职业习惯"：面对需求先拆解、再质疑、再规划、再动手，而不是上来就撸代码。我用了大概两周之后回看，才意识到以前那堆"智障时刻"，绝大多数不是模型笨，是 prompt 里缺少一套强制思考的流程。

1.2 superpowers 到底是个什么东西

superpowers本质上是给 AI 编码工具准备的一组"技能包"（skills）。它在 GitHub 上开源，通过给 Codex CLI 这类工具注入额外的系统指令和工作流定义，让 AI 在特定场景下按照预设的流程来工作。

可以这样理解：原生的 Codex CLI 像个刚毕业的应届生——基础知识扎实，但没经过正规军训练，接到活儿就凭直觉干。装上superpowers，相当于给这个应届生报了个职业培训班：需求分析课、架构设计课、代码审查课、调试方法论课，一门门安排好，它在什么时候该调用哪套技能，全部有章可循。

这个项目最核心的三个关键词：

• Skills：一系列 markdown 格式的技能定义文件，每个文件规定了一种工作流，比如头脑风暴（brainstorm）、方案设计（plan）、代码审查（review）等。AI 在对话里被触发到某个场景时，会调用对应的技能流程。
• 流程化思考：技能文件里不只是写"你要好好思考"，而是写明了具体的思考步骤、要输出的内容格式、要提的问题清单。这让 AI 的"思考"变成可预期的、结构化的过程。
• CLI 深度集成：直接在终端环境里通过 codex 命令加载，不依赖 IDE，所以对只用终端的开发者特别友好，同时也给后续接入其他工具留了空间。

我最初以为这只是一个 prompt 合集，后来翻源码才发现，它在每个 skill 里做了很细的分工——有的技能负责"在动手前帮忙把需求搞清楚"，有的负责任务拆解，有的负责查漏补缺，各自的触发条件和执行流程都是独立定义的。这套设计让"AI 的工作方式"变得可控，而不只是让回答变长。

2. 安装前的准备：Codex CLI 版本、Node 环境和认证

先别急着复制粘贴命令，我在这步已经见过太多人翻车。superpowers不是独立软件，它依附在 Codex CLI 里面，所以你得先把底座准备好。我建议按下面这个顺序自查，缺哪个补哪个，能省掉后面一大堆莫名其妙的报错。

2.1 环境依赖与版本要求

先说版本问题。superpowers对 Codex CLI 的版本有要求，项目 README 里写的是建议使用较新版本，但我在实际安装中发现，不同小版本之间对 skill 配置文件的加载路径和处理逻辑有差异。最稳妥的方式是装的时候直接装最新版本，不要用系统包管理器里那种几年不更新的老版本。

其次是 Node.js 环境。Codex CLI 本身是 Node 写的，superpowers的安装脚本也要跑在 Node 环境里，所以node和npm都得提前准备好。版本建议 Node 18 以上，太老的版本有些依赖装不上。

另外要注意 Git。安装superpowers需要从 GitHub 拉取仓库，所以你得确保机器上有 Git，而且能正常访问 GitHub 仓库。这块如果平时有代理习惯的，记得把终端代理配好，不然卡在 clone 那一步最痛苦。

我把环境要求整理成了一张表，照着查就行：

提示：如果你之前装过其他给 Codex 加技能/规则的工具，建议先清理掉再装superpowers，不然多个工具同时往 Codex 的配置里写内容，很可能互相覆盖，最后哪个都没生效。

2.2 首次安装的完整命令

环境确认完之后，安装本身其实不复杂。官方推荐的方式是用codex命令配合install superpowers这样的指令，不过当时我在终端里试的时候，发现直接执行codex install不一定能识别到项目。更通用、也更推荐的做法是：

# 1. 先确认 codex 命令和版本 codex --version # 2. 确认 node 版本 node -v # 3. 拉取 superpowers 项目到本地 git clone https://github.com/obra/superpowers.git cd superpowers # 4. 安装依赖 npm install # 5. 执行安装脚本，把 skills 注册进 Codex CLI npm run install:skills

这套流程走完之后，Codex CLI 会多出一个skills目录，里面就是一堆 markdown 文件，也就是超级技能的定义本体。装上之后可以做个快速验证：

codex

然后在会话里输入/help或者直接问一句"what skills do you have"，看 AI 能不能列出技能清单。如果能列出来，说明加载成功。如果它一脸茫然，大概率是配置路径没对上，这个我在后面的踩坑部分会细讲。

注意：不同版本的 Codex CLI 对配置文件路径要求不一样。旧版本读的是~/.codex目录，新版本改成了~/.codex/experimental或者随系统平台变化的目录。装完别急着开心，先用codex --help确认你当前版本的配置目录，再回去看 skill 装哪儿了。

3. 核心技能拆解：superpowers 自带哪些"思维流程"

装好的superpowers不是给你一个开关，装了就变聪明，它其实是给你一组可以随时调用的"方法论"。我在实际使用里慢慢摸清了每个技能适合什么场景，这里分两块来说：先看整体功能地图，再看几个我高频使用的技能的详细打法。

3.1 十多个内置 skills 的功能地图

superpowers的 skills 是模块化的，每个解决一类问题。项目源码里维护了一个类似"技能目录"的索引文件，Codex 在对话中可以动态查询并加载对应技能。我把常用的几个做了个梳理：

除了这些，还有不少围绕敏捷开发、任务管理、系统设计等场景的技能。我这里不逐一点名，因为项目在持续迭代，技能列表一直在扩充，以你本地拉到的最新版为准。重点是想说明一件事：superpowers的设计哲学不是"让 AI 更聪明"，而是"让 AI 在有需要的时候，自动切换到正确的思维框架里面"。

3.2 几个最常用的技能详细用法

Brainstorming（头脑风暴）是我在接到需求时用的第一个技能。以前我拿到一个需求，脑子里就开始想技术方案，选型、架构、数据库，一股脑涌上来。用了这个技能之后，Codex 会先做一件事：把焦点拉回"问题本身"，不断问你"这个功能的真正目标是什么""有没有更简单的替代方案""哪些约束条件是真实存在的"。它输出的不是代码，而是问题清单和方向梳理。

Writing Plans（写计划）是我个人使用频率最高的技能。它负责把需求落地成一份"施工图"：任务拆解、依赖关系、风险点、验证方式、测试策略，一层层写清楚。而且这个技能的输出格式很稳定，方便我直接把计划贴进项目管理工具里复用。实测下来，计划写得越细，后面写代码的返工率越低。

Debugging（调试）有一套让我眼前一亮的方法论。它不会上来让你改这改那碰运气，而是按"收集信息 → 提出假设 → 验证假设 → 定位根因"的闭环来走。尤其适合那种"偶发 bug"，我过去靠打印日志硬怼，现在直接把它丢给这个技能，它会先问我复现步骤、环境差异、最近改动，然后给出一个排查优先级列表，效率提升非常明显。

Code Review（代码审查）适合在提交合并请求之前自我检查。它不只是看语法和风格，更关注有没有潜在的边界问题、异常处理缺失、性能隐患等。我实测过一次：它在我自以为写得很干净的代码里，揪出了一个隐蔽的并发问题，那种细粒度，确实像个高级工程师在 review。

用下来我最大的体会是：技能不是越多越好，而是要懂得在正确的场景里调用正确的技能。有些人装上superpowers之后觉得没啥变化，很大程度上是因为他们从没主动触发过这些技能，一直在用最原始的"问答式"让 AI 干活。

4. 从"装上"到"用明白"：正确使用姿势与实测效果

安装只是第一步，真正让superpowers发挥价值的是使用方式。我在这个项目上反复折腾了一周，从最开始觉得"就这？"到后面熟练掌握，中间的变化完全是使用姿势带来的。这节分享几个核心心法，以及一组实测对比数据。

4.1 核心命令与关键词的正确用法

superpowers的使用方式分「显式触发」和「隐式触发」两种。

显式触发的做法是：在 Codex 会话里直接输入技能名。比如我想让它帮我梳理一个项目方案，我会这样输入：

/skill Writing Plans

或者更自然地用自然语言触发："请使用 Writing Plans 技能，帮我规划一下这个功能的实现步骤。"

这里有个细节值得注意：技能名的匹配不是非要一字不差，Codex 会根据语义自动理解。比如你说"帮我制定一个开发计划"，它也可能主动加载 Writing Plans 技能。但为了稳定，我仍然建议在关键环节明确点名技能，减少 AI 猜错的可能性。

隐式触发则更省心：当对话中出现符合某些技能描述的场景时，Codex 会自动加载对应技能。但自动触发不是 100% 可靠，和模型的上下文理解能力、对话长度都有关系，所以我建议在重要任务上别依赖自动触发，主动点名更靠谱。

经验：如果你的对话已经进行了很久、上下文很长，AI 可能"忘记"自己需要加载某个技能。这时我会先输入/new开一个新会话，然后在第一句话里就把技能名和需求一起抛进去，让 AI 从干干净净的上下文里开始走流程。

4.2 实测对比：同样的需求，装前装后差别在哪

为了验证superpowers的实际效果，我做了一组对比测试。需求描述故意写得模糊："给博客系统加一个标签管理功能。"

没装superpowers时，Codex 的反应是：立刻给出Tag模型、TagController、增删改查接口、前端页面，一口气生成几百行代码。表面看很完整，但你仔细看就会发现：没有考虑已有文章的标签迁移、没有定义标签名的唯一性规则、没有设计标签使用频率统计、也没有考虑标签过多时的性能问题。基础功能能用，但不是一次"有质量的交付"。

装了superpowers后，同样的需求，它没有直接写代码，而是先输出了一连串关键问题：标签是有层级关系还是扁平结构？标签是否关联用户？删除标签时已有文章怎么处理？标签命名规范有没有要求？是否需要标签云展示？

等这些讨论完之后，它才进入 Writing Plans 流程，给出分步实施方案，然后才开始写代码。最后出来的代码结构明显更完整，连数据迁移脚本都备好了。

用表格看更直观：

我不是说superpowers是银弹，但在这个测试里，它确实让 AI 从"快但不稳"变成了"先想清楚再动手"，对于做项目、做产品的人来说，这种稳定性比速度重要得多。

5. 踩坑实录：版本不匹配、上下文爆炸与插件冲突

任何工具都不是装上就岁月静好，superpowers在我实际使用中也踩了好几个坑，有的坑一度让我想卸载。这里把它们记录下来，希望你能绕过。

5.1 问题一：git 版本过低导致安装失败

第一次安装时，我用的是一台老开发机，Git 版本停留在 2.20 左右。执行npm run install:skills时，脚本报错，提示某个依赖需要更高版本的 Git 支持。由于报错信息不够友好，我当时还以为是 Node 版本问题，来回折腾了很久。

后来排查发现，是安装脚本内部使用了 Git 的某些新特性（比如--recurse-submodules的扩展参数），老版本 Git 不支持。解决办法也很简单：升级 Git，或者换一台环境干净的新机器重装。

注意：装superpowers这种从源码拉取的工具，尽量别用系统自带的老版本基础软件，教训就是要优先满足官方推荐的版本要求，不要自己脑补"应该没问题"。

5.2 问题二：上下文过长时"技能丢失"

有一次我在一个很长很长的 Codex 会话里工作，聊了几个小时后突然发现，AI 不再调用技能了，我明确叫出技能名它也没反应，好像完全忘了技能的存在。

后来我理解了原因：Codex 的上下文窗口有限，超长对话会把早期加载的技能定义"挤"出有效上下文，AI 自然就"失忆"了。这不算 bug，是上下文机制导致的必然结果。

解决办法有几种：

• 重要任务单独开新会话，开头就把技能加载进去。
• 用/compact之类的方式压缩历史对话，给技能腾出上下文空间。
• 不依赖 AI 自动想起技能，而是把技能名写在关键 prompt 里，比如"使用 Debugging 技能分析以下问题"。

我后来形成了一套自己的习惯：一个大任务拆成几个小阶段，每个阶段开新会话，并在开头明确指定本次要用的技能。这样不但技能稳定生效，每个会话的上下文质量也高很多，AI 输出的专注度完全不一样。

5.3 问题三：与其他 CLI 工具或配置的冲突

Codex CLI 本身是高度可配置的，很多开发者会写自定义的AGENTS.md规则文件，或者加载其他 prompt 增强工具。superpowers装上后，这些规则文件和技能定义之间可能会打架。

我遇到的情况是：我的AGENTS.md里写了一套特定的代码风格要求，而superpowers的 Code Review 技能有自己的质量标准，两者在审查代码时产生了冲突，AI 一会儿按这个标准说，一会儿按那个标准说，输出很不稳定。

解决思路是理清优先级：要么以superpowers的流程为主，把自己的规则文件改造成"配合"它的形态；要么在某些环节禁用部分技能，保留自己的规则。

还有个容易被忽略的点：如果你同时在用 Codex CLI 和trae work cn这类工具，配置文件路径可能会互相影响。我在尝试把superpowers接到 Trae 时，发现 Trae 的 skill 配置目录和 Codex CLI 不是同一个，需要把技能文件复制过去或者建立软链接。所以我后来干脆把技能文件放在一个公共目录，两边都指向它，更新一次两边生效。

6. 进阶玩法：自定义自己的 skill 和接入 Trae

用熟内置技能之后，就可以考虑更进一步了——自己写 skill，以及把它接入到你日常最常用的工具里。这节分享一些我总结出来的实践经验，尤其是 skill 的目录结构和 Trae 接入的做法。

6.1 自定义 skill 的目录结构与编写规范

一个 skill 本质上是 markdown 文件，但superpowers对它的组织方式是有讲究的。以我本地的项目结构为例：

superpowers/ ├── skills/ │ ├── brainstorming/ │ │ ├── SKILL.md │ │ └── examples/ │ ├── writing-plans/ │ │ ├── SKILL.md │ │ └── templates/ │ └── my-custom-skill/ │ ├── SKILL.md │ └── references/

关键就两个点：第一，每个技能有自己的目录，SKILL.md是技能主文件；第二，主文件里要写清楚触发场景、执行步骤、输出格式、参考示例。

我自己写了一个"数据库迁移评审"的 skill，目录大概是这样的：

# Database Migration Review ## Description 用于评审数据库迁移脚本，检查索引、锁表、数据一致性等风险。 ## When to Use - 提交迁移脚本前 - 大表结构变更时 ## Steps 1. 检查迁移脚本是否包含索引优化 2. 检查是否存在长时间锁表风险 3. 检查数据回滚方案 4. 输出评审结果表 ## Output Format | 风险点 | 等级 | 建议 | | --- | --- | --- |

定义好之后，Codex 就能在对话里识别到并调用它。重点：Description 一定要写得清楚，因为 AI 是根据描述来判断何时触发这个技能的。如果描述太含糊，它很容易把技能用在错误场景。

6.2 在 Trae 中接入 superpowers 的思路

关于 Trae 的接入，我看到很多人在搜，说明大家都有类似需求。不过要说清楚：trae work cn默认不会读 Codex CLI 的技能配置，你需要手动把 skill 文件放入 Trae 的提示词/技能目录。

我在实践中的做法是：

1. 先找到 Trae 的技能目录或自定义规则目录，一般在用户配置目录下。
2. 把superpowers里skills/下的技能文件复制过去，或者用软链接指向同一份文件。
3. 在 Trae 的自定义指令里，添加一句"请参考以下技能定义，并在合适场景下使用"。

这样接入之后，Trae 里的 AI 也能获得类似的"流程化思考"能力。但我得诚实说一句：Trae 的上下文组织方式和 Codex CLI 不完全一样，技能的触发稳定性和在 Codex 里比起来还是有差距的。如果做重要项目，我更倾向回到 Codex CLI 里用；日常顺手的小任务，Trae 里能用上一部分技能就够了。

自定义 skill 是最容易上头的部分，因为一旦跑通，你会发现 AI 的"职业习惯"完全由你定义，它能主动按你的团队规范、编码标准、流程偏好去干活，比任何通用 prompt 都贴合实际场景。

7. 最后说几句实在的

superpowers这个项目我前前后后用了快一个月，最大的感受是：它不是在炫技术，而是在补 AI 编程工具最关键的一块短板——把"会思考"变成"必须思考"。装上之后，AI 从"抢答选手"变成了"先举手的选手"，代码质量提升了，返工少了，连带着我自己的项目规划习惯都变得更严谨了。

当然，它也有学习成本：你得记住哪些场景该触发哪个技能，得和 AI 磨合出一套适合自己的沟通节奏，甚至得学会调整自己的提问方式。它的定位不是傻瓜式的"一键变强"，它是一套需要你参与其中的工作流框架，投入多少，回报就多少。

安装上有问题的，优先去 GitHub 仓库看 README；使用上有疑问的，多在会话里试几个技能对比输出效果；被坑了也别急着卸载，往往只是使用姿势问题。我的建议很简单：先装上，花一两天时间把常用技能全部触发一遍，感受一下"有流程的 AI"和"没流程的 AI"之间的差距，你会回来感谢我的。