企业官网建设流程全解析

人跟人之间最大的差距，其实不是会用多少工具，而是同一种工具在不同人手里，发挥出来的效率完全不同。就拿 Codex 来说，有人用它五分钟改完一个 bug，有人折腾一上午还在跟报错搏斗。差别在哪？很多时候就差在一套好用的工作流上。最近社区里特别火的一个东西叫 superpowers，我深度用了几个星期，可以说它改变了我和 AI 结对编程的方式。这篇就把我的使用心得、踩坑记录、工作流整理出来，给想入坑的朋友一份能直接照抄的作业。

1. superpowers 到底是什么，它解决了什么痛点

1.1 一个被忽略的真相：Codex 本身只是个引擎

先聊点掏心窝的话。我最早接触 Codex CLI 的时候，第一反应是“这不就是个终端里的 ChatGPT 吗”。确实，光秃秃的 Codex 能帮你写代码、改文件、跑命令，但用久了你会发现它有一个致命的问题——每次对话都是全新的开始。它不记得你项目的代码规范、不熟悉你的目录结构、不知道怎么处理你仓库里那一堆历史遗留问题。你跟它说“按老规矩来”，它根本不知道“老规矩”是什么。

这就像你雇了一个智商极高但完全失忆的程序员。他每次上班都忘了你们项目的约定，忘了代码风格，忘了哪些目录不能动，甚至忘了你昨天刚跟他交代过的事情。你需要反复解释、反复纠正，效率低到让人崩溃。

superpowers 解决的就是这个问题。它不是要替代 Codex，而是给 Codex 装上了一个“记忆体”和“操作规范手册”。它通过一套精心设计的规则文件、技能目录和上下文工程方法，让 Codex 从一开始就“懂规矩”，知道该用什么节奏干活、该遵守什么约定、该往哪个方向使劲。

1.2 它不是玩具，是一套完整的工作方法论

现在网上很多文章把 superpowers 描述成一个简单的“配置文件包”，这是对它的严重低估。我用了这段时间之后最大的感受是：它本质上是一套把人类软件工程实践翻译成 AI 能理解指令的方法论。

比如它提倡的“计划先行”工作流，让 AI 在动手改代码之前先写出完整的实施计划；它推崇的“forking”模式，让 AI 先尝试一个最小可行方案，而不是上来就大刀阔斧地重构；它强调的“mock 先行”，让 AI 在写真实逻辑之前先用桩代码把整个流程串起来。这些东西听起来是不是特别像我们人类工程师一直在强调的 TDD、小步提交、接口先行？

说白了，superpowers 是把过去十几年软件工程领域积累的最佳实践，通过规则文件“注入”到 AI 的工作习惯里。你不用再苦口婆心地教 Codex“先想清楚再做”，因为它的规则文件已经把这一步写死了。

1.3 适合谁用，不适合谁用

先劝退一波人。如果你只是想让 AI 帮你写个一次性脚本、跑个简单爬虫、生成一段临时数据，那 superpowers 对你来说有点杀鸡用牛刀了。它的价值主要体现在中大型项目、多人协作、需要长期维护的代码库里。

举个例子，我自己维护的几个 Java 项目，代码量都在十万行上下，里面有严格的分层架构（controller-service-repository），有固定的异常处理规范，有统一的返回体封装。这种项目里，AI 如果不知道这些约定，写出来的代码看起来“好像没问题”，但扔进代码评审里一定会被喷得体无完肤。用上 superpowers 之后，Codex 的行为会明显收敛，它知道返回体要用Result<T>包一层，知道异常要丢给全局处理器，知道 mapper 不能写在 service 层里。

如果你符合下面任意一条，我强烈建议你试试：

• 你在用一个中大型代码库，希望 AI 严格遵守已有的架构约束
• 你想要 AI 主动制定开发计划，而不是闷头就写
• 你经常需要 AI 在多个文件之间穿梭修改，且希望修改有章法
• 你痛恨反复向 AI 交代项目背景和代码规范

2. 核心设计思路拆解：规则即代码，上下文即性能

2.1 一切从 AGENTS.md 开始：AI 的项目入职手册

要理解 superpowers 的设计精髓，得先理解一个关键文件：AGENTS.md。这个名字可能会让很多人想到 GitHub 之前推出的一个类似概念，但这里的意义更宽泛。你可以把它理解成给 AI 看的项目 README，或者更准确地说，是 AI 的“入职手册”。

传统项目里，新人入职要看三样东西：项目文档、代码规范、架构说明。AGENTS.md就是这三样的浓缩版，只不过阅读对象不是人类，而是 AI 协作工具。在里面，你要告诉 Codex 这个项目是干什么的、用什么语言、遵循什么架构、有哪些雷区不能碰、测试怎么跑、构建命令是什么。

我在项目根目录放了一份精炼的AGENTS.md，全文只有三行：

阅读 .codex/ 目录下的所有规则文件，并严格遵守其中的约定。 在动手修改代码之前，必须先写出清晰的实施计划。 遵循项目现有代码风格，不得引入新的模式或依赖。

千万别小看这三行字。它像一个“总入口”，把 AI 的注意力引导到了.codex/目录下那套完整的规则体系上。这背后的设计哲学是：不要在根目录堆一大堆规则文件污染工作区，而是建一个独立的配置目录，里面再按领域拆分成多个专题规则。

2.2 分层规则体系：全局、项目、任务三管齐下

superpowers 对规则的编排方式是分层级的，这个设计非常像计算机里的缓存体系——越靠近具体任务的规则优先级越高，也越具体；越靠近底层的规则覆盖面越广，也越抽象。

全局规则放在用户主目录下的.codex/里，管的是“我这个人习惯怎么跟 AI 协作”。比如我全局规则里写了：默认使用中文回复、涉及破坏性操作前必须二次确认、生成的代码要带必要注释。这些规则适用于我所有的项目，不管今天打开的是 Java 后端还是 Python 脚本。

项目级规则放在每个仓库的.codex/目录里，管的是“这个项目有哪些特殊约定”。这部分是该项目的架构师或维护者需要重点维护的。比如我们 Java 项目的项目级规则里就有这么几条：所有对外接口必须返回Result<T>统一封装、禁止在 Controller 里写业务逻辑、新功能的单元测试覆盖率不得低于 80%。这些规则写清楚之后，Codex 生成的代码就像是在我们团队干了三年的老手写的。

任务级规则则是你在具体需求中临时补充的约定，通常直接写在对话里。比如“这次改动只涉及 service 层，不要碰 controller”“这个接口的超时时间统一设为 3 秒”。这些规则优先级最高，能覆盖掉全局和项目级别的默认设定。

2.3 规则不是越多越好：精确比全面重要

说到这儿我得泼一盆冷水。很多人一上来就疯狂往.codex/里塞规则，动辄几十个文件、上万字，看着特别全面，实际上效果很差。我见过一个朋友的项目，规则文件加起来比某些小项目的源码还长，结果 Codex 的每次响应都变得特别慢，而且经常出现规则之间互相打架的情况。

规则的本质是上下文压缩，是帮 AI 快速判断“当前最重要的事是什么”。如果规则多到 AI 都看不过来，那它反而不知道该优先遵守哪条了。我的建议是一条规则必须满足三个条件才值得写进去：一是它明确且无歧义，二是它在这个项目里会高频触发，三是违反它的代价足够大。

举个例子，“禁止使用华丽的不必要设计模式”这种规则就别写了，因为它太模糊了，AI 没法判断什么叫“华丽”。但“新代码禁止直接new线程池，必须使用项目统一的ThreadPoolConfig获取”就很精确，因为它的触发场景明确、违反后果严重（可能导致线程资源泄漏）。

2.4 上下文工程：把 token 花在刀刃上

superpowers 之所以受欢迎，还有一个很重要的原因是它对上下文的管理思路特别务实。用过 Codex 的人都知道，对话窗口总长度有限，动不动就被 token 数限制卡脖子。如果你每次对话都要重新加载一大堆项目说明，那实际能用来写代码的上下文就所剩无几了。

它的做法是让规则文件尽量短、尽量结构化、尽量场景化。不是每一条规则都需要每次聊天都进来，而是通过 AGENTS.md 的引导，让 Codex 在需要的时候再主动去查对应的规则文件。比如我只在项目规则里写了“单元测试规范详见 .codex/rules/testing.md”，Codex 在写业务代码的时候就不会去加载这个文件，但一旦它准备写测试代码，就会主动去读取。

这种“按需加载”的模式极大降低了上下文的浪费。实测下来，同样一个中等规模的改动，用 superpowers 管理规则比在对话里连续粘贴各种项目说明，节省的上下文空间至少在百分之三十以上。省下来的空间可以拿来放更多的代码示例、需求描述和过程分析，整个协作质量都上了一个台阶。

3. 安装与配置实操：从零开始跑通整套系统

3.1 前置条件：先确保 Codex 命令行工具能正常工作

在碰 superpowers 之前，你得先有一台能跑 Codex CLI 的电脑。以 macOS 为例，如果你已经装了 Homebrew，一条命令就能装好：

brew install codex

安装完成后先验证一下能不能正常调用：

codex --version

看到版本号输出就说明 CLI 本身没问题。接着你要在系统里配置好 API 密钥。新版的 Codex 支持通过codex login登录 ChatGPT 账号的方式完成鉴权，跑到这一步的时候注意终端会有一个验证链接弹出来，用浏览器打开确认一下就好。

如果codex --version报错，先别急着往下走。八成是 Node.js 版本太老，supperpowers 依赖新版 CLI 的一些特性，建议把 Node 升到 18 以上。我见过好几个朋友卡在这一步，就是因为系统里装的是上古版本的 Node。

3.2 两种安装方式：全局安装和项目级安装怎么取舍

我个人的建议是：superpowers 配好之后是两个部分，一部分是你自己的工作习惯规则，另一部分是项目专属规范。前者的优先级更高，建议全局安装；后者跟着仓库走，用项目级安装。

先演示全局安装。假设把 superpowers 的仓库文件克隆到用户主目录下的某个隐藏文件夹里：

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

别急着完事，你还要确认这个目录里有没有AGENTS.md这个入口文件。按照该项目的推荐写法，全局入口文件的内容很简单，就一句话：

读取并遵守 ~/.codex/rules.md 中的全部规则，当与项目级规则冲突时，以项目级规则为准。

然后再看看~/.codex/目录下有没有skills/文件夹。这个文件夹里装的是各类技能的提示词模板文件。比如你想让 Codex 掌握“编写单元测试”“拆解大型重构任务”“编写 git 提交信息”这些能力，对应的模板文件都整理在这里。你要做的就是检查它们是否齐全。

项目级安装更简单，直接把仓库克隆到项目的.codex/目录就行：

cd /path/to/your/project git clone https://github.com/obra/superpowers.git .codex

不过我强烈建议你克隆完之后把它里面的通用规则清掉，改成你自己项目的专属规则。不然别人的工作习惯会污染你的项目，AI 的行为会变得莫名其妙。

3.3 目录结构与关键文件逐一盘盘

装完之后，你可能会被~/.codex/里那一堆文件吓一跳。别慌，真正核心的东西就那么几样。我拉开目录给你看：

• AGENTS.md：总入口文件，AI 每次对话都会先读它
• rules.md：全局规则主文件，放你个人的协作偏好
• skills/：技能模板目录，每个.md文件是一个可复用的“能力包”
• conventions/：代码约定目录，存放语言或框架级别的约定
• context/：项目背景资料目录，AI 可以在这里找到项目的架构说明、依赖图谱等

我拿自己的.codex/rules.md举个例子，你就知道该写什么了：

- 回复使用中文，代码注释使用中文 - 在修改代码前，必须先调用 plan 技能生成改动方案 - 所有新增的公共方法必须附带 docstring - 涉及删除代码的操作，需要先解释删除的理由 - 遇到不确定的需求假设，优先列出假设并请用户确认

这里面的第 2 条特别关键。它强制 Codex 在动手之前先把计划列出来，而不是直接开始改文件。这个习惯养成之后，你会发现自己对 AI 的掌控感大大提升，它不会突然给你改一堆你根本不需要的东西。

3.4 写一个最小可用的项目级规则文件

前面我说了项目规则要短小精悍，这里给一份可以作为起点的模板。假设你维护的是一个 Spring Boot 项目：

# 项目技术栈 - Spring Boot 3.x / Java 17 / Maven - 数据库使用 MySQL 8.x，ORM 使用 MyBatis-Plus # 架构约束 - 严格的分层架构：Controller -> Service -> Mapper - Controller 层不允许出现业务逻辑 - Service 层必须处理事务，并向上抛出业务异常 - Mapper 层只允许出现数据库操作 # 代码风格 - 所有接口统一返回 Result<T> 封装 - 异常必须使用全局异常处理器，禁止在业务代码里 try-catch 后吞掉 - 日期时间类型统一使用 LocalDateTime，禁止使用 Date # 测试 - 每个 Service 的新方法必须附带单元测试 - 单元测试禁止访问真实数据库，使用 H2 内存库即可

把这些内容保存为项目根目录下的.codex/rules.md，然后在项目根目录的AGENTS.md里写上：

遵循 .codex/ 目录下的规则，尤其注意架构约束和代码风格。

这样配完之后，Codex 在这个项目里写出的代码瞬间就“有灵魂”了。我曾经让它写一个分页查询的用户列表接口，它主动用了PageHelper、返回了PageResult<T>、异常处理统一走了全局异常处理器——这跟我手写代码的习惯几乎一模一样，那一刻我真有点后背发凉。

4. 实战工作流：从需求到上线的完整协作流程

4.1 计划先行：让 AI 先交方案再动手

配置好环境只是第一步，真正的好戏在工作流上。superpowers 里最核心的一条价值观我前面已经提了：先计划，再动手。这个理念贯穿整个工具集的设计。

我跟 Codex 协作的标准流程是这样的。我先把需求描述清楚，然后不等它动手写代码，先下一条指令：

请先调用 plan 技能，针对上面这个需求制定一份实施计划，包括涉及的文件、改动顺序、潜在风险和测试思路。等我确认后再开始执行。

Codex 接到指令后会先梳理现有代码结构，定位相关模块，然后生成一份结构化的实施计划。这份计划通常包含五个部分：需求分析、涉及文件清单、具体改动点、测试策略、潜在风险。我会逐条看，有不对劲的地方直接在对话里纠正它，比如“用户列表接口不需要先生成 Excel 导出功能”“缓存的失效时间统一用 30 分钟”。等计划打磨得差不多了，才允许它进入执行阶段。

这个步骤至少帮我拦下了两三次可能会把代码库搞得一团糟的误操作。有一次它计划直接重构用户模块的数据访问层，说这样能为后续需求铺路。我一看着急冒汗，这个模块是核心链路，在没有任何自动化测试保护的情况下动它，简直是玩火。我赶紧拦住它，把需求范围收缩到只加一个字段、改一条查询语句。要是没有计划先行这一步，它可能真就一声不吭开始重构了。

4.2 小步快跑：把大需求拆成 AI 能驾驭的小任务

即使计划已经确认，直接让 Codex 一口气把整个计划执行完，风险依然不小。AI 的执行能力和注意力是波动的，越长的任务链越容易在中途跑偏。我自己亲身经历过一次：让它实现一个全链路的订单导出功能，它写到一半突然开始“优化”订单查询的 SQL，加了好几个看似合理但其实没必要的索引，还把原有的一段缓存逻辑给删了。

从那以后我把 superpowers 的“小步提交”原则奉为圭臬。具体操作方法是把计划拆成一个个互相独立的小任务，每个任务尽量控制在十几个文件以内，做完一个、验收一个、提交一个。比如上面那个订单导出功能，我会这样拆：

1. 第一步：新建导出服务接口和实现类，先只写空方法
2. 第二步：实现查询待导出订单列表的方法（不涉及文件写入）
3. 第三步：实现 Excel 文件生成逻辑，用本地临时文件验证
4. 第四步：接入异步任务系统，控制并发和超时
5. 第五步：补充单元测试和接口文档

每一步执行完，我都会让 Codex 自己总结一下刚做了什么、改了哪些文件、有没有偏离预期。这样做有趣的事情发生了：Codex 在写第三部 Excel 生成逻辑的时候，会主动跟我确认输出格式到底是.xlsx还是兼容.xls。这在以前一口气执行整个计划的时候是根本不会发生的事，因为它的上下文早就被前序工作占满了，根本无暇顾及这种“细枝末节”。

4.3 fork 与 mock：让 AI 尝试的代价降到最低

superpowers 在工作流层面特别推崇两个技术：fork 和 mock。这两个概念翻译成大白话就是“让 AI 在尝试时尽量少产生真实副作用”。

fork 是指在正式改动代码之前，让 Codex 先在“另一个维度”把改动尝试一遍。实操上通常有两种实现方式。一种是让 AI 先把关键代码片段写到临时文件里，比如scratch/plan.md和scratch/example.java，你审核认可后才手动让它应用到真实文件。另一种更激进的方式是直接用 Git 分支隔离，让所有改动发生在 feature 分支上，随时可以整体回滚。

mock 则是更进一步，让 Codex 在核心逻辑还不完整的时候，先用桩代码把流程串起来。写一个订单导出功能，它不需要一上来就把 Excel 生成、异步调度、权限校验全做出来。而是先写一个OrderExportService的空壳，里面每个方法都返回模拟数据。然后你确认方法签名、调用链、外部依赖都是对的，再让它一步步把 mock 方法替换成真实实现。

这套组合拳最值钱的地方在于：它把“AI 犯错”的成本从小时级降到了分钟级。以前 AI 写错一个深层的业务逻辑，你要在一大坨代码里追踪半天；现在任何一步出了问题，你只需要检查对应的一小步改动。对于我这种对代码库安全极度敏感的人来说，这种感觉太踏实了。

4.4 收尾检查：让 AI 自己审自己的代码

我一直觉得，代码写完之后让 AI 自己给自己做 code review 是非常被低估的一个环节。superpowers 里有一个技能专门干这个事，名字就叫“review”。每次 Codex 完成一个小任务，我都会让它运行这个技能，对刚写的代码做一遍自查。

自查的重点不是语法错误，因为那通常不会犯。重点是这些问题：

• 有没有违反项目规则里写的约束
• 有没有潜在的并发安全和事务问题
• 有没有遗漏异常处理分支
• 有没有办法在不改变行为的前提下简化代码

刚开始用的时候，AI 的自查报告经常是“代码质量良好，没有发现问题”。这显然不是在完成任务。后来我调整了指令，给它加了强度，明确要求它“必须找出至少两个可以改进的点，否则就视为没有认真检查”。加了这条前置约束之后，它反而真的开始认真审了，时不时真能揪出一些隐蔽的问题，比如并发场景下的共享变量没有加锁、缓存 key 设计不合理导致穿透、SQL 查询没有覆盖联合索引等。

我经常开玩笑说，superpowers 让我从一个“写代码的人”变成了“审代码的人”。而且这个审查还特别卖力，永远不会烦，你让它审多少次它就审多少次，这个体验是任何人类同事都给不了的。

5. 高频问题与排查技巧：我踩过的坑都在这了

5.1 规则明明写了，AI 却视而不见怎么办

这是被问得最多的一个问题。很多人配置好规则文件之后满心期待，结果发现 Codex 的响应和没配之前一个样，该违反还是违反。排查这件事，我的经验是分三步走。

第一步，确认AGENTS.md的路径有没有放对。很多人在项目根目录下放了一堆.codex里面的规则文件，却忘了放入口文件，或者把入口文件写到了.codex/AGENTS.md。Codex 默认从工作目录往上找AGENTS.md，不会自动去读.codex/目录下面的东西。这个低级错误我犯过一次，排查了半个小时才发现。

第二步，确认规则文件没有被大到上下文塞不下。如果你把一本五千字的规范塞进rules.md，Codex 可能只读取了前面一小部分。我的经验是单个规则文件控制在两百行以内，如果规则确实很多，就拆成多个文件，用AGENTS.md里的引用关系去组织。AI 跟人一样，在一堆废话里找重点的效率是很低的。

第三步，在对话中主动提醒它去读规则。比如在第一次发指令的时候附带一句“开始之前请先阅读 .codex/rules.md”。别觉得啰嗦，这是最可靠的兜底手段，能保证规则一定被加载进上下文。实测下来这句提醒能显著提高规则遵循率，值得养成习惯。

5.2 多项目规则互相污染：全局和项目级的边界怎么划

这个坑我也踩得比较深。最开始我把所有自定义规则一股脑塞进了全局规则里，包括某些项目专用的架构约束。结果在那个项目里好用的规则，到了另一个技术栈完全不同的项目里就开始捣乱。最典型的是我在一个微服务项目里写了“所有接口必须返回统一 Result 封装”，结果换到一个纯算法项目里，它封装的每一段输出函数都被硬套上了 Result，搞得整个代码库充满了无意义的样板代码。

给大家一个划分标准的建议：全局规则只管“你跟 AI 的协作方式”，项目规则才管“项目本身的代码约定”。类似“先计划后执行”“涉及破坏性操作前要确认”“中文回复”这种跨项目通用的东西放全局；类似“Controller 层不允许业务逻辑”“统一返回体”“数据库操作必须在 Mapper 层”这种和业务技术栈深度绑定的放项目规则。划清楚这条线之后，两个维度各司其职，再没出现过污染问题。

还有一个细节是全局规则里尽量别写技术栈相关的东西，比如“优先使用 Optional 处理空值”这种话，它在 Java 项目里没问题，但你要是哪天接了个 Go 项目，它就会试图在 Go 里写类似 Optional 的代码出来，那画面太美我不敢看。

5.3 上下文爆炸：对话太长导致 AI 失忆

Codex 对话久了会变傻，这是所有重度用户都遇到的问题。尤其是处理一个大需求时，聊到后面 AI 可能连需求本身都忘了，更别提前面约定好的规则和计划。superpowers 的工作流在一定程度上缓解了这个症状，但没有完全根治。

我自己摸索出来的几个土办法还是相当实用的。一是在开始大需求之前，先让 AI 把已经确认的计划浓缩成一份精炼的执行摘要，放在对话里固定位置。后续它跑偏的时候，你就引用这份摘要让它回到正轨。二是每完成一个小任务就让 AI 出一份非常简短的变更记录，包括改了什么、为什么改、涉及哪些文件。下次对话时把这份记录粘贴进去，AI 能在分钟级内重新获得项目上下文。三是考虑切分对话。如果需求实在太大，就分多个会话处理，每个会话只负责一个阶段，会话之间用文档传递上下文，而不是硬扛着在一个超长对话框里连续作战。

这几招虽土但管用。说到底，AI 的上下文窗口就是它的工作记忆，你得学会帮它做“记忆管理器”。

5.4 Java 项目中的特殊场景与超级技巧

最后聊一点 Java 项目里的特殊体会。因为我自己主要用 Java，所以在这块的经验会格外具体。

Java 项目通常源文件多、类名长、依赖关系复杂，AI 在定位代码时经常會在错误的方向上浪费大量时间。我在.codex/rules.md里加了一条“在处理具体业务前，先列出涉及的类名和文件路径并简单说明它们之间的关系”。这个约束很便宜，但是对 Codex 的行为影响非常大，它不会一上来就乱试错，而是先花几十秒做静态梳理，定位准确率一下子提高了一大截。

还有一个实战心得是让 Codex 处理 Lombok 的时候要格外谨慎。Lombok 的注解在编译期生成大量代码，AI 的光标定位经常因为 Lombok 生成的方法而错乱。我建议在规则里明确约定“新增实体类禁止使用 @Data 等全量注解，改用显式 getter/setter 或 Java record”。这个约束让我少删了至少几百行垃圾代码。

另外就是测试。Java 项目的单测框架多，JUnit 4、JUnit 5、TestNG 并存的情况很常见。如果项目里没有统一，AI 很容易按自己的偏好乱选。我这里直接写死“新代码统一使用 JUnit 5 + AssertJ，不允许使用 TestNG”，从此测试代码的风格就稳定下来了。

6. 除了代码，superpowers 还能帮你做什么

6.1 需求分析与技术方案设计

superpowers 的能力边界其实远不止于写代码。它那套“规则前置、计划先行”的工作流，用到需求分析和技术方案设计上同样好使。我现在做一个中型需求的时候，会先让 Codex 在“需求分析师”模式下工作：输入一段业务描述，要求它输出功能清单、边界情况、异常场景、验收标准。

这套流程跑完之后，再切到“架构师”模式，让它基于需求清单给出技术方案，包括选型理由、模块划分、接口定义、数据模型设计。由于需求分析阶段已经把边界情况和异常想得很充分，技术方案的质量会明显高于直接让 AI 凭空设计。

我印象最深的是做一个小程序的支付回调模块。需求描述就一句话“处理支付结果回调并更新订单状态”。Codex 在需求分析阶段主动列了十多个异常场景，包括重复回调、金额不一致、订单不存在、签名校验失败等，这些后来成了测试用例的核心来源。放在以前，这些场景要等测试工程师提 bug 我才会意识到。

6.2 Git 操作与代码评审的自动化

你有没有想过，AI 其实也能帮你做 Git 操作和代码评审？superpowers 的技能库里有一套专门针对 Git 工作流的技能包。比如它可以帮你生成 commit message——不是那种烂大街的单行模板，而是基于实际 diff 生成的结构化提交信息，包括本次改动的目的、涉及的功能点、潜在的破坏性影响。这玩意在我提交 PR 的时候能省下很多脑细胞。

代码评审就更不用说了。每次有同事提了 PR，我可以直接把 PR 的 diff 喂给 Codex，让它站在“挑刺的资深工程师”角度审查。它输出的报告覆盖的点比我预想的还全：架构一致性、命名规范、异常处理、性能隐患、测试覆盖。我甚至会把它生成的评审意见转述给团队成员，当然会注明这是 AI 的意见，避免产生“你拿 AI 来怼我”的误会。

6.3 写文档与维护知识库

写技术文档是非常适合 AI 的领域，但前提是它得先了解你的项目。如果直接用普通的 Codex，你得在对话里粘贴大量文件路径和代码块，效率低不说，它写出来的文档还可能跟实际代码有出入。在 superpowers 的规则体系下，AI 已经通过上下文文件掌握了项目的整体结构，写文档时直接引用具体类名、方法名、依赖关系，准确率会高很多。

我在项目里试过让它把某个核心模块的架构说明写成一页带类图的 Markdown 文档。因为规则文件里有架构约束的描述，它写出来的文档没有和现有代码产生矛盾。换成没有规则文件的裸 Codex，同一件事就得反复纠错才行。

6.4 从个人工具到团队基础设施

最后说一个扩展视角。很多人把 superpowers 当成个人效率工具，但我觉得它的潜力远不止于此，它完全可以变成团队的基础设施。

设想一下，你把你团队的架构约束、编码规范、代码评审标准全部沉淀成.codex/目录下的规则文件，然后把这份配置放在一个公共仓库里。团队每个成员 clone 项目时，只需要执行一条安装命令，就能让整个团队的 AI 协作体验保持一致。新成员入职之后，与其让他在一堆文档和代码里摸索，不如让他直接上手用这个配置好的 Codex 工作，他写出来的第一批代码就已经符合团队规范了。

这种体验让我想到了早年团队引入代码规范检查工具的时候，从“人工评审靠感觉”进化到“工具扫描自动拦截”的那种震撼。superpowers 做的事情本质上是一样的，只不过这次拦截的主体从 Lint 工具变成了 AI。

我个人在实际操作中还有一个体会：配置好规则之后，不要期望它一步到位。规则是需要持续演化的，就像代码一样，要不断根据实际使用反馈去调整。我用了三个多星期，前前后后改了差不多十几次规则内容。删掉了一些从来没派上用场的废话规则，新增了几个在实战中发现的坑对应的约束。现在这套规则已经在我的日常工作中跑得非常顺，几乎不需要额外干预。

如果你也想试试，我的建议是别从零开始，先去把项目仓库里的默认规则 clone 下来，用最少的内容起步，然后在真实项目中一点一点磨。等它在你手底下工作了一个月之后再来评价它到底值不值得——我的答案是，值得，而且用过之后就回不去了。