# 第一次用 Codex：从模糊需求到可验收改动

- 定位：CODEX 实操
- 面向人群：没有技术基础、希望把 AI 用到真实工作的人
- 课程说明：用一个真实的网站小改动，完整演示任务定义、项目检查、最小修改、验证和交付。
- 章节数：12

## 01｜只说“帮我改一下网站”，为什么容易翻车？

**屏幕提示：** 开场 · 先看失败现场

**旁白：** 很多人第一次用 Codex，会直接说：帮我改一下网站。然后看到它开始读文件、改代码，心里越来越没底。问题不在 Codex 会不会写代码，而在于我们没有告诉它：最后要变成什么、哪些地方不能动、拿什么证明任务已经完成。

## 02｜把首页按钮改成“开始学习”

**屏幕提示：** 本课任务

**旁白：** 我们不用虚构一个大项目，只做一个十分钟能验收的小任务：把学习站首页的按钮文字，从从零开始学 AI，改成开始学习。商城链接不能改变，其他课程内容不能改，修改以后还要检查站内链接。这就是今天的清楚终点。

## 03｜弱任务和可执行任务，差在哪里？

**屏幕提示：** 第一步 · 定义任务

**旁白：** 帮我改一下首页、做得好看一点，这种任务把所有判断都推给了 Codex。可执行任务至少要回答三个问题：具体改什么，哪些内容不能动，怎样才算完成。清楚不等于写很长，而是把决定结果的边界说出来。

## 04｜结果、位置、现状、边界、验证、交付

**屏幕提示：** 任务说明 · 六个字段

**旁白：** 给 Codex 的任务可以固定成六个字段。结果：最后要看到什么。位置：项目和页面在哪里。现状：现在是什么样。边界：哪些内容不能动。验证：要运行什么检查。交付：最后需要它汇报哪些文件、测试和风险。以后任何代码任务，都可以先填这六项。

## 05｜把真实边界放进任务里

**屏幕提示：** 可以直接照着写

**旁白：** 完整任务可以这样写：检查当前网站项目，把首页主按钮文字改为开始学习。不要修改按钮链接、商城入口和其他课程内容。先找到相关文件并说明计划，再执行修改。完成后检查内部链接，并汇报改动文件和验证结果。这里没有神奇句式，只有清楚的工作合同。

## 06｜先让 Codex 说明它看到了什么

**屏幕提示：** 第二步 · 先检查再修改

**旁白：** 收到任务后，先看它的检查结果，而不是只等最后答案。一个合理的计划应该指出相关文件、当前按钮文字、准备修改的位置和验证方式。如果它准备顺手重构页面、升级依赖，或者修改没有关系的文件，就应该立刻缩小范围。

## 07｜最小修改应该一眼能看懂

**屏幕提示：** 第三步 · 检查差异

**旁白：** 现在看差异。删除的是从零开始学 AI，新增的是开始学习。链接地址完全没有变化，也没有其他文件被顺手修改。你不需要读懂整个项目，但必须能回答：这次变了什么，为什么必须变，是否超出了任务边界。

## 08｜完成不是一句话，而是检查结果

**屏幕提示：** 第四步 · 用证据验收

**旁白：** 接下来验收。确认首页已经出现开始学习，按钮链接仍然指向第一阶段，站内页面没有缺失链接，再用桌面和手机尺寸预览。Codex 说已经完成，只是一条陈述；文件差异、检查输出和实际页面，才是完成证据。

## 09｜这三类操作不要无条件放行

**屏幕提示：** 安全边界

**旁白：** 还有三条安全底线。密码、密钥和客户数据先脱敏。涉及删除、付费或生产发布时，先确认准确目标。重要修改要保留备份和回滚方式。Codex 可以执行操作，但允许使用哪些文件、工具和外部系统，仍然由你决定。

## 10｜一次小改动用普通任务，多轮探索才考虑 Goal

**屏幕提示：** 普通任务还是持续目标？

**旁白：** 像今天这种一次就能完成的小改动，普通任务最合适。如果工作需要多轮尝试，例如持续优化性能、复现偶发故障、迁移并反复测试，才适合把终点、验证证据和约束写成持续目标。无论使用哪种方式，证据都应该决定是否完成。

## 11｜五个问题，判断结果能不能接收

**屏幕提示：** 交付前检查

**旁白：** 接收结果前问五个问题：改动是否只覆盖目标范围；关键差异是否能解释；检查或测试是否真的运行；页面或功能是否亲自看过；失败时能否恢复到修改前。如果有一项答不上来，任务还不能算真正交付。

## 12｜现在完成一次小而完整的 Codex 任务

**屏幕提示：** 跟做练习 · 15 分钟

**旁白：** 现在轮到你。选一个十分钟能验收的小改动，填写结果、位置、现状、边界、验证和交付六个字段。先审查计划，再允许修改。最后检查差异、运行验证并记录结果。真正会用 Codex，不是让它写更多代码，而是让每一次改动都有边界、有证据、能交付。