
1. 为什么你的 Codex 总在猜从“改一下登录页”说起刚接触 Codex 的开发者十有八九都踩过同一个坑满心期待地敲下一句“帮我优化一下首页”然后眼睁睁看着它改了七八个文件、装了两个新依赖、顺手把 README 也重写了最后跑起来还报错。你回头一看 diff发现它根本没理解你到底想要什么。这不是 Codex 笨而是任务单写得太潦草。你可以把 Codex 想象成一个刚入职、技术不错但完全不熟悉你项目的新同事。你跟他说“把这个页面做好一点”他脑子里立刻冒出十几个问号好一点是指加载更快还是视觉更整齐只改移动端还是桌面端一起改能不能动接口能不能装新组件怎样才算做完你没给的信息他只能靠猜。猜对了是运气猜错了就是返工。提示词工程在 Codex 场景下本质不是找“万能咒语”而是写一张信息完整的工作任务单。这一课要解决的就是三件事让它少猜信息给够、少改边界划清、做得更准验证方式明确。适合谁适合那些已经能用 Codex 跑通简单任务但经常遇到“做出来的不是我想要的”“只想改一处却动了一堆文件”“同一个要求时好时坏”的开发者。如果你还在纠结怎么把 Codex 接进自己的开发流后面第三节我会给出通过 TaoToken 统一 Key 和 API 通道的完整配置先把通道打通再谈提示词质量。先记住一个判断标准一条好的 Codex 提示词读起来应该像一张清楚的任务单而不是一段抒情描述。任务单里有目标、有背景、有边界、有验收标准、有汇报要求。缺哪一项Codex 就会在哪一项上自由发挥。下面我把这五个要素拆开讲每一项都配可复制的写法和对照示例。2. 好提示词的五个要素目标、上下文、范围、验证、输出这一节是整篇的地基。我把第 1 课里的公式扩展成五个要素目标 上下文 范围与限制 验证方式 输出要求。五个要素不是让你把提示词写成论文而是确保 Codex 拿到任务后不需要回头问你。目标要描述结果而不是只描述动作。“改一下登录页”是动作“让登录页在手机屏幕上不再出现横向滚动并让登录按钮保持完整显示”才是结果。动作给的是方向结果给的是验收线。你写目标时问自己一句做完之后我用什么现象判断它成了把这个现象写进去。上下文回答“为什么要做、现状是什么”。可以包括错误现象、复现步骤、用户场景、相关文件路径、已有设计约定。比如“当前登录页在宽度小于 375px 时出现横向滚动项目已有统一按钮组件请优先复用”。上下文不是越多越好只给完成任务真正需要的信息。塞一堆无关背景反而会淹没重点。范围与限制决定 Codex 能碰什么、不能碰什么。常用限制包括先不要修改文件、只修改必要文件、不要新增第三方依赖、不要改变接口行为、不要删除现有功能、不要处理与当前任务无关的问题。这里有个反直觉的点限制不是越多越安全。如果你把十几条“绝对不能”全堆上去Codex 可能为了遵守限制而卡住或者写出绕来绕去的代码。只写真正重要的边界其他偏好用“优先”“如果可行”来表达。验证方式是很多人漏掉的一环。没有验证任务就只有“看起来完成了”。你可以要求它运行现有测试、跑类型检查、在浏览器里走一遍流程、对照截图检查或者列出手动检查步骤。验证方式越具体你越容易判断结果真假。输出要求规定完成后怎么汇报。不需要长篇报告但至少让它说明改了哪些文件、为什么这样改、执行了什么检查、检查结果如何、还有什么没验证。这五句话能帮你快速判断任务是否真的落地。把五个要素合起来一条完整提示词长这样目标修复登录页在手机屏幕上出现横向滚动的问题并保证登录按钮完整显示。 上下文问题出现在宽度小于 375px 时。项目已有统一按钮组件请优先复用现有写法。 范围与限制只修改登录页和它直接使用的样式不要修改登录接口不要新增依赖不要重构无关组件。 验证完成后运行最相关的检查如果没有自动测试请给出在 375px 和 320px 宽度下的手动验证步骤。 输出列出修改的文件、验证结果和仍未确认的风险。注意这条提示词里没有“你是一位世界顶级工程师”之类的开场。任务清楚本身就足够有效。你可以把这段存成模板每次替换括号里的内容。还有一个关键判断什么时候先让 Codex 分析而不是直接执行。遇到你不熟悉项目、不知道问题出在哪、任务会影响很多模块、涉及删除或迁移、你无法判断方案优劣时先让它只分析。写法是“先不要修改任何文件。请阅读相关代码说明问题原因、可能影响的范围、可选方案和推荐方案。等我确认后再执行。”适合直接执行的是目标明确、范围很小、改错容易恢复、结果容易验证的任务比如修正文案、调整一个确定的样式值。最后强调一条一次只给一个主要目标。“修复登录问题顺便优化首页、升级依赖、补测试、更新 README”这种任务看起来省事其实至少有五个目标任何一步出错都很难定位。拆成四个独立任务每一步都容易检查反而更快。3. 通过 TaoToken 统一 Key 与 API 通道Codex 侧可复制配置提示词写得再好通道不通也白搭。这一节给出通过 TaoToken 统一 Key 和 API 通道的完整配置路径和字段名保持和实际一致你可以直接复制。TaoToken 官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 这个地址不加 UTM 参数。先拿 Key。打开控制台页面 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 在 API Keys 区域创建一个新 Key复制出来。创建入口也可以直接走 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。Key 只显示一次建议先存进密码管理器。接下来是 Codex 侧的配置。Codex 读取的是~/.codex/auth.json和~/.codex/config.toml两个文件。先看auth.json把 Key 填进去{ OPENAI_API_KEY: sk-你的TaoTokenKey, OPENAI_BASE_URL: https://taotoken.net/api }再看config.toml这里要写全三件套Base URL、Key 引用、Model ID。Model ID 按你实际要用的模型填比如gpt-5-codex或你账号下可用的编码模型model gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key OPENAI_API_KEY wire_api chat如果你用的是 Claude Code 或 Cline 这类工具配置思路一致都是把 Base URL 指向https://taotoken.net/apiKey 用同一个Model ID 按工具要求填。Cline 的 MCP 配置里baseUrl和apiKey两个字段对应填上即可。Codex 的auth.json里如果同时存在旧的官方 Key记得替换掉否则会走错通道。配置完成后用一条最小请求验证通道是否打通。在终端里执行curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的TaoTokenKey \ -H Content-Type: application/json \ -d { model: gpt-5-codex, messages: [{role: user, content: 回复 ok}] }返回里能看到choices数组和内容就说明通道正常。如果返回 401说明 Key 没填对或没生效如果报local proxy failed通常是本地网络或代理配置干扰检查一下环境变量里有没有残留的HTTP_PROXY。这一步过了再回到 Codex 里跑提示词才能把问题定位在提示词本身而不是通道。4. 用同一任务验证改动前后差异五个可复制示例光讲理论没用这一节给你五个可复制的提示词示例覆盖理解项目、修 bug、加功能、审查代码、更新文档。每个示例都按五要素写你可以直接拿去改。更重要的是我建议你用同一个任务跑两遍第一遍用模糊写法第二遍用五要素写法对比 Codex 的改动范围和验证结果。示例 1理解陌生项目请阅读当前项目不要修改文件也不要安装依赖。 请用小白能听懂的话说明项目解决什么问题主要目录的作用怎样启动和测试一次请求大致经过哪些模块新手最适合从哪个小任务开始。 如果有无法从代码确认的内容请明确说“不确定”不要猜测。示例 2修复 bug用户点击“保存”后出现错误【粘贴错误信息】。 复现步骤是【填写步骤】。 请先定位根因再做最小修改。不要重构无关代码不要隐藏错误信息。 完成后运行最相关的测试并说明根因、改动文件和验证结果。示例 3增加小功能请给文章列表增加标题搜索。搜索只针对当前已经加载的数据不调用新接口。 输入框放在列表上方并复用项目现有输入框样式。 不要新增依赖不要修改其他筛选功能。 完成后说明怎样手动验证搜索、清空和无结果三种情况。示例 4审查代码请审查当前改动先不要修改文件。 重点检查真实 bug、边界情况、数据丢失风险和缺少的测试。不要把个人风格偏好当成问题。 按严重程度列出发现并给出对应文件和原因如果没有发现明确问题也请直说。示例 5更新文档请对照当前项目检查 README 的安装、启动和测试步骤。只修正与项目实际情况不一致的内容。 不要编造不存在的功能或命令。 完成后列出修改点并说明你实际验证了哪些命令。现在做对照实验。拿“帮我优化首页”这条模糊任务先直接发给 Codex记录它改了哪些文件、装了什么依赖、有没有跑测试。然后清空改动用五要素重写目标让首页在移动端首屏加载时不再出现布局抖动主要内容区域在 375px 宽度下完整显示。 上下文当前首页首屏有一张未设尺寸的图片加载后会把下方内容顶下去。项目已有图片懒加载组件。 范围与限制只修改首页组件和它直接使用的样式不要改接口不要新增依赖不要动其他页面。 验证完成后说明怎样在 375px 宽度下检查布局抖动是否消失。 输出列出修改文件、验证结果和未确认风险。对比两次的 diff你会发现第二遍的改动范围明显收窄而且 Codex 会主动告诉你它验证了什么。这就是“少猜、少改、做得更准”的实际效果。你可以把这个对照实验当成作业的一部分亲手跑一遍比看十遍理论都管用。5. 常见报错排查401、local proxy failed、reading choices、OAuth配置和提示词都到位了还是可能遇到报错。这一节按真实报错逐条排查每条都给出定位思路。401 Unauthorized。最常见的原因是 Key 没填对、Key 已失效或者auth.json里还留着旧 Key。先确认~/.codex/auth.json里的OPENAI_API_KEY是 TaoToken 控制台新建的那把再确认config.toml里env_key指向的变量名和auth.json一致。如果两处不一致Codex 会读到空值。改完重启 Codex 进程环境变量不会热加载。local proxy failed。这个报错通常和本地网络环境有关。检查终端里有没有设置HTTP_PROXY、HTTPS_PROXY、ALL_PROXY这类环境变量有的话先unset掉再试。另外确认base_url写的是https://taotoken.net/api不要多写或少写/v1路径不对也会触发连接失败。reading choices 相关报错。这类报错一般出现在响应解析阶段说明请求发出去了但返回结构不符合预期。先看返回体里有没有error字段常见原因是 Model ID 填错比如填了一个账号下不存在的模型名。把config.toml里的model换成控制台里确认可用的编码模型再重试。如果返回体是空的检查wire_api是否和模型匹配编码模型一般用chat。OAuth 相关报错。如果你之前用官方账号登录过 Codex本地可能残留 OAuth 凭据和 API Key 模式冲突。处理方式是清掉旧的凭据缓存确保auth.json里只有OPENAI_API_KEY和OPENAI_BASE_URL两个字段不要混入 token 字段。清完后重新走一遍第三节的验证请求。排查顺序建议固定下来先跑第三节的 curl 验证通道通道通了再进 CodexCodex 里报错先看是通道问题还是提示词问题。通道问题看本节提示词问题回到第二节检查五要素是否齐全。这样能把问题域缩小不用每次从头猜。6. 把提示词变成习惯从模板到长期编码工作流写到这里你已经有了五要素框架、五个可复制示例、一套通道配置和一份排错清单。剩下的就是把它变成习惯。我的建议是准备一份通用模板每次下任务前花十秒检查五个问题我要的最终结果清楚吗Codex 知道必要背景吗允许和禁止的范围清楚吗完成后有办法验证吗我要求它怎样汇报了吗缺哪项补哪项不用把提示词写成论文。如果你打算长期用 Codex 做编码和 Agent 任务可以考虑 Coding Plan把额度和通道统一管理入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。需要体验模型对话能力可以走 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 配置细节以文档为准。Claude Code 相关接入参考 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaude-code-anthropicutm_campaignrewrite 。最后留一个本课作业把“帮我优化首页”“帮我修复登录问题”“帮我更新项目文档”这三条模糊任务分别改写成包含五要素的提示词。然后选其中一条发给 Codex但先要求它只分析任务是否清楚“先不要执行。请检查这份任务是否已经说明目标、上下文、范围与限制、验证方式和输出要求。如果缺少关键信息只指出缺少什么不要替我猜。”根据反馈补充一次再让它执行。跑完这个流程你对“少猜、少改、做得更准”会有自己的体感。下一课我们讲怎么审查 Codex 的改动看懂文件变化、测试结果和风险。