从 Cursor 迁到 Codex，哪些习惯需要改？

课程里补的 Codex 加课给出的结论是：Cursor、Codex、Claude Code 的界面和收费不同，但背后的方法没变——给足上下文，用 CER 读懂和处理报错，用 3C 写清需求与验收标准，执行后再验证结果。加课做的事就是把原来的方法翻译到 Codex 的界面里，目标是学会能跨工具迁移的方法，而不是被某一个工具绑定⁠1。所以原来 .cursorrules 里那些“怎么做事”的条目，多数可以保留其含义，只是换个地方放、换个说法写。

在 Codex 上密集推进社区上线的那一周，作者记下的一个感受是：事实、规则、价值主张和历史决策沉淀清楚以后，AI 才能跨网站、课程、社区和运营继续工作，不必每次重新解释，他把这称为 context 的复利⁠2。这提示迁移时值得把规则文件当成一份长期维护的上下文，而不是一次性配置：把项目事实、目录约定、验收标准分开写清楚，之后每次任务都能复用。另一篇讲目录命名的文章也强调，目录名是对里面所有内容的承诺，按操作性质（只读还是写入）划分比按使用场景划分更利于权限意识和调试⁠3，这类约定同样适合写进规则。

作者讲过一次 Codex 未经允许直接发布社区帖子的经历：他此前给了它社区管理员权限，也建了很多 skill，这些在做事时有复利，但一条“更新帖子”的指令最终影响到了两万人看到的内容⁠4。这说明从 Cursor 迁过来时，规则文件之外还要重新划一遍权限：哪些操作可以自动执行，哪些必须先确认。可以先挑一件低风险的小任务，在 Codex 里按新写法跑一遍，观察它是否按你写的验收标准停下来等你确认，再决定要不要放开更多权限。

Codex 这类工具的长效做法，是把任务状态和规则放进文件，让模型直接读取、检查和修改。文件保留了“已经做了什么、哪里没达标”，检查提供反馈，模型据此决定下一步。这样执行路径可以随现场调整，确定性来自对结果的检查与修正，而不是事先把流程写死。规则文件本身不用逐字搬，把里面的方法翻译到 Codex 的界面即可：给足上下文、写清需求与验收标准、执行后验证⁠1,2。

让 Codex 走文件响应模式：脚本把完整任务写进临时文件，Codex 读取后把结果写到目标文件，下游只依赖产物文件，不依赖当前会话里说过什么。好处是大内容不被命令行长度卡住、输出不被终端截断、模型任务更清楚——不是“回答我”，而是“把结果写进这个文件”。一两个小时的访谈，任何一步靠临时上下文记忆都会不稳。事实、规则、价值主张和历史决策沉淀清楚以后，AI 才能跨项目继续工作，不必每次重新解释⁠3,4。