Codex 发布了最新一版的使用焚决 ~~

大家好，我是DASOU

前不久，Codex 发布了最新一版的使用焚决~~

没开玩笑，确实属于焚决了

9 月 11 日，OpenAI 开发者博客发了一篇文章，标题是《Rethinking skills and prompts for GPT-6 Astra》。

直接给出了一个让人惊讶一个判断：

换到 Astra 以后，过去积累的 AGENTS.md、Skills 和任务提示词，哪些地方有必要重新检查一波。

嗯，挺有意思的一个发现文章。

今天花时间简单说下这个文章。

文章开篇第一句就很直接：

Coding agents have come a long way, and best practices are changing fast. With more capable models, what used to require a lot of handholding and scaffolding no longer does.

翻译过来就八个字： 过去那套脚手架，现在不用了。

GPT-6 Astra 有多牛其实不用我都说了，那么问题来了。

就是这样一个"更能干、也更守规矩"的模型，OpenAI 却转头劝开发者把攒了一年的提示词删薄。为什么？

第一刀：技能描述写长，等于让模型看不见

问题出在 skill（技能） 上。

在 OpenAI 的生态里，skill 本质是"存成 Markdown 文件的提示词"，可以打包资源和脚本，每个 skill 都带一个名称和描述。 这个描述会被加载进模型上下文 ，让模型知道什么时候该调用它。

于是第一类问题出现了：描述越写越长，技能越装越多，Codex 为了塞进上下文， 会自行把各条描述截短 。结果是模型看到的每条描述都更少，反而更难选对技能。

更麻烦的是第二类问题——描述之间会互相矛盾，或者过度强调自己的适用范围，把一堆当下用不上的指令塞进上下文，白白把模型推向压缩阈值。

官方给出的写法标准只有一条： 描述尽可能短，但必须让人一眼看清"什么时候用"。

反面写法 Create and validate Postgres schema migrations. Use when working with databases, queries, models, or persistence. 注解：创建并校验 Postgres schema 迁移；触发条件被写成了"只要涉及数据库、查询、模型或持久化就用它"。 官方推荐写法 Create and validate Postgres schema migrations. Use when adding or changing a migration, or reviewing its rollout. 注解：前半句不变，触发条件收窄为"新增或修改迁移、或审查迁移上线时"。

（这两句是要直接抄进技能文件的字面内容，所以保留英文原文；下同。）

差别在哪？反面写法把触发条件写成了"只要碰数据库相关的事就用它"，模型在任何涉及数据库的任务里都可能把它拉起来；改法是把触发时机收窄到一个 具体动作 ：新增或修改迁移、或者审查迁移上线。

第二条原则叫 渐进式披露（progressive disclosure） ，官方原话是：

一个有价值的技能，其关键标志之一就是渐进式披露。 原文：one of the key markers of a useful skill is progressive disclosure.

逻辑很朴素：读技能本身是要花上下文的，会让模型离压缩更近一步，还会引入一堆当下不适用的指导。所以对于包含多个工作流的技能，**根文档应该只做一个最小的"路由器"**，指向支撑文档和脚本——给模型足够的指引，让它知道该去哪儿看，而不是逼它一次读完。

第三条则戳中了很多人的习惯： 别再写食谱。

很多技能被写成了详尽的行程表或食谱。模型对细微差别和模糊表述的理解已经强得多，所以过于具体的指导，在过去帮上忙的地方，现在反而会拖累结果。 原文：many skills were written as elaborate itineraries or recipes. Models have gotten much better at understanding nuance and ambiguity, so overly specific guidance can now hinder results where it previously helped.

过去的模型需要手把手的步骤保证输出稳定；现在模型对细微差别和模糊表述的理解强了，**过细的步骤规定从"帮助"变成了"妨碍"**。

文章还补了一句容易被忽略的提醒：仓库里的技能文件不只服务于你的 agent，还会引导其他贡献者的 agent——而他们可能用着别的模型。

对 Sol 或 Luna 有帮助的指导，可能会过度约束 GPT-6 Astra——所以要想想，你留下的这些指令最终会被哪些模型读到。 原文：Guidance that helps Sol or Luna may overconstrain GPT-6 Astra, so consider which models will use the instructions you leave behind.

为 Sol 或 Luna 写的指导，放到 Astra 身上可能就成了过度约束。

第二刀：AGENTS.md 从"每次都读"改成"按需读"

AGENTS.md 的问题和 skill 同源——它作用于模型在你仓库里的每一次工作，所以每一条规则都该被反复问一句："现在还必要吗？"

官方的判断是： 为了修一个拼写错误而要求模型先读完一摞文档，是过度的。 原话是，Astra 能自己判断出它需要读什么，不需要被推着在每次改动前通读整个项目。

反面写法 Before every edit, read architecture.md, database.md, and deployment.md. 注解："每次改动之前，先读 architecture.md、database.md、deployment.md。" 官方推荐写法 Use architecture.md for service boundaries, database.md for schema changes, and deployment.md when preparing a deployment. 注解："改服务边界时看 architecture.md，改 schema 时看 database.md，准备部署时看 deployment.md。"

从"每次改动前必须读三份文档"，改成"做什么事读什么文档"。原文顺带补了一句：让模型在每次编辑前读文件，是烧上下文、拖慢速度的好办法。文档仍然可以指，但必须 是上下文相关的 ——而且这些文档自己也得保持更新。

这里有个反直觉的细节： 上一代模型需要被鼓励去跑测试、检查工作，而 Astra 会自己这么做。 所以同样那句"记得跑测试"，在新模型上会导致多余的测试。

但 Astra 也有反面——它足够细致，却在"要把任务推进到多远"上更犹豫，有时需要一点推力。官方建议在 AGENTS.md 里，为已知安全的具体工作流 明确授权 ：

本地测试用的是一次性 fixture，不接触生产环境。直接跑它们、修掉这次改动引起的失败、重跑受影响的测试，不必每一步都来征求批准。 原文：The local tests use disposable fixtures and have no production access. Run them, fix failures caused by the requested change, and rerun affected tests without asking for approval at each step.

本地测试不碰生产环境——那就直接告诉它：跑、修、重跑， 不必每一步都来请示 。

第三刀：最反直觉的一条，是把权限放宽

如果说前面是"删冗余"，这一条就是"松绑"。

文章指出，如果你曾经因为旧模型"擅自动手"而写下强硬措辞，让它凡事必须先问——那套话术现在要重新审视：

GPT-6 Astra 作为我们最对齐的模型，判断力要好得多，除非确认安全，否则不会去执行任务——所以你应该按这个前提来对待它。 原文：GPT-6 Astra, as our most aligned model, has much better judgment and will not perform tasks unless it knows it is safe – so you should treat it as such.

说白了就是： 把它当一个有判断力的模型来对待。 而那些为了阻止其他模型越界写下的措辞，Astra 可能会太当回事——

Astra 可能会把它执行得太字面，在你其实乐意看它继续干下去的地方停下来。 原文：Astra could take it too seriously and may stop work where you'd actually be happy for it to continue.

这条还有另一面： Astra 可能在"什么时候收工"上更保守。 如果你习惯了 GPT-5.6 Sol 接到任务后一口气跑很长一段，Astra 会让你有点不习惯——

它可能刚做出第一版就回来找你评审，而活其实还没干完。 原文：It may reach a first implementation and come back for your review while there's still work to do.

所以官方建议： 开工前先把"完成"定义清楚。

"做完第一版就停下来等我确认"这类要求，会把模型拉向一个更早的停止点——先想清楚，这个确认动作是不是你真的需要。 原文：A requirement to stop for review after the first implementation will pull the model toward an earlier stopping point, so check whether that's a decision you actually need to make.

如果任务本身就包含"跑起来、看结果、修错误"，那就把这部分明确写进请求里——否则那句"做完第一版等我确认"，会变成模型提前停手的理由。

Sol 与 Astra 同任务对比

△ 官方演示：同一个"做个人求职网站"的需求，左侧 GPT-5.6 Sol 跑了 13 分 15 秒直接交付，右侧 GPT-6 Astra 只跑了 20 秒就开始反问"你要转去什么方向"（图片 官方发布页）

这张官方对比图，恰好把"它更主动"和"它更爱问"这两面同时摊开了：左边 Sol 闷头干了 13 分钟直接交付成果；右边 Astra 20 秒就加载工具、跑命令、搜网页，然后转头问用户——你要转的是哪个方向？这个信息它能用上。

更强的判断力，同时也意味着更早地停下来确认。

结语

文章结尾，Eric Provencher 给了一句很"轻"的建议：

换个新模型，是清理旧规则的好时机；但不必手动逐条审， 让 Astra 依据这篇文章的思路先做一次审计 ——然后去做点你以前不敢碰的东西。

参考来源

• OpenAI Developers Blog：《Rethinking skills and prompts for GPT-6 Astra》，作者 Eric Provencher，2026 年 9 月 11 日

• OpenAI：《GPT-6 Astra: A new generation of intelligence》官方发布页