任务执行：跟进、审查与验证结果

任务完成需要对应目标的证据。文件已写入、构建通过、推送成功和页面上线是不同状态，不能用一句“完成了”互相替代。

先核对当前材料与工作状态

开始前确认项目、工作目录和现有改动。对于本仓库，正文在 content/，不是旧版教程里的 docs/start/。需要修改内容时，还应按项目约定验证生成数据与构建。

请先读取项目约定，检查当前工作区是否有尚未提交的改动。
本轮只处理 content/start/06-first-task.md 的下一步入口。
保护已有改动；如果目标已经满足，直接提供核对证据。
如需修改，按仓库约定验证正文、生成内容和页面链接。

执行中补充信息：纠偏还是排队

官方文档区分两种跟进方式：

方式	用途	适合的消息
Steer	把信息加入当前执行	“刚确认目标是移动端，请把窄屏作为本轮验收条件。”
Queue	留待下一轮处理	“当前任务完成后，再检查另一篇文章。”

桌面应用可在 Settings → General → Follow-up behavior 查看默认行为及切换方式。不要仅凭“消息发出去了”就认为当前任务已经按新要求执行；查看运行中的回应和后续结果。官方说明

纠偏时说明变化及仍需保留的目标；如果希望立即停止当前工作，要明确说“停止当前任务”，而不是仅发送一个看似后续事项的问题。

审查 diff，而不只读总结

检查改了哪些文件、是否涉及无关配置、正文和链接是否符合目标。任务生成的文件也应打开阅读；仅有文件名不代表内容正确。

Git 项目可以使用桌面审查面板检查差异。在 Codex 输入 /review，可选择审查未提交改动或与基准分支比较；官方说明这会报告问题，不直接修改工作树。该入口需要 Git 仓库。官方代码审查

自动审查是补充证据，不能替代对应功能的验证。发现问题后，可以要求解释影响和最小修复，而不是无条件接受所有建议。

根据目标选择验证

目标	应取得的证据
本仓库内容修改	Lint、构建、生成内容差异和页面正文
修复链接	渲染后的实际目标可访问；不是只搜索源 .md 路径
修复交互问题	在复现条件下观察行为，必要时增加覆盖失败场景的测试
配置修改	相关配置加载与最小运行结果，避免只检查语法
发布更新	本次提交 SHA、CI、部署状态，以及线上对应新正文或行为

本仓库内容修改需要运行：

npm run lint
npm run build

构建通过之后，再查看 lib/generated-content.json 是否只包含本轮预期变化，并打开相关页面检查。其他项目应使用其自己的验证命令，不要照搬这里的脚本名称。

验证失败时继续定位

先保留错误，判断失败是否来自本次修改、原有缺陷、运行环境或外部服务。与任务有关且在已授权范围内的环境问题也可以修复，不能简单规定“只有本次代码导致的错误才处理”。

请说明验证失败的直接证据、影响和最小处理方案。
能在当前任务范围内修复的继续处理；不要覆盖已有工作或扩大无关改动。
若仍无法验证，明确列出已经完成的部分、未通过的检查和阻塞原因。

超时、403 或服务暂不可用，应单独记录并有限重试。若一次推送或发布的结果不确定，先核对远端状态，避免重复执行。不要把失败命令替换为更容易成功的检查后声称原目标已经通过。

用明确状态交付

• 已完成并验证：目标满足，相应检查已通过，附上可核对结果。
• 已修改，尚未验证：有成果，但缺少必要检查，说明仍需做什么。
• 受阻或验证失败：保留已完成部分和错误证据，说明下一步。

“失败原因已记录”不能使一个尚未通过验收的功能变成已完成。若任务只要求分析，则一份证据充分的分析即可完成，无需为了交付而修改代码。

交付时用一段话说明改了什么、验证了什么、还有什么未确认。可以继续内容贡献练习，或进入手机端跟进桌面任务。