📄 本文翻译自 OpenAI Developers 官方博客 《Rethinking skills and prompts for GPT-6 Astra》 。
编码 Agent 已经走了很长一段路，最佳实践也在快速变化。随着模型能力越来越强，过去需要大量手把手引导和「脚手架」的工作，现在不再需要了。
如果你在过去一年里一直在项目中使用 Codex 这类 Agent，那么在引导模型产出好结果的过程中，你很可能积累了一大堆指令。每一次版本发布，都值得重新审视这些假设，而面对 GPT-6 Astra，这件事比以往任何时候都更重要。
这些指令有很多种形式：skills、AGENTS.md，以及你的任务提示词，它们都在塑造模型完成工作的方式。
更好的 skills
这些指令可以以 skills 的形式存在。skills 本质上是以 Markdown 文件存储的提示词，还可以连同资源和打包好的脚本一起分发。一般来说，它们最适用于围绕某个特定工作流程、或在使用某些应用时提供指导。
现在人们默认会把大量 skills 打包进项目里，每个 skill 都带有一个名称和描述，这些会被加载到模型的上下文中，好让模型知道什么时候该用它们。但很多描述太长了，而且当你添加了太多 skills 时，Codex 会开始缩短它们的描述来适应。最终模型看到的每个描述都变少了，也就更难判断该选哪个 skill。
更糟的是，这些描述常常互相矛盾，或者过度强调 skill 应该在什么时候被使用，导致模型加载了一些对当前任务其实没有帮助的指令。
创建 skills 的一个常见工作流，是使用 $skill-creator 这个 skill。我们最近更新了它的指导，以缓解我们在实践中见到的许多失败模式。
第一，skill 的描述应该尽可能短，同时清楚地说明模型应该在什么时候使用它：
说明它适用于什么场景
❌ 不好：创建并验证 Postgres 数据库结构迁移（schema migration）。在做任何与数据库、查询、模型或持久化相关的工作时使用。
✅ 好：创建并验证 Postgres 数据库结构迁移。在新增或修改迁移，或评审其上线时使用。
这里，糟糕的 skill 描述会让模型一碰到任何跟数据库相关的东西就想去用它，而不是只在需要处理迁移时才用。
第二，一个有用 skill 的关键标志之一是「渐进式披露」。阅读一个 skill 会占用上下文，让你更接近上下文压缩，还会引入可能不适用于当前任务的指导。对于那些包含多个工作流的 skills，应该把根文档做成一个极简的路由器，指向支撑文档和脚本。给模型足够的引导，让它知道该去哪里看，而不是强迫它去读当下无关紧要的东西。
第三，很多 skills 被写成了精心设计的行程表或菜谱。模型已经越来越擅长理解细微差别和模糊性，因此过去能帮上忙的过度具体的指导，现在反而可能妨碍结果。
仓库里的 skills 也会指导其他贡献者的 Agent，而那些 Agent 可能用的是不同的模型。对 Sol 或 Luna 有帮助的指导，可能会过度约束 GPT-6 Astra，所以要考虑清楚，你留下的这些指令会被哪些模型使用。
保持更新的 AGENTS.md
因为只要模型在你的仓库里工作，AGENTS.md 就会生效，所以你应该经常重新审视每一条指令，问自己它是否还有必要。
对于改一个错别字这种事来说，要求每次编辑前都读一堆文档或完整的仓库地图，实在太过分了。GPT-6 Astra 自己就能弄清楚该读什么，不需要被逼着在每次改动前都审查整个项目。
只读任务所需的内容
❌ 不好：每次编辑前，都要先读 architecture.md、database.md 和 deployment.md。
✅ 好：处理服务边界时参考 architecture.md，做 schema 变更时参考 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 根据本文讨论的内容做一次审计，然后去构建一些你以前不敢尝试的东西吧！