装好 CLI 之后，别急着找个大项目练手。挑一个小、能验证、出错也好回滚的活，先把协作节奏跑顺。
第一个任务怎么挑
判断标准很直白，这个活的范围小到你自己都能验。修一个错别字，给一个纯函数补测试，把 README 里过期的命令改掉，这些都很合适。给一个小模块补上注释，或者修一个已经有失败测试覆盖的 bug，同样能拿来练手。
反过来，有几个方向第一次别碰。大规模架构重构先放着，跨多个服务的迁移也一样。没有测试的核心业务改动别碰。涉及生产凭据和账单的操作，要删数据的活，还有那种一改就是十几个文件的需求，这些一旦出错，你连从哪查都找不到。
先只读，不动手
让 Codex 理解仓库这一步不能省。给它一段只读指令，让它先把项目用途、关键目录和安装测试的构建命令梳理出来。然后再让它给两个建议：当前任务适合从哪开始，以及它建议你第一次交给它什么低风险任务。
它给的建议值不值得采纳，看一条就够了：有没有列出文件依据。凭感觉给的答案，后面多半要返工。
给它一个小任务，把要求写全
新手最容易犯的错是把要求写得太短。一句帮我修个 bug，它只能靠猜。有效的指令里应该包含几个意思。先跑测试确认失败信息，读相关代码和测试，但不做无关重构。只改最少必要的文件，改完重新跑一遍相关测试。最后总结失败原因，说清改了哪些文件、用什么命令验证、还剩哪些风险。
文档类的活要求不一样。要它先读官方资料和现有文档结构，保持中文教程的写法而不是整段翻译，涉及步骤的地方留截图占位。改完跑一遍文档站构建，最后列出来源链接和需要人工补图的位置。
过程中盯这五件事
它开始干活之后，有五件事值得看着。先看它有没有在读上下文，再看范围有没有失控。执行命令前有没有说明目的，改完之后有没有跑验证。没验证的部分，有没有如实说出来。
第一次任务不用追求它顺手重构。范围收得住，比效率高更要紧。
收工前看一遍 diff
改完先自己看一遍 git diff。也可以让它自查，指令是请 review 你刚才的改动，不要继续修改文件。重点看有没有无关改动和漏掉的测试，有没有引入安全和兼容风险，还有哪些地方没验证。
提交前让它给一段摘要
满意的改动，提交前让它给一段摘要。改动目标写在最前面，接着是改了哪些文件和验证命令，再写清验证结果和剩余风险，最后附一条建议的 commit message。核对没问题再提交。
第一次翻车了怎么处理
改动太大，让它停下，只保留最小修复思路。测试跑不起来，先让它解释环境缺口和命令来源。方向不对，退回只读分析，让它列出文件依据。输出太泛，要求按文件，命令，风险分段说。误改了无关文件，用 git diff 确认，再手动决定哪部分留下。
做完这一轮，你手上应该有
一个很小的 diff，一条能复现的验证命令，一段说得清楚的改动摘要，一个以后能接着用的任务模板。还有对 Codex 权限和审批机制的初步感觉。
这几样都拿到了，才算真的跑通了一轮。
