企业官网建设流程全解析

第一次听说 superpowers 这个词，是在 Codex CLI 的讨论串里。那时候我用的 Codex 还很简单：能读仓库、能改代码、能跑测试，但整体感觉就像一个"很有潜力的实习生"——你说一步它做一步，遇到编译错误就开始原地打转，甚至会在同一个死胡同里撞三次。后来有人提到 olaulau 做了一套叫 codex-superpowers 的 skill 库，装上之后第一反应是：这个 Codex 好像换了一个人。它不再急着动手改代码，而是先拆任务、写测试、看失败、再实现，整个过程像极了一条标准的 TDD 流水线。

这篇文章就是围绕 superpowers 的实际使用体验来写的。我会先讲清楚它到底是什么、解决什么问题，然后给出完整的安装步骤和验证方法，再深入拆解它的核心工作流（TDD、任务拆解、失败恢复），接着单独拉出 Java 项目场景说一说适配细节，最后分享我在实际使用中踩过的坑和排查思路。无论你是刚接触 Codex CLI 的新手，还是已经在用但觉得它不够"稳"的老手，这篇都值得往下看。

1. 什么是 superpowers：给 Codex CLI 装上"职业素养"的操作手册

先说结论：superpowers 不是一个新模型，也不是什么代码补全插件。它本质上是一套高度结构化的 Markdown 指令集，也就是 GitHub 上那个 codex-superpowers 仓库里的内容。这套指令通过 Codex CLI 的 AGENTS.md 机制注入对话上下文，告诉模型在什么场景下应该触发什么流程、按什么顺序执行、每一步有什么验收标准。

1.1 我的真实使用感受：从"实习生"到"熟手"

我最初是在一个 Rust 项目里跑通 superpowers 的。装之前，Codex 面对一个失败测试时，最常见的反应是：直接打开源文件，开始改逻辑，改完跑一次测试，如果还挂，就换个方向再改，直到某一次碰对为止。整个过程没有章法，像是靠概率在做题。装完 superpowers 之后，同样的场景下它会先停下来，新建一个 tracking 文件，把失败原因、当前分支、测试命令全部记录下来，然后按技能列表里定义的"TDD 工作流"逐步执行：先复现测试红，再写最小实现，最后重构。

这种变化不是模型变聪明了，而是"流程约束"生效了。模型还是那个模型，但它手里多了一本"遇到什么情况该怎么做"的操作手册。这就像同样是新来的工程师，有人给他一份清晰的团队规范，他就知道什么时候该写单测、什么时候该重构、什么时候该问人；没人给规范，他就只能凭感觉乱来。superpowers 做的就是这个事情。

1.2 它的本质：技能目录 + AGENTS.md 注入机制

superpowers 的核心机制并不神秘。Codex CLI 本身支持在项目里放一个 AGENTS.md 文件，里面写的是给 AI 的"项目规则"或"操作指引"。superpowers 把大量通用开发场景的指引拆成了一个个独立的"技能"（skill），每个技能就是一个目录，里面放着 SKILL.md 文件，以及可能的示例、模板、脚本。然后它通过一个总控的 AGENTS.md 把这些技能目录的组织方式、触发条件、调用方式告诉 Codex。

实际表现是什么？你在 Codex 对话里输入/skills，它会列出一串可用的技能名，比如：

• TDD workflow：测试驱动开发流程
• Task breakdown：任务拆解与计划跟踪
• Red-green-refactor：红绿重构循环
• Dependency debugging：依赖排查
• IDE workflow：编辑器集成场景

每个技能都有自己的 description 字段，Codex 会根据当前任务语义决定要不要调用，或者你自己手动指定。

这里我想强调一个关键认知：superpowers 不改变 Codex 的生成能力，它改变的是 Codex 的决策路径。生成代码的能力是模型固有的，但"什么时候写测试、先做哪一步、失败了怎么办"这些决策是规则决定的。这就是为什么很多人装了之后觉得 Codex 变靠谱了——不是它变聪明了，而是它不再瞎试了。

1.3 它到底解决了哪些具体问题

我用了一段时间后，把它的收益归纳成三类：

第一类是"路径问题"。默认 Codex 遇到任务时，路径是高度不确定的，经常绕过测试直接改功能代码。superpowers 通过 TDD 流程硬性规定路径：先写测试、先看失败，再写实现。这条路径一旦固定，行为的可预测性就大幅提升。

第二类是"记忆问题"。Codex 上下文有限，我做一次多文件重构时，它经常做着做着就忘了前面的约定。superpowers 的 tracking 文件机制让它在每次改动前把当前目标、已完成项、未完成项、已知风险写进一个文件，每次继续工作时先读这个文件。这就等于给 AI 装了一个外部记忆。

第三类是"恢复问题"。失败是常态，但模型面对失败时的默认策略是"猜下一个答案"。superpowers 会要求模型先复现失败、记录失败、分析根因，再决定修复方案。这个过程听起来朴素，但在长任务里的价值极高，能省下大量来回试探的时间。

2. 安装与首次启动：从 clone 到技能生效的完整过程

安装 superpowers 本身不复杂，但里面有几个细节如果没注意，很容易出现"装了半天/skills还是空的"的情况。我按自己当时的操作过程一步步拆解，你照着走一遍就能跑通。

2.1 前置环境：Node.js、Codex CLI、Git

superpowers 本身不依赖 Node.js，但你本机要能跑 Codex CLI，而 Codex CLI 一般安装在 Node 环境里。所以前置条件就三条：

• Node.js 18 或更高版本
• Codex CLI 已经安装并且登录了 OpenAI 账号（codex --version能正常输出版本号）
• Git 能正常 clone 仓库

这三条看似基础，但我当时在第二台机器上装的时候，因为 Codex CLI 版本太老，/skills这个命令一直没反应，后来升级了 Codex 才正常。所以如果你后续遇到技能不加载，先检查版本是不是太旧。

2.2 三分钟安装路径

我的安装路径分成三步，每一步都可以验证是否成功。

第一步，克隆仓库。官方仓库地址是https://github.com/olaulau/codex-superpowers，为了节省体积可以加--depth 1只拉最新版：

git clone --depth 1 https://github.com/olaulau/codex-superpowers.git

我习惯把它放到~/codex-superpowers这样固定的位置，因为后面配置文件里要写绝对路径。位置换来换去容易导致路径失效。

第二步，找到你项目里的 AGENTS.md 配置。Codex CLI 会按层级加载指令：全局配置在~/.codex/AGENTS.md，项目配置在当前工作目录的AGENTS.md。superpowers 的官方 README 里建议的方式是，在你的项目目录下新建或编辑一个 AGENTS.md，往里面写入对 superpowers 目录的引用。

我当时是在自己的项目根的 AGENTS.md 里加了这样的引用片段（具体写法以你 clone 下来的 README 为准）：

## Available Skills This project supports the superpowers skill system. Run /skills to list available skills. Skills are defined in ~/codex-superpowers/skills.

这里的关键是给出技能目录的绝对路径，让 Codex 能顺着路径找到 SKILL.md 文件。

第三步，配置 Codex 的全局指令文件。如果你希望 superpowers 对所有项目都生效，而不是只在某个项目里生效，可以直接编辑~/.codex/AGENTS.md，把同样的引用写进去。我实测下来，全局生效更适合我，因为我的开发环境里经常同时开好几个仓库，不想每个仓库都单独配一遍。

不过要注意：全局 AGENTS.md 的内容会被所有会话加载，如果里面写了太多技能描述，会白白消耗上下文窗口。我的做法是全局只放一个入口说明，具体的技能描述让它按需读取。

2.3 验证安装是否生效

装完之后，进入你的项目目录，启动 Codex：

cd /path/to/your/project codex

进入对话界面后，输入/skills。如果一切正常，你会看到一份技能清单，里面列出了所有可用的技能名、描述和触发方式。如果这个命令没有反应，或者提示找不到技能，大概率是 AGENTS.md 里的路径写错了，或者文件名不对（后面排查章节我会细说）。

2.4 不同系统的注意事项

我在 macOS 上用得很顺利，但在帮朋友排查时发现，Windows 上如果用的是 WSL 2 环境，跨文件系统访问会有性能问题，建议把 superpowers 仓库 clone 到 WSL 的 home 目录下，而不是/mnt/c下面的 Windows 目录，否则每次读取技能文件都有肉眼可见的延迟。

另外，Linux 服务器上使用时要留意文件权限。如果遇到Permission denied，执行一次：

chmod -R u+r ~/codex-superpowers

这些问题都不难解决，但它们是"装了但没生效"的高频原因。

3. 核心工作流：TDD、任务拆解和失败恢复这三板斧

superpowers 最值钱的部分不是安装本身，而是它内置的那套工作流。这套工作流不是凭空造出来的，它几乎就是把一支成熟开发团队的操作规范翻译成了 AI 能执行的指令。我用下来，最重要的就是三板斧：TDD 流程、任务拆解、失败恢复。

3.1 为什么 TDD 是 superpowers 的第一技能

如果你让 Codex 直接写一个功能函数，它通常会先给你一坨代码，然后让你自己测试。但让它按 TDD 流程走，顺序就完全反过来了：先写测试、跑测试确认失败、再写实现、再跑测试确认通过。这个顺序的意义在于，测试先行实际上是把"需求"硬编码成了可验证的契约。

superpowers 的 TDD 技能会指示模型做这些事：

1. 先阅读现有测试文件的风格，理解断言库和测试框架
2. 在动手写实现前，先写一个新测试，这个测试描述期望行为
3. 运行测试，确认它是红的（failed），并且失败原因正是"该功能不存在"或"行为不符合预期"
4. 再写最小实现，只为了让这个测试变绿
5. 运行整个测试套件，确认没有回归
6. 最后重构，清理重复代码

这个流程看起来死板，但就是这种死板，治住了模型"跳步"的毛病。我见过最典型的场景是：没有 TDD 约束时，模型会在写实现之前先顺手改了一堆无关代码，最后测试红的时候根本不知道是哪里出了问题。按 TDD 流程走，每一步都有明确的验证点，定位问题的成本大幅降低。

3.2 红-绿-重构循环在 Codex 里怎么实际操作

我举一个具体例子。假设我要给一个订单模块加一个"超过 30 分钟未支付就自动取消"的逻辑。

没有 superpowers 的时候，我可能会直接让 Codex"在 OrderService 里加一个 cancelExpiredOrders 方法"。它会生成代码，然后等我反馈。

有 superpowers 的情况下，它会先问我要不要启动 TDD 工作流，然后自动进入以下步骤：

codex> /tdd

它先创建一个测试文件。假设项目是 TypeScript + Vitest，它会生成类似这样的测试骨架：

import { describe, expect, it } from 'vitest'; import { OrderService } from './order-service'; describe('OrderService', () => { it('should mark orders unpaid for over 30 minutes as canceled', () => { const service = new OrderService(); const order = service.createOrder({ createdAt: new Date(Date.now() - 31 * 60 * 1000) }); service.cancelExpiredOrders(); expect(order.status).toBe('canceled'); }); });

然后它立刻跑一次测试。注意，这时候cancelExpiredOrders方法根本不存在，测试必然失败。它会记录这个失败，把这作为"红"的证据。

接下来，它写最小实现，再跑一次测试，直到变绿。最后它检查有没有重复代码或者可以提炼的公共逻辑。

整个过程你会看到 Codex 对话里出现清晰的"RED → GREEN → REFACTOR"标注。这种可追踪的执行方式，是我认为 superpowers 带来的最大体验提升。

3.3 任务拆解：用 plan 文件给 AI 装外部记忆

TDD 解决的是"每一步怎么走"，任务拆解解决的是"整个任务怎么不跑偏"。

superpowers 内置了一个任务拆解技能，它会引导模型把大任务拆成多个小步骤，并把每一步写进一个 plan 文件。这个文件通常放在项目的一个约定位置（比如docs/plan.md或者.superpowers/plan.md），里面记录的字段包括：

这个文件的作用是让 Codex 在长任务中随时"复盘"。我试过一个比较大的重构任务，涉及 6 个文件、4 个测试。如果没有 plan 文件，Codex 干到一半就会忘记自己最初设计的接口约束，甚至把已经确认过的 API 结构改掉。有了 plan 文件之后，每次继续，它都会先读一遍 plan，再决定下一步。这就像是给 AI 配了一个记事本，治的是模型的"短期记忆焦虑"。

我自己在后面做自定义技能的时候，也会默认给每个复杂任务配套一个 plan 文件模板，这个习惯就是被 superpowers 带出来的。

3.4 失败恢复：不猜、不蒙、先复现

模型面对失败测试最大的问题是：它倾向于"猜一个更可能对的答案"，而不是"找到失败的真实原因"。superpowers 的依赖调试和失败恢复技能，做的就是把后者强行变成默认行为。

它的实际流程是：

1. 完整记录失败输出，粘贴测试日志
2. 尝试本地复现这个失败，确认不是环境问题
3. 定位失败发生的函数或模块
4. 分析根因，可能的原因列出来
5. 对每个可能原因写一个最小验证
6. 找到根因后，再按 TDD 流程修复

我在一个 Python 项目里遇到过循环依赖导致 import 时崩溃的问题。普通操作下，Codex 会直接改 import 结构，然后反复试错。但按 superpowers 的调试技能走，它会先让我提供完整的调用栈，然后写一个最小脚本复现失败，确认根因是两个模块互相依赖，再把其中一个依赖关系通过延迟导入解除。整个过程只改一处代码，测试一次通过。

这个"先复现再定位"的思维，其实是任何资深工程师都知道的基本方法。superpowers 的价值在于，它把这种思维写成了模型必须遵守的指令，让 AI 没机会走捷径。

4. Java 项目实战：superpowers 在 Maven/Gradle 场景下的适配

我在 Java 项目里用 superpowers 的经历格外有代表性，因为 Java 项目对 Codex 来说几乎是"重灾区"：构建慢、测试慢、语言冗余、项目结构复杂。直接裸用 Codex，体验往往很糟。但配上 superpowers 之后，Java 项目也能跑得相对顺。

4.1 Java 项目为什么是 Codex 的重灾区

Java 项目有三个特点，每一个都天然克制 AI 的发挥。

第一个特点是构建系统重。Maven 或 Gradle 的构建时间动辄几十秒，甚至几分钟。如果模型每次改完代码都全量构建，一次任务可能搭进去一个小时。它又不会主动判断"这次改动只需要增量编译"，所以经常把时间浪费在无意义的等待上。

第二个特点是项目结构复杂。Java 项目的目录层次深、类名长、包名多，模型很容易找不到该改的文件。我遇到过它打开一个 Controller 文件夹里三个相似命名的类，改错了一个，然后整个任务链全部崩溃。

第三个特点是测试反馈慢。JUnit 测试和断言风格相对正式，模型写出来的测试经常因为生命周期注解不对、mock 方法不匹配而失败，调试成本高。

4.2 我定义的 Java 技能集：构建、测试、断言风格

superpowers 默认技能更偏向 Node/Python 等轻量生态。我针对 Java 项目做了一套自己的技能集，放在~/codex-superpowers/skills/java/下面。这里把我的设置分享给你：

第一个技能是"Java 增量构建"。它的指令核心是：优先使用 Maven 的增量编译，避免无意义的全量清理。具体规则是：

• 如果只修改了单个模块，执行mvn -pl <module> -am test而不是mvn clean test
• 如果项目的目标文件存在，优先mvn compile而不是mvn clean compile
• 确认构建工具：是 Maven 还是 Gradle，主命令分别用mvn和./gradlew

第二个技能是"JUnit 5 测试规范"。它会要求模型遵循以下约定：

• 使用@DisplayName说明测试意图
• 断言使用 AssertJ 的assertThat风格，而不是裸 JUnit 的assertEquals
• mock 使用 Mockito，遵守given/when/then三段式结构
• 测试类命名用XxxTest，测试方法用should_xxx格式

第三个技能是"上下文精简"。Java 源码长得离谱，模型很容易把整个文件塞进上下文。这个技能要求模型在读取 Java 文件时，优先提取类签名、方法签名、注解，跳过 getter/setter 大段样板代码。

4.3 一个具体的 JUnit 用例生成过程

我在一个 Spring Boot 项目里，让 Codex 配合 superpowers 给 UserService 生成"找不到用户时抛异常"的测试。它的操作路径非常清晰：

先检测项目的测试基础设施：

ls src/test/java cat pom.xml | grep -A 2 "junit"

然后生成 JUnit 5 测试文件：

@DisplayName("UserService") class UserServiceTest { @Test @DisplayName("should throw UserNotFoundException when user not found") void should_throw_exception_when_user_not_found() { UserRepository repository = mock(UserRepository.class); when(repository.findById(99L)).thenReturn(Optional.empty()); UserService service = new UserService(repository); assertThatThrownBy(() -> service.getUser(99L)) .isInstanceOf(UserNotFoundException.class) .hasMessage("User not found with id: 99"); } }

这个测试生成过程最大的亮点是：它没有直接去改 UserService 的实现，而是先运行测试，看到UserNotFoundException类是 missing 的失败结果，再去创建异常类、修改 UserService，最后重新跑测试。

整个过程里，Codex 没有出现"改完实现却忘了补异常类"的低级错误，因为 TDD 的红-绿循环天然保证了每一步都有验证。

4.4 上下文管理：Java 项目如何省 token

Java 项目的上下文消耗比脚本语言大得多，我总结了几条实测有效的方法：

第一，精简技能目录。superpowers 默认包含大量技能，但一个 Java 项目可能用不到那些前端、移动端相关技能。我会在项目的 AGENTS.md 里只引用 Java 相关的技能目录，减少模型每次加载的指令数量。

第二，开启"按需读取"。在自定义技能里写清楚：不要一次性把整个项目的 AGENTS.md 和所有源码读进上下文，而是先读取目录树，按需打开具体文件。

第三，对大文件做分段提示。如果一个 Java 类超过 400 行，让模型优先读取方法签名列表，只再打开它认为需要修改的方法所在的区域，而不是从第一行读到第 400 行。

这套组合拳下来，同样的 Java 重构任务，我的 token 消耗大概降了三分之一，而且正确率还更高了。因为上下文越干净，模型越不会因为无关代码而"分心"。

5. 排查实录：技能未生效、配置失效与上下文爆炸

任何工具用久了都会踩坑，superpowers 也不例外。我不打算只给结论，而是把这几次典型的排查过程完整写出来，这样你遇到类似问题时可以按同样的思路排查。

5.1 问题一：装了但/skills列表是空的

这是我见过最多的问题，也是最容易犯的错。我当时在一台新的 Linux 机器上 clone 了 superpowers，配置也写了，但进入 Codex 后输入/skills，它回了一句"unknown command"。

我的排查路径是分层的：

第一步，检查技能目录本身是否存在：

ls ~/codex-superpowers/skills

如果目录不存在，说明 clone 没成功或者路径错了。

第二步，检查 AGENTS.md 文件的名字。Codex 只认AGENTS.md这个精确的文件名，不认agents.md或Agent.md。在 Linux 和 macOS 上，文件名大小写是敏感的。我排查了一圈，发现问题就是我把文件写成了agents.md，Codex 直接忽略了它。

第三步，检查配置文件里是不是有语法错误。Codex 的 config.toml 里如果某个字段写错了，它可能不报错，但行为完全不对。比如引用了不存在的路径，它也不会提示，只是静默忽略。

这个排查顺序很重要：先确认文件和目录存在，再确认文件内容可读，再确认配置语法正确。很多人一上来就改配置文件，结果问题只是少了个s。

5.2 问题二：Codex 版本升级后配置字段变了

superpowers 是紧跟 Codex CLI 的变化走的。我第一次遇到"昨天还好好的，今天突然不认技能"的情况，就是 Codex 升级之后，配置文件里的某个旧字段被废弃了。

我当时的处理方式是：先看 Codex 的更新日志，确认配置项变化；然后对比 superpowers 仓库里的 AGENTS.md 模板，看它是否已经更新了推荐写法。

这类问题没有一劳永逸的解法，只能保持两个习惯：一是 clone 了 superpowers 之后不要放着不管，经常git pull拉最新版；二是升级 Codex CLI 之后，第一时间跑一个简单的/skills验证，早发现问题早处理。

另外，不要直接修改原仓库里的文件。如果你改了~/codex-superpowers里的内容，下次git pull很容易产生冲突。我的做法是：原仓库保持只读，所有个性化配置都通过项目里的 AGENTS.md 覆盖。

5.3 问题三：上下文窗口被打满了

superpowers 技能一多，AGENTS.md 里引用的指令长度就会膨胀。Codex 的上下文窗口是有限资源，如果技能说明占掉太多，留给实际代码和测试的上下文就少了，模型会表现得明显变笨。

我遇到的典型场景是：在一个大型 TypeScript 项目里，Codex 突然开始频繁忘记前面已经确认过的接口定义。排查之后发现，根因是全局 AGENTS.md 加载了 20 多个技能的完整说明，每次对话光技能说明就吃掉了一大块上下文。

解决办法有三个：

• 全局只放精简入口，不放完整技能说明，让模型按需读取
• 将不常用的技能移到独立目录，通过对话中手动指定技能名触发
• 对常用技能，用更短的语言重写 description，把不必要的示例代码移出主文件

我最后是把技能目录分成了core和extended两层，核心技能常驻，扩展技能按需加载。这样既保留了能力，又控制了上下文开销。

5.4 问题四：Java 项目 Maven 测试一直失败

这个坑放在 Java 场景下特别典型。superpowers 默认的测试技能总是假设项目用 npm test 或者 pytest，碰到 Maven 项目就抓瞎。

我在一个 Maven 项目中遇到过它反复执行mvn test，因为某个模块需要先 install 依赖，导致一直失败。排查后发现，是技能里没有定义"如果项目是多模块 Maven 项目，先mvn -pl <module> -am install -DskipTests"这个规则。

这类问题的通用排查思路是：把构建失败视为环境适配问题，而不是模型能力问题。默认技能覆盖的是通用场景，你要在自己的 AGENTS.md 里补充针对当前项目的"局地知识"，比如该项目用什么构建工具、测试框架是什么、有没有特殊的环境变量要求。补充完之后，同样的问题一般就不会再犯。

6. 自己写一个技能：把团队规范变成 AI 肌肉记忆

用熟 superpowers 内置技能之后，你大概率会走到这一步：想把自己团队的一些规范也变成 AI 的"肌肉记忆"。这一步其实比想象中简单，核心就是会写 SKILL.md。

6.1 技能目录结构和 SKILL.md 写法

一个技能就是一个目录，目录名是技能名，目录里至少要有一个 SKILL.md 文件。SKILL.md 的开头是一个 YAML frontmatter，里面包含两个字段：

--- name: "conventional-commit-zh" description: "当用户要求生成 Git 提交信息时，使用中文撰写符合 Conventional Commits 规范的提交信息" ---

name是技能名，description是触发条件描述。Codex 会根据 description 的语义匹配来决定是否调用这个技能。所以 description 要写得具体，最好包含触发场景。

frontmatter 下面是技能的具体指令正文，可以写任何你想让模型遵守的规则。格式上建议用明确的步骤列表，而不是大段文字。模型对结构化指令的遵循度明显更高。

6.2 一个示例：强制输出中文提交信息

我在国内团队做项目时，最头疼的就是模型默认生成英文提交信息。我写了一个技能，效果非常直接。

在~/codex-superpowers/skills/cn-commit/SKILL.md里：

--- name: cn-commit description: "生成 Git 提交信息时使用中文，遵循 Conventional Commits 规范" --- 当需要生成提交信息时，遵守以下规则： 1. 用中文写 subject 部分，不要用英文 2. subject 第一个词是提交类型：feat、fix、docs、style、refactor、test、chore 3. 格式为 "类型(模块): 简短描述"，例如 "feat(订单): 增加超时自动取消逻辑" 4. 如果有对应 issue，在正文中引用 5. 描述保持一句话，不超过 50 个字符

写完之后，下次让 Codex 帮你 commit，它就会自动使用中文提交信息，而且格式还会带上类型和模块前缀。这个技能我用了大半年，非常稳定。

6.3 让技能支持参数和条件分支

SKILL.md 里也可以定义更复杂的逻辑。我当时为了处理不同模块的测试命令，写过一个带条件分支的技能片段：

当用户要求运行测试时，按照以下逻辑执行： - 如果是 Maven 项目： - 单模块执行 mvn test - 多模块执行 mvn -pl <module> -am test - 如果是 Gradle 项目： - 执行 ./gradlew test --tests "特定测试类" - 如果是前端项目： - 执行 npm test 或 yarn test

模型读到这里会当作决策树来执行，效果比让它"随机应变"好得多。这个思路可以进一步扩展：像写代码一样写技能，把团队所有重复性操作都固化成规则。

6.4 你的可复用清单

最后给你一份我总结的技能编写要点：

• description 写得越具体，触发越准确
• 指令用有序列表，比散文段落更有效
• 每个步骤都给出执行命令或验收标准
• 能写路径就不写描述，能写命令就不写概念
• 技能越短越好，把长细节放在独立示例文件中按需读取
• 写完后一定要用一个真实场景验证触发是否正常

我自己现在维护着七八个自定义技能，覆盖提交信息、构建优化、测试规范、日志规范等场景。每一段配置都是踩过坑换来的，但它带来的收益是持续的——AI 开始用我们的方式干活，而不是我们每次去纠正 AI 的方式。

这套"技能库"的思路，其实不只适用于 Codex，任何支持自定义指令的 AI 编程工具都可以借鉴。把团队规范固化下来，AI 才能真正成为团队里那个"可靠的新人"。