最近不少写代码的朋友都在聊 Codex skills 这件事。这东西其实不复杂本质上就是给编程助手挂一个“兵器架”把常用的任务流程、写作规范、领域知识打包成固定技能需要的时候一键调用。我把官方仓库、GitHub 和社区里能翻到的 skill 都过了一遍安装、测试、删掉来回折腾了好几周最后真正留在机器上的其实没几个。今天就把筛选逻辑、安装配置、还有这几个留下的 skill 的用法一次说清楚。无论你是刚接触 Codex 的新手还是已经入坑、想提升团队效率的老手这篇都值得花十分钟看完。1. 先搞懂Codex 的“技能货架”到底是个啥1.1 skill 的本质不是插件是“有格式的专家笔记”很多人第一次接触 skill 时会下意识把它类比成浏览器插件或者 IDE 扩展这个理解其实不太对。Codex skill 没有一个可执行文件也没有独立的运行进程它本质上是一套有固定格式的 Markdown 文档外加若干参考资料文件放在约定的目录里。Codex 在启动对话或者执行任务时会扫描这些文档把里面的指令、规则、示例作为上下文喂给模型。通俗点说skill 就像厨房里预处理好的调料包。你想做一道菜不用重新去查每一种调料的配比直接拿对应调料包往锅里一倒就行。Codex 本身是那个厨师模型是那把锅铲而 skill 就是让你不用每次重复交代“盐放多少、酱放多少”的标准化料包。这套机制的聪明之处在于它把“教会模型干一件事”的成本从每次对话都重复一遍变成了“只封装一次、到处引用”。而且因为 skill 是纯文本它天然支持版本管理、团队共享和跨项目复用。你不需要会写代码只需要会写清楚步骤就能做一个好用的 skill。1.2 使用场景拆解从单次聊天到团队级复用我在实际使用中把 skill 的场景分成三个层级。第一层是个人效率层比如“写单元测试”“做代码评审”“把一段口语化的文字改成书面表达”这类技能几乎每天都要用封装好后能省掉大量重复的 prompt 描述。第二层是领域知识层比如 GIS 空间分析、SolidWorks 参数化建模、学术论文格式规范这类技能的价值在于把专业领域的规则沉淀下来让模型在你不懂具体细节时也能按照行业标准干活。第三层是团队协作层把团队的编码规范、提交信息格式、上线检查清单做成 skill 放进 Git 仓库新成员接手项目时Codex 会自动加载这些约束减少“我明明说了要按规范来它还是写偏了”的拉扯。还有一个很多人忽略的使用方式skill 不只是给 Codex 看的也是给你自己看的。我经常把一个 skill 的 SKILL.md 当成项目的活文档里面写清楚某个流程为什么要这样做、有哪些坑不能踩。模型在用人也在用。1.3 我的定位策略怎么判断一个 skill 值不值得留这是我在“翻货架”过程中收获最大的一点。判断一个 skill 是否值得留下我会看三个维度第一使用频次高不高一年用不了几次的技能不值得占目录空间第二替换成本低不低如果一句话就能说清楚的事情没必要做成 skill做成 skill 反而因为加载时间长显得拖沓第三洗不洗得干净也就是这个 skill 的核心指令是否通用如果只能适配某一个极其特殊的场景我会选择把它改成一段 prompt 模板而不是 skill。最后一条对我筛掉很多花哨 skill 特别有用。社区里经常有人发布看起来很有趣、但实际上只服务于某一次特定 hackathon 的 skill这种我一般看一眼就划走了。真正值得留下的一定是能反复用在真实工作里的东西。2. 从零装好 Codex 并让它能跑起来2.1 三种装法CLI / 桌面版 / 内网自托管实测对比Codex 现在的安装方式已经比较成熟了主要就三条路命令行工具、桌面版应用、以及面向团队的私有化部署。我三种都试过直接放结论对比例子。安装方式适合人群上手难度我的评价npm 安装 CLI开发者和喜欢终端的用户低最灵活配环境变量最方便Windows/macOS 桌面版不熟悉命令行的用户低图形界面友好但设置项少一些内网自托管团队和有安全要求的场景高适合数据不出内网需要额外部署推理服务如果你是在个人电脑上想快速体验我建议直接走 CLI。终端里执行一次全局安装把 Node 环境准备好npm 安装完成后用codex --version确认版本号。桌面版的好处是点两下就能登录也不用记命令但它能暴露出来的配置项确实比 CLI 少后续想接自定义模型、改模型供应商时你会发现自己被界面限制住了。至于内网自托管我在第六部分会展开讲思路。这里先记住一句话Codex 本体只是个壳它真正依赖的是背后的大模型推理服务所以内网部署的关键不是装 Codex而是把推理服务也搬到内网里。2.2 登录与基础配置把“登录不上”的问题一次说透装好之后第一件事是登录。Codex 支持两种认证方式一种是直接用 ChatGPT 账号走 OAuth 登录另一种是用 API Key。我的建议是如果你有 OpenAI 的账号和订阅优先走 OAuth因为会带上一些订阅权益如果是在自动化脚本或者 CI 里用那就用 API Key把 Key 放到环境变量里而不是直接写在配置文件中。很多人卡在”登录不上“这一步我排查了几次之后总结出最常见的三个原因终端时间不同步导致 OAuth 的 token 校验失败账号的计费状态异常被服务端拒绝以及你在公司内网环境里存在额外的防火墙拦截策略。前两个用date命令看一下系统时间、登录网页版看一眼账号状态就能定位。第三个问题属于环境层面不要试图绕过策略直接找网络管理员确认你所在网络的访问白名单即可。登录成功后Codex 会在你的用户目录下生成一个.codex/文件夹里面放着配置文件和日志。记住这个位置后面所有 skill 和自定义配置都要往这个目录里放。2.3 让 Codex 接入 DeepSeek 等兼容模型的几个关键配置这是最近搜索热度最高的需求也是我实际配置过很多次的场景。Codex 在设计时留了模型供应商扩展能力只要对方提供 OpenAI 兼容的 API 接口就能通过环境变量或者config.toml指过去。以 DeepSeek 为例你可以这样配置export OPENAI_BASE_URLhttps://api.deepseek.com/v1 export OPENAI_MODELdeepseek-chat然后在config.toml里检查有没有残余的默认模型设置如果之前用过别的模型得把model字段改成你想实际调用的模型名。这里有一个特别容易踩的坑Codex 会先读config.toml再读环境变量但环境变量的优先级更高。如果你在配置文件里写死了某个模型环境变量又设了另一个最后实际生效的是环境变量里的那个排查时经常造成误解。还遇到过一种情况第三方模型接口路径不是标准的/v1而是带了自己的前缀。这时候OPENAI_BASE_URL只写到域名根路径Codex 会自己在后面拼接/responses或/chat/completions你不需要手动补全路径。2.4 验证装好了没一条命令跑通全链路配置完成后别急着测试 skill先把基础链路验证一遍。找一个安全的临时目录执行codex exec 用三句话介绍你自己如果能看到正常的回复说明安装、登录、模型调用三个环节都是通的。如果你配的是 DeepSeek 这类兼容模型这条命令跑通就证明 base URL 和模型名都没问题。如果你的环境里存在多条 Codex 版本路径比如同时装了桌面版和 npm 版测试前先which codex确认你调用的到底是哪一个避免桌面版走一套配置、CLI 走另一套配置最后互相打架。这个坑我一开始就踩过整整浪费了一个下午。3. 翻完整个货架后我留下的这几个 skill3.1 文档处理三件套PDF / Office 公文包官方 skill 仓库里那套文档处理技能是我第一批留下来的。它们的价值不在于“能处理 PDF”这么简单而在于把大文件的切片、版面分析、表格抽取这些繁琐步骤全部封装好了。以前我想让 Codex 帮我从一份 200 页的 PDF 报告里提取关键指标需要自己写代码处理分页和压缩上下文空间经常搞到一半就超 token。现在直接在对话里把 PDF 拖给它用触发词调动文档 skill它自己知道怎么分块、怎么合并结果。类似的还有 docx 和 xlsx尤其是表格类的 Excel 文件官方 skill 内置了按区域读取的指令模型不会傻乎乎地把整张几万行的表塞进上下文而是按需读取这个设计非常聪明。我的体会是这类基础功能型 skill 不必自己造轮子直接用官方维护的跟着仓库更新走就行因为它们解决的问题太通用了社区迭代速度远比你个人快得多。3.2 测试军火库让单测覆盖率实打实地涨起来“写测试”这个 skill 是社区里公认最硬核的留存之一。它的设计思路不是让模型随便生成几个断言就算完事而是规定了一套完整的测试流程先梳理被测模块的分支和边界条件再按优先级列出测试用例清单最后逐个实现并运行反馈。我用了一段时间后发现它的核心价值在“分支覆盖”这四个字上。手动写 prompt 让模型写测试时模型总是倾向于挑最明显的正常路径边界条件和异常分支经常被忽略。而有了这个 skill 之后它的指令里强制模型先列出所有可能的输入情况包括空值、超长字符串、并发冲突然后才动手写代码。对于习惯了“写完功能就算完”的团队这个 skill 几乎是在帮团队建立测试文化。我甚至见过有人直接在 CI 里挂了一个任务让 Codex 加载测试 skill 后对新增代码做一次测试评审相当于组里有了一个不知疲倦的测试顾问。3.3 去AI味 skill现在写什么都先过它一遍这个 skill 是我留下所有非编程类技能的里面最惊喜的一个尤其适合经常要写方案、写周报、写对外文档的人。它的指令核心是一份“AI味词汇清单”凡是出现“赋能”“抓手”“闭环”“总而言之”“值得注意的是”这些词一律要求改写。同时它会要求模型检查句式避免“首先、其次、最后”这种机械排比也不能每段都用“通过XX实现XX”的模板。我一开始以为这只是个文字洁癖工具但实际用下来发现它很会抓语气问题。比如它会把“随着技术的不断发展”这种正确的废话直接删掉把“我们需要加强协作”改成“我们周一碰一下接口细节”。这种改写逻辑不是简单的词语替换是靠一段精心设计的 prompt 实现了过来人的文字审美。如果你也是靠文字吃饭的这个 skill 值得常驻在全局配置里让 Codex 每次回答完问题之后自动过一遍这层润色。3.4 学术论文与深度研究 skill格式、引用、降重一把抓写论文的痛点不在“写不出来”而在“格式对不对”“引用规不规范”“思路有没有文献支撑”。社区里那批学术写作 skill 精就精在把这几件事拆开了。你调用它之后它不会直接甩给你一大段文字而是先问你要投的期刊或学校格式要求把引用风格、章节结构、字数限制这些约束钉死再开始组织内容。我拿它处理过一篇需要严格按 GB/T 格式排版的技术报告效果意外地好。它会把参考文献的著录项逐条校验甚至能识别出[1]和[2]的引用顺序有没有乱。这类 skill 的另一个用处是处理”降重“它不是教你改词而是要求模型重新组织段落逻辑把同一个观点用不同的论证路径表达出来这样出来的文字查重率自然就降了。对于研究生或者经常写技术报告的朋友这基本是必留项。3.5 领域定制派GIS 空间分析与 SolidWorks 接入的专业包如果说前面几个都属于通用技能那么领域定制 skill 才是真正体现“货架深度”的东西。我看到过有人把 GIS 空间分析的全部常用工作流打成一个 skill里面配了 references 目录放着各种空间数据格式说明和坐标系转换参数。模型在加载这个 skill 后不再需要你先解释什么叫缓冲区分析、什么叫叠加分析直接给数据路径它就能按行业常规流程出结果。类似的还有 SolidWorks 接入类 skill这类技能把 CAD 的参数化建模逻辑、常用命令、单位制约定都写进了指令里模型可以生成 SolidWorks 的 API 脚本去驱动建模操作。这类 skill 的启发在于Codex 的边界远不止写代码任何有明确步骤和领域规则的场景都可以靠 skill 让模型上手。我自己的经验是这类领域包不用多挑你工作里最高频的那个场景做深就行。做完之后你会发现原本需要你给模型科普两天的背景知识现在只需要一行触发词。3.6 娱乐向生存包打斗提示词、语言学习这些解压品当然货架上也有不少看起来特别“不正经”的 skill但它们恰恰证明了这套机制的扩展性。比如有人专门做了一个打斗动作提示词 skill给网络小说作者用的里面收录了几十种打斗场景的描写节奏、肢体动作分解、招式命名模板调用之后写出来的战斗场面非常有画面感。还有语言学习类的 skill它的做法不是让模型出一堆单词表而是模拟真实情景对话让模型扮演服务员、面试官、海关工作人员带着你把一个场景里的高频表达全部过一遍。我用它练口语对话比对着单词书记得牢得多。这类 skill 的特点是触发词极其好记一个斜杠加一个词就行非常适合碎片时间玩着用。我个人的观察是别小看这些看似玩票的 skill它们往往最能激发你对“给模型写说明书”这件事的兴趣。一旦你理解了思路就会忍不住想给自己手头的活儿也做一个。4. 手把手做一个自己的 skill从 SKILL.md 到实战4.1 SKILL.md 的结构frontmatter 与正文怎么写如果你看懂了前面说的大方向这一步就非常简单了。一个标准 skill 的目录结构长这样my-skills/ └── code-review/ ├── SKILL.md └── references/ └── review-checklist.md核心文件是SKILL.md它分两部分带 YAML 格式的 frontmatter和正文。frontmatter 里必须写清楚name和description尤其是description这一段 Codex 会自动读取用来判断“用户当前请求适不适合调用这个 skill”。所以描述一定要写清楚这个技能是干什么的、什么场景该用、什么场景不该用描述写得含糊模型就可能永远不触发它。正文部分才是真正干活的地方。我写 skill 正文时的原则是把它当成一份给新员工的入职手册要有清晰的目标、分步骤的操作说明、必须遵守的约束条件、以及几个能直接抄的结果示例。约束条件越明确模型跑偏的概率越低。4.2 一个能直接抄作业的例子做一个代码评审 skill下面这个例子是我自己的code-reviewskill 简化版你照着改成自己的项目就能用。--- name: code-review description: 用于对代码变更执行评审。当用户要求 review、评审、检查 MR/PR 时触发。不适用于全新代码编写任务。 --- # 代码评审专家 你是一名资深代码评审员请按以下流程完成评审。 ## 评审流程 1. 先读取本次变更的 diff 信息。 2. 识别变更涉及的核心模块与影响范围。 3. 按优先级检查以下项目 - 正确性是否存在明显的逻辑错误、空指针、资源未释放。 - 安全性是否有 SQL 注入、敏感信息硬编码、越权风险。 - 性能是否有不必要的重复计算、缺失缓存、长事务。 - 可维护性命名是否表意、函数是否过长、是否缺少注释。 ## 输出格式 - 每个问题按 [级别] 标记P0 为必须修复P1 为建议修复P2 为可选优化。 - 问题描述控制在两句话以内不翻旧账不评价人只评价代码。 - 最后给出一个整体结论通过 / 有条件通过 / 不通过。 ## 约束 - 不修改任何文件只输出评审意见。 - 如果 diff 过大超过 500 行先请用户缩小范围。把这段内容存成SKILL.md然后放进 Codex 的全局 skills 目录一般是~/.codex/skills/code-review/SKILL.md重启一次对话就能用。References 目录里可以放你们团队的编码规范摘要这样模型评审时不只靠通用经验还能对照你们自己的红线。4.3 调试技巧怎么确定 skill 真的被触发了很多人做完 skill 之后发现“好像没生效”先别急着怀疑模型没看过你的文件。调试方法分三步。第一步直接在对话里输入你的触发场景观察回复开头有没有按 SKILL.md 里的流程走。比如代码评审 skill如果回复直接给出了 P0/P1/P2 分级说明触发了如果回复是泛泛的“整体代码写得不错”说明没触发。第二步检查description是否和你实际输入的说法匹配Codex 是根据语义模糊匹配触发技能你的描述里如果写的是“当用户要求 review”而用户实际说的是“帮我看看这个代码质量”这部分匹配逻辑就要调整。第三步查看 Codex 的日志日志里会明确记录本次对话加载了哪些 skill 文件基本上这个日志一翻就知道问题出在哪。还有一个笨但有效的办法在 skill 正文的第一行写一句固定开场白比如“好的进入代码评审流程”这样只要它触发了输出一定带这句。没带就是没触发简单粗暴。4.4 发布与分享从本地目录到团队仓库一个 skill 在自己的机器上跑通之后剩下的事就是让它流转起来。最简单的分享方式是把整个 skills 目录放到 Git 仓库里团队约定好克隆后把它软链接到各自的本机 skill 路径即可。如果想要共享给更广泛的社区可以参考官方和社区常用做法把 skill 整理成一个独立仓库根目录放 README 说明用法SKILL.md 保持标准结构。我的建议是发布前一定要把 references 里的示例文件清理干净有些示例里会带有真实企业数据的痕迹删掉再提交。这既是职业习惯也是给自己省事。5. 装了 skill 之后常见的报错与排查实录5.1 “unrecognized configuration setting” 不等于配置崩了Codex 启动时如果提示“is ignoring 1 unrecognized configuration setting”很多人会慌但其实只是个警告不是致命错误。含义是配置文件里有一个当前版本不认识的键Codex 会忽略它继续运行。出现这种情况十有八九是你按旧教程配置了某个字段而新版本把它改名或者移除了。处理方式很简单逐个注释掉配置里的可疑项重新运行codex exec hi直到警告消失。我当时就是因为照着网上一个半年前的教程配了beta字段折腾半天发现新版本根本不需要它。别一上来就删整个配置文件先搞清楚是哪个键出问题。5.2 模型不支持类报错看到“gpt-5.6-sol”这类说法别慌自定义模型接入时最容易碰到的报错是model is not supported意思很简单Codex 不认识你在配置文件里指定的模型名。解决方案是把模型名改到你实际请求的那个比如 DeepSeek 的deepseek-chat或者在config.toml的模型供应商配置里把模型名字段和它的请求端点对应起来。还有一种情况是模型名对但请求的 API 路径不对Codex 走的是/responses新接口你的服务商只支持旧的/chat/completions。这就需要在配置里显式指定接口风格让 Codex 切换调用方式否则就会一直报错。这部分文本信息在报错日志里都有照着日志里显示的端点请求找问题基本都能定位。5.3 组织设置加载失败与 Windows 设置未完成unable to load organization settings这类问题通常和账号权限有关。排查顺序是先确认你登录的账号是不是 org 管理员再看组织的结算信息是否正常。很多所谓“设置加载失败”其实只是因为当前账号根本没有该项目的访问权。Windows 用户遇到的“设置未完成”提示大概率是环境变量没生效就直接启动了 Codex。我处理过一个同事的问题他把OPENAI_API_KEY通过系统设置面板配好了但终端是启动前打开的环境变量根本没读到解决方式是关掉终端重新打开再跑一次。Windows 桌面版装完后建议重启一次系统让安装器写的路径变量彻底生效。5.4 skill 目录层级不对导致的“找不到技能”这是最隐蔽也是最多人踩的坑。Codex 对 skill 目录的层级要求是“skills 目录下直接存放各个技能文件夹技能文件夹里放 SKILL.md”。很多人会把 SKILL.md 直接扔在 skills 根目录或者多套了一层文件夹Codex 都识别不到。我推荐用加编号前缀的方式管理多技能目录比如01-testing/、02-writing/既方便自己排序也方便调试时一眼看出加载顺序。文件名必须严格是SKILL.md大写改成skill.md或者skills.md都会失效。这类问题说穿了其实都特别小但因为日志信息不直观排查起来反而最费时间。5.5 本地端点切换报错的排查思路还有一种报错场景是在切换自定义模型服务时出现的提示无法正常处理某个/responses请求。这类报错的核心不在技能文件而在你的端点配置和认证信息相互冲突。排查顺序是先确认 base URL 拼写无误再确认目标服务商提供的鉴权请求头与 Codex 发送的一致最后确认当前账号对目标端点有访问权限。我自己的做法是遇到这类问题先不看 Codex 的报错直接用一个简单的curl命令请求一次目标服务商的接口看能不能通、返回什么状态码。这一下就能把问题范围切成两半接口本身的问题还是 Codex 配置的问题。6. 我踩过的坑和一些使用心得6.1 不要给 Codex 装比项目还多的 skill我见过有的朋友拿到新玩具之后狂装了几十个 skill结果每次对话都要等 Codex 扫描大量文件响应速度肉眼可见地变慢而且各个 skill 之间的约束还会互相打架。技能过载是不可忽视的配置负担。我的建议是全局目录里只留那些跨项目都通用的比如去AI味、测试、文档处理项目相关的 skill 直接放进项目仓库用随项目走的方式隔离。一个技能目录超过五个之后我基本都会重新审视一遍删掉那种“下周可能用得上”的库存思维。 skill 不是收藏品是工具工具是拿来用的不是拿来数的。6.2 命名与目录规范编码前缀怎么排才顺手目录命名直接决定你后期维护的心情。我用的是功能分类加序号的组合比如common-testing、common-writing、project-location。如果同一个分类下技能数量超过三个再在前面加两位数字前缀比如01-testing、02-writing、03-document。这样排有三个好处文件管理器里排序稳定某些工具对前缀编号有约定时不会乱你在调试日志里也很容易按编号定位到底是哪个技能被加载了。另外每个 SKILL.md 的name字段尽量和文件夹名保持一致减少不必要的认知负担。6.3 内网部署与团队共享技能库的思路有些团队的场景是代码不能离开内网于是很多人会问“deepseek harness 附带的那套 skill 能不能部署到内网服务器”。答案是完全可以。部署分两层第一层是模型推理服务内网里要有一个兼容 OpenAI 接口的推理端点可以是本地的 vLLM也可以是内网部署的 ollama通过 base URL 指过去。第二层是技能文件把整个技能仓库放到内网 Git 服务器上团队成员 clone 后软链接到本地 skills 目录这样所有人的技能版本都是一致的。这种做法最大的收益不是“安全”这个标签本身而是把团队的隐性经验显性化。原本只在老员工脑子里的代码规范、上线检查流程变成了一份每个人都能调用的 SKILL.md。哪怕那个人只做了两周也能按老员工的标准干活。6.4 最后分享一个效率小技巧写 skill 正文的时候在关键输出节点加一句“请使用检查清单格式输出”模型的输出质量会肉眼可见地提升。因为一旦它被要求用清单格式就不得不逐条检查自己有没有遗漏步骤。比如代码评审 skill 要求最后输出检查清单实际评审出的问题数量比我没见过清单格式时多了将近一倍。另一个技巧是给 skill 的description写“排他性描述”也就是明确写清楚“什么情况不要用”。这种负向描述比正向描述更能帮模型做判断。社区里大量 skill 触发失败问题都出在描述写得太泛模型不知道该不该用最后干脆不用。写下这篇东西时的实际感受这一路翻完货架又筛掉大半最大的感想其实就一句话skill 的价值不在于你拥有多少而在于你能让模型稳定复现多少次高质量输出。一个普通的测试 skill 远比十个花里胡哨但没人调用的 skill 更有意义。如果你现在还在纠结从哪个 skill 入手我的建议是先做那个你自己最痛的点。如果你每天要花一个小时给模型解释你们的项目背景那你就把这个背景整理成一个 skill如果你每天要改十遍周报的AI味那就先把去AI味 skill装上。把最痛的场景解决了你自然而然就会产生下一轮优化动力。最后再提醒一句带着编号管理你的技能目录并且记得让每个 skill 都用检查清单收尾这两个小习惯能让你少走很多弯路。