为 GPT-6 Astra 重新思考 Skills 与 Prompt 设计规范
原文链接：Rethinking skills and prompts for GPT-6 Astra | OpenAI Developers
编程智能体（Coding agents）已经取得了长足的进步，最佳实践也在迅速变化。随着模型能力的不断增强，过去那些需要大量人工把手引导和脚手架约束的做法，如今已不再必要。
如果你在过去一年中一直在项目里使用 Codex 等智能体，为了引导模型输出理想的结果，你很可能积累了大量的指令。每次新模型发布时，重新审视这些前提假设都是值得的；但在 GPT-6 Astra 发布之际，这项工作比以往任何时候都更加重要。
这些指令可以表现为多种形式：Skills、AGENTS.md 以及你的任务 Prompt，它们都在共同塑造模型完成工作的方式。
打造更好的 Skills
这些指令可以以 Skills 的形式存在，其本质上是作为 Markdown 文件存储的提示词，同时也可以与资源以及打包的脚本捆绑在一起。通常情况下，它们在针对特定工作流提供指引、或在使用特定应用程序时最为有用。
现在人们习惯于在项目中打包大量的 Skills，每个 Skill 都带有一个名称和描述，这些内容会被加载到模型的上下文当中，以便模型知道何时使用它们。然而，许多 Skill 的描述都过于冗长；当你添加了过多的 Skills 时，Codex 会开始对描述进行截断以适应上下文。结果导致模型能看到的描述变少，反而更难判断该选用哪个 Skill。
更糟糕的是，不同 Skill 的描述之间经常会出现相互冲突，或者过分夸大了该 Skill 的适用范围，导致模型加载了对当前任务毫无帮助的指令。
创建 Skill 的一种常见工作流是使用 $skill-creator。我们最近更新了它的指引，以帮助缓解我们在实践中看到的诸多失效模式。
第一，Skill 的描述应当尽可能精炼，同时明确指出模型应在何时使用它：
明确适用时机
❌ 不推荐（Bad）：
创建并验证 Postgres 数据表迁移。在处理数据库、查询、数据模型或持久化相关工作时使用。推荐（Good）：
创建并验证 Postgres 数据表迁移。在添加、修改 migration 或审查其上线发布时使用。
在这里，不推荐的 Skill 描述会导致模型只要接触到与数据库相关的任何内容就尝试调用它，而不是仅在真正需要处理 migration 时才调用。
第二，一个实用 Skill 的关键标志之一是渐进式披露（Progressive disclosure）。
读取一个 Skill 会消耗上下文，这会让你更快触及上下文压缩上限，并引入可能并不适用于当前任务的指引。对于包含多个工作流的 Skill，应当将根文档设计为一个极简的“路由器（Router）”，指向辅助文档和脚本。给模型提供足够的指引让其知道该去哪里查找，而不要强迫它在当下读取无关的内容。
第三，过去的许多 Skill 都被写成了详尽的执行清单或配方。
现代模型在理解细微差别和模糊性方面已经强得多，因此过于具体的死板指引在过去或许有用，现在反而可能阻碍输出质量。
代码仓库中的 Skills 也会指导其他协作者的智能体，而他们可能会使用不同的模型。有助于 Sol 或 Luna 的指引可能会对 GPT-6 Astra 造成过度约束，因此在编写留存的指令时，请考虑未来会有哪些模型使用它们。
保持 AGENTS.md 的时效性
由于 AGENTS.md 在模型于仓库中工作的任何时候都会生效，因此你应该经常重新审视其中的每一条指令，并问问自己它是否仍然必要。
在每次修改代码前都强制要求阅读一堆文档或完整的仓库地图，对于仅仅修复一个拼写错误来说是极其过度的。GPT-6 Astra 能够自行推断出它需要阅读哪些内容，而不需要在每次改动前都被逼着通读整个项目。
按任务所需阅读
❌ 不推荐（Bad）：
在每次编辑前，先阅读 architecture.md、database.md 和 deployment.md。推荐（Good）：
在涉及服务边界时使用 architecture.md，在涉及数据表结构变更时使用 database.md，在准备部署时使用 deployment.md。
在每次编辑前都提示模型读取文件，是极易消耗上下文并拖慢工作进度的做法。不过，只要具备上下文针对性，指向某些文档仍然是有帮助的。同时请确保你的文档始终保持最新！
以前的模型需要外部鼓励才会去运行测试并检查自己的工作。GPT-6 Astra 自身就会主动完成这些事情，因此相同的催促指令反而会导致不必要的重复测试。
GPT-6 Astra 虽然严谨周密，但在推进任务的深入程度上可能会表现得较为谨慎，有时需要给它一点推动力来让它继续深入。你可以通过 AGENTS.md 针对已知安全的工作流向其下放权限，例如本地测试套件：
本地测试使用一次性测试夹具（fixtures），不具备生产访问权限。直接运行测试，修复由请求的变更引起的失败项，并重新运行受影响的测试，无需在每一步都请求批准。
决策边界（Decision boundaries）
请格外注意你描述边界的方式。如果以前的模型曾未经许可擅自替你做决定，你可能会添加强硬的措辞要求它“凡事必先询问”。这在过去是有用的，但 GPT-6 Astra 作为我们目前对齐程度最高的模型，具备好得多的判断力，除非它确认安全，否则不会擅自执行任务——因此你应该给予它相应的信任。
如果你之前制定严格边界是为了防止其他模型走得太远，而现在正切换到 GPT-6 Astra，建议重新调整这些表述：Astra 可能会过于严格地执行这些限制，在原本你乐意让它继续推进的地方停下工作。
任务持续性（Persistence）
如果你习惯了 GPT-5.6 Sol 接收到一个请求后能长时间自主持续执行，GPT-6 Astra 在何时停下方面可能会显得更为谨慎。它可能会在完成第一版实现后，就返回等待你的审查，哪怕后续仍有工作要做。
这就是在开始之前**明确定义“完成标准”**能够发挥作用的地方。你可能需要推动 Astra 持续执行直到彻底完工。如果任务包含让实现跑起来、检查运行结果并修复失败项，请把这些明确写进请求里。如果在第一版实现后要求停下等待审查，会把模型拉向更早的停止点，因此请检查这是否是你真正需要的人工介入决策。
如果你希望它在第一轮实现之外继续探索，请明确说明你希望探索的内容以及应该在何处停下。
一个新模型的到来是清理项目冗余指令的绝佳契机，而且你无需手动审查所有内容：直接让 GPT-6 Astra 根据本文讨论的要点对项目进行一次全面审计，然后放手去构建你以前未曾尝试过的全新事物吧！