1. 先搞清楚 Codex 的 Skill 到底是个什么东西很多人第一次接触 Codex 的 Skill 体系脑子里冒出来的第一个问题是这跟插件有什么区别。我一开始也这么想直到真正把几个 Skill 装进去跑了一遍才发现两者的定位完全不同。插件更像是给编辑器加一个按钮或者一条命令你点它才动而 Skill 更像是一份写给 AI 的岗位说明书它规定了 AI 在特定场景下应该按什么流程、用什么工具、产出什么格式的结果。换句话说插件是给人用的Skill 是给 AI 用的。这个区别直接决定了你挑选 Skill 的思路。如果你按挑插件的逻辑去挑 Skill你会盯着功能多不多界面好不好看但按挑 Skill 的逻辑你该盯的是这个场景我是不是经常遇到它规定的流程是不是符合我的习惯它产出的东西我能不能直接用。这三个问题答不上来装再多也是摆设。Codex 的 Skill 本质上是一组结构化的指令加资源文件通常包含一个描述文件、若干提示词模板可能还有配套的脚本或参考文档。当你在对话里触发某个场景时Codex 会加载对应的 Skill按照里面写好的流程去执行。所以 Skill 的质量高低很大程度上取决于写它的人对那个场景理解得深不深。这也是为什么同样叫代码审查 Skill有的用起来像资深 reviewer有的用起来像刚毕业的实习生。新手最容易犯的错是一上来就去搜Codex 必装 Skill 合集十大神器 Skill然后一股脑全装上。结果就是 AI 每次加载一大堆互相冲突的指令行为变得飘忽不定你也不知道到底是哪个 Skill 在起作用。我踩过这个坑后来把装过的 Skill 砍到只剩五个反而顺手多了。所以下面我按基础层、提效层、业务层这三层来拆每一层告诉你该装什么、为什么装、装的时候注意什么。提示Skill 不是越多越好。每多装一个就多一份指令噪音。新手阶段控制在 5 到 8 个以内等你能清楚说出每个 Skill 在什么情况下触发再考虑扩充。2. 基础层 Skill让 Codex 先学会好好说话基础层解决的不是能不能干活而是干活靠不靠谱。这一层的 Skill 不直接帮你写业务代码但它们决定了 Codex 输出的稳定性、可读性和可维护性。很多人跳过这一层直接上业务 Skill结果就是 AI 写出来的东西能跑但没法看改起来比重写还累。2.1 代码规范与格式化 Skill统一输出的第一道闸门这个 Skill 的核心作用是让 Codex 在生成代码时自动遵循你项目的代码风格。别小看这件事我见过太多团队因为 AI 生成的代码缩进用空格还是 Tab、函数名用驼峰还是下划线而吵起来。更麻烦的是当 AI 生成的代码风格和项目现有风格不一致时代码审查会变得极其痛苦reviewer 要花大量精力在格式问题上真正该关注的逻辑问题反而被忽略。装这个 Skill 的时候关键是把你的规范文件喂给它。大多数项目根目录下都有.editorconfig、.eslintrc、pyproject.toml这类配置文件Skill 一般会读取这些文件作为依据。如果项目没有你得先补一个。我建议的做法是先手动写一段符合团队规范的示例代码然后让 Codex 参照这段代码的风格去生成。这比单纯给一堆规则条文有效得多因为 AI 对示例的理解能力远强于对规则的理解能力。实测下来这个 Skill 对 Python 和 JavaScript 这类风格差异大的语言效果最明显。比如 Python 里你要求用 4 空格缩进、行宽 88、类型注解必须写装好之后 Codex 生成的函数基本不用再手动调格式。但要注意如果你的项目里同时存在多种风格比如老代码用旧风格、新代码用新风格Skill 可能会困惑这时候要么分目录配置要么在对话里明确告诉它这次按新风格来。2.2 错误处理与日志 Skill把能跑变成能查新手写的代码有个通病正常路径跑得通一出错就抓瞎。Codex 默认生成的代码也经常这样try-catch 里就一句print(error)日志打得稀里哗啦出了问题根本不知道哪一步挂了。错误处理与日志 Skill 就是专门治这个毛病的。这个 Skill 通常会规定几件事异常必须分类捕获而不是一把抓、日志必须带上下文信息比如请求 ID、用户 ID、关键参数、错误信息必须能定位到具体位置。装好之后Codex 生成的代码会明显厚实一些虽然行数多了但排查问题时你会感谢当初多写的这几行。我自己的经验是这个 Skill 配合结构化日志库比如 Python 的 structlog、Java 的 logback效果最好。你可以在 Skill 里指定日志格式比如要求输出 JSON 格式方便后续用日志平台检索。另外提醒一句别让 Skill 把日志级别写死该 debug 的地方用 debug该 error 的地方用 error全用 info 等于没分级。2.3 测试生成 Skill让 AI 自己给自己出题这个 Skill 的价值在于它逼着 Codex 在写完功能后顺手把测试也写了。很多人不写测试是因为写测试比写功能还累但让 AI 来写这个成本就降下来了。测试生成 Skill 一般会要求 Codex 覆盖正常路径、边界条件、异常输入这三类情况产出的测试用例质量比手写的新手测试要高不少。装这个 Skill 的时候有个细节要注意你得告诉它你用的是哪个测试框架。Python 有 pytest、unittestJavaScript 有 jest、mochaJava 有 JUnit。不同框架的写法差异很大Skill 如果不知道你用哪个生成的测试可能跑不起来。另外如果你项目里已经有测试文件最好让 Skill 先读一遍现有测试的风格保持一致。注意测试生成 Skill 产出的用例不是拿来直接用的是拿来当起点的。AI 写的测试经常漏掉一些业务特有的边界情况你得自己补。但有了这个起点补起来比从零写快得多。3. 提效层 Skill把重复劳动交给机器基础层让 Codex 的输出靠谱了提效层就是让它跑得更快。这一层的 Skill 针对的是那些每次都要做、每次做法都差不多的事情。装对了提效 Skill你每天能省下一两个小时而且省下来的是那种最消耗精力的机械劳动。3.1 代码审查 Skill把 reviewer 从格式问题里解放出来代码审查 Skill 是我认为提效层里最值得装的一个。它的作用是在你提交代码前先让 Codex 按一套审查规则过一遍把明显的问题挑出来。这样人工 reviewer 拿到代码时格式、命名、明显的逻辑漏洞已经被过滤掉了他们可以专注在架构和业务逻辑上。这个 Skill 的配置重点在于审查规则的优先级。我一般会分三档必须改的比如安全漏洞、空指针风险、建议改的比如命名不清晰、函数过长、可改可不改的比如注释风格。Codex 按这个优先级输出审查意见你一眼就能看出哪些是硬伤。如果不分优先级AI 会把所有问题平铺给你反而增加认知负担。实测中我发现一个有意思的现象代码审查 Skill 对重复代码的识别特别准。人眼容易忽略的复制粘贴痕迹AI 一扫就出来了。但它对业务逻辑是否正确的判断就比较弱因为它不知道你的业务规则。所以这个 Skill 的定位是辅助审查不是替代审查。3.2 文档生成 Skill让注释和 README 不再靠自觉写文档这件事所有人都知道重要但所有人都拖着不写。文档生成 Skill 的思路是既然你不写那就让 AI 根据代码写。它一般能生成三类东西函数级注释、模块级说明、项目级 README。函数级注释这块Skill 会根据函数签名和内部逻辑自动生成 docstring包括参数说明、返回值说明、可能抛出的异常。质量嘛比不写强但比认真写差一点。我的做法是让 Skill 先生成一版然后自己改关键部分这样比从零写快很多。README 生成是另一个亮点。Skill 会扫描项目结构、依赖文件、入口脚本然后拼出一份包含安装步骤、使用方法、目录说明的 README。对于内部项目或者个人项目这份 README 完全够用。但如果是开源项目你还是得自己润色因为 AI 写不出项目的灵魂——它不知道你为什么要做这个项目也不知道它解决了什么痛点。3.3 重构建议 Skill给老代码做一次体检重构建议 Skill 针对的是那些能跑但很丑的代码。它会分析代码的复杂度、耦合度、重复率然后给出重构建议。这个 Skill 特别适合接手老项目的时候用你花半小时让 Codex 扫一遍就能得到一份哪里该动、哪里别动的清单。用这个 Skill 有个原则先看建议再动手别让 AI 直接改。因为重构涉及大量上下文AI 可能不知道某个看起来冗余的函数其实是被外部系统调用的。我一般会让 Skill 输出一份分级建议然后自己判断哪些可以立即改、哪些需要排期、哪些干脆不动。直接让 AI 重构的风险太大改出问题来排查成本很高。提效层 Skill核心价值配置关键点适用场景代码审查过滤低级问题聚焦核心逻辑审查规则分优先级提交前自查、团队协作文档生成降低文档撰写成本指定文档格式和粒度内部项目、个人项目重构建议快速识别技术债只出建议不直接改接手老项目、定期体检4. 业务层 Skill让 Codex 懂你的行话业务层 Skill 是最难挑的一层因为它跟你的具体领域强相关。基础层和提效层的 Skill 换个项目还能用业务层 Skill 换个项目可能就废了。但一旦配对它带来的效率提升也是最明显的——因为它让 Codex 从通用助手变成了懂行的同事。4.1 业务术语 Skill解决鸡同鸭讲的问题每个行业都有自己的黑话。做电商的张口就是 SKU、SPU、GMV做金融的三句不离头寸、敞口、久期做物流的天天说揽收、中转、派送。Codex 默认是不懂这些的你跟它说帮我写个计算 GMV 的函数它可能给你算成简单的销售额求和忽略了退款、优惠券、税费这些因素。业务术语 Skill 的作用就是把这些黑话的定义、计算口径、常见坑点喂给 Codex。装好之后你再提业务需求它就能理解你在说什么。这个 Skill 的维护成本比较高因为业务规则会变你得定期更新。但相比每次对话都要解释一遍术语这个投入是值得的。我建议的做法是先整理一份业务术语表每个术语写清楚定义、计算公式、边界情况。然后把这个表作为 Skill 的知识库。更新的时候只改表不用改 Skill 本身。这样维护起来轻松很多。4.2 业务流程 Skill让 AI 按你的流程走业务流程 Skill 比术语 Skill 更进一步它规定的是做一件事的步骤。比如用户下单这个流程可能涉及库存检查、优惠计算、支付发起、订单落库、通知推送五个步骤每个步骤还有失败回滚的逻辑。这些流程如果只靠对话里临时说AI 很容易漏步骤或者搞错顺序。把业务流程写成 Skill 之后Codex 在处理相关需求时就会按这个流程走。比如你让它写一个下单接口它会自动把五个步骤都考虑到而不是只写个创建订单就完事。这个 Skill 对复杂业务系统特别有用因为复杂系统的坑往往不在单个步骤而在步骤之间的衔接和异常处理。装这个 Skill 的时候建议用流程图或者步骤列表的形式来描述流程比纯文字描述清晰得多。Codex 对结构化信息的理解能力更强。另外流程里的异常分支一定要写清楚比如库存不足时应该返回什么错误码支付超时后订单状态怎么处理这些细节不写AI 就会自己编编出来的往往不符合你的预期。4.3 领域数据模型 Skill让 AI 认识你的表结构这个 Skill 解决的是AI 不知道你的数据库长什么样的问题。你让它写个查询它得先知道有哪些表、表里有哪些字段、表之间怎么关联。如果不告诉它它就会瞎猜猜出来的 SQL 跑不起来。领域数据模型 Skill 一般会把核心表的结构、字段含义、关联关系整理成文档作为 Skill 的知识库。这样 Codex 在生成 SQL、ORM 代码、数据迁移脚本时就能基于真实的表结构来写。这个 Skill 对后端开发特别有用能省下大量查表结构的时间。提示数据模型 Skill 的知识库不要放敏感数据只放结构信息。字段名、类型、关联关系这些可以放具体的用户数据、交易记录绝对不能放。这是安全底线。5. 三层 Skill 的搭配逻辑与安装顺序知道了每层该装什么接下来是怎么搭。我见过有人把三层 Skill 全装上结果 Codex 每次响应都慢半拍因为要加载的指令太多了。也见过有人只装业务层结果 AI 写出来的代码风格乱七八糟。三层 Skill 的关系不是叠加而是配合。5.1 为什么基础层必须最先装基础层是地基。地基没打好上面盖什么都是歪的。我建议新手第一个装的就是代码规范 Skill装完之后先跑几个小任务感受一下 AI 输出风格的变化。等你能稳定得到符合规范的代码了再装错误处理和测试生成。这三个装完Codex 的基本盘就稳了。这个顺序不能反。如果你先装业务层AI 虽然懂业务了但写出来的代码风格飘忽、错误处理潦草、没有测试你还得花大量时间擦屁股。先装基础层相当于先把 AI 的职业素养培养起来后面学业务就快。5.2 提效层什么时候进场提效层建议在基础层用顺了之后再装。判断标准很简单如果你现在让 Codex 写代码已经不需要反复纠正格式和错误处理了那就可以进提效层了。提效层里我建议先装代码审查因为它的反馈能帮你发现基础层 Skill 没覆盖到的问题相当于一个自检环节。文档生成和重构建议可以晚点装。文档生成适合项目有一定规模之后再用小项目没必要。重构建议适合接手老项目或者定期体检时用平时不用常开。5.3 业务层的装法按项目装不按人装业务层 Skill 最大的特点是项目相关。你在这个项目里配的业务术语 Skill换到另一个项目可能完全不适用。所以我的建议是业务层 Skill 跟着项目走不要装到全局配置里。每个项目有自己的业务 Skill 集合切换项目时自动切换。具体操作上可以把业务 Skill 放在项目根目录的特定文件夹里Codex 加载时优先读项目级的 Skill。这样你同时维护多个项目时不会互相干扰。全局只保留基础层和提效层业务层永远项目级。层级安装时机配置位置维护频率基础层最开始全局低规范变了才改提效层基础层用顺后全局中按需调整业务层有明确业务场景时项目级高业务变就改6. 装完之后的调试与踩坑记录Skill 装完不是终点是起点。我装第一个 Skill 的时候以为装上就完事了结果发现 AI 的行为跟预期完全不一样。后来才明白Skill 需要调试就像新员工入职需要磨合一样。6.1 怎么判断一个 Skill 真的生效了最直接的方法是做对比测试。同一个任务在装 Skill 前后各跑一次看输出有没有变化。如果没变化要么是 Skill 没加载要么是 Skill 的指令太弱被其他指令覆盖了。我一般会用一个固定的测试任务比如写一个读取 CSV 并统计每列空值数量的函数装 Skill 前后各跑一次对比输出。如果 Skill 没生效先检查加载路径对不对。Codex 加载 Skill 有优先级顺序项目级通常高于全局级。如果你把 Skill 放在全局但项目里有同名 Skill可能被覆盖了。另外检查 Skill 的描述文件格式对不对格式错了会静默失败不报错但也不生效。6.2 Skill 之间打架怎么办这是最常见的问题。比如你装了代码规范 Skill 要求函数不超过 50 行又装了重构建议 Skill 建议拆分长函数两个 Skill 同时触发时AI 可能无所适从。我的处理原则是同一时间只让一个 Skill 主导。具体做法是在对话里明确说这次按代码规范 Skill 来或者这次用重构建议 Skill 分析。如果两个 Skill 经常冲突说明它们的职责边界没划清。这时候要么改 Skill 的触发条件让它们在不同场景下触发要么干脆合并成一个 Skill。我倾向于后者因为维护一个 Skill 比维护两个互相打架的 Skill 省心。6.3 业务 Skill 的更新节奏业务 Skill 是最容易过时的。业务规则一变Skill 里的知识就错了AI 按错的规则干活产出全是坑。我的做法是给每个业务 Skill 设一个复查日期比如每季度复查一次。复查时对照最新的业务文档把过时的内容删掉新增的内容补上。另外业务 Skill 的更新最好有版本记录。每次改动记一下改了什么、为什么改出问题的时候能回溯。我吃过这个亏有次业务 Skill 改错了但不知道改了什么排查了半天。7. 我自己的 Skill 清单和日常用法说了这么多理论最后分享一下我目前实际在用的 Skill 组合以及每天怎么用它们。这份清单不是标准答案只是一个跑了半年多、踩了不少坑之后稳定下来的配置你可以参考但别照搬。基础层我留了三个代码规范、错误处理、测试生成。这三个是每天都会触发的基本不用管它们默默在后台起作用。提效层我留了两个代码审查和文档生成。代码审查在每次提交前手动触发文档生成在每周整理项目时用一次。重构建议我装是装了但平时关着只在接手新项目或者季度体检时打开。业务层我按项目配目前手头三个项目各有一套。业务术语 Skill 是每个项目必备的业务流程 Skill 只在最复杂的那个项目里配了因为其他两个项目流程简单对话里说清楚就行。领域数据模型 Skill 我只在后端项目里配前端项目用不上。日常用法上我有个习惯每天早上开工前先让 Codex 用代码审查 Skill 扫一遍昨天写的代码。这相当于一个晨间自检能提前发现不少问题。然后白天写代码时基础层 Skill 自动生效我不用操心。遇到业务需求时业务 Skill 自动加载我只需要用业务语言描述需求就行。注意Skill 是工具不是拐杖。我见过有人装了 Skill 之后自己连基本的代码规范都不记了全指望 AI 兜底。这样下去AI 一抽风你就抓瞎。Skill 的正确用法是放大你的能力不是替代你的能力。最后说一个我踩过的最大的坑有段时间我装了太多 Skill导致 Codex 响应特别慢而且行为很不稳定。后来我把 Skill 砍到只剩最核心的几个响应速度回来了输出质量也稳定了。这件事让我明白一个道理Skill 的价值不在于数量而在于每一个都真正被用到。装十个用不上的 Skill不如装三个天天用的。你现在如果刚开始配 Skill我的建议是从基础层的一个开始用顺了再加下一个别急。