Codex 零基础入门：用一个小游戏走完 AI 编程全流程

拿到一段 AI 生成的代码，和做出一个自己能用的项目，中间还隔着运行、修改、测试和保存版本。

这篇教程用一个“饼干店经营小游戏”把这些步骤串起来：从创建本地项目开始，让 Codex 生成第一版，再添加动画、查看改动、创建 Git 提交，最后尝试多智能体、Skill 和云端任务。先完成一个能运行的小项目，再逐步增加能力。

文中的界面截图取自配套视频，按钮位置以你正在使用的版本为准。本文的提示词已整理为便于照着操作的中文示例，不要求逐字输入视频里的英文。

1. 先给 Codex 一个明确的工作目录

安装并登录 ChatGPT 桌面应用，进入 Codex，再添加一个本地项目。桌面入口可参考 OpenAI 官方入门说明。

新手可以先建一个空文件夹，例如 cookie-shop，将它作为项目的工作目录。项目名用于识别任务，文件夹用于实际保存文件；两者最好取一个容易辨认的名字。

这里使用的是能访问本机文件夹的本地项目。它与仅上传资料的 ChatGPT 项目有所区别，相关概念可参阅官方的项目与对话说明。

第一次打开文件夹时，应用可能要求确认访问或信任。检查选中的目录是否正确，再继续。

2. 第一条提示词，把“能做什么”说清楚

第一版不必堆功能，但要说明玩法、输入、输出和运行方式。这个案例的核心是：玩家用有限资金经营饼干店，每天决定产量、价格和广告预算，再查看经营结果。

可以先输入下面这段需求：

创建一个浏览器小游戏，名称为“饼干店大亨”。

玩家初始拥有100美元，经营一家饼干店，共30天。
每天可以设置：饼干烘焙数量、每块售价、广告预算。
当天结束后显示：销量、收入、支出、利润和剩余资金。

界面简洁，适合新手操作，能在本地浏览器运行。
请先完成可玩的第一版，并说明如何打开和测试。

提交后，先看 Codex 创建了哪些文件，以及它给出的运行方法。视频中生成了 index.html、game.js、README.md 等文件，并通过打开页面进行预览。

“第一版已经生成”只是到了试用环节。接下来要检查：页面能否打开，输入是否有效，点击按钮后是否出现结果，进入下一天时资金和天数是否正确变化。

先让一轮完整操作跑通。背景图、动画和更复杂的系统，可以在确认基本玩法之后再加。

3. 想改什么，就围绕现有项目继续描述

游戏能玩以后，最直接的反馈是：屏幕上的数字变了，但“开店卖饼干”的感觉还不够明显。因此，第二轮要求增加顾客到店的动画。

在现有游戏中添加简单的顾客动画：
每天点击开店后，显示顾客到店购买饼干。
顾客数量大致反映当天卖出的饼干数量。
动画保持简单、有趣，保留现有经营规则。

Codex 完成修改后，刷新页面，再走一遍之前的操作。除了看动画是否出现，还要确认售价、广告预算和结算功能仍然可用。

如果效果不符合预期，可以把反馈写得更具体，例如：“顾客动画结束前，开店按钮不要重复触发”或“动画数量太多，请控制在更容易看清的范围内”。这些属于后续改进示例，不是视频中已经完成的功能。

每一轮最好围绕一个可检查的变化展开：描述修改 → 查看结果 → 试用 → 继续反馈。这样更容易判断是哪一次修改带来了问题。

4. 用 Git 给可用版本留一个检查点

项目改过几轮后，应该开始保存版本。视频展示了更改列表和 diff：绿色表示新增内容，红色表示删除内容。

即使暂时读不懂每一行代码，也可以先核对改动范围：这次只是添加动画，为什么还动了结算规则？如果有疑问，就让 Codex 解释这些修改与需求之间的关系。

确认当前版本能用后，可以这样提出要求：

检查当前项目的 Git 状态。
将本轮已经确认的修改创建为一次提交，
提交说明为“添加顾客动画”。
完成后告诉我提交是否成功，以及包含哪些文件。

如果项目还没有启用 Git，先让 Codex 说明当前状态，再初始化仓库并创建基线提交。官方的本地环境说明也介绍了应用中的 Git 更改、提交等操作。

Git 提交可以记录一次项目状态，但它不会自动证明功能正确。先验收，再提交；出现问题时，也要明确是希望回退某个功能、查看早期版本，还是撤销某次改动。

5. 功能可以拆开，再尝试多个智能体

视频接着把三项改进拆给不同的智能体：增加饼干种类、增加店铺升级系统、改善视觉效果和动画。

将接下来的改进拆成三个独立任务：
1. 增加不同口味的饼干及相应价格。
2. 增加烤箱、店面等升级选项。
3. 改善视觉效果和动画。

请让各任务在独立工作树中进行，暂时不要合并进主项目。
完成后分别说明修改内容、测试结果和查看方法。

工作树可以理解为同一个 Git 仓库的独立检出目录：各自有一份工作文件，可以分别修改和测试。它要求项目已经是 Git 仓库，详细规则见官方工作树文档。

任务完成后，分别试用，再决定合并哪些功能。视频先合并了饼干种类，其他两个版本继续保留。

将已经验收的“饼干种类”功能合并到主项目。
另外两个工作树先保留。
合并后检查主要玩法是否仍然正常，说明实际测试结果。

独立工作树减少了对主项目的直接干扰，但不代表合并一定没有冲突。功能共用同一文件或同一套业务规则时，合并后仍要重新检查。第一个项目很小时，先把单智能体的修改流程用熟，再增加并行任务也完全来得及。

6. 重复测试，可以整理成一个 Skill

每次添加功能后，都会遇到相似的检查：游戏能否启动、按钮能否使用、经营计算是否正确、是否允许超支、库存是否会出错。

这些重复要求适合整理成 Skill。官方说明中，Skill 的核心是 SKILL.md 中的指令与元数据，也可以配套脚本和参考资料；它可以用于固定一类任务的执行方法。参阅官方 Skill 文档。

为这个项目创建一个可复用的 Game Tester Skill。

检查游戏启动、主要控件、收入与利润计算、资金限制、
库存限制，以及一天结束后进入下一天的行为。

只报告发现的问题，不自动修改游戏。
报告中区分：已经验证、发现问题、无法验证。
对无法验证的项目，说明原因和建议的验证方法。

创建好之后，可以要求：“使用 Game Tester 检查当前游戏，按既定清单输出报告。”

这里有一个值得特别留意的细节：截图中的浏览器启动和控件验证标为 Unverified，并写明了 file:// 相关的浏览器访问限制。其他逻辑检查虽然有通过项，也不能据此把整份报告写成“全部测试通过”。

遇到这类结果，应把“没有发现问题”和“尚未完成验证”分开处理。可以继续询问：

请说明哪些项目没有完成实际浏览器验证。
如果本地文件访问方式阻碍了验证，给出可行的运行方案。
完成验证前，不要将相关项目标为通过。

Skill 能让检查要求更稳定，最终仍要看它实际执行了哪些步骤、获得了什么证据。

7. 需要远程执行时，再把任务交给 Codex Cloud

视频的云端部分可以按四个环节理解：准备 GitHub 仓库 → 推送当前项目 → 创建云端环境 → 提交具体任务。

首先连接 GitHub。视频中通过插件入口进行连接；当前账号的入口可能不同，按应用给出的连接和授权流程操作即可。创建仓库时，把名称和公开范围说清楚，例如：

将当前主项目准备为一个名为 cookie-shop-tycoon 的私有 GitHub 仓库。
先检查是否有同名仓库，以及本地是否有未提交修改。
确认需要推送的内容，完成后提供仓库地址和结果。

然后在任务位置中选择 Cloud，并选择或创建云端环境。按照当前官方云端环境文档，创建环境时需要选择仓库、完成设置与测试，再发布环境供任务使用。

这里的“发布环境”是准备供云端任务使用的运行环境。把代码推送到 GitHub、发布云端环境，都不等于已经把游戏部署成一个公开网站。

环境准备好后，就可以布置具体改进任务。视频中的示例是增加顾客满意度系统：

为游戏增加顾客满意度系统。
满意度应受到饼干种类、价格和当天需求的影响。
在界面展示当前分数，并解释当天分数为什么发生变化。
完成后测试主要流程，说明修改文件和测试结果。

回到结果时，仍要做与本地项目相同的事：查看更改、运行项目、检查新功能是否影响原有玩法。云端改变了执行位置，验收工作依然需要完成。

8. 第一次练习，做到哪里就够了

如果你第一次接触 Codex，先完成这三个结果：

从一个空文件夹得到能运行的初版。
提出一次明确修改，并在页面里看到它生效。
验收后创建一次 Git 提交，留下可辨认的版本。

完成这些以后，再逐步增加并行任务、测试 Skill 和云端环境。

这个案例可以迁移到小型工作清单、简单计算器或数据展示页面。每次换一个题目，仍然围绕同一套动作：把目标说具体，做出可运行的初版，按结果反馈，记录版本，再将反复有效的做法整理成可复用流程。

Codex 零基础入门：用一个小 游戏 走完 AI 编程全流程