上周有个朋友给我发消息说他把 Codex 下载下来打开之后发现自己站在一个蓝框面前完全不知道下一步该干嘛。这个场景我见得太多了——大多数人对 Codex 的预期是“又一个 AI 聊天窗口”结果打开以后面对的是一个命令行交互界面瞬间就懵了。Codex 真正有意思的地方在于它不是帮你“出主意”的它是一个真的会动手改你代码、跑你测试、执行你命令的终端智能体。这篇文章我想把这一路摸爬滚打的经验完整写出来从安装、认证到接入 DeepSeek 这种第三方模型再到高频报错的排查和高阶配置篇幅会比较长但每一步都是能直接照做的。1. Codex 到底是什么先把三个错误预期纠正过来1.1 它不是聊天框是一个住在终端里的“执行者”很多人第一次启动 Codex 之后会习惯性地输入一句“你好你是谁”然后等它回一段自我介绍。这不怪用户毕竟这两年大家已经被各种对话框训练出了肌肉记忆。但 Codex 的定位完全不同它默认拥有读取项目文件、在终端执行命令、修改代码的权限你给它的不是一个“问题”而是一个“任务”。我可以给一个比较贴近实际的类比想象你请了一个外包工程师他坐在你的电脑前能够打开终端、翻阅代码、运行测试、修改文件但他每做一步动作之前都会停下来请示你。Codex 就是这样一个“住在终端里的执行者”。你让它修 bug它不是给你一段修复建议而是真的把代码改掉然后把 diff 展示给你看。这也解释了为什么 Codex 的使用体验和聊天类产品完全不同。聊天产品追求的是“回得好”Codex 追求的是“做得到”。它内部有一套 plan-act-observe 的循环先规划怎么完成任务然后执行命令或改文件再观察结果如果不对就继续调整直到你满意或它放弃。这种循环是 Codex 与普通 AI 工具最本质的区别。1.2 它给的不是“答案”而是“动作”同样一个问题你问 Copilot 或 ChatGPT得到的是解释和代码片段你问 Codex它可能会直接运行pytest发现失败用例定位到具体文件修改代码再重新跑一遍测试最后把整个过程的记录和改动清单交付给你。我说一个真实的使用场景。有次我的同事说“这个项目里的登录接口超时时间写死了帮我都抽成配置项”。这句话如果扔给传统 AI 工具你大概率会得到一段“应该怎么改”的建议然后自己照着改。但扔给 Codex 之后它会先全项目搜索超时时间相关的硬编码列出所有出现的位置逐个改成从配置文件读取再跑已有的测试确认没有破坏行为最后给你一份清晰的改动摘要。这中间的差异非常关键Codex 的核心价值不是“告诉你答案”而是“替你完成动作”。你在意的是那个测试能不能跑绿、那个 diff 能不能合并而不是一段漂亮的解释。从这个角度看它更像是“自动驾驶模式”而 Copilot、Cursor 这类工具更接近“辅助驾驶”。1.3 但也不是所有任务都适合交给它把 Codex 神话也是不行的。我自己的经验是它对几类任务特别在行跨文件重构比如把某工具函数从 A 模块挪到 B 模块并批量更新引用修测试失败尤其是断言、mock、测试数据这类问题补测试、写脚本、格式化代码、加注释、清理无用 import把老接口调用方式迁移到新 SDK这种机械性很强的批量操作。不太适合的任务也有几类。比如需要跟远程环境频繁交互的部署排障、需要敏感生产数据支撑的修改、跨七八个服务的大范围改造。不是 Codex 不够聪明而是这类任务的上下文很难完整放进一个终端会话里它看不到你脑子里的全局约束。另外如果你自己对项目的目标和约束都还很模糊那 Codex 大概率也会跑偏。所以我的建议是第一次使用不要在大型生产项目上直接实战先找一个干净的、结构简单的小项目试水摸清它能做什么、不能做什么再逐步放开权限。这样你对它建立起来的信任才是真实的。2. 安装与首次启动把 Codex 跑起来的关键细节2.1 安装之前先把三个前提确认好安装 Codex 本身不复杂但很多人死在环境上。第一个前提是 Node.js 版本。Codex CLI 基于 Node.js 开发社区里比较一致的结论是至少需要 Node 20 以上的版本。你在终端里先执行一下node -v如果版本太低先去装新版本再回来不然 npm 安装阶段就会报错。第二个前提是终端环境。Windows 用户我强烈建议用 Windows Terminal而不是默认的 CMD 或老版 PowerShell。不是因为 CMD 跑不了而是 Codex 的交互界面涉及颜色、光标控制、历史记录Windows Terminal 的兼容性好很多刷屏、乱码、按键失灵这类问题能少一大半。第三个前提是网络。Codex 安装包从 npm 仓库拉取运行时需要请求模型服务。这里的核心不是网速多快而是要保证你能正常访问对应的依赖源和 API 服务。如果下载时反复超时可以先检查 npm 源配置是否正常、DNS 是否解析到正确地址再考虑用镜像源重试。环境问题不要在安装阶段硬扛先确认网络连通再继续。2.2 CLI 安装与登录最稳妥的一条路径桌面版虽然好看但绝大多数实战场景里大家最常用也最稳定的是 CLI 版本。安装命令很简单npm install -g openai/codex codex --version如果你连 npm 全局安装都用不习惯也可以不全局安装直接通过npx openai/codex临时启动。全局安装的好处是后面可以随时在任意目录执行codex而且便于和 Git、脚本、CI 配合。安装完成之后处理认证这一步最容易出问题。Codex 支持两种认证方式一是用 ChatGPT 账号登录二是直接用 API Key。codex login执行codex login会打开浏览器让你登录 ChatGPT 账号登录成功后 Codex 会把凭据写入家目录下的.codex/auth.json文件。如果你不想用 ChatGPT 账号也可以用 OpenAI 的 API Key设置环境变量即可export OPENAI_API_KEYsk-你的key这里有个很关键的细节codex login写入的 auth.json 和OPENAI_API_KEY是两套平行的认证机制。Codex 在启动时会优先读取本地登录态如果没有登录态再找环境变量。很多人在 CI 或者计划任务里遇到 “auth token is unavailable”就是因为这两个条件一个都不满足后面我会专门展开讲。2.3 Windows 桌面版安装未完成别在安装器上死磕热词里“codex windows 安装未完成”是一个非常高频的问题。我自己在 Windows 上装桌面版时就卡过一次进度条走到一半停住等了十分钟没有反应最后强制结束安装进程。后来我仔细排查了一遍原因是安装包自身很小真正的程序主体和运行时组件是在安装过程中联网下载的只要这期间网络波动或者安全软件把某个下载组件拦截了安装就会卡住或直接失败。如果你也遇到这个问题按下面的顺序排查以管理员身份重新运行安装程序很多权限不足导致的写入失败会直接消失暂时关闭杀毒软件的实时防护Windows Defender 偶尔会把安装器释放的临时文件误判为风险检查系统盘剩余空间安装过程需要解压和缓存空间不足也会表现为“卡住”而不是“报错”找到安装日志搜索关键字error或failed看具体卡在哪一步。我的个人建议是如果桌面版反复安装不成功不要在上面纠缠直接用npm install -g openai/codex装 CLI 版。桌面版本质上是 CLI 加一个图形壳核心功能 CLI 全都有而且 CLI 的安装过程简单得多。2.4 安装完成后先做一次“健康检查”装完 Codex先别急着跑真实项目花两分钟做一个健康检查确认三点CLI 能启动、认证有效、沙箱能读写文件系统。先建一个临时测试目录mkdir codex-test cd codex-test git init codex进入交互界面后输入一段非常简单的指令“请先列举当前目录下的所有文件然后告诉我这是一个什么结构的项目。”如果它能够正常读取目录并给出回答说明认证没问题沙箱也能工作。如果这里就报错大多数情况下是认证问题或网络问题直接跳到第五节排查。还有一个我后来才注意到的小技巧在交互式会话里随时输入/status可以查看当前会话用的模型、上下文长度和状态。这个命令在健康检查阶段就能用确认一下当前模型是不是你预期的那一个避免后面跑了一堆任务才发现模型配置错了。3. 把 Codex 接上 DeepSeek 等第三方模型完整配置与踩坑3.1 为什么这么多人想换模型Codex 官方默认走 OpenAI 的模型体系需要 ChatGPT 账号或 OpenAI 官方 API 额度。但在国内团队的语境下大家更常用的是 DeepSeek、通义千问这类国产模型的 API原因无非两个一是成本确实低很多二是账号和调用方式对国内用户更友好。Codex 之所以能接入第三方模型是因为它的模型供应商抽象层做得比较清晰只要目标服务提供 OpenAI 兼容接口也就是请求路径和返回格式基本一致Codex 就能把模型供应商“换”成你自己的。DeepSeek 的 API 属于 OpenAI 兼容接口所以接起来完全可行这也是“codex 接入 deepseek”会成为热搜词的原因。3.2 配置 DeepSeek 供应商的完整步骤先在 DeepSeek 开放平台创建 API Key然后把以下配置写入~/.codex/config.tomlmodel deepseek/deepseek-chat [model_providers.deepseek] base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY上面的配置声明了一个名为deepseek的模型供应商它的接口地址是 DeepSeek 的 OpenAI 兼容端点API Key 从环境变量DEEPSEEK_API_KEY读取。model字段里的deepseek/deepseek-chat表示“使用 deepseek 这个供应商下的 deepseek-chat 模型”。然后设置环境变量。Linux 或 macOSexport DEEPSEEK_API_KEYsk-你的keyWindows PowerShell$env:DEEPSEEK_API_KEYsk-你的key设置完成之后启动codex再输入/status确认当前模型显示为deepseek/deepseek-chat就说明接入成功了。这里有几个容易踩的坑。第一base_url有的文档写https://api.deepseek.com有的写https://api.deepseek.com/v1两者在兼容性上会有微妙差异建议先用带/v1的版本如果请求报 404 再改成不带/v1的。第二模型名要用 DeepSeek 平台真实存在的名字比如deepseek-chat或deepseek-reasoner不要自己拼一个看起来很合理但不存在的模型名。第三改完环境变量之后一定要重启终端或重新加载 shell 配置不然环境变量没有生效Codex 会一直报认证错误。3.3 为什么改完还是报 model not supported关于热词里那个 “the gpt-5.6-sol model is not supported when using codex with a...” 的报错我可以负责任地说绝大部分情况下是因为模型名写了一个 Codex 不认识的名字。Codex 在发起请求之前会先对模型名做一次基本校验。如果配置里写的模型像gpt-5.6-sol这种听上去很厉害但实际不存在的名字校验阶段就直接拒绝了。那为什么有人会写这种名字大概率是看到了某个内测分享或者教程里贴了一段示例以为这是官方新发布的模型结果对方只是随手编的。解决这个问题的方法很简单先执行codex --version确认当前版本尽量保持最新登录模型服务商的控制台把“真实存在的模型 ID”抄下来在config.toml里把model字段改成真实的模型名重启 Codex 会话用/status验证。有一点要专门提醒Codex 对官方模型名有白名单校验但对第三方供应商的模型名通常不会做强制白名单限制所以如果你接的是 DeepSeek却仍然报 not supported那基本就是你配置里的模型名和实际请求的模型名不一致——很大概率是config.toml没有被正确加载。改完配置之后一定要新开一个会话不要在一个旧的交互式会话里继续输入旧会话可能还持有旧的模型配置。3.4 多供应商切换一个值得长期坚持的习惯如果你既想用 OpenAI 官方模型又想在需要的时候切到 DeepSeek我的建议是不要反复修改同一个配置文件而是准备多个配置文件通过启动参数切换。我在~/.codex/下至少维护两个配置文件config.toml默认用 OpenAI 官方模型config.deepseek.toml用 DeepSeek 供应商。然后配合别名使用alias codex-openaicodex --config ~/.codex/config.toml alias codex-deepseekcodex --config ~/.codex/config.deepseek.toml这样切供应商只需要敲不同的命令不需要每次去改文件也不会出现“改了 A 供应商的配置结果下次切回官方模型时忘了改回来”的尴尬。另一个细节是不同供应商的 API Key 对应的环境变量名不要共用比如一个用OPENAI_API_KEY另一个用DEEPSEEK_API_KEY这样两个配置文件即使同时存在也不会互相污染。4. 日常使用技巧把 Codex 真正用进你的一天4.1 exec 模式适合“一句话待办”Codex 交互式会话适合复杂任务但很多日常小任务根本不需要开启一个会话慢慢聊一句话就能说清楚。这时候用codex exec更合适。codex exec 给 README.md 补上项目的启动步骤和依赖说明codex exec会把这句话直接当作任务执行执行完就退出不会进入交互界面。它的好处是非交互、可脚本化你可以把它串进 Git hooks、shell 脚本、CI 流水线实现一些自动化的批量操作。我用得比较多的一个场景是批量处理杂事。比如代码库里有几十个文件缺少类型标注我会写一个小脚本对每个子目录执行一次codex exec 给这个目录下所有 Python 函数的参数和返回值补上类型标注这种机械化的任务人工做又烦又容易漏Codex 做起来反而很快而且改完的 diff 我可以快速 review。需要注意exec模式在严格的审批策略下可能不会真的执行修改动作如果你确认要在完全自动化的场景用需要在配置或命令行参数层面放行这个放到第六节细说。4.2 审批模式和沙箱等级怎么搭配用Codex 有两个安全维度一个是沙箱等级决定它能碰哪些文件一个是审批策略决定它在执行命令或写文件之前要不要征求你的同意。沙箱等级大致分三档等级可操作范围适合场景read-only只能读文件可以执行命令但不能改文件代码审查、解释代码、搜索定位workspace-write可以修改当前工作区内的文件日常改代码、重构、修测试danger-full-access可以修改任何路径并执行任意命令信任的隔离环境、一次性批量任务我的习惯是日常开发用workspace-write因为绝大多数修改都发生在当前项目里够用且安全。只有在明确知道自己在干什么的情况下才会用danger-full-access而且用之前会把当前 Git 工作区提交干净这样即使 Codex 改坏了也能回滚。审批策略建议保持默认也就是每个有风险的动作都会停下来问你。有些人为了省事一上来就全局关掉审批结果 Codex 自作主张把配置文件改得面目全非。我的经验是审批带来的那点摩擦远小于改错代码带来的返工成本。4.3 给 Codex 提供足够好的上下文同样的 Codex有人用起来像老工程师有人用起来像刚实习的毕业生差别主要在于你怎么给它输入。如果你只说一句“帮我看看这个项目怎么跑不起来”Codex 会像无头苍蝇一样乱翻最后给你一堆猜测。更好的做法是把这个任务当成你在给一个刚入职的同事派活说清楚项目背景、涉及的文件、复现步骤、你期望的结果。举个例子低质量的指令是这个登录功能有问题帮我修一下。高质量一点的指令是在 src/auth/login.py 里login 函数设置了 5 秒超时但是稳定复现超时。请先用 tests/test_login.py 里的测试复现这个问题定位超时位置然后修复并保证 pytest 全部通过。你看这个指令里包含了明确的范围、复现方式、验证标准。Codex 收到这样的指令就会沿着一条清晰路径执行而不是东一下西一下。还有一个技巧让 Codex 先列计划再动手。在会话开始时加一句“先输出你的修改计划确认后再动手”能有效防止它在错误方向上一路狂奔。等它把计划列出来你一看不对直接纠正比等它改完代码再返工节省得多。4.4 交互会话里的高频指令建议记下来Codex 的交互式会话里有一些内置斜杠指令掌握之后效率能提升一大截/model临时切换模型不用改配置文件/status查看当前会话状态、模型、上下文用量/clear清空当前会话的上下文重新开始/undo撤销刚才的修改/reset重置会话状态。另外一个容易被忽略的用法是在 Codex 会话里输入!开头的内容它会直接把后面的命令交给系统 shell 执行不用退出 Codex。比如在对话过程中想看一下当前分支状态直接输入!git status就能看到结果非常顺手。我个人的工作流是这样的先codex进入会话用自然语言描述需求让它先输出计划确认计划后让它实施实施过程中穿插!git diff查看改动收尾时要求它跑一遍测试然后我退出会话自己 review 完整 diff。整个过程 Codex 承担了大部分执行工作但决策和验收始终握在我手里。5. 高频报错排查auth token、model not supported、switch 工具报错的完整链路5.1 auth token is unavailable非交互环境的认证坑这个报错我见过太多次了尤其是在服务器、CI 流水线、Windows 计划任务里跑codex exec的时候。它不是 Codex 本身坏了而是 Codex 在非交互环境下找不到任何可用的凭据。Codex 找认证信息的顺序大概是先看本地是否存在登录态~/.codex/auth.json再看有没有设置对应的 API Key 环境变量。如果两个都没有它就只能报 “auth token is unavailable”。排查这一步的时候不要瞎猜按链路来在交互式终端里执行codex login确保本地能正常登录这一步能排除账号本身的问题检查auth.json是否存在且未过期如果文件存在但令牌过期删除它然后重新登录如果现场确实是无交互环境那就显式设置 API Key 环境变量比如export OPENAI_API_KEYsk-xxx或者供应商对应的环境变量在定时任务场景里额外确认环境变量是否真的传进了任务进程。我在 Windows 计划任务里踩过一个很经典的坑在系统环境变量里明明配好了 key但计划任务运行时 Codex 还是说找不到 token。原因是计划任务默认不会加载用户级环境变量任务里的进程根本看不到那个 key。解决办法是在任务设置里显式指定环境变量或者在启动命令里临时注入。安全建议API Key 这类敏感信息千万不要写进仓库也不要把 auth.json 复制到共享目录。在 CI 里用平台的 secrets 管理在本地用.env文件或系统级环境变量管理。5.2 “cc switch local ... failed”这类转发工具报错问题在中间层很多人在使用 cc switch 这类“API 切换/本地转发工具”时会遇到一个和 Codex 自身没直接关系的报错。热心网友分享的错误信息大概是 “cc switch local ... failed while handling codex endpoint /responses”Codex 的请求走不出去拿不到响应。这个报错的根源是这类工具会在本地启动一个转发服务把 Codex 发出的请求导流到真实的模型服务。如果这个本地转发服务没有正常启动、进程崩溃、端口被占用或者和当前 Codex 版本不兼容Codex 调用/responses端点时就会失败。遇到这个报错我的排查顺序是先看 cc switch 的主界面或系统托盘确认它显示的本地服务状态是不是正常运行如果它显示运行中但还是报错检查端口占用情况——Windows 用netstat -ano | findstr 端口号macOS/Linux 用lsof -i :端口号看看端口是否真的被它的进程监听重启 cc switch让本地转发服务重新初始化如果重启无效临时把 Codex 的base_url改回模型服务商的官方地址确认 Codex 本身能正常请求确认 Codex 版本和 cc switch 的兼容性必要时升级任一方。有一点要特别强调这个报错和模型本身没有关系你在config.toml里改模型名、改供应商都解决不了。问题出在“本地转发服务”这一层时间不要浪费在改模型配置上。如果你根本不需要这类转发工具直接让 Codex 连官方地址绕开中间层问题自然消失。5.3 model not supported 为什么反复出现模型名不是你想叫什么叫什么前面章节已经讲过 model not supported 的常规解法这里我再往深挖一层。Codex 的模型名校验其实分两种情况对于 OpenAI 官方模型它有一个白名单不在名单里的直接拒绝对于第三方模型它通常会放行让请求直接打到服务商那里。这就会造成一个很有趣的现象同一个模型名在 OpenAI 场景下被拒换成第三方供应商配置却可能通过。很多人不理解这一点以为把所有模型名都换成gpt-...系列就能解决结果越改越乱。正确的态度是把模型名当作“供应商平台上的唯一标识”以服务商控制台实际列出的为准。你说你想用gpt-5.6-sol但 OpenAI 官方模型列表里根本没有这个名字Codex 自然不认识。同样的道理如果你在 DeepSeek 平台想用deepseek-chat那就老老实实写deepseek/deepseek-chat前面那个deepseek是供应商名后面才是真实模型名。如果排查到最后模型名确实没错还是报 not supported那大概率是配置文件的加载问题。Codex 在不同工作目录下可能加载不同层级的配置项目级配置会覆盖用户级配置。你可以用codex --config 你的配置文件显式指定再通过/status确认当前实际生效的模型。5.4 常见问题速查表现象最常见原因首选处理方法安装后codex打不开Node 版本过低或权限不足检查node -v更新 Node管理员权限重试Windows 桌面版安装未完成安装过程联网下载组件中断换 CLI 版安装或排查网络后重试auth token is unavailable非交互环境没有登录态和 API Key设置环境变量 API Key或先codex loginmodel not supported模型名不存在或 provider 配置未加载核对服务商真实模型名重启新会话验证cc switch 转发失败本地转发服务未正常启动或端口冲突重启该工具检查端口占用必要时改回官方地址对话无响应网络波动或上下文过长等待几秒后输入/clear重试确认网络正常这个速查表可以打印出来贴墙上了至少对于刚开始用的朋友90% 的问题都逃不出这几类。6. 进阶玩法用配置、AGENTS.md 和脚本把 Codex 调教成老手6.1 config.toml 里的常用键一次讲明白Codex 的核心配置都在~/.codex/config.toml里很多问题其实不是你操作不对而是配置没写对。我常用的几个键如下model gpt-5-codex model_providers [] sandbox_mode workspace-write approval_policy on-requestmodel定义默认模型前面加provider/可以指定供应商sandbox_mode定义沙箱等级可取值大致对应我前面说的三种approval_policy定义审批策略on-request表示在执行需要权限的操作时征求你同意never表示完全不审批这种策略只建议在完全自动化的隔离环境中配合受限沙箱使用。我个人在项目里更推荐用项目级配置也就是把config.toml放在项目的.codex/目录下这样这个项目的人只要走进目录Codex 就会自动应用这套规则。比如一个团队统一规定沙箱等级和审批策略就不需要每个人在自己家目录里手工配一遍。6.2 AGENTS.md让 Codex 自动读懂你的项目规则Codex 有一个很实用的机制当你进入一个项目时它会自动寻找并读取项目根目录下的AGENTS.md文件把这个文件当成项目规范和约束。这是我从“被 Codex 乱改代码”到“Codex 像老同事一样守规矩”的转折点。我的AGENTS.md大概长这样# 项目规范 - 代码语言TypeScript运行环境 Node 20 - 测试命令npm test - 代码风格2 空格缩进字符串用单引号 - 禁止改动migrations 目录、dist 目录、docs/architecture.md - 每次改动后必须运行npm run lint npm test有了这个文件之后Codex 在进行修改之前会先遵守这些约定不会去动禁止的目录改完会自动跑指定的检查命令。这能极大减少无效沟通你不用每次都在对话里重复“不要改 migrations 目录”之类的提醒它自己会读。如果你是在团队里推广 CodexAGENTS.md是必须养成的习惯。它能保证不同人用 Codex 时行为边界都是统一的哪怕你的队友根本不熟悉 Codex 的配置只要在项目里就不会乱来。6.3 把 Codex 接入脚本和 CI自动化要守住底线codex exec最大的魅力在于可以脚本化。比如我有个仓库需要给所有 Python 文件统一加上项目 license 注释人工改几百个文件显然不现实我写个循环就解决了for repo in ./repos/*/; do cd $repo codex exec 给所有 .py 文件头部加上项目 license 注释 cd .. done在 CI 里使用 Codex 也是常见做法。但我要泼一盆冷水自动化和无审查是两回事。让 Codex 在 CI 里自动修代码、自动提交 PR 是合理的但直接让它往生产分支推送那就是给自己埋雷。我的建议是让 Codex 修改代码并创建分支和 PR然后由人来 review 和合并。这种模式既能享受自动化带来的效率又能守住代码质量底线。如果你准备在 CI 里跑codex exec还要注意给任务设置合理的沙箱和审批策略同时把执行日志留存下来。否则一旦出问题你连它当时做了什么都不知道那才是真正的灾难。6.4 从入门到精通我总结的几个使用习惯用 Codex 到现在我最大的体会是它的上限不取决于模型有多聪明而取决于你有多会描述任务和约束。Codex 技术能力足够强但如果你给它的上下文是模糊的它再聪明也只能瞎猜。我自己现在会刻意坚持几件事。一是每次给它派活之前先写出“验收标准”比如“改完必须通过全部测试”“不允许修改某个目录”二是在大改动之前让它先输出计划计划确认了才允许动手三是每周都会留出一点时间用 Codex 处理那些积压的机械化小任务比如清理无用注释、补类型标注、整理 import 顺序这些事虽然小但攒多了也会拖慢节奏。还有一个小技巧是我在踩了很多次坑之后总结的每次进入一个新项目之前先花两分钟看一下项目的AGENTS.md存不存在不存在就自己补一个。别小看这个文件它相当于给 Codex 写了一份“员工手册”有了它Codex 的行为会稳定得多你也不需要在每次对话里重复交代同样的规矩。说到底工具是死的用法是活的。Codex 能不能成为你的得力助手关键还是看你愿不愿意花时间去给它建立规则。把这些规则沉淀下来它的价值才会真正释放出来。