GPT-6 时代怎么给 Codex 写指令：精简 AGENTS.md 和技能，管好长任务

如果你用 Codex 有一段时间了，项目里多半攒了不少指令：AGENTS.md 越写越长，技能装了一堆，提示词里习惯性地加上“先读完这些文档”“每一步都先问我”。这些当初是为了把老模型拉回正轨。

OpenAI 的说法是：换到 GPT-6 之后，这些指令很多已经不需要，有的还在帮倒忙。官方指南里引了开发者体验团队 Eric Provencher 的一句话，大意是模型理解细微差别和模糊含义的能力已经大幅提升，过去有帮助的过于具体的指导，现在反而可能妨碍模型发挥。

这篇按官方的两篇文章，讲四处该改的地方，再讲长任务怎么管。本文是按官方资料整理的，本站尚未在本机实测。

先给一个最省事的办法，来自原文的结尾：不用自己逐条检查，让 GPT-6 Astra 按这些原则把你的指令审一遍。

一、技能：描述要短，正文要分层

技能本质上是存成 Markdown 文件的提示词，可以带上资源和脚本，适合指导某个具体的工作流。每个技能的名字和描述会被加载进模型的上下文，模型靠它判断什么时候用。

官方指出的三个问题和改法：

描述太长、太宽

技能装得太多时，Codex 会把描述缩短来放进上下文，模型看到的每条描述更少，更难选对。描述之间还可能互相矛盾，或者过分强调自己该被使用，让模型加载了对任务没用的指令。

改法：描述尽量短，同时说清楚什么时候该用。 原文的对比（译自原文）：

不好：创建并验证 Postgres 的表结构迁移。在处理数据库、查询、模型或持久化时使用。

好：  创建并验证 Postgres 的表结构迁移。在新增或修改迁移，或者审查迁移的上线过程时使用。

第一种写法会让模型一碰到和数据库沾边的事就加载这个技能，而不是只在要处理迁移的时候。

一次读进来太多

读一个技能要占上下文，离压缩更近一步，还会带进这次任务用不上的指导。

改法：渐进式披露。 有多个工作流的技能，把根文档写成一个最小的“路由”，指向配套的文档和脚本。让模型知道去哪里找，而不是强迫它把眼下用不到的都读一遍。

写成了一步步的操作手册

很多技能被写成详细的行程表或菜谱。模型现在能理解细微差别，过于具体的步骤反而会拖累结果。

改法：用指导原则代替僵化的步骤。

还有一点容易忽略：放在仓库里的技能，也会指导其他贡献者的代理，而他们用的可能是别的模型。对 Sol 或 Luna 有帮助的指导，可能把 Astra 限制得太死。写的时候要想想会有哪些模型读到它。

二、AGENTS.md：按情况指路，别要求每次全读

AGENTS.md 在模型进入你的仓库工作时始终生效，所以要经常回头看每一条：它现在还需要吗？

读文件：给条件，不要给命令

改一个错别字之前要求先读一摞文档或整份仓库地图，是过度的。GPT-6 Astra 能自己判断需要读什么。原文的对比（译自原文）：

不好：每次修改之前，先读 architecture.md、database.md 和 deployment.md。

好：  服务之间的边界看 architecture.md，改表结构看 database.md，
      准备部署时看 deployment.md。

要求每次修改前都读文件，既烧上下文又拖慢工作。指向文档仍然有用，前提是说明什么情况下看哪一份。文档本身也要保持更新。

测试：不用再催

以前的模型需要鼓励才会跑测试、检查自己的工作。GPT-6 Astra 会自己做，同样的指令现在可能导致不必要的测试。

给安全的常规流程明确授权

GPT-6 Astra 做事很彻底，但对一件事该推进到什么程度会更谨慎，有时需要推一把。可以在 AGENTS.md 里对一个你确定安全的流程给出许可，比如本地测试（译自原文）：

本地测试使用一次性的测试数据，访问不到生产环境。
运行它们，修复由这次改动引起的失败，并重跑受影响的测试，
不必每一步都请求批准。

三、决策边界：别再写“一律先问”

如果以前的模型未经允许就替你做了事，你可能加过语气很重的话让它先问。原文提醒，Astra 的判断力更好，不确定安全就不会动手；你为了防别的模型越界而写下的强硬边界，它可能看得太重，在你其实乐意它继续的地方停下来。

改法：说清楚哪些可以自己做、哪些需要批准，用明确的边界代替一概“始终先询问”。

官方指南举的例子：模型可以自己决定摘要怎么组织，但改变项目范围之前要先和你确认。

按这个思路，一段边界可以这样写（示例是本站按上述原则写的，不是原文）：

可以直接做：读代码、改本次任务涉及的文件、跑本地测试和 lint、新建分支。
先问我：    改公共接口、加新的依赖、动数据库迁移、改 CI 配置。
不要做：    推送到 main、访问生产环境。

四、做到什么算完成：开工前说清楚

习惯了上一代模型接到任务就连续干很久的人，会觉得 GPT-6 Astra 更早停下来：做出第一版实现就回来请你看，而其实还有活没干完。

改法：开始之前定义“完成”。 如果任务包括把实现跑起来、检查结果、修掉失败的地方，就把这些写进要求里。官方指南对“执行到底”的拆解是四个环节：实施改动、运行、检查结果、修复问题，同时指出哪些决定要留给你审。

原文还有两条：

“做完第一版先停下来让我看”这类要求，会把模型往更早的停止点拉。先想想这个决定是不是真的需要你来做。
想让它在第一轮之后继续探索，就说明要探索什么、到哪里为止。

写任务提示词时的三件事

官方指南建议每次交代任务时先明确：想要什么结果、给谁用、有哪些相关的背景和限制、什么算完成。此外说清楚：

它可以自己做哪些决定，什么时候该来问你。 让它能持续推进，而不用在重要的事上猜。
什么样的回复对你有用。 例如用通俗的语言、技术细节适合读的人、最后给一段简短的交接：改了什么、检查了什么、还有什么需要留意。
各处的要求要一致。 提示词、技能和仓库里的指令，对“交付什么、能独立做什么、什么算完成”的说法不要互相打架。

长任务怎么管

GPT-6 这一代可以处理持续几小时甚至几天的任务。任务一长，总会遇到写第一条提示词时想不到的决定。官方指南给 Codex 用户两个办法：

回答它的提问时，多说一句。 用 GPT-6 Astra 时，Codex 会在工作过程中请你澄清。回答影响下一步的那个问题，同时说明在你考虑期间，哪些独立的工作可以继续。要离开一阵子的话，告诉它哪些任务可以接着做、到什么时候该停下来等你。

需求变了就中途引导。 用新的信息引导当前的任务，说明哪些要改、哪些保持不变，避免它在已经不符合需求的方案上继续花时间。

需要操作界面时

GPT-6 Astra、GPT-6.1 Sol 和 Luna 都支持计算机使用，可以直接操作网站和桌面应用。例如让模型查一个缺陷、修代码，然后在浏览器里打开你的产品确认修好了。官方的原则是每一步选最简单可靠的方式：API 或已连接的工具能直接完成的就用它们；需要读屏幕、点按钮、填表单时才用计算机使用。

一份检查清单

对照着过一遍自己的项目：

每个技能的描述是否只有一两句，并且说的是“什么时候用”，而不是“和什么有关”？
长的技能是否拆成了入口加配套文档？
技能里有没有可以换成原则的逐步操作？
AGENTS.md 里有没有“每次都先读……”“务必运行测试”这类话？
安全的常规流程（本地测试等）有没有明确授权？
有没有一概而论的“任何操作前先询问”？能不能换成三类：直接做、先问、不要做？
任务提示词里有没有写“完成”包括哪些环节？
提示词、技能、AGENTS.md 三处有没有互相矛盾？

做不过来的话，把这份清单交给 Codex，让它审一遍再给你改动建议。

和 Claude Code 那边的对照

Anthropic 在 7 月说了几乎一样的话：他们为新一代模型删掉了 Claude Code 系统提示词的八成以上，见本站的 Claude 5 这一代模型的上下文怎么写。两家的共同点是少定规则、按需加载、给明确的边界。不同点在于，OpenAI 这篇特别强调了一件事：新模型更谨慎，所以除了删规则，还要主动授权和定义完成，否则它会停得比你预期的早。

模型怎么选、推理强度怎么定，见 Codex 该选哪个模型。