3.2 海外路线：用 Codex App 做出第一个产品
本节任务：使用 Codex App 在本地完成个人介绍网站，检查代码变化和运行结果，再提交到 GitHub 并部署到 Vercel。
本节目标
完成这一节后，你应该能够：
- 理解 Codex App、Codex CLI 和普通聊天工具的区别
- 在 Codex App 中打开项目并创建任务线程
- 先让 Codex 检查项目和规划，再授权修改
- 审查文件差异，运行检查并修正问题
- 使用 Git 保存版本，推送到 GitHub 并部署到 Vercel
- 判断什么时候需要使用 Codex CLI
本节继续制作上一节的个人介绍网站。Coze 编程更强调在线生成和快速发布；Codex App 更强调本地代码所有权、变更审查和持续维护。
Codex App 是什么
Codex App 是 OpenAI 提供的桌面 AI 编程应用。它不是一个只负责回答代码问题的聊天窗口，而是可以在获得授权后读取项目、修改文件、运行命令并展示变更的工作环境。
你可以把几种常见方式理解为：
| 方式 | 主要交互界面 | 更适合的场景 |
|---|---|---|
| 普通 AI 对话 | 浏览器聊天窗口 | 解释概念、讨论方案和生成片段 |
| Codex App | 桌面应用、线程和变更审查 | 新手入门、本地项目和多任务协作 |
| Codex CLI | 终端 | 远程环境、脚本化操作和命令行工作流 |
对于本书读者，Codex App 是默认入门路线，CLI 是后面的进阶补充。图形界面能更直观地看到项目、任务过程和文件变化，但这并不代表你可以跳过验收。
第一步：安装并登录
从 Codex 官方页面 下载适合当前系统的 App，安装后使用支持的 OpenAI 或 ChatGPT 账号登录。
产品支持的系统、套餐、模型和界面可能发生变化，以官方页面和应用内显示为准。本节不记录容易过期的价格、额度和按钮位置。
第二步：准备项目文件夹
为了把注意力放在 AI 协作流程上，可以从一个现有的静态网站模板开始，也可以让 Codex 在空文件夹中创建最小项目。
在电脑上创建一个空文件夹，例如：
personal-site/
在 Codex App 中选择这个文件夹作为工作区。工作区决定了 Codex 可以读取和修改哪些文件，选择前先确认路径正确，不要误选包含大量私人资料的目录。
权限不是确认弹窗而已
Codex 可能需要文件写入、命令执行或网络访问权限。每次授权前先判断任务是否真的需要：
| 权限 | 常见用途 | 审核重点 |
|---|---|---|
| 读取文件 | 了解项目结构和现有代码 | 工作区是否选对 |
| 写入文件 | 创建或修改项目 | 修改范围是否符合任务 |
| 运行命令 | 安装依赖、启动和测试 | 命令是否与当前项目有关 |
| 网络访问 | 下载依赖或访问外部服务 | 是否会上传敏感内容 |
不要在提示词、项目文件或截图中放入 API Key、密码和其他密钥。需要密钥时应使用环境变量，并确保 .env 类文件不会被提交到 Git。
第三步：创建线程，先让 Codex 检查
新建线程后，先说明目标和工作方式，不要立即要求大范围改动：
我要在这个文件夹中制作一个个人介绍网站，目标读者是潜在合作伙伴。
请先不要修改文件。先完成以下工作：
1. 检查当前目录和已有文件
2. 判断是否已经有可用的网站框架
3. 给出最小实施方案
4. 列出需要我确认的内容
5. 给出完成后的验收清单
优先采用现有项目的技术和风格，不要添加不必要的依赖。
如果是空目录，Codex 应该说明准备创建什么；如果已有项目，它应该先识别框架、脚本和约束。没有读懂项目就直接重建，通常会带来无谓改动。
第四步：提供真实内容和明确范围
把上一节准备的 Markdown 资料放进项目，或者直接提供给 Codex。确认方案后再要求执行：
按照确认后的方案实现个人介绍网站。
范围：
- 姓名和一句话定位
- 关于我
- 2 至 3 个项目
- 联系方式
- 桌面端和手机端适配
限制：
- 只使用我提供的真实资料，不编造经历或数据
- 不添加登录、数据库、后台和支付
- 不引入项目当前没有且并非必要的框架
- 保持实现简单，完成后运行现有检查
这里最重要的是写出“不做什么”。对第一个项目来说，控制范围比增加功能更有价值。
第五步：阅读执行过程，但用结果验收
Codex 工作时会说明正在检查或修改什么。这些说明有助于你发现方向偏差，但不能替代最终检查。
任务结束后重点查看：
- 修改了哪些文件。
- 是否添加了没有必要的依赖。
- 是否删除或重写了原有内容。
- 是否存在占位资料、虚构经历或无效链接。
- 是否实际运行了构建、测试或格式检查。
如果项目原来就有未提交改动，要特别注意区分哪些是你的改动、哪些是 Codex 新增的改动，不要为了“恢复干净”覆盖已有工作。
第六步：启动本地预览
让 Codex 根据项目实际脚本启动开发服务，例如：
请检查 package.json 中已有的脚本，启动本地开发服务。告诉我访问地址，并检查终端和浏览器控制台是否有错误。不要自行更换框架。
常见命令可能是：
npm install
npm run dev
不要不加判断地复制命令。项目也可能使用 pnpm、yarn 或其他工具，应以仓库已有的锁文件和说明为准。
打开本地地址后，按与 Coze 版本相同的标准检查：
- 首屏是否能快速说明你是谁、做什么
- 资料和链接是否准确
- 手机端是否有溢出、重叠或难以点击的控件
- 页面刷新后是否正常
- 浏览器控制台是否有错误
第七步：反馈问题，让 Codex 定点修复
一次反馈只处理一组相关问题，并明确不允许改变的部分：
本地预览发现三个问题，请定点修复，不要重构其他区域：
1. 手机端项目卡片超出屏幕宽度。
2. GitHub 链接指向了示例地址，请改为我提供的真实地址。
3. 首屏标题与下一段间距过大，在常见笔记本屏幕上看不到项目区入口。
修改后重新运行检查，并说明具体改了哪些文件。
修复后重新看变更，而不是只相信“已经完成”的文字回复。修改范围明显超出要求时，应让 Codex 解释原因或撤回无关改动。
第八步：运行工程检查
让 Codex 先读取 package.json 和仓库文档，再运行项目已经提供的检查。典型检查包括：
npm run build
npm run lint
npm test
并非每个项目都有这三个脚本。不存在的脚本不需要临时造一个来“凑齐”，但至少应该确保生产构建通过，并完成一次浏览器里的关键流程检查。
什么叫完成
本项目的完成标准是：
- 内容与提供的资料一致
- 桌面和手机端页面可正常使用
- 外部链接有效
- 没有明显控制台错误
- 生产构建通过
- 变更范围与任务一致
- 不包含密钥、构建产物和无关文件
第九步：用 Git 保存可回退版本
先查看状态和差异：
git status
git diff
确认文件无误后再提交：
git add <本次修改的文件>
git commit -m "feat: add personal introduction site"
优先只暂存本次任务涉及的文件，而不是习惯性执行 git add .。如果仓库中还有其他人的修改或本地生成文件，不应混进这次提交。
第十步：推送 GitHub 并部署 Vercel
如果项目还没有远程仓库，先在 GitHub 创建仓库，再按页面给出的命令建立关联。已有远程仓库时，先确认当前分支和同步状态：
git branch --show-current
git status
git fetch origin
确认没有冲突后再推送。不要在不理解远端差异时使用强制推送。
在 Vercel 中导入 GitHub 仓库时：
- 选择包含网站源码的仓库。
- 如果是单仓库，根目录通常保持默认。
- 如果网站在子目录中，把 Root Directory 指向该子目录。
- Framework Preset 优先使用 Vercel 自动识别结果。
- 构建命令和输出目录优先使用框架默认值。
- 部署完成后检查公开地址，而不是只看“Deployment Ready”。
静态网站和常见前端框架通常不需要自定义 Vercel 配置。只有默认识别失败或项目确有特殊路由需求时，才增加 vercel.json。
Codex CLI 放在哪里
Codex CLI 与 App 面向同一类本地编程任务，但交互入口不同。当你遇到以下情况时，再学习 CLI 更合适：
- 需要在远程服务器或纯终端环境工作
- 希望把 Codex 放进脚本化流程
- 已经熟悉 Shell，终端操作比图形界面更快
- 需要精确组合现有命令行工具
安装和登录方式可能随版本变化，应以 Codex CLI 官方仓库 的当前说明为准。安装完成后，通常可以在项目目录启动：
codex
不要把 API Key 写进命令历史、代码或公开教程截图。Codex 当前支持的登录方式以实际客户端提示为准。
Coze 编程与 Codex App 如何选择
| 维度 | Coze 编程 | Codex App |
|---|---|---|
| 开始方式 | 在线对话和生成 | 打开本地项目并创建线程 |
| 主要优势 | 快速得到可预览版本 | 掌握文件、代码和 Git 历史 |
| 修改方式 | 预览、标注、版本记录 | Diff、文件审查、命令和测试 |
| 发布方式 | 平台提供的发布能力 | GitHub 与 Vercel 等工程流程 |
| 更适合 | 快速验证、低门槛原型 | 长期维护、持续开发和协作 |
两者不是高低级关系。判断标准是：这个项目是否需要你长期掌握代码、数据和部署流程。
练习
基础练习
- 用 Codex App 完成个人介绍网站。
- 查看并解释本次修改涉及的主要文件。
- 完成构建、Git 提交和公开部署。
对照练习
把 Coze 版本和 Codex 版本发给同一个人，观察：
- 哪个版本更快完成
- 哪个版本更容易做精确修改
- 哪个版本的代码和部署更容易长期维护
进阶练习
在新线程或独立工作区中增加“最近更新”区块。完成后只合并确实需要的改动，并保持主版本随时可以运行。
常见问题
Codex 修改范围太大怎么办
先停止继续扩展需求，查看 Diff，并明确要求保留哪些文件、撤回哪些无关修改。后续任务增加“只修改指定文件”或“先给方案，不执行”的限制。
本地可以运行，Vercel 构建失败怎么办
把完整构建日志交给 Codex 分析，同时检查 Node.js 版本、包管理器锁文件、环境变量和项目根目录。不要只截最后一行错误。
推送时提示远端有更新怎么办
先执行 git fetch 并检查远端差异，再选择合并或 rebase。不要用强制推送覆盖不清楚的远端提交。
Codex 说完成了，但页面仍有问题怎么办
以浏览器结果、控制台、测试和构建输出为准。提供复现步骤、截图和错误信息，让 Codex 继续定点修复。
本节回顾
Codex App 降低的是操作代码的门槛，不是判断产品是否正确的责任。真正可迁移的能力是：给出明确范围、审查变化、用运行结果验收，并保留可回退的版本。
资源
| 资源 | 链接 |
|---|---|
| Codex 官方页面 | https://openai.com/codex/ |
| Codex CLI 官方仓库 | https://github.com/openai/codex |
| GitHub | https://github.com |
| Vercel | https://vercel.com |