06 · 第一个任务：从启动到检查修改

用最小案例走完一次完整流程：进入项目、授权、描述任务、审查差异、运行验证。

学再多的概念，都不如亲手跑一次。这一篇我们用一个最小案例，把 Codex 的完整流程走一遍。

第一步是「进入项目」。Codex 需要在一个工作目录里运行，因为它要读这个目录下的文件、并把改动写回这个目录。所以先找一个你熟悉的、不重要的项目目录（或者新建一个空目录），再启动它。

第二步是「授权工作区」。首次在一个目录里运行时，它会问你是否信任这个目录、允许它读写。这是安全机制在起作用，确认无误后放行即可。

第三步是「描述任务」。这是最关键的一步。别只说「帮我改一下」，而要讲清楚三件事：你想达成什么目标、它应该关注哪些文件、以及做完之后你希望看到什么结果。任务描述得越具体，它返工的概率越低。

第四步是「审查差异」。它做完之后，先别急着提交。用 diff 之类的工具，逐条看它到底改了哪些地方。这是你最后一道质量关，也是建立信任的过程——好的用法是「它干、你审」。

第五步是「运行验证」。看它改得对不对，最可靠的办法是真正跑起来：跑测试、跑构建、或者手动点一遍。只有验证通过，这次任务才算真正完成。

这一整套「进目录—授权—说任务—审差异—跑验证」的闭环，就是后面所有复杂工作流的母版。你现在跑通的是一个最小版本，但它每一步都在，缺一不可。

如果中途它停下来问你问题，别烦，那通常是它在做有风险的动作前需要你拍板。你可以选择批准、拒绝，或者补充说明。这恰恰说明安全机制在正常工作。

几个常见陷阱：第一次用 Codex 时，新手最容易犯的错是「任务描述太模糊」（如「帮我优化代码」），让它返工；第二是「没有验证就提交」（让 AI 改完直接 commit，错都不知道错在哪）；第三是「权限设太大」（一次性让它能改所有文件，结果它误删了别的）。

提效技巧：第一次跑任务时，**故意选一个不重要的项目来试**——就算它把代码改崩了也不心疼。等你熟练了再用真实项目。这是一种「零压力练习」。

常见误区：很多新手会把这一篇讲的「基本规则」当成「教条」——什么都严格遵守。其实这些规则的核心是「降低风险、提高效率」，理解了动机，规则就自然内化了，不用死记硬背。

动手试一下：你可以花 5 分钟做一个最小验证——找一个真实的代码任务，让 Codex 跑一遍，看它的行为是不是和这一篇描述的一致。理论与实践对照，才知道「懂」和「会用」是两件事。

与其他篇的关系：这一篇是本组的基础。如果你跳过了前面几篇，建议先回去看，否则这里有些概念可能看着突兀。如果都看过了，那你可以直接进入更后面的实战环节，把这里学到的东西用上。

判断决策树：用三个问题判断该不该用——① 这件事值不值得用 Codex 做？② 用的话该用哪个入口？③ 风险高不高需不需要审批？三个问题的答案一出来，怎么做就清楚了。