1. 从终端出发为什么我最终把 Codex CLI 留在了工作流里第一次接触 Codex CLI 的时候我的态度其实是怀疑的。命令行里跑一个智能体来写代码听起来像是把 IDE 里已经做得很顺的事情又倒退回终端。但用了大概两周之后我把它固定进了日常流程原因很直接它解决的不是写代码这件事而是在项目上下文里连续做多步操作这件事。举个具体场景。我手上有一个 Node.js 服务需要把原来基于回调的错误处理改成 async/await同时补上单元测试再更新 README 里的接口说明。这三件事单独做都不难但要在同一个上下文里连贯完成中间还要反复读文件、改文件、跑测试、看报错、再改传统方式下我要在编辑器和终端之间来回切换几十次。Codex CLI 的价值就在于它把读—改—跑—看—再改这个循环压缩成了一次对话。这篇是系列第十一篇前面十篇分别覆盖了安装配置、基础对话、文件读写、权限模型、MCP 接入、子智能体、会话恢复等主题。到了这一篇我想聊的是真正把它当成一个编程智能体来用时那些文档里不会写、但每天都会遇到的东西上下文怎么给才有效、任务怎么拆才不翻车、权限怎么设才既安全又不憋屈、跑偏了怎么拉回来。适合读这篇的人已经装好 Codex CLI、能跑通基本对话但总觉得它好像没我想的那么聪明的开发者。如果你还没装建议先看前几篇把环境跑起来否则这篇里的很多细节会缺少参照。提示本篇所有操作基于 Codex CLI 的通用交互模型不同版本在具体命令和参数上可能有差异遇到不一致时以codex --help的实际输出为准。2. 上下文不是越多越好喂给智能体的信息该怎么筛很多人第一次用 Codex CLI 的挫败感来自同一个地方我明明把需求说清楚了它改出来的东西却不对。排查下来十有八九不是模型能力问题而是上下文给错了。2.1 项目根目录决定了它能看见什么Codex CLI 启动时会以当前工作目录作为项目根它读取文件、执行命令、理解项目结构都基于这个根。这意味着你在哪个目录下敲codex直接决定了它的视野范围。我踩过的一个坑在 monorepo 的根目录启动然后让它改packages/api里的一个文件。结果它花了大量时间在扫描无关的包回复里还夹杂着对其他包的猜测。后来我改成先cd packages/api再启动同样的任务响应质量和速度都明显提升。这里的原则很简单智能体的注意力是有限资源项目根就是注意力的边界。任务只涉及一个子包就进到那个子包再启动任务需要跨包才在根目录启动并且在提示里明确告诉它只关注 A 和 B 两个包。2.2 用 AGENTS.md 做常驻上下文每次对话都重复交代项目规范是效率杀手。Codex CLI 支持在项目里放一个AGENTS.md部分版本叫codex.md或类似名字启动时自动读取相当于给智能体的入职手册。我自己的AGENTS.md大概长这样# 项目约定 ## 技术栈 - Node.js 20 TypeScript 5 - 测试用 vitest不用 jest - 包管理用 pnpm ## 代码规范 - 所有导出函数必须有 JSDoc - 错误处理统一用 Result 类型不抛异常 - 禁止使用 any必要时用 unknown 类型守卫 ## 常用命令 - 跑测试pnpm test - 类型检查pnpm typecheck - 格式化pnpm format写这个文件有几个心得。第一只写它猜不到的东西。像用 TypeScript这种从文件扩展名就能看出来的不用写。第二命令要写全因为智能体跑测试时会直接调用写错了它就会一直失败。第三规范要可执行代码要优雅这种话没用禁止 any才有用。2.3 什么时候该主动贴文件什么时候让它自己找Codex CLI 有文件读取能力理论上你可以只说改一下用户登录的逻辑让它自己去找。但实测下来明确指路永远比让它猜更快更准。我的判断标准是这样的场景做法原因改动集中在 1-2 个文件直接在提示里点名文件路径省去搜索开销避免误改改动涉及一个模块说清模块名 关键文件平衡效率和准确度探索性任务这个功能在哪实现的让它自己搜这正是它擅长的跨多个模块的重构先让它列计划再逐个确认避免一次性大改失控举个反例。有次我说优化一下数据库查询性能它扫了一圈把三个不相关的查询都改了其中一个还改错了语义。后来我改成src/repo/order.ts里的listOrders查询在数据量大时很慢看看能不能加索引或改查询结构一次就对了。注意让智能体自己找适合探索不适合精确修改。精确修改时你多打的那几个字省下的是它跑偏后你排查的半小时。3. 任务拆解把帮我做个功能翻译成智能体能执行的步骤智能体最容易翻车的时刻是你给它一个模糊的大任务。比如给项目加个用户认证。这种任务对人来说都需要先设计再动手对智能体来说更是灾难——它会自己脑补一套方案然后一路做到底等你发现方向错了已经改了一堆文件。3.1 先要计划再要执行我现在养成的习惯是任何超过两个文件改动的任务第一步都只要计划不要代码。提示可以这样写我要给 API 加 JWT 认证。先不要改任何文件 给我一个实现计划包括 1. 需要新增哪些文件 2. 需要修改哪些现有文件 3. 每个文件的改动要点 4. 可能的风险点拿到计划后我会先审一遍。这一步的价值在于计划是廉价的代码是昂贵的。计划错了改几行字就行代码错了要回滚一堆文件。而且审计划的过程往往能让我发现自己需求里没说清的地方。确认计划没问题后再让它执行。执行时我倾向于分步确认而不是让它一口气做完。比如先做新增认证中间件跑通测试再做接入到路由再做补测试。3.2 一个真实的任务拆解案例上个月我要给一个 Express 服务加请求限流。原始需求就一句话防止接口被刷。我拆成了四步调研让它读现有的中间件结构告诉我限流中间件应该插在哪一层实现写限流中间件用内存存储先不引入 Redis接入把中间件挂到需要限流的路由上验证写测试模拟高频请求确认限流生效每一步都是一个独立的对话轮次做完一步确认一步。这样做的好处是任何一步出问题影响范围都可控。如果一口气做完中间某步理解错了后面全错。3.3 拆解的粒度怎么把握拆得太细你会变成人肉编译器每行代码都要确认还不如自己写。拆得太粗又会失控。我的经验是一个步骤对应一个可验证的结果。比如中间件写完了能单独跑测试就是一个可验证结果。一个步骤的改动控制在 3-5 个文件以内。超过这个数说明还可以再拆。涉及架构决策的步骤要单独拆出来。比如用内存还是 Redis这种决策不要混在实现步骤里。有个反直觉的点拆解本身可以让智能体帮你做。你可以说这个任务比较大帮我拆成几个可独立验证的步骤它给出的拆解往往比你自己想的更细你可以在此基础上删减。4. 权限与安全怎么设才既放得开又不失控Codex CLI 默认不会随便执行命令或改文件需要你确认。这个设计是对的但用久了会发现每次都确认会让人烦躁烦躁之后就会无脑点同意反而更危险。所以关键是找到适合自己的权限档位。4.1 理解它的权限模型大体上Codex CLI 的操作分几类风险从低到高读文件基本无风险通常默认允许写文件有风险可能覆盖你的改动执行命令风险最高可能删文件、装依赖、改系统状态不同版本对这几类的默认策略不同但核心逻辑一致越危险的操作越需要显式授权。4.2 我的权限配置思路我自己的做法是分场景场景一探索性任务读代码、查实现。这种我基本放开读权限让它自由扫描效率最高。场景二明确的修改任务。写文件我允许但执行命令要确认。因为写文件出问题可以git diff看、可以回滚执行命令出问题可能就来不及了。场景三涉及依赖安装、数据库操作、部署脚本。这种我一律手动执行不让智能体碰。它可以把命令写出来我自己复制到终端跑。这个分法的底层逻辑是可逆的操作放手不可逆的操作收紧。改文件可逆有 git跑rm -rf不可逆跑npm install会改 lock 文件也算半不可逆。4.3 沙箱模式值不值得开部分版本的 Codex CLI 提供沙箱模式让命令在受限环境里执行。我的看法是如果你的任务涉及跑测试、跑构建沙箱值得开如果只是改代码沙箱意义不大。沙箱的代价是有些命令会失败比如需要网络访问的你得判断失败是代码问题还是沙箱限制。我一般会在提示里提前说明当前在沙箱环境不要执行需要网络的命令。提示无论权限怎么设动手前先git commit或git stash。这是最后一道保险比任何权限配置都可靠。5. 当它跑偏时识别、止损、拉回的三段式处理再熟练也会遇到智能体跑偏。跑偏的表现有很多种改错文件、理解错需求、陷入死循环、越改越乱。关键是早识别、快止损、稳拉回。5.1 跑偏的早期信号我总结了几个信号出现任何一个就该警惕它开始改你没提到的文件。这通常意味着它对你的需求理解和你不一样。它反复修改同一个地方。说明它没找到问题根因在试错。它的解释开始变得含糊。比如我优化了一下逻辑但说不清优化了什么。测试从通过变成失败且它说不清原因。一旦出现这些信号立刻打断不要抱着再等等看它能不能自己修好的心态。实测下来它自己修好的概率远低于越改越乱的概率。5.2 止损先回滚再复盘打断之后第一件事是看git diff判断改动范围。如果改动已经乱了直接git checkout .回滚别心疼。回滚之后重新组织提示把这次跑偏的原因考虑进去。我踩过的一个典型坑让它改一个函数它顺手把整个文件的格式都重排了导致 diff 巨大根本看不出真正的逻辑改动。后来我在AGENTS.md里加了一条只改必要的行不要重排格式这类问题就少了很多。5.3 拉回用具体化代替重来回滚之后不要简单重说一遍原话那样大概率还会跑偏。要把提示具体化原来优化这个函数改成calculateTotal函数在 items 为空时返回 NaN改成返回 0只改这一个函数的返回值处理不要动其他逻辑具体化的核心是把要什么和不要什么都说清楚。智能体对不要的响应其实很好只要你明确说了。5.4 一个完整的拉回案例有次我让它给一个 React 组件加 loading 状态。它加完之后顺手把组件的状态管理从 useState 改成了 useReducer还引入了一个新的状态库。这就是典型的过度发挥。我的处理git diff看到它改了 5 个文件其中 3 个是它自作主张引入的git checkout .全部回滚重新提示只改UserList.tsx这一个文件加一个isLoading的 useState在数据请求前后切换它的值不要引入任何新依赖不要改状态管理方式这次一次到位这个案例的教训是智能体倾向于顺便优化你必须明确划定边界。6. 让它真正好用的几个进阶习惯前面讲的都是怎么不出错这一节讲怎么用得爽。这些习惯是我用了几个月之后沉淀下来的每一条都对应一个具体的效率提升。6.1 把常用提示存成模板有些任务你会反复做比如给这个函数补测试review 这个文件的错误处理把这个回调改成 async。这些提示可以存成模板用的时候直接调。我自己的做法是在项目里放一个.codex/prompts/目录每个模板一个文件。虽然 Codex CLI 不一定原生支持模板调用但你可以直接复制粘贴比每次重新组织语言快得多。模板的价值在于把想清楚要什么这件事前置。你状态好的时候写一次好提示状态差的时候直接复用避免在疲惫时给出模糊指令导致跑偏。6.2 用子智能体处理独立子任务Codex CLI 支持子智能体subagent的概念可以派一个独立的智能体去处理某个子任务处理完把结果返回给主对话。这个能力在两种场景下特别有用场景一调研。主任务进行到一半需要查一个 API 的用法。派个子智能体去查主对话不受干扰。场景二并行处理。有两个互不依赖的修改可以各派一个子智能体最后合并。用子智能体的关键是任务要真正独立。如果子任务需要主对话的上下文那就不适合拆出去否则子智能体缺信息结果还得你来补。6.3 会话恢复别让好上下文浪费Codex CLI 的会话可以恢复。这意味着你上午聊到一半的复杂任务下午可以接着聊不用重新交代背景。这个功能在长任务里价值巨大。我的习惯是一个复杂任务开一个会话做完再关。不要在一个会话里塞多个不相关的任务那样上下文会互相污染。也不要在任务做到一半时关掉重开那样前面建立的上下文就浪费了。如果确实需要切换任务我会先让当前会话总结一下当前进度和下一步把总结存下来新会话开始时贴进去相当于手动迁移上下文。6.4 定期 review 它改过的代码这一条听起来像废话但真的有人不看就提交。智能体改的代码必须 review原因不是它写得差而是它写得看起来对。它很擅长写出语法正确、风格一致、但逻辑有微妙错误的代码。我 review 的重点边界条件空数组、null、超长输入它经常漏错误处理它倾向于 happy path异常分支容易糊弄副作用它可能引入了你没预期的状态修改依赖它可能悄悄加了新依赖review 的时候用git diff逐文件看不要只看它总结的我改了什么那个总结可能和实际改动不一致。7. 关于智能体编程这件事我现在的真实看法用了这么久我对 Codex CLI 这类工具的态度从怀疑变成了离不开但保持警惕。它真正改变的是我和代码之间的交互节奏。以前我写代码是想—写—跑—调现在很多时候是描述—审—调。描述需求、审查产出、调整方向这三件事成了主要工作。写代码本身反而变少了。但这不意味着门槛降低了。恰恰相反它对你的判断力要求更高了。因为它产出得快你如果判断力跟不上就会积累一堆看起来对、实际有问题的代码。快是双刃剑快得对是效率快得错是负债。我现在的用法是把智能体当成一个手很快、但需要明确指令的初级同事。给它清晰的任务、明确的边界、可验证的目标它就能发挥很大价值。给它模糊的需求、放任的权限、不检查的信任它就会给你制造麻烦。最后分享一个我最近才想明白的点不要试图让它替你做决策。架构怎么设计、方案怎么选、权衡怎么把握这些还是得你自己来。它擅长的是执行不是判断。把判断留给自己把执行交给它这个分工目前来看是最稳的。