GPT-6 Astra 的 Skills、AGENTS.md 与提示词怎么改 | OpenAI 官方指南解读

OpenAI 官方指南《Rethinking skills and prompts for GPT-6 Astra》讨论了一个很实际的问题：换用更强的模型后，过去积累的 Skills、AGENTS.md 和任务提示词，还要不要原样保留？对于已经给 Codex 配置了许多规则的用户，值得先检查规则是否在正确的任务中生效，以及它们会把任务引向什么完成状态。

原文由 Eric Provencher 撰写，页面标注日期为 2026 年 9 月 11 日。本文是杂货喵的中文解读，核对时间为 2026 年 9 月 12 日；后面的文件组织、内容运营场景和审计提示词均为编辑示例，不是官方原话，也不代表已经实测能提高某个百分比的效果。

先理解官方建议：规则需要跟着模型重新检查

这篇指南的重点可以归纳为四项：缩小技能描述的触发范围；把多流程技能拆成按需读取的参考资料；让 AGENTS.md 的阅读与验证要求匹配实际任务；明确授权边界和完成条件，避免任务过早停在初稿阶段。原文也提醒，面向不同模型的共享规则，未必都适合直接照搬给 Astra。

我们的理解是，审计时应先问“这条规则解决什么具体问题”。例如，“正文不能把推测写成已确认事实”直接约束内容质量；“任何修改前必须读取全部文档”则把一个阅读步骤扩展到了所有修改。前者是否保留，取决于业务要求；后者是否保留，要看这些文档对当前任务是否有用。

因此，文件短不一定代表设计得好。删掉生产环境说明，却留下许多泛化的“务必仔细检查”，可能让指令更短、边界更模糊。衡量修改是否有效，应观察真实任务中误触发、遗漏与不必要的暂停是否减少。

Skills 描述怎么改：先写清楚何时使用

用具体动作替换宽泛关键词

假设你有一个 WordPress 草稿编辑技能。下面两种描述会给模型不同的选择依据。表格是针对内容运营场景编写的示例。

写法	示例	可能产生的影响
范围过宽	处理 WordPress 内容。只要涉及网站、文章、图片或链接，就必须使用。	单纯解释一篇网页，也可能触发建稿、上传和字段保护流程。
范围具体	创建或更新 WordPress 文章草稿。用于用户要求将文案保存到 WordPress，或修改已指定文章时。	围绕“写入草稿”选择技能，较容易与普通阅读、写文案任务区分。

如果技能同时支持只读审查，应在适用范围中简短写出，并在正文分开审查与写入路径。不要为了缩短描述，把实际存在的工作流隐藏起来；也不要把压缩参数、字段名清单、异常处理和所有示例都挤进描述。

主文件负责选择路径，参考文件负责解释细节

下面是一个可供改造的目录示例。它表达的是文档组织方式，不是要求新建某套固定目录：

wordpress-drafts/
  SKILL.md
  references/
    article-writing.md
    media-processing.md
    field-boundaries.md
  scripts/
    validate-payload.js

SKILL.md 可以说明：写正文时读取文章规范，处理配图时读取媒体规范，提交草稿时读取字段边界并使用验证脚本。只改标题，就不需要先学习图片压缩流程；用户要求完整制作图文草稿，则可以依次进入这些相关分支。

关键保护要求也要能及时读到。 如果“不得公开发布”只藏在一个不一定会打开的参考文件末尾，拆分就失去了可靠性。入口应保留适用边界与必须遵守的限制，细节再按需展开。

AGENTS.md 怎么减负：保留项目事实，按任务读取资料

对一个内容工作区来说，根目录说明最有价值的信息可能是：正式稿放在哪里、哪个脚本负责提交、哪些字段不能随正文改动，以及新文章默认保存成什么状态。它不必重复每种文章的全部写作规范。

可以把必读要求改成条件明确的指路语句。以下仍是编辑示例，实际文件名应替换为项目中确实存在的路径：

撰写或改写正文时，读取 docs/article-rules.md。
处理封面或正文图片时，读取 docs/media-rules.md。
向 WordPress 提交内容前，读取 docs/field-boundaries.md，
验证本次 payload；写入后回读本次修改的字段。

这段要求把阅读行为绑定到具体操作。若只是讨论标题方向，不会自动进入媒体上传检查；若已经要提交 WordPress，则验证和回读仍属于必做工作。

检查范围跟着变化走

例如，把文章中的一个错字修正后，需要确认错字确实改好、附近 HTML 没有损坏。如果同时改变了目录链接或图片地址，就应增加相应检查。检查应当覆盖修改可能影响的行为，而不是每次都重跑与内容无关的整套流程。

还要区分“旧规则过时”和“旧规则有业务依据”。禁止泄露凭据、保存前验证、保护付费设置，都能对应到具体后果。精简这些规则时可以合并重复表述，但不应顺便删掉它们的约束。对尚不清楚用途的规则，先记录来源和疑问，再决定是否修改。

减少重复确认：把授权与完成状态写在同一个任务里

“帮我把文章处理一下”没有说明最终要交付对话文案、可预览文件，还是已保存的 WordPress 草稿。模型即便写出了正文，也可能无法判断下一步是否属于请求范围。更可执行的任务需要说明对象、允许的操作和完成状态。

图文草稿任务的写法示例

在“攻略手册”分类新建一篇文章草稿，包含正文、封面和两张正文配图。
完成事实核对、写作、图片处理、媒体上传和草稿保存。
在本次范围内自行修复文案、排版和校验失败的问题。
保存后回读标题、分类、正文图片和特色图，确认仍为草稿。
完成时提供编辑入口，并说明尚未解决的证据缺口。
涉及新增付费服务、修改账号权限或公开发布时，先提出具体请求。

这里的“继续完成”具有明确终点：保存并检查草稿。它不等于授权公开发布，也不要求在正文完成、图片完成、上传完成之后分别重复询问一次。实际使用时，删除任务不需要的步骤，并把审批事项改为自己的真实边界。

出现局部问题时，说明它阻塞了什么

假设图片服务暂时不可用，图片生成与依赖图片的提交步骤就存在缺口，但已经核实的正文仍可以整理保存。报告应该说明“正文已完成，配图尚未生成，完整图文草稿未完成”，并继续处理独立部分。相反，如果连指南原文都无法核对，主要结论也不能确定，就不能拿推测补成一篇“官方解读”。

这样的区分有助于避免两种误报：把一个局部失败当成整项任务都无法推进，或把部分成果称为全部完成。

一份可复制的 Skills 与 AGENTS.md 审计提示词

第一次审计建议选一个经常出现问题的工作流，例如“解释网页时误启动发布技能”，或“制作草稿时在中途频繁停下来”。先备份相关规则，再使用下面这段提示词。它是本文提供的审计模板，需要自行填写范围：

请只读审计以下范围内的 Skills、AGENTS.md 及相关引用文档：
【填写目录或技能名称】

目标：定位技能误触发、重复或冲突的规则、无关的强制阅读，
以及会让已授权任务提前停止的条件。

请按实际任务需要读取文件，不必先读取全部参考资料。
每个问题提供文件路径、相关原文、触发场景、可能后果和建议改写。
区分确定冲突、重复表述和需要向维护者核实的业务要求。
没有证据时，不推定一条限制已经失效。

优先给出最小修改方案，保留凭据保护、真实证据要求、
生产环境边界、商业字段保护和必要的提交验证。
本次只提交审计结果，不修改文件，不执行外部写入。

最后为修改方案列出少量有代表性的验证任务，
包括应当触发技能、不应触发技能、应继续执行和应停下确认的场景。

审计中的“只读”是这一次任务的明确终点。等修改方案确定后，再单独要求落地修改及验证，就不会把审计模板中的停顿要求永久带入所有工作流。

用四类任务观察改写是否有效

验证场景	希望观察到的行为
只解释一篇官方网页	读取相关来源并回答，不进入草稿写入或媒体上传流程。
明确新建无图文章草稿	完成正文、必要字段、保存和回读，不启动配图流程。
已授权的草稿校验失败	在本次范围内修复后重新验证，不把可修复的问题直接交还。
任务需要新增账号权限	提出具体缺口和所需权限，不把“持续完成”解释成无限授权。

这些是建议的验证场景，并非本文已经执行过的测试。比较修改前后时，记录实际读了哪些文件、在哪里暂停、交付了什么，以及是否出现遗漏。若同一套技能供多种模型使用，也应分别验证，避免只对某一个模型有效的改写影响其他使用者。

原文与适用范围

这篇文章面向已经使用 Codex、并维护 Skills 或项目规则的读者。没有配置过自定义规则时，可以先从写清楚一次任务的交付结果入手，不需要为了应用指南额外安装一批技能。本文没有执行模型性能对比，也没有验证任何“精简后必然更快”的承诺。

官方原文：Rethinking skills and prompts for GPT-6 Astra
作者：Eric Provencher
页面日期：2026 年 9 月 11 日
原文地址：https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra