GPT-6 Astra 时代的 skills 与提示词：重新审视你的编码指令

Mon, 14 Sep 2026 17:30:00 +0800

📄 本文翻译自 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 被写成了精心设计的行程表或菜谱。模型已经越来越擅长理解细微差别和模糊性，因此过去能帮上忙的过度具体的指导，现在反而可能妨碍结果。

GPT-6 Astra on Codexer

GPT-6 Astra 时代的 skills 与提示词：重新审视你的编码指令

更好的 skills