企业官网建设流程全解析

最近在折腾命令行AI编程工具，试了一圈下来，Codex CLI是我目前用得最顺手的。但用久了也会觉得它差点意思——模型很强，代码写得快，但碰到稍微复杂一点的任务，它容易“快手乱打”：不写测试就改代码，改完不回归验证，全凭一股冲劲，遇到重构或者多文件改动时，翻车概率直线上升。这恰好是superpowers这个开源项目要解决的问题。

superpowers（GitHub 上的 obra/superpowers）本质上是一套“AI 技能包”，它不是模型，不是 IDE，而是一组标准化的操作规范和提示词策略，专门给 Codex CLI、Gemini CLI 这类命令行 AI 编程工具用的。装上它之后，AI 在动手之前会先跟你确认需求边界，把方案讲清楚，然后写测试、再实现、再回归，每一步都有章法。它解决的核心痛点很直接：模型能力不缺，缺的是工程纪律。这篇文章我把自己的安装过程、日常用法和踩过的坑都整理出来了，给想给 AI 编程助手“立规矩”的朋友做个参考。

1. 项目概述与设计思路拆解

1.1 superpowers 到底是什么

先给还不了解的朋友说个大概。superpowers 是一套开源项目，作者是 Jesse Vincent（GitHub 账号 obra），他本人是资深 Perl 和开源社区的老兵，写过多年的基础设施软件。这个项目最初是从他使用 Codex CLI 的亲身经历中长出来的——他发现模型本身已经很强了，但如果缺少一套清晰的工作指引，AI 很容易在复杂的编码任务里“自嗨”，写出看起来很合理、实际上没经过验证的代码。

它的形态很有意思：不碰模型权重，不做独立 App，而是用一组 Markdown 格式的“技能文件”（skills）来约束 AI 的行为。这些技能文件被放到 Codex CLI 能读到的目录里，Codex 在每次对话时会把相关技能的规则注入到上下文里，让 AI 在回答前先“读过”这批操作手册。装完之后，你可以在 Codex 的配置里看到插件列表，也能在对话中要求 AI 遵循某个具体的技能文件来工作。

这就像给一个天赋很好但没受过系统训练的工程师发了一整套团队 SOP：需求阶段先写清楚验收标准，动手前先讲方案，写完代码先补测试，发现问题按流程排查而不是瞎猜。模型本身的知识面和处理能力仍然是核心，superpowers 做的事情是把“正确的工作方式”前置到每一次交互里，给 AI 一个可复用的方法论框架。

1.2 为什么需要给 AI 编程助手装“技能包”

我个人的体感是，现在的对话式 AI 编程工具有一个通病：它们天然是“顺从型”的。你让它改一个函数，它会立刻给你新版本；你让它重构模块，它会欢快地动手。问题在于，它很少反驳你，也很少主动说“等等，这里需求还没定义清楚”。在大型代码库里，这种顺从会变成灾难——AI 改了一个核心函数的入参，结果调用方们谁也没被更新，编译一跑，红了一片。

superpowers 针对的就是这个问题。它通过显式的规则把 AI 从“问你一句答一句的实习生”改造成“先思考再动手的高级工程师”。装完这套技能包之后，最明显的变化是 Codex 在动手前会主动向你确认理解，甚至反过来追问需求边界。我第一次用的时候，有点不习惯这种“变啰嗦”的 AI，但几次下来，发现返工率确实低了，因为很多歧义在写代码之前就被澄清了。

另一个价值是它把测试的地位提到了几乎最高的优先级。过去我让 Codex 写功能，它可能写完核心逻辑就认为自己“完成”了；现在它会把测试当作交付的一部分，甚至在实现之前就先写好测试。这个转变对我们这种习惯了 TDD 的开发者来说非常对味，对还在观望的人，也能直观感受到“测试先行”在 AI 协作里的价值——AI 自己写的测试可以充当反复修改时的安全网，后续你再让它改功能，回归用例就在那里兜底。

2. 安装部署与前置环境准备

2.1 安装前需要准备什么

先说环境。superpowers 不是独立软件，它是 Codex CLI 的插件集，所以你的机器上必须先装好 Codex CLI。如果你用的是 Trae Work CN 这类支持 skills 的编辑器，也可以走另一条路径，但核心前提一样：得有一个能识别技能文件的 AI 编程环境。

安装前建议确认几样东西：

• Codex CLI 版本：superpowers 的新特性通常会跟随 Codex CLI 的更新，建议把 Codex 升级到比较新的版本再装。老版本可能解析不了插件配置，或者行为差异很大。
• Node.js 环境：Codex CLI 本身基于 Node.js，装个 LTS 版本比较稳妥。如果你之前装过 Codex，Node 环境通常已经有了。
• Git 命令行：虽然不强制，但在拉取 superpowers 仓库和后续更新时用得上。
• OpenAI API 访问权限或 Codex 订阅权限：Codex CLI 需要连接后端模型，这个前提没满足的话，工具本身就跑不起来。

这些准备项都满足后，再动手安装 superpowers。我自己的环境是 macOS + Node 20 LTS，Codex CLI 已经用了一段时间，整个安装过程大概十分钟以内能完成。

2.2 通过 Codex CLI 安装 superpowers

Codex CLI 的插件机制在早期版本里是通过配置文件管理的，后来版本增加了更方便的插件安装命令。你可以先打开终端，运行 Codex 的交互界面，然后直接用/plugin指令查看当前插件状态，或者用命令行直接安装。

我实测过的路径大致如下：

# 先确认 codex 已安装 codex --version # 安装 superpowers 插件 codex plugins add superpowers

如果当前版本的 Codex CLI 还不支持plugins add子命令，也可以手动改配置文件。Codex CLI 的配置文件一般在~/.codex/config.toml（macOS/Linux）或%USERPROFILE%\.codex\config.toml（Windows）。打开后找到[plugins]部分，添加如下内容：

[plugins] superpowers = "github:obra/superpowers"

保存后重启 Codex CLI，插件就会被加载。你可以输入类似“请列出你当前可用的技能”这种话，看 AI 是否会提到 bootstrapping、tdd、design 等技能名称。能提到，就说明 superpowers 已经生效了。

提示：部分版本对插件路径比较敏感，如果你用的是本地 clone 的仓库，可以把地址指向本地目录。比如superpowers = "file:///Users/yourname/superpowers"，这样可以随时手动改动技能文件来调试。

2.3 在 Trae Work CN 中安装 superpowers skill

如果你主力编辑器是 Trae Work CN，也可以把 superpowers 作为 skill 装进去。Trae 支持自定义技能导入，路径一般是：设置 → 技能（Skills）→ 导入技能。source 选择本地目录或 Git 仓库，把 superpowers 仓库 clone 下来后直接选中skills目录导入即可。

# 先拉取项目 git clone https://github.com/obra/superpowers.git # 进入项目目录，确认技能文件列表 cd superpowers ls skills

在skills目录里你会看到一组子目录，比如bootstrapping、test-driven-development、design等。Trae 导入时一般识别的是单个技能文件夹，所以你需要逐个导入，或者看你的版本是否支持整个目录批量导入。装完后，在 Trae 的对话侧边栏里应该能看到这些技能出现在可用技能列表里，使用效果和 Codex CLI 里的差别不大。

有一点要注意：Trae 的技能机制和 Codex 的插件机制不是一回事，两者对技能文件的解析规则可能略有差异。遇到个别技能在 Trae 里不生效，不用太纠结，优先保证核心的 bootstrapping 和 tdd 两个技能能用，就足够改善主力工作流了。

3. 核心技能盘点与实际工作方式

3.1 核心技能文件一览

superpowers 仓库里的技能文件是这套工具的灵魂。不同版本技能清单会有些出入，我目前版本里看到的几个核心技能：

除了这五个，仓库里还有一些更细粒度的技能，比如写提交信息、做代码审查、处理安全问题的规则等。作者的思想挺清晰：每一个技能都是在模拟真实团队里某种“角色规范”。bootstrapping 相当于入职培训，test-driven-development 相当于质量红线，design 相当于技术评审会，implementing-changes 相当于开发计划，troubleshooting 相当于故障排查手册。

3.2 最常用的 TDD 技能到底怎么工作

test-driven-development 是我用得最多的技能。没装 superpowers 之前，我让 Codex 写个函数，它常常直接生成完整实现，看起来很方便，但一旦逻辑分支稍微多点，边界条件经常漏。装上 TDD 技能后，Codex 会按一个固定节奏来推进：

1. 先写一个最小失败测试，跑一次确认是红的；
2. 根据测试写最小实现，让测试变绿；
3. 再补下一个失败测试，循环往复；
4. 全部通过后，做一轮简单重构。

这个流程单独看并不稀奇，奇的是由 AI 来执行时，“先写测试再写实现”这个顺序会极大影响代码结构。AI 在写测试的过程中相当于提前做了一遍需求分析，它会主动把“输入是什么、输出是什么、异常怎么办”想清楚再动手。我遇到过几次，Codex 写完测试后停下来问我：“这个方法的边界行为没定义，是先抛异常还是返回空值？”这种问题在过去直接写实现时它几乎不会提。

如果你以前没有 TDD 习惯，用这套技能会打开新世界——它把“安全修改代码”变成了一种可重复的操作模式。后续你再让 AI 改功能，回归测试就在那里，AI 每次跑完测试才知道自己有没有改坏东西，比过去“改完凭感觉”靠谱太多。

3.3 从“一问一答”到“项目协作”的体验变化

装上 superpowers 后，Codex 给我的观感更像一个拿着任务清单的协作者，而不是一个等待指令的问答机器。举一个我最近的例子：我要给一个内部工具加一个“批量导入用户”的功能。过去我直接说“帮我写批量导入”，AI 吭哧吭哧生成一大段代码，跑起来一堆异常。现在它先会根据 design 技能，问我：“导入文件的格式是什么？字段校验失败是跳过还是中止？重复用户怎么处理？”这些问题会有一些繁琐，但回答完之后，它写出来的代码命中率非常高，基本就是一版过。

这种变化背后有一个很实在的设计逻辑：AI 模型对自然语言歧义非常敏感，同一句话在不同上下文里会有完全不同的理解。superpowers 通过技能文件强制 AI 在动手前做需求澄清，相当于从流程上消灭歧义。实践证明，多花两分钟对话，能省下几十分钟的调试时间，这笔账非常划算。

4. 实操过程与典型任务拆解

4.1 新会话启动后的标准操作流程

我现在的习惯是，每次用 Codex 处理一个新任务，都会先让 AI 加载 bootstrapping 技能，再进入具体任务。你可以直接对 Codex 说：

请加载 bootstrapping 技能，然后我们开始处理一个任务。

这时候 AI 通常会回复一段项目原则说明，表示它理解了如何协作。接下来我再描述具体需求。它很有可能会反过来确认几件事：项目背景、验收标准、修改范围、现有测试状态。这些确认动作都是 superpowers 注入的，不用嫌烦，把它当成 Team Leader 在开工会时做的信息拉齐就好。

描述完需求后，根据任务类型选择技能路径。小改动就直接走 implement 流程；新功能或复杂逻辑就要求它先用 design 技能给出方案；修复 bug 则建议它先写一个失败测试复现问题，再开始改。这套组合拳打下来，每次会话的节奏都会比较稳，不太容易出现“AI 写了一堆代码、最后发现方向错了”的尴尬局面。

4.2 一个典型任务的完整推进过程

我拿一个真实任务来演示，这样比较直观。任务是：给一个 Python 脚本增加“从 CSV 导入用户，并返回导入结果统计”的函数。

第一步，我启动 Codex，让它加载 bootstrapping：

我：请加载 bootstrapping 技能，我们有一个新功能要开发。 AI：已加载。我理解自己的工作方式：先明确需求边界，再设计方案，测试先行，小步实现。请描述任务。

第二步，我描述需求。因为 superpowers 的引导，AI 主动问了我三个问题：CSV 的必填列有哪些、重复用户如何处理、导入结果是否需要包含失败原因。我回答之后，它给出了设计方案：分两步，先解析文件，再批量写入，写一个parse_csv和一个import_users函数。

第三步，在 design 技能引导下，它列出了一个简短的接口定义和数据格式示例，并说明异常处理策略。这里我不需要写任何代码，它已经做了明确的拆解，待我确认后才进入实现阶段。

第四步，进入 TDD 流程。AI 先生成测试文件，覆盖三个场景：正常导入、重复用户跳过、必填字段缺失报错。然后跑测试，确认失败，再逐个实现功能让测试变绿。整个过程它都在小幅操作，每完成一个测试就跑一次 pytest。全部通过后，它会做个极简重构，然后汇报结果。

这个过程比我以前直接用 Codex 写代码要慢一点点，但完成质量明显高很多：测试文件随需求一起交付，函数边界清晰，代码里几乎没有多余的“模型幻觉”。对于把稳定性和可维护性看得很重的项目，这个慢是值得的。

4.3 让 AI 遵循技能的执行细节

日常使用中还有一个实用技巧：你不需要每次手动指定技能。装好 superpowers 后，Bootstrapping 技能会在新会话的默认上下文里被自动注入，AI 会在合适的场景自动调用其他技能。但由于不同版本的 Codex 行为略有差异，建议在一个任务的开头显式说一句：

请在所有步骤中遵循 TDD 技能的要求。

这句话的效果是给当前会话设置一个强制优先级。实测下来，加了这句之后，AI 会更坚持先写测试。如果你连这句都不想输入，也可以把这句话写进 Codex CLI 的用户自定义指令（system prompt 或 AGENTS.md），做成全局默认规则。这个思路我在两个项目里试过，都挺稳的。

注意：如果任务本身是一次性探索或原型验证，强行套 TDD 流程反而繁琐。此时你可以明确告诉 AI“不需要写测试，只做快速原型”。superpowers 的规则是可覆盖的，你的显式指令优先级更高。

5. 常见问题与排查技巧实录

5.1 安装后 AI 不识别技能，怎么排

最常遇到的问题就是：插件配置完了，Codex 却像没装一样，完全不提技能。这时先别急着怀疑项目有问题，从三处排查：

1. 配置文件格式：检查config.toml里插件路径有没有写错。常见错误是仓库地址带上了.git后缀以外的多余字符，或者路径写成了https://github.com/obra/superpowers.git这种完整 URL，有些版本只认github:obra/superpowers这种简写。
2. Codex 版本过旧：旧的 Codex CLI 对插件支持不完整，最直观的验证方式是运行codex --version，然后去项目 README 或更新日志里对一下要求的版本号。
3. 技能文件权限：如果你是用本地 clone 的方式配置插件，需要确认技能文件所在的目录有读取权限。权限不对时，Codex 会静默跳过加载，不报任何错误，看起来就像没装一样。

排完这三个点，绝大多数情况都能解决。还有一个不常见的坑：如果你同时开了多个终端窗口，旧窗口里的 Codex 进程可能还持有旧配置，改完配置后务必新开一个终端再试。

5.2 测试先行遇到“遗留代码”怎么办

装了 superpowers 之后，AI 会默认要求先写测试。但如果你负责的是老项目，一堆遗留代码连测试框架都没有，这时候 TDD 流程会卡住。我的处理办法是分两步：

第一步，先引入一个最轻量的测试框架，比如 Python 的 pytest 或 Node 的 vitest，只要能让 AI 跑起来即可，不需要追求覆盖率。

第二步，遇到具体 bug 时，让 AI 先针对这个 bug 写一个“复现性测试”，也就是先证明问题存在，再修改代码让测试通过。这个过程成本很低，效果立竿见影——不仅修了 bug，还留下了一个防止回归的测试。

在 Codex 里可以这样表述：

这是遗留项目，目前没有测试框架。先帮我引入 pytest 并写一个最小配置，然后针对这个 bug 先写复现测试，再修复。

AI 在 superpowers 的规则下会很配合地执行这个两步方案。其实这也是所有改造老项目的好姿势：不要幻想一步到位，先给关键路径加安全网，再逐步推广测试。

5.3 常见问题速查表

5.4 我对这套工作方式的一些实操心得

最后分享几个我自己的使用心得。第一个是关于“技能不是越多越好”。superpowers 默认会带不少技能文件，但对多数日常任务来说，bootstrapping 加 TDD 两个已经能覆盖大部分收益。我一开始试图让 AI 在每个任务里都把 design、implement、troubleshooting 全套走一遍，结果对话变得冗长，反而拖慢节奏。现在我按任务复杂度灵活选择：小改动用 TDD 就够，大功能才进 design，只有排查疑难杂症时才上 troubleshooting。

第二个心得是“AI 生成的测试也有质量问题”。superpowers 虽然让 AI 写测试，但它写的测试有时会只覆盖正向路径，对异常输入的断言不够。我现在的做法是：AI 写完测试后，我会扫一眼断言逻辑，补上我认为关键的边界场景。它不是万能药，但它提供了一个非常好的起点，让我把精力花在补充关键用例上，而不是从零搭测试框架。

第三个心得是关于团队协作。如果你和同事共享一个项目，建议把 superpowers 的技能文件纳入仓库的AGENTS.md或文档目录，让每个人都能看到 AI 的工作规则。这样不同成员用 Codex 时的行为模式更一致，代码风格也会更统一，某种意义上这也是一种“团队级别的工作协议”。

我个人在实际操作中的体会是：superpowers 真正值钱的地方不是那些炫酷的提示词模板，而是它把“怎么写代码才能少返工”这件事，从人的脑子搬到了 AI 的运行机制里。它不是什么银弹，装了也不会让你的 AI 一夜之间变成架构师，但它确实是目前我在命令行 AI 编程工具里见过的最务实、最接近“真实团队协作”的增强层。如果你正在用 Codex CLI，而且有点受不了它那种“撞了南墙再回头”的编码方式，非常建议花半小时把这个技能包装上，亲自感受一次 TDD 流程下的 AI 写代码。