开篇 · 一个反直觉的问题

新模型来了，
你辛辛苦苦攒的 Skill，还在帮你吗？

GPT-6 Astra 发布了。过去一年，你为了让模型听话，攒了一大堆 Skill、AGENTS.md 指令、复杂的任务 Prompt。

现在有个反直觉的事：那些曾经帮你「驯服」旧模型的东西，在新模型身上，很可能已经变成了拖累。

作者（Eric Provencher，OpenAI 的 Codex 团队成员）的原话：

「如果你在过去一年里一直在项目中使用 Agent，你很可能积累了一大堆臃肿的指令——为了把模型引导到好的结果上。每次新版本发布，都值得回头重新审视这些假设，而到了 GPT-6 Astra，这件事比以往任何时候都更重要。」

这堂课就是带你，一步步搞懂：哪些该删、哪些该留、哪些该改。全程动手，不是看文章。

第 1 课 · Skill 不是越多越好

你下载了一堆 Skill，模型反而更「瞎」了

每个 Skill 都带一个「名字 + 描述」，这些会被加载进模型的上下文，好让它知道「什么时候该用我」。问题是——

🎯 动手：往项目里塞 Skill，看会发生什么

模型能读到的「描述空间」是有限的。点击下面按钮，一次加一个 Skill，观察右边的描述被「压缩」成什么样。

上下文描述预算已占用：0%

👆 点我看「为什么会这样」

关键认知：Skill 是「按需加载」的引导，不是「越多越保险」。加一个 Skill，等于多占一份上下文、多一层选择干扰。

第 2 课 · 描述要短、要准

一个 Skill 描述，该写多长？

作者给了三条改 Skill 的原则，第一条就是：描述要尽可能短，同时说清楚「什么时候该用它」。

🎯 对比：两个「数据库」Skill 的描述

❌ 坏描述（太长、到处触发）

「这个 Skill 帮助你处理任何与数据库相关的工作。无论你是要查询数据库、插入数据、更新记录、删除数据、设计表结构、写迁移脚本、优化查询、调试连接问题，还是做任何涉及数据库的事情，你都可以使用这个 Skill。它涵盖了 SQL、NoSQL、ORM、连接池、事务……」

问题：模型一碰到任何「数据库」相关的东西就会加载它，哪怕只是问个字段名。

✅ 好描述（短、明确触发点）

「当需要编写或修改数据库迁移（migration）时使用。」

只在一个明确场景触发，不占多余上下文。

🎯 判断一下：下面哪条描述更合理？

对。第二条才是「短 + 明确触发」的正解。第一条什么都能干 = 什么场景都触发 = 白占上下文还干扰选择。

关键认知：一个 Skill 的价值，在于「让模型一眼知道何时该用它」——不是「覆盖得越全越好」。

第 3 课 · 渐进式披露

一个有用的 Skill，是「极简路由器」

读 Skill 会消耗上下文，把你推向 compaction（上下文压缩），还塞进跟当前任务无关的引导。作者的第二个原则：progressive disclosure（渐进式披露）。

🎯 结构对比

❌ 一根超长文档

Skill.md 里塞满了：工作流 A 的全部步骤 + 工作流 B 的全部步骤 + 工作流 C 的全部步骤 + 所有脚本说明……

模型一读就全读，哪怕只用到工作流 B 里的一个步骤。

✅ 极简根文档（路由器）

根文档只写：
「本 Skill 处理 X。有 3 个子流程：A（见 a.md）、B（见 b.md）、C（见 c.md）。只读你需要的那一个。」

模型先看路由，再按需只读相关子文档，不浪费上下文。

👆 点我看作者的原话

第三条原则：别写「过度具体的食谱」

很多 Skill 被写成繁琐的行程表。但模型现在对细微差别和歧义的理解已经强了很多——过去有帮助的「过度具体」，现在反而会妨碍结果。

还提醒一句：仓库里的 Skill 也会引导其他贡献者的 Agent（可能用不同模型）。对旧模型有帮助的引导，可能过度约束 Astra。要想想：你留下的指令，未来会被谁用。

第 4 课 · 逐条审视 AGENTS.md

那些「每次编辑前先读一堆文档」的规矩，还该要吗？

AGENTS.md 会在模型每次工作于你的仓库时生效。所以更要逐条问一句：这个任务还需要它吗？

🎯 判断：下面三条旧规矩，在新模型上「删 / 留 / 改」？

规矩 1：「每次编辑前，先读完整 repo map + 全部相关文档」

对。GPT-6 Astra 自己能判断该读什么，不需要被逼着每次改动前通读整个项目。逼它读文件 = 烧上下文、拖慢工作。可以改成「按情境指向相关文档」。

规矩 2：「每次改动后，必须运行测试并自查」

对。以前的模型需要鼓励才去跑测试，Astra 自己就会做，同样的指令反而导致「不必要的测试」。

规矩 3：一个你确定安全的工作流，模型却老停下来问你

对。Astra 很彻底，但在「一个任务要做到什么程度」上更犹豫。你可以用 AGENTS.md 给它授权一个你知道安全的工作流，比如本地测试：「运行测试、修复由本次改动导致的失败、重跑受影响测试，不必每步请求批准。」

关键认知：AGENTS.md 是「每次都会生效」的东西，所以它的每一条都在持续消耗上下文。定期问一句「这还必要吗」，比堆更多规矩更重要。

第 5 课 · 边界 & 完成标准

Astra 比你想象的更「谨慎」，也更「听得进边界」

① 决策边界：别再用「旧模型时代」的强语言

如果以前的模型老是在没经你允许时就擅自做事，你可能加了很强烈的措辞让它「先问」。这在当时有用。但 Astra 的判断力好得多，也会把你的边界当回事——它可能在你其实很乐意让它继续的地方停下来。

所以：重新审视你写的每一条「先问我」「禁止」「必须先确认」，问一句——这条现在还是我真正想要的吗？

② 持久性：开始前，先定义「完成」

如果你习惯了旧模型（Sol）拿到一个请求就长时间连跑，那 Astra 在「什么时候停」上会显得更犹豫：它可能做出第一版，就回来找你评审——尽管还有活没干完。

👆 点我看「正确写法」

关键认知：新模型的「停」和「走」，很大程度上由你的边界描述和完成定义决定。与其怪它「不主动」，不如先把自己的意图写清楚。

结业 · 测一测

你真的懂了吗？

Q1. 为什么「下载一堆 Skill」是个错误？

对。Skill 太多 → 描述被压缩 → 模型看到更少的字 → 更难判断选哪个，还可能加载无用甚至矛盾的指令。

Q2. 「渐进式披露」指的是？

对。渐进式披露 = 先给路由，按需展开，不浪费上下文读无关内容。

Q3. Astra 做了一半就回来找你评审，最可能的原因是？

对。Astra 在「何时停」上更犹豫，倾向于做出第一版就停。需要你在请求里明确「完成」的标准。
恭喜
🎓

你抓住了这篇文章的核心

模型每进化一代，就该回头删一轮旧指令。你的 Skill 和 Prompt，不是资产，是会过期的负债。

一句话带走的 5 个结论

1️⃣ Skill 不是越多越好——描述会被压缩、互相干扰。

2️⃣ 描述要「短 + 明确触发点」，别写「万能」。

3️⃣ 根文档做成极简路由器，按需展开（渐进式披露）。

4️⃣ AGENTS.md 逐条审视：删掉「每次读全项目」「催它跑测试」这类旧规矩。

5️⃣ 重新写边界 + 定义「完成」——新模型更听得进边界，也更需要你说清停在哪。

原文：《Rethinking skills and prompts for GPT-6 Astra》by Eric Provencher（@pvncher）

本页为互动教学演示，基于 Eric Provencher (@pvncher) 的原文 提炼整理，仅供学习。