单次对话只允许一个可验证交付物，需用四步隔离法拆分任务：①遇混用注解等信号立即输入/stop；②新建对话仅保留单一子目标；③补全技术栈、路径、禁止项；④执行/plan并验证每步。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当你在Codex中同时处理接口改造、数据库字段新增、前端联动和测试覆盖时，对话窗口会迅速堆积大量上下文碎片，导致后续生成偏离原始约束、API路径写错、SQL类型不匹配——这不是模型能力问题，而是单线程承载了不该并行的任务。
识别必须拆分的信号
出现以下任意一种情况，立即停手，不要继续输入新指令：
① 你刚让Codex改完Controller，又顺手加了一句“顺便把Mapper.xml里对应的SQL也更新下”；
② Codex返回的代码片段里开始混用两种事务注解（@Transactional 和 @Transaction），且未说明原因；
③ 你发现自己在回复Codex时反复强调“别动User实体类”“不要碰auth模块”，但下一轮输出仍出现了对User.java的修改建议。
【单次对话只允许存在一个可验证交付物】例如：“生成 /api/v1/orders/{id}/status 接口的 PUT 实现”是合格任务；“优化订单模块”不是。
通过本地 Codex 或 OpenClaw OAuth 凭证直接调用 ChatGPT/Codex Responses 的 image_generation 工具来生成或编辑光栅图像，然后保存
执行四步隔离法
第一步：在当前对话顶部输入 /stop，强制终止主代理正在构建的上下文链；
第二步：新建空白对话窗口，粘贴原始需求全文，但只保留其中一项可独立验证的子目标；
第三步：在新对话中补全三项硬信息——技术栈（如 Spring Boot 3.3 + PostgreSQL 15）、关键文件路径（如 @src/main/java/com/example/order/controller/OrderController.java）、禁止项（如“禁止新增任何DTO类”）；
第四步：输入 /plan → 等待Codex提出澄清问题 → 仅回答与当前子目标直接相关的问题 → 确认计划步骤中每个 step 结尾都带 curl 或 junit 断言类可验证动作。
子任务命名与归档规则
方法一：按交付物类型+模块缩写命名
例：【API-ORD-STATUS-PUT】、【SQL-ORD-ADD-CANCELLED_AT】、【TEST-ORD-SERVICE-UNIT】；
方法二：用时间戳+语义关键词组合
例：20260618-ord-status-api、20260618-ord-cancelled-sql；
方法三：绑定Git分支前缀（推荐团队协作时使用）
例：feat/ord-status-api、chore/ord-sql-migration。
所有子任务对话关闭前，必须将最终生成的代码块、验证命令、失败日志截图三者合并为一段Markdown文本，粘贴到项目根目录下的 TASK_LOG.md 文件对应章节。这一步不可跳过，否则下次打开Codex时无法自动关联上下文。
