重新思考 GPT-6 Astra 的 skills 和 prompt

Coding agents 已经走了很长一段路，最佳实践也迭代得很快。模型更强了，以前得大量手把手带、再搭一堆脚手架的事，现在往往不再需要了。

过去一年如果你一直用 Codex 这类 agent 做项目，多半已经攒了一大堆指令（用来提升模型往效果）。每次发新版本，这些假设都值得回头看一眼；到了 GPT-6 Astra，这件事比以往都更要紧。

这些指令可以有很多形态：skills、AGENTS.md，还有你的任务 prompt，都会塑造模型怎么把活干完。

更好的 skills

有些指令可以做成 skills：本质上就是存成 Markdown 的 prompt，还可以打包资源和附带脚本。一般最有用的场景，是某个具体工作流的指引，或者在用某些应用的时候。

现在大家默认会往项目里塞很多 skills，每个 skill 都有名字和描述，会进到模型的 context 里，让它知道什么时候该用。但很多描述写得太长；skills 一多，Codex 就会开始截短描述来塞进去。模型看到的每条描述更少，更难判断该挑哪个 skill。

更糟的是，描述之间经常互相打架，或者把「何时该用」说得过满，结果模型加载了一堆对当前任务其实没帮助的指令。

创建 skills 的常见做法是用 $skill-creator 这个 skill。我们最近更新了它的指引，用来缓解实践里见到的不少失败模式。

首先，skill 描述能短就短，但要让模型清楚什么时候该用：

举个例子，Skill 描述。

• 差的写法：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.（只在新增、修改 migration，或 review 它的上线过程时用。）

这里，差的 skill 描述会把模型往「只要碰到数据库相关的东西就用」上推，而不是只在真要处理 migration 的时候才用。

第二，有用的 skill 有个关键特征：progressive disclosure。读一份 skill 会占 context，让你更接近 compaction，还会塞进当前任务未必用得上的指引。如果一个 skill 覆盖多种工作流，根文档做成一个极简路由器，指向配套文档和脚本就行。给模型足够的线索让它知道去哪找，但别逼它把此刻无关的东西全读一遍。

第三，很多 skills 当初写成了详尽的行程单或菜谱。模型现在更擅长理解细微差别和模糊之处，所以过分具体的指引，以前能帮上忙，现在反而可能拖后腿。

仓库里的 skills 也会指导其他贡献者的 agent，而那些 agent 可能用的是不同模型。对 Sol 或 Luna 有帮助的指引，可能会把 GPT-6 Astra 约束得太死，所以写进去之前要想想，后面会有哪些模型来读这些指令。

保持 AGENTS.md³ 不过时

因为 AGENTS.md⁴ 会在模型进你仓库干活时始终生效，所以要经常回头看每条指令，问自己：这条还需要吗？

如果每次改动前都要求先读一摞文档或整份仓库地图，对改个 typo 来说太过分了（没必要）。

GPT-6 Astra 自己能判断该读什么，不用你推着它每次改之前把整个项目过一遍。

举个例子：AGENTS.md³ 的 context。不好的例子：Before every edit, read architecture.md⁵, database.md⁶, and deployment.md⁷.（每次编辑前都先读这三份。）好的例子：Use architecture.md⁵ for service boundaries, database.md⁶ for schema changes, and deployment.md⁷ when preparing a deployment.（architecture.md 看服务边界，database.md 看 schema 改动，deployment.md 在准备部署时用。）

用 prompt 让模型每次编辑前都先读文件，是烧掉 context、把活干慢的好办法。指向一些文档仍然有用，但得是按场景来的。文档本身也记得保持更新！

以前的模型需要你鼓励它跑测试、检查自己的活。GPT-6 Astra 自己就会做，所以同样的指令现在可能变成多余的测试。

GPT-6 Astra 很仔细，但在「这个任务该做到哪一步」上可能更犹豫。有时需要你轻轻推一把，让它继续。对你知道安全的特定工作流（比如本地测试套件），可以用 AGENTS.md 明确授权：

本地测试用的是一次性 fixtures，没有生产环境权限。直接跑，修掉这次改动引起的失败，再重跑受影响的测试，中间不用一步步征求批准。

决策边界

写边界的时候要特别小心。如果以前的模型会未经允许就替你干活，你可能加过很强硬的措辞，逼它先问一声。这仍然有用，但 GPT-6 Astra 是我们对齐最好的模型，判断力强得多，不确定安全就不会动手——所以你也该按这个前提来对待它。

如果你以前写边界是为了防止其他模型走太远，现在换成 GPT-6 Astra，考虑把那些措辞改一改：Astra 可能当真到过头，在你其实希望它继续的地方停下来。

把事情做完

如果你习惯了 GPT-5.6 Sol 接过请求就一路干很久，GPT-6 Astra 在「什么时候该停」上会显得更犹豫。它可能做到第一版实现就回来让你 review，但后面其实还有活没干完。

所以开工前先把「怎样算完成」说清楚会很有帮助。你可能需要推 Astra 一直做到真正完成为止。如果任务本身包括把实现跑起来、检查结果、修掉失败的地方，就把这些写进请求里。如果要求第一版实现之后就停下来等 review，模型会被拉向更早的停点，所以先确认这是不是你真的需要做的决定。

如果你希望它在第一轮之后继续探索，就说清楚要探索什么、在哪里停。

新模型是一次很好的大扫除机会，但你不必自己把所有东西过一遍：让 GPT-6 Astra 按这篇文章讨论的内容做一次审计，然后去造点你以前不会下手的东西！