1. 为什么每次都要重新给 Codex 讲一遍检查规则我最初用 Codex 做代码检查时习惯在每次会话开头贴一大段要求先读项目规范、别动无关文件、跑完测试再汇报。单次任务里这套话术确实管用但只要换一个仓库、开一个新会话甚至只是隔天回来继续改同一个项目这些要求就全部清零得重新讲一遍。时间一长你会发现真正消耗精力的不是写代码而是反复向工具解释「我们这个项目该怎么检查」。这个问题的本质是把「一次性对话指令」和「长期可复用流程」混在了一起。对话指令只对当前任务有效关掉就没了而代码检查这种动作往往是跨任务、跨会话反复出现的。你真正想固化的不是某句万能提示词而是一套稳定的操作步骤交付前先读规范、检查改动范围、运行仓库已有的测试、最后报告风险。这套步骤如果每次都靠手打既容易漏也没法保证一致性。Codex 提供了两个互补的机制来解决这件事。一个是 AGENTS.md它相当于项目的说明书告诉 Codex 这个仓库有哪些固定规则比如用哪个包管理器、该跑哪些测试命令、哪些文件不能提交。另一个是 Skill它是一套有明确触发场景的操作流程可以附带脚本、参考资料和模板在多个任务之间复用。把这两者配合起来你就能把「检查工作流」从记忆负担变成可维护的文件。判断一条信息该放哪里有个简单标准只对当前任务有效的要求直接写在本次对话里当前仓库长期有效的规范写进 AGENTS.md能在多个任务中重复使用的完整流程做成 Skill。按这个标准代码检查显然属于第三类因为它步骤固定、反复出现而且漏掉某一步会产生真实成本比如把不该提交的文件带进版本库或者跳过了本该跑的回归测试。这篇内容会带你从零搭一个「交付前检查」Skill配上对应的 AGENTS.md并给出触发检查、验证输出一致性的具体动作。全程只需要一个能访问 Codex 的环境以及一个你想规范化的代码仓库。下面先从接入准备讲起。2. TaoToken 接入准备拿到 Base URL、Key 和 Model ID在写 Skill 之前得先让 Codex 能正常调用模型。如果你已经在用官方通道可以跳过这一节如果你希望通过统一的 API 入口来管理调用可以按下面的方式准备三件套Base URL、API Key、Model ID。这三样是任何 OpenAI 兼容客户端接入的基础缺一不可。先到控制台创建一把 API Key。打开 https://taotoken.net/api-keys 登录后新建密钥复制出来保存好。注意 Key 只在创建时完整显示一次关掉页面就看不到了所以务必先存到安全的地方不要直接写进代码或 Skill 文件里。Base URL 统一使用 https://taotoken.net/api 这是所有兼容请求的入口前缀。Model ID 则根据你要用的模型填写比如常见的对话与代码模型名称。把这三个值记下来后面配置 Codex 时会用到。这里要强调一个安全习惯不要把 API Key、密码、Cookie 或服务器地址直接写进 Skill。Skill 应该描述「如何从环境变量取用」而不是保存敏感值本身。正确做法是把 Key 放进环境变量Skill 和 AGENTS.md 里只引用变量名。这样即使 Skill 文件被提交到仓库也不会泄露凭据。如果你还想先验证模型是否可用可以打开模型对话页面 https://taotoken.net/models 直接发一条测试消息确认返回正常后再进入配置环节。对于需要长期跑编码任务或 Agent 流程的场景也可以了解 Coding Plan https://taotoken.net/coding-plan 它更适合高频、持续的调用需求。准备好这三件套之后下一步就是把它们写进 Codex 的配置文件。不同客户端的配置路径不一样下面给出可直接复制的片段。3. 可复制配置settings、auth.json 与 Skill 目录结构配置分两部分一是让 Codex 能连上模型二是让 Codex 能发现你的 Skill。先看连接配置。如果你用的是支持 settings 文件的客户端可以新建或编辑配置文件填入下面这段 JSON。注意把YOUR_API_KEY替换成你刚才创建的真实 KeyModel ID 按需调整。{ base_url: https://taotoken.net/api, api_key: YOUR_API_KEY, model: gpt-4o-codex }如果你用的是 Codex CLI 这类读取auth.json的工具配置写法略有不同。文件通常位于用户目录下的配置文件夹中内容形如{ OPENAI_BASE_URL: https://taotoken.net/api, OPENAI_API_KEY: YOUR_API_KEY, model: gpt-4o-codex }无论哪种写法核心都是三件套Base URL 指向https://taotoken.net/apiKey 用你自己的Model ID 填你要用的模型。三件套齐全请求才能正确路由。接下来是 Skill 的目录结构。按照 Codex 的约定项目级 Skill 放在仓库的.agents/skills目录下个人全局 Skill 放在$HOME/.agents/skills。我们做一个「交付前检查」Skill目录长这样.agents/ └── skills/ └── preflight-review/ └── SKILL.md每个 Skill 至少包含一个SKILL.md并在文件开头用 YAML front matter 声明name和description。description是最容易被忽略、却最关键的一行因为它决定了 Codex 什么时候会触发这个 Skill。不要只写「代码检查工具」而要把使用时机写清楚比如「在提交、发布或交付代码前检查改动范围、项目规范、测试结果和潜在风险」。描述越具体误触发和漏触发就越少。SKILL.md的正文部分写具体步骤。下面是一份可以直接用的示例--- name: preflight-review description: 在提交、发布或交付代码前检查改动范围、项目规范、测试结果和潜在风险。 --- # 交付前检查 1. 先读取当前目录适用的 AGENTS.md。 2. 查看 git status 和 git diff理解实际改动。 3. 检查是否修改了任务范围之外的文件。 4. 只使用项目已经定义的命令运行测试、构建或静态检查。 5. 不执行删除、重置、强制推送等破坏性操作。 6. 最后列出改动内容、验证结果和仍需注意的风险。这份 Skill 把「检查边界」写成了可维护的文件而不是靠每次对话临时描述。配合 AGENTS.mdCodex 就能先知道项目规则再按固定步骤执行检查。4. 用 AGENTS.md 固定项目规则并触发检查Skill 解决「按什么步骤做」AGENTS.md 解决「这个项目有哪些固定规则」。两者分工明确Skill 是流程AGENTS.md 是约束。在仓库根目录新建AGENTS.md写入下面这些长期有效的内容# Project Rules - 前端统一使用 bun不使用 npm。 - 后端修改完成后运行 go test ./...。 - 不提交 .env、密钥和本地生成文件。 - 不修改任务范围之外的文件。 - 交付前必须检查 git diff。规则要尽量短只记录真正需要长期遵守的条目。临时需求仍然留在当前对话里不要一股脑塞进 AGENTS.md否则文件会越来越臃肿反而没人维护。如果仓库里不同目录使用不同技术栈可以在子目录继续放置更具体的 AGENTS.mdCodex 会读取当前目录适用的那一份。配置完成后触发检查的动作很简单。完成一次修改后直接对 Codex 说请使用 preflight-review 检查当前改动。 发现问题先说明原因不要直接删除或重置文件。这时流程会变得稳定Codex 先找项目规则再看真实 diff然后运行仓库已经提供的验证命令最后给出一份可以复查的结果。相比「帮我全面检查一下」「全面」对每个人的含义都不同而 Skill 把检查边界写成了文件结果自然更一致。验证输出一致性时可以连续跑两次同样的检查对比两次报告的结构是否一致是否都先列改动范围、再列测试结果、最后列风险。如果两次差异很大说明 Skill 步骤写得不够明确或者 AGENTS.md 里的规则有歧义需要回去补充。实测下来把步骤编号写清楚、把「只使用项目已定义的命令」这类约束写死一致性会明显提升。还有一个容易踩的坑不要让 Skill 自己发明测试命令。它应该先读取package.json、Makefile、项目文档或 AGENTS.md使用仓库真实存在的命令。否则 Codex 可能编出一个根本不存在的脚本跑出一堆假报错。5. 常见报错排查401、local proxy failed 与 OAuth配置和触发过程中最常见的几类报错集中在鉴权和连接上。下面按真实报错逐条对照排查。第一类是 401 Unauthorized。这通常意味着 Key 无效、过期或者请求头里的鉴权字段没带上。排查顺序是先确认auth.json或 settings 里的api_key是不是完整复制有没有多余空格再确认 Base URL 是否写成了https://taotoken.net/api路径多一个斜杠或少一个斜杠都可能导致鉴权失败最后确认这个 Key 在控制台里状态正常、没有超出配额。如果三件套里 Model ID 填错有时也会返回类似的鉴权类错误所以顺手核对一下模型名。第二类是 local proxy failed。这个报错一般出现在客户端尝试走本地转发时。先检查你的配置里有没有残留的本地代理地址比如指向127.0.0.1某个端口的设置。如果有把它清掉让请求直接走https://taotoken.net/api。另外确认本机网络能正常访问该地址可以用一条简单的 curl 测试连通性curl -s -o /dev/null -w %{http_code} https://taotoken.net/api如果返回 200 或 401说明网络通、服务可达如果超时则是网络层问题需要检查本机网络设置。第三类是 OAuth 相关报错。有些客户端默认走 OAuth 登录流程当你改用 API Key 接入时旧的 OAuth 缓存可能还在生效导致冲突。解决办法是清理客户端的登录缓存重新以 API Key 方式配置。具体路径因客户端而异通常在用户配置目录下找到认证缓存文件删除后重启即可。第四类是reading choices报错。这通常说明返回体结构不符合预期常见原因是 Model ID 填了一个不存在的模型或者请求被路由到了不兼容的端点。核对 Model ID 拼写确认它在你所用通道里是有效的。如果问题依旧换一个已知可用的模型名测试能快速定位是模型名问题还是通道问题。排查时有个通用思路先确认三件套Base URL、Key、Model ID是否齐全且正确再看网络是否可达最后看客户端缓存是否需要清理。绝大多数报错都落在这三步之内。如果还是解决不了可以对照接入文档 https://taotoken.net/doc 里的示例逐项核对文档里的请求样例可以直接拿来对比你的配置。6. 把检查工作流沉淀下来从一个小 Skill 开始走到这里你已经有了一个能跑的「交付前检查」Skill、一份项目级 AGENTS.md以及一套排查常见报错的方法。剩下的就是把它用起来并在使用中微调。哪些流程值得做成 Skill我的判断标准是三个特点同时满足重复出现、步骤相对固定、漏掉某一步会产生真实成本。比如发布前检查代码、迁移和配置根据接口定义执行回归测试检查数据库迁移的兼容性补全多语言文案并验证缺失项按固定模板生成变更说明对安全配置进行只读审查。这些都很适合沉淀。相反一次性的产品讨论、临时文案修改没必要急着做成 Skill等流程稳定了再沉淀维护成本更低。如果你已经在用 Codex建议先从一个很小的 Skill 开始只解决一个重复问题写清楚触发条件用一周后再根据实际误差调整。通常这比一开始设计一套庞大的「全自动工作流」更有效。AGENTS.md 让 Codex 理解当前项目Skill 让它复用一套工作方法两者配合后每次任务仍然需要人做判断但很多容易遗忘的步骤不必再靠记忆维持。需要人工比较调用成本时可以查看官方定价或公开价格页把成本口径记录在项目文档里而不是写死在通用 Skill 中。涉及模型调用的 Skill建议只描述「如何取用环境变量」把具体供应商和价格留在配置层这样 Skill 本身保持通用换通道时不用改流程。最后留一个可以直接上手的动作在你的仓库里建好.agents/skills/preflight-review/SKILL.md把上面那份示例填进去再补一份根目录 AGENTS.md然后对 Codex 说一句「请使用 preflight-review 检查当前改动」。跑通一次之后你就有了一个可复用的检查工作流下次开新会话也不用再从头解释。