不要只凭 Codex CLI 的“任务完成”提示提交：先检查实际改动，再运行课程要求的测试或构建，并确认关键行为符合题目；只有作业要求 Xcode 或 iOS 模拟器验收时，才需要转到兼容的 Mac 环境完成专项检查。
这份 Codex CLI 课程代码验收清单，适合第一次让它修改课程项目、但不熟悉 Git diff 和测试结果的学生。
如果你目前只有 Windows，也可以先做通用代码检查；是否需要 Mac，要看课程交付要求里有没有 Xcode 或模拟器验收。
最后更新于 2026 年 10 月 13 日。 Codex CLI 的工具说明依据 官方入门资料 与官方代码库文档核对；具体课程测试和提交要求，以你的课程说明及项目文档为准。
SECTION 01 修改前：给原始作业留一份可比较的版本
在开始前先确认自己打开的是正确项目目录，并读一遍题目要求、项目说明和现有代码。把目标拆成明确的小任务，例如“修复输入为空时的报错”，比“把程序完善一下”更容易在事后判断改动是否越界。
最稳妥的保护方式，是先保存一个可恢复版本。项目已经使用 Git 时，确认现有改动归属，再提交或另建分支保存当前状态；不熟悉 Git 时，先复制项目文件夹作为备份。备份文件不要放到容易被 Codex CLI 一并修改的位置。
| 修改前的状态 | 建议做法 | 后续能核对什么 |
|---|---|---|
| 项目已使用 Git，工作区干净 | 记录当前版本，再开始任务 | 与修改后的版本比较 |
| 项目已使用 Git，但已有未提交改动 | 先区分自己的修改和工具要处理的部分 | 避免把旧作业改动误认为新改动 |
| 项目没有版本记录 | 复制一份原始项目，保留题目与运行说明 | 与备份文件对照，发现变更 |
给 Codex CLI 的任务描述也要留有边界：写清要解决的问题、允许修改的文件范围，以及不能改变的课程要求。不要把老师提供的测试数据、评分标准或项目配置删掉后再开始验收。
SECTION 02 修改后：先看文件清单，再读 Git diff
代码差异，就是修改前后文件内容的对照；像检查作业答案一样，你要确认具体哪一行被增加、删除或改变。Git 的 diff 可以比较工作区与暂存内容或某个版本之间的差异，因此文件清单和内容差异要分别看，不能只读工具生成的总结。具体比较范围可查阅 Git diff 官方手册。
在项目目录执行：
git status --short
git diff --name-status
git diff
第一条帮助你查看工作区状态；第二条聚焦文件名称和变更类型；第三条展示具体内容。若你的改动已暂存，再用 git diff --cached 查看暂存区里准备提交的内容。
| 你看到的情况 | 先核对的内容 | 处理方向 |
|---|---|---|
| 只改了题目涉及的文件 | 改动是否对应任务目标 | 继续逐段检查 |
| 多出配置、依赖或无关文件 | 是否为运行测试必需，项目说明是否提到 | 不清楚就先询问或回退核查 |
| 文件被删除、改名或大范围重写 | 删除是否必要，重要逻辑是否还在 | 暂停提交，和原始版本比较 |
| 差异为空，但工具称已完成 | 当前目录、保存状态和版本记录是否正确 | 确认代码究竟写到了哪里 |
提醒：
git diff主要展示已被版本控制跟踪文件的差异；新建文件可能要先看状态列表才能发现。不要因为差异视图里没有代码变化，就认定项目没有新增文件。
SECTION 03 改动复核：把每项变化说清楚
阅读差异时，不必一开始就理解整个项目，但要能用自己的话解释主要改动：它修改了什么输入、影响了什么结果、为什么能解决题目中的问题。若你解释不了新增代码的作用，就先停下来让工具说明具体文件和修改理由，再对照实际差异核验，不要直接接受解释作为证据。
额外留意这些容易被忽略的变化：
- 是否加入了课程没有要求的依赖，或更改了项目配置。
- 是否新增、删除或移动了资源、测试文件和提交文件。
- 是否把题目给出的示例数据、接口或函数名称一并改掉。
- 是否修改了与当前任务无关的页面、函数或注释。
如果改动超出题目范围，先确认它是否确实是运行所必需；如果不能说明必要性，就恢复那部分再检查。不要为了“让测试通过”而接受与题目目标无关的额外修改。
SECTION 04 测试阶段：按项目说明运行，并记录真实结果
测试是对某些输入或功能执行检查；构建则是把项目整理成可运行的程序。两者都不能替代你对题目的理解，而且命令应以课程要求和项目自带说明为准。不要看到网上某个通用命令就直接套到自己的项目上。
| 项目类型或线索 | 验收动作 | 结果边界 |
|---|---|---|
| Python 项目提供测试文件 | 按课程说明运行；项目采用标准测试框架时，可先查其官方命令说明 | 只说明已运行的测试项结果 |
| 前端项目有项目说明或脚本 | 先查看说明中列出的测试、构建或启动方式 | 构建成功不代表每个交互都正确 |
| iOS 项目要求 Xcode | 按课程要求在 Xcode 中构建、运行或测试 | 模拟器检查不等于真机功能验证 |
如果课程项目明确使用 Python 标准库的 unittest，官方文档列出了按文件运行和自动发现测试的命令，例如 python -m unittest tests/test_something.py 与 python -m unittest discover；不要在项目并未采用该框架时照抄。每次运行后记下执行命令、通过或失败信息，以及失败时对应的文件或测试名称。命令示例可对照 Python unittest 官方文档。
测试通过只能说明已检查的部分符合预期，不能推断没覆盖的页面、输入和异常情况也正确。比如课程只测了正常输入，你还需要按题目要求手动检查空输入、边界数据或错误提示；不必自行发明课程没有要求的测试标准，但要把未验证的部分说清楚。
SECTION 05 提交前：按题目要求作最后判断
把作业要求拆成可核对的项目，对照程序实际行为、测试记录和准备提交的文件。若项目无法按项目说明启动，或者同一检查在相同条件下结果不一致，先找原因，不要用工具提出的额外改动来掩盖问题。
| 验收记录 | 通过条件 | 未通过时 |
|---|---|---|
| 改动范围 | 每项变化都能对应题目目标 | 暂停提交，解释或恢复无关改动 |
| 关键行为 | 题目要求的输入与结果能对应 | 重现问题，定位代码或理解偏差 |
| 测试与启动 | 按课程说明运行，结果可复核 | 区分代码错误、环境问题和命令错误 |
| 交付文件 | 文件类型、目录和格式符合提交说明 | 按要求整理后重新检查 |
决策分支：
- 若你能说明主要改动、课程要求的测试或构建已运行，且题目要求的行为和提交文件都核对通过，就按课程要求提交。
- 若测试失败，先判断失败来自代码、运行环境还是题意理解；原因没查清前，不要提交，也不要连续接受未经核验的修复。
- 若测试通过但你无法解释关键改动，或有题目未覆盖的重要行为，就先暂停，补做检查或请老师、助教确认。
- 若课程要求 Xcode 构建或 iOS 模拟器运行，而当前设备不能提供这些条件，就把通用代码复核和 Mac 专项验收分开处理，不要把前者当成后者的替代。
SECTION 06 Xcode 专项：课程要求时再切换到 Mac
通用代码差异检查不等于 Xcode 验收。若课程只要求读代码、运行跨平台逻辑或完成普通测试，先在现有设备上处理即可；若交付明确要求 Xcode 构建、运行 iOS 模拟器或检查 Apple 平台特有行为，就需要兼容的 Mac 环境完成相应步骤。
Apple 的文档说明，Xcode 可在模拟设备或实体设备上运行应用；但模拟器不一定具备实体设备的全部硬件功能，涉及设备专属行为时应按课程要求选择真实设备验证。构建和运行时还要确认项目方案及运行目标正确，具体说明见 Apple 关于模拟或实体设备运行应用的文档。
需要 Xcode 时，可先对照 Xcode 官方文档和课程环境要求，确认所需组件、运行目标及交付形式。测试结果则应查看具体失败项和错误信息；Apple 的测试结果说明也将测试定位为检查代码行为的手段，而不是对所有未测场景的保证。
SECTION 07 常见问题
Git diff 没显示新文件，是不是 Codex CLI 没有新增文件？
不一定。新文件可能还没有纳入版本控制，先查看 git status --short，再检查项目目录；确认新增文件后，判断它是否属于作业交付范围。
测试命令报错，但代码看起来没问题怎么办？
先保留完整报错，确认自己位于项目目录，并按课程或项目说明核实运行命令、依赖和环境。只有排除命令或环境问题后，才把它作为代码失败继续排查。
没有 Xcode，能先检查 iOS 项目吗？
可以先核对源代码变化、题目要求和能够在当前环境运行的通用检查；但这不能代替课程明确要求的 Xcode 构建或 iOS 模拟器验收。先问清老师是否要求实际运行结果。
SECTION 08 按验收缺口选择下一步
如果你的课程只要求通用代码测试，用现有电脑按清单验收即可；为了一次课程作业购买 Mac，可能带来不必要的硬件开销。反过来，若你长期需要本地运行、必须连接实体设备，或课程项目依赖本地硬件，远程环境未必合适。临时需要 Xcode 时，可以先通过 VPSNIX 的 Mac 学习环境说明核对连接与交付方式，再查看可选方案，确认符合课程要求后再决定是否租用。远程 Mac 可以减少为短期验收单独购机的负担，但网络连接、远程操作方式和课程所需的实际设备仍需提前确认。