第一次让 Codex 改代码

第一次让 Codex 改代码

这一篇开始让 Codex 真正修改文件。

但请注意：第一次改代码，目标不是“做一个很厉害的功能”，而是跑通一个最小闭环：

明确任务 -> 限定范围 -> 让 Codex 修改 -> 让 Codex 解释 diff -> 判断是否接受

本篇推荐只做一个低风险小改动，比如：

• 修改 README 里的一句话。
• 修改首页标题文案。
• 修改一个按钮文案。
• 修改一个静态提示语。

不要一上来修复杂 Bug，也不要一上来新增完整页面。

前置教程：第一次让 Codex 阅读项目
如果你还没有让 Codex 只读分析过项目，先完成前置教程，再回到本篇。

依据来源：OpenAI Codex 官方手册中关于提示词、任务上下文、验证和审查 diff 的说明。

本篇目标

跟着本篇做完后，你应该能做到：

1. 从只读分析结果里选一个低风险修改任务。
2. 写出范围明确的 Codex 修改提示词。
3. 限制 Codex 只改一个文件。
4. 等 Codex 修改完成。
5. 让 Codex 检查并解释改了哪些文件。
6. 让 Codex 总结 diff。
7. 判断这次改动是否可以接受。

本篇不做什么

本篇不做这些事情：

• 不运行 npm run build。
• 不运行测试。
• 不提交 Git。
• 不做复杂 Bug 修复。
• 不新增完整功能。
• 不让 Codex 一次修改多个文件。

构建、测试和提交会放到后面的教程。第一次改代码先把范围控制住。

你需要准备什么

你需要已经有：

• 一个能正常打开的项目。
• 已登录的 Codex CLI。
• 干净的 Git 状态。
• 上一篇教程得到的项目分析结果。

使用阶段主要靠对话完成。只需要打开已经准备好的项目并启动 Codex；项目状态、文件变化、diff 解释，都优先让 Codex 帮你检查。

如果你使用 CLI，可以先进入项目目录：

cd D:\code\codex-demo

如果你的项目在 C 盘：

cd C:\code\codex-demo

进入 Codex 后，先让 Codex 确认项目状态是否适合继续，不要自己急着改。

第 1 步：选择一个低风险任务

第一次修改不要选大任务。

推荐任务：

把首页标题从 “Vite App” 改成 “Codex Demo”

或者：

在 README 里增加一句项目说明

如果你用前面教程创建的是 Vite vanilla 项目，推荐改首页文案。

一个好任务应该满足 5 个条件：

1. 只涉及 1 个文件。
2. 不需要改数据库。
3. 不需要安装依赖。
4. 不需要理解复杂业务。
5. 改错了能通过 Git diff 看出来。

不要选这些任务：

• 优化整个首页。
• 重构项目结构。
• 修复所有报错。
• 增加登录注册。
• 接入支付。

第 2 步：启动 Codex

如果你还没进入 Codex，在项目目录启动：

codex

进入 Codex 后，不要直接说：

帮我改一下首页

这太模糊。

要告诉它：

• 目标是什么。
• 允许改哪个文件。
• 不允许做什么。
• 完成后怎么汇报。

如果你已经在 Codex 里，可以跳过这一步。

第 3 步：让 Codex 先确认当前状态

进入 Codex 后，先发送：

在开始修改前，请先只读确认当前项目是否适合做第一次小修改。

请检查并告诉我：
1. 当前项目路径。
2. Git 工作区是否干净。
3. 首页文案或 README 可能在哪个文件。
4. 你建议我第一次只改哪 1 个文件。

要求：
- 不要修改文件。
- 不要运行构建。
- 不要安装依赖。
- 不要提交 Git。

你要等 Codex 回复后再继续。

如果 Codex 说工作区噪音较多，先不要开始修改。让它解释有哪些变化，以及是否应该换一个干净项目练习。

第 4 步：复制第一次修改提示词

如果你要改 Vite 首页标题，复制下面这段：

请完成一个非常小的首次代码修改任务。

任务目标：
把当前项目首页中显示的默认标题或默认欢迎文案，改成 “Codex Demo”。

修改范围：
1. 请先定位首页文案在哪个文件。
2. 只允许修改 1 个文件。
3. 不要修改样式文件。
4. 不要安装依赖。
5. 不要运行构建命令。
6. 不要提交 Git。
7. 修改完成后，请你自己检查 Git 状态和 diff，并用中文解释给我。

完成后请按下面格式回复：

## 修改文件
- 文件路径：

## 修改内容
- 原文案：
- 新文案：

## 为什么只改这个文件
- 说明原因：

## 我接下来应该检查什么
- 请直接总结本次 Git 状态和 diff。
- 请告诉我是否只修改了 1 个文件。
- 请告诉我是否存在超出范围的改动。

如果你的项目不是 Vite，可以把任务目标换成更通用的 README 改动：

请完成一个非常小的首次代码修改任务。

任务目标：
在 README.md 开头增加一句项目说明：“这是一个用于练习 Codex 的演示项目。”

修改范围：
1. 只允许修改 README.md。
2. 不要修改其他文件。
3. 不要安装依赖。
4. 不要运行构建命令。
5. 不要提交 Git。
6. 修改完成后，请你自己检查 Git 状态和 diff，并用中文解释给我。

完成后请按下面格式回复：

## 修改文件
- 文件路径：

## 修改内容
- 新增了什么：

## 为什么只改这个文件
- 说明原因：

## 我接下来应该检查什么
- 请直接总结本次 Git 状态和 diff。
- 请告诉我是否只修改了 1 个文件。
- 请告诉我是否存在超出范围的改动。

第 5 步：等待 Codex 完成修改

Codex 可能会先读取文件，然后修改一个文件。

你在它完成前不要继续追加新任务。

完成后，先看它的总结。

你要确认：

1. 它有没有写清楚修改了哪个文件。
2. 它有没有说明原文案和新文案。
3. 它有没有遵守只改 1 个文件。
4. 它有没有擅自运行构建或提交 Git。

第 6 步：让 Codex 解释 Git 状态和 diff

如果 Codex 修改完后没有主动解释 diff，不要自己急着敲命令，继续问：

请检查本次修改后的 Git 状态和 diff，并用中文解释。

要求：
1. 列出被修改的文件。
2. 说明每个文件为什么被修改。
3. 总结具体 diff。
4. 判断是否只修改了 1 个文件。
5. 判断是否有超出任务范围的改动。
6. 不要继续修改文件。

只需要看 Codex 的解释，并截图保存。

第 7 步：判断是否只改了预期文件

你希望 Codex 的解释里只有 1 个文件被修改。

示例：

modified:   src/main.js

或者：

modified:   README.md

如果你看到多个文件被修改，先不要继续。说明 Codex 没有严格控制范围，或者项目里本来就有其他改动。

你可以继续问：

我要求只修改 1 个文件，但你报告有多个文件变化。请逐个解释原因，不要继续修改文件。

第 8 步：判断 diff 是否足够小

你要检查：

1. 是否只改了你要求的文案。
2. 是否有无关格式化。
3. 是否有大片代码被删掉。
4. 是否改了不该改的文件。

如果你只要求改标题，理想 diff 应该很小。

如果你看不懂 Codex 的 diff 总结，可以继续问：

请用完全新手能看懂的话解释这次 diff。只解释，不要修改文件。

第 9 步：判断是否接受改动

如果满足下面条件，可以暂时接受：

• 只改了 1 个文件。
• 改动内容和任务目标一致。
• 没有删除大片代码。
• 没有改配置文件。
• 没有新增奇怪依赖。

如果不满足，先不要提交。

你可以让 Codex 解释：

我看到你总结的 diff 里有超出任务范围的改动。请只解释为什么出现这些改动，不要继续修改文件。

第 10 步：如果改错了怎么撤回

第一次练习时，如果你确定这次改动不要了，可以让 Codex 撤回单个文件。

不要直接说“全部撤回”，而是明确文件路径：

请撤回本次对 src/main.js 的修改。

要求：
1. 只撤回这个文件。
2. 不要修改其他文件。
3. 撤回后检查 Git 状态并告诉我结果。

如果改的是 README.md：

请撤回本次对 README.md 的修改。

要求：
1. 只撤回这个文件。
2. 不要修改其他文件。
3. 撤回后检查 Git 状态并告诉我结果。

如果 Codex 告诉你工作区恢复干净，说明撤回成功。

注意：撤回会丢掉这个文件的未提交改动。正式项目里如果你不确定，先不要让 Codex 撤回，先截图或让 Codex 解释 diff。

常见问题

情况 1：Codex 修改了多个文件

不要继续让它扩大修改。

你可以问：

我要求只修改 1 个文件，但现在 git status 显示多个文件变化。请解释每个文件为什么变化，不要继续修改。

情况 2：Codex 改了样式文件

如果你明确写了“不要修改样式文件”，它仍然改了样式文件，说明任务约束没有被遵守。

你可以要求 Codex 只撤回样式文件：

请只撤回本次对 src/style.css 的修改。

要求：
1. 不要改其他文件。
2. 撤回后检查 Git 状态。
3. 用中文告诉我现在还剩哪些文件有变化。

然后重新给更严格的提示词。

情况 3：Codex 运行了构建命令

本篇不要求运行构建命令。

如果它运行了，也不一定有问题，但说明它没有完全遵守“不要运行构建命令”的限制。

你可以在后续提示词里更明确：

本次任务只允许修改文件和总结，不允许运行任何命令。

情况 4：diff 看不懂

你可以让 Codex 解释 diff，但不要让它继续改：

请解释当前 git diff。只解释，不要修改任何文件。

验收结果

做到这里，如果满足下面 7 条，就说明本篇完成：

1. 你通过 Codex 确认了开始前 Git 状态适合练习。
2. 你选择了一个低风险小任务。
3. 你给 Codex 的提示词限制了修改范围。
4. Codex 完成了修改。
5. Codex 汇报只修改了预期文件。
6. Codex 解释的 diff 很小，并且符合任务目标。
7. 你知道如何让 Codex 撤回指定文件的本次修改。

本篇你真正学会了什么

你学会了 Codex 改代码的第一条安全原则：

第一次改动一定要小，小到你能一眼看懂 diff。

这比一次做出复杂功能更重要。

下一篇学什么

下一篇看：让 Codex 完成任务验收。

那一篇会讲怎样在任务开始前写清验收标准，怎样看懂 Codex 做了哪些检查，以及当 Codex 漏检或检查失败时怎么继续追问。