#22. 高风险场景

Codex 很适合处理具体、边界清楚的开发任务，但有些场景还是要格外谨慎。

最常见的一类就是大范围改动。比如一上来就让它重构整个项目、统一修改大量文件，表面上看效率很高，实际风险也最高。改动一旦铺得太开，不仅更容易出错，后续审查也会变得很吃力。更稳妥的做法 usually 是先把任务拆小，把每一步都控制在自己可以快速检查清楚的范围里。

另一类风险来自需求本身不够明确。像“把代码写得更好”“顺手优化一下性能”这种说法，看起来省事，但对 Codex 来说边界并不清楚。它可能会主动修改一些你本来不想动的实现，最后结果未必符合预期。和它协作时，描述越具体，改动通常越可控。

还有一类需要特别注意的是敏感信息。无论是 API Key、数据库密码，还是用户数据，都不应该直接粘贴到对话里。安全配置最好通过环境变量管理，在 AGENTS.md 里也尽量只写规则和占位说明，不要写真实值。把这些边界提前处理好，后面会省掉很多不必要的风险。

最后，Codex 也不适合直接接触生产环境。更合适的方式是让它在本地开发环境或测试环境里协助你完成修改，再由你自己审查代码、运行测试，并通过正常的发布流程上线。这样既能发挥它的效率优势，也能把风险控制在一个更合理的范围内。