夜雨聆风第一次让 CodexApp 改代码，不要选一个“顺便重构一下项目”的任务。
选一个小功能。
小到你不用相信它，也能自己看懂它到底改了什么。
这句话有点反效率。
很多人第一次用 AI 编程工具，恨不得立刻丢一个大需求进去：把登录流程优化一下，把整个页面改漂亮一点，把这个项目重构一下。
我不建议。
不是因为 Codex 做不了复杂任务，而是因为你还没建立校准。你不知道它会怎么读仓库，怎么决定改哪些文件，怎么处理测试失败，怎么解释自己做过的事。
第一次先练闭环。
不是练肌肉。
第一步，挑一个低风险小任务
我建议第一单任务满足三个条件。
第一，范围小。最好只涉及一个组件、一个函数、一个配置项，最多两三个文件。
第二，结果可见。比如文案变化、按钮禁用态、空状态提示、一个小测试补充。你能一眼看出它有没有做对。
第三，失败可回退。就算它改错了，你也能在 diff 里直接 revert ，不会牵出一串数据库、权限、部署和外部服务。
举个很普通的例子：
“把设置页在没有 APIKey 时的提示文案改得更清楚，并补一个对应的空状态测试。”
这就比“优化设置页体验”好得多。
后者像愿望。
前者像任务。
普通开发者第一次用 CodexApp ，最需要的不是被震撼，是知道自己还握着方向盘。
第二步，给它三句话就够
新手写第一条任务，不需要长篇大论。
但必须有三句话。
第一句写目标：你到底想让它改成什么。
第二句写边界：哪些文件或模块可以动，哪些不要动。
第三句写验证：做完后跑什么命令，或者如果没有自动测试，怎么手动检查。
比如你可以这样写：
请把设置页没有APIKey时的空状态文案改得更清楚，只改settings相关组件和测试，不要改API层。
完成后运行npm test -- settings，如果没有对应测试，说明原因并给出手动验证步骤。
如果发现需要改认证逻辑，先停下来问我。
这不是 prompt 技巧。
这是工作交代。
官方的 Codex prompting 文档也强调， Codex 在能验证工作时输出质量更高，复杂工作应该拆成更小、更聚焦的步骤。
我特别认同这一点。
因为 AI 最容易放大的，不是你的效率，而是你的含糊。
你说“优化一下”，它就会认真猜什么叫优化。
猜对了你觉得神。
猜错了你说它不靠谱。
这不公平。
先把任务说成任务。
第三步，看执行，不要只看回答
Codex 开始工作以后，新手最容易犯的错是一直盯着聊天内容。
它说“我会先检查相关文件”，你觉得不错。
它说“我已经完成修改”，你松一口气。
但真正该看的不是它说了什么，而是它做了什么。
看 terminal 。
它跑了哪些命令？命令过了吗？有没有失败后绕过去？如果测试失败，它是修了失败原因，还是换了一个更宽松的判断？
再看 diff 。
改动是不是集中在你允许的范围？有没有顺手格式化一堆不相关文件？有没有把一个小文案改动变成架构调整？
这一步有点像带新人。
你不需要怀疑他每一个动作，但第一周你肯定会看 commit 。不是不信任人，是要建立团队习惯。
Codex 也是这样。
它不是一次性答案机器，它是会改你仓库的执行者。
执行者就必须留痕。
Local 先够了，别急着上 Worktree
CodexApp 有 Local 、 Worktree 和 Cloud 这些模式。
第一次我建议用 Local 。
理由很简单：你最熟悉本地项目。依赖装好了，测试命令知道，出了问题也能立刻打开编辑器看。
Worktree 很好，官方文档里也说它适合隔离变化、并行跑独立任务。等你开始让 Codex 同时尝试两个方案，或者你不想干扰当前工作区时， Worktree 就很有用。
但第一天先别把工具链复杂度叠满。
你还没学会看 diff ，就先开三个 worktree ，并不会更专业。
它只会让你不知道该相信哪一份改动。
先在 Local 里完成一单小任务。
确认你能看懂过程，再把更大的任务放到 Worktree 里隔离。
这不是保守。
这是学习顺序。
如果没有测试，也要留下验证路径
很多个人项目没有完整测试。
这很正常。
别因为没有测试，就把验证这一步跳掉。
你可以让 Codex 做两件事。
第一，让它说明这次改动应该怎么手动验。
比如打开哪个页面，点哪个按钮，输入什么内容，预期看到什么提示。这个步骤越具体越好，不要写成“手动检查页面是否正常”这种废话。
第二，让它说明没跑自动测试的原因。
是项目没有测试脚本，还是这次改动没有覆盖到测试，还是依赖没装好，还是命令失败了？
这几种情况完全不同。
我不怕它说“没有验证”。
我怕它含糊地说“已验证”，但你不知道验证了什么。
如果你愿意再进一步，可以让 Codex 顺手补一个很小的测试。不要一上来追求完整测试体系。只补这次任务对应的一条断言就够。
比如空状态文案改了，就检查文案是否出现。
按钮 loading 改了，就检查点击后按钮是否禁用。
这类测试小，但它能把“我看起来没问题”变成“以后别人改坏时会报警”。
这就是小任务的额外价值。
它不只是让你试用 Codex 。
它还逼你把项目里一个模糊角落补上一点证据。
这也会反过来改善你自己的工程习惯。
以前你可能觉得“这个小地方没必要测”，但当你开始把任务交给 AI 做，你会突然发现，没有测试不是 AI 的问题，是你没有给协作留下抓手。
你可以不追求完美覆盖率。
但每次让 Codex 动一个小地方，就顺手留下一个小证据。
几次以后，项目会变得更适合 AI ，也更适合人类自己维护。
这是我觉得新手练小任务最值钱的地方。
它不是一次演示。
它是在给后面的自动化铺地板。
完成以后，做一个很小的复盘
第一单任务结束时，不要急着开第二单。
停 30 秒，看三件事。
第一，任务描述里有没有哪句话帮你避免了跑偏。
第二， Codex 有没有改到你没想到的文件。
第三，验证命令是不是真的证明了结果。
如果三件事都清楚，这次就是成功的。
哪怕它只改了两行代码。
因为你已经掌握了第一次闭环：交代边界、让它执行、审查证据。
AI 编程不是从“它一次写了多少代码”开始的。
对普通开发者来说，它从一个更小的瞬间开始：你发现自己可以把一件小事交出去，但仍然知道发生了什么。
这才是安全感。
先练这个。
