很多任务效果不稳定，并不是模型不会写代码，而是开始时没有定义“做到什么程度才算完成”。完整闭环的价值，在于把想法转换成一组可以依次确认的事实。
一、先描述完成后的状态
不要只写“优化首页”或“修一下登录”。更有效的描述是：用户在手机端打开首页时，推荐文章以单列卡片展示；后台隐藏文章后，首页不再出现；现有课程和会员区域保持不变。
这类表达直接描述用户能看到的结果，后续才有明确的验收标准。
二、补足必要上下文
上下文不是越多越好，而是要覆盖决策所需的信息。通常包括技术框架、相关入口、现有交互、不能改变的业务规则，以及是否允许修改数据库或配置。
如果不确定入口，可以先让 Codex 搜索并汇报；确认理解一致后，再授权它修改。
三、明确范围和停止条件
- 允许修改哪些目录、表或页面；
- 必须复用哪些现有组件和视觉规范；
- 哪些数据或功能不能触碰；
- 遇到缺少密钥、权限或业务选择时应停止并说明。
范围不是限制创造力，而是减少无关改动，让审查更快、更可靠。
四、边执行边留下证据
高质量的过程应当能回答：改了什么、为什么这样改、怎样验证。对于普通页面，可以结合语法检查、接口响应、关键文案断言和浏览器操作；对于订单、权限等高风险功能，还应增加数据一致性与异常路径测试。
五、用验收标准结束任务
验收不要停在“测试通过”。应逐条对应最初目标，并说明实际证据。例如：后台发布文章后列表可见；首页只读取已发布且推荐的文章；分类链接与详情链接均返回成功；移动端宽度下卡片变为单列。
一个可复用的任务模板
- 目标：完成后用户能看到或做到什么。
- 背景：相关业务和当前状态是什么。
- 范围：允许改什么，不允许改什么。
- 要求：交互、样式、兼容性和安全约束。
- 验收：必须通过哪些检查和真实场景。
长期使用这套结构，你会发现任务返工减少了，代码审查也更聚焦。真正提高效率的不是一次生成更多代码，而是更少走错方向。
四阶验收工作流：让每次交付都经得起回溯
怎样看懂 Codex 的 Diff：确认改动没有越界