Codex 下不同场景 模式选择

建议你默认这样选：小改动直接执行；需求和影响范围不明确时先计划；需要反复排查、修复、验证的长任务用目标模式。复杂功能可以先计划，确认后再用目标模式执行。

不要每个 bug 都先审批方案，也不要把复杂功能只描述一句就交给 AI 自由发挥。

对比项	直接描述，让 AI 实现	计划模式，确认后执行	目标模式
主要解决什么	完成一次明确任务	先确定需求和实现路径	持续推进到满足完成条件
工作方式	读代码 → 修改 → 验证 → 汇报	调研 → 澄清 → 提交方案 → 确认后实施	执行 → 检查结果 → 调整 → 继续
你需要参与多少	少，主要验收结果	前期较多，需要确认关键取舍	前期定义目标，过程中处理重要阻塞
适合的任务	局部 bug、小功能、明确修改	业务规则不清、跨模块、架构调整	疑难 bug、性能优化、批量迁移
主要风险	AI 误解需求后直接改错方向	方案看起来完整，但未经运行验证	验收条件模糊时，可能持续做无效尝试
时间与消耗	通常较少	多一轮调研和确认，但可能减少返工	取决于迭代次数，需要控制范围与预算

这里的产品区别是：计划模式确定"怎么做"，目标模式定义"做到什么程度才结束" 。官方也建议，风险较大的长任务可以先计划，再把认可的结果设为目标。官方工作流说明

改 bug 时怎么选

关键看两个问题：能否稳定复现？修复会影响多少业务？

情况	建议	原因
某字段为空时报错，步骤明确	直接执行	范围小，可以用复现和回归验证
某接口与 PHP 返回字段类型不一致	直接执行	有明确的对照基线
偶发重复提交、并发数据异常	目标模式	通常需要多轮取证和验证
登录失效，涉及前端、后端、缓存	先诊断，必要时计划，再执行	原因和影响范围都不确定
修复涉及权限规则、订单状态、历史数据	先计划确认	技术修改背后有业务取舍

普通 bug 不必让 AI 先猜一份修复方案。 更有效的是让它先复现、追踪调用链、拿到根因证据；只有发现需要调整业务规则或扩大范围时，才停下来确认。

做新功能时怎么选

情况	建议
已有列表增加筛选项，规则明确	直接执行
按现有模式新增一个 CRUD 接口	直接执行，明确字段和验收条件
新增导出功能，但数据范围、权限、格式没定	先计划确认
新增审批流、角色权限、支付流程	先计划确认，再执行
完整模块包含前端、接口、数据库、联调	计划确认后，用目标模式持续交付
批量迁移多个接口，要求双端结果一致	明确批次和验收标准后，用目标模式

是否先确认，主要取决于业务决策是否明确；是否用目标模式，主要取决于是否需要持续迭代。

目标模式适合有明确终点、实现路径需要逐步探索的任务。普通提示也可以完成完整开发和测试；目标模式增加的是跨轮次持续追踪和推进的机制，并不会自动保证代码质量。官方 Goals 说明

结合你这个 PHP → FastAPI 项目，我建议采用下面三种表达。

① 日常 bug：直接修复，把需要确认的边界写清楚。

修复这个问题：［现象、复现步骤、预期结果］。

先查看相关代码和日志，尽量复现并定位根因，再做最小必要修改，补充对应回归测试并实际验证。

遵守项目 AGENTS.md。涉及 PHP 迁移兼容时，以 PHP 行为为基线，检查状态码、字段类型和空值处理。

如果修复需要改变业务规则、数据库结构或公共接口，先说明依据、影响及建议方案，等我确认；其余情况直接完成。

② 新功能：先让方案建立在真实代码上，再确认业务取舍。

我要新增：［功能描述］。

先读取现有实现和相关调用链，暂不修改业务代码。提交方案，包含：

1. 你理解的业务规则及需要我决定的问题。
2. 用户操作流程、接口和数据变更。
3. 可以复用的现有模块及预计修改范围。
4. 兼容性影响、验收场景和回滚方式。

推荐一个方案，并说明关键取舍。等我确认后再实施。

③ 长任务：批准方案后，用明确的完成条件持续推进。

按已确认方案，以目标模式推进：［具体目标］。

完成标准：

• ［可观察的功能结果］。
• ［必须通过的测试或接口对比］。
• ［必须保持的兼容性约束］。

在约定范围内持续完成实现、验证和问题修复。验证失败时，根据证据调整后继续；不能只凭代码已修改就宣布完成。

遇到需要新增业务决策、扩大修改范围或缺少必要环境与权限时，说明具体阻塞并等待我处理。最终汇报完成内容、验证证据和剩余问题。

你确认方案时，重点看 业务规则是否正确、修改范围是否合理、验收是否充分。具体改哪几行代码可以交给 AI；最终仍要用实际测试和页面、接口结果验收。