1. 为什么命令行里的提示词值得单独写一篇攻略很多人第一次接触 Codex CLI会把它当成一个命令行版的聊天窗口——敲一句话等它回一段代码复制粘贴走人。这个用法不能说错但只发挥了它三成不到的能力。真正让 Codex CLI 拉开差距的是它能够直接读取你的项目目录、理解文件之间的依赖关系、在多个文件之间做一致性修改甚至帮你把一次改动拆成可审查的补丁。而驱动这一切的不是鼠标点击是你敲进去的那段提示词。我在过去大半年里把 Codex CLI 用在了三类高频场景上接手陌生仓库时快速摸清结构、定位并修复线上报的 Bug、以及给同事的 PR 做代码审查。这三件事如果纯手工做一个下午就没了用对了提示词往往十几分钟就能拿到一份能直接用的结果。但前提是——你得知道该说什么、不该说什么、按什么顺序说。这篇攻略不讲虚的全部是我自己反复试出来、现在还在用的提示词模板覆盖读项目修 BugReview三条主线。每一条我都会告诉你它为什么这么写、哪些词是必须保留的、哪些坑我踩过。你可以直接复制但更建议你理解背后的逻辑因为项目千差万别死记模板迟早会翻车。先明确一下适用范围本文假设你已经装好了 Codex CLI并且配置好了可用的 API Key能在终端里正常发起对话。如果你连安装都还没搞定那属于另一个话题这里不展开。另外本文提到的所有提示词都是通用的工程实践不依赖某个特定版本2026 年这个时间点上依然适用。提示提示词的效果高度依赖你给的上下文。Codex CLI 能读文件但它不会自动读你脑子里想的那个文件。你指哪儿它看哪儿。2. 读项目让 Codex CLI 先当一次新来的同事2.1 为什么不能一上来就问这个项目是干嘛的我见过太多人打开一个新仓库第一句话就是这个项目是干嘛的。结果 Codex CLI 要么给你一段 README 的复述要么开始瞎猜因为它根本不知道该看哪些文件。一个中等规模的项目动辄几百上千个文件它不可能全读一遍再回答你——就算能token 也烧不起。正确的思路是把读项目拆成几个有明确目标的小任务每个任务都告诉它去看哪些目录、回答什么问题。这就像你带一个新同事熟悉代码库你不会让他自己看吧你会说先看 src 下的入口文件再看 config 目录然后告诉我这个服务启动时都加载了什么。2.2 摸清项目骨架的提示词模板下面这段是我最常用的项目概览提示词直接复制就能用请阅读当前项目的以下内容然后给我一份结构化的项目概览 1. 根目录下的 README、package.json或 pyproject.toml / go.mod 等依赖清单 2. src 或 app 目录下的入口文件 3. 配置文件目录config、.env.example 等 请按以下格式回答 - 项目类型与技术栈语言、框架、主要依赖 - 启动入口在哪个文件启动流程大致经过哪几个模块 - 核心业务逻辑集中在哪些目录 - 有哪些外部依赖数据库、缓存、第三方服务 - 我如果要改一个业务功能最可能动到哪几个文件 不要复述 README 原文用你自己的话总结。如果某个信息在文件里找不到直接说找不到不要猜。这段提示词有几个关键设计点。第一我明确列出了要读的文件范围避免它漫无目的地扫全库。第二我规定了输出格式这样结果可以直接当文档用不用再整理。第三最后那句找不到就说找不到不要猜非常重要——大模型有个坏习惯信息缺失时会编一个看起来合理的答案在代码场景里这是致命的。2.3 追踪一条调用链的提示词概览看完接下来往往是这个接口被调用时到底发生了什么。这时候要用追踪式提示词我想搞清楚从 HTTP 请求进入到返回响应中间经过了哪些函数。 入口是 src/routes/user.js 里的 GET /user/:id 路由。 请沿着调用链往下读列出经过的每一个函数标注它所在的文件和行号 并说明每个函数做了什么。遇到异步调用、中间件、装饰器要特别标出来。 最后给我一张调用顺序的文字列表不要用图。这里我特意强调不要用图因为终端里渲染图形很别扭纯文字列表反而清楚。另外要求标注文件和行号是为了我自己能跳过去核对——永远不要完全信任模型给的路径它偶尔会记错文件名。2.4 读项目阶段最容易踩的三个坑第一个坑是一次性问太多。有人喜欢把项目概览调用链数据库设计部署方式塞进一段提示词结果模型每样都答一点每样都不深。正确做法是一次问一个维度拿到结果再追问。第二个坑是不给文件路径。Codex CLI 虽然能自己找文件但你给个大致方向它的准确率会高很多。比如看看 auth 相关的代码就比看看登录怎么实现的要好因为前者能匹配到目录名。第三个坑是忽略 .gitignore 和生成文件。有些项目里 dist、build、node_modules 一大堆模型如果误读了编译产物给你的结论全是错的。可以在提示词里加一句忽略 dist、build、node_modules 等生成目录。注意读项目类提示词的核心是限定范围规定输出。范围越清楚结果越可用。3. 修 Bug把复现—定位—修复—验证拆成四段对话3.1 为什么修 Bug 不能一句话丢给模型帮我修一下这个 Bug——这是效率最低的提示词没有之一。模型不知道 Bug 长什么样、在什么条件下触发、你期望的正确行为是什么。它只能靠猜猜出来的补丁十有八九不能用甚至会把好的代码改坏。我的做法是把修 Bug 拆成四段独立的对话先让它理解 Bug 现象再让它定位可疑代码然后让它给出修复方案最后让它写验证步骤。每一段都有独立的提示词前一段的输出作为后一段的输入。这样做的好处是每一步你都能介入检查不会等到最后才发现方向错了。3.2 第一段让模型准确复述 Bug 现象我遇到一个 Bug现象如下 [把报错信息、复现步骤、期望行为贴在这里] 请你先不要给修复方案。先做三件事 1. 用你自己的话复述一遍这个 Bug 的现象和触发条件 2. 列出你认为可能相关的 3-5 个方向按可能性排序 3. 针对每个方向告诉我应该去读哪些文件来验证 复述要准确如果我的描述里有矛盾或信息不足的地方直接指出来。这段的关键是先不要给修复方案。一旦模型开始给方案它就会顺着第一个想法往下走不再认真分析。强制它先复述、先列方向等于逼它做一次结构化思考。而且它指出的信息不足往往真的能提醒你补充关键细节。3.3 第二段定位可疑代码拿到方向后进入定位阶段根据上面的分析请重点阅读以下文件 [列出上一步建议的文件] 找出最可能导致这个 Bug 的代码段对每一处可疑代码 - 给出文件路径和行号 - 引用原始代码 - 解释为什么这段代码会导致我描述的现象 - 标注这段代码是最近改过的还是一直如此如果能从注释或结构判断 如果读完这些文件后你发现方向不对直接说并给出新的方向。如果方向不对直接说这句很重要。模型有时候会为了完成任务硬凑一个答案给它一个承认失败的出口反而能得到更诚实的结果。3.4 第三段生成修复补丁定位准了修复就是水到渠成请针对上面定位到的问题给出修复方案。要求 1. 先说明修复思路一两句话讲清楚改什么、为什么这么改 2. 给出完整的修改后代码不要只给 diff 片段我要能直接替换 3. 如果涉及多个文件按文件分别给出 4. 说明这个修改会不会影响其他调用方如果有影响列出需要同步修改的地方 5. 如果有多种修复方式列出你推荐的那种并说明取舍理由要求给完整代码而不是 diff是因为终端里看 diff 容易看漏上下文。要求说明影响面是因为很多 Bug 修复会引入新 Bug提前知道影响范围能帮你判断风险。3.5 第四段写验证步骤最后一段经常被忽略但恰恰最重要请给出验证这个修复是否生效的步骤 1. 需要构造什么样的输入或触发条件 2. 期望看到什么结果 3. 如果修复没生效最可能的原因是什么 4. 有没有边界情况需要额外测试 如果这个 Bug 适合写单元测试请给出一段测试代码。3.6 修 Bug 提示词的参数与边界处理经验在实际操作中有几个细节值得单独说。报错信息要贴全不要只贴最后一行堆栈的前几行往往包含关键调用路径。复现步骤要具体到可执行点一下按钮就报错不如用账号 A 登录后进入订单页点击导出按钮等待 3 秒后报错。还有一个我踩过的坑有些 Bug 是环境相关的比如某个依赖版本不一致。这时候光看代码看不出来需要在提示词里补充我的运行环境是 Node 18依赖版本见 package.json。模型看到版本信息后往往能联想到已知的兼容性问题。另外如果项目里有测试用例可以在定位阶段就让模型先跑一遍相关测试看看哪些失败。Codex CLI 能执行命令这一步能省掉大量手工排查。阶段提示词核心要求常见错误复述现象先分析不给方案描述太模糊模型只能猜定位代码指定文件要求行号不给文件模型乱扫生成补丁要完整代码影响面只要 diff替换时出错验证步骤要可执行边界情况跳过验证改完就提交4. Review让 Codex CLI 当一个不客气的审查者4.1 Review 提示词和修 Bug 提示词的本质区别修 Bug 是我知道有问题帮我找出来并修掉Review 是我不确定有没有问题帮我挑刺。这两个目标决定了提示词写法完全不同。修 Bug 可以聚焦Review 必须发散修 Bug 要收敛到方案Review 要尽量多列问题。很多人 Review 时用的提示词和修 Bug 一样结果模型只挑了一两个明显问题就收工了。正确的 Review 提示词要明确告诉它我要的是全面性宁可多报也不要漏报。4.2 通用代码审查提示词请对以下改动做一次代码审查 [贴出 diff 或指定要审查的文件] 审查维度包括 1. 正确性逻辑有没有漏洞边界条件有没有处理 2. 安全性有没有注入、越权、敏感信息泄露的风险 3. 性能有没有明显的低效写法比如循环里查数据库 4. 可维护性命名是否清晰有没有重复代码注释是否到位 5. 一致性是否符合项目现有的代码风格和架构约定 对每个问题请给出严重程度高/中/低、所在位置、问题描述、修改建议。 如果某个维度没有问题明确说未发现问题不要为了凑数硬编。不要为了凑数硬编这句是必须的。模型在 Review 场景下很容易过度敏感把正常的代码说成有问题。给它一个可以没问题的许可能显著降低误报。4.3 针对特定风险的定向审查通用审查之外我还会根据改动类型做定向审查。比如改的是数据库相关代码这次改动涉及数据库操作请重点检查 1. 有没有 SQL 注入风险参数是否正确转义 2. 事务边界是否合理有没有可能出现部分提交 3. 查询有没有走索引有没有全表扫描 4. 有没有 N1 查询问题 5. 迁移脚本是否可回滚改的是接口相关代码就换成参数校验、错误码、幂等性、限流这几个维度。定向审查比通用审查更容易发现真问题因为模型知道该往哪个方向使劲。4.4 Review 结果怎么用才不浪费模型给的 Review 意见不能照单全收。我的做法是分三档处理高危问题立刻核实并修复中危问题记下来判断是不是这次改动引入的如果是就修不是就另开任务低危问题基本忽略大多是风格偏好。还有一个技巧把模型的 Review 意见反过来喂给它问你刚才提的这几条哪几条其实可以不改为什么。这一步能帮你过滤掉相当一部分过度审查的意见。提示Review 提示词里最好加上只针对本次改动不要审查未改动的代码否则模型可能把整个文件都翻一遍报一堆历史遗留问题。5. 提示词工程在 Codex CLI 场景下的几个底层原则5.1 上下文比措辞重要很多人花大量时间琢磨怎么问才显得专业其实在 Codex CLI 里你给它看哪些文件、贴哪些信息比你怎么措辞重要得多。同样一句帮我看看这段代码你附上文件路径和报错信息效果天差地别。我的经验是提示词里至少一半的内容应该是上下文而不是指令。指令部分简洁明确就行上下文部分要尽量完整。5.2 用约束代替期望希望你能给出高质量的代码——这种话没有任何作用。有效的做法是给出具体约束函数不超过 30 行不要引入新依赖保持现有命名风格。约束是可验证的期望是模糊的模型对约束的响应明显更好。5.3 分步对话优于单次长提示词我试过把读项目、修 Bug、Review 塞进一段超长提示词结果模型顾此失彼。后来改成每段对话只做一件事虽然多敲几次回车但每步结果都更可靠。Codex CLI 支持上下文延续前一步的结论会自动带入下一步不用担心重复交代。5.4 关于 API Key 和模型选择的实际考量Codex CLI 需要配置 API Key 才能工作这是绕不开的一步。不同模型的代码能力差异明显我的建议是读项目和 Review 用推理能力强的模型修 Bug 用响应快的模型。因为读项目和 Review 需要深度理解慢一点没关系修 Bug 往往要反复试快更重要。另外长对话会消耗大量 token读大项目时记得适时用/compact之类的命令压缩上下文或者开新对话重新交代关键信息。这个习惯能帮你省下不少成本。6. 那些我踩过的坑和总结出的手感6.1 模型说已修复不等于真的修复了这是我最想强调的一点。Codex CLI 有时候会自信地说问题已修复但你一看代码它改的是另一个地方或者改完引入了新问题。永远要自己核对补丁尤其是涉及边界条件和错误处理的地方。我的习惯是拿到补丁后先看它改了哪几行再想一遍这几行改了之后原来的调用方还正常吗。6.2 提示词里的不要比要更管用不要猜不要复述原文不要用图不要为了凑数硬编——这些否定指令在实践中的效果出奇地好。因为模型的默认行为往往是尽量多给而代码场景里多给经常等于给错。用否定指令把它的默认行为压一压结果反而更精准。6.3 保留一份自己的提示词库我现在维护着一个纯文本文件里面按场景分类存着几十条提示词用的时候复制出来改几个参数就行。这个习惯是从反复重写提示词的过程中逼出来的——与其每次重新想不如把好用的存下来。你也可以这么做按读项目修 BugReview写测试重构分几个大类每条标注适用场景和注意事项。6.4 别指望一次成功把它当成结对编程最后说个心态问题。Codex CLI 不是许愿机它更像一个反应很快但需要你带路的搭档。第一轮结果不理想是常态追问、纠正、补充上下文来回几轮才能拿到能用的东西。我见过有人试了一次觉得不过如此就放弃了其实再追问两句结果就完全不一样了。把它当成结对编程里的那个搭档你负责判断方向和把关质量它负责快速产出和查漏补缺。这个分工想清楚了提示词自然就知道该怎么写了。