本篇会做出一条可以直接发送的 Codex 提示。它只处理一个小任务，写清允许改动的内容，并要求 Codex 交付可复查的结果。发送以后，你能从回复中判断它有没有理解目标，随后决定让它继续还是补一句说明。
前置条件
先进入正确的本地项目或工作区，选一份容易检查的文件。第一次练习可以改一段说明文字、补一个标题，或让 Codex 解释一个函数。暂时避开账号、支付、线上配置和大批量文件。
你还要知道怎样确认结果。文字可以对照原稿，代码可以运行已有测试，页面可以打开指定路由。验收方法越具体，任务结束时越容易判断。
第一步写出看得见的结果
先写希望得到的结果，别从操作步骤起笔。初学者可以沿用下面这个例子。
请只修改
src/content/about.md的第一段，把产品名称统一为 CodexNav。保留段落原意和其余文件。完成后列出修改位置，并说明我该怎样核对。
这条提示里有目标、文件范围、保留项和验收要求。发送前读一遍，确认文件路径存在，产品名称拼写准确。可见结果是一条范围明确、没有“顺便优化全部内容”的任务。
第二步只补会改变结果的上下文
如果文件名还不足以说明要求，再补一两句背景。可以写目标读者、必须沿用的术语，或一条不能破坏的行为。图片和文件也能成为上下文，但要说明 Codex 应该看哪里、从中得到什么。
边界只留眼下最重要的一两条。比如“不要改标题”和“不要创建新文件”。把十几条预防性规则塞进第一次提示，读者自己也很难检查。
第三步让回复先落到范围上
任务很小，可以直接发送。你仍然可以要求 Codex 在修改前复述目标和预计改动的文件。看到它只提到 src/content/about.md，名称也写对了，说明当前理解可继续。若回复出现额外页面、重构或依赖更新，马上纠正范围。
后续消息宜指向一个具体偏差。可以写“保留标题，只调整第一段名称”。这比重新发送一条更模糊的“再优化一下”更容易得到稳定结果。
把一条模糊请求改到能验收
假设原话只有“帮我优化首页文案”。先问自己完成后要打开哪里，看见什么。可以把它改成下面这条。
请只改首页第一段，让第一次来访的人能在读完后知道 CodexNav 提供中文 Codex 教程。正文控制在九十到一百二十个汉字，保留现有标题、按钮文字和链接。完成后展示修改前后内容，并确认没有改其他文件。
发送前逐项检查。首页第一段给出了位置，读者理解产品给出了结果，字数和保留项限制了范围，前后对照和文件清单提供了验收证据。Codex 回复时若能先复述这四项，你就有了继续的依据。它若把“优化”理解成重写整个页面，此时纠正成本还很低。
这个练习也能暴露缺失信息。项目里可能有多个首页，或页面文字来自翻译文件。路径不确定时，把编辑改成先查找候选位置并等你确认。确认文件以后，再发完整任务，避免让一个猜测直接变成修改。
输出形式也会影响验收。若你只想先看方案，就写“先给建议，暂时不要改文件”。若已经允许修改，就要求汇报动过的文件和运行过的检查。两种结果都很清楚，但授权范围不同。发送前把这句话放在结尾，能减少 Codex 在讨论和执行之间作错误判断。
常见失败与恢复
提示只有“帮我优化”时，先暂停并补上文件、结果和保留项。路径写错时，让 Codex 先查找候选文件，确认以后再编辑。任务开始扩大时，明确要求停止新增工作，列出已经动过的文件，再决定保留或撤回。
遇到权限请求，先看命令会访问哪里。目标只是改一份本地文档，却申请网络或项目外写入时，应拒绝并让它改用当前工作区内的做法。
完成检查
发送前确认提示里有一个结果、一份上下文、一两条边界和一种验收办法。发送后确认 Codex 复述的文件与目标一致。任务结束时，你还应能亲自打开文件或运行检查，得到与要求相符的证据。
