修改核心代码前，先让 Codex 补测试

当你准备修改支付、订单、权限、计费、库存这类核心逻辑时，可以先不让 Codex 改实现，而是让它为现有行为补一层测试。

提示词可以这样写：

暂时不要修改业务实现。
先阅读订单取消逻辑，为当前行为补充回归测试。
覆盖：正常取消、已支付订单、重复取消、订单不存在、数据库更新失败。
确认测试能够描述当前系统行为后，再告诉我哪些行为可能存在问题。

这样做有两个价值。

第一，你得到了一张“安全网”。后面无论是你改还是 Codex 改，一旦旧行为被破坏，测试会第一时间提醒。

第二，Codex 会因为写测试而被迫更深入理解现有代码。很多隐藏逻辑，例如特殊状态、兼容分支、历史字段，往往是在测试阶段才暴露出来。

之后再下第二个任务：

现在按照新的业务规则修改实现，并确保刚才的回归测试以及新增测试全部通过。

如果某些旧行为本身就是 Bug，就明确说明哪些测试允许修改，否则 Coding Agent 可能为了“让所有测试通过”保留错误逻辑。

对重要系统来说，“先测试后修改”是非常适合 Codex 的工作方式，因为它把模糊的正确性变成了可执行的验证条件。