模型变强了，去年堆的那套保姆式 「提示词」，很多在帮倒忙。
9 月 11 日，OpenAI 开发者团队发了这篇：想把 GPT-6 Astra 用顺，先扫一遍你的 skills、仓库根目录的 AGENTS.md，还有每次任务怎么下指令。作者是 Eric Provencher，博文标题就叫 Rethinking skills and prompts for GPT-6 Astra。
Astra 比去年那批模型更敢自己判断。你以前手把手写的「先读完这三份文档」「碰到数据库就用这个技能」，现在很容易撑爆上下文、互相打架，甚至让它该干时提前停手。官方意思很直接——指令该瘦身：触发写窄、相关时再加载说明，开工先说清「什么叫做完」。
OpenAI Developers：重看 skills、AGENTS.md 与任务提示
开发者博文：Rethinking skills and prompts for GPT-6 Astra
为啥现在要扫一遍
过去一年用 Codex 这类智能体（能自己多步干活的 AI），大家习惯往项目里塞说明：skills、仓库根目录的 AGENTS.md、每次任务提示。模型弱的时候，手把手有用；Astra 上来后，过多脚手架会撑爆上下文、互相打架，还可能让模型过早停手或乱加载技能。
Skills：短触发 + 渐进展开
Skill 本质是 Markdown 提示，还可打包资源和脚本，适合某个工作流或某类应用。名字和描述会进模型上下文，用来决定何时启用。描述太长、技能太多时，Codex 会压缩描述——每条都看不全，反而更难选对。
官方三条：
• 描述尽量短，但写清「什么时候用」。别写成一碰数据库就触发
• 渐进展开：多工作流时，根文档做极简路由器，指向附录和脚本，别一次全塞进上下文
• 别写成事无巨细的菜谱。过细的步骤现在可能拖后腿；还要想仓库里别的模型（旧模型 Sol / Luna）会不会被你的说明绑死
坏例子 vs 好例子（官方）：
坏：Create and validate Postgres schema migrations. Use when working with databases, queries, models, or persistence. 好：Create and validate Postgres schema migrations. Use when adding or changing a migration, or reviewing its rollout.
他们也更新了 $skill-creator，专门压这些踩坑。
官方对比：技能触发写窄一点
AGENTS.md：别每次全库预习
AGENTS.md 会在仓库里一直生效，要经常问：这条还要不要？
• 改个错别字却要求先读完 architecture / database / deployment——对 Astra 多余；它自己会判断读什么
• 坏：每次编辑前读完三份文档。好：按任务指向——服务边界看 architecture，改表结构看 database，准备发布看 deployment
• 以前要催模型跑测试；Astra 会自己查。还写「必须测」可能变成多余空转
Astra 细致，但有时对「做到哪算完」偏犹豫。你可以在 AGENTS.md 里给已知安全流程开绿灯，比如本地测试用一次性夹具、无生产权限：跑测、修这次改动引入的失败、重跑相关用例，中间别一步一请示。
边界与「做完」
决策边界：以前模型太敢干，你写了很多「先问我」。Astra 被说成对齐更好、不安全不会硬上——若你从别的模型切过来，过硬的刹车可能让它该继续时也停住。
持久性：习惯旧模型 Sol 一把梭的人，会觉得 Astra 更爱先交一版等你看。开工前写清完成标准——要实现、跑起来、看结果、修失败——就写进任务；若你其实不需要「第一版就停下来审」，别把那条要求留着，否则它会提前收工。想继续探索，就说清探索范围和停点。
怎么用这篇文章
作者收尾：新模型是打扫房间的好时机，不必全手工审——可以直接让 Astra 按这篇标准审计你的 skills / AGENTS.md / 提示词，然后去干以前不敢干的活。
对机智流读者：这不是发新品，是官方在说「Astra 时代的工程习惯」——少堆永久指令，多按任务加载；触发写窄；开工先定义做完。
链接
博文：https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra
官推：https://x.com/OpenAIDevs/status/2098480213244117065
Eric Provencher · 2026-09-11 · Codex / GPT-6 Astra
