OpenAI 的 Eric Provencher 在本文中重新审视技能描述、AGENTS.md 与任务提示词：随着模型能力增强，过去有益的过度指导可能造成上下文膨胀、技能误选和不必要的停顿。文章给出了更精简的技能描述、渐进式披露、按任务读取文档、调整决策边界以及明确完成标准等实践建议。
原文：Rethinking skills and prompts for GPT-6 Astra
本文由 LobsterAI 自动翻译和发布。
中文译文
作者：Eric Provencher
原文日期：2026 年 9 月 11 日
原文：Rethinking skills and prompts for GPT-6 Astra
封面来源：OpenAI
编程智能体已经取得了长足进步，最佳实践也在迅速变化。随着模型能力增强，过去需要大量手把手引导和辅助框架的事情，现在已经不再需要了。
如果你在过去一年里一直使用 Codex 这样的智能体开发项目，那么在引导模型取得理想结果的过程中，你很可能已经积累了大量指令。每次新模型发布，都值得重新审视这些指令背后的假设；而到了 GPT-6 Astra，这件事比以往任何时候都更重要。
这些指令有多种形式：技能、AGENTS.md 和任务提示词，都在塑造模型完成工作的方式。
更好的技能
这些指令可以以技能的形式存在。技能本质上是存储在 Markdown 文件中的提示词，也可以与资源文件和脚本一起打包。一般来说，它们最适合用于指导特定工作流程，或特定应用的使用。
现在，人们习惯于在项目中加入大量技能。每个技能都有名称和描述，这些信息会被加载到模型上下文中，让模型知道何时使用它们。但许多描述实在太长；当技能数量过多时，Codex 就会开始缩短描述，以便将它们放进上下文。结果是，模型看到的每条描述都变少了，也更难判断该选择哪个技能。
更糟糕的是，这些描述往往还会彼此矛盾，或者过度强调应该使用技能的场景，导致模型加载对当前任务实际上没有帮助的指令。
一种常见的技能创建方式，是使用 $skill-creator 技能。我们最近更新了它的指导内容，以帮助减少实践中遇到的许多失败情况。
首先，技能描述应尽可能简短，同时明确说明模型应在什么情况下使用它。
明确适用场景
不好的写法：
创建并验证 Postgres 数据库结构迁移。在处理数据库、查询、模型或持久化相关工作时使用。
好的写法：
创建并验证 Postgres 数据库结构迁移。在新增或修改迁移，或审查迁移上线方案时使用。
在这个例子中，不好的描述可能会促使模型在接触任何与数据库有关的内容时都使用该技能，而不是仅在确实需要处理迁移时使用。
其次，有用技能的一个关键特征是渐进式披露。读取技能会占用上下文，让你更接近触发上下文压缩的阈值，还可能引入不适用于当前任务的指导。对于包含多个工作流程的技能，应让根文档成为一个精简的导航入口，指向配套文档和脚本。给模型足够的指引，让它知道去哪里查找，但不要强迫它阅读当下无关的内容。
第三，许多技能过去被写成了详尽的行程表或操作配方。如今，模型理解细微差别和模糊信息的能力已经大幅提升，因此，过去有帮助的过度具体的指导，现在反而可能妨碍结果。
仓库中的技能也会指导其他贡献者使用的智能体，而这些智能体可能采用不同的模型。对 Sol 或 Luna 有帮助的指导，可能会过度约束 GPT-6 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，明确允许它执行某个你已知安全的工作流程，例如本地测试套件：
本地测试使用可丢弃的测试数据，无法访问生产环境。运行测试，修复由本次请求的变更引起的失败，并重新运行受影响的测试，无须在每个步骤都征求许可。
决策边界
请特别注意你如何描述边界。如果以前的模型曾未经允许就替你做事，你可能加入了强硬措辞，要求它先询问。这可能有用，但 GPT-6 Astra 是我们迄今对齐程度最高的模型，判断力也强得多：除非确认安全，否则它不会执行任务。因此，你应该以符合这一特点的方式对待它。
如果你之前设置边界，是为了防止其他模型做得太过，而现在正切换到 GPT-6 Astra，那么可以考虑调整这些措辞：Astra 可能会过于严格地理解它们，在你其实希望它继续的地方停下工作。
持续推进
如果你习惯了 GPT-5.6 Sol 接到请求后长时间持续推进，那么 GPT-6 Astra 在判断何时停止时，可能会显得更谨慎。它可能完成第一版实现就回来请你审查，而此时其实还有工作没做完。
这时，在开始之前定义清楚“完成”的标准就很有帮助。你可能需要明确推动 Astra 持续工作，直到任务彻底完成。如果任务包括让实现运行起来、检查结果，以及修复失败之处，就把这些内容写进请求。要求它在完成第一版实现后停下来等待审查，会让模型更早停止，所以请确认：这真的是一个需要由你来做的决策吗？
如果你希望它在第一轮尝试后继续探索，就明确说明想探索什么，以及应该在哪里停止。
新模型的到来，是一次清理现有配置的好机会，但你无须手动审查所有内容：让 GPT-6 Astra 根据本文讨论的内容进行一次审查，然后去构建一些你以前根本不会尝试的东西吧！