计划确认之后才动代码。最容易出问题的地方是一次性让它全部实现，页面和样式一起动。最后项目看起来变了，你却判断不出哪里出了岔子。更稳的方式是一次只改一个功能点，改完就检查一段。
一次只改一个功能点
比如优化首页，不要一次性说优化整个首页，可以拆成几步。
步骤修改内容第一步只优化首屏标题和副标题第二步只[……]标签： 代码审查
第一次让 Codex 改代码：任务怎么挑，流程怎么走
装好 CLI 之后，别急着找个大项目练手。挑一个小、能验证、出错也好回滚的活，先把协作节奏跑顺。
第一个任务怎么挑
判断标准很直白，这个活的范围小到你自己都能验。修一个错别字，给一个纯函数补测试，把 README 里过期的命令改掉，这些都很合适。给一个小模块补上注释，或者修一个已经有失败测试覆盖的[……]
怎么判断 Codex 真做完了，而不是看起来做完了
交出去的任务，最怕的结果不是失败，是它说做完了，你信了，上线才发现没做完。一套稳定的执行流程能把这种坑堵住。
一轮完整的任务要六步
顺序大概是这样：把任务写清楚，让它先建图，小步执行，检查 diff，跑验证，记录结果。少了哪一步都容易出问题。
第一步，任务写清楚
目标，背景，范围，验证和交付这五样别[……]
