用好 GPT-6 Astra，先给 AGENTS.md 和 Skills 做一次减法

只是想改一行文案，Agent 却先读了一轮项目文档，列出计划，再停下来问你要不要继续。遇到这种情况，先翻一下自己的 AGENTS.md：里面是不是还留着“每次修改前必须……”这样的规定？

模型换了，过去为了让它少犯错而加上的指令，未必还适合现在的工作。

OpenAI 的 Eric Provencher 在 9 月 11 日发布了 Rethinking skills and prompts for GPT-6 Astra。文章建议重新检查 Skill 的适用范围、常驻指令和任务完成条件，减少过时的约束与不相关的上下文。

这件事可以交给 Codex 帮你做。先让它指出具体哪几条值得改，比直接要求“全面优化我的配置”更容易得到有用的结果。

先复制这段提示词

在要检查的项目中打开 Codex，确认使用的是 Astra，再粘贴下面这段。如果还没确认模型入口，可以先看 Codex 中的 GPT-6 Astra 使用指南。

参考这篇 OpenAI 文章：https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra
检查当前项目实际生效的 AGENTS.md、覆盖文件和可用 Skills，找出会导致过度工作、指令冲突或不必要等待的设置。
先确认指令来源与 Skill 的触发描述，仅在需要核实问题时读取相关 Skill 正文和参考资料。
重点看：- 是否强制每次任务都读大量无关资料；- 是否把局部工作扩大成全仓检查或重复验证；- Skill 是否触发过宽，或与其他指令相互冲突；- 是否在已经授权的工作中反复要求确认，或过早停止。
每项给出文件位置、原句、具体影响和最小修改建议。区分官方明确建议与根据本项目作出的推断。保留有效的工程约束和授权边界；无法确认的内容注明原因。先只给建议，不修改文件。不为凑数量制造问题。

这是本文整理的检查模板，不是 OpenAI 发布的原文提示词。它会先给你一份可审阅的建议，不会粘贴一次就自动改完设置。

收到结果后，优先看它有没有指出真实文件、具体句子和触发场景。如果只是把所有规则换一种说法，甚至给你生成了一份更长的新规范，这次检查还没解决问题。

先弄清楚：哪些指令一直在，哪些用到才读

AGENTS.md 和 Skills 的加载方式不同。

按照 Codex 的 AGENTS.md 文档，指令会从全局设置和项目目录逐层组合；AGENTS.override.md 也会影响实际读到的内容。所以，根目录那份文件写得很清楚，不代表当前任务没有其他指令在生效。

Skills 则先提供名称与描述，选中之后再读取完整 SKILL.md。官方 Skills 文档还说明，初始列表有大小预算，技能很多时描述可能被缩短，部分技能也可能不出现在初始列表里。把所有工作都塞进一个宽泛的描述，会让选择更困难。

可以拿一个周报 Skill 试着判断：

• “处理任务、文件、沟通和团队协作时使用”——几乎什么事都可能撞上它。
• “把已有工作记录整理成周报；生成、修改或审阅周报时使用”——读完就知道它负责什么。

名称和描述负责让 Agent 找对入口。周报的格式、特殊字段和脚本参数，可以放到使用时才需要的内容里。

改一句话，看看它会少做哪件事

下面是几个示例，用来演示怎么把建议落到具体行为上。它们不是适合所有仓库的通用配置。

让阅读要求带上任务条件

假设项目规定：“每次修改前，先阅读全部产品、架构和发布文档。”

那么即使只修改一个按钮标题，这条规则也会生效。更有用的写法可以是：“修改按钮文案时，核对所在页面与文案规范；涉及发布步骤时，查阅发布说明。”

改完以后，应该能在下一次同类任务中看到差别：Agent 找到了当前页面及相关规范，就开始修改。若它仍然先通读所有文档，就继续查是哪一条指令触发了这段工作。

给检查一个结束条件

“反复检查，直到完全没有问题”很难验收。它既没说该检查什么，也没说什么时候可以交付。

以修改表单错误提示为例，可以要求：复现对应错误状态，检查提示文字与遮挡情况，运行受影响模块需要的检查；通过后交付结果，有新错误再继续处理。

这里保留了验证，也能判断验证是否已经完成。需要改掉的是没有对象、没有终点的反复检查。付款、权限、数据一致性等功能需要哪些测试，仍由它们实际承担的风险决定。

把“等我确认”写到具体边界上

假设一处要求“完成任务再返回”，另一处要求“每完成一个步骤都停下来确认”。Agent 不管继续还是停下，都会违反其中一条。

如果你希望它完成本地修改、修复相关测试失败并检查页面，就把这些写进这次授权。真正需要负责人决定的事情，例如把改动部署到生产环境，则单独写明。已有授权覆盖的步骤可以连续完成，新增范围或风险出现时再停下来说明。

检查提示词能找出这种冲突，但涉及团队授权方式的取舍，需要由有权决定的人确定，不能靠模型把不方便的规则删掉。

不要漏掉你刚刚发出的任务

配置整理得再好，当前任务如果只写“帮我看看怎么改”，Agent 仍然可能把解释方案当成完成。

给一个小型页面问题下任务，可以这样写：

修复登录表单的错误提示被遮挡的问题。完成代码修改，检查正常、报错和提交中状态，运行相关检查并修复本次改动造成的问题。结果满足这些条件后，给我变更说明与验证结果。这次工作到本地验证完成为止。

这个任务说明了问题、要交付的结果和工作终点。项目若使用别的验收方式，就换成真正适用的条件。不要为了让 Astra 多做事，又加上一句“顺便全面优化整个项目”。

如果同一套仓库指令还要给其他模型使用，也留几个代表性任务做对照。某条提示对 Astra 显得多余，并不能直接证明它对团队里所有 Agent 都没有用。

怎么知道这次整理有效

选一个你经常做的任务，保留相同代码基线、模型、推理强度和工具，分别用修改前后的指令运行。先看结果是否合格，再比较读了多少文件、调用了多少工具、停下来问了几次，以及总耗时和实际用量。任务存在波动时多观察几次，别拿一次特别顺利的结果当结论。

少读两份文件，可能同时减少后续上下文；取消一次重复检查，也可能节省一整轮工具调用。但实际节省多少，取决于原有规则和任务。计算 API 成本时还要区分输入、缓存与输出，可以参考 Coding Agent API 成本计算方法。

最值得保留的指令，往往是模型没法自己猜对的信息：哪个命令才是项目认可的检查入口，哪个目录不能随便改，哪一步需要谁的授权。给这些信息留出位置，再把完成条件说清楚，下一次任务就有了可以检验的改进方向。

本文参考 OpenAI 于 2026 年 9 月 11 日发布的文章，以及 AGENTS.md、Skills 官方文档；资料核对日期为 2026 年 9 月 15 日。检查提示词和场景示例由 Agent.Space 编写。