Codex App 从 0 到 1 完整入门教程

第一次打开 Codex App，很多人会被它的界面吓住：左侧有导航，中间是对话，右侧会出现网页、图片、文档、来源、代码变化和预览结果。它看起来不像一个简单聊天框，而更像一个 AI 工作现场。

你可以把它理解成装在电脑里的 AI Agent 工作台。普通聊天工具主要回答问题，Codex App 更强调直接帮你做事：读文件、改代码、打开浏览器、生成文档、检查结果、连接外部服务，甚至定时继续任务。

新手最重要的不是马上搞懂每个高级名词，而是先知道它的基本工作方式：你提出目标，它读取上下文，必要时请求权限，然后执行、展示过程和交付结果。

普通 ChatGPT 更适合问问题、写文案、解释概念、生成单次内容。Codex App 也能做这些，但它真正突出的地方是能接触你的本地工作环境，并围绕文件、项目和工具执行任务。

如果你只是想问一个概念，普通对话就够了。如果你希望它读取一个文件夹、修改项目代码、运行构建命令、打开本地页面验证效果，就应该使用 Codex App 的项目能力。

云端 Codex 则更像远程运行的 Agent。它适合不依赖你电脑持续开机的任务。本地 Codex App 的优势是贴近你的桌面、文件和当前工作流，适合边看边改、边验证边推进。

安装时建议只从 OpenAI 官方入口下载，避免从不明网盘或二次打包站点获取。安装完成后，用你的 ChatGPT 或 OpenAI 账号登录即可。

第一次进入后，不要急着改设置。先开一个普通对话，问一个低风险问题，比如让它解释 Codex App 的界面，感受它和普通聊天的差别。

等你熟悉基本对话后，再进入项目模式。项目模式会涉及本地文件和命令执行，所以要比普通聊天更注意权限、路径和任务边界。

左侧导航栏负责找入口：新对话、历史搜索、插件、自动化、项目、设置等内容通常都从这里进入。你可以把它当成 Codex 的功能目录。

中间对话区是你和 Codex 真正协作的地方。你在这里描述任务、补充限制、确认风险、查看它的回答和下一步动作。

右侧结果区会在需要时出现，用来展示网页预览、文件结果、引用来源、图片、文档、代码变化或浏览器画面。它让 Codex 不只是说，而是把工作现场摆给你看。

普通对话适合不需要读取本地项目的任务，比如解释概念、写一段文案、整理清单、生成学习计划、分析一个问题、把复杂内容改写成更容易理解的版本。

如果你只是想问“Codex App 和 ChatGPT 有什么区别”，没有必要进入项目。普通对话更轻，风险也更低。

判断标准很简单：如果任务不需要访问你电脑里的文件，也不需要运行命令，就先用普通对话。

项目对话适合围绕一个具体文件夹工作，例如 Next.js 网站、脚本项目、文档目录、表格资料或代码仓库。进入项目后，Codex 可以读取相关文件并提出更贴近实际结构的修改方案。

典型任务包括修复页面、补充文章、调整组件、排查构建错误、整理 README、生成测试、检查代码变更和准备提交说明。

进入项目后，提示词要更具体。不要只说“优化一下”，而要说清楚目标、范围、限制和验收方式，比如“只修改文章数据和详情页，不新增依赖，最后运行构建”。

新对话用于开始一个干净任务，适合你不想沿用旧上下文的时候。搜索用于找回历史对话、之前的任务或相关信息。

插件入口用于扩展 Codex 能力，例如浏览器、文档、演示文稿、表格、GitHub、Gmail、Drive、Slack 等。自动化入口用于让 Codex 按时间或条件重复执行任务。

项目入口用于绑定本地目录。设置入口用于管理模型、权限、账户、工具、外观和其他行为偏好。新手前期最常用的是新对话、项目和设置。

插件可以理解成给 Codex 安装能力包。比如浏览器插件让它能操作页面，表格插件让它更擅长处理 Excel，演示文稿插件让它能创建和检查 PPT。

连接器更偏外部账号连接，例如 GitHub、Gmail、Google Drive、Slack。它解决的是“让 Codex 能访问某个外部服务”的问题。

技能是一套本地工作流说明书，告诉 Codex 在某类任务里应该按什么流程做。MCP 是一种把外部工具或服务接入 Codex 的方式。新手不用一开始就深挖 MCP，先把插件和项目工作流用熟更重要。

自动化适合重复检查、定时总结、延后继续和周期性监控。比如每天早上总结资料、每周检查项目状态、半小时后继续当前线程。

它不适合模糊的大任务。你不能只说“以后帮我变厉害”，而应该说清楚时间、范围和输出，比如“每周一上午检查这个项目的构建状态并总结失败原因”。

新手使用自动化时，要先从低风险的信息型任务开始，不要一上来就让它定期改文件或执行高风险操作。

Codex App 能做事，所以权限比普通聊天更重要。它可能需要读取文件、写文件、运行命令、访问网络、打开浏览器或连接外部账号。

当它请求权限时，你要看三件事：它要访问什么，为什么任务需要这个权限，有没有更低风险的做法。

如果你不确定，就让 Codex 先解释风险。一个好习惯是直接问：“这个权限会让你做什么？为什么需要？有没有替代方案？”

设置里通常会有账号、模型、权限、插件、自动化、外观或开发者相关选项。新手不用一次性全看完，先关注账户状态、模型选择和权限策略。

模型决定回答质量、速度和成本倾向。权限决定 Codex 能不能直接执行某些动作。插件决定它能接触哪些额外工具。

如果你发现 Codex 不改文件、不跑命令或不能访问某个资源，不要急着说它不会用，先检查当前项目、权限和插件是否满足任务要求。

让 Codex 处理本地项目时，目录边界非常关键。你应该明确告诉它当前项目在哪，哪些文件可以改，哪些文件不要动。

如果工作区里已经有别人或你自己改过的文件，也要提醒它不要随便回退。好的任务描述会减少误改和返工。

例如你可以说：“只修改 src/lib/site-data.ts 和 src/app/docs/[slug]/page.tsx，不要调整样式，不要提交 Git。”这类边界比一句“帮我加文章”可靠得多。

写代码任务要给目标、范围、约束和验收。目标说明你要什么结果，范围说明能改哪些文件，约束说明不要做什么，验收说明怎样算完成。

比如：“把这篇文章添加到 Learn Codex 的教程目录，保持现有数据结构，文章详情页末尾显示出处，最后运行 npm run build。”这就是可执行任务。

不要只说“做得好一点”。这种指令太虚，Codex 会自己猜方向，结果可能和你真正想要的不一致。

Codex App 可以结合浏览器检查页面、打开本地预览、查看布局是否正常、测试按钮和表单。对前端项目来说，这比只看代码更可靠。

当你让它修改页面后，最好要求它启动本地服务，然后用浏览器打开目标 URL 检查。这样能发现构建通过但页面不好看的问题。

如果页面有交互，比如搜索、筛选、弹窗、上传或表单提交，也应该要求它实际点击或输入测试，而不是只凭代码判断。

Codex App 不只面向代码。配合对应插件，它可以生成图片、整理文档、制作演示文稿、处理表格和导出结果。

这类任务同样需要清楚说明目标和格式。比如做 PPT 时要说页数、受众、风格、每页重点；做表格时要说字段、公式、汇总方式和输出文件。

新手容易犯的错是只说“做个 PPT”。更好的说法是：“做一个 8 页的产品介绍 PPT，面向非技术用户，第一页讲痛点，最后一页给行动建议。”

Codex 可以查看 Git 状态、解释 diff、整理提交信息、创建分支、提交和推送。但这些动作会影响真实仓库，不能随便让它自动完成。

新手前期建议先让它只做只读操作，比如查看状态、解释改动、总结风险。等你确认没有问题，再让它提交。

如果要提交，最好明确提交范围和提交信息。不要让它把无关文件一起打包进去，也不要让它回退你没要求回退的改动。

第一步，描述目标和范围。第二步，让 Codex 先读项目结构。第三步，确认实现路径。第四步，允许它修改文件。第五步，运行构建或测试。第六步，查看页面或 diff。

这个流程看起来慢，但其实能省很多返工。尤其是已有项目里，先读结构比直接写代码更重要。

你可以把它当成固定模板：先看、再改、再验、再汇报。长期这样用，Codex 的结果会稳定很多。

第一个坑是把普通聊天和项目任务混在一起。问概念用普通对话，改文件用项目。第二个坑是不给范围，导致 Codex 改得太多。

第三个坑是不看权限请求。只要涉及文件、命令、网络和外部账号，都应该知道它为什么要这样做。

第四个坑是不验证。看起来完成了，不代表真的能跑。前端要看页面，后端要跑接口或测试，文档要打开检查排版。

你可以先让 Codex 做一个低风险任务：解释一个项目结构、整理 README、给已有页面补一段文案、把一篇文章加入数据列表。

然后再尝试中等任务：新增一个页面、修复一个样式问题、把重复逻辑抽成组件、为一个函数补测试。

最后再尝试高风险任务：重构核心模块、迁移数据结构、改认证和支付逻辑。越高风险，越要分步骤、看 diff、跑测试、人工复核。

不要只看 Codex 说“完成了”。你要看它有没有说明改了哪些文件、为什么这样改、验证做到了哪一步、还有什么风险。

可靠的结果通常有明确文件路径、构建或测试结论、页面访问地址、剩余风险说明。含糊的“已优化”价值很低。

你也可以让它自检：“请检查这次修改有没有遗漏、有没有可能影响其他页面、有没有需要补的验证。”

免费额度适合体验和轻量任务，但如果你频繁让 Codex 读项目、改代码、跑验证，付费额度会更稳定。

模型选择不要只看强不强，还要看任务类型。简单文案和小改动可以用更快的模型，复杂排错、架构分析和跨文件修改适合更强的模型。

如果一个任务很重要，不要为了省一点时间选择太轻的配置。真正浪费时间的通常不是模型慢，而是结果不稳导致返工。

第一天，只用普通对话，问概念、写文案、整理思路。第二天，打开一个低风险项目，让 Codex 读结构并解释每个目录做什么。

第三天，让它做一个小修改，比如补一篇文章、改一个按钮文案、修一个样式细节。第四天，学习看 diff、跑构建、确认页面。

等这些动作熟了，再去尝试插件、自动化、Git 和 MCP。不要第一天就把所有高级功能打开，先建立稳定的使用手感更重要。

Codex App 的价值不是让你少思考，而是把你的目标变成可执行流程。你越能说清楚目标、边界和验收，它越能稳定完成任务。

把它当成一个会执行的协作者，而不是一个万能按钮。你负责判断方向和风险，它负责读上下文、动手实现和反馈结果。

新手不用一开始就追求全能。先从一个真实小任务开始，让 Codex 帮你完整走完一次“说明目标、修改文件、运行验证、查看结果”的闭环，这比看十篇概念介绍更有用。