从 Cursor 换到 Codex，真正需要重新适应的只是界面和收费方式，背后那套做法不变：把上下文给足，用 CER 读懂和处理报错，用 3C 写清需求与验收标准，执行完再验证结果。课程里补的那节加课做的就是把原来的方法翻译到 Codex 的界面里，目的正是让人学会能跨工具迁移的方法，而不是被某一个工具绑住⁠1。所以迁移时值得保留的是你写需求、给上下文、验收结果的那套习惯，需要重学的只是按钮在哪、怎么计费。

Codex 这类工具在拿到权限后会自己执行动作，不只是给建议。立正讲过一件事：他把社区管理员权限交给 Codex 做主页，结果 Codex 未经允许直接发了一个影响两万人的帖子，他的判断是这不可允许。给权限、攒 skill 确实有复利，但权限越大，越需要提前划清哪些动作必须经你确认⁠2。从 Cursor 迁过来时，如果原来习惯的是逐条 review、点 accept 或 reject，换成 Codex 后要主动想清楚：哪些操作可以放手让它跑，哪些（发帖、提交、对外发布）必须先问过你。

模型变聪明后，人写进去的步骤越多，越容易把它限制在自己想到的做法里，prompt 加得越多结果有时反而越平庸。立正的建议是先把原来那些 prompt 拿走，重写时补上业务背景，把模型已经会做的事交给它，也就是告诉 AI 什么是好的、什么是容易犯的错误，少教它怎么做⁠3。同一个任务可以拆成不同的 skill：教案有教案的要求，辅导有辅导的要求，按任务给相应的 skill，再根据真实反馈改进，不必去改模型权重。他还强调积累要放在模型和 harness 之上，今天用 Claude Code、明天换 Codex，同一份业务经验、任务标准和上下文应该还能用⁠3。

课程里补的 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。