人跟人之间最大的差距其实不是会用多少工具而是同一种工具在不同人手里发挥出来的效率完全不同。就拿 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 的行为会明显收敛它知道返回体要用ResultT包一层知道异常要丢给全局处理器知道 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 项目的项目级规则里就有这么几条所有对外接口必须返回ResultT统一封装、禁止在 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.xORM 使用 MyBatis-Plus # 架构约束 - 严格的分层架构Controller - Service - Mapper - Controller 层不允许出现业务逻辑 - Service 层必须处理事务并向上抛出业务异常 - Mapper 层只允许出现数据库操作 # 代码风格 - 所有接口统一返回 ResultT 封装 - 异常必须使用全局异常处理器禁止在业务代码里 try-catch 后吞掉 - 日期时间类型统一使用 LocalDateTime禁止使用 Date # 测试 - 每个 Service 的新方法必须附带单元测试 - 单元测试禁止访问真实数据库使用 H2 内存库即可把这些内容保存为项目根目录下的.codex/rules.md然后在项目根目录的AGENTS.md里写上遵循 .codex/ 目录下的规则尤其注意架构约束和代码风格。这样配完之后Codex 在这个项目里写出的代码瞬间就“有灵魂”了。我曾经让它写一个分页查询的用户列表接口它主动用了PageHelper、返回了PageResultT、异常处理统一走了全局异常处理器——这跟我手写代码的习惯几乎一模一样那一刻我真有点后背发凉。4. 实战工作流从需求到上线的完整协作流程4.1 计划先行让 AI 先交方案再动手配置好环境只是第一步真正的好戏在工作流上。superpowers 里最核心的一条价值观我前面已经提了先计划再动手。这个理念贯穿整个工具集的设计。我跟 Codex 协作的标准流程是这样的。我先把需求描述清楚然后不等它动手写代码先下一条指令请先调用 plan 技能针对上面这个需求制定一份实施计划包括涉及的文件、改动顺序、潜在风险和测试思路。等我确认后再开始执行。Codex 接到指令后会先梳理现有代码结构定位相关模块然后生成一份结构化的实施计划。这份计划通常包含五个部分需求分析、涉及文件清单、具体改动点、测试策略、潜在风险。我会逐条看有不对劲的地方直接在对话里纠正它比如“用户列表接口不需要先生成 Excel 导出功能”“缓存的失效时间统一用 30 分钟”。等计划打磨得差不多了才允许它进入执行阶段。这个步骤至少帮我拦下了两三次可能会把代码库搞得一团糟的误操作。有一次它计划直接重构用户模块的数据访问层说这样能为后续需求铺路。我一看着急冒汗这个模块是核心链路在没有任何自动化测试保护的情况下动它简直是玩火。我赶紧拦住它把需求范围收缩到只加一个字段、改一条查询语句。要是没有计划先行这一步它可能真就一声不吭开始重构了。4.2 小步快跑把大需求拆成 AI 能驾驭的小任务即使计划已经确认直接让 Codex 一口气把整个计划执行完风险依然不小。AI 的执行能力和注意力是波动的越长的任务链越容易在中途跑偏。我自己亲身经历过一次让它实现一个全链路的订单导出功能它写到一半突然开始“优化”订单查询的 SQL加了好几个看似合理但其实没必要的索引还把原有的一段缓存逻辑给删了。从那以后我把 superpowers 的“小步提交”原则奉为圭臬。具体操作方法是把计划拆成一个个互相独立的小任务每个任务尽量控制在十几个文件以内做完一个、验收一个、提交一个。比如上面那个订单导出功能我会这样拆第一步新建导出服务接口和实现类先只写空方法第二步实现查询待导出订单列表的方法不涉及文件写入第三步实现 Excel 文件生成逻辑用本地临时文件验证第四步接入异步任务系统控制并发和超时第五步补充单元测试和接口文档每一步执行完我都会让 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.mdCodex 可能只读取了前面一小部分。我的经验是单个规则文件控制在两百行以内如果规则确实很多就拆成多个文件用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 下来用最少的内容起步然后在真实项目中一点一点磨。等它在你手底下工作了一个月之后再来评价它到底值不值得——我的答案是值得而且用过之后就回不去了。