转译：
译自 X 原标题：Rethinking skills and prompts for GPT-6 Astra
作者：Eric Provencher（@pvncher） ｜ 原文发布：2026年9月4日
编程智能体已经走了很长一段路，最佳实践变得很快。以前要大量手把手带着、搭很多脚手架才能做成的事，现在不再需要了。
如果你过去一年都在项目里用智能体，多半已经攒下一大堆臃肿的指令——那是你一路把模型往好结果上带的痕迹。每次发新版，这些假设都值得再过一遍；到了 GPT-6 Astra，这件事比以往任何时候都更重要。
这些指令可以有很多形态。Skill（技能文件）、AGENTS.md，以及你写的任务提示词，都会塑造模型怎么把活干完。
Skill 文件
指令的一种形态，是 Skill 文件：本质上就是存成 markdown 的提示词，有时还带着配套脚本。它们最有用的场景，通常是模型只在特定任务才需要的工作流指引，或某个插件的使用说明。
很多人默认往项目里塞一大堆 Skill，这是错的。每个 Skill 都有名称和描述，会先载入模型的上下文，好让它知道何时该用。很多描述写得太长；Skill 加多了，Codex 就会开始截短描述来塞进上下文。结果是模型每个描述都看得更少，更难判断该选哪一个。
更糟的是，描述之间可能互相打架，或者带着太重的「选我」劲头，导致模型加载了其实帮不上这次任务的指令。
如果你让 Codex 创建过 Skill，它多半用过 skill-creator 这个 Skill。我们最近更新了它的指引，专门对付实践中常见的几种失败模式。
第一，Skill 描述应尽可能短，同时让模型清楚何时该用。
这里，糟糕的 Skill 描述会把模型推向：只要碰到数据库相关的任何事就调用它；而它真正该用的时候，只是处理迁移。
第二，有用 Skill 的一个关键标志，是渐进式披露（progressive disclosure）。读一份 Skill 会占用上下文，让你更接近压缩（compaction，上下文被折叠成摘要），还可能引入跟当前任务无关的指引。Skill 里若有多条工作流，就把根文档做成一份最小路由器，指向配套文档和脚本。给模型足够信息，让它知道该往哪看，但不要强迫它读此刻用不上的东西。
第三，很多 Skill 写成了详尽的行程单或菜谱。模型现在更擅长理解细微差别和模糊之处，所以过度具体的指引，以前能帮忙，现在反而会拖后腿。
仓库里的 Skill 也会指导其他贡献者的智能体，而那些智能体可能用不同的模型。对 Sol 或 Luna（其他 Codex 模型）有帮助的指引，可能把 GPT-6 Astra 约束得太死。所以，想一想你留下的指令，会被哪些模型用到。
AGENTS.md
AGENTS.md 会在模型进入你的仓库干活时一律生效，所以每条指令都该再问一遍：这件事现在还需要吗？
修个错别字之前，先要求读完一摞文档或整份仓库地图，过头了。GPT-6 Astra 能自己判断该读什么，不必每次改动前都逼它先把整个项目过一遍。
每次改动前都提示模型先读文件，是烧掉上下文、把活拖慢的好办法。指向某些文档仍然有用，但前提是跟当前任务有关。文档本身也要保持更新。
以前的模型需要你鼓励它跑测试、检查自己的活。GPT-6 Astra 自己就会做，同样的指令现在可能变成多余的测试。
GPT-6 Astra 做事仔细，但对「这件事该做到哪一步」更犹豫。有时它需要你轻轻推一把，让它继续往前。你可以在 AGENTS.md 里给它开绿灯，允许它跑你知道安全的特定工作流，比如本地测试套件：
本地测试用的是一次性测试夹具，没有生产环境权限。直接跑，修由这次改动引起的失败，再重跑受影响的测试，不必每一步都来问我。
决策边界
仔细注意你怎么描述边界。如果以前的模型会在没得到许可时替你做事，你可能加过很硬的措辞，逼它先问。这仍然有用，但 GPT-6 Astra 的判断力好得多，你也该这样对待它。它会认真对待你设的边界，可能在你其实希望它继续的地方停下来。
持续性
如果你习惯了 GPT-5.6 Sol 接过请求就连干很长一段时间，GPT-6 Astra 在「何时该停」这件事上会显得更犹豫。它可能做到第一版实现，就回来让你看，而后面其实还有活要干。
这时候，开工前先定义「完成」会有帮助。如果任务包含把实现跑起来、检查结果、修好失败的地方，就把这些写进请求。如果要求第一版实现之后必须停下来等评审，模型就会更早停手——先确认这是不是你真的需要做的决定。
如果你希望它在第一轮之后继续探索，说清楚要探索什么、该在哪里停。
新模型是一次大扫除的好机会。让 GPT-6 Astra 按这篇文章讨论的内容做一次审计，然后去建一件你以前不敢下手的东西。