Codex 真正值得学的，不是“让 AI 写几行代码”，而是把一个明确任务交给它，让它能读仓库、改文件、跑测试、看浏览器、处理 PPT，甚至长时间推进科研或产品原型。

这篇文章按官方用例重新整理成一份可操作指南：你会知道 Codex 适合做什么、怎么开启、怎么写任务、怎么配置模型服务、怎么排错，以及哪些场景不该直接放手让它跑。

1. 先搞清楚：Codex 适合解决什么问题

Codex 不是 ChatGPT 的“代码问答窗口”，它更像一个能进入项目现场的执行型助手。

ChatGPT 更适合解释概念、讨论方案、生成片段；Codex 更适合接管一个有上下文、有文件、有验证命令的任务。

更适合交给 Codex 的任务，通常有几个特点：

• 有项目文件或工作区，不只是问一句“怎么写”
• 能用命令验证，例如 npm test、pnpm build、pytest
• 需要多轮修改，例如 UI 对齐、重构、迁移、修 bug
• 需要读取上下文，例如 issue、日志、接口文档、设计稿
• 能定义完成标准，例如测试通过、页面截图接近、PPT 无溢出

不适合直接丢给 Codex 的任务也很明确：

• 权限边界不清楚的生产环境操作
• 没有测试、没有验收标准的大规模改造
• 涉及敏感数据、账号凭据、内部客户资料的任务
• 一句话说不清结果，但又要求它“自己发挥”的任务

如果你之前觉得 Codex “用不上”，多数时候不是能力问题，而是任务拆得不够像工程任务。

给 Codex 的输入，最好不是一句愿望，而是一份可执行的工作说明。

2. 安装、登录与模型服务配置

使用 Codex 前，先把入口、权限和模型配置确认清楚，否则后面跑复杂任务很容易卡在环境问题上。

常见准备动作可以按这张清单来：

1. 确认你使用的是官方 Codex 入口、Codex App 或支持 Codex 的工作区。
2. 登录账号，并检查当前账号是否具备对应功能权限。
3. 打开要处理的项目目录，确认它能正常构建或运行。
4. 准备好验证命令，例如 npm run build、npm test、pnpm lint。
5. 如果工具支持自定义模型服务，确认 API Key、Base URL、Model 三项配置。

Codex 这类编程助手通常会提供多种登录或接入方式。

如果你使用 ChatGPT 账号登录，重点检查账号权限、工作区授权、文件访问权限。

如果工具支持 API 登录或自定义模型服务，则要重点看接口格式是否兼容，以及模型名称是否写对。

这里用 Codex 相关工具配置为例，本文演示环境选择 iThinkAPI 作为 OpenAI Compatible API 配置样例；当前工具链需要支持这类配置方式。

实际落地时，重点核对 API Key、Base URL 和模型名称，具体可用模型、接口格式、计费与状态均以服务文档为准。

Base URL：https://token.ithinkai.cn/v1
API Key：YOUR_API_KEY
Model：gpt-5.5.claude-opus-4-8, 
gpt-image-2，单图 0.05¥/图，支持 2k,4k，会持续更新最新模型

这里容易踩坑的是，把“能填进去”和“能稳定完成任务”混为一谈。

建议先用一个小任务测试配置：

请读取当前项目的 README，列出启动命令、测试命令和主要目录结构，不要修改文件。

如果这一步都失败，先不要直接让 Codex 改代码。

优先排查：

• API Key 是否复制完整
• Base URL 是否带 /v1
• Model 名称是否与服务文档一致
• 当前工具是否真的支持 OpenAI Compatible API
• 网络、权限、组织空间是否限制了请求

3. Computer Use：让 Codex 操作电脑，但别把权限放太大

Computer Use 的价值不是“让 AI 随便控制电脑”，而是让 Codex 在受控任务里点击、查看、输入和跨应用搬运信息。

它适合处理这类工作：

• 从 Notes 摘取面试记录，整理到飞书或文档
• 查看企业微信消息，提取今天必须完成的事项
• 在浏览器、表格、聊天工具之间复制信息
• 打开音乐、文档、会议记录等低风险应用

使用方式一般是：

1. 在 Codex App 中找到 Computer Use。
2. 确认功能已开启，并理解它会访问哪些应用。
3. 在指令开头使用 @Computer。
4. 如果要限定应用，可以写 @Slack、@Messages 等。
5. 当 Codex 请求权限时，逐项确认，不要一次性放开所有权限。
6. 任务完成后，让它总结做了什么、还有哪些失败点。

示例指令可以这样写：

@Computer 请查看今天的企业微信未读消息，只整理需要我今天处理的事项。
不要回复任何消息，不要删除内容。
完成后按“事项、来源、截止时间、建议动作”输出表格。

这类任务的关键，是提前写清楚“禁止动作”。

比如：

• 不要发送消息
• 不要删除文件
• 不要修改设置
• 不要提交表单
• 不要打开无关应用
• 遇到登录、付款、授权页面立即暂停

运行 Computer Use 时，还要注意几个环境问题：

• Mac 不要自动锁屏，或者确认工具支持锁屏期间运行
• 同一时间不要让两个任务控制同一个应用
• 提前告诉 Codex 默认浏览器、常用文档目录和命名规则
• 涉及账号、客户、财务信息时，优先手动确认
• 任务结束后要求它输出操作日志，方便复盘

如果 Codex 卡在界面识别，可以让它先描述当前屏幕，再继续下一步。

请先描述你现在看到的界面、按钮和可操作区域。
不要点击任何按钮，等我确认后再继续。

4. /goal：让 Codex 持续推进一个长期目标

/goal 适合比一句提示词更复杂、但又没复杂到需要完整项目管理系统的任务。

它解决的是一个常见问题：AI 做一小步就停下来问你，长期任务很难连续推进。

适合使用 /goal 的任务包括：

• 把旧项目迁移到新框架
• 给现有应用做一个可运行原型
• 根据测试集持续优化提示词
• 逐步修复一组相关 bug
• 根据日志定位性能瓶颈并迭代优化

写好 /goal 的核心，是把目标、输入、验证和停止条件讲清楚。

可以套用这个结构：

/goal

目标：
将当前项目的登录页重构为响应式布局，保留现有登录逻辑。

请先阅读：
- README.md
- src/pages/login
- src/components
- package.json

验证方式：
- 运行 pnpm lint
- 运行 pnpm test
- 使用 Playwright 检查桌面和移动端页面

完成标准：
- 登录流程不变
- 移动端无横向滚动
- 桌面端表单居中
- 所有验证命令通过

工作要求：
- 分阶段修改
- 每完成一阶段写入 .logs/login-refactor.md
- 不要重写设计系统
- 不要引入新的 UI 框架

这里最容易出问题的是“目标太虚”。

不要写：

/goal 帮我把项目优化一下。

应该改成：

/goal 找出首页首屏加载慢的原因，优先检查图片、接口请求和打包体积。
每次只改一个方向，改完运行构建命令，并记录指标变化。

如果任务跑偏，可以用三种方式处理：

• 暂停：先停住，让它汇报当前状态
• 继续：确认方向没问题后继续跑
• 清除：目标已经不适合当前阶段，重新定义

长期任务建议让 Codex 维护一个简短日志，而不是只在对话里输出。

推荐放在：

.logs/
  goal-progress.md
  decisions.md
  failed-attempts.md

日志不用长，重点写三类内容：

• 做了什么
• 为什么这么做
• 失败过什么

这能避免它重复走错路，也方便你中途接管。

5. 用 Codex 做 PPT：重点是模板、素材和验收

Codex 做 PPT 的关键不是“生成漂亮幻灯片”，而是把结构化内容、品牌模板和自动检查串起来。

官方提到的两个能力很实用：

• $$slides：用 PptxGenJS 读写 .pptx
• $$imagegen：生成或补充配图

适合交给 Codex 的 PPT 任务包括：

• 给已有汇报模板更新季度数据
• 批量修复间距、错位、字体替换
• 根据文档生成初版演示稿
• 给若干页补充统一风格插图
• 渲染页面截图后检查溢出和排版

提示词可以这样写：

使用 $$slides 和 $$imagegen 编辑当前目录下的 presentation.pptx。

要求：
- 保留现有品牌颜色、字体和版式
- 如果存在 logo.png，请放到每页右下角
- 第 3、5、6 页右侧生成抽象数字艺术风格插图
- 尽量保留文本为可编辑文本
- 简单图表保留为 PowerPoint 原生图表
- 渲染每页为图片并检查文字溢出
- 交付前检查字体替换和元素重叠

如果是周报、月报、季报，建议先让 Codex 生成一份 guidelines.md。

里面写清楚：

• 每期固定结构
• 数据来源
• 哪些图表需要更新
• 哪些页面不能改版式
• 标题、数字、脚注的格式
• 交付前检查项

做 PPT 最常见的翻车点有三个。

第一，原始素材散在不同位置。

解决方式是建一个目录：

deck-workspace/
  presentation.pptx
  logo.png
  data.xlsx
  brand.md
  assets/
  guidelines.md

第二，文字被转成图片，后期无法编辑。

提示词里要明确写“文本尽量保留为文本，图表尽量保留为原生图表”。

第三，没有渲染检查。

一定要让 Codex 输出幻灯片截图，并检查：

• 文字是否溢出
• 字体是否被替换
• 图标是否变形
• 页脚是否遮挡
• 页面比例是否一致

6. 照着截图做网页：让 Playwright 参与验收

如果你有截图、设计说明或参考图，Codex 可以把它们转成项目里的真实页面。

这类任务的关键是：不要让它发明一套新系统，而是复用现有组件、路由、状态管理和样式规范。

可以直接给它这样的提示词：

请以我提供的截图和注释为依据，在当前项目中实现这个界面。

要求：
- 重用现有设计系统组件
- 使用项目已有样式工具，不要另起一套
- 间距、层级、布局和响应行为尽量贴近截图
- 尊重现有路由、状态管理和数据获取方式
- 桌面端和移动端都要适配
- 不明确的细节选择最简单实现，并说明假设

验证：
- 使用 $playwright-interactive 打开页面
- 分别检查桌面端和移动端
- 对照截图调整到接近为止

如果是已有项目，建议先让 Codex 做一次“只读分析”：

请先不要修改文件。
阅读当前项目的组件目录、路由目录和样式方案。
告诉我这个页面应该放在哪里、复用哪些组件、可能影响哪些文件。

确认方案后，再让它动手。

页面实现完成后，验收不要只看“能跑起来”。

至少检查：

• 断点：桌面、平板、手机是否正常
• 交互：按钮、表单、hover、loading 是否完整
• 数据：是否用了假数据，是否破坏现有接口
• 可访问性：表单 label、图片 alt、键盘焦点是否合理
• 构建：lint、test、build 是否通过

如果页面总是和截图差一点，可以让 Codex 输出差异清单：

请对比当前页面与参考截图，只列出视觉差异。
按“间距、字体、颜色、布局、交互状态”分类。
不要先修改，等我确认优先级。

这个过程比让它“一次做到完全一样”更稳。

7. 从零做浏览器游戏：先写计划，再写代码

游戏是检验 Codex 综合能力的好场景，因为它同时涉及玩法、渲染、输入、素材、状态和部署。

不要一上来就写：

帮我做一个小游戏。

先让 Codex 生成 PLAN.md，把游戏拆清楚。

推荐包含这些部分：

• 玩家目标
• 核心循环
• 操作方式
• 胜负条件
• 难度成长
• 视觉风格
• 技术栈
• 部署假设
• 里程碑顺序
• 验证方式

再写一份 AGENTS.md，让 Codex 在项目内按规则工作。

可以参考：

游戏名：星际快递

类型：浏览器休闲游戏

技术栈：
- 前端 Next.js
- 渲染使用 Canvas 或项目内既有方案
- 后端如无必要先不引入
- 数据先使用本地状态

约定：
- 每做完一个功能运行 build / test
- 新功能按 PLAN.md 推进
- 关键决定记录到 .logs/
- 用 Playwright 检查画面和交互
- 生成素材时保存提示到 .prompts/

如果要结合多个工具，可以这样写任务：

Use $playwright-interactive, $imagegen, and $openai-docs to plan and build a browser game in this repo.

Implement PLAN.md, and log your work under `.logs/`.

但要注意，生成大量图片和长时间迭代会带来明显的 Token 消耗。

建议先分阶段：

1. 只做可玩的灰盒版本
2. 再补美术素材
3. 再做音效、动画和菜单
4. 最后处理部署、性能和移动端适配

游戏类任务最容易的问题是“越做越散”。

解决方式是每个里程碑只验收一个目标：

• 第 1 版：能开始、能移动、能失败、能重新开始
• 第 2 版：加入计分和难度变化
• 第 3 版：加入素材和动画
• 第 4 版：适配移动端并优化性能

8. 科研和复杂分析：让 Codex 做执行，不让它替你下结论

Codex 也能处理科研和复杂分析任务，但它更适合作为执行助手，而不是最终判断者。

官方用例里有模型架构实验、药物靶点排序等场景。

这类任务共同点是：用户给方向和判断标准，Codex 负责实现、取证、打分、记录、迭代。

比如模型实验，至少要给它三样东西：

• 一个边界清楚的科学假设
• 一个能跑通的基线模型
• 一套自动评估指标或基准

任务可以这样描述：

/goal

研究目标：
在当前基线模型上测试一种新的几何特征表示方式，观察验证集指标是否改善。

边界：
- 不更换训练数据
- 不改变评估脚本
- 每次只引入一个结构变化
- 所有实验记录到 experiments.md

验证：
- 运行现有训练脚本
- 使用现有评估脚本
- 对比 baseline、实验设置、指标和失败原因

停止条件：
- 完成 5 组有效实验
- 或连续 3 次实验指标无改善
- 或训练脚本无法稳定运行

如果是文献、数据库、证据评分类任务，则要明确评分规则。

例如：

请对候选靶点进行证据整理。
每条证据按 1-5 分评分，并说明理由。

评分维度：
- 遗传学证据
- 临床相关性
- 文献支持
- 表达数据
- 安全性风险

输出：
- 排名表
- 证据摘要
- 不确定性说明
- 需要人工复核的数据源

这里必须保留人工复核。

尤其是科研、医疗、金融、法律等场景，Codex 可以帮你跑流程，但不能替代专业判断。

如果它给出结论，建议继续追问：

• 证据来自哪里
• 有没有相反证据
• 数据是否过期
• 评分是否可复现
• 哪些结论需要人工确认

9. 常见报错与避坑清单

Codex 用不好，通常不是模型“不聪明”，而是任务环境没有准备好。

遇到问题可以按下面顺序排查。

任务一直问下一步怎么办

原因通常是目标太大、验收标准太模糊。

处理方式：

• 改成 /goal
• 写清楚完成标准
• 指定先读哪些文件
• 指定验证命令
• 要求它每阶段记录进度

改了很多文件但跑不起来

先让 Codex 停止继续改。

再输入：

请不要继续新增功能。
只阅读最近修改的文件和报错日志。
列出导致构建失败的最小原因，并给出最小修复方案。

不要让它在错误状态下继续扩展功能。

UI 和截图不一致

不要一句话要求“再像一点”。

改成分项对比：

请按间距、字体、颜色、布局、响应式行为列出差异。
每次只修复最影响观感的 3 个问题。
修复后用 Playwright 重新截图对比。

Token 消耗过快

长任务里最耗的是重复读上下文、反复失败和无边界生成。

建议：

• 先让它做只读分析
• 每次只处理一个目录
• 大任务写进 PLAN.md
• 失败记录写进 .logs/failed-attempts.md
• 图片生成、浏览器验证、长时间实验分阶段开启

权限和安全边界不清

所有会影响外部系统的动作，都应默认需要确认。

例如：

• 发送消息
• 删除文件
• 提交代码
• 修改生产配置
• 操作客户数据
• 调用付费资源
• 访问内部系统

可以在提示词里加一句：

涉及外部提交、删除、发送、授权、付费或生产环境变更时，必须先暂停并请求确认。

10. 总结：把 Codex 当成可验收的执行者

Codex 的正确打开方式，不是把它当聊天框，而是把它当一个需要目标、上下文、权限和验收标准的执行者。

如果你只问“帮我写代码”，它能给你片段。

如果你给它仓库、计划、验证命令、截图、日志和停止条件，它就能持续推进更接近真实工作的任务。

更实用的使用顺序是：

1. 先让它只读分析项目。
2. 再让它写 PLAN.md。
3. 小范围改动后立刻验证。
4. 长任务使用 /goal。
5. UI 任务接入 Playwright。
6. PPT、图片、科研等任务明确产物和复核方式。
7. 涉及权限、账号、生产环境时人工确认。

OpenAI 官方用例可以在开发者文档继续查看：

developers.openai.com/codex/use-cases

真正能把 Codex 用起来的人，往往不是提示词写得最花的人，而是最会定义任务、控制边界、设计验收的人。