Last updated: 2026-06-30

Source route: reviewed against the current local Codex manual cache on 2026-06-30, especially best practices, prompting, AGENTS.md, and skills sections. Codex product surfaces can change, so interface wording, command names, pricing, and account behavior should be checked against the current app or official docs before being treated as permanent facts.

OnlyPat 建站指南 is an independent site. This article is a personal workflow note, not official OpenAI documentation.

先说结论

第一次用 Codex，不要一上来就让它“帮我做一个完整项目”。

更稳的方式是：选一个足够小、但真实有用的目标，让 Codex 读当前项目规则，给它清楚的边界和验收标准，然后让它完成一轮“读代码、改文件、跑检查、汇报结果”的闭环。

你要追求的不是“AI 一次把所有东西写完”，而是先建立一个可靠节奏：

  1. 说清楚你要什么；
  2. 说清楚哪些地方不能乱动；
  3. 让 Codex 自己找相关文件；
  4. 让它改最小范围；
  5. 让它跑验证；
  6. 最后看 diff 和结果。

只要这个闭环跑通，Codex 就不再只是一个聊天窗口，而会变成你本地项目里的执行型助手。

适合 / 不适合

任务类型 适合交给 Codex 不适合直接交给 Codex
范围 一个页面、一个脚本、一个小 bug、一个验证缺口 一次重写整站或改多个不相关模块
上下文 仓库里有 README、AGENTS、源码和可运行命令 没有目标、没有边界、没有验收标准
风险 本地文件改动、可回滚、可构建、可测试 密钥、支付、线上数据、账号权限和生产操作
判断 让 Codex 查文件、提出计划、执行并验证 让 Codex 代替你决定产品方向或商业承诺
完成标准 diff 清楚，命令跑过，结果可复核 只看回复里的“已完成”，不看证据

30 分钟开工版

  1. 选一个真实但小的目标，例如新增页面、补文档、修一个可复现的小问题。
  2. 写清楚目标、上下文、约束和完成标准，不把产品方向交给 Codex 猜。
  3. 让 Codex 先读 AGENTS.md、README 和相关源码，再决定要改哪里。
  4. 要求它先给短计划，确认不会动旧 URL、密钥、广告脚本或无关模块。
  5. 让它完成最小可验证改动，并运行对应构建、脚本或检查。
  6. 看 staged diff、命令输出和剩余风险，再决定是否继续放大任务。

详细判断

Codex 的价值不是“替你想出所有东西”，而是把一个边界清楚的工程目标推进到可检查状态。它越能读到真实项目规则、源码和验证命令，输出越接近可交付结果。

Codex 适合从哪里开始

最适合新手的第一批任务，不是复杂架构，也不是大规模重构，而是这些具体工作：

  • 给现有网站加一个小页面；
  • 改一个导航、卡片、列表或文案结构；
  • 把散落的说明整理成文档；
  • 根据报错定位一个小问题；
  • 给已有功能补验证命令；
  • 把重复操作沉淀成 AGENTS.md、脚本或技能。

这些任务有两个共同点：范围能看见，结果能验证。

不建议第一次就把下面这些任务直接丢给 Codex：

  • 重写整个项目；
  • 一次改很多业务模块；
  • 让它自己决定产品方向；
  • 让它处理真实密钥、支付、账号权限或线上数据；
  • 没有验收标准地说“优化一下”。

Codex 可以处理复杂任务，但新手应该先从一个小闭环开始。闭环稳定后，再逐步放大任务。

第一步：先选一个小目标

一个好目标应该能在一句话里说清楚。

差的说法：

帮我把网站弄好一点。

更好的说法：

给建站指南新增一个“实战笔记”分类，保留现有指南文章 URL 不变，新增一篇 Codex 使用笔记，并确保构建通过。

这个目标好在三个地方：

  • 范围明确：只动 guide 站；
  • 边界明确：旧 URL 不能变；
  • 验收明确：构建要通过。

你不需要一开始就知道所有技术细节。你只需要把结果和边界说清楚，让 Codex 去读项目结构。

第二步：给 Codex 四块信息

我现在最常用的提示词结构是：

目标：
我想做什么。

上下文：
相关目录、文件、现有行为、你已经知道的背景。

约束：
哪些不要动，哪些规则必须遵守。

完成标准：
什么结果算完成，需要跑什么检查。

例如：

目标：
给 guide.onlypat.com 增加一个“实战笔记”分类，并新增第一篇 Codex 使用文章。

上下文：
项目在 sites/guide，是 Astro 静态站；当前导航有首页、指南、路线图、关于；现有文章数据在 src/data/articles.ts。

约束：
不要改变旧 10 篇建站文章的 URL；不要删除 AdSense 脚本和 ads.txt；新增内容不要写成 OpenAI 官方文档。

完成标准：
新增 /notes/ 列表页和 /notes/codex-from-zero-to-one/ 文章页；sitemap 包含新页面；guide 构建通过；提交并推送。

这个格式的价值是让 Codex 不用猜。它知道从哪里开始，也知道什么时候停。

第三步：让 Codex 先读项目规则

如果项目里有 AGENTS.md，优先让 Codex 读它。

AGENTS.md 的作用不是装饰文档，而是把项目里的长期约定写给代理看，例如：

  • 哪些目录是源码；
  • 哪些目录是生成文件；
  • 改完要跑什么命令；
  • 提交信息怎么写；
  • 哪些东西不能碰；
  • 什么情况算完成。

如果你每次都要重复这些规则，说明它们应该进 AGENTS.md 或项目文档。

新手可以先写一个很短的版本：

# AGENTS.md

## 项目规则

- 修改前先读 README 和相关源码。
- 不提交 .env、token、密码或生成目录。
- 改前端后运行 npm run build。
- 完成时说明改了什么、跑了什么检查、还有什么没验证。

短而准，比长而空更有用。

第四步：先让它计划，再让它动手

当任务跨多个文件时，我一般会先让 Codex 给一个短计划。

不是要它写很长的方案，而是要确认它理解了边界：

  • 会改哪些文件；
  • 会新增哪些页面或数据；
  • 会怎样保持旧行为；
  • 会跑什么验证。

如果计划不对，马上纠正。这个阶段改一句话，比等它改完十个文件再返工便宜得多。

但如果任务已经很清楚，也不用过度仪式化。让它直接开干就行，只要它先读相关文件，不要凭空改。

第五步：让 Codex 做最小可验证改动

好的 Codex 任务不是“尽量多做”，而是“刚好做到可验证”。

比如新增一个实战笔记分类，第一版只需要：

  • 数据结构能区分 guide 和 notes；
  • 导航能进入“实战笔记”；
  • /notes/ 能列出笔记；
  • 文章详情页的面包屑正确；
  • sitemap 收录新页面；
  • 第一篇文章能正常构建。

这已经足够上线第一版。后面如果真的持续写，再考虑标签、归档、搜索、作者页、系列页、RSS 或更复杂的内容系统。

不要为了“以后可能会用”先做一大堆结构。先把真实内容放进去，让真实使用决定下一步。

第六步：一定要让它验证

Codex 最有价值的部分不是生成代码，而是它能在同一轮里读、改、跑命令、看结果。

所以你应该在完成标准里写清楚验证方式：

改完后请运行：
npm run build

如果失败，先修到通过；如果不能运行，说明原因和当前风险。

对不同任务，验证标准可以不同：

任务类型 常见验证
静态站页面 构建通过，关键路由生成
UI 改动 构建通过，本地页面检查，移动端无明显溢出
脚本改动 用样例输入跑一遍
Bug 修复 复现步骤不再失败
文档改动 链接和路径仍然正确

如果没有验证路径，也要让 Codex 明确说出来。不要把“我觉得可以”当成完成。

第七步：看 diff，而不是只看回复

Codex 完成后，不要只读它的总结。

至少看三样东西：

  1. 它到底改了哪些文件；
  2. 有没有动到你没要求的范围；
  3. 验证命令是不是真的跑过。

如果你发现它走偏了，不要只说“不对”。给它更具体的反馈：

这个方向不对。保留 /guides/ 现有逻辑，不要把建站文章移动到 /notes/。
只新增 notes 分类，并让文章详情页根据 section 切换面包屑。

Codex 很适合根据具体反馈继续迭代。模糊批评只会让它继续猜。

第八步：把重复经验沉淀下来

当你发现同一个要求重复出现三次，就不要每次都靠聊天提醒。

可以沉淀到不同层级：

  • 单次任务：写在当前提示词里；
  • 当前仓库长期规则：写进 AGENTS.md；
  • 跨项目个人习惯：写进全局规则或个人技能；
  • 可重复流程：写成脚本、检查命令或 Codex skill。

例如，如果你总是要求“改完必须构建、提交、推送”，这就不该每次手打。它应该成为项目规则。

真正的效率提升不是一次让 Codex 多写几百行，而是让下一次任务少解释一堆背景。

一个可以直接复制的起步提示词

你可以从这个模板开始：

请先读当前项目的 AGENTS.md、README 和跟任务相关的源码，再执行。

目标：
【写你要完成的具体结果】

上下文：
【写相关目录、文件、已有行为、报错或背景】

约束：
【写不要动什么、必须保留什么、风格/技术/安全限制】

完成标准：
【写需要生成什么、验证什么、失败时怎么汇报】

请先给一个很短的实现计划。方向没问题就直接改，改完运行相关检查，并总结改动和验证结果。

第一次用的时候，不要追求完美提示词。你可以边用边改，只要每次都让目标和验收更清楚一点。

用 Codex 做 GEO 时怎么验证

如果你让 Codex 帮你做 GEO，不要把目标写成“24 小时冲到第一”。这不是一个可验证的工程目标，也容易逼着内容变成夸张承诺。

更稳的目标应该写成：

把这 5 篇文章改造成更容易被搜索引擎和 AI 答案系统理解的页面：每篇都有直接答案、判断表、官方来源、最后核验日期、相关工具内链，并且构建通过。

这样 Codex 可以做四类可检查的事：

  1. 读现有文章和页面模板，确认哪些内容已经有“先说结论”和行动清单；
  2. 给文章补 lastFactCheck、sourceLinks、geoQuestions 这类元数据；
  3. 把官方来源和 OnlyPat 的真实经验分开，不把猜测写成事实；
  4. 跑构建、检查 sitemap/robots/canonical/ads.txt 是否仍然在正确站点里。

验证 GEO 也要分层看。当天能验证的是页面结构、构建结果、元数据和链接边界；几周后才能验证的是 Google Search Console 展示、外部 referral、ChatGPT 或 Perplexity 是否提到你的页面。不要把后者伪装成当天已经发生的结果。

OnlyPat 实操备注

OnlyPat 这个仓库里的 Codex 工作流已经固定成一条可复核路径：先读 AGENTS.md、docs/project-map.md、docs/done-definition.md 和目标站点入口，再按 guide、tool、yimoo 或 root 控制面选择验证命令，最后提交并推送中文 commit。

做 GEO 时也按这个方式落地：内容页先补直接答案、判断表、官方来源和下一步；工具页补用途、输入、输出、常见错误和相关指南；Yimoo 保持可抓取摘要和来源边界。这样当天能证明的是页面结构和本地构建，不把 AI 引用或排名说成已经发生。

官方来源

  • OpenAI Developers: Codex: https://developers.openai.com/codex/
  • OpenAI Developers: Codex prompting: https://developers.openai.com/codex/prompting

常见误区

第一个误区，是把 Codex 当搜索引擎。

如果你问的是事实、价格、政策、官方限制，应该要求它查当前官方资料；如果你问的是本地项目怎么改，应该让它读本地文件。两种任务不要混在一起。

第二个误区，是让 Codex 自己决定产品。

它可以帮你拆方案、指出风险、实现代码，但你的目标、用户和取舍要自己负责。尤其是公开网站、付费产品、广告、账号和数据相关的决定，不要让代理自动替你拍板。

第三个误区，是不给完成标准。

没有完成标准，Codex 很容易写出看起来很多、但你很难验收的东西。你越清楚什么叫完成，它越容易交付能用的结果。

第四个误区，是不看验证结果。

“已完成”不等于“已验证”。如果构建没跑、测试没跑、页面没看，就只能说代码已改，不能说行为已经证明。

什么时候应该停下来

如果出现下面情况，先停，不要继续让 Codex 扩大改动：

  • 它开始反复改同一块但问题没有变少；
  • 它要动到密钥、账号、付款或线上数据；
  • 它无法解释验证失败原因；
  • 它的方案需要你接受一个你没理解的架构变化；
  • 你发现任务其实不是代码问题，而是产品方向没定。

停下来不是失败。很多时候，暂停确认边界，比让代理继续猜更快。

下一步

如果你从来没用过 Codex，可以先挑一个 30 分钟内能验收的小任务。

比如：

  • 给你的项目补一个 README；
  • 给个人网站新增一个页面；
  • 把一段重复流程写成脚本；
  • 修一个可以复现的小 bug；
  • 让 Codex 读项目后告诉你应该先补哪些验证。

目标不要大，但一定要真实。真实的小任务跑通之后，你会更清楚 Codex 适合进入你工作流的哪一环。