我见过太多人把 Codex 用得像个玩具——拿它改两行报错、问几句 syntax然后关掉窗口。说实话这只是在浪费它真正值钱的那部分能力。Codex 真正拉开差距的地方是它那个经常被人忽略的Skill技能机制你可以在本地给它装各种技能包让它在处理某类任务时自动切换思维模板、调用脚本、按固定流程办事。如果再顺手把 Jev 这类第三方模型服务接进来整个 CLI 的实用性会往上跳一大截。这篇文章我会用一套真实跑过的流程讲清楚三件事Skill 在 Codex 里到底是什么、怎么装、怎么写Jev 这类 OpenAI 兼容模型服务怎么挂进 Codex以及我实际跑了一周之后踩到的那些坑和完整的排查链路。适合正在用 Codex、或者正准备从聊天式 AI 编码工具转向工作台式用法的朋友。1. 先搞清楚Skill 到底在 Codex 里扮演什么角色1.1 它不是传统插件是一套可复用的指令上下文很多人一听到 Skill第一反应是像 VS Code 插件一样的东西这个类比其实会误导你。Skill 更像你给新同事准备的那本《入职手册》它不是一段随时驻留在内存里的代码而是一份精心组织的文本加上可选的脚本和资源告诉模型当你遇到这类请求时你应该按什么流程、用什么标准、输出什么格式。Codex 加载 Skill 的机制是描述匹配。每个 Skill 文件夹里都有一个核心文件通常叫SKILL.md文件头部写清楚这个技能的名字和用途描述。当你输入的问题跟这个描述命中时模型就会把这个文件的内容读进上下文然后按照里面的步骤执行。换句话说Skill 不是装了就生效而是被触发才生效这决定了你编写时要在描述上多花心思。1.2 Skill 和 Agent 的区别一句话讲透热搜词里一直有人问skill 和 agent 的区别。我自己的理解很简单Agent 一个会自己决定下一步干什么的调度器Skill 是一份遇到某类事就照着做的规范手册。Agent 可以主动拆解目标、调用工具、循环验证Skill 本身没有执行能力它只是给模型提供高质量的约束和指令。实际工程里两者常常配合Agent 负责规划Skill 负责把某个具体环节的流程标准化。你在 Codex 场景下把 Skill 理解为给模型喂的高质量指令包就够了。1.3 官方和第三方 Skill 的生态现状目前官方提供了一些示例技能社区里 GitHub 上也能搜到大量第三方 Skill 仓库名字五花八门有的封装代码评审有的封装数学建模甚至有人把一些专业课程的知识体系做成了 Skill。这里要提醒一句装第三方 Skill 之前一定先看目录结构。一个规范的 Skill 至少要有完整的SKILL.md和清晰的描述如果只有一个 README 扔进去基本不顶用。我自己踩过这个坑后面会细说。2. 装 CLI 和 Skill 前先把这几个环境细节准备好2.1 安装方式npm 全局装、官方安装包、Windows 桌面版Codex 的安装路径现在比较杂最常见的三种方式安装方式适用场景备注npm 全局安装macOS / Linux 开发者npm install -g openai/codex需要 Node.js 环境官网下载安装包不想碰命令行的用户图形化安装装完自带 CLIWindows 桌面版Windows 用户有独立客户端但底层用的还是同一套 CLI建议统一用 npm 方式装命令行版本因为 Skill 配置的调试大多在命令行里完成。装完之后先跑一次codex --version确认能正常输出版本号。2.2 认证问题的真相codex auth token is unavailable 怎么处理这个报错我见过太多次了很多人的第一反应是重新安装其实不用。这条报错的本质是 Codex 找不到一个有效的身份凭证。排查顺序就三步执行codex login走一遍浏览器授权确认账号状态正常。检查环境变量里有没有残留的OPENAI_API_KEY。如果你之前接其他工具时设置过它而它的值又失效了Codex 会优先读它导致登录态被绕过。如果上面两招都没用再看~/.codex/auth.json是不是损坏或者权限不对。这里面最容易翻车的是第 2 步。很多人明明codex login成功了但codex auth token is unavailable还是冒出来十有八九就是那个环境变量在作怪。解决方式很简单打开 shell 配置文件把残留的OPENAI_API_KEY注释掉重新开一个终端窗口再试。2.3 Skill 目录全局和项目级别放错位置Skill 的存放位置分两种全局目录和项目级目录。全局目录是~/.codex/skills/里面的技能对所有项目生效项目级目录是.codex/skills/或者.codex/skill/具体看版本只对当前项目生效。同一个 Skill 如果两边都放了项目级会覆盖全局级。这个优先级规则我之前不知道调试了很久最后才发现是两边同名打架。3. 手写一个最小可用 Skill目录结构与 SKILL.md 的写法3.1 最标准的目录长这样拿一个代码评审技能举例目录结构如下~/.codex/skills/code-review/ ├── SKILL.md └── scripts/ └── review.pySKILL.md是必有的scripts/目录是可选的用来放你想让模型调用的脚本。技能名用短横线连接如code-review里面不要带空格。3.2 SKILL.md 的 frontmatter 与正文怎么写SKILL.md的开头是 YAML 格式的前置信息至少要有name和description重点在 description因为它决定了技能什么时候被触发--- name: code-review description: 当用户要求进行代码评审、代码审查、review PR 或检查代码质量时使用本技能。 --- # 代码评审流程 ## 目标 对给定代码进行系统性评审输出可落地的修改建议。 ## 约束 - 只评审不直接重写整段代码。 - 每个问题必须标注文件路径、行号和严重程度。 - 优先指出会导致错误、安全风险、性能退化的问题。 ## 执行步骤 1. 通读代码梳理主流程。 2. 对照约束逐项检查。 3. 输出评审报告格式为问题描述 / 影响 / 修改建议。正文的核心原则是目标、约束、执行步骤、输出格式四样缺一不可。你越把模型当新员工带它给出的结果越稳定。很多人的 Skill 不生效不是因为 Codex 不支持而是 SKILL.md 里全是废话模型根本没提取到有效指令。3.3 一个能直接用的 review.py 示例脚本不是必须的但如果你的 Skill 需要做文件操作、统计分析这类事情写一个小脚本能省大量 token。下面这个review.py只做一件事找出代码里超过指定长度的函数作为评审材料的一部分。import ast import sys from pathlib import Path THRESHOLD int(sys.argv[1]) if len(sys.argv) 1 else 80 def find_long_functions(filepath): tree ast.parse(Path(filepath).read_text(encodingutf-8)) for node in ast.walk(tree): if isinstance(node, (ast.FunctionDef, ast.AsyncFunctionDef)): length node.end_lineno - node.lineno 1 if length THRESHOLD: yield f{filepath}:{node.lineno} 函数 {node.name} 共 {length} 行 if __name__ __main__: for result in find_long_functions(sys.argv[2]): print(result)大家熟悉后可以逐渐给技能加更复杂的脚本比如统计代码圈复杂度、提取 TODO 清单等思路完全一样。4. 把 Jev 这类第三方模型服务挂进 CodexOpenAI 兼容接口的接入思路4.1 为什么会有这种需求Codex 默认用的是官方模型但很多时候你想试试社区里口碑很好的第三方模型比如 Jev。Jev 在社区里讨论最多的是两件事一是它在部分推理任务上表现确实能打二是它到底开不开放模型权重。对使用者来说开源与否其实不关键关键问题只有一个——它提供不提供 OpenAI 兼容接口。只要提供理论上就能接入。4.2 接入流程申请密钥、配置环境变量、验证整个接入过程不复杂重点在配置细节。假设你已经申请到了 Jev 的 API Key社区里常说的jev密钥接下来这样做确认 Jev 服务方提供的接口地址通常是https://api.xxx.com/v1这样的格式。在 shell 配置文件~/.zshrc或~/.bashrc里写入export OPENAI_BASE_URL你的 Jev 接口地址 export OPENAI_API_KEY你的 Jev 密钥重开终端执行codex随便问一个问题看模型是用 Jev 的接口响应的。这里最关键的点是Codex 正是通过OPENAI_BASE_URL这个环境变量把请求路由到第三方服务的。官方设计上留了这个口子社区里接 DeepSeek、Qwen 走的也都是同一条路。4.3 用同样的思路接 DeepSeek、Qwen 等模型服务我把几个常见服务的接入要点整理成了表方便参考服务接口地址类型密钥类型接入注意点Jev需找服务方确认API Key确认路由路径带不带/v1DeepSeek官方文档获取API Key地址末尾斜杠不能乱加Qwen通义千问DashScope 兼容端点API Key部分区域可能要单独开权限不管接谁验证方式都一样改完环境变量执行codex观察回复如果你输入的内容能正常得到响应说明路由已经通了。4.4 一个容易忽略的细节密钥别写进全局配置再提交很多人习惯把密钥直接写死在~/.zshrc里这没问题但不能把这个文件拖进 git 仓库。更稳妥的做法是单独维护一个.env文件运行时加载set -a source ~/.codex/env set a用 Jev 这类第三方服务时密钥安全比官方场景更敏感因为它相当于把你的账户凭证暴露在本地环境变量里。我的习惯是只在当前终端会话里export不写入全局配置用完就关。5. 跑了几天之后我总结的这些坑和排查链路5.1 cc switch local proxy failed十有八九是本地转发服务的残留配置有段时间我一打开 Codex 就报这条错完整报文大致是cc switch local proxy failed while handling codex endpoint /responses。第一次遇到时我以为是 Codex 本身的问题重装了一遍没解决。后来静下心排查发现根因完全不在 Codex 上。我的完整排查链路分享出来照着走就行先看完整报错不要只看第一行。终端里往上翻找到它实际想请求的地址。检查环境变量。执行env | grep -i -E proxy|base_url|http看看有没有以前配置其他工具时留下的转发服务变量比如为调试本地服务设置的网关指向。我那次就是变量指向了一个早已不存在的本地地址。确认端口占用。如果变量指向127.0.0.1:xxxx用lsof -i :xxxx看一下这个端口还有没有服务在监听没有就说明配置失效了。清理残留配置。把对应变量注释或删除重新开终端报错消失。这条报错我强调一下它不是网络问题更不是需要额外装什么工具的问题百分之百是本地配置层的事。如果你也遇到别在 Codex 配置里浪费时间先排查环境变量。5.2 codex auth token is unavailable 的二次排查前面说了这套报错主要是认证失效但还有一种更隐蔽的情况你同时设置过OPENAI_API_KEY和通过codex login登录过Codex 会优先读环境变量。而在接 Jev 这类第三方服务时OPENAI_API_KEY会被改成 Jev 的密钥这时候原本的官方登录态就相当于被屏蔽了。这不是 bug而是环境变量的优先级设计。如果你想在官方模型和第三方模型之间来回切换最干净的做法是准备两套 shell 配置文件或者两个函数切换时一次性替换两个变量不要手动改一半留一半。我因为手动改漏过很多次每次都费半天时间。5.3 SKILL.md 太长导致上下文爆炸Skill 文件不是越长越好。我最早写的评审技能有 300 多行里面塞了各种边界情况。实际使用时发现模型一命中技能就把整份文件读进去还没开始干活上下文就占了一大截回答质量反而下降。最佳实践是把 SKILL.md 控制在 100 行以内把详细规则拆到scripts/或单独的参考文档里需要时让模型按需读取。这与给新员工手册是同一个逻辑——手册应该精炼细节留在附录。5.4 同名 Skill 的覆盖问题全局目录~/.codex/skills/code-review和项目目录.codex/skills/code-review同名时项目目录优先级更高。有一阵我改了全局技能没生效就是因为项目里躺着一个旧版本。排查办法很简单执行codex skills list部分版本叫codex skill list查看当前生效的技能列表和路径一目了然。6. 从用 Skill到写 Skill几组值得收藏的进阶玩法6.1 把重复工作流封装成 Skill很多人装完别人分享的 Skill 就满足了但真正让 Codex 变得顺手的是你把自己每周都在重复的流程固化成 Skill。随便举几个我身边的真实例子数学建模技能把建模题的标准流程问题抽象、假设、建模、求解、灵敏度分析写进 SKILL.md遇到竞赛题直接触发输出结构非常稳定。周报技能要求模型根据本周 commit 记录和 PR 记录按做了什么 / 有什么问题 / 下周计划三段式输出周报草稿。技术方案评审技能规定评审维度架构合理性、数据一致性、异常处理、可运维性每次评审都按这个框子走。社区里还有各种奇怪名字的 Skill有的叫book-to-skill作用是把一本书的知识结构自动拆成技能笔记有的把特定领域课程做成技能包。这些玩法本质上都一样把你的方法论文本化喂给模型。6.2 带脚本的 Skill让模型能真正执行动作前面code-review里的review.py是纯文本辅助脚本更进阶的玩法是让模型通过脚本和外部系统交互。比如封装一个批量检测重复代码的技能其中放一个 Python 脚本模型识别到场景后就执行脚本再把结果整理成报告输出。这里有个重要的安全约束习惯要提前养成注意凡是带执行脚本的 Skill必须在 SKILL.md 里写明执行前需用户确认并把危险的命令删除文件、覆盖数据、发请求明确列为禁止项。模型对脚本的执行不像人那么有分寸约束必须写在技能文件里。6.3 Skill 的迭代思路先小后大我自己的迭代流程是先拿一两个真实任务跑看输出离预期差多远然后修改 SKILL.md 里的约束或步骤再跑一次只改一个变量。千万不要一上来追求全都考虑到那样写出来的 Skill 基本不可用。个人建议给首个自写 Skill 选一个你最有把握、重复频率最高的场景——比如代码提交信息生成。领域足够窄你能立刻看出来它有没有用也方便对比改进。等这个跑通了你自然会理解 Skill 的设计哲学再写复杂的就轻车熟路了。最后再分享一个我实际用下来很有效的小技巧在 SKILL.md 正文第一行写一句遇到本技能描述范围内的请求时必须严格按以下流程执行不要跳过任何一步。这句话看着简单但它在模型逻辑里相当于一个强触发信号能让技能被命中的概率和稳定性都提升不少。装好 Skill、接好模型之后Codex 就不再是那个问一句答一句的聊天框了你会明显感觉到它在往半自动工作台的方向变化。这种体验值得你花一下午折腾。 Codex Skill机制实战：从编写技能包到接入Jev兼容模型服务
我见过太多人把 Codex 用得像个玩具——拿它改两行报错、问几句 syntax然后关掉窗口。说实话这只是在浪费它真正值钱的那部分能力。Codex 真正拉开差距的地方是它那个经常被人忽略的Skill技能机制你可以在本地给它装各种技能包让它在处理某类任务时自动切换思维模板、调用脚本、按固定流程办事。如果再顺手把 Jev 这类第三方模型服务接进来整个 CLI 的实用性会往上跳一大截。这篇文章我会用一套真实跑过的流程讲清楚三件事Skill 在 Codex 里到底是什么、怎么装、怎么写Jev 这类 OpenAI 兼容模型服务怎么挂进 Codex以及我实际跑了一周之后踩到的那些坑和完整的排查链路。适合正在用 Codex、或者正准备从聊天式 AI 编码工具转向工作台式用法的朋友。1. 先搞清楚Skill 到底在 Codex 里扮演什么角色1.1 它不是传统插件是一套可复用的指令上下文很多人一听到 Skill第一反应是像 VS Code 插件一样的东西这个类比其实会误导你。Skill 更像你给新同事准备的那本《入职手册》它不是一段随时驻留在内存里的代码而是一份精心组织的文本加上可选的脚本和资源告诉模型当你遇到这类请求时你应该按什么流程、用什么标准、输出什么格式。Codex 加载 Skill 的机制是描述匹配。每个 Skill 文件夹里都有一个核心文件通常叫SKILL.md文件头部写清楚这个技能的名字和用途描述。当你输入的问题跟这个描述命中时模型就会把这个文件的内容读进上下文然后按照里面的步骤执行。换句话说Skill 不是装了就生效而是被触发才生效这决定了你编写时要在描述上多花心思。1.2 Skill 和 Agent 的区别一句话讲透热搜词里一直有人问skill 和 agent 的区别。我自己的理解很简单Agent 一个会自己决定下一步干什么的调度器Skill 是一份遇到某类事就照着做的规范手册。Agent 可以主动拆解目标、调用工具、循环验证Skill 本身没有执行能力它只是给模型提供高质量的约束和指令。实际工程里两者常常配合Agent 负责规划Skill 负责把某个具体环节的流程标准化。你在 Codex 场景下把 Skill 理解为给模型喂的高质量指令包就够了。1.3 官方和第三方 Skill 的生态现状目前官方提供了一些示例技能社区里 GitHub 上也能搜到大量第三方 Skill 仓库名字五花八门有的封装代码评审有的封装数学建模甚至有人把一些专业课程的知识体系做成了 Skill。这里要提醒一句装第三方 Skill 之前一定先看目录结构。一个规范的 Skill 至少要有完整的SKILL.md和清晰的描述如果只有一个 README 扔进去基本不顶用。我自己踩过这个坑后面会细说。2. 装 CLI 和 Skill 前先把这几个环境细节准备好2.1 安装方式npm 全局装、官方安装包、Windows 桌面版Codex 的安装路径现在比较杂最常见的三种方式安装方式适用场景备注npm 全局安装macOS / Linux 开发者npm install -g openai/codex需要 Node.js 环境官网下载安装包不想碰命令行的用户图形化安装装完自带 CLIWindows 桌面版Windows 用户有独立客户端但底层用的还是同一套 CLI建议统一用 npm 方式装命令行版本因为 Skill 配置的调试大多在命令行里完成。装完之后先跑一次codex --version确认能正常输出版本号。2.2 认证问题的真相codex auth token is unavailable 怎么处理这个报错我见过太多次了很多人的第一反应是重新安装其实不用。这条报错的本质是 Codex 找不到一个有效的身份凭证。排查顺序就三步执行codex login走一遍浏览器授权确认账号状态正常。检查环境变量里有没有残留的OPENAI_API_KEY。如果你之前接其他工具时设置过它而它的值又失效了Codex 会优先读它导致登录态被绕过。如果上面两招都没用再看~/.codex/auth.json是不是损坏或者权限不对。这里面最容易翻车的是第 2 步。很多人明明codex login成功了但codex auth token is unavailable还是冒出来十有八九就是那个环境变量在作怪。解决方式很简单打开 shell 配置文件把残留的OPENAI_API_KEY注释掉重新开一个终端窗口再试。2.3 Skill 目录全局和项目级别放错位置Skill 的存放位置分两种全局目录和项目级目录。全局目录是~/.codex/skills/里面的技能对所有项目生效项目级目录是.codex/skills/或者.codex/skill/具体看版本只对当前项目生效。同一个 Skill 如果两边都放了项目级会覆盖全局级。这个优先级规则我之前不知道调试了很久最后才发现是两边同名打架。3. 手写一个最小可用 Skill目录结构与 SKILL.md 的写法3.1 最标准的目录长这样拿一个代码评审技能举例目录结构如下~/.codex/skills/code-review/ ├── SKILL.md └── scripts/ └── review.pySKILL.md是必有的scripts/目录是可选的用来放你想让模型调用的脚本。技能名用短横线连接如code-review里面不要带空格。3.2 SKILL.md 的 frontmatter 与正文怎么写SKILL.md的开头是 YAML 格式的前置信息至少要有name和description重点在 description因为它决定了技能什么时候被触发--- name: code-review description: 当用户要求进行代码评审、代码审查、review PR 或检查代码质量时使用本技能。 --- # 代码评审流程 ## 目标 对给定代码进行系统性评审输出可落地的修改建议。 ## 约束 - 只评审不直接重写整段代码。 - 每个问题必须标注文件路径、行号和严重程度。 - 优先指出会导致错误、安全风险、性能退化的问题。 ## 执行步骤 1. 通读代码梳理主流程。 2. 对照约束逐项检查。 3. 输出评审报告格式为问题描述 / 影响 / 修改建议。正文的核心原则是目标、约束、执行步骤、输出格式四样缺一不可。你越把模型当新员工带它给出的结果越稳定。很多人的 Skill 不生效不是因为 Codex 不支持而是 SKILL.md 里全是废话模型根本没提取到有效指令。3.3 一个能直接用的 review.py 示例脚本不是必须的但如果你的 Skill 需要做文件操作、统计分析这类事情写一个小脚本能省大量 token。下面这个review.py只做一件事找出代码里超过指定长度的函数作为评审材料的一部分。import ast import sys from pathlib import Path THRESHOLD int(sys.argv[1]) if len(sys.argv) 1 else 80 def find_long_functions(filepath): tree ast.parse(Path(filepath).read_text(encodingutf-8)) for node in ast.walk(tree): if isinstance(node, (ast.FunctionDef, ast.AsyncFunctionDef)): length node.end_lineno - node.lineno 1 if length THRESHOLD: yield f{filepath}:{node.lineno} 函数 {node.name} 共 {length} 行 if __name__ __main__: for result in find_long_functions(sys.argv[2]): print(result)大家熟悉后可以逐渐给技能加更复杂的脚本比如统计代码圈复杂度、提取 TODO 清单等思路完全一样。4. 把 Jev 这类第三方模型服务挂进 CodexOpenAI 兼容接口的接入思路4.1 为什么会有这种需求Codex 默认用的是官方模型但很多时候你想试试社区里口碑很好的第三方模型比如 Jev。Jev 在社区里讨论最多的是两件事一是它在部分推理任务上表现确实能打二是它到底开不开放模型权重。对使用者来说开源与否其实不关键关键问题只有一个——它提供不提供 OpenAI 兼容接口。只要提供理论上就能接入。4.2 接入流程申请密钥、配置环境变量、验证整个接入过程不复杂重点在配置细节。假设你已经申请到了 Jev 的 API Key社区里常说的jev密钥接下来这样做确认 Jev 服务方提供的接口地址通常是https://api.xxx.com/v1这样的格式。在 shell 配置文件~/.zshrc或~/.bashrc里写入export OPENAI_BASE_URL你的 Jev 接口地址 export OPENAI_API_KEY你的 Jev 密钥重开终端执行codex随便问一个问题看模型是用 Jev 的接口响应的。这里最关键的点是Codex 正是通过OPENAI_BASE_URL这个环境变量把请求路由到第三方服务的。官方设计上留了这个口子社区里接 DeepSeek、Qwen 走的也都是同一条路。4.3 用同样的思路接 DeepSeek、Qwen 等模型服务我把几个常见服务的接入要点整理成了表方便参考服务接口地址类型密钥类型接入注意点Jev需找服务方确认API Key确认路由路径带不带/v1DeepSeek官方文档获取API Key地址末尾斜杠不能乱加Qwen通义千问DashScope 兼容端点API Key部分区域可能要单独开权限不管接谁验证方式都一样改完环境变量执行codex观察回复如果你输入的内容能正常得到响应说明路由已经通了。4.4 一个容易忽略的细节密钥别写进全局配置再提交很多人习惯把密钥直接写死在~/.zshrc里这没问题但不能把这个文件拖进 git 仓库。更稳妥的做法是单独维护一个.env文件运行时加载set -a source ~/.codex/env set a用 Jev 这类第三方服务时密钥安全比官方场景更敏感因为它相当于把你的账户凭证暴露在本地环境变量里。我的习惯是只在当前终端会话里export不写入全局配置用完就关。5. 跑了几天之后我总结的这些坑和排查链路5.1 cc switch local proxy failed十有八九是本地转发服务的残留配置有段时间我一打开 Codex 就报这条错完整报文大致是cc switch local proxy failed while handling codex endpoint /responses。第一次遇到时我以为是 Codex 本身的问题重装了一遍没解决。后来静下心排查发现根因完全不在 Codex 上。我的完整排查链路分享出来照着走就行先看完整报错不要只看第一行。终端里往上翻找到它实际想请求的地址。检查环境变量。执行env | grep -i -E proxy|base_url|http看看有没有以前配置其他工具时留下的转发服务变量比如为调试本地服务设置的网关指向。我那次就是变量指向了一个早已不存在的本地地址。确认端口占用。如果变量指向127.0.0.1:xxxx用lsof -i :xxxx看一下这个端口还有没有服务在监听没有就说明配置失效了。清理残留配置。把对应变量注释或删除重新开终端报错消失。这条报错我强调一下它不是网络问题更不是需要额外装什么工具的问题百分之百是本地配置层的事。如果你也遇到别在 Codex 配置里浪费时间先排查环境变量。5.2 codex auth token is unavailable 的二次排查前面说了这套报错主要是认证失效但还有一种更隐蔽的情况你同时设置过OPENAI_API_KEY和通过codex login登录过Codex 会优先读环境变量。而在接 Jev 这类第三方服务时OPENAI_API_KEY会被改成 Jev 的密钥这时候原本的官方登录态就相当于被屏蔽了。这不是 bug而是环境变量的优先级设计。如果你想在官方模型和第三方模型之间来回切换最干净的做法是准备两套 shell 配置文件或者两个函数切换时一次性替换两个变量不要手动改一半留一半。我因为手动改漏过很多次每次都费半天时间。5.3 SKILL.md 太长导致上下文爆炸Skill 文件不是越长越好。我最早写的评审技能有 300 多行里面塞了各种边界情况。实际使用时发现模型一命中技能就把整份文件读进去还没开始干活上下文就占了一大截回答质量反而下降。最佳实践是把 SKILL.md 控制在 100 行以内把详细规则拆到scripts/或单独的参考文档里需要时让模型按需读取。这与给新员工手册是同一个逻辑——手册应该精炼细节留在附录。5.4 同名 Skill 的覆盖问题全局目录~/.codex/skills/code-review和项目目录.codex/skills/code-review同名时项目目录优先级更高。有一阵我改了全局技能没生效就是因为项目里躺着一个旧版本。排查办法很简单执行codex skills list部分版本叫codex skill list查看当前生效的技能列表和路径一目了然。6. 从用 Skill到写 Skill几组值得收藏的进阶玩法6.1 把重复工作流封装成 Skill很多人装完别人分享的 Skill 就满足了但真正让 Codex 变得顺手的是你把自己每周都在重复的流程固化成 Skill。随便举几个我身边的真实例子数学建模技能把建模题的标准流程问题抽象、假设、建模、求解、灵敏度分析写进 SKILL.md遇到竞赛题直接触发输出结构非常稳定。周报技能要求模型根据本周 commit 记录和 PR 记录按做了什么 / 有什么问题 / 下周计划三段式输出周报草稿。技术方案评审技能规定评审维度架构合理性、数据一致性、异常处理、可运维性每次评审都按这个框子走。社区里还有各种奇怪名字的 Skill有的叫book-to-skill作用是把一本书的知识结构自动拆成技能笔记有的把特定领域课程做成技能包。这些玩法本质上都一样把你的方法论文本化喂给模型。6.2 带脚本的 Skill让模型能真正执行动作前面code-review里的review.py是纯文本辅助脚本更进阶的玩法是让模型通过脚本和外部系统交互。比如封装一个批量检测重复代码的技能其中放一个 Python 脚本模型识别到场景后就执行脚本再把结果整理成报告输出。这里有个重要的安全约束习惯要提前养成注意凡是带执行脚本的 Skill必须在 SKILL.md 里写明执行前需用户确认并把危险的命令删除文件、覆盖数据、发请求明确列为禁止项。模型对脚本的执行不像人那么有分寸约束必须写在技能文件里。6.3 Skill 的迭代思路先小后大我自己的迭代流程是先拿一两个真实任务跑看输出离预期差多远然后修改 SKILL.md 里的约束或步骤再跑一次只改一个变量。千万不要一上来追求全都考虑到那样写出来的 Skill 基本不可用。个人建议给首个自写 Skill 选一个你最有把握、重复频率最高的场景——比如代码提交信息生成。领域足够窄你能立刻看出来它有没有用也方便对比改进。等这个跑通了你自然会理解 Skill 的设计哲学再写复杂的就轻车熟路了。最后再分享一个我实际用下来很有效的小技巧在 SKILL.md 正文第一行写一句遇到本技能描述范围内的请求时必须严格按以下流程执行不要跳过任何一步。这句话看着简单但它在模型逻辑里相当于一个强触发信号能让技能被命中的概率和稳定性都提升不少。装好 Skill、接好模型之后Codex 就不再是那个问一句答一句的聊天框了你会明显感觉到它在往半自动工作台的方向变化。这种体验值得你花一下午折腾。