计划确认之后才动代码。最容易出问题的地方是一次性让它全部实现，页面和样式一起动。最后项目看起来变了，你却判断不出哪里出了岔子。更稳的方式是一次只改一个功能点，改完就检查一段。

一次只改一个功能点

比如优化首页，不要一次性说优化整个首页，可以拆成几步。

步骤	修改内容
第一步	只优化首屏标题和副标题
第二步	只调整 CTA 按钮
第三步	只优化移动端布局
第四步	只补充产品卖点卡片

每一步都很清楚，出问题也好定位。改完一段就停下来，让它汇报这次改了哪些文件，每个文件改了什么。有没有改到计划外，有没有潜在风险，也要一并说清。

别让它顺手重构无关代码

它有时会觉得某些代码不够优雅，顺手帮你重构，这在真实项目里很危险。

顺手操作	可能的问题
重命名组件	引用路径出错
拆分文件	维护成本增加
改全局样式	影响其他页面
升级依赖	引发兼容问题
删除它认为无用的代码	可能删掉真实业务逻辑

提示词里要写清楚，本次只实现当前功能点。不要顺手重构无关代码，不要改命名和目录结构，也不要动依赖版本。它如果发现某段代码可以优化，先记录成建议，不要直接改。

改得太多就先停

一次性改了很多文件又没解释清楚，就该暂停。

情况	处理方式
改动文件突然很多	要求解释每个文件为什么改
删除大量代码	要求说明删除原因
新增不认识的依赖	要求说明必要性
改了和需求无关的页面	要求回退无关修改

遇到关键的不确定也要停下来问。不确定该改哪个文件，不确定业务规则，不确定能不能删旧代码，这几种都先问清楚。不要让它自行决定。

它说完成了不代表真跑通

测试按从快到慢的顺序走。

类型	作用	重点
单元测试	检查函数和模块是否正常	失败先说明原因，不要直接改代码
类型检查	提前发现类型错误	没有这条命令就明确说明
lint	检查代码规范问题	区分本次新增问题和项目原有问题
构建	本地能打开不代表能上线，构建才算能打包	失败先总结报错和影响范围
手动测试	UI，表单，登录这类必须点一遍	按用户操作路径逐步验证
浏览器测试	终端看不出的页面和控制台问题	看页面显示和 Console 报错，也看移动端
回归测试	测旧功能有没有被改坏	列出本次修改可能影响的旧页面

两个地方最容易漏。老项目本身就有 lint 或者类型问题，不要让 Codex 把历史问题一起顺手重构。回归测试是最容易被忽略的一步，改了一个首页按钮，也可能影响复用同一组件的其他页面。

审查要走两轮

测试过了不等于可以交付。改得对不对，稳不稳，有没有风险，这几件事还要再看一遍。它写代码快，但也容易出事。功能能跑但逻辑不对，改动范围超出需求，这些都很常见。

第一轮让它自审刚才的修改，输出成表格。有没有改到计划外文件，有没有新增依赖，有没有误删旧逻辑，这几项都要写清楚。目的是让它先暴露明显问题。

第二轮是人工审查。最终交付的人是你，不要求每行都看懂，但 diff 里这几处要看清楚。文件范围是不是只动了该动的地方，修改和删除的内容符不符合计划，命名和结构跟原项目是否一致，都要过一遍。

涉及登录和支付这类重要代码，可以再用第二个模型交叉审一遍。它的意见同样不能全盘接受，决定权还在你手里。

四类问题重点盯

类别	常见问题	审查要点
边界条件	正常输入能用，异常输入就崩	空数据，接口失败和权限不足
安全问题	涉及用户，接口和支付的地方	有没有暴露密钥，权限判断有没有缺失
误删	看似没用实际有用的代码被删	重点看 diff 的删除内容
业务逻辑	代码能跑但逻辑错	正常路径和异常路径都要走一遍

看到大段删除又没解释清楚，不要直接接受。

这几步都过了，这次修改才算具备交付的资格。