适合解决什么问题
适合那些需要“理解上下文再行动”的任务：改代码、修 bug、读项目、生成网页、写脚本、整理文档、分析数据、跑测试、做审查、拆产品方案。
第一部分
什么是 Codex
Codex 是面向真实工作的编码代理。它不只是回答问题，还可以在你授权的项目或工作区里读文件、运行命令、修改文件、整理结果，并把工作过程留在同一个线程里。
和普通聊天 AI 的区别
普通聊天 AI 多数停在建议层；Codex 可以进入工作区，基于文件和命令结果持续执行。你看到的不是一段回答，而是一组可检查的改动、日志和交付文件。
它如何理解项目
它会读取项目结构、配置文件、测试脚本、报错日志、README、设计文档、打开的文件和你提供的任务目标，再把这些信息纳入当前线程。
桌面应用
适合本地项目、长线程、自动化、图形化审查和日常工作管理。官方 quickstart 推荐新用户可从 App 开始。
编辑器扩展
适合你正在写代码时让 Codex 读当前文件、理解选区、直接修改项目。Agent 模式默认可读文件、运行命令、写改动。
命令行
适合工程师在终端里发任务、查看状态、运行审查、管理配置和自动化流程。
云端线程
适合把任务委托到远程环境、并行处理、从 GitHub 仓库创建 PR，或让 Codex 在后台跑较长任务。
维度
普通聊天 AI
Codex
上下文
主要依赖你粘贴内容
可以读取项目文件、命令输出、历史线程和相关工具上下文
执行
给建议或代码片段
能创建、修改、运行、检查并汇报结果
交付
你自己复制粘贴
直接在工作区生成文件、补测试、跑验证
安全边界
通常不接触本地文件
通过本地、云端、沙盒、批准策略和 Git 检查点控制权限
适合谁用
- 开发者
- 创业者
- 产品经理
- 设计师
- 内容创作者
- 运营人员
- 数据分析师
- 一人公司
Codex 在沙箱运行是什么意思
沙箱可以理解为给 Codex 划出的“可行动范围”。Codex 不是天然拥有整台电脑的无限权限， 它会根据当前配置决定能读哪里、能写哪里、能不能联网、运行命令前是否要先问你。
- 只读：适合先理解项目，Codex 可以检查文件，但不能直接改。
- 工作区写入：适合日常开发，Codex 可以在当前项目内读写并运行常规命令。
- 完全访问：限制最少，只适合你明确信任任务和环境时使用。
新手可以记住一句话：先让 Codex 在安全范围里读项目、给方案、等你批准，再让它动手。
什么是中转站 API
中转站 API 通常指放在你的应用和上游模型 API 之间的一层转发服务。你的程序请求中转站， 中转站再把请求转给模型服务，并把结果返回给你。
- 可能用途：统一接口地址、隐藏上游密钥、做模型路由、统计用量、限流或备用切换。
- 常见形式：把客户端里的 API base URL 改成中转站地址，再使用中转站提供的 key。
- 注意事项：它不是 OpenAI 官方 API。生产使用前要确认服务商信誉、隐私政策、计费规则、模型来源和合规风险。
如果请求里包含用户隐私、商业数据或源代码，先确认中转站是否可信；不确定时，不要把敏感数据发给陌生中转服务。
第二部分
如何开始第一次对话
第一次对话不要追求完美。先告诉 Codex 你要达成什么、它可以看哪里、有什么限制、什么结果算完成。它会边读上下文边推进。
目标
一句话说清你要什么结果。比如“修复登录页移动端按钮溢出”。
背景
告诉它业务、用户、技术栈、相关文件、错误日志、已尝试过的方法。
限制
说明不要碰哪些文件、不要新增依赖、保持现有风格、先计划后执行。
完成标准
告诉它“跑过哪些测试”“页面没有溢出”“生成文件放在哪里”。
不好的提示词
帮我优化一下这个项目。问题：目标模糊、范围太大、没有上下文、没有完成标准，Codex 只能猜。
更好的提示词
请检查这个 Next.js 项目的首页性能。
范围：只看 app/page.tsx、components/ 和图片资源。
目标：找出影响首屏加载的 3 个主要原因。
先给我检查结果和修改方案，不要直接改。
如果我批准，再做最小改动，并跑 lint/build 验证。优点：目标、范围、执行权限、验证方式都清楚。
一个关键习惯
当你不确定怎么拆任务时，可以让 Codex 先采访你：“请先问我最多 5 个问题，把我的模糊想法整理成可执行计划，再等我确认。” 这比一上来让它做完整项目更可靠。
第三部分
Codex 可以帮你做什么
下面按真实场景理解，而不是按“功能按钮”理解。你给它任务、上下文和完成标准，它就能帮你把一段工作推进到可检查状态。
写代码、改代码、重构
新增页面、组件、API、脚本，或把重复逻辑抽成函数。适合明确目标、影响范围和代码风格。
例：把设置页拆成可复用表单组件，并保持现有 UI。找 bug、修 bug、解释报错
让它先复现失败，再定位最小文件集合，最后做高置信度修复。
例：根据堆栈日志修复支付回调偶发 500。写测试、跑测试
补单元测试、集成测试、端到端测试，并分析失败原因。
例：给订单状态机补 8 个边界测试。阅读大型项目
总结架构、关键流程、模块依赖、启动方式、风险点和改动入口。
例：说明这个 monorepo 的前后端数据流。生成网页、App、工具
从需求生成可打开的网页、内部工具、表单、看板、小型应用。
例：做一个本地可预览的定价计算器。处理数据和文档
整理 CSV、表格、报告、README、PRD、技术方案、教程和变更说明。
例：把用户反馈表归类并生成优先级清单。处理图片、音视频
生成素材、转码、压缩、抽取音频、转写会议、做字幕或内容摘要。
例：把访谈视频转成文章初稿和短视频脚本。自动化日常工作
写脚本、定时检查、生成周报、扫描 CI、整理发布说明。
例：每天汇总昨天的提交和待办风险。市场、运营、销售、客服
不是只写文案，而是把产品上下文、用户画像和数据一起纳入任务。
例：从功能更新生成邮件、X 帖、FAQ 和客服话术。把想法变成 MVP
从想法澄清、竞品调研、功能拆解、原型页面、上线清单到迭代计划。
例：把“AI 简历助手”拆成首周可上线版本。第四部分
Codex 的典型工作方式
最可靠的使用方式不是“说一句，等奇迹”，而是让 Codex 按工程流程前进：理解、计划、实现、验证、修复、交付。
需求
你说目标、背景、范围、约束和完成标准。
方案
Codex 读文件、识别风险、提出执行计划。
实现
在限定范围内修改文件，保持项目风格。
测试
运行 lint、类型检查、单测、构建或手动验证。
修复
根据失败日志做最小改动，直到验证通过。
交付
汇报改动、证据、风险、文件位置和后续建议。
你应该怎么审查它的结果
- 先看最终摘要：它改了什么、为什么改、验证了什么。
- 再看 diff：有没有改到无关文件、有没有新增不必要依赖。
- 再看验证证据：测试命令是否真的运行，失败是否被解释清楚。
- 最后给第二轮指令：保留好的部分，指出要调整的地方。
第五部分
一人公司如何使用 Codex
一人公司最大的瓶颈不是想法，而是连续执行能力。Codex 的价值在于把“一个人的脑子”扩展成一套可重复的工作流。
技术合伙人
帮你评估技术路线、搭 MVP、修 bug、补测试、做部署检查。
产品助理
把模糊想法变成 PRD、用户故事、验收标准和迭代路线。
运营助理
整理用户反馈、生成活动方案、做增长实验和复盘表。
内容团队
从产品更新生成教程、邮件、社媒帖、FAQ、视频脚本。
数据分析师
清洗数据、找趋势、输出决策建议和可视化报告。
自动化工程师
把重复任务脚本化、技能化、自动化，减少手工操作。
一人公司的闭环
一个可执行的闭环是：想法澄清、调研验证、产品拆解、原型实现、页面和文案、发布准备、数据回收、下一轮迭代。 你不需要一次把所有事情做完，只要让 Codex 每次推进一个明确节点。
想法
调研
产品
MVP
页面
发布
数据
迭代
示例：从一句想法到第一版产品
让 Codex 采访你，把想法整理成目标用户、核心痛点、MVP 功能和不做清单。
让 Codex 做轻量竞品和定位分析，形成一页产品方案。
让 Codex 生成原型网页、后端脚本、数据结构和基础测试。
让 Codex 写发布文案、FAQ、用户反馈表和第一轮迭代清单。
第六部分
高质量提示词模板
直接复制使用。模板的关键不是华丽，而是把目标、上下文、范围、权限和完成标准写清楚。
让 Codex 理解项目
请先阅读这个项目并建立上下文。
请输出：
1. 项目用途和主要用户
2. 技术栈、目录结构、关键入口文件
3. 启动、测试、构建、部署命令
4. 重要约定和潜在风险
5. 如果我要继续开发，你建议我先看哪些文件
限制：
- 先不要修改文件
- 不确定的地方请标注“已确认/推测/需要我补充”让 Codex 制定计划
我想完成这个目标：[写清目标]。
请你先不要执行，先做计划：
1. 需要阅读哪些文件或资料
2. 你会分成哪几个步骤
3. 每一步会产生什么交付
4. 可能的风险和需要我确认的问题
5. 验证方式是什么
请把计划写得具体，等我批准后再执行。让 Codex 修改代码
请帮我修改代码，实现：[具体功能或修复目标]。
范围：
- 优先查看：[相关文件/目录]
- 尽量不要改：[不相关文件/模块]
- 不新增依赖，除非你先说明原因并等我确认
要求：
- 遵循现有代码风格
- 做最小必要改动
- 如果有测试体系，请补充或更新测试
- 完成后运行相关检查，并汇报命令和结果让 Codex 做网页
请制作一个可以本地打开的网页，主题是：[主题]。
内容要求：
- 受众：[新手/客户/团队/投资人]
- 必须包含：[列出章节]
- 内容要具体可操作，不要空泛宣传
设计要求：
- 清爽、现代、专业
- 桌面端和移动端都要好看
- 有导航、章节、示例、表格或步骤卡片
- 如有按钮或交互，必须可用
交付：
- 创建完整网页文件
- 告诉我文件位置和打开方式
- 检查排版、移动端、文字溢出和交互可用性让 Codex 检查 bug
请帮我定位并修复这个 bug。
现象：
[粘贴错误信息、截图描述、复现步骤]
请按这个方法执行：
1. 先尝试复现或从日志定位
2. 找出最小相关文件集合
3. 说明根因和修复方案
4. 等我批准后再改代码
5. 修复后补充测试或复现检查
限制：
- 不要做无关重构
- 不要把猜测当结论
- 如果无法复现，请说明还缺什么信息让 Codex 写测试
请为这个功能补测试：[功能名称或文件]。
请先阅读现有测试风格，然后补充：
1. 正常路径
2. 边界情况
3. 错误情况
4. 回归测试，覆盖之前出现的问题
要求：
- 使用项目已有测试框架
- 不为了测试而改业务逻辑，除非发现可测试性问题并先汇报
- 完成后运行相关测试并解释结果一人公司任务拆解
我现在是一个人做这个项目：[项目/想法]。
请你像一人公司的运营合伙人一样帮我拆解：
1. 目标用户和核心痛点
2. 最小可行产品版本
3. 本周必须完成的 5 件事
4. 可以暂时不做的事情
5. 需要 Codex 执行的技术任务
6. 需要我本人决策或确认的事情
7. 发布前检查清单
请用可执行任务列表输出，而不是泛泛建议。执行前先汇报方案
请先检查并制定执行方案，不要直接修改。
你需要汇报：
1. 你检查了哪些文件或证据
2. 你发现的问题
3. 你建议的修复方案
4. 影响范围和风险
5. 验证方式
等我明确批准后，再按方案执行。第七部分
使用 Codex 的最佳实践
这些习惯会显著提高结果稳定性，尤其是当任务涉及已有代码、业务规则、多人协作或高成本操作时。
把任务说清楚
用“目标、上下文、限制、完成标准”四段式描述。复杂任务先让 Codex 采访你。
限制范围
说明优先看哪些文件、不要碰哪些模块、是否允许新增依赖、是否允许重构。
先检查再修改
高风险任务要求先读、先汇报方案，得到批准再执行。
保护已有代码
用 Git 检查点、diff 审查、测试验证。不要让多个线程同时改同一批文件。
要求每一步汇报
对长任务要求它在关键节点报告：已读什么、准备改什么、验证了什么。
给出可验证结果
让 Codex 运行测试、构建、lint、页面截图或手动检查，并说明无法验证的部分。
保存交付文件
明确输出位置、文件名、格式和打开方式。比如“放到 outputs 目录”。
处理不确定信息
要求它区分“已确认、推测、需要你补充”。这能减少看起来很自信的误判。
权限和安全边界
Codex 可以通过沙盒和批准策略控制行动范围。新手建议从默认权限开始；更强权限只给可信项目和明确任务。 官方文档把常见沙盒分为只读、工作区写入和完全访问，把批准策略分为需要批准、按请求批准和不暂停批准。
第八部分
常见错误和避坑
需求太模糊
不要说“优化一下”，要说优化哪个指标、哪个页面、怎样算完成。
一次要求太多
把大任务拆成阶段。先做理解和计划，再做实现和验证。
没有提供上下文
给相关文件、错误日志、业务背景、期望行为和反例。
不看结果直接相信
始终看 diff、运行结果和风险说明。Codex 是搭档，不是免审机制。
没有要求测试
只改代码不验证，等于把风险推迟到上线后。
没有要求方案先行
涉及删除、迁移、大重构、依赖升级时，先让它报告方案。
混淆咨询和执行
想讨论就说“只分析不要改”；想执行就说“请实现并验证”。
长期规则只放在提示词里
反复使用的规则应该沉淀到 AGENTS.md、技能或自动化里。
第九部分
交付前检查清单
每次让 Codex 做完工作，都可以用这张清单做最后验收。
最短可用公式
“请先理解上下文，制定方案，等我批准后做最小改动，完成后运行验证并汇报结果。” 这句话能覆盖大多数高质量协作场景。