一、先说结论
Codex用得好不好，提示词只占一部分。更重要的是形成一套稳定的使用习惯：
只想快速查阅？ 可直接阅读精简速查版。
本文统一案例：商城系统
为方便前后对照，文中的示例统一使用一个虚构商城系统。系统包含商品、营销、订单、库存、支付和通知服务，主要业务链路是“领取优惠券 -> 提交订单 -> 锁定库存 -> 支付 -> 发货 -> 取消/退款”。
- 先说结果，再补背景：告诉它要解决什么问题，以及什么状态才算完成
- 先确认理解，再讨论方案：让Codex复述需求，并列出不明确的地方
- 先分析，再改代码：复杂需求和线上问题不要一上来就让它修改
- 一次只处理一个可以验收的任务：任务太大时，Codex很容易顾前不顾后
- 给入口，不要一次塞完整个项目：指出关键文件、报错和调用入口，让它继续搜索关联代码
- 让测试和实际运行结果说话：不能只看Codex说“已经完成”
- 实现和审查尽量分开：写完后重新从
diff、调用方和异常路径检查一次 - 把重复踩坑变成项目规则：稳定规则写进
AGENTS.md，临时要求留在当前任务里
我比较推荐下面这条日常流程：
明确目标 -> 复述确认 -> 只读分析 -> 确认改动范围 -> 小步实现 -> 运行验证 -> 检查diff -> 总结风险
这套流程看起来比直接说“帮我实现一下”多了两步，但通常能少返工很多次。
二、提示词不用华丽，但要包含关键信息
1、把提示词当成一张开发任务单
不太建议只写：
修复订单重复支付的问题。这种描述虽然简单，但Codex需要自己猜测现象、入口、限制和验收方式。更实用的写法是：
目标：修复支付回调重复到达时，订单可能被重复记账的问题。
现象：同一个支付流水号连续回调两次，account_flow表会出现两条记录。
复现：使用docs/curl/pay-callback.sh连续请求两次即可复现。
入口：先从PayCallbackController开始跟踪调用链。
约束：
1. 不修改现有回调协议和返回结构。
2. 不做无关重构。
3. 需要考虑并发回调，而不只是串行重复请求。
完成标准：
1. 同一支付流水只能记账一次。
2. 重复回调仍返回成功，避免上游持续重试。
3. 补充能够复现问题并验证修复的测试。
先只读分析根因、影响范围和候选方案，不要修改文件。这里真正有用的不是固定格式，而是以下信息：
- 目标：最终要改变什么
- 现象：当前哪里不对
- 入口：从哪里开始查，减少无效搜索
- 限制：哪些行为和文件不能动
- 完成标准：怎样证明任务真的结束了
如果自己也不确定实现方案，就描述业务结果，不要提前替Codex指定技术方案。比如写“重复回调只能记账一次”，通常比直接要求“在这里加一个Redis锁”更好，因为后者可能掩盖数据库唯一约束、事务范围或幂等设计上的真正问题。
电商案例：支付回调重复记账
用户支付成功后，支付平台可能因为网络超时重复发送回调。需求应该描述为“同一支付流水只能记账一次，并且重复回调仍返回成功”，而不是直接要求“增加Redis锁”。Codex需要先检查数据库唯一约束、事务和现有幂等记录，再决定实现方式。
2、根据任务复杂度决定描述多少
不是所有任务都需要一大段提示词：
- 改一个错别字：直接说文件和位置即可
- 修一个可复现的小Bug：给现象、复现方式和完成标准
- 做跨模块需求：补充调用链、兼容要求、数据变化和验收用例
- 做线上问题分析：先要求只读排查，并区分事实、推测和待验证项
提示词的长度应该跟任务风险走，而不是越长越好。
电商案例：不同任务使用不同粒度
把商品详情页的“立即购买”改成“马上抢”只需要给出页面和文案；修复购物车金额计算需要提供复现商品、优惠规则和预期金额；新增“下单自动使用最优优惠券”则要补充营销、订单、退款和历史客户端的兼容要求。
3、怎么避免需求理解误差？
计划模式、补充说明和二次确认不是三选一，它们解决的问题不同：
- 补充说明：自己已经知道缺少哪些背景时，直接补充最快
- 复述和二次确认：不知道Codex有没有理解正确时，先让它说出自己的理解
- 计划模式：需求复杂、影响范围大，或者错误方向会产生较多返工时使用
我通常把“复述需求”作为默认动作，把“计划模式”留给复杂任务。一个改文案的小需求没有必要先生成完整计划，但也可以让Codex用一句话确认修改对象和预期结果；跨服务、数据库、消息、权限和资金相关需求，则适合先进入计划模式，把调用链、改动范围和风险一起确认。
可以在第一次提示词末尾加上：
先不要修改代码，请先复述你对需求的理解，并按下面的结构输出：
1. 要解决的问题和最终目标。
2. 当前行为与预期行为的差异。
3. 本次需要处理和明确不处理的范围。
4. 验收条件和需要覆盖的场景。
5. 已确认的事实。
6. 你当前做出的假设。
7. 仍然不明确、需要我确认的问题。
如果某个不明确点会影响业务行为、数据、接口兼容或改动范围，
不要自行选择，等我确认后再制定方案或修改代码。收到回复后，不需要重新解释整个需求，只补充它理解错误或仍不明确的部分。确认完成后，再让它输出实现计划或直接修改。
比较实用的处理顺序是：
- 先给基本信息：目标、现状、限制和完成标准
- 让Codex复述：检查它理解的对象、范围和结果是否一致
- 让Codex提问：把事实、假设和待确认项分开
- 按复杂度决定下一步：简单任务直接执行，复杂任务进入计划模式
- 实现中再次确认：如果代码与需求文档冲突，或者出现新的业务选择，暂停修改并询问
还可以补充正例和反例，减少文字本身的歧义。例如不要只说“订单关闭后不能退款”，而是同时说明“已支付后超时关闭是否允许退款”“部分退款后关闭如何处理”“管理员强制退款是否例外”。具体场景通常比继续增加抽象描述更有效。
判断标准很简单：如果只是少了一条已知信息，就直接补充；如果不确定Codex理解得对不对，就让它复述并提问；如果连改动范围、依赖关系和实现顺序都需要共同梳理，就使用计划模式。
电商案例：订单关闭后的退款规则
“订单关闭后不能退款”存在明显歧义。应先让Codex确认：未支付超时关闭、支付后人工关闭、部分退款后关闭以及管理员强制退款是否属于同一种情况。只有影响范围和状态流转都确认后，才进入计划模式设计改动。
三、怎么给Codex关联上下文？
1、当前任务只放“这次真正相关”的内容
我一般会优先提供下面几类信息：
- 需求单或故障现象
- 报错堆栈和关键日志
- 可以稳定复现的步骤
- 一个明确的代码入口
- 已知的接口、表结构或消息格式
- 不能改变的兼容行为
只要给出入口，Codex通常可以继续通过搜索找到调用方、实现类和测试。没有必要把几十个文件全部贴进提示词。
一个很好用的补充要求是：
以仓库中的实际代码和测试为准。请自行搜索调用方、相似实现和相关配置，不要只分析我提到的这个文件。它可以防止Codex把你提供的文件误认为全部影响范围。
电商案例：从订单入口向外查找
排查“优惠券已使用但订单创建失败”时，可以先提供
OrderCreateService和失败日志，但要求Codex继续搜索优惠券核销、库存预占、事务消息和补偿任务。只看订单服务，很可能会漏掉营销服务没有回滚券状态的问题。
2、长期规则写进项目，临时规则留在任务里
下面这些内容适合写进AGENTS.md：
- 项目怎么启动、构建和测试
- 目录分别负责什么
- 固定的代码规范和架构边界
- 哪些文件不能改
- 数据库、消息和接口的兼容要求
- 完成任务后必须执行哪些检查
下面这些内容不适合长期保留：
- “这次先不要修改数据库”
- “今天只分析问题，不提交代码”
- 某个临时需求的业务细节
- 已经过期的故障背景和排查结论
AGENTS.md更适合做项目地图，不适合写成项目百科全书。文档较多时，可以在里面告诉Codex去哪里找：
## 项目资料
- 系统边界：`docs/architecture.md`
- 数据库约定：`docs/database.md`
- 消息兼容规则：`docs/mq-contract.md`
- 测试说明：`docs/testing.md`电商案例：长期规则和临时要求分开
“库存扣减必须通过库存服务，订单服务不能直接更新库存表”是长期架构规则，适合写进项目
AGENTS.md；“本次灰度期间暂时保留旧库存接口”只属于当前需求，应该写在任务提示词里，灰度结束后不应继续影响后续任务。
3、不要迷信“上下文越多越准确”
一次性塞入大量无关日志、历史聊天和完整设计文档，反而容易让真正重要的限制被淹没。更好的习惯是：
- 先给任务和入口
- 让Codex列出还缺什么信息
- 再补充它确实需要的日志、文档或业务决定
如果一个对话已经混入多个无关需求，建议新开任务，并附上一段简短交接：当前目标、已确认结论、未完成项、关键文件和验证命令。
电商案例：按需补充上下文
分析库存超卖时，先给出秒杀接口、库存扣减入口和一条失败日志即可。Codex确认需要后，再补充Redis Lua脚本、数据库库存表和压测数据；不要一开始就把商品、支付、物流等所有设计文档都放进上下文。
4、重复问题怎么沉淀成统一规范？
如果多个任务反复出现同一种误判，每次都需要人工纠正，说明这条经验不应该继续留在人脑或聊天记录里。但也不要把所有内容都塞进一份全局规则，而是先判断它的适用范围：
| 内容 | 推荐位置 |
|---|---|
| 只适用于当前任务的限制 | 当前提示词 |
| 所有项目都适用的工作习惯 | ~/.codex/AGENTS.md |
| 当前项目的架构、命令和业务约束 | 项目根目录的AGENTS.md |
| 只适用于某个服务或目录的规则 | 对应目录下的AGENTS.md |
| 多个项目都会重复执行的分析步骤 | Skill |
| 能够通过程序判断对错的硬性要求 | 测试、脚本、CI或Hook |
可以把这套结构理解为：
~/.codex/AGENTS.md 所有项目通用习惯
项目/AGENTS.md 当前项目规则
项目/services/payment/AGENTS.md 支付服务规则
~/.agents/skills/change-risk-review/ 跨项目复用的审查流程
项目/scripts/check-payment-config.sh 可以自动判断的配置检查其中，AGENTS.md适合放简短、稳定的约束；Skill适合封装“先读什么、按什么步骤检查、最后怎么输出”这类完整流程；能够自动判断的要求最好交给脚本和CI，不能只依赖Codex记住一句话。
一个电商系统中的示例
电商案例：支付回调验签配置
商城测试环境使用支付平台的回调模拟器，不加载生产证书；线上环境则必须开启回调验签并配置证书。Codex如果每次都把“测试环境没有生产证书”报告为风险，就需要把这条业务规则沉淀下来。
这条规则不应该放进全局~/.codex/AGENTS.md，否则Codex处理非支付项目时也会携带一条无关规则。更合适的是放进services/payment/AGENTS.md：
## Code Review Rules
### 支付回调验签
- 线上环境必须开启支付回调验签并配置有效证书。
- 测试环境使用回调模拟器，缺少生产证书不视为风险。
- 新增支付渠道时，检查对应的线上验签开关和证书配置。如果多个项目都需要进行“配置风险审查”，可以再做一个通用的change-risk-review Skill，规定审查流程：
1. 先读取当前目录适用的AGENTS.md。
2. 确认配置所属环境以及该环境是否启用对应能力。
3. 区分明确缺陷、待验证风险和正常差异。
4. 只报告能够从代码、配置或项目规则中举证的问题。如果线上验签配置是否缺失可以由程序直接判断，还可以增加一个只检查线上配置的脚本并接入CI。最终形成三层保护：
- 服务
AGENTS.md负责告诉Codex正确的业务规则 - Skill负责统一审查步骤和输出格式
- CI负责阻止能够自动识别的错误进入主分支
写规则时，尽量包含四项内容：
触发条件：什么时候应用这条规则
正确行为：应该怎样处理
例外情况：哪些情况不算问题
验证方式：通过什么文件、命令或结果确认可以采用“同一个问题人工纠正两次就考虑沉淀”的习惯。沉淀前先判断它属于全局、项目、服务、流程还是自动检查，并定期删除已经过期或互相冲突的规则。修改AGENTS.md后应新开任务，让Codex重新读取最新内容。
电商案例：从人工纠正到自动拦截
第一次误报时补充支付服务规则；同类误报再次出现后，把环境识别步骤加入审查Skill；最后增加CI，只校验线上配置中验签开关和证书是否齐全。以后既不会重复误报，也不会漏掉真正的线上风险。
四、复杂任务先让它分析，不要急着改
对于新需求、线上故障、跨服务改造，我会先发一轮只读任务：
先不要修改代码。请完成下面的分析：
1. 画出从入口到数据落库/消息发送的实际调用链。
2. 说明当前行为和需求之间的差异。
3. 找出所有可能受影响的调用方、配置、表和消息。
4. 给出最小改动方案，并说明为什么选它。
5. 列出兼容性、并发、数据一致性、性能和回滚风险。
6. 列出准备修改的文件和需要补充的测试。
7. 不确定的地方单独列出，不要自行假设业务规则。这一步的价值不是让Codex写一份好看的方案，而是提前暴露三类问题：
- 它理解错了需求
- 它漏掉了调用方或数据链路
- 需求本身存在没有决定的业务规则
确认分析方向后，再让它按最小范围实现。这样即使最初方向有偏差，也只需要修改方案，不用先撤掉一大批代码。
电商案例：先分析库存超卖
收到“秒杀商品出现超卖”的反馈时，先让Codex只读梳理网关限流、Redis预扣、订单创建、数据库扣减和失败补偿链路。确认根因是补偿任务重复释放库存后，再修改幂等逻辑；如果直接让它“修复超卖”，很可能只在接口外层加锁，掩盖真正问题。
五、怎么让Codex分析Bug和风险？
1、不要只说“帮我Review一下”
只说“检查有没有问题”，很容易得到一堆命名、格式和抽象层次的建议。真正需要检查的是：这次改动在什么条件下会出错，出错后会影响谁。
可以直接使用下面的提示词：
请以代码审查的方式检查当前分支相对main的改动。
重点检查：
1. 是否满足原需求，是否存在只完成一半的流程。
2. 是否遗漏调用方、实现类、配置、数据库脚本或消息消费者。
3. 接口、字段、枚举、消息和数据结构是否向前/向后兼容。
4. 事务、幂等、并发、重试、超时和执行顺序是否存在问题。
5. 空值、边界值、异常分支和部分失败是否处理正确。
6. 是否引入权限、敏感数据或注入类安全问题。
7. 是否可能造成慢查询、循环调用、资源泄漏或流量放大。
8. 日志、监控、灰度和回滚条件是否足够。
9. 测试是否真正覆盖失败场景，而不只是正常路径。
只报告有实际影响且能从代码中举证的问题。每个问题需要给出：
- 严重程度
- 文件和行号
- 触发条件
- 可能影响
- 修复建议
如果没有发现明确问题，请直接说明，并列出仍未验证的风险。电商案例：审查满减活动改动
如果只让Codex“Review满减功能”，它可能只评论命名和重复代码。明确要求检查金额精度、优惠叠加、退款分摊、活动过期、旧订单兼容和并发限额后，审查才会集中在可能造成资损的真实问题上。
2、检查范围不能只停留在diff
diff告诉我们改了什么，但很多Bug出现在没有改动的调用方中。例如：
- 新增了枚举值，但某个
switch没有默认处理 - 接口新增必填字段，但旧客户端不会传
- 生产者修改消息结构，旧消费者还按原格式反序列化
- 方法返回值允许为空，但调用方直接解引用
- 修改事务位置后，异步消息可能先于数据提交
因此审查时应该要求Codex从改动点向外搜索：谁调用它、它依赖谁、失败后怎么重试、旧数据怎么处理。
电商案例：新增订单状态
订单服务新增
PARTIALLY_REFUNDED状态后，diff可能只修改了订单模块，但Codex还应搜索支付回调、售后、物流、用户订单列表和数据统计中的switch分支。否则订单服务本身测试通过，旧消费者仍可能把新状态当成未知值。
3、把改动点、Bug和风险分开写
Codex有时会把“代码确实有问题”“可能有风险”和“可以顺手优化”混在一起，读完仍然不知道哪些必须处理。可以要求它把结论分为四组：
- 改动点：已经修改了什么行为，涉及哪些文件和上下游
- 明确问题：有代码证据、触发条件和实际影响的Bug
- 风险与待验证项：目前不能确认，但受数据、环境、流量或上线顺序影响的事项
- 优化建议：不影响本次正确性，可以后续单独处理的改进
例如“新消费者没有处理旧消息字段缺失”可以是明确问题；“生产环境可能仍有三个月前的旧消息积压”则属于待验证风险；“把重复转换逻辑抽成工具类”通常只是优化建议。
最终可以要求它按下面的格式交付：
1. 改动点：文件、行为变化、改动原因、影响的调用方。
2. 明确问题：严重程度、证据、触发条件、影响和建议修复。
3. 风险与待验证项：需要什么数据或环境才能确认。
4. 验证结果：已执行命令、结果、未执行项及原因。
5. 优化建议：与本次正确性无关的建议单独列出。电商案例：区分问题和风险
“旧版优惠券消息缺少新字段，消费者会反序列化失败”是可以举证的Bug；“线上可能仍积压旧消息”是需要查询队列后确认的风险；“把金额转换提取成公共方法”只是优化建议。三者不应该混成同一优先级。
4、让另一个任务做第二次审查
实现任务中的Codex已经接受了自己的方案，后续容易顺着原有思路检查。重要改动可以新开一个任务，只提供需求、目标分支和审查标准，让它以审查者身份重新分析。
不需要每个小改动都这样做，比较适合：
- 数据库结构和数据迁移
- 支付、账户、库存等一致性逻辑
- 权限和敏感数据处理
- 公共组件或公共协议变更
- 多服务同时上线的需求
电商案例：支付退款独立复查
第一个任务负责实现“部分退款后按比例退还优惠券金额”，第二个全新任务只读取需求和分支diff，检查金额舍入、重复退款、并发退款和账务流水。独立任务没有沿用原实现的判断，更容易发现方案本身的遗漏。
六、任务应该按需求划分，还是按服务划分？
我的默认选择是：先按需求结果划分，再按服务拆执行步骤。
原因很简单：用户最终验收的是一项完整能力，而不是“订单服务改完了”“优惠券服务也改完了”。如果一开始完全按服务拆开，各个任务可能局部都正确，合起来却协议不一致、上线顺序错误，或者没人负责端到端验证。
可以参考下面的判断方式：
| 场景 | 推荐拆法 |
|---|---|
| 小需求，只涉及一个服务 | 一个任务完成分析、实现和验证 |
| 一个需求跨多个服务，接口还没确定 | 先做一个总分析任务，确认链路和协议，再按服务拆子任务 |
| 接口已经稳定，各服务修改相互独立 | 可以按服务并行，但保留一个最终联调任务 |
| 涉及数据库或消息的不兼容变更 | 按上线阶段拆：兼容旧版本 -> 切换调用方 -> 清理旧逻辑 |
| 同一服务里有多个无关需求 | 按需求拆开，避免一个diff混入多种目标 |
| 大规模机械迁移 | 可按模块或目录分批，每批都能单独验证和回滚 |
电商案例：大促下单链路
“支持大促预售下单”是一个完整需求，涉及营销价格、订单定金、库存预占、尾款支付和超时关闭。应先统一订单状态、接口协议和上线顺序，再按服务拆执行任务；如果一开始让五个服务各自实现，很容易出现状态名和时间规则不一致。
一个跨服务需求的拆分示例
电商案例：订单详情展示优惠券名称
这个需求涉及订单服务、优惠券服务和网关，最终验收标准是用户能看到正确名称，同时历史订单和优惠券服务超时不能导致订单详情不可用。
不推荐直接拆成：
- 任务A：修改订单服务
- 任务B：修改优惠券服务
- 任务C：修改网关
因为三个任务都需要自己猜测字段、降级逻辑和上线顺序。
更合适的拆法是：
- 链路分析：确认优惠券名称的来源、接口协议、历史订单和服务不可用时的行为
- 优惠券服务：以兼容方式提供查询能力，并补充契约测试
- 订单服务：接入新字段，处理超时、空值和降级，不改变旧订单查询结果
- 网关/前端：透传并展示可选字段，保证旧响应仍可解析
- 联调验证：覆盖有券、无券、券已删除、优惠券服务超时和灰度期间新旧版本混跑
这里仍然按服务执行，但所有服务共同服从一个已经确认的需求和协议。
什么样的任务大小比较合适？
一个任务最好满足：
- 只有一个主要目标
- 改动范围可以说清楚
- 可以独立验证
- 出问题时容易回退
- 人能在较短时间内看完diff
社区中有使用者把标准定为“每个任务应当能在5到10分钟内人工验证”。这不是硬指标，但思路很好：如果自己都不知道怎么快速判断对错，任务通常还没有拆清楚。
电商案例：把购物车优化拆小
不要用一个任务同时完成购物车合并、失效商品处理、优惠试算和性能优化。可以先交付“登录后合并游客购物车并保证商品数量正确”，用几个明确账号场景验证后，再单独处理优惠试算。
七、测试不要一刀切，要跟着风险走
有两种常见极端：一种是什么测试都不跑，只相信生成结果；另一种是改一行文案也跑完整测试，时间和额度都浪费在低价值等待上。
我更推荐分层验证：
- 先复现原问题，确认测试或步骤在修改前确实失败
- 运行与改动直接相关的单元测试或模块测试
- 修改公共模块、协议或基础设施时，再扩大到集成测试和完整测试
- 页面和交互变化需要实际打开页面检查，不能只看编译通过
- 无法运行的测试要明确说明原因，不能把“未验证”写成“已完成”
还可以要求Codex在结束时固定输出：
请在完成后汇总：
1. 修改了哪些文件，以及每个文件为什么要改。
2. 执行了哪些验证命令，结果是什么。
3. 哪些场景没有验证，以及原因。
4. 仍然存在什么风险或后续工作。测试不仅是交付检查，也是Codex最可靠的反馈。自然语言可以理解错，但失败的断言、编译错误和实际页面结果能迫使它修正判断。
电商案例：按风险扩大测试范围
修改商品详情文案，只需检查对应页面；修改订单金额计算，先跑金额单元测试，再跑下单和退款集成测试；修改公共Money类型，则需要扩大到营销、订单、支付和结算模块。测试范围由影响面决定，而不是所有任务固定跑完整套测试。
八、什么时候继续当前任务，什么时候新开任务？
适合继续当前任务：
- 仍在解决同一个目标
- 新消息只是补充日志、验收条件或反馈
- 需要Codex根据刚才的实现继续修复测试
适合新开任务：
- 开始一个无关需求
- 需要独立审查刚才的实现
- 当前对话已经尝试多套方案，存在大量过期结论
- 希望两个任务并行修改互不重叠的区域
- 需要换一个仓库或完全不同的业务背景
新开任务时不要把旧对话全部粘贴过去，可以提供一份交接摘要：
目标：
已确认结论：
已完成改动：
尚未解决：
关键文件：
验证命令：
注意事项：电商案例：什么时候新开任务
Codex刚实现完优惠券核销，继续修复它引起的测试失败可以留在当前任务；随后要开发物流轨迹查询，应新开任务；要独立审查优惠券核销的资损风险，也应新开任务，并用交接摘要提供需求、关键文件和验证命令。
九、几个容易踩的坑
1、一句话交给Codex，最后才看结果
任务越大，越应该在“分析完成”和“第一批改动完成”时看一次方向。否则最后得到的可能是一份代码很多、但需求理解错误的diff。
电商案例：一句话实现618大促
只说“实现618大促”可能让Codex同时修改价格、优惠券、订单、库存和页面，最后才发现它把“满300减50”理解成每件商品分别满减。应先确认活动范围和算价规则，再分阶段检查。
2、把所有规则都塞进一个文件
规则太多后，真正重要的要求反而不突出，而且很容易过期。项目规则应当短、具体、可执行，详细设计放到独立文档并从规则文件中索引。
电商案例：商城规则全部写进根文件
如果根
AGENTS.md同时塞入商品上下架、库存预占、支付验签、退款分摊和物流回传的全部细节，修改商品标题时也会加载大量无关规则。根文件只保留系统地图，各服务规则放到对应目录。
3、让Codex自己决定不明确的业务规则
技术细节可以让它参考现有代码选择，但金额舍入、状态流转、兼容期限、降级行为这类业务决定，不明确时应该停下来确认。
电商案例：退款后优惠券怎么处理
订单退款后，优惠券是立即退回、过期不退，还是延长有效期，属于产品规则。Codex可以找出现有实现和影响范围，但不能自己选择一个看起来合理的方案。
4、只检查改动文件，不检查上下游
接口、数据库、消息和公共方法的风险通常都在调用方。要求它搜索引用、旧版本和失败路径。
电商案例：支付成功事件新增字段
支付服务把
paidAmount改为必填字段后，还要检查订单、积分、通知和结算消费者，以及队列中的旧消息。只审查生产者文件，无法发现旧消息反序列化失败的问题。
5、一个任务混入顺手重构
功能修改、代码整理和依赖升级最好分开。混在一起不仅难审查，出现问题后也很难判断是哪一部分造成的。
电商案例：退款功能顺便升级支付SDK
在新增部分退款的同时升级支付SDK并重构支付客户端，测试失败后很难判断来自业务逻辑、SDK行为还是重构。应先完成可验证的退款能力，再单独升级依赖。
6、只让原实现任务自我检查
自查有价值，但高风险改动最好再开一个独立审查任务，或者至少重新提供需求，让它只看分支diff，不沿用前面的实现思路。
电商案例：库存补偿逻辑自审
实现任务认为“消费失败就释放库存”是正确方案，自审时往往继续沿用这个前提。独立审查任务可能发现消息会重复投递，第一次失败实际已经创建订单，直接释放会造成超卖。
十、公开案例里有哪些值得借鉴的习惯？
1、先让Codex读懂系统，再让它动手
OpenAI公开的内部使用总结中，工程师会先让Codex定位核心逻辑、梳理服务关系和追踪失败传播路径；修复一个Bug后，还会继续检查代码库中是否存在同类问题。
值得借鉴的不是某个固定功能，而是这个习惯：一次Bug修复包含“修当前问题”和“搜索同类问题”两个动作。
电商案例：修复一处重复扣款后继续搜索
修复支付回调重复记账后，继续让Codex搜索退款回调、充值回调和积分入账是否使用相同的非幂等写法，而不是只关闭当前故障单。
2、重复出错时，优化项目环境而不是继续堆提示词
OpenAI的一个公开项目早期进展较慢，主要原因不是Codex不会写代码，而是仓库缺少工具、约束和清晰结构。后来团队逐步把测试、验证、审查、文档和故障恢复写进项目流程，任务才变得更稳定。
这个案例更像是在提醒我们：如果Codex每次都不知道怎么启动项目、总选错测试命令、反复破坏同一条架构边界，就应该修文档、脚本或检查机制，而不是每次在提示词里重新提醒。
电商案例：把重复纠正变成项目能力
Codex连续两次使用错误命令启动订单服务，就在项目文档中写清启动方式；连续漏跑退款测试，就增加统一验证脚本；反复直接修改库存表，就把边界写进库存服务规则并用架构测试约束。
3、规则要能直接执行
开源的openai/codex仓库没有只写“保证代码质量”，而是明确了格式化命令、不同改动应该运行哪些测试、公共模块何时扩大测试范围，以及大改动应该继续拆分。
这说明好的规则通常可以回答：
- 什么时候触发
- 具体做什么
- 用什么命令验证
- 什么情况下需要扩大检查范围
电商案例：把“注意金额正确”改成可执行规则
与其写“注意金额计算”，不如写“修改订单金额后运行
OrderPriceCalculatorTest；涉及优惠分摊时再运行退款集成测试；金额统一使用分为单位的整数，禁止使用浮点数”。
4、先从重复、边界清楚的工作开始
Simplex公开案例中，团队先从CRUD类应用切入，把Codex用于设计、前后端实现、测试和集成问题修复，再分别统计不同阶段的耗时变化。公开结果显示其特定场景下页面设计、开发和集成测试时间都有下降，但这些数字依赖团队流程和任务类型，不能直接套到其他项目。
更值得照搬的是做法：先选容易验收的任务，用数据比较前后差异，再逐步扩大范围。
电商案例：从商品后台CRUD开始
团队可以先让Codex处理商品后台的查询、创建和上下架，并记录开发时间、返工次数和测试结果。流程稳定后，再逐步扩展到优惠计算、库存和支付等高风险模块。
5、小任务、阶段提交、独立审查是社区高频做法
一些Codex使用者会把功能拆成多个阶段，每个阶段完成后提交，再用另一个任务检查功能、完整性、边界场景和代码一致性；也有人把流程简化成“设计、记录计划、交给Codex一个小任务、验证、重复”。
这些属于个人经验，不是严格的效果证明，但它们反复指向同一件事：工作过程要能停下来检查，也要能回退。
电商案例：分阶段迁移订单状态
第一阶段只新增兼容状态和解析测试，第二阶段修改状态生产方，第三阶段切换消费者，第四阶段清理旧状态。每阶段单独提交并审查，任何一步出错都能明确回退。
十一、我常用的三个提示词模板
1、新需求分析
请先只读分析这个需求，不要修改代码。
需求：{需求内容}
入口：{接口/页面/服务/文件}
限制：{兼容要求、不能修改的部分}
请输出：
1. 当前实现和完整调用链。
2. 需求与当前行为的差异。
3. 建议的最小改动方案。
4. 预计修改的文件、接口、配置、表和消息。
5. 测试方案和验收用例。
6. 风险点、待确认项和上线顺序。电商案例：调用新需求分析模板
输入“下单时自动选择最优优惠券”，并把
CheckoutController作为入口。Codex应先说明“最优”的排序规则是否按实付金额、优惠金额还是有效期，确认后再分析营销和订单服务。
2、Bug排查和修复
现象：{实际现象}
预期：{正确行为}
复现：{复现步骤/命令}
日志：{关键报错}
入口：{已知文件或接口}
先复现并定位根因，说明证据和影响范围；确认后做最小修复。
不要用吞异常、写死数据或删除校验的方式绕过问题。
修复后补充回归测试，并搜索是否存在相同写法导致的同类问题。电商案例：调用Bug排查模板
提供“同一支付流水产生两条账务记录”的复现请求、回调日志和
PayCallbackController入口，让Codex先证明重复写入发生在哪里，再做最小修复并搜索其他回调入口。
3、改动审查
请检查当前分支相对{目标分支}的全部改动，并结合原需求判断是否正确。
重点检查功能遗漏、兼容性、并发和事务、数据一致性、异常路径、
安全、性能、可观测性、回滚以及测试缺口。
只报告可以从代码举证的实际问题，按严重程度排序，并给出文件、
行号、触发条件、影响和修复建议。最后列出未验证项和剩余风险。电商案例：调用改动审查模板
审查“部分退款”分支时，把
main作为目标分支，重点要求检查退款金额上限、重复请求、优惠分摊、订单状态、账务流水和旧客户端兼容，并把明确Bug和线上待验证风险分开。
十二、总结
Codex最佳实践并不是记住多少提示词技巧，而是养成下面几种习惯：
- 需求写成可以验收的任务，而不是一句模糊愿望
- 动手前让Codex复述需求，并确认假设和不明确点
- 复杂改动先分析链路和风险，再开始写代码
- 上下文给入口和约束，不要无差别堆资料
- 默认按需求结果拆任务，跨服务时再按边界分步骤
- 用测试、运行结果和diff验证，不把回答本身当成证据
- 高风险改动增加一次独立审查
- 同类错误重复出现时，按作用范围沉淀到全局规则、项目规则、Skill或自动检查中
最终目标不是让Codex一次生成更多代码，而是让每次改动都更容易理解、验证、审查和回退。
