夜雨聆风Codex 好不好用，很大程度取决于你会不会交代任务。
很多人用 Codex 的方式是：
“帮我修复 bug。”“帮我优化页面。”“帮我重构代码。”
这些话不是不能用，但太模糊。
Codex 最怕的不是任务难，而是边界不清楚。
你没有告诉它改哪里、不能改哪里、怎么验证、完成后要汇报什么，它就只能自己判断。一旦它判断错了，就可能改多、改偏，甚至引入新问题。
所以，我建议新手使用 Codex 时，尽量套用一个固定结构：
目标、范围、限制、验证、汇报。
可以直接用这个模板：
目标：请帮我完成【具体任务】。范围：优先查看【相关目录或文件】。只修改和这个任务直接相关的代码。限制：不要修改无关文件。不要引入新依赖。不要改变现有业务逻辑，除非你先说明原因。验证：修改完成后，请运行相关测试、lint 或构建命令。如果无法运行，请说明原因。汇报：最后请总结：1. 修改了哪些文件2. 每个文件改了什么3. 如何验证4. 还有哪些风险这个模板看起来有点长，但非常有用。
比如你要修一个登录问题，可以这样写：
请帮我修复登录页手机号格式校验失效的问题。范围：优先查看登录页组件、表单校验逻辑和相关测试。只修改登录相关代码。限制：不要改全局表单组件。不要引入新依赖。不要调整页面样式。验证：修改完成后运行相关测试。如果没有测试，请说明你是如何手动检查逻辑的。汇报：请列出修改文件、修改原因和验证结果。这比一句“帮我修登录 bug”稳定太多。
如果你要让 Codex 做前端页面，也可以这样写：
请帮我新增一个用户设置页面。要求：页面包含头像、昵称、邮箱、密码修改入口。风格参考现有设置页面。复用项目里已有组件。限制：不要新增 UI 框架。不要改路由结构之外的无关文件。不要影响已有页面。验证：完成后运行构建或类型检查。最后告诉我访问路径和修改文件。Codex 的强项是执行工程任务，但前提是你要把任务讲清楚。
它不是越自由越强。恰恰相反，边界越清楚，它越可靠。
尤其是涉及重构、测试、安全、权限、支付、数据库这些任务时，一定要加限制。
比如：
不要修改公共 API。不要改数据库结构。不要操作生产数据。不要大范围重构。不确定的地方先问我。修改前先给方案。
这不是不信任 Codex，而是正常的工程管理。
真正会用 Codex 的人，不是把所有事情都丢给它，而是知道怎么把任务拆清楚、边界讲明白、结果验收好。
一句话总结：
Codex 不是靠“神提示词”变强的。它是靠清晰目标、明确范围和可验证结果变稳定的。
你把任务交代得像工程需求，它就更像工程助理。
