完成第一次修改并检查结果：本地网页练习与历史案例

难度：基础

类型：首次任务后的结果检查

首期主线：准备 → 打开练习目录 → 完成小修改 → 检查结果

首期统一练习

本文首期使用独立的本地静态网页练习：只修改 index.html 的主标题和一段简介，保留按钮链接、其他 HTML 内容和全部 CSS。练习材料在 `练习材料/首次任务-本地网页/`；不要直接操作 CodexGuide 正式网站或私人仓库。

适用环境：已经登录 Codex App 或 CLI 其中一种，并能打开复制出的练习目录。App 与 CLI 共用同一任务和验收标准，本轮没有声称所有系统和客户端均已实测。

先确认起始目录

1. 解压 `Codex首次任务-本地网页练习包.zip`，或复制仓库中的 练习材料/首次任务-本地网页/起始文件/。
2. 把 起始文件/ 复制到新的测试目录；Codex 应打开这个复制出的目录，直接看到 index.html 和 styles.css。
3. 先打开 任务说明.md，再阅读 检查清单.md。参考差异/ 只在修改后查看。
4. 不要把原始 starter 当作工作区，也不要向目录加入 Token、.env、客户资料或生产配置。

给 Codex 的任务

请先阅读 index.html 和 styles.css，不要修改文件。
然后只做这两处文字修改：
1. 将主标题改为“我的第一个 Codex 练习”；
2. 将简介改为“先看清修改，再确认页面结果。”。
请保留按钮文字、https://example.com 链接、其他 HTML 内容和全部 CSS 样式。
完成后告诉我修改了哪些行，不要运行部署或安装命令。

如果 Codex 先提出读取或编辑请求，确认路径仍是这个测试目录。App 和 CLI 的按钮、权限显示可能不同；本任务只需要允许当前练习目录内的读取和编辑。

检查修改范围

预期只有 index.html 的两处文字变化：

-    <h1>晨间读书角</h1>
-    <p class="intro">用十分钟记录今天读到的一段话，慢慢建立自己的阅读清单。</p>
+    <h1>我的第一个 Codex 练习</h1>
+    <p class="intro">先看清修改，再确认页面结果。</p>

逐项检查：

• styles.css 没有变化；
• 按钮文字仍是“查看阅读清单”；
• 按钮链接仍是 https://example.com；
• diff 中没有重排、安装、部署或其他文件修改；
• 若目录不是 Git 仓库，使用原始 starter 和当前文件做人工比较，不要凭空补写测试命令。

检查实际页面结果

直接在浏览器打开测试目录中的 index.html，确认标题、简介、按钮和样式都正常显示。页面能打开只证明浏览器读到了本地文件，不证明 Codex 已经正确完成任务；还要把页面看到的结果和 diff 对照。

出错时怎么处理

• 找不到 index.html：停止修改，用 pwd、ls 或 App 的当前文件夹信息确认打开的是复制出的目录。
• styles.css 或按钮链接发生变化：保留当前 diff 作为证据，重新解压到新目录，不要清空真实工作区或执行 git reset --hard。
• 页面文字正确但样式异常：比较 styles.css 与 starter；如果不能确认，重新解压再练习。
• 登录、权限或客户端入口异常：先看登录 Codex和安装登录常见问题；仍无法定位时进入故障排查目录。

当前练习的完成标准

• [ ] 在正确的复制目录中完成修改；
• [ ] 只改了 index.html 的标题和简介；
• [ ] 原有按钮文字、链接和 CSS 保留；
• [ ] 已查看 diff 或完成起始文件对照；
• [ ] 浏览器页面显示与目标文字一致；
• [ ] 记录了客户端、操作系统和任何未验证项。

下面保留此前发布的 README 文档案例，供希望学习“先查项目实际命令，再修改并验证”的读者参考。它依赖一个另行准备的 Node.js 练习项目，不是首期本地网页练习。

历史案例：README 文档修改

开始前确认

准备一个可以随时恢复的练习项目，并确认：

• 当前目录是项目根目录；
• 项目中没有密码、Token、客户资料或生产配置；
• 你知道当前 Git 分支和工作区状态；
• 第一次练习只改一个文件。

本次示例项目的目录如下：

codex-first-edit-demo/
├─ README.md
├─ package.json
└─ tests/
   └─ check.mjs

<p align="center">图一：打开练习项目，确认 README、配置文件和测试目录</p>

先做只读检查

先让 Codex 读取项目，不要修改文件。可以直接发送：

请先只读取项目配置和 Git 状态，不要修改文件。

请告诉我：
1. README.md 当前有哪些标题；
2. 项目的启动命令和测试命令；
3. 当前 Git 分支和工作区是否有未提交修改；
4. 完成下一步任务前，你准备读取哪些文件、运行哪些命令。

<p align="center">图二：先确认项目结构、脚本和 Git 状态</p>

这一步的价值在于先看事实，再写任务。示例项目的 package.json 只有 npm test，没有 npm run dev。如果 README 写入不存在的启动命令，文档就会误导读者。

<p align="center">图三：项目配置没有 dev 脚本，不能把 npm run dev 当成可用命令</p>

发送范围明确的修改请求

确认项目现状后，再发送修改请求。下面的写法同时限定了目标文件、禁止事项和验收方式：

请只修改 README.md。

在“开发”这一节补充项目当前实际可用的命令，以 package.json 的配置为准。

限制：
- 不修改 package.json 和其他文件；
- 不新增依赖；
- 不调整现有标题层级；
- 不运行会修改数据或删除文件的命令。

如果发现我要求的命令不存在，请先说明，不要自行修改配置。
修改完成后先告诉我改了什么，并展示 diff，等我确认后再验证。

看到 Codex 请求写入文件或执行命令时，只批准与这次任务直接相关的操作。如果请求扩大到删除目录、覆盖大量文件或安装依赖，先停止并重新确认范围。

<p align="center">图四：再次强调只修改 README，避免任务范围扩大</p>

查看修改摘要和 diff

Codex 完成编辑后，先看它的摘要，再打开编辑器的 Changes 面板。示例中最终只增加了 npm test，没有修改 package.json 或其他文件。

<p align="center">图五：修改摘要应说明文件、内容和依据</p>

还可以让 Codex 只审查本次修改：

请只审查刚才的改动：列出修改文件、每处修改的目的，以及是否违反了“只改 README.md”的限制。不要继续编辑。

重点检查三件事：

1. 修改文件是否只有预期文件；
2. 命令是否来自项目实际配置；
3. 是否混入格式化、重命名或无关内容。

<p align="center">图六：通过 diff 确认新增内容和未改动内容</p>

如果项目已经有其他未提交修改，不要直接恢复整个文件。先区分哪些内容属于本次任务，再决定是否撤销。

做最小验证

diff 看起来正确后，再验证命令确实存在并运行项目已有的测试：

请读取 package.json，确认 README.md 中写入的命令与项目配置一致。

确认没有问题后，只运行项目已有的测试命令 npm test。
不要安装依赖，不要修改配置，不要清理缓存。

请报告实际执行的命令、测试结果和当前 Git 状态。

示例项目的测试输出为 README check passed，退出码为 0。这说明本次 README 修改没有破坏已有检查。

<p align="center">图七：运行项目已有测试，确认结果可复现</p>

如果项目没有自动化测试，就做 Markdown、命令名称和 diff 的人工检查，并在记录中说明“未运行自动化测试”。不要为了验证一个小改动擅自升级依赖、清理缓存或修改项目配置。

最后检查 Git 状态

在终端中执行：

git diff --check
git status --short
git diff -- README.md

git diff --check 用来发现多余空格等基础问题；git status --short 确认没有意外改动；最后一条只查看目标文件的完整差异。

不符合预期时如何回退

发现修改超出范围或内容不对时，优先使用编辑器撤销，或者在确认目标文件没有其他人的改动后，精确恢复这次修改。不要删除整个项目目录，也不要把 git reset --hard 当作第一次练习的默认操作。

完成标准

• [ ] 目标文件和修改范围与任务描述一致；
• [ ] 已查看完整 diff，没有无关格式化或敏感信息；
• [ ] 已运行项目提供的最小检查，或记录了未运行原因；
• [ ] git diff --check 通过，工作区状态符合预期；
• [ ] 知道如何只撤销本次修改。

第一次修改的重点不是让 Codex 一次做很多事，而是建立一套可重复的节奏：描述目标，批准操作，检查 diff，运行验证，确认状态。后面的开发、修 Bug 和文档更新，都可以沿用这套流程。

接下来可以进入 核心概念与任务方法 和 项目理解与上下文，继续学习任务拆分与项目规则。