第一次使用 Codex：从下载安装到跑通第一个项目

一篇面向初学者的 OpenAI Codex 入门实战教程

资料依据：OpenAI Developers Codex 官方文档（Quickstart / App / IDE Extension / CLI 等页面，访问日期：2026-05-30）

目录

1. 引言：Codex 入门真正要学什么

2. 一、Codex 到底是什么：从“代码问答”到“工程智能体”

3. 二、安装前准备：不要急着点下载，先准备好这 5 件事

4. 三、三种安装入口怎么选：App、IDE Extension、CLI

5. 四、路线 A：使用 Codex App 完成第一次启动

6. 五、路线 B：使用 CLI 安装和启动

7. 六、路线 C：在 IDE 中使用 Codex Extension

8. 七、正式实战：创建 Hello Codex 项目

9. 八、第一条提示词：让 Codex 先理解，再动手

10. 九、运行项目：从文件生成到浏览器预览

11. 十、审查改动：不要让“能跑”替代“看得懂”

12. 十一、Git 检查点：AI 编程时代的安全带

13. 十二、提示词模板：让 Codex 更稳定的写法

14. 十三、审批模式和权限：新手要学会说“不”

15. 十四、常见问题：从安装失败到项目跑不起来

16. 十五、从第一个项目迁移到真实项目

17. 十六、第一次使用后的三个进阶练习

18. 十七、可直接复制的 Codex 入门提示词库

19. 十八、把 Codex 当作“工程流程”而不是“灵感工具”

20. 十九、30 分钟上手计划：把教程变成一次真实练习

21. 二十、给初学者的安全边界清单

22. 结语：第一次使用 Codex，最重要的是建立“可控感”

引言：Codex 入门真正要学什么

如果你第一次打开 Codex，很容易把它理解成“一个更会写代码的聊天窗口”。但真正上手之后，你会发现它更像一个坐在你电脑旁边的 AI 编程搭档：它可以阅读项目目录，理解已有代码，提出计划，修改文件，运行命令，解释报错，并把改动以 diff 的方式交给你审查。换句话说，Codex 的关键不是“帮你补一段代码”，而是把“理解项目—制定计划—改动文件—运行验证—人工审查—提交版本”这条工程链路连接起来。

这篇文章面向第一次使用 Codex 的读者，尤其适合已经会一点点命令行、用过 VS Code 或 Cursor、想用 AI 加速个人网站、小程序、iOS App、前端页面、教学工具开发的人。我们不追求一上来就做复杂项目，而是用一个最小可运行的 Hello Codex 静态网页，完整走一遍下载安装到跑通项目的全过程。你会看到三种入口：桌面 App、IDE 插件和 CLI。为了降低入门阻力，正文会以官方推荐的桌面 App 和 IDE 方式为主，同时给出 CLI 备选路径。

这篇教程的目标很具体：第一，知道自己应该安装哪个入口；第二，知道第一次启动时如何登录、如何选择项目文件夹；第三，知道第一条提示词不要怎么写、应该怎么写；第四，亲手跑通一个本地网页项目；第五，学会用 Git 检查点保护自己，避免 AI 一次性改坏项目。读完后，你不一定已经成为“AI 全栈工程师”，但应该可以安全地把 Codex 放进你的日常开发流程里。

一、Codex 到底是什么：从“代码问答”到“工程智能体”

从官方文档的定位看，Codex 并不只是一个代码生成模型，而是一个可以在你的开发环境里工作的 coding agent。它可以读取、修改、运行代码；在 IDE 中，它能结合打开的文件、选中的代码和项目上下文给出更相关的回答；在 CLI 中，它能从终端启动交互式会话；在桌面 App 中，它可以把多个任务线程、Git 改动审查、worktree 和本地操作组织到一个更适合工程工作的界面里。

这和过去“把需求复制给 ChatGPT，再把代码复制回编辑器”的方式有本质区别。传统方式的问题是上下文经常断裂：你问的是一个函数，但真实 bug 可能在另一个文件；你让模型写页面，但它不知道项目已有样式、依赖和命令；模型给出代码后，还需要你手工粘贴、保存、运行、报错、再复制错误信息。Codex 则尝试把这些步骤变成一条连续的工作流：它先检查项目，再提出计划；需要改文件时会生成可审查的 diff；需要运行命令时会请求或遵循权限设置；最后你可以决定接受、修改或回滚。

对初学者来说，最重要的不是“Codex 能不能一次写完整个项目”，而是理解它的工作边界。Codex 很强，但仍然需要你给出清楚的目标、限制和验收标准。你要像给一名新人同事安排任务一样描述：当前项目是什么，允许改哪些文件，不允许做什么，完成后怎样判断通过。这样它的能力才会被纳入可控流程，而不是变成一次不可预测的“魔法改代码”。

二、安装前准备：不要急着点下载，先准备好这 5 件事

第一次使用 Codex 前，建议先做一个很小的准备清单。第一，确认你的系统环境。Codex App 官方页面显示桌面应用可用于 macOS 和 Windows；CLI 则支持 macOS、Windows 和 Linux。Mac 用户需要区分 Apple Silicon 和 Intel 版本，如果你是 M 系列芯片，选择 Apple Silicon；如果是老款 Intel Mac，选择 Intel 版本。Windows 用户可以根据官方入口安装桌面应用或使用 PowerShell 方式安装 CLI。

第二，准备一个可以登录的账号。官方 Quickstart 说明，可以用 ChatGPT 账号登录，也可以用 OpenAI API key 登录；但如果使用 API key 登录，部分功能例如 cloud threads 可能不可用。第一次入门建议优先使用 ChatGPT 账号登录，因为路径更简单，界面也更容易理解。

第三，安装一个编辑器。你可以只用 Codex App 完成本文的最小项目，但如果已经在用 VS Code、Cursor、Windsurf 或 JetBrains 系列 IDE，安装 Codex IDE Extension 会更自然。IDE 方式的好处是：你能同时看到文件、终端、预览和 Codex 对话，不用在多个窗口之间来回复制。

第四，准备一个空文件夹。千万不要第一次就把自己的正式网站、App 或论文项目交给 Codex。最好在桌面新建 hello-codex 文件夹，先练习一次完整流程。等你熟悉“计划—改动—运行—审查—提交”之后，再把它引入真实项目。

第五，准备 Git。Git 不是高级工程师的专属工具，而是 AI 编程时代的安全带。只要 Codex 会改文件，你就应该有办法比较改动、回滚改动、保存检查点。即使你不懂复杂分支，也至少要学会 git init、git status、git diff、git add 和 git commit。

三、三种安装入口怎么选：App、IDE Extension、CLI

官方文档把 Codex 的使用入口分成多个方向：桌面 App、IDE Extension、CLI 和 Cloud。第一次上手时，不建议同时全装、同时学习。你可以按自己的习惯选择一条主路径。

如果你希望“少配置、先跑通”，选择 Codex App。它像一个专门为 Codex 设计的工作台，适合新手理解项目线程、任务列表、审查面板和本地运行。你打开 App，登录账号，选择项目文件夹，确认 Local 模式，然后发送第一条消息，就可以开始让 Codex 阅读项目、解释项目或创建最小应用。

如果你已经每天使用 VS Code、Cursor、Windsurf 或 JetBrains，选择 IDE Extension。它把 Codex 放进编辑器侧栏，适合边看代码边提问。比如你可以选中一个函数，让 Codex 解释；也可以在提示词里引用 @example.tsx，让它基于某个文件新建页面。IDE 扩展也提供模型切换、reasoning effort 调整和审批模式选择。官方文档说明，默认 Agent 模式下，Codex 可以读取文件、修改文件并在工作目录内运行命令；如果你只想讨论方案，可以切换到 Chat；如果你想给它更大权限，也有 Agent Full Access，但新手不建议一开始就用。

如果你喜欢命令行，选择 CLI。CLI 的优势是轻量、直接、适合脚本化。官方 CLI 页面给出的 macOS/Linux 安装命令是 curl 安装脚本，安装后在终端输入 codex 即可启动交互式终端界面。它能检查仓库、修改文件、运行命令，也能用 codex "Explain this codebase to me" 这种方式直接带初始提示启动。

本文建议的顺序是：第一天先用 App 或 IDE Extension 跑通一个小项目；第二天再安装 CLI，把它作为终端助手；第三天以后再尝试 Cloud 或更复杂的自动化。不要把工具选择复杂化，先建立可控的工程习惯更重要。

入口选择对照表

这个表不是绝对答案。真正的判断标准是：你是否能看懂 Codex 的计划，是否能审查它的改动，是否能在出错时回滚。

图 1｜Codex 的四种入口与第一次使用建议

四、路线 A：使用 Codex App 完成第一次启动

如果你选择 Codex App，整体流程可以概括为四步：下载、登录、选项目、发消息。第一步，打开官方 Codex Quickstart 或 App 页面，下载对应系统的安装包。Mac 用户注意芯片类型，Apple Silicon 和 Intel 不要选错；Windows 用户按官方入口安装即可。安装后第一次启动可能会要求系统授权，例如访问项目文件夹、打开终端或使用本地工具。原则是：只给当前项目需要的权限，不要在不了解的情况下授予全局权限。

第二步，打开 Codex 并登录。你可以用 ChatGPT 账号登录，也可以使用 OpenAI API key。第一次入门推荐 ChatGPT 账号，因为它和 Codex 功能的整体体验更一致。如果登录失败，先检查网络环境、账号状态和浏览器弹窗拦截，必要时重启 App。

第三步，选择项目文件夹。这里非常关键。Codex 会在你选择的目录内理解和修改文件，所以这个目录就是它的工作范围。第一次练习请选择一个空文件夹，例如 ~/Desktop/hello-codex。不要选择整个桌面、整个用户目录或包含隐私资料的大文件夹。选择项目后，App 中可能会显示过去使用过的项目，如果你以前用过 App、CLI 或 IDE Extension，也可能看到历史项目。

第四步，发送第一条消息。官方 Quickstart 给出的示例包括“Tell me about this project”“Build a classic Snake game in this repo”“Find and fix bugs in my codebase with minimal, high-confidence changes”。第一次建议从最保守的“Tell me about this project”开始。原因是：让 Codex 先读项目、说理解，再让它动手，能降低误操作概率。对于空项目，可以这样写：

图 2｜第一次启动 Codex 的基础流程

五、路线 B：使用 CLI 安装和启动

CLI 适合喜欢终端的人，也适合把 Codex 放进日常开发脚本。官方 CLI 页面说明，Codex CLI 是可以在本地终端运行的 OpenAI 编程智能体，它可以读取、修改和运行所选目录中的代码，并且是开源的、使用 Rust 构建。macOS 或 Linux 用户可以使用官方安装命令：

# macOS / Linux：安装 Codex CLI          curl -fsSL https://chatgpt.com/codex/install.sh | sh          # 启动 Codex 交互式终端界面          codex          # 也可以带着第一条指令启动          codex "Explain this codebase to me"          

六、路线 C：在 IDE 中使用 Codex Extension

如果你平时写代码主要在 VS Code、Cursor、Windsurf 或 JetBrains IDE 中完成，那么 IDE Extension 是最自然的入口。它的核心优势是上下文更贴近真实开发：你打开了哪些文件、选中了哪些代码、当前项目结构是什么，Codex 都能围绕这些信息工作。官方 IDE 文档说明，Codex 可以帮助你构建、修 bug、理解陌生代码，并且能在 IDE 中并排使用或把任务委托到 Codex Cloud。

安装方式通常是打开编辑器扩展市场，搜索 Codex，安装后在侧边栏找到 Codex 图标。如果使用 VS Code，官方文档提到 Codex 默认会出现在右侧边栏；如果没有看到，重启编辑器或检查侧边栏折叠区域。Cursor 等 VS Code 分支可能因为 Activity Bar 布局不同需要手动固定或调整位置。

登录后，先不要急着让它改代码。你可以先打开 README.md 或一个主要文件，然后让 Codex 回答：“请根据我当前打开的文件，解释这个项目的入口、运行命令和主要结构。”如果回答合理，再让它执行小范围任务。IDE Extension 的审批模式很重要：Chat 更像讨论模式；Agent 可以读写工作目录并运行命令；Agent Full Access 权限更大，新手应谨慎。建议第一次练习保持默认 Agent 或更保守的 Chat/Agent 组合，不要直接让它访问网络和系统外部目录。

IDE 中还有一个很实用的能力：引用文件。比如你可以写“请参考 @README.md，创建 index.html、style.css 和 app.js”。这样比“帮我写个网页”更具体，因为 Codex 知道项目说明在哪里，也能围绕指定文件改动。

七、正式实战：创建 Hello Codex 项目

接下来我们跑通第一个项目。这个项目不用 React、Vue 或后端框架，只做一个静态网页。选择静态网页有三个好处：第一，依赖少，失败点少；第二，浏览器即可验证；第三，Codex 的改动容易审查。等你熟悉流程后，再把同样方法迁移到个人网站、微信小程序、iOS App 或后端服务。

首先，新建文件夹。你可以在 Finder/资源管理器中创建，也可以使用命令行：

mkdir hello-codex          cd hello-codex          git init          cat > README.md <<'EOF'          # Hello Codex          这是我的第一个 Codex 练习项目。          目标：创建一个无框架静态网页，包含 index.html、style.css、app.js。          验收：可以在本地浏览器打开，输入名字后点击按钮显示欢迎语。          限制：不安装依赖，不访问网络，不修改项目外文件。          EOF          

图 3｜Hello Codex 项目的最小文件结构与预览目标

八、第一条提示词：让 Codex 先理解，再动手

打开 Codex App 或 IDE Extension，选择 hello-codex 文件夹。第一条提示词不要写“帮我做一个炫酷网站”，因为这会让任务边界太大。建议先让它阅读项目：

“请先阅读当前项目，不要修改任何文件。请告诉我：1. 这个项目目前有哪些文件；2. 你认为它要做什么；3. 如果要把它变成一个可运行的静态网页，你建议下一步怎么做。”

这条提示词的价值在于建立共同上下文。即使项目很空，Codex 也会告诉你它看到了 README.md，并给出下一步计划。接着你再发送第二条提示词，让它真正创建文件：

“请在当前项目中创建一个无框架的静态网页。要求：1. 新建 index.html、style.css、app.js；2. 页面标题为 Hello Codex；3. 有一个输入框、一个按钮和一个结果区域；4. 点击按钮后，根据输入内容显示一段欢迎语；5. 样式简洁，有现代科技感；6. 不要访问网络，不要安装依赖；7. 完成后告诉我如何本地预览。”

这条提示词包含目标、范围、限制和验收标准。你会发现，Codex 更容易给出稳定结果。它通常会先说明计划，然后创建或修改文件。此时不要只看最终回答，一定要看它的 diff。检查它是否真的只创建了三个文件，是否没有改 README 之外的内容，是否没有加入外部 CDN 或未知脚本。

九、运行项目：从文件生成到浏览器预览

当 Codex 创建完文件后，下一步是运行本地预览。静态网页可以直接双击 index.html 打开，但更推荐使用本地 HTTP 服务，因为这更接近真实开发。你可以让 Codex 运行命令，也可以自己运行。最简单的方式是使用 Python 自带的 http.server：

# 在 hello-codex 项目根目录运行          python3 -m http.server 5173          # 浏览器打开          http://localhost:5173          

十、审查改动：不要让“能跑”替代“看得懂”

项目跑起来后，很多新手会立刻兴奋地进入下一个需求。但真正安全的做法是先审查。审查分三层。第一层看文件列表：Codex 是否只创建了你允许的文件？有没有多余依赖、缓存文件、奇怪脚本？第二层看代码逻辑：HTML 结构是否清楚，CSS 是否可读，JS 是否只做必要交互？第三层看运行结果：按钮是否真的能响应，输入为空时是否有提示，页面刷新后是否仍能正常打开。

如果使用 IDE，可以直接查看 diff；如果使用命令行，可以输入：

git status          git diff          # 如果确认改动合理          git add .          git commit -m "Create hello codex static site"          

十一、Git 检查点：AI 编程时代的安全带

官方 Quickstart 在 IDE 路线中提醒，Codex 可以修改代码库，因此建议在每个任务前后创建 Git checkpoints，方便需要时回滚。这个建议非常重要。AI 编程不是“把风险交给 AI”，而是“让 AI 的每次行动都能被版本系统记录”。

第一次项目可以这样做。项目开始前初始化 Git；Codex 修改前提交一次 checkpoint；Codex 修改后看 diff；确认能跑再提交。这样即使某一步不满意，也可以用 git checkout 或 git restore 回到上一状态。完整流程如下：

# 任务前：创建检查点          git add .          git commit -m "checkpoint before codex task"          # Codex 修改后：审查          git status          git diff          # 不满意：恢复某个文件          git restore app.js          # 满意：提交结果          git add .          git commit -m "implement hello codex interaction"          

图 5｜Git 检查点与审批流程

十二、提示词模板：让 Codex 更稳定的写法

Codex 的能力很强，但它对任务边界非常敏感。糟糕提示词通常有三个问题：目标模糊、范围过大、没有验收标准。比如“帮我优化项目”就很危险，因为它可能改样式、改架构、改依赖、改命名，最后你不知道它为什么改。更好的方式是把任务拆成小块：先解释项目，再创建文件；先修一个 bug，再补测试；先给计划，再请求执行。

可以把提示词写成六段：背景、目标、范围、限制、验收、输出格式。示例：

“背景：这是一个无框架静态网页项目。目标：增加一个任务清单功能。范围：只允许修改 index.html、style.css、app.js。限制：不要安装依赖，不要访问网络，不要删除现有功能。验收：可以新增任务、勾选完成、删除任务，刷新页面后不要求保存。输出：先列出计划，等我确认后再修改文件；完成后说明改了哪些文件和如何测试。”

对于真实项目，还可以补充项目规则，例如：“保持现有目录结构”“遵循当前代码风格”“不要重构无关文件”“如果发现不确定点先提问”。你越像工程负责人，Codex 越像可靠的协作伙伴。

图 5｜给 Codex 的六要素提示词模板

十三、审批模式和权限：新手要学会说“不”

IDE Extension 文档提到 Codex 的不同审批模式。默认 Agent 模式下，它能在工作目录内读文件、改文件和运行命令，但访问工作目录之外或网络通常需要批准。Agent Full Access 可以给它更高自主权，但第一次使用不建议开启。原因很简单：你还不知道哪些命令安全，哪些改动合理，哪些行为会影响系统环境。

审批时要看三个问题。第一，这个命令是不是当前任务必须的？创建静态网页不需要 npm install，也不需要访问外网。第二，这个命令会不会修改系统或全局环境？比如 sudo、rm -rf、全局安装依赖、修改 shell 配置，都要特别谨慎。第三，这个命令的输出是否可验证？比如 python3 -m http.server 是临时本地服务，风险很低；而下载并执行远程脚本就需要确认来源和必要性。

新手可以给 Codex 加一条固定规则：“在运行任何会修改文件、安装依赖、访问网络或影响系统的命令前，先解释命令作用，并等待我批准。”这条规则能把很多风险挡在执行前。等你熟悉项目后，再逐步放宽权限。

十四、常见问题：从安装失败到项目跑不起来

问题一：安装后打不开。先确认系统是否匹配，Mac 是否选对 Apple Silicon 或 Intel；Windows 是否通过官方入口安装；必要时重启系统或重新下载安装包。

问题二：登录失败。检查网络、浏览器弹窗、账号状态。如果用 API key 登录，确认 key 是否有效。需要注意的是，官方 Quickstart 提到 API key 登录可能缺少部分 cloud threads 等能力，因此第一次体验最好优先用 ChatGPT 账号。

问题三：Codex 看不到项目。通常是选错目录或权限不足。重新选择 hello-codex 文件夹，并确认里面有 README.md。如果在 IDE 中使用，确保打开的是项目根目录，而不是单个文件。

问题四：Codex 一直在解释，不创建文件。可能是你使用了 Chat 模式，或者提示词没有明确允许它修改文件。把模式切到 Agent，并写清“请创建 index.html、style.css、app.js”。

问题五：运行命令报错。不要只说“报错了”，而是把完整错误信息交给 Codex。更好的写法是：“这是运行 python3 -m http.server 5173 的报错，请先解释原因，再给出最小修复方案，不要修改无关文件。”

问题六：改动太多。立刻停止，查看 git diff。你可以要求：“请撤销除 index.html、style.css、app.js 之外的所有改动，并解释为什么产生了额外修改。”如果已经提交了 checkpoint，回滚会非常轻松。

新增配图：图 6｜Codex 入门常见问题排查地图

十五、从第一个项目迁移到真实项目

当 Hello Codex 跑通后，不要马上把全部真实项目交给 Codex 大改。正确迁移方式是“先读、后问、再小改”。第一步，让 Codex 解释真实项目结构：入口在哪里，依赖是什么，运行命令是什么，测试命令是什么。第二步，让它只做文档类任务，例如补 README、整理运行步骤、生成项目架构说明。第三步，让它修一个低风险 bug，比如按钮文案、样式间距、表单校验。第四步，再让它做有测试保护的功能。

对于个人网站，可以让 Codex 先分析页面结构，再新增一个独立文章页；对于微信小程序，可以让它先解释 pages、components、app.json 的关系，再修改一个页面；对于 iOS App，可以让它先阅读 SwiftUI 视图和数据流，再修一个 UI 问题。无论项目是什么，原则都一样：范围越小，成功率越高；验收越清楚，结果越稳定；版本控制越及时，风险越可控。

随着使用深入，你可以考虑把项目规则写入 AGENTS.md 或项目说明文件中，例如代码风格、测试命令、禁止事项、常用目录、发布流程。这样每次 Codex 进入项目时，都能先读取这些规则，而不是每次都靠你重复说明。长期看，AI 编程的核心竞争力不是会不会输入一句提示词，而是能不能建立一套让 AI 稳定协作的工程系统。

图 7｜从第一个项目到日常工作流的路线图

十六、第一次使用后的三个进阶练习

当你跑通 Hello Codex 之后，可以继续做三个小练习。它们不复杂，但能帮助你从“会启动工具”过渡到“会设计任务”。第一个练习是改造页面视觉。你可以要求 Codex 在不改变 HTML 结构的前提下，只修改 style.css，让页面更像一个科技风落地页。这个练习训练的是“限制改动范围”。同样是美化页面，如果你不限制文件，它可能会同时改 HTML、JS 和 CSS；如果你明确“只改 style.css”，你就能更容易审查。

第二个练习是增加一个可测试的小功能。例如给 Hello Codex 增加“清空输入”“随机欢迎语”“复制结果到剪贴板”等功能。提示词可以写：“只新增一个功能，不要重构已有逻辑，完成后列出手动测试步骤。”这会训练你把需求拆小。真实项目的大部分任务也应该这样拆：不要让 Codex 一次完成“用户系统、支付系统、后台管理、发布上线”，而要先做一个页面、一个按钮、一个接口、一个测试。

第三个练习是让 Codex 自我审查。你可以在它完成页面后继续问：“请像代码审查者一样检查你刚才的改动，找出可能的可读性、可维护性和边界情况问题，只给建议，不要修改文件。”这一步很有价值。很多时候，AI 生成的第一版代码能跑，但并不一定足够稳。让它切换到 reviewer 角色，可以帮助你看到更多细节，例如输入为空、按钮重复点击、变量命名、样式兼容性、无障碍标签等。

这三个练习形成一个很好的入门闭环：第一步只改样式，第二步只加功能，第三步只做审查。每一步都可以通过 Git diff 看清楚边界。等你习惯这种节奏后，再进入真实项目时就不会被“AI 一次性改太多”吓到，也不会被“看起来能跑”迷惑。

十七、可直接复制的 Codex 入门提示词库

下面这组提示词可以直接复制到 Codex 中使用。第一类是项目理解提示词：“请先阅读当前项目，不要修改任何文件。请用新人能看懂的方式解释项目结构、入口文件、运行命令、主要依赖和潜在风险。如果你不确定，请标注不确定。”这条适合任何新项目，尤其适合接手陌生代码。

第二类是小范围修改提示词：“请只修改当前任务相关文件。任务是：____。范围限制：只允许修改 ____。禁止事项：不要重构无关代码，不要删除现有功能，不要安装新依赖。完成后请列出改动文件、测试方法和可能风险。”这条适合修 bug、改样式、补交互、增加小功能。

第三类是报错排查提示词：“这是我运行命令后的完整报错：____。请先解释报错原因，再给出最小修复方案。不要直接大规模修改项目；如果需要改文件，请先列出要改的文件和理由。”这条能避免 Codex 为了修一个错误而改出更多错误。

第四类是代码审查提示词：“请审查当前改动，不要修改文件。请从正确性、可读性、可维护性、安全性、边界情况五个角度列出问题。每个问题给出严重程度、原因和建议修复方式。”这条适合在提交前使用，可以让你在 git commit 之前多一层检查。

第五类是学习型提示词：“请把你刚才的改动当作教学案例解释给初学者。请说明每个文件的作用、关键代码的含义、为什么这样写，以及如果我要扩展下一步功能应该从哪里开始。”这条适合把 Codex 变成学习教练，而不只是代码生成器。

第六类是回滚与收敛提示词：“当前改动超过了我的预期。请不要继续新增功能。请根据 git diff 总结你改了什么，并给出两种方案：A. 保留最小必要改动；B. 回退到任务前状态。先不要执行，等我确认。”这条在 AI 改动失控时很有用。你不需要慌张，只要把任务拉回审查流程。

十八、把 Codex 当作“工程流程”而不是“灵感工具”

很多人第一次使用 AI 编程工具时，会把重点放在“它能不能写出漂亮页面”或“它能不能一次生成完整 App”。这种期待可以理解，但并不是最稳的使用方式。真正能长期提升效率的，是把 Codex 放进工程流程。工程流程的核心不是灵感，而是可重复、可验证、可追踪。

可重复，意味着你应该把常用做法沉淀下来。比如每次开始新任务都先创建 checkpoint；每次让 Codex 修改前都要求它列计划；每次修改后都看 diff；每次提交前都让它自我审查。这样你不是靠感觉使用 Codex，而是用一套固定动作降低风险。

可验证，意味着每个任务都要有验收标准。创建网页的验收是浏览器能打开、按钮能点击；修 bug 的验收是复现步骤不再出错；补文档的验收是新人能按 README 跑起来；重构的验收是测试仍然通过、行为不变。如果没有验收标准，Codex 可能给出看似完整但难以判断好坏的结果。

可追踪，意味着每一次改动都应该被版本控制记录。不要让 Codex 连续改十几轮后才第一次保存。更好的做法是小步提交：完成页面结构提交一次，完成样式提交一次，完成交互提交一次，完成文档提交一次。这样未来出现问题，你可以很快定位是哪一步引入的。

当你把 Codex 当作工程流程，它的价值会变得更稳定。它不再只是“帮我想一个点子”，而是可以长期承担重复劳动：解释旧代码、生成初稿、补测试、整理文档、根据报错定位问题、做提交前审查。你仍然是项目负责人，Codex 是执行力很强的协作者。这个关系一旦建立，AI 编程就会从新鲜感变成真正的生产力。

十九、30 分钟上手计划：把教程变成一次真实练习

为了让第一次使用不只停留在阅读层面，你可以按 30 分钟计划实际演练一遍。前 5 分钟只做准备：新建 hello-codex 文件夹，初始化 Git，写一个 README.md，把项目目标、限制和验收标准写进去。这个动作看起来简单，却能让 Codex 明确知道你要做什么，也能让你从一开始就进入工程状态。

第 6 到 10 分钟安装或打开入口。如果你使用 App，就完成登录和选择项目；如果你使用 IDE Extension，就打开项目根目录，并确认 Codex 面板能看到当前文件；如果你使用 CLI，就在项目目录输入 codex。这个阶段不要让 Codex 改文件，只确认它能读到项目。

第 11 到 15 分钟发送第一条“只读”提示词，让 Codex 解释项目，不允许修改。你要观察它是否理解 README 中的目标、限制和验收标准。如果它理解错误，不要急着让它改，而是补充说明。这个阶段训练的是沟通，而不是生成。

第 16 到 22 分钟发送第二条“创建最小网页”的提示词，让它新建 index.html、style.css、app.js。你要重点关注它是否遵守了不安装依赖、不访问网络、不修改项目外文件的要求。如果它请求运行命令，你先看命令含义；如果命令只是本地预览，可以批准；如果命令要安装依赖或下载内容，就要求它改用无依赖方案。

第 23 到 27 分钟运行本地服务并手动测试。打开 http://localhost:5173，输入名字，点击按钮，确认结果显示。如果出错，把报错原文交给 Codex，让它先解释再修复。不要只写“不能用”，因为这会让它猜测太多。

最后 3 分钟审查和提交。运行 git status 和 git diff，看清楚改了哪些文件。确认无误后提交。这个 30 分钟练习的结果不是一个多么复杂的网页，而是你第一次亲手完成了“AI 修改代码但由人类掌控流程”的完整闭环。以后所有更大的项目，都可以从这个闭环放大。

二十、给初学者的安全边界清单

最后补一份可以贴在桌面上的安全边界清单。第一，不要让 Codex 第一次就接触你的重要私密目录，例如证件扫描件、个人照片、财务表格、账号密钥和生产服务器配置。第二，不要把 .env、API key、证书私钥直接粘进提示词。如果项目必须使用环境变量，只告诉它变量名和用途，不给真实值。第三，不要批准自己看不懂的高风险命令，尤其是带 sudo、rm -rf、chmod -R、curl | sh、全局安装、修改系统配置的命令。第四，不要把“它说没问题”当成最终验证，最终验证必须来自运行结果、测试结果和人工审查。

第五，不要让一次任务跨越太多目标。比如“重构项目、修复所有 bug、优化 UI、部署上线”应该拆成四到六个独立任务。第六，不要跳过 Git。哪怕项目只有三个文件，也要在任务前后提交检查点。第七，不要害怕让 Codex 停下来。你可以随时要求它只解释、不执行；只列计划、不修改；只审查、不提交。第八，不要把 AI 生成内容直接发布到生产环境。发布前至少要自己运行一次、检查一次、备份一次。

这份清单看起来保守，但它能让你长期使用 Codex。AI 编程的效率来自速度，也来自稳定。没有边界的速度会制造风险；有边界的速度才会变成生产力。

你还可以把这份清单写进项目的 README 或 AGENTS.md 中，让 Codex 每次进入项目都先读取。这样做的好处是减少重复沟通，也让协作规则变成项目资产。今天你只是在一个练习文件夹中使用它，明天你可能会把它用于个人网站、教学工具、App 原型或真实业务代码。越早建立安全边界，后续扩展越稳。

结语：第一次使用 Codex，最重要的是建立“可控感”

第一次使用 Codex，不必追求震撼效果。真正值得追求的是可控感：你知道它在哪个目录工作，知道它准备做什么，知道它改了哪些文件，知道怎么运行验证，也知道不满意时如何回滚。只要建立了这套流程，Codex 就不再只是一个会写代码的聊天机器人，而会成为你个人开发系统中的一个智能协作者。

本文的 Hello Codex 项目看起来很小，但它包含了 AI 编程的完整闭环：下载安装、登录、选择项目、写提示词、生成文件、运行预览、审查 diff、Git 提交、总结经验。这个闭环一旦跑通，你就可以把它复制到更大的任务中：个人网站改版、公众号工具开发、小程序页面、App 原型、教学演示网页、数据分析脚本。所有复杂项目，本质上都可以拆成一个个可验证的小任务。

下一次打开 Codex 时，可以记住一句话：不要把它当成许愿机，而要把它当成工程队友。给它清楚的任务，给它明确的边界，要求它先计划再行动，用 Git 记录每一步，用运行结果验证每一次改动。这样，AI 编程才会从“看起来很厉害”变成“真的能进入生产力”。

如果你是第一次接触编程智能体，建议把本文作为一个固定练习反复做两三遍：第一次照着步骤跑通；第二次尝试换一个小功能；第三次把流程迁移到自己的真实项目中。工具会不断更新，但“任务拆解、权限控制、版本管理、运行验证、人工审查”这五件事会长期有效。掌握这套方法后，任何新的 Codex 功能都能被你安全地吸收进自己的工作流，并逐步形成个人专属的 AI 编程方法论，让每一次协作都更稳、更快、更可控。

资料来源与延伸阅读

[1] OpenAI Developers: Codex Quickstart: https://developers.openai.com/codex/quickstart

[2] OpenAI Developers: Codex App: https://developers.openai.com/codex/app

[3] OpenAI Developers: Codex IDE Extension: https://developers.openai.com/codex/ide

[4] OpenAI Developers: Codex IDE Extension Features: https://developers.openai.com/codex/ide/features

[5] OpenAI Developers: Codex CLI: https://developers.openai.com/codex/cli

[6] OpenAI Developers: Codex CLI Features: https://developers.openai.com/codex/cli/features

正文中文字符数约 8002 字（不含代码、图注和资料来源），可按公众号排版继续增删小标题或案例。