企业官网建设流程全解析

Superpowers 这个项目，最近在开发者圈子里讨论度确实不低。它本质上是给 Codex CLI 这类终端 AI 编程助手加装的一套"技能包"——装上之后，AI 不再只是被动地等你敲指令，而是会主动思考、拆解任务、自己造技能，把一个模糊的大需求变成一步步可执行的小计划。如果你是那种已经用上 AI 写代码、却总觉得它像个会接话的实习生、动不动就把整个项目搅浑的人，这篇就是为你准备的。

我一开始接触到它，是因为每次让 Codex 改一个稍微大点的需求，它总是"秒回"一堆改动，方向对不对不确定，反正 diff 先给你铺满。后来看到 obra 这个项目，核心思路只有一句话：给 AI 装上一层"方法论"，让它在动手之前先走完思考、规划、拆解这套流程。这篇就把我安装、配置、实战 Java 项目的过程完整捋一遍，包括安装环境、核心技能怎么用、Java 场景怎么定制，以及我踩过的坑。

如果你连 Codex CLI 都还没装，也不影响阅读——你会看到一种"怎么把一个只会接单的 AI，训练成有章法的同事"的思路。这套思路跟具体工具无关，迟早用得上。

1. Superpowers 到底是什么：不只是插件，是给 AI 补上"方法论层"

1.1 它解决的真实痛点

先说说我为什么对这个项目感兴趣。用 Codex CLI 或者类似的终端 AI 编程工具，最常见的几个痛点，我相信用过的朋友都有共鸣。

第一个痛点，AI 拿到需求就直接动手，没有先确认理解是否一致。你说"优化登录模块"，它默认你是要重构，结果你只是想加个验证码。第二个痛点，大任务没有拆解，AI 在一个上下文里闷头改，改到一半上下文窗口不够，前面做的决定又忘了。第三个痛点，每次对话都在"重新发明轮子"，昨天刚教过它怎么处理某个业务规则，今天换个会话，它又不知道了。

Superpowers 的思路很直接：既然 AI 本身不擅长"方法论"，那就给它一套写好的方法论，让它照着执行。注意，这不是传统意义上"给你提供某些功能的插件"，而是一个"教 AI 怎么干活的框架"。它通过向 Codex 的技能目录写入一组 Markdown 格式的技能定义，改变了 AI 处理问题的默认路径。

1.2 核心设计思想：Skill 即方法论

Superpowers 里最核心的概念是 Skill（技能）。每个技能就是一个目录，目录里包含一个 SKILL.md 文件，用结构化的方式写了"这个技能是什么、在什么场景用、具体怎么执行"。Codex 本身支持从指定目录读取技能定义，所以 Superpowers 的安装过程本质上就是"把一堆高质量技能定义放进 Codex 的技能目录"。

默认带来的一组技能覆盖了：Thinking（系统化思考）、Planning（任务规划）、Skill Creator（技能创造）、Brainstorm（头脑风暴）、任务拆分与跟踪、系统信息扫描等。每个技能都设计成可组合的，比如你让 AI 先用 thinking 技能分析需求，再用 planning 技能给出实施方案，它就会按步骤执行，而不是像以前那样直接生成代码。

有个细节值得单独说：这些技能是按"程序化"的方式组织的。所谓程序化，就是每个技能文件都像一份可执行的食谱，既有"什么时候用这道菜"的判断条件，也有"一步一步怎么做"的具体步骤。AI 读到的不是一句飘着的"你要多思考"，而是"先列已知信息、再列未知信息、给出三个可选方案、标注每个方案的风险"，照着做就行。

1.3 它不做什么：先给预期管理

把定位说得再清楚一点，Superpowers 不做什么。

它不帮你写代码。它不直接提供某个业务功能，也不替代 Codex 本身的代码生成能力。它是"元工具"，作用在 AI 的行为层，不是功能层。

它不改变模型。别指望装上它之后，你的小模型突然变成大模型，或者说它能让 Codex 突然"变聪明"。它改变的是 AI 工作的流程，不是 AI 的智力水平。

它不保证 100% 遵循。技能文件对 AI 来说是"操作手册"级别的建议，AI 有一定自主权。模型遵循能力越强，技能效果越明显；如果模型本身遵循指令的能力弱，技能的效果也会打折扣。

想清楚这三点，你就不会对它产生不切实际的期待。它解决的是"流程问题"和"复用问题"，而不是"智商问题"。

这个设计最大的好处是行为可控。以前你调教 AI，靠的是在 prompt 里反复写"不要急着给代码，先想清楚"，每次都要写，而且 AI 不一定买账。现在这套方法论被固化成了技能文件，AI 看到任务后会主动匹配技能，相当于你把 SOP 写进了它的工作记忆里。而且这个能力是可积累的——你今天调教好的某个业务技能，明天、下个星期、下个项目都能复用，不用重新教。

我个人的感受是：它并没有让 AI"变聪明"，而是让 AI"变靠谱"。聪明是模型的事，靠谱是流程的事。Superpowers 管的正是流程。

2. 安装与环境准备：三分钟跑起来，但这些前置条件要看清

2.1 前置依赖与准备

安装 Superpowers 之前，先确认几件事，不然大概率会卡在莫名其妙的地方。

第一，你需要先装好 Codex CLI。Superpowers 默认的安装脚本会探测 Codex 的配置目录，如果你还没装 Codex，脚本装完技能也"无处安放"。Codex CLI 的安装方式官方仓库写得很清楚，支持 npm 和原生安装包两种方式，这里就不展开了。

第二，系统环境。macOS 和 Linux 我都实测过，Windows 建议走 WSL，纯 Windows 原生环境会有路径和换行符问题，我后面常见问题部分会详细说。

第三，网络要能访问 GitHub。安装脚本要从 GitHub 拉取技能定义，如果你的网络访问 GitHub 不稳定，第一步 curl 就可能卡住。遇到这个情况先确认网络连通性，把网络问题解决到"能在浏览器打开 GitHub"的程度，再继续。别急着怀疑脚本。

第四，确认你的 Codex 版本支持 skills 机制。skills 是 Codex 后来加入的能力，如果你的 Codex 是老版本，可能根本不读技能目录。装 Superpowers 之前，建议先把 Codex 更新到较新版本。

2.2 安装过程详解

安装命令很简单，官方提供的是单行脚本（具体命令以仓库 README 为准）：

curl -sSL https://superpowers.dev/install.sh | bash

执行之后，脚本会依次做几件事：

1. 检查 Codex CLI 是否已经安装，没装会提示。
2. 在你的用户配置目录下创建技能目录，通常是~/.codex/skills/。
3. 从仓库拉取技能定义到该目录。
4. 首次安装完成后，一般会提示你重启 Codex CLI 会话。

整个安装过程通常在 1-2 分钟内完成，输出里会出现每个技能的安装状态。我建议装完以后不要急着直接用，先做一步验证。验证目录结构：

ls ~/.codex/skills/

正常情况下你会看到一组技能文件夹，比如 thinking、planning、skill-creator、brainstorm 等。看到这些文件夹，说明核心技能已经就位。

提示：千万不要用 sudo 执行安装脚本。脚本会往你的用户目录写文件，用 sudo 不但多余，还可能把技能目录变成 root 所有，导致 Codex 读不到技能，后续排查起来很麻烦。

2.3 安装后的目录结构与验证

技能目录的结构大概是这样的：

~/.codex/skills/ ├── thinking/ │ └── SKILL.md ├── planning/ │ └── SKILL.md ├── skill-creator/ │ └── SKILL.md ├── brainstorm/ │ └── SKILL.md └── ...

每个技能目录里，除了 SKILL.md，可能还有辅助文件。SKILL.md 本身是 Markdown 格式，头部用 YAML frontmatter 写技能的基本信息，包括 name、description、适用场景；正文就是具体的执行步骤和注意事项。Codex 对技能的匹配，主要依赖 description 字段——它根据用户请求的描述去"猜"该用哪个技能，然后读取对应文件。

怎么验证技能真的被 Codex 识别？最简单的方式：在 Codex 里随便问一个问题，看它的回复有没有主动提到"使用 thinking 技能分析"之类的表述，或者你直接显式要求它：

Use your thinking skill to analyze this task before writing code.

如果它真的进入"先分析再动手"的模式，说明技能链路是通的。

如果你发现 Codex 完全没有技能意识，大概率是下面几个原因：

• 技能目录路径不对。不同版本的 Codex 读取技能目录的位置可能有差异，有的版本会用配置项指定路径，先查文档确认。
• 安装脚本与 Codex 版本不匹配。Superpowers 迭代快，有时会针对新版 Codex 做调整，旧版装法在新版本上不生效，去仓库看 README 的更新说明。
• 你自定义了配置目录。如果你用环境变量或--config指定了别的 Codex 配置目录，技能装到了默认目录里，自然读不到。

2.4 关于安装方式的补充说明

除了官方安装脚本，Superpowers 的仓库本身也在持续演进，有的版本支持手动克隆仓库到技能目录的方式。我个人不推荐手动方式，原因很简单：脚本会处理目录结构、权限、版本兼容这些繁琐的事，手动复制容易漏文件，也容易复制出错误的目录层级。

保持更新的习惯也很重要。我大概每隔一个多月会重新跑一次安装脚本，看看有没有技能定义层面的更新。这个项目迭代速度快，新增技能、改进技能描述都是常有的事，跟随更新能让你始终用上最新的方法论设计。但注意一点，更新前先备份你自己定制的技能目录——如果你已经有业务技能沉淀，重跑脚本有可能会覆盖或冲突。备份永远比事后恢复省事。

3. 核心技能拆解：Thinking、Planning、Skill Creator 到底怎么用

3.1 Thinking 技能：让 AI 先想后做

Thinking 是我用得最频繁的技能，没有之一。它的作用非常简单：在 AI 动手之前，强制它先做一轮系统化思考。

具体使用方式是在给 Codex 的指令里明确提"Use your thinking skill"，或者你直接描述场景让它自己判断。比如：

Use your thinking skill to analyze this problem before proposing code changes: <你的需求描述>

AI 读到这条指令后，会按照技能定义逐步执行：拆解问题、列出已知信息、识别未知信息、给出可能的方案和风险，最后才进入编码环节。这个过程看似多花了一步，实际上大幅减少了返工。

我实测下来，Thinking 最有价值的地方是"逼 AI 暴露假设"。比如你给它一个需求："优化订单查询接口"，它会先问清楚：你要优化的到底是性能还是代码结构？现在的瓶颈是数据库慢查询还是网络序列化？有没有压测数据？这些如果没想清楚就直接改，十有八九改了个寂寞。

有个观察可以分享：Thinking 技能产出"思考过程"的方式，跟模型本身的能力强相关。能力强的模型给出的思考过程质量很高，几乎像一份设计评审记录；弱一些的模型则容易流于形式，输出的分析都是为了"凑结构"。这时候别失望，你依然可以通过追问让它把分析落到实处，比如追问"你这个方案里最大的风险点是什么，用数据说明"。

3.2 Planning 技能：大任务拆解的正确姿势

Planning 技能解决的是"AI 处理大任务容易走一步看一步"的问题。它的做法是：把一个大目标拆成阶段性的小任务，每个小任务有明确的输出物和验收标准，然后用待办列表的形式跟踪进度。

我自己在接一个"给旧系统加一个新模块"的需求时，会让 Codex 先走 Planning：

Use your planning skill to create a plan for adding a new payment callback module to this project.

它会产出类似这样的计划：

有了这个计划，最直接的收益是：你可以逐个阶段验收，而不是等它一口气交出一大坨代码再整体 review。对于习惯了"小步提交、频繁验证"的工程师来说，这种分阶段可控的感觉，比原生 AI 编程体验舒服太多。

另外一个心得是：Planning 产出的计划是可以谈判的。Codex 给的阶段划分不一定符合你的预期，你可以直接要求它调整划分粒度、合并阶段、调整验收标准。把计划当成一份草稿来 review，而不是当成圣旨，效果会好很多。

还要提醒一点，Planning 与 Thinking 经常配合使用。Think 阶段弄清楚"做什么"，Plan 阶段理清楚"怎么做"，两者是天然先后关系。我现在的习惯是：中等复杂度以上的需求，一律先 Think 再 Plan，两个技能调用完，才允许 Codex 写第一行代码。

3.3 Skill Creator：让 AI 自己长出新技能

Skill Creator 是 Superpowers 里最有想象力的一个技能。它能让 AI 根据你的一次成功调教，自动生成一个新的技能文件，沉淀到技能目录里，下次直接复用。

举一个真实场景。我在做 Java 项目时，反复要求 Codex 按照团队规范生成 DTO：必须带 Swagger 注解、必须实现序列化接口、字段必须有校验注解。每次都要在 prompt 里写一大段规范说明，烦不胜烦。后来我用 Skill Creator 模式，把我给 Codex 的规范描述和它的最终产出一起丢给它，让它从这次交互中学习并创建一个可复用的技能。

它就在~/.codex/skills/下新建了一个 java-dto-generation 技能目录，把团队规范固化成了 SKILL.md。从那以后，我再做新的接口模块，只需要说一句"Use your java-dto-generation skill"，生成的 DTO 一次到位。

这个机制的本质是：把"你教会 AI 的东西"从对话的临时记忆，变成长期可复用的程序化知识。用我的话说，这是把"人教 AI"变成了"AI 自己总结方法论"。而且技能文件是 Markdown，你能直接编辑，不满意改两行就行。

不过有一点要提醒：创建技能时给 AI 的素材质量，直接决定技能的可用性。如果你只是丢给它一段模糊的"按我们团队规范来"，生成的技能大概率也是模糊的。正确做法是，给它明确的规范条目、正反例子、你之前逐字写过的完整 prompt。输入越具体，产出的技能越可靠。创建完之后，一定要用一个新的会话实际测试一次，发现问题直接改 SKILL.md，迭代两轮基本就稳定了。

3.4 技能组合与数量的边界

最后聊一聊技能之间的组合与数量控制。

技能不是越多越好。技能文件太多，Codex 在判断"该用哪个技能"时会有选择困难，甚至出现技能间指令冲突。比如一个技能说"遇到数据库问题先看慢查询日志"，另一个技能说"遇到性能问题先重构代码结构"，当两个场景重叠时，AI 就会纠结。

我个人的建议：默认技能保持原样，自己新增的技能控制在少量、高复用的范围内，而且命名要清晰、description 要写准，否则 AI 根本不会在合适的时机想到它。判断一个技能是否值得沉淀，就看一条标准：你是否有过三次以上"反复叮嘱 AI 同一件事"的经历。有，就值得；没有，就不值得。

另外，技能描述（description 字段）真的值得花心思。我见过不少人把技能描述写成"用于 Java 开发"，这种描述几乎等于没有——AI 在任何一个 Java 任务里都不会想起用它。正确的姿势是写清楚触发条件，比如"当需要生成 Service 层代码且项目使用 MyBatis-Plus 时使用"。描述越像触发器，技能被正确调用的概率越高。

4. 在 Java 项目里的实战：superpowers java 的正确打开方式

4.1 为什么单独聊 Java 场景

热搜词里有个 "superpowers java"，这其实反映了一个真实需求：Java 项目普遍体量大、规范多、编译链路长，AI 直接上手改代码的翻车率比脚本语言项目高不少。Java 的强类型、框架约束、构建工具链（Maven/Gradle）、团队代码规范，每一样都是 AI 的"扣分项"——上下文稍微漏一点，它就能给你写出一个编不过的类型，或者一份不符合项目惯例的代码。

在这个背景下，使用 Superpowers 的正确姿势不是"装上就完事"，而是围绕 Java 项目做两件事：一是用核心技能规范 AI 的改码流程，二是用 Skill Creator 把团队规范沉淀成技能。我下面按实际项目的操作顺序展开。

4.2 用技能给 Codex 定"Java 规矩"

我实际在 Maven 项目里是这样调 Codex 的，三步走。

第一步先走 Thinking。把需求描述清楚后，让 Codex 先梳理涉及的类、方法、数据流，输出改动范围和风险评估。这一步在 Java 项目里特别重要，因为类之间的依赖关系太容易牵一发动全身。一个"简单"的接口改造，背后可能牵扯 Service、Mapper、缓存、事务、消息队列五个层面。

第二步走 Planning。让 Codex 给出分阶段实施计划，每个阶段都标注涉及的文件和验证方式（编译、单测、集成测试）。这一步能有效避免它改到一半陷入"这个接口需要改，那个接口依赖这个接口"的无底洞。Java 项目的任务拆解粒度要比脚本项目更细，因为编译反馈周期更长，步子太大必然扯到蛋。

第三步动手改。这一步我会要求它在每个文件改完后先编译验证，再继续下一个文件。用 prompt 明确约束它：

After modifying each file, run the compile check (./mvnw -q compile) before proceeding to the next change.

实测下来，这套流程让 Codex 在 Java 项目上的可用性提升了不止一个档次。之前它经常一次改几十个文件，然后编译错误一堆，回头看 diff 根本理不清。现在分阶段小步走，每个阶段都能编译通过，review 起来轻松很多，出问题的范围也小得多。

还有一个细节值得注意：Java 项目的上下文通常很大，开一个全新的 Codex 会话时，我不知道它对这个项目了解多少。为了减少它瞎猜，我会在第一轮 prompt 里就交代清楚项目坐标信息：JDK 版本、构建工具、是否用 Lombok、Spring Boot 还是其他框架。这些信息配合 Thinking 技能，能让它少走很多弯路。

4.3 定制 Java 技能的实际案例

再分享一个技能定制的完整案例。我的团队用 MyBatis-Plus + Spring Boot，代码生成器已经生成了一套基础 CRUD，但团队规范要求 Service 层必须做参数校验、必须写事务注解、Controller 必须统一返回 Result 包装类。这些规范在项目文档里写得很清楚，但每次让 Codex 写新模块都要重新交代。

我把这套规范整理成条目，配上一个符合规范的示例类，一起喂给 Codex，让它从这次交互中学习并创建可复用的技能（参考 3.3 的技能创建流程）。生成的技能文件里固化了这些规则，包括：

• Service 方法必须标注@Transactional（只读查询除外）
• Service 入口必须做参数校验，校验失败抛业务异常
• Controller 返回值统一用Result<T>包装
• 禁止在 Controller 里直接操作数据库

之后新建业务模块时，我只需要描述业务逻辑，Codex 就会按照技能里固化的规则产出 Service、Controller、Mapper 层代码，几乎不用我再逐条校对规范。我把这个技能命名成 service-layer-codegen，description 写清楚触发条件"当需要生成 Spring Boot Service/Controller 层代码时使用"。

这一步的价值，不亚于给 Codex 换了个大脑：你等于把团队的编码约定从人类成员的脑内知识，变成了 AI 的默认行为。新成员还在翻规范文档的时候，AI 已经在按规范给你产出代码了。

4.4 Java 场景的注意事项

Java 场景下有几个特别容易踩的坑，我单独拎出来说，每一条都是真金白银换来的。

第一个坑，构建工具版本问题。如果项目用 Maven Wrapper（mvnw），而 Codex 不知道这一点，它可能会调用系统里不存在的 mvn，编译命令直接失败。建议在技能或项目描述里写清楚："此项目使用 Maven Wrapper，编译命令为 ./mvnw compile"。

第二个坑，Lombok 相关。Codex 对 Lombok 的源码理解经常有问题，因为 getter/setter 是编译期生成的，源码里根本看不到。默认情况下，它可能以为属性没有访问方法，然后给你写出冗余的 getter/setter，甚至把代码改成用反射访问私有字段。解决方法是明确告知项目用了 Lombok，并让它在思考阶段就确认这一点。

第三个坑，Java 版本与语法。如果项目在 Java 8 上维护，而 Codex 默认按高版本语法写，var、switch 表达式、record 这些新特性全会变成编译错误。建议在 Planning 技能输出计划时就明确标注目标 Java 版本，而不是等编译报错了再回头改。

第四个坑，依赖冲突。Java 项目改依赖的时候，Codex 经常会"好心"给你加新依赖却不检查版本，结果引入传递性依赖冲突。让它改 pom.xml 时，最好明确要求"只改必要的部分，不要升级无关依赖版本"。

这几个问题放不进技能文件的话，至少要在每个会话的开头用一两句话交代清楚，比如"本项目使用 JDK 17、Maven Wrapper 构建、启用了 Lombok"。别嫌啰嗦，这几个信息能避免一堆编译期笑话。

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

5.1 安装失败与权限问题

我用一张表把最常遇到的问题列出来，后面再逐个展开。

第一个问题是网络。curl 下载脚本失败的原因多半是网络层面无法访问脚本所在的服务器。排查思路：先手动访问脚本地址，确认能不能打开；如果确认是网络问题，从网络层解决，保证能稳定访问之后重试。这里我不展开具体网络方案，只提醒一点：不要在没确认网络连通的情况下反复重试，没有意义。

第二个问题是 sudo 后遗症。症状是技能目录变成 root 所有，Codex 读不了也写不了。处理方式很直接：

sudo chown -R $(whoami) ~/.codex chmod -R u+rwX,g+rX,o+rX ~/.codex

然后重新启动 Codex 会话，一般就恢复正常了。这个问题的根源只是装的时候多敲了一个 sudo，教训是：凡是往用户目录写的安装脚本，都不要加 sudo。

5.2 技能不生效怎么排查

技能装好了，Codex 却像没装一样，这是我收到最多的反馈。我的排查顺序固定是四步，每一步都对应一类原因。

第一步，确认目录。ls ~/.codex/skills/，看技能文件夹是否真的存在。如果目录是空的，说明安装脚本根本没跑成功；如果目录里有文件夹但 Codex 不读，进入下一步。

第二步，读 SKILL.md 检查格式。重点关注头部 frontmatter 有没有语法错误。YAML 缩进错误、字段名拼错，都可能导致技能加载失败。另外确认 name 和 description 字段非空，这两个字段是技能能不能被触发的前提。如果发现文件是坏的，最快的修复方式是重跑安装脚本覆盖，或者手动从仓库拉一个干净副本。

第三步，显式调用测试。写死命令让 Codex 用技能："Use your thinking skill to analyze this task"。如果显式调用也不生效，说明问题不在技能内容，而在 Codex 对技能机制的支持上——检查你的 Codex 版本是否支持 skills，是否取消了相关配置，或者配置目录是否被环境变量覆盖。

第四步，看日志。Codex 的日志会输出它有没有读技能文件。日志里完全没提到 skills 目录，基本可以断定是配置路径问题。顺着日志里显示的配置路径去检查，比在代码里瞎猜效率高得多。

这四步走完，绝大多数"技能不生效"都能定位到原因。我从经验里总结出一点：这类问题九成是路径或版本问题，技能文件内容本身一般没问题，所以排查时先怀疑环境，再怀疑内容。

5.3 superpowers 能不能用在其他 AI 工具上

经常有人在问"worbuddy 怎么用 superpowers"这类问题，翻译一下就是：我用的不是 Codex CLI，而是别的 AI 编程工具或工作流工具，这套技能能不能直接搬过去。

我的判断是：要分情况看。Superpowers 的技能定义文件是标准 Markdown，理论上不绑死某个特定工具，但实际生效依赖工具的"技能读取机制"。Codex 原生支持从技能目录读取 SKILL.md 并做技能匹配；其他工具如果有类似的自定义指令功能（比如 Claude 的 CLAUDE.md、某些编辑器的规则文件），你可以把技能文件的核心步骤改写成该工具支持的格式，但"自动匹配技能"这个能力大概率会打折扣。

对一个具体工具能不能用，最靠谱的验证方法只有一种：在该工具的文档里查"它支持什么形式的指令注入和规则文件"，然后照着格式转写一个最小技能测试一下。别花太多时间在"迁移所有技能"上，工具之间没法无缝平移，但方法论是可以平移的。

对这种情况，我的建议是：不要贪多，选中两三个最核心的技能（Thinking、Planning）转写过去就够用了。方法论的落地，靠的是一两个关键 SOP，而不是技能数量。我见过不少人把一堆技能文件从 Codex 硬搬到另一个工具，结果格式不兼容、触发不灵敏，最后得出"这工具不如 Codex"的结论——其实只是姿势不对。

5.4 一个容易被忽略的坑：技能冲突

最后补一个我踩过的坑：技能冲突。Superpowers 的生态里已经有人分享各种第三方技能包，看起来都很好，装的时候一时爽，用起来才发现问题。当两个技能对同一个场景给出不同指令的时候，AI 就会陷入两难，输出结果可能融合了两个技能的观点，反而比用一个技能更差。

症状典型表现为：同一类请求，这次输出一种风格，下次输出另一种风格，而且都不是你想要的完整效果。排查方式是把技能目录列出来，看看是否有不同技能描述的是同一类场景。比如你装了一个"后端代码生成"技能，又装了一个"Spring Boot 最佳实践"技能，它们大概率会在生成 Controller 时打架。

我的处理原则是：同类场景只保留一个技能。如果真的觉得两个都有用，就把它们合并成一个，用优先级条款写清楚"当 XX 时按 A 执行，当 YY 时按 B 执行"。技能文件是 Markdown，合并起来并不费劲，但效果会稳定很多。

6. 我个人的踩坑记录与使用心得

6.1 几个容易忽略的细节

装完 Superpowers 之后，有几个细节我花了不少时间才体会到，写出来帮你省点时间。

第一，技能是"建议"而不是"命令"。Codex 对技能的遵循程度，跟模型自身的遵循能力有关。有时候它读了技能文件，但生成结果还是跑偏了。这时候不要指望纯靠技能文件解决，还是要配合明确的 prompt 约束。我的做法是，在关键节点用一句话重申约束，比如"记住，每个文件改完先编译再继续"，效果比只依赖技能好得多。

第二，技能的"触发"不如想象中智能。虽然技能文件里有 description 字段给 AI 做匹配依据，但 AI 能不能在正确时机想起来用，取决于它的判断。最保险的方式是显式点名技能，尤其在你明确知道该用哪个的时候，不要等它自己选。

第三，定期更新有讲究。这个项目迭代很快，思想和实现都在进化。隔一两个月重新跑一次安装脚本是值得的，但更新前先备份你自己定制的技能目录，否则最新版的默认技能可能覆盖你的自定义内容。别问我怎么知道的，问就是经历过一次"辛辛苦苦沉淀的技能被刷掉"的痛。

6.2 给新手的建议

如果你是第一次接触这类"给 AI 编程助手套方法论"的工具，我的建议是不要一上来就想着定制一堆技能。先用默认技能完整跑一个中等规模的任务，把 Thinking、Planning、Skill Creator 三个核心流程走一遍，你才能真正理解它的价值在哪里，也才能判断哪些环节需要调整。

等熟悉了默认行为之后，再开始定制。定制的时候，从"你反复叮嘱过 AI 三次以上"的事情入手，这种场景最适合固化成技能。如果你发现自己每写一个模块都要花两百字描述团队规范，那基本就是 skill creator 出场的信号。别急着把项目所有规范一次性灌给 AI，先挑最痛的那一个试水，跑顺了再扩展。

最后说一句我的真实感受。Superpowers 并没有让 AI 变成不需要 review 的超级程序员，它只是把"怎么让 AI 少犯低级错误"这件事，从一个需要你每时每刻用 prompt 提醒的问题，变成了一个可维护、可积累的方法论体系。对我来说，这就够了。工具会换，模型会换，但"先思考、再规划、后动手、可复用"这套流程，到哪里都用得上。