这篇文章是公众号《GPT-6 Astra 更新了，你该先更新的是自己的提示词》的配套深读页，写给三种人：
- 想直接抄作业的——拿走下面的完整审查提示词，今晚就能跑；
- 想搞懂机制再动手的——看中间的深度解析，弄清楚每条建议到底在解决什么；
- 想核实原文、逐段精读的——翻到最下面，是原文全文中译（译自 Eric Provencher / @pvncher 的《Rethinking skills and prompts for GPT-6 Astra》）。
一、完整提示词（可直接复制）
提示词 A：给 Skill / AGENTS.md / 提示词体系做一次”规则体检”
用法：开一个全新的会话（别在旧会话里跑，旧上下文会干扰判断），把你所有的规则文件作为附件喂进去——Skill 文件夹、AGENTS.md、常用的系统提示词都行。下面的提示词整段复制即可：
你现在只做一件事：帮我审查我交给你的这批规则文件。全程只读，不要修改任何文件。
背景：我刚换到能力更强的模型。很多规则是当年为了约束旧模型写的——旧模型爱自作主张、需要手把手教、需要每步确认。新模型判断力更强，也会主动跑测试、主动检查结果。这些旧规则现在可能正在：① 白占上下文；② 诱导我误调用没用的 Skill；③ 把新模型的手脚绑住，让它停在我其实乐意让它继续的地方。
请按下面三份清单输出，每条都要引用具体文件、具体原文，并说明理由：
① 从未触发：哪些规则、哪些 Skill 描述，看起来从没被真正用过？（判断依据：规则内容非常具体到某个旧流程、某次事故，但你现在的工作流里已经没有那个场景了）
② 会误导误触发：哪些 Skill 的名字或描述写得太宽、太”表现自己”，会让模型碰到一点边就调用它，而不是在真正需要它的场景才调用？
③ 像旧模型的拐杖：哪些规则是在替模型做它现在已经会做的事——比如反复强调”记得跑测试""记得检查结果""每步都要问我""开工前先把全仓读一遍”？
输出格式：三份清单，每项 =
文件路径 + 原文摘录 + 一句话理由。最后单独给一行总结：如果要删，你建议从哪三条开始，为什么。注意：规范、交接、合规类的规则不属于”拐杖”，它们是底线，不要列进③。删拐杖，别拆承重墙。
提示词 B：给单个任务的”完成标准”补丁句
每次派活时，在任务末尾追加这句（可自行改写成你的场景）：
做完的标准是：让实现真正跑起来，检查结果，修掉你改出来的失败，再回来报告。完成第一版不要停下来等我——如果后面还有验证、修复或值得顺带探索的地方，做完再回来。
如果不想让它继续探索，就明确写死边界：
做完第一版、跑通验证就停，回来报告。不要继续扩展范围。
使用说明（三条纪律）
- 先备份再动手：体检前把规则目录提交一次 git，或整体复制一份。删错了能回滚，你才敢真删。
- ③ 先动，①②当参考：清单③（拐杖）是主要战果；①和②信息量大但噪音多，用来校准，别急着照单全收。
- 改完做一次回归：删完描述、改完 AGENTS.md 后，挑一个你最常用的任务原样跑一遍，看它是否还知道什么时候该读什么、什么时候该停。
二、深度解析：每条建议到底在解决什么问题
公众号文章为了能”今晚就跑”，把动作压缩成了四步。这里把机制讲透，免得你照做时不知道自己为什么这么做。
1. 两个伤要分开算：token 成本，和选择质量
Skill 的名字和描述常驻上下文——模型每次判断”要不要调用它”都要读一遍。这里其实有两个不同的伤：
- 真烧 token：假设你装了 30 个 Skill、每个描述 150 字，每次会话先背 4500 字。说实话，这点量对现在的模型不算致命——所以这不是重点。
- 真致命的：误触发：描述写宽了（“处理数据库、查询、模型时用”），模型碰点边就调它。更糟的是装得太多时，模型根本读不完所有描述，它只能看到每条的”截肢版”，于是开始瞎猜该调哪个。真正疼的不是那点 token，是它在错的时候调错东西。
这就是为什么改法不是”把描述写短一点”，而是”让描述只回答一个问题：什么时候才用你”。好的描述是触发条件，不是自我介绍。
2. 渐进披露（progressive disclosure）：根文档只做路由器
很多人以为 Skill 写得越全越好。恰恰相反——读规则本身就在消耗上下文，而且把当前任务用不上的指引也一起灌了进来。规范做法是”渐进披露”：
根文档 = 一张最小的路由器：用一两句话说清这个 Skill 覆盖哪些场景、什么情况下该去读哪个子文档。细节收在子文档里，用到才翻。
模型需要的不是”全部规则都在脑子里”，而是”知道该去哪找”。
3. 菜谱为什么现在有害：最佳粒度从”步骤”退到”原则”
很多老 Skill 是”逐步执行的菜谱”——当年模型把握不住模糊和语境，你得把每一步写死它才走得到终点。新模型对 nuance 和 ambiguity 的理解强了很多：
- 过度具体的指引，现在可能反而压制结果——它本来能自己判断最优路径，你却逼它按旧路径走；
- 规则会留给别的协作者和别的模型用（比如仓库里的 Skill 会指导贡献者的 agent，可能是不同模型）。能约束旧模型的规则，可能正好绑住新模型。写规则前想一句：这东西到底是谁在用？
4. AGENTS.md：从”每次全读”到”用到了才读”
AGENTS.md 是常驻宪法，管着模型每次干活前先读什么。最容易犯的错是让它”每次编辑前把 architecture.md、database.md、deployment.md 全读一遍”——为改一个 typo 烧掉整仓地图，纯属浪费。改成按情境指向：涉及服务边界才查架构文档、涉及表结构才查库文档、要部署才看部署文档。文档本身也要同步更新，否则指向的是过期信息。
至于”记得跑测试”这类强调：新模型本来就会主动跑测试、主动检查结果。同样的指令现在只会导致多余的测试、重复的劳动。但完全删掉也不对——把”催”改成”许可”才是正解：明确告诉它”本地测试用一次性夹具、碰不到生产环境，直接跑，修掉你改出来的失败，再重跑受影响的，不必每一步都来请示”。前者是唠叨，后者是放权。
5. 边界：你画的线，新模型会严格遵守
以前模型爱自作主张，你多半在配置里加了狠话：“没有我的批准不许 X”。这话对旧模型有用，对判断力更强的新模型是亲手给它上锁：它把你的边界当真，停在你其实乐意让它继续的地方，等你点头。检查你配置里的”批准""请示""等我确认”——每一条都问一遍：以它现在的能力，这条还需要吗？判断力强的模型，该给的是原则，不是每步审批。
6. 完成标准：它不知道”做完”长什么样
新模型有个反直觉的毛病：第一版做完就停下来回来找你，哪怕后面还有验证和修复。不是它懒，是它谨慎——它不确定你要不要它继续。解法不是骂它，是把”做完”定义进任务里（见提示词 B）。顺便检查你自己：那句”做完先回来给我 review”，是真的需要这个决策点，还是只是习惯？
7. 别删过头：区分”拐杖”和”承重墙”
规范、交接、合规类的规则不是上下文负担，是底线。一刀切删到”零规则”，换来的多半是事故——敏捷是幻觉。删拐杖，别拆承重墙。 换大版本模型时做一次季度体检，是给所有规则定”保质期”。
三、原文全译：Rethinking skills and prompts for GPT-6 Astra
译自 Eric Provencher（@pvncher）《Rethinking skills and prompts for GPT-6 Astra》。行内示例保留英文，方便对照；以下为译文与整理，观点请以作者原文为准。
为 GPT-6 Astra 重新思考你的技能与提示词
编程智能体（coding agents）已经走了很长的路，最佳实践也在快速变化。过去需要大量手把手引导和脚手架的事，现在已经不再需要了。
如果你在过去一年里一直在项目中使用智能体，你很可能已经积累了大量臃肿的指令——都是当年为了让模型走向好结果而加进去的。每一次新版本发布，都值得重新审视这些假设；而到了 GPT-6 Astra，这件事比以往任何时候都更重要。
这些指令可以有多种形态：Skills、AGENTS.md，以及你的任务提示词，都在塑造模型完成工作的方式。
Skill 文件
指令的一种形态是 Skill 文件——本质上是以 Markdown 文件形式存储的提示词，有时还捆绑了脚本。通常，它们最适合用来指导”模型只在某些任务上才需要的工作流”，或提供某个插件的使用说明。
很多人习惯往项目里下载一大堆 Skill，但这是个错误。每个 Skill 都带有一个名字和描述，会被加载进模型上下文，好让它知道什么时候该用。很多描述实在太长了，而当你塞进去太多 Skill 时，Codex 会开始缩短它们的描述来适配。模型最终看到的每条描述都更少，也就更难判断该选哪个 Skill。
更糟的是，描述之间可能互相矛盾，或者充满”选我选我”的气息，导致模型加载了对当前任务毫无帮助的指令。
如果你让 Codex 创建过 Skill，它大概用过 $skill-creator 这个 Skill。我们最近更新了它的指引，从几个方向上缓解我们在实践中看到的种种失败模式。
第一，Skill 描述应该尽可能短，同时清楚地说明模型什么时候该用它。这里那条糟糕的描述，会让模型在碰任何和数据库相关的东西时都想用这个 Skill，而它本应只在处理迁移时才被调用。
第二，一个好 Skill 的关键标志是渐进披露（progressive disclosure）。阅读 Skill 会占用上下文，让你更快逼近上下文压缩点，还会引入可能与当前任务无关的指引。对于包含多条工作流的 Skill，让根文档成为一张最小路由器，指向辅助文档和脚本——给模型足够的指引让它知道该往哪看，而不是逼它读当下无关紧要的东西。
第三，很多 Skill 被写成了详尽的行程表或菜谱。模型对细节和歧义的理解已经好太多了，所以过度具体的指引，在以前有帮助的地方，现在反而可能拖后腿。
仓库里的 Skill 还会指导其他贡献者的智能体——它们可能用的是不同的模型。对 Sol 或 Luna 有帮助的指引，可能过度约束了 GPT-6 Astra。所以，想一想你留下的这些指令到底会被哪些模型使用。
AGENTS.md
因为 AGENTS.md 在模型于你的仓库中工作时始终生效，请重新审视每一条指令，问问：这个任务真的还需要它吗？
每次编辑前都要求读一堆文档、或者读一遍全仓地图，对一个 typo 修复来说是过度的。GPT-6 Astra 自己就能搞清楚需要读什么，不需要被推着在每次改动前审查整个项目。
提示模型每次编辑前读文件，是烧上下文、拖慢工作的好办法。不过，指向某些文档仍然可能有帮助——只要它是按情境的。也别忘了保持文档更新！
以前的模型需要鼓励才会跑测试、检查自己的工作。GPT-6 Astra 会自己做这些，所以同样的指令可能导致不必要的测试。
GPT-6 Astra 很彻底，但它对”任务要做到什么程度”可能更保守。有时候它需要一点点推动才能继续。你可以在 AGENTS.md 里为某个你知道安全的具体工作流给它授权，比如本地测试套件：
本地测试使用一次性夹具，没有生产环境权限。运行它们，修复由你这次改动引起的失败，并重跑受影响的测试——每一步都不必请示批准。
决策边界
要非常小心你描述边界的方式。如果以前的模型未经允许就替你做了事，你可能加了很重的措辞让它先问。这可能有用，但 GPT-6 Astra 的判断力好得多，你应该这样对待它。它也会认真对待你画的边界，可能在你其实乐意让它继续的地方停下来。
持续性（Persistence）
如果你习惯了 GPT-5.6 Sol 接下一个请求后连续干很久，GPT-6 Astra 可能会让你觉得它在”什么时候该停”上更保守。它可能做出第一版实现后就回来找你 review，哪怕后面还有活没干完。
这时候，**开工前就定义”完成”**会很有帮助。如果任务包含”让实现跑起来、检查结果、修掉失败”，就把这些写进请求里。如果任务里写了”做完第一版就停下来等我 review”，就会把模型拉向更早的停点——所以检查一下：这个决策点真的是你需要做的吗？
如果你希望它越过第一版继续探索，就明确说出你想探索什么、它应该在哪里停。
一个新模型，是打扫你房间的好机会。让 GPT-6 Astra 基于这篇文章讨论的内容做一次审计，然后去做一件你以前不会尝试的事吧！
本文配套公众号：《GPT-6 Astra 更新了，你该先更新的是自己的提示词》（赛博飞鸟）。原文作者观点归原作者所有，译文与解析中的错误由译者负责。