1. 一场深夜排障让我重新认识了superpowers这个词大约两个月前的一个周五晚上我被一个让人抓狂的Java编译错误困住了。错误信息指向一个泛型方法的重载冲突IntelliJ的代码提示又一直跟我绕圈子——它建议的类型参数和实际传入的参数类型总是差那么一点。我一边翻着Stack Overflow一边嘀咕这活儿要是能有个超能力替我拆解就好了。那一晚我顺手搜了一下superpowers本想看看有没有现成工具能直接定位这种复杂类型推断的问题结果搜出来的东西比我预期的要宽得多。社区里围绕superpowers这个词的讨论已经从某个具体工具的名字扩展成了给AI编码代理配置一整套增强能力的方法论。跟着蹦出来的热搜词还有superpowers使用指南、superpowers安装、codex superpowers明显能看到很多人正在把这一套东西接入自己的日常编码流程尤其是配合Codex这类AI编码助手在Java项目里做深度重构。这也是我今天想完整写一篇经验分享的原因。过去这一个多月我把superpowers的配置思路完整走了一遍先后在三个项目里落地一个Spring Boot微服务、一个纯JDK的原生模块、还有一个跑了五年没敢动的老项目。整个过程下来最直观的感受是——它确实能补上AI编码代理很多看不见的天花板但前提是你得理解它背后的构造逻辑而不是简单跑个安装命令就指望万事大吉。这篇文章主要面向两类人一类是已经日常使用AI编码助手、但总觉得它在复杂任务里差点意思的开发者另一类是刚听说superpowers这个词、想搞清楚它到底是什么、值不值得折腾的新手。我会把我自己的选型依据、安装过程、配置细节、在Java实战里踩过的坑以及最终沉淀下来的一套工作流都摊开讲尽量做到你看完就能自己动手复现。先说结论superpowers的核心价值并不是给你一个更聪明的AI而是给AI一套更完整的思维脚手架——包括任务拆解规则、上下文管理策略、代码变更流的控制方法以及针对特定语言生态比如Java的优化提示词。它不改变模型本身但能显著改变模型处理问题的方式。这才是它被叫作superpowers的原因。2. 为什么默认的AI编码代理总在复杂任务里掉链子2.1 问题的本质不是模型变笨了而是上下文管理失效了你在一个小函数上让Codex帮忙修改逻辑它一般完成得又快又好。但一旦任务规模上升——比如重构这个模块的服务层把原有的XML配置迁移到注解方式同时保持对外接口兼容——AI就开始频繁出现迷路的症状修改到这里就忘了那边的约束条件明明已经决策过的方案推倒重来完全相同的代码段在不同文件里给出两种相反的处理意见。我一开始以为是模型理解能力不够后来做了几次对照实验才意识到真正的问题是上下文管理失效。Codex这类工具本身有很强的单步推理能力但它面对一个较长会话时需要不断在不同文件之间切换读取内容、追踪已经做过的决定、维护哪些字段已经重命名、哪些接口还需要保留别名这类状态信息。如果没有人帮它建立一套清晰的任务边界和决策记录机制它自己很难把几百轮的上下文组织成结构化的知识。你可以把AI编码代理的工作方式想象成一个记忆力很好但容易分心的助手你交代第一件事它记得很牢等它处理到第三件、第四件事时前面那些你已经确定不要改这个公共接口之类的约束就可能被它忘在脑后因为那些信息埋在很深的对话历史里每次重新读取时它的注意力分配是平均的不会自动识别什么是重要约束、什么是可以忽略的过程性聊天内容。2.2 大多数人的应对方式其实是在绕弯路我刚接触这个问题时和很多开发者的第一反应一样多给AI一些重复提示明确告诉它记住不要动XXX文件上次已经决定用方案B了。这种做法短期有效长期很痛苦。一旦任务再复杂一点你会发现你花在叮嘱AI记住事情上的时间甚至超过了你自己动手改代码的时间。另一种常见做法是把大任务拆成很多个小任务一个一个小窗口做完。这个思路方向是对的但执行起来会丢失全局视图。拆得太细AI在每个窗口里都只盯着局部做出的修改和服务层、数据层之间的耦合关系可能完全对不上拆得太粗又回到上下文失控的老问题。superpowers围绕这个问题给出的解法很直接与其让AI在原始对话流里自己摸爬滚打不如在系统层面给它建立一套工作记忆机制。这套机制可以理解成给AI配了笔记本、任务清单和变更记录表——每一个重要决策都被显式记录下来每次开始新任务时会先加载相关的历史约束每次代码操作完成后会把变更摘要回写到笔记本里。这样一来AI的短期记忆负担大大降低它不需要靠回忆来维持一致性而是靠系统化的记录来保证自己始终知道当前在哪、已经做了什么、还有什么没做。2.3 为什么这件事和Codex特别搭配Codex本身是一个能力很强的编码代理它擅长理解代码库结构、生成高质量代码片段以及执行复杂修改。但它的默认使用方式非常依赖用户喂足够的上下文信息给会话。也就是说它默认假设用户在每一轮对话中会把必要的项目背景说清楚而不是自己去长期维持一个复杂的项目画像。superpowers的思路恰好补上了这一环。它在Codex的工作区间里加入了一层结构化的元信息层项目概览、技术栈说明、任务目标、当前进度、已完成变更清单、待办事项、约束条件全部以明文文件的形式组织和维护。Codex在每一轮决策前可以先读取这些文件获得一个全局快照而不是只依赖聊天窗口里的即时信息。配合起来的效果很惊人。我在Spring Boot项目里做一次跨模块的重构时Codex在superpowers模式下连续工作了将近一个小时中间没有出现一次忘记前置约束的情况。而在之前默认模式里同样规模的重构通常超过十五分钟就会开始出现逻辑不连贯。这个对比让我确认了一件事AI编码代理的上限很大程度取决于你能不能给它一套好的工作方法superpowers本质上就是在做这件事。3. 安装与初始配置不是跑个命令就完事3.1 环境准备里最容易翻车的版本匹配先说最基础的安装。superpowers目前的主流使用方式是作为Codex的扩展组件以本地项目目录为单位加载。也就是说不是全局安装一次以后所有项目都能自动用上而是每个项目都需要初始化一份属于自己的superpowers配置。这个设计有好处也有坏处好处是不同项目可以有不同的规则集互不干扰坏处是如果你的项目很多每个都要初始化一遍而且版本升级时需要逐个同步。我从踩坑中得到的最重要经验是安装前必须先确认你的Codex版本和superpowers的兼容范围。这也解释了为什么社区里经常有人发帖问为什么我装完之后一点效果都没有——大多数情况不是装错了而是Codex一侧的接口变了旧的superpowers版本没法正确识别。我自己遇到过一次典型情况Codex更新到新版本之后superpowers的任务清单文件生成逻辑直接失效AI完全不读取我手动创建的状态文件。排查了半天才意识到是版本间API变动导致的。所以建议在做任何安装动作之前先去查一下当前superpowers的官方说明中标注的最低支持版本和推荐版本不要一味追新。我的实际操作步骤如下确认当前Codex客户端版本在终端里运行版本查询命令。打开目标项目目录创建专门的配置文件目录通常命名为.superpowers之类。从官方源拉取模板文件包括主配置文件、任务清单模板、变更记录模板。根据项目实际技术栈在配置文件中声明语言优化开关Java、Python、TypeScript等。运行初始化脚本生成第一份项目快照。快速验证在Codex会话中让AI读取项目概览文件看它能否准确说出项目结构和关键依赖。3.2 初始化完成后的目录结构长什么样在Java项目里初始化完成后你会看到类似这样的目录布局.superpowers/ ├── config.yaml ├── context/ │ ├── project_overview.md │ ├── architecture_decisions.md │ └── constraints.md ├── tasks/ │ ├── current_task.md │ └── task_history.md ├── logs/ │ └── change_log.md └── rules/ ├── java_rules.md ├── git_workflow.md └── coding_conventions.md这套目录结构不是一个装饰性的骨架它直接影响Codex的工作方式。context目录下的文件负责描述项目的基本面和约束条件tasks目录负责管理当前进行中的任务及历史任务logs目录里的change_log是AI每次操作后的产出记录rules目录则是你希望AI在编码时遵守的具体规范。Java项目的java_rules.md在实操中非常重要。因为Java的代码风格选择太多——有人写Lombok有人讨厌Lombok有人用Stream API有人坚持传统for循环有人接口一律加I前缀有人不加。这些偏好如果不显式写进规则文件AI每次都可能给出违背你审美的代码你还得一遍遍返工。我在规则文件里明确写了几条影响最深的规定禁止在核心业务逻辑里使用Optional作为字段类型、所有集成层方法必须显式声明异常策略、DTO转换统一使用MapStruct而非手写setter。这样做之后Codex生成的代码质量立刻上了一个台阶。3.3 接入Codex的完整链路配置好目录结构之后还有一步关键操作让Codex每次会话启动时自动加载superpowers的上下文。这一步做不好前面所有的目录创建都白费。我的做法是在项目的启动配置中注入一个初始化提示词块。这个提示词块的作用是告诉Codex你是一个在superpowers模式下工作的编码代理你的第一优先级是读取context目录下的项目概览和约束文件第二优先级是检查tasks目录里的当前任务描述第三优先级是处理用户当前请求。每次做出重要变更之后你需要在change_log.md中追加记录。有一个细节值得你特别留意提示词块的写法要具体而清晰不能给AI太宽泛的自由解释空间。比如请在工作开始前查看项目信息这种提示Codex不会因为这句话就养成好习惯但每次回复前必须读取project_overview.md并在首次回复中复述你对项目结构的理解这种明确指令Codex通常会遵循得很好。我接入完成后做过一次验证在全新的Codex会话里什么项目背景都不说直接问这个项目当前的构建流程是什么AI准确回答出了Maven多模块的构建顺序还指出了其中一个模块有测试跳过配置。这证明superpowers的上下文已经成功植入了AI的初始工作记忆而不再需要你在每次对话的前两三轮辛苦补充背景信息。4. 核心模块拆解任务清单、变更日志和约束文件是怎么配合的4.1 任务清单模块把大目标拆成AI能消化的执行单元superpowers里我最欣赏的机制就是它把思维链从隐性的对话推理变成了显性的文字记录。默认情况下AI在一个长任务里靠自己的内部状态来维护我进行到哪一步了这个内部状态对用户是黑盒出了问题很难排查。而superpowers的任务清单模块本质上是强制AI把进度写在一个明文文件里整个思考过程可以被用户随时查看和纠正。我在实际使用中会把一个大型重构任务拆成这样几个阶段阅读现有代码结构产出依赖关系图确定公共API的兼容策略创建新的服务实现类迁移核心逻辑修改调用方处理编译错误运行测试定位回归问题更新相关文档Codex在superpowers模式下会自动维护current_task.md将当前阶段标记为进行中完成后勾选为已完成。我每隔一段时间会打开这个文件确认AI所在的进度阶段。如果某个阶段执行时间过长我能立刻通过变更日志看到AI是在哪个位置纠缠不清然后手动介入给它更明确的指令而不是像默认模式那样只能盲目等待产出。长期实践下来我还有一个额外的好处由于所有任务轨迹都被记录在task_history.md里我可以在重构结束后复盘AI当时的决策过程。这对我来说帮助很大因为很多时候AI给出的修改方案不是错的而只是和我预期的思路不同。有了记录之后我能更客观地评估AI的推理质量而不是凭印象感觉它这次干得不错。4.2 变更日志为什么代码改了以后要记下来而不是靠记忆另一个核心模块是change_log。它的作用很容易被低估但它恰恰是防止AI在长会话中精神分裂的关键。设想一个场景你在重构一个支付模块AI先在一个文件里把旧的接口实现删掉了然后在另一个文件里调用方还在引用旧接口。默认模式下AI如果在后续生成代码时没有回读到之前的修改记录很可能在同一个文件里写出互相矛盾的代码。它可能会在某个新方法里又重新使用了已经被删除的旧工具类因为它不记得自己已经删了那个类。change_log的解决方式是每当AI完成一组文件修改它就把改了什么、为什么改、涉及哪些文件追加到change_log.md里。后续生成代码时它会先扫一遍变更日志确认自己已经做过的操作避免重复劳动或冲突修改。我让这个机制落实的办法是在初始化提示词里做了硬性规定完成一次连续修改后必须立即更新change_log更新时使用固定的三段式格式变更原因、变更内容、影响文件。经过几次迭代Codex会把这个流程内化成习惯基本不会漏掉。有时候它还能主动在日志里标记出此变更可能影响XXX模块建议后续测试重点关注这种价值已经超出了简单的记录范畴而是带着推断主动提醒我风险点。4.3 约束文件把你脑子里的历史背景显性化约束文件是三个模块里最容易被新手忽略的因为它看起来就是一堆文字描述不像任务清单那样有明确的执行张力。但在我个人体验里约束文件恰恰是superpowers效果提升最大的来源之一。举个例子。我在维护一个老项目时知道有个著名的历史包袱某个公共工具类里有三个方法已经被标记为Deprecated但为了兼容老接口不能删除任何重构都不应该修改这三个方法的签名。这个信息我可以在每次会话里重复告诉AI但我更希望AI自己记住。于是我在constraints.md里明确写下工具类XXX中的A、B、C三个方法为历史保留接口禁止改动签名禁止在重构时移除。新代码禁止调用这三个方法若发现已有调用需逐一记录并迁移。一旦这个约束被写进文件Codex在生成新代码时就会主动避开这些方法而且当它读到老代码里的调用点时会自动在变更日志里标记需要迁移的遗留调用而不是直接替换掉——因为它知道替换可能破坏兼容性。这种知道自己不能做什么的能力比知道自己能做什么更能避免灾难性的重构事故。我也把团队的编码规范沉淀进了约束文件。比如在我们的Java项目里禁止在生产代码里使用System.out.println所有日志必须走SLF4J禁止在事务方法内部捕获通用异常后继续执行禁止循环内调用远程服务。这些约束在代码评审时常被人工指出但AI在superpowers模式下能主动遵守大幅减少了评审阶段的返工时间。4.4 三个模块之间的信息流是怎么走的看完上面三个模块你可能会想它们是各管各的还是有关联的答案是它们通过一套明确的读写规则形成了一个闭环。我总结出来的信息流大致是这样会话开始时Codex读取约束文件和项目概览建立全局认知接收到用户的新任务后Codex在任务清单里新建一条任务记录细化执行步骤每一步执行前Codex先查看变更日志确认已经完成的工作避免重复执行完代码修改后Codex把变更内容写入日志并更新任务状态若某次修改触发了约束文件的某个条目比如发现了一个遗留调用Codex会在约束文件的关联条目中追加标记把这个发现沉淀为长期记忆下一轮会话开始时新会话加载所有更新过的文件相当于拥有了一次完整的记忆传承这个闭环一旦跑顺AI的工作稳定性和连续一致性都会有质的提升。我曾经在一个大模块的逐层重构中让Codex连续工作了将近三个小时期间AI处理了几十个文件的修改最终当我在新会话中让它总结整个重构脉络时它给出的描述和实际变更高度吻合。这就是信息流闭环的价值——它让AI不再是一个每一轮对话都从零开始的工具而更像一个有持续记忆的协作者。5. Java项目实战我拿superpowers做了哪三类改造5.1 类型系统重构泛型边界这么难缠的问题也能稳住前面提到的那个让我深夜抓狂的泛型问题后来成了我第一个完整使用superpowers做实操的试验场。那个问题的本质是项目中有一个老旧的基类使用了未经参数化的原始类型raw type导致子类在重写方法时泛型推断出现歧义。要修复它必须在多个文件里同时调整继承关系和泛型边界任何一个文件单独修改都无法通过编译。在没有superpowers之前我尝试过让Codex单独处理这个重构结果它每一次都只改了一部分文件就停下来然后告诉我建议手动检查编译错误。这倒不是说AI不努力而是因为它没有一套全局的任务追踪机制改到第三个文件时已经忘了前面两个文件的具体签名变化。后来我用了superpowers的任务清单方法。我先在current_task.md里写清楚完整的重构步骤第一步定位所有使用原始类型的继承链第二步为基类补充泛型参数并修改直接子类第三步沿继承链逐层修复子类签名第四步运行全部单元测试并处理编译错误。每个阶段都标注了明确的完成条件。这次Codex的表现和之前完全不同。它严格按照任务清单逐层推进每完成一个阶段就在变更日志里记录具体的类型签名变化。遇到编译错误时它不是慌张地试图往回退而是先查看变更日志里已经做了什么再对照当前编译器的报错信息推断出缺失环节。最终整个重构在四十多分钟内完成后面接着跑了完整测试只有两个调用方需要微调。那次经历让我意识到AI并不是不擅长做复杂的重构而是需要一个帮助它保持全局稳定的任务框架。一旦框架搭好它的类型推导能力、跨文件关联理解力、编译错误的分析能力都会得到充分发挥。5.2 老项目技术债清理AI主动给出历史迁移清单第二个让我印象深刻的场景是在一个维护了五年的老项目里。这个项目里散布着大量已废弃的commons包调用、手工字符串拼接的SQL、以及完全被后来者替代的旧工具类。正常情况下清理这些技术债需要人工在每个文件中识别废弃调用工作量巨大排期上总是被优先级更高的需求压在后面。superpowers模式下的处理方式让我很惊喜。我在任务清单里给出的目标是对整个项目的废弃API使用情况进行全面摸底产出一份可执行的迁移清单。Codex在约束文件的技术栈说明中看到了项目依赖列表然后结合项目概览扫描了全部源代码文件最后在变更日志里生成了一张清单哪些文件用了哪些废弃API、建议替换方案是什么、影响范围多大、受影响测试有哪些。这轮操作里Codex并没有直接改写代码——因为我知道一次改太多风险极高只让它做摸底和规划。但产出质量已经足够我安排后续的迁移排期。而且这份摸底结果也变成了项目长期知识资产之后任何新人接手代码时都可以通过这份清单快速理解遗留系统的薄弱点在哪里。AI借助superpowers从按需生成代码变成了主动做项目诊断这个能力边界的突破是我以前没有预料到的。5.3 测试生成策略的调整先摸清行为边界再编写断言在用superpowers前后我对于让AI写测试这件事的看法也发生了变化。默认模式下Codex生成的单元测试通常只是简单覆盖几个正常路径对边界条件和异常路径的覆盖不足。更麻烦的是它写出的测试经常依赖它自己刚生成的新代码里的实现细节一旦实现稍作调整测试立刻到期。superpowers模式让我找到了一个更可靠的测试生成策略。我先让AI读取约束文件中的项目测试规范比如必须使用AssertJ、禁止mock静态方法、核心业务方法必须有异常分支覆盖然后在任务清单里把测试任务分解成两个阶段第一阶段是行为摸底——AI先阅读待测类的完整实现和已有测试在变更日志中记录每个方法的公开行为、边界条件、异常路径第二阶段才是编写测试——基于第一阶段的行为清单逐条生成断言。这样做的好处是生成的测试不再是对实现代码的简单镜像而是对接口行为的真实描述。即使实现内部重构了只要对外行为不变测试就依然有效。这个策略在后来一次小范围重构里得到了验证我手工重构了核心类的内部实现原有的AI生成测试全部通过几乎没有需要修正的地方。这在过去使用默认模式时是很少见的情况测试总是会对内部实现细节产生脆弱的依赖。6. 使用过程中真实踩过的坑三个阶段三种翻车方式6.1 阶段一目录结构错误导致AI根本找不到上下文第一次配置superpowers时我犯了一个特别低级的错误把配置文件放在了一个嵌套路径里比如.superpowers/config/settings/而Codex实际读取的路径是.superpowers/config.yaml。由于目录不一致AI每次启动时都提示找不到初始化文件我还一度以为是安装不完整反复重装了三次。排查过程也挺折腾。我先检查了Codex的会话输出日志发现AI根本没有执行初始化读取动作说明问题不在于AI是否理解prompt而在于信息根本没有被AI可见。后来我逐条打印Codex能看到的所有文件名才发现路径偏差。这个坑给我的教训是你写的提示词再精确如果文件放错了位置AI什么都读不到。所以安装完以后一定要先做一次视野验证——向AI确认你能看到哪些文件或直接让它输出项目里存在的配置文件列表。如果AI列出的和你实际创建的完全吻合才算真正装好了。6.2 阶段二任务描述太笼统AI自己加戏另一个让我哭笑不得的问题发生在任务清单的写法上。一开始我以为任务描述写得更概括一点AI能有更多自由度但结果并不理想。有一次我让它优化这个模块的异常处理逻辑它马上开始大规模重构把整个catch块结构全部推倒重来改服务层接口签名甚至连日志格式都换了。虽然这些改动单看质量不差但完全脱离了我原本想控制的范围。项目风险一下子飙升我不得不让AI回退重做。后来我把任务描述改成仅处理该模块中未捕获的受检异常新增集中式异常处理但保持所有方法签名不变不修改业务逻辑AI就开始老老实实地在我指定的边界内工作。由此我总结了一个写任务清单的公式目标动作 操作范围 绝对禁止 验证标准。四要素缺一不可。只有目标动作没有操作范围AI会自己圈地没有绝对禁止AI总会跨越你心理底线的边界没有验证标准你永远不知道它什么时候算真正完成。6.3 阶段三上下文文件互相冲突AI无所适从第三个坑是我把约束文件和任务描述同时写得过于详尽导致两者之间产生了矛盾。举个例子我在约束文件里写了禁止使用Lombok但在任务清单里又无意间写了利用Lombok的Builder简化对象创建。AI加载到这两个互相冲突的指令后行为变得非常古怪有时候它遵守了约束但违反了任务描述有时候又反过来甚至在某一次操作里同时写出了Lombok注解和手工setter的混合体结果编译直接失败。这个问题的修复方式倒不复杂但给了我一个很深的体会superpowers虽然大大增强了AI的上下文能力但也把用户对上下文的组织能力要求抬高了。你必须像维护代码一样维护上下文文件保证它们之间的一致性。我后来在每次修改任务清单时都会顺手扫一遍约束文件确认没有新的冲突。最好再加一个验证步骤在每次会话开始前让AI从context和tasks目录中提取出所有指令按优先级列出来你再快速审查一遍看看有没有明显的矛盾。7. 实际体会什么样的团队适合上superpowers什么样的不适合7.1 适合的团队画像经过一段时间的使用我大致理解了superpowers在什么样环境下能发挥最大价值。在我看来最适合上superpowers的团队有三个特征第一团队里有大量高频重复但流程复杂的编码任务比如多模块重构、跨层接口调整、技术债的逐步清理。这类任务规模大、状态多、步骤长正是AI在默认模式下最容易翻车的类型。第二团队的代码规范已经相对明确有沉淀的编码约定或评审清单。这意味着你容易把这些规范转化成约束文件AI能更准确地遵循团队标准而不是按照模型训练数据里的平均风格来写代码。第三团队愿意花一点前期成本去维护上下文文件。这不是一蹴而就的事情约束文件和项目概览需要持续更新。如果你们团队连基本的文档都懒得写那superpowers上线后会变成另一个没人维护的文档。7.2 不适合的场景反过来有三类场景我建议不要强行上superpowers。第一种是极高频的问一句答一句模式。如果AI对你来说就是一个加强版单行补全工具每次任务都在五分钟内完成完全没有必要搭建一整套上下文系统。这是杀鸡用牛刀反而增加了初始配置成本。第二种是完全没有代码规范、编码风格极度自由的项目。这种情况下即使你给了AI很具体的约束文件它的风格输出依然很难符合每个开发者的个人习惯约束反而变成了束缚。第三种是项目本身规模极小、逻辑简单且没有长期演进的预期。在单文件脚本类工具、一次性工具脚本这类场景里上不上superpowers意义不大AI本身在短上下文里工作已经足够可靠。7.3 如果从零开始尝试我的建议顺序如果你决定在自己的项目里试试superpowers我给你一套从零到一的建议路径按顺序执行能避免不少弯路先选择一个有代表性、但你并不急于交付的项目来试水。不要一开始就用它搞最核心的生产系统否则一旦出问题你很容易归咎于工具本身。花一个星期手动使用先不追求效率目标是理解AI在superpowers模式下和你以往使用习惯的差异。从第二个星期开始根据第一次试水中的体会逐步完善你的约束文件和项目概览。建立一个固定的checklist每次会话结束时确认变更日志已更新、任务清单状态准确、约束文件没有新增冲突。熟练之后再把superpowers迁移到真正的大型重构任务上这时的体验提升会比起步阶段显著许多。8. 最后分享一个让superpowers效果翻倍的小技巧如果你已经用上了superpowers或者读完上面的内容准备尝试我今天最后想分享一个小技巧它是我个人觉得投入产出比最高的一个设置给AI设定先复述再动手的行为准则。具体做法是在初始化提示词里加一条明确规则当用户下达一个复杂任务时AI必须先用三到五句话复述它对任务的理解包括目标、范围、约束、可能的风险点得到用户确认后才能真正开始修改代码。如果用户没有回复确认AI不得直接动手。这个规则的价值在于它把AI的脑内理解强制变成了可检查的输出。很多时候AI在default模式下动手修改完了一堆文件你才发现它的理解和你的要求根本不是一回事这时候返工成本很高。而先复述、再动手把这个问题在开始前就暴露出来了。你只需要花十几秒扫一眼它的复述就能知道它是不是抓到了任务的核心。在我的实际使用中这个规则几乎消除了所有由于任务理解偏差导致的大规模返工我认为它是所有superpowers配置规则里性价比最高的一个。如果你只能记住今天文章里的一条建议那我希望是这条。