重新思考 GPT-6 Astra 的技能与提示词

核心意思

编码智能体已经进步很快，围绕它们的最佳实践也在变化。过去为了让模型稳定工作，我们往往会写很多“手把手”的说明、脚手架式流程和强约束规则；但模型能力增强之后，这些历史说明不一定还合适。

如果你过去一年一直在用 Codex 一类的智能体做项目，你的仓库里很可能已经积累了大量指导信息，例如 skills、AGENTS.md、任务提示词等。GPT-6 Astra 发布后，OpenAI 建议重新审视这些说明，因为它们会直接影响模型如何选择上下文、如何行动、何时停下，以及是否会被过时规则束缚。

更好的 Skills

Skills 本质上是保存为 Markdown 的提示词，也可以附带资源文件和脚本。它们最适合用于特定工作流，或者用于操作某些特定应用。

文章指出，现在很多项目会打包大量 skills。每个 skill 的名称和描述会先进入模型上下文，帮助模型判断是否需要加载它。但问题是：很多描述太长，skills 一多，Codex 为了放进上下文会缩短这些描述，结果模型看到的信息变少，反而更难判断该用哪个 skill。

更麻烦的是，skills 之间的描述可能彼此冲突，或者把触发条件写得太宽。这样模型会加载并不真正相关的说明，浪费上下文，还可能被错误流程带偏。

文章给出的改进方向是：

• Skill 描述应尽可能短，但必须清楚说明“什么时候该用”。
• 描述触发条件时要避免泛化。例如，一个关于 Postgres 迁移的 skill，不应让模型在任何数据库相关任务中都使用它；更合适的触发范围是新增、修改或审查迁移方案时使用。
• 好的 skill 要有“渐进披露”设计。读取 skill 会占用上下文，因此根文档应该像路由器一样，只告诉模型去哪里找相关材料，而不是一开始就塞入所有流程、背景和脚本说明。
• 对包含多个工作流的 skill，主文件保持精简，把细节拆到支持文档或脚本里。模型只在需要时继续读取。
• 过去那种非常详细的路线图式、菜谱式说明，在新模型上可能变成阻碍。GPT-6 Astra 更擅长理解模糊性和上下文，因此过度具体的步骤可能限制它的判断。
• 仓库中的 skills 可能也会被其他贡献者的智能体使用，而不同模型的行为不同。对 Sol 或 Luna 有帮助的约束，可能会过度限制 GPT-6 Astra。

保持 AGENTS.md 更新

AGENTS.md 会在模型处理仓库任务时生效，因此也需要定期回看。文章建议逐条检查里面的指令，问自己：这条现在还必要吗？

例如，要求模型在每次编辑前都阅读一堆架构文档、数据库文档、部署文档，对一个修错别字的任务来说就太重了。GPT-6 Astra 通常能够自己判断需要读哪些文件，不必每次都被要求先浏览全仓库或完整项目地图。

更好的写法是给出上下文式指引：

• 涉及服务边界时再看架构文档。
• 涉及 schema 或迁移时再看数据库文档。
• 准备部署时再看部署文档。

文章还提醒：过去的模型可能需要反复提醒“运行测试”“检查结果”。GPT-6 Astra 本身更倾向于验证工作，因此同样的旧指令可能导致过度测试，拖慢任务。

不过，GPT-6 Astra 也可能在“要不要继续往前做”这件事上更谨慎。它可能完成第一版实现后就回来让你审阅，而不是自动把后续修复、验证和打磨全做完。对于你确信安全的本地工作流，可以在 AGENTS.md 里明确给它权限，例如说明本地测试使用一次性 fixture、不会访问生产环境，并允许它直接运行测试、修复由本次改动引起的失败，再重跑相关测试。

重新校准决策边界

文章特别强调，要认真检查你如何描述“边界”。如果过去某个模型曾经未经允许替你做太多事，你可能在说明里加入了非常强的“先问再做”规则。这类规则有时有用，但在切换到 GPT-6 Astra 时可能需要放松。

OpenAI 将 Astra 描述为判断力更好、更对齐的模型。它通常不会在不确定安全性的情况下擅自推进。因此，如果旧边界只是为了防止早期模型越界，现在可能会让 Astra 过于保守，在你其实希望它继续完成的地方停下来。

实际做法是：保留真正重要的审批边界，例如生产环境、不可逆操作、外部付费资源、真实用户数据等；但对安全的本地开发、测试、格式化和可恢复修改，可以写得更明确、更可执行。

关于持续推进

如果你习惯 GPT-5.6 Sol 接到任务后长时间持续推进，GPT-6 Astra 可能会显得更容易停下来确认。它可能已经实现了第一版，但还没有运行、检查、修失败或完成收尾，就先回来请求审阅。

文章建议在任务开始前定义“完成”的含义。如果你希望它把实现跑起来、查看结果、修掉失败并再次验证，就把这些都写进请求里。相反，如果你写了“第一版完成后停下来给我看”，它就会更早停住。

如果你希望它在第一版之外继续探索，也要说明探索范围和停止条件。比如可以要求它比较两种方案、检查相邻模块影响、运行相关测试，但在涉及外部服务或生产资源前停下。

文章最后的建议是：新模型是清理提示词和仓库说明的好机会。你不必人工逐条检查所有规则，可以直接让 GPT-6 Astra 根据这篇文章的原则审计你的 skills、AGENTS.md 和常用提示词，然后把精力放到更有价值的构建任务上。

可执行清单

• 清点项目里的 skills、AGENTS.md 和常用任务提示词。
• 删除或缩短过长的 skill 描述。
• 把 skill 触发条件写窄，避免“任何相关任务都用它”。
• 将复杂 skill 改成“根文档路由 + 支持文档/脚本”的渐进披露结构。
• 删除要求模型每次都读完整项目地图的旧规则。
• 把文档阅读要求改成上下文式指引。
• 重新区分真正需要审批的高风险操作和可以自动推进的安全本地操作。
• 在任务提示中明确完成标准：实现、运行、检查、修复、验证、收尾。
• 如果要模型继续探索，说明探索范围和停止条件。

可直接复用的提示词模板

审计仓库说明

请根据“更短的 skill 描述、渐进披露、上下文式文档读取、清晰决策边界、明确完成标准”这些原则，审计本仓库的 skills、AGENTS.md 和常用任务提示词。请指出哪些说明已经过时、哪些会浪费上下文、哪些可能让 GPT-6 Astra 过早停止，并给出最小修改建议。

改写 Skill 描述

请把这个 skill 描述改得更短，并明确它的触发条件。目标是让模型只在真正需要该工作流时加载它，避免因为泛化描述而误触发。保留必要的边界条件，不要加入完整流程细节。

改写 AGENTS.md

请审查这个 AGENTS.md，把“每次都必须读取/执行”的规则改成上下文式规则。保留生产环境、不可逆操作、外部付费资源和真实用户数据相关的审批边界；对安全的本地测试、格式化和可恢复修改，给出明确的自动推进权限。

定义完成标准

请完成这个任务直到真正可验证：实现必要改动，运行相关本地检查，查看失败原因，修复由本次改动引起的问题，并重跑受影响测试。只有在遇到生产环境、不可逆操作、外部付费资源或缺少关键信息时才停下来确认。