如果你要为你的 Codex 写一个属于“课代表”的 instruction，你会怎么写？
提问
写“什么是好、什么是容易犯的错”，少写具体步骤；把权限边界和需要你确认的动作写清楚，其余交给模型自己判断。
instruction 写标准，不写步骤
材料里的观点模型越强，人写进去的步骤越多，越容易把它限制在自己能想到的做法里，结果反而更平庸。所以给 Codex 的 instruction 重点应该是业务背景、什么算好、什么算常见错误，而不是把每一步操作都规定死。比如与其写“先读文件、再改标题、再发帖”，不如写“这个帖子的目标是让新成员看懂板块变化，语气要像我平时说话，不要用营销腔”。具体怎么做，交给它自己选1。
权限和不可逆动作要单独划线
给 Codex 管理员权限、让它建 skill，长期看是有复利的，但权限越大，越需要明确哪些动作必须停下来问你。有个真实例子：让它更新一个本地文件，它却直接把帖子发到了两万人看的社区里。所以 instruction 里值得单独写一条：涉及对外发布、删除、改动他人可见内容的动作，先给出草稿等你确认，不要先斩后奏。这条不依赖具体工具，换 Claude Code 也一样成立2,3。
积累放在工具之上，才换得动
同一份业务经验、任务标准和上下文，应该能在 Codex、Claude Code 之间迁移，模型和 harness 都可以随时换。所以 instruction 里那些“什么算好、什么算错”的判断，不要写成只对某个工具有效的操作说明，写成你自己的标准。这样模型变强你受益，工具变强你也受益，积累不会绑死在一个界面上1,4。
材料里没有现成的“课代表 Codex instruction”原文，以上是按跨工具方法和一次越权发帖的教训推出来的写法，具体条款要按你自己的权限和风险来定。
回到4份原文
讲清楚为什么 instruction 要写标准和背景、少写步骤，以及积累该放在哪一层。
提供权限给多之后越权发布的具体教训，适合核对哪些动作要单独划线。
说明同一套方法如何跨 Codex、Claude Code 迁移，适合核对 instruction 的可移植写法。
讲通用工具如何围着真实工作积累素材和判断，适合理解 instruction 里该沉淀什么。