最近在折腾 Codex CLI 的时候我发现一个很有意思的现象很多人把 Codex 当成一个“高级聊天框”让它在终端里帮忙写点代码、改点 bug 就完事了但实际上 Codex 真正拉开体验差距的地方是它的 Skill 机制。我自己的感觉是装上十几个靠谱的 Skill 之后Codex 从一个“你问一句它答一句”的被动工具变成了一个“你交代目标、它按流程干活”的半自动员工。这篇就把我实测下来最值得收藏的 15 个 Skill 整理出来每一个都附上适用场景和我自己的使用心得。不管你是刚开始接触 Codex还是已经装了一堆插件但不清楚怎么搭配这篇都值得你先收藏再慢慢看。1. Skill 到底是个什么东西为什么突然大家都在装1.1 一句话解释 Skill 的运作机制Codex 的 Skill 本质上是一套“预置提示词 结构化流程 工具调用约束”的打包方案。你可以把它理解成给 Codex 准备的一份岗位说明书里面写清楚这个 Skill 负责什么场景、遇到什么输入应该走什么流程、输出格式长什么样、哪些工具可以用、哪些操作绝对不能做。举个例子默认情况下你让 Codex“帮我检查这段代码有没有问题”它可能会泛泛地看一遍语法、提几个建议就结束。但如果你加载了一个“代码审查 Skill”它就会严格按照你定义的清单去检查先看安全漏洞再看性能瓶颈然后看可读性和命名规范最后给出一个带严重等级的问题列表。同一个 Codex有没有 Skill 加持产出的质量完全是两个量级。Skill 的文件结构也不复杂通常是一个目录里放一个SKILL.md文件里面用简单的 YAML 头加上 Markdown 正文来描述角色、流程、规则和示例。Codex 在会话中加载 Skill 之后会把这份说明书的内容注入到上下文里相当于在每次对话前先给它“洗脑”一次让它进入对应的工作状态。1.2 Skill、Agent、插件三者的边界在哪里这个问题在社区里被问过无数次我刚开始也混淆。简单区分的话插件负责“接外部系统”比如让 Codex 能操作浏览器、能读数据库、能调第三方 APIAgent 是一个能自主决策、多步执行的任务执行体它会自己规划步骤并调用工具而 Skill 更像是“给 Agent 或 Codex 本身的领域知识包”它不直接连外部系统但它决定了 Codex 在某个场景下用什么样的思维方式和流程来干活。打个比方插件是给工具装上的机械臂Agent 是那个会思考怎么干活的工人Skill 则是工人手里的作业指导书。三者可以配合使用但 Skill 的门槛最低不需要写复杂的调度逻辑只要会写 Markdown 就能做一个属于自己的 Skill。很多社区里流传的“skill 就是给 AI 的提示词模板”这种说法不算错但更准确地说它是一个带流程、带约束、带示例的“高阶提示词工程包”。2. 15 个值得收藏的 Skill我按场景给你拆开讲这一部分我按使用场景分成四类方便你按需取用。需要提前说明的是Codex 社区里 Skill 的更新速度非常快很多热门 Skill 在 GitHub 上一周能更新好几个版本所以我这里讲的是“这一类 Skill 解决什么问题、怎么选”而不是让你死记某个仓库名。2.1 代码质量与工程效率类这一类是日常开发中最刚需的装上之后立刻能感受到差别。第一个是 impeccable社区里叫它“完美主义审查官”。这个 Skill 的核心逻辑是让 Codex 不再当老好人而是用近乎苛刻的标准去挑毛病。我拿它审查过一次自己的 PR它不光指出了代码里的潜在空指针问题还顺带把我函数命名不一致、注释和实现不匹配这种小问题全翻了出来。它适合在提交代码之前跑一遍把 Codex 从一个“你说改哪它改哪”的工具变成一个“主动帮你找茬”的质检员。为什么值得收藏因为大多数人写代码时对自己的盲区是没有感知的而 impeccable 的价值就是把那些你自己看不出来的问题暴露出来。第二个是测试用例生成 Skill。这个 Skill 的厉害之处在于它不只是生成单测而是会先分析你的函数入口、边界条件和依赖关系然后按等价类划分、边界值分析这些测试理论来生成用例。我实际用它给一个日期处理函数生成测试它把闰年、跨月、时区这种边界情况全都覆盖了比我手动写的还全。用的时候我建议你给 Codex 提供足够的上下文比如函数所在的文件路径、依赖的外部服务有哪些这样它生成的用例会更贴合你的业务场景。第三个是安全审计 Skill社区里也有人叫它“授权范围内的漏洞挖掘助手”。需要强调一下这个 Skill 的正确用法是对自己的代码做安全自查或者在企业授权的前提下做代码审计不要拿去干任何越界的事。它的工作方式是检查输入校验、SQL 拼接、权限校验这些常见风险点然后给出修复建议。我拿它扫过一个老项目的登录模块几分钟就定位到一处越权访问的风险点这种问题靠人肉 review 很容易漏掉。第四个是代码迁移/脚本转换 Skill。它特别适合处理“把一段 Python 脚本改成 Go 服务”或者“把旧框架的写法迁移到新框架”这类机械但费神的活。这个 Skill 会先确认源语言和目标语言之间的语义映射关系再逐步转换而不是一股脑生成一大堆跑不起来的代码。我建议迁移完必须让 Codex 自己写一个对比测试用例验证迁移前后的输出结果一致这一步能省掉很多返工时间。第五个是需求拆解与任务规划 Skill。这个 Skill 的作用是把一句含糊的需求拆成一个可执行的任务清单。比如你跟 Codex 说“我要给博客加一个搜索功能”它会先问你搜索范围是什么、需不需要分词、结果怎么排序然后输出一个带依赖顺序的任务列表。它适合在项目启动阶段使用能让 Codex 从“直接甩一段代码”变成“先跟你对齐方案再动手”效率提升非常明显。2.2 专业领域与数据类这一类适合有特定专业背景的读者或者经常处理数据的同学。第六个是数学建模 Skill社区热搜里的“数模 skill”就是它。这个 Skill 内置了一套完整的建模流程问题分析、假设条件、模型建立、求解、灵敏度分析、结果评价。它非常适合数学建模竞赛或者论文里需要用到数学模型的人。我拿它跑过一个资源调度优化问题它先给出线性规划的标准形式然后逐步推导约束条件最后还带着我做了参数敏感性分析。这个 Skill 的可贵之处是它不会直接扔一个黑箱公式而是把每一步的推导逻辑都展示出来方便你理解和修改。第七个是数据清洗 Skill。很多人的日常工作是跟脏数据打交道的缺失值、重复值、异常格式、编码混乱这些问题用脚本处理每次都要重新写一遍。数据清洗 Skill 的流程是先做数据概览再识别缺失和异常然后根据你的业务规则做清洗最后生成一份数据质量报告。它适合在数据分析流程里作为固定环节使用。我实际用下来最爽的一点是它会把每一步的清洗规则写清楚这样你随时可以回溯“这条记录为什么被删了”。第八个是仓颉术语管理 Skill。这里说的“仓颉”是指汉字和文化意义上的中文信息处理场景。这个 Skill 非常实用的一点是它能建立并维护一套术语表保证 Codex 在写技术文档、产品文案、代码注释时用词统一。比如你规定“接口”不能说成“界面”“缓存”不能说成“缓冲”它就会在输出里严格执行。做中文化项目的同学一定要装一个它可以彻底解决 AI 生成内容时常见的“翻译腔”和名词飘忽问题。第九个是知识库构建 Skill社区里的“archify skill”就是做这个的。它能把一堆零散的文档、笔记、网页摘录整理成一个结构化的知识库。它的流程包括自动提取核心概念、建立主题之间的关联、生成索引和摘要。我拿它整理过几百篇技术收藏夹文章最后输出了一份带分类和关键词的目录再配合 Codex 的问答能力简直像给自己装了一个私人知识库搜索引擎。对知识管理有需求的人这个 Skill 值得长期使用。2.3 文档、内容与效率类写文档和日常工作效率相关的 Skill是我个人使用频率最高的。第十个是 workbuddy工作伙伴型 Skill。它跟普通的任务管理 Skill 不一样它更像一个会主动跟进你工作进度的助手。你早上跟它说今天要做的三件事它会帮你拆解优先级、预估耗时、在每件事完成时帮你记录结果下班前还能自动生成一份日报。对自由职业者和经常需要多人协作的人来说这个 Skill 能帮你省掉很多整理同步信息的琐碎时间。它的核心思路是“工作上下文管理”让 Codex 始终知道你做到哪一步了、下一步该干什么。第十一个是 taste Skill它是做文案审美控制的。写公众号、写产品文案、写周报最怕 AI 产出那种一股营销味的空话。taste Skill 的作用就是给 Codex 灌输一套你的文字偏好不要形容词堆砌、不要空泛的展望、每句话要有信息量。我拿它润色过几篇技术文章改完之后明显感觉节奏更紧凑读起来像人写的而不是 AI 生成的。对内容创作者来说这个 Skill 比任何写作模板都管用。第十二个是 grill Skill它的角色是“追问面试官”。这个 Skill 会让 Codex 针对你的方案、代码或者文档不断提出尖锐的问题帮你发现逻辑漏洞。比如你写完一个设计方案grill Skill 会站在评审的角度追问这个方案的失败模式是什么如果数据量扩大十倍怎么办你的假设依据是什么它特别适合在做技术分享、项目答辩或者重要决策之前拿它当一面镜子照一照自己的思考盲区。第十三个是 ponytail Skill表面上是个轻松的名字实际上是做“人设一致性”的。它的作用是定义一种固定的语气、风格和表达习惯让你和 Codex 的协作保持稳定输出。比如说你希望它在生成代码注释时简洁克制、在写 commit message 时按照“类型-范围-描述”的格式ponytail Skill 会在每次会话中强制维持这套规则。它适合作为“基础底座型” Skill跟其他 Skill 叠加使用。2.4 元能力与自举类最后一类很有意思这些 Skill 是拿来“造 Skill”或者优化 Codex 本身的。第十四个是 book to skill它的作用是把一本书或一份长文档转换成可用的 Skill。它的工作流程是分析原文的结构、提炼核心方法论、把关键流程转成可执行的步骤、最终生成一个 SKILL.md 文件。比如你有一本《xx 设计模式》的电子书它可以把它转成一个“设计模式顾问” Skill之后你再问相关问题的时候Codex 会自动按照这本书的框架来回答。这个 Skill 的价值在于它让你从“使用别人的 Skill”升级到“把自己的知识体系变成 Skill”。第十五个是蒸馏辅助 Skill它用于帮助整理和压缩训练/微调数据集。如果你在做模型蒸馏、微调或者构建 few-shot 示例这个 Skill 可以帮你从原始文档中提取高质量的对齐样本、过滤低质量片段、按格式整理成训练集。我拿它处理过一批客服对话记录它能自动把冗余的寒暄删掉、把标准答案抽取出来生成的结构化数据基本可以直接用于后续的模型优化。这个 Skill 不是人人用得上但如果你有相关需求它是真正能省下几周时间的利器。3. 安装与自建 Skill 的完整实操3.1 怎么把别人的 Skill 装进 Codex先讲最基础的操作把别人分享的 Skill 装进 Codex 里。Codex 在会话启动时会扫描特定目录下的 Skill默认查找顺序有项目级目录比如.codex/skills/和用户级目录比如~/.codex/skills/。我个人建议把通用型 Skill 装在用户级目录把跟具体项目强相关的 Skill 装在项目级目录这样你的通用能力可以跨项目复用项目特定规则又不会污染其他项目。安装步骤很简单第一步先把下载下来的 Skill 文件夹整个复制到 skills 目录下比如mkdir -p ~/.codex/skills cp -r ~/Downloads/impeccable ~/.codex/skills/第二步是检查 Skill 目录结构是否正确一个标准的 Skill 目录里至少要有一个SKILL.md文件~/.codex/skills/impeccable/ └── SKILL.md第三步就是重新启动 Codex 会话然后在对话里输入/skills命令查看当前已加载的 Skill 列表。如果你能看到刚才复制进来的名字说明加载成功。遇到不生效的情况我后面会在常见问题里专门讲排查方法。3.2 手写一个自己的 SKILL.md从别人那里收集 Skill 终究是有限的真正让 Codex 变得顺手的方式是学会自己写。一个完整的 SKILL.md 长这样--- name: demo-skill description: 适用于 xxx 场景的示例 Skill当用户提到 xxx 关键词时优先使用 allowed-tools: - bash - read_file - write_file --- # Demo Skill ## 角色 你是一个专注于 xxx 领域的资深专家。 ## 工作流程 1. 先读取项目的配置文件了解项目结构。 2. 根据用户输入的目标拆解任务清单。 3. 每完成一步向用户汇报结果。 ## 输出规范 - 所有建议按照“问题-原因-方案”的结构输出。 - 禁止使用空泛的表达每条结论必须给出依据。 ## 示例 用户输入... 你的输出...name是 Skill 的唯一标识description很重要Codex 在后台会根据你的对话内容自动决定要不要调用某个 Skill所以描述里最好写清楚“什么时候用、解决什么问题”。allowed-tools可以限定这个 Skill 允许动用的工具权限属于安全控制手段比如你不想让某个 Skill 执行写文件操作那就不给它列write_file。正文部分我建议至少包含四个板块角色定义、工作流程、输出规范、示例。角色定义解决“Codex 以什么身份思考”的问题工作流程解决“先干什么后干什么”的问题输出规范解决“内容长什么样”的问题示例解决“抽象规则如何具象化”的问题。写完之后放到 skills 目录下重启会话就能用。我自己优化 Skill 的习惯是先用一个真实任务跑一次看哪一步输出不符合预期然后回去改 SKILL.md 里的流程描述反复迭代几轮之后这个 Skill 就会像长在你的工作流里一样顺手。3.3 用 CC Switch 这类工具管理多套配置当你本地配置了多个不同的模型端点或者多套 Codex 使用环境时手动改配置文件很容易出错。社区里常用的 CC Switch 这类配置管理工具本质上是一个配置文件切换器它可以让你在不同的 Provider、Base URL、模型名称之间快速切换而不需要每次手动去改 Codex 的配置文件。我在 CC Switch 里最常用的操作是新建一个配置项填好服务商名称、接口地址、模型名和密钥保存之后一键切换。如果你同时接了多个服务商的 API或者想在“日常通用模型”和“深度推理模型”之间切换这个工具能省掉大量来回改配置的时间。注意切换配置之后一定要重新启动 Codex 会话否则新配置可能不会生效。如果你用的是自定义的本地服务地址还要注意“Base URL”必须指向服务暴露/responses或/chat/completions这类接口的根路径填错层级是最常见的连接失败原因。特别提醒一下不要为了贪图方便随便填一个非官方的第三方中转地址这样既有隐私风险稳定性也没有保障。安全第一尽量用你熟悉、可信的服务来源。4. 高频故障清单与排查记录4.1 端点报错“local proxy failed while handling codex endpoint /responses”这个报错我在用 CC Switch 切换配置后遇到过好几次字面意思是“在处理 Codex endpoint 时本地代理服务调用失败”。第一次遇到的时候我以为是 Codex 本身的问题折腾了很久才发现是 CC Switch 里配置的“Base URL”指向本地的网关服务没启动或者地址端口写错了。排查步骤可以参考下面这个顺序第一步确认你配置的接口服务是否已经正常启动可以用浏览器或者 curl 访问一下配置里填的地址看是否有正常响应。第二步检查 Base URL 是否写到了正确的层级很多服务要求写到版本号那一级。第三步看看是不是同时启动了多个占用了相同端口的程序端口冲突也会导致请求失败。第四步如果以上都没问题把 CC Switch 里的配置重新保存一次重启 Codex 再试。这类问题绝大多数是配置细节引起的跟 Codex 本身没关系所以遇到的时候不要慌按顺序排查即可。4.2 上下文爆炸“Codex ran out of room in the models context”这个报错说明你的会话上下文已经超过了模型的窗口限制。Codex 会把整个会话历史都算进上下文里包括你加载的 Skill 说明、之前的问答、工具执行结果。如果会话拉得太长或者某个工具输出了一大段日志就可能触发这个错误。解决思路有三个第一把大的任务拆成多个独立的小会话每个会话聚焦一件事第二利用 Codex 自带的压缩或重置功能清掉早期对话第三把大段日志改为让 Codex 只读取文件的特定片段而不是一次性读全量内容。我个人的经验是越到复杂的重构任务越应该保持“小步快跑”的会话节奏。一次会话只做一件事做完就开新会话这样既省上下文也不容易把思路带偏。4.3 模型不支持报错“model is not supported”有些错误提示里的模型名看起来很像 Codex 默认模型但实际可能是某个新版本或者特定账号才支持的模型。如果你用的是普通账号或者接入了第三方兼容服务就很容易遇到“这个模型没有权限/不被支持”的报错。处理办法是在 CC Switch 或 Codex 配置里把模型名改成你的服务商真正支持的版本或者切换回官方默认模型。这里也提醒一下不要盲目追求最新最强模型关键要看你的接口账号有没有对应的访问权限否则配置填得再漂亮也跑不起来。4.4 Skill 装完不生效的常见原因Skill 目录放对了也重新启动了会话但 Codex 就是不调用这种情况通常由以下几个原因造成第一SKILL.md里的description写得不够明确导致 Codex 判断不出当前对话应该使用这个 Skill。解决办法是在对话里直接点名比如“用 demo-skill 来分析这个问题”通过显式指定来确认是不是索引问题。第二Skill 目录里缺文件或者目录层级不对Codex 识别不到。重新检查一下目录下是不是直接躺着 SKILL.md还是中间多套了一层文件夹。第三YAML 头部的格式写错了比如冒号后面没空格导致解析失败。用支持 YAML 校验的编辑器检查一遍。第四部分 Skill 需要依赖额外的工具或脚本如果你电脑上没装对应的运行环境Skill 就会输出异常或者直接静默失败。如果以上都检查过了还是不行一个非常有效的调试手段是拿一个最小化样例测试新建一个只有一行话“你好”的简单 Skill看能不能被正常调用。如果简单 Skill 能被调用说明问题出在你那个复杂 Skill 的配置细节上如果简单 Skill 也不行那大概率是 Codex 的全局配置出了问题需要看看是不是装到了错误的目录。我个人在实际操作中的体会是Skill 这套机制最大的价值不在于“装得多”而在于“用得准”。挑三到五个真正贴合你日常工作的 Skill反复打磨它们的内容和流程远比囤积几十个吃灰的 Skill 更有意义。我整理这些的时候也把不少社区里的热门 Skill 挨个试了一遍最后常驻的也就六七个。建议你先从这篇里挑最戳你痛点的两三个装上用一周再回来调整效果会是最好的。最后再分享一个小技巧看到别人好用的 Skill与其直接照搬不如把它当成一个起点改成符合自己习惯的版本这比自己从零开始写轻松得多。