企业官网建设流程全解析

前阵子我被 Codex CLI 搞到差点崩溃：让它给项目加一个导出功能，它闷头改了 17 个文件，顺手把我原来的分页逻辑整个重构了一遍。代码能跑，但 code review 的时候我看着那几百行 diff 真的非常痛苦。后来同事甩给我一个 GitHub 链接，名字就叫 superpowers。说实话，第一眼看到这名字觉得有点中二，但抱着死马当活马医的心态装好后试了一周，真香。

superpowers 不是一个具体函数库，也不是传统意义上的插件，而是一套给 AI 编程代理用的 skills 技能集。它解决的是很多 AI 代理最让人头疼的问题：模型知道怎么写代码，但不知道什么叫好好干活。这篇文章我会从实际使用者的角度，讲清楚 superpowers 到底是什么、怎么在 Codex CLI 里装、里面几个核心技能是怎么约束代理的、怎么把它迁移到 Trae Work CN 这类平台，以及我踩过的几个坑。

1. 初见 superpowers：它到底给 Codex 加了什么 buff

1.1 为什么我觉得 AI 编程代理“缺根弦”

我一开始用 Codex CLI 的时候，心态和很多朋友一样：觉得它就是个加强版自动补全，丢一个任务进去，它把代码改完，我 review 一下就完事。结果用了两天我就发现问题了——模型确实聪明，但它完全没有“工程习惯”。

打个比方，AI 编程代理就像一个刚毕业、能力很强但没进过正规团队的程序员：你让他加一个字段，他恨不得把整个数据库结构、接口层、页面样式全改一遍；你让他修一个 bug，他上来就在你觉得最可疑的地方贴一段新逻辑，根本不做最小复现，也不确认是不是真正的问题点。这种“能干但不会干活”的状态，用久了真的会让人血压升高。

后来我意识到，这其实不是模型能力的问题，而是缺少一套“操作守则”。模型不是不懂代码，而是不知道该在什么时候做什么事。它需要有人告诉它：接到需求先拆任务，改代码前先写测试，出问题先定位根因。superpowers 干的就是这件事——把资深工程师的隐性工作习惯，变成一段段模型能读、能照做的显性指令。

1.2 superpowers 仓库里装的是什么

superpowers 本质是一个 GitHub 上的开源项目，你搜“superpowers github”就能找到。这个仓库里装的是一堆 skills，也就是技能包。每个技能包通常是一个目录，里面包含一个 SKILL.md 主文件，可能还有示例、模板、辅助脚本。模型在会话中读到这些文件后，会被要求按照里面定义的流程来做事情。

我从最开始用的版本里挑几个典型技能出来，你会发现都是正常开发者最需要的东西：planning，负责任务拆解和实施计划；test-driven-development，强制先写测试再写实现；debugging，引导代理用可复现、可验证的方式排查问题；code-review，让模型在做完改动后以审查者视角重新看一遍代码；甚至还有 memlog 这种东西，用来维护项目决策记录。

这些技能不是普通的编程教程文档，而是给模型看的“行为规范”。比如 SKILL.md 里会写明：当用户提出需求时，你不能立刻写代码，必须先把需求拆成步骤，明确每个步骤的输入输出和完成标准，等用户确认后再动手。模型读到这些规则后，输出的行为模式会明显不一样。

1.3 它跟普通提示词模板的区别

可能有朋友会说：这种规则我自己写在 AGENTS.md 里不也一样吗？说实话，单看某一条规则，确实没有本质差别。superpowers 的价值在于“系统化”和“可组合”。它不是一句“你要先做计划”，而是把计划流程、验收标准、异常情况处理都写成一套完整协议。技能之间还能互相调用，比如调试的时候如果发现需要新功能，它会主动告诉你要不要进入 TDD 流程。

另外，社区维护也是它比个人提示词强的地方。模型的版本在变，API 的行为在变，提示词也得跟着变。普通开发者很难持续跟踪这些变化，而 superpowers 这类项目会定期更新技能定义，跟着模型迭代做调整。你只需要拉最新代码，就能保持规则的可用性。

2. 在 Codex CLI 里安装 superpowers 的实操流程

2.1 安装前的环境检查

网上搜“codex cli 安装 superpowers”，出来的教程很碎，有的说一条命令搞定，有的说要改一堆配置。我这里给你一套我实际跑通且验证过的流程，至少在我当前用的环境下是可靠的。

先做三样准备：一个已经登录好的 Codex CLI，一个能正常使用的 Node.js 环境，还有一个 git。检查命令很简单：

codex --version codex login node --version git --version

Codex 版本不同，技能加载的路径会有细微差别，但大部分版本都支持本地技能目录。模型方面，我建议至少用指令跟随能力比较强的模型，不然技能文件再多也白搭。我自己测试的时候用过 GPT-5 模型和 Claude 系列模型，superpowers 都能正常加载，只是不同模型的遵守程度会有差异，这个后面细说。

2.2 clone 技能仓库与目录放置

我把 superpowers 仓库 clone 到了 Codex 的用户级技能目录，这样所有项目都能用，不用每个项目都复制一遍。命令大致是这样的：

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

注意这里的仓库地址要以你实际找到的页面为准，GitHub 上同名的仓库和 fork 不少，直接照抄别人的地址很容易装错版本。我的建议是点进仓库后先看 README，确认它确实是你要的那个 skills 集合，再复制地址。

放在~/.codex/skills目录下还有一个好处：后续更新方便，直接在目录里执行git pull就能同步最新技能。如果你只想在单个项目里试验，也可以 clone 到项目目录里，但要记得把项目目录加入 Codex 的搜索范围，否则技能永远不生效。

2.3 让 Codex 识别技能的关键配置

只把仓库 clone 下来是不够的，很多教程在这里就结束了，导致大家装完发现没效果。关键是要让 Codex 在每次会话中知道去哪里找技能，并且知道什么时候该读这些文件。

我用了两种方式，组合起来效果最稳。第一种是全局配置：在~/.codex/config.toml里添加技能路径的注册信息。不同版本的配置项名称不一样，新版本可能直接支持skills_path，老版本需要在环境变量或配置里手动指定路径。这一行写好后，Codex 启动时就会把对应的技能目录纳入扫描范围。

第二种是项目级引用：在项目根目录的AGENTS.md里写一句明确指令，比如“在开始任何任务之前，请阅读~/.codex/skills/superpowers/下的核心规划技能，并严格按照其中的流程执行”。因为 Codex 每次会话都会自动加载项目根目录的AGENTS.md，这相当于把 superpowers 的核心规则固定在了每次对话中。

如果你只想写一行配置，那就写 AGENTS.md 引用，它比纯目录扫描更可靠。模型不一定每次都会主动去翻技能目录，但 AGENTS.md 是每次会话必然进入上下文的，触发优先级高很多。

2.4 安装验证：一个最小测试用例

安装完先别急着干大活，用一个小任务验证一下。我在验证时用的方法是让 Codex“给项目写一个 README”。如果 superpowers 加载成功，它不会上来就生成一段漂亮的 markdown，而是会先输出自己的任务理解，列出 README 需要包含哪些模块，然后问我有没有补充需求。它会先做“计划动作”，而不是直接“执行动作”。

另一个更直接的验证方法是问模型：“你当前加载了哪些技能？”如果它能说出来 planning、TDD、debugging 这些名字，说明技能文件已经进上下文了。如果它一头雾水，大概率是路径配置不对，或者 AGENTS.md 里的触发词不够明确。这时候我会回退到 2.3 里两种方式，逐一排查是目录没注册成功，还是引用文件里的表述被模型忽略了。

3. 拆开看几个核心技能：planning、TDD、debug 到底怎么工作

3.1 planning：让 AI 先写作战计划

在 superpowers 的所有技能里，我用的最多、收益最明显的应该是 planning。原因很简单：AI 编程代理最大的问题不是写不出代码，而是“写得太快”。你刚把需求描述完，它代码已经生成了一大半，结果方向错了，后面全是白干。

planning 技能会把“写代码”这个动作强行往后推。它的执行流程大概是：第一步，解析需求，把模糊的表述转化成明确的问题清单；第二步，定义边界，哪些做、哪些不做；第三步，把任务拆成足够小的实施单元；第四步，识别每个单元的风险和依赖；第五步，输出完整的实施计划，等用户确认后再开始写代码。

这套流程对我的帮助很大。拿之前的导出功能举例，如果没装 superpowers，Codex 第一版代码大概率是按 CSV 格式直接做的。但装了 planning 之后，它会在动手前问我：导出格式是 CSV 还是 Excel？数据量大概多少？是否需要筛选权限？这些问题问完，需求边界清楚得我都开始怀疑自己是不是漏了什么。整个过程看起来多了几次交互，但实际省掉的返工远远超过那点会话成本。

3.2 TDD 技能：从红到绿的约束

TDD 的基本思路一句话就能说清：先写一个会失败的测试，再写让它通过的最小实现。对真人开发者来说这需要自律，对模型来说则需要指令约束。superpowers 里的 TDD 技能，本质上就是把这条流程固化成了不可跳过的检查点。

为什么这件事对 AI 编程特别重要？因为模型生成的代码最容易出现的情况就是“看起来对，但没有任何验证”。代码风格像模像样，接口也调用了，但一旦跑起来就崩。TDD 技能强制模型在实现前先执行测试，看到失败输出后，再写满足测试的代码，最后看到测试通过才算完成。这相当于给模型的输出加了一道“必须有证据”的闸门。

我在实际使用中会特意观察 Codex 有没有跳过红灯阶段。如果它直接开始写实现，而没有任何测试先行的动作，我会打断它，让它重新按流程跑。多纠正几次后，模型会逐渐习惯这个顺序。你甚至可以把这个技能和 planning 组合起来，让模型在计划阶段就把测试用例设计清楚。

3.3 debugging 和 code review：查错与把关

除了开发阶段的规划和控制，superpowers 里的调试和审查技能也很实用。debugging 技能的核心是让模型停止“猜答案”。它会要求模型先复现 bug，再通过日志、断言或最小样例定位问题范围，然后用二分法缩小候选原因，最后基于证据给出修复方案，而不是凭直觉甩一段代码。

这个流程和我平时教新人的思路几乎一样。模型本身对代码库有很强的全局理解，但它经常高估自己找到根因的能力。debugging 技能本质上是在给模型的“直觉”加上约束，让它每一步都有可复现的输出，这样即使一开始方向错了，也能通过证据快速纠偏。

code-review 技能则适合在改动完成之后触发。我一般会在 Codex 完成一版功能后，单独让它切换到审查者模式，重新拉一遍 diff，从正确性、安全性、可维护性三个角度挑毛病。很多时候它会发现自己前面实现里没处理好的边界条件，或者指出某个函数命名和现有代码风格不一致。这个技能不需要全程开启，手动触发反而更灵活。

3.4 这些技能背后的设计逻辑

把 planning、TDD、debugging、code-review 放在一起看，你会发现它们有一个共同的内核：把资深工程师的工作习惯，编码成模型可以遵循的最小流程。模型不具备“常识”，但它擅长模式匹配。只要你在流程里定义了“先做什么、后做什么、什么算完成”，它就会比散装提示词稳定得多。

这也是 superpowers 这个命名真正贴切的地方。它并不是给了模型更强的推理能力，而是给了模型一套“老工程师附体”的操作协议。模型还是那个模型，但行为表现完全不同。从这个角度看，它更像一个行为框架，而不是技术库。

4. 把 superpowers 迁移到 Trae Work CN 和其他平台

4.1 并不是只有 Codex 能用技能

每次我聊 superpowers，都会有人问：“我只用 Trae Work CN，能不能装？”我的回答是能，而且很多主流工具都能装，只是叫法不一样。Cursor 里叫 rules，Trae 里可能叫项目规则或技能目录，Claude Code 里有专门的 skills 机制。不管叫什么，底层逻辑都是把一段结构化的指令注入到模型上下文中，影响模型的后续行为。

所以 superpowers 虽然最初我是在 Codex CLI 里装的，但它本质上是一堆 markdown 文件，天然具备跨平台迁移的可能。只要目标平台支持某种形式的角色设定或项目规则，你就能把对应的技能内容“贴”进去，或者通过引用文件的方式加载。

4.2 迁移步骤：复制、引用、调整触发

以 Trae Work CN 为例，我的做法分三步。第一步，把 superpowers 仓库 clone 到本地一个固定目录，比如~/superpowers，方便后续更新。第二步，在 Trae 项目里找到项目规则目录，新建一个规则文件，把核心技能的 SKILL.md 内容复制进去，或者直接写一行“读取~/superpowers/planning/SKILL.md并严格遵守”。第三步，调整触发方式：CLI 工具适合自动加载，IDE 工具则建议按需启用，避免每次对话都塞一大堆内容。

特别提醒一下，IDE 类工具有上下文窗口压力，直接把整个 superpowers 仓库几十个技能全部加进去并不明智。我自己的经验是，只迁移最核心的三个技能：planning、TDD、debugging。其他技能作为备用文档放在目录里，等需要时再手动让模型读取，这样既保证核心行为可控，又不会挤占宝贵的上下文空间。

4.3 平台间的行为差异与兼容处理

不同平台对技能文件的读取方式差异比我想象中大。在 Codex CLI 里，写在 AGENTS.md 中的指令几乎每次都会被认真对待；但在 Trae Work CN 里，如果只是把规则放在项目描述文件里，模型不一定每次都会主动读取。我后来把它放进项目规则并开启了“每次对话都读取”的选项，效果才和 Codex 下接近。

还有一个容易被忽略的坑：编辑器在保存文件时可能自动转换格式。superpowers 的 SKILL.md 里有不少代码块和 shell 命令示例，如果用带格式的编辑器保存成富文本，模型读取后可能会看到一堆渲染标记，导致技能不生效。我的解决办法是统一用纯文本方式编辑这些规则文件，保持原始 markdown 结构，别让 IDE 自作聪明地改格式。

5. 用了两周后的真实体感、坑和我的取舍

5.1 最明显的收益：上下文质量和返工率

连续用了大概两周后，我对 superpowers 的态度已经从“试试看”变成了“离不开”。最明显的变化是 Codex 的输出不再像一段孤立的代码，而更像一个工程方案。它会在动手前给出任务拆解，会主动提及风险点，甚至会提醒我哪些改动可能影响现有模块。虽然多了一层确认交互，但整体返工次数大幅下降。

之前最消耗耐心的事情就是看它生成大段无关 diff。装了 planning 和 TDD 之后，这类情况减少了很多。模型知道在什么节点该做什么事，也知道“完成”的定义是什么。它不再为了追求速度而跳过验证，至少在我的项目里，代码质量提升了一个档次。

5.2 踩过的坑：上下文膨胀与技能冲突

但superpowers也不是完全没有代价。第一个坑就是上下文爆炸。刚开始我把整个仓库的技能文件全部加载进会话，结果模型光读规则就耗掉了大量 token，甚至会出现前后技能定义互相干扰的情况。后来我改成只加载核心技能，其他技能按需手动读取，上下文压力立刻小了很多。

第二个坑是技能触发词冲突。比如某个技能要求一遇到“报错”就走调试流程，而调试流程里又要求先写测试，结果模型在两种规则之间摇摆，反而不知道该听谁的。我在 AGENTS.md 里加了明确的优先级顺序“先规划、后测试、再调试”，才把行为稳定下来。

第三个坑是模型版本带来的波动。同一个技能文件，换一个模型版本后，遵守程度可能完全不同。有的模型很听话，每一流程都走；有的模型则会选择性忽略。我的处理方式是在每次重要任务的会话开头，先明确说一句“请严格遵循 superpowers 中的规划流程”，相当于给技能规则做一次高亮强调。

5.3 我现在推荐的启停组合与使用习惯

如果你也想试 superpowers，我推荐一个最精简的组合：planning 全局开启，每次任务前强制计划；TDD 在写新功能时开启；debugging 在遇到故障时开启；code-review 在提交前手动触发。这个组合覆盖了开发周期里的关键环节，又不会让上下文变得臃肿。

日常使用我还有两个小习惯。一是每个重要任务开始前，手动确认技能已激活，别完全依赖 AGENTS.md，因为模型偶尔会忽略默认规则。二是有空就拉一下 superpowers 仓库的最新代码，社区更新很快，技能文件会随着模型能力迭代不断优化，旧版本可能跟不上新模型的行为模式。

我现在找 Codex 干活前，都会先问一句：“今天的流程遵循 superpowers 了吗？”这句话看起来多余，但很多时候模型的输出质量差异就体现在这里。如果你也在调教 AI 编程代理，不妨从这几个核心技能试起，找到适合自己项目的组合。