编者摘要：GPT-6 Astra 模型能力、判断力与对齐度大幅升级，原有适配旧模型的技能规则、AGENTS.md 配置和任务提示词已不再适用，极易造成上下文臃肿、执行保守、效率低下。本次优化核心是做“减法与适配升级”。技能层面，需摒弃冗长宽泛的描述，精简文字、精准界定适用场景，避免多技能冲突与模型识别偏差；复杂技能采用渐进式披露设计，以极简根文档做路由，减少无效上下文加载，同时删除过度细化的流程约束，适配新模型的自主理解能力。AGENTS.md 需要全面减负，取消所有编辑前强制通读全量文档的规则，改为场景化按需引用；移除冗余测试指令，针对本地安全测试下放执行权限，同时放宽旧模型的严格边界限制，避免Astra过度保守、中途停工。任务执行上，Astra相比旧模型更谨慎，易初稿完成后提前终止，因此任务需提前明确完整完成标准、探索范围和终止条件。整体优化核心：告别老旧冗余规则，贴合Astra高判断力、高自主性特性，精简上下文、明确执行边界，大幅提升代码智能体工作效率.
10主要问题问与答
Q1. 为什么要专门适配GPT-6 Astra的规则？答：Astra对齐度、判断力、自主能力远超旧模型，旧模型的冗余、强约束规则，会导致其执行保守、上下文臃肿、工作效率下降。
Q2. 旧技能描述最大的问题是什么？答：描述宽泛冗长、场景界定模糊，多技能易冲突，模型会自动压缩内容，导致技能识别、调用精准度大幅降低。
Q3. 优质的技能描述标准是什么？答：文字极简，不写泛化场景，只精准写明技能具体适用时机与触发条件。
Q4. 什么是技能的渐进式披露设计？答：复杂技能用极简根文档做路由，指向配套文档脚本，让模型按需查阅，不一次性加载无效上下文。
Q5. AGENTS.md最需要删除的旧规则是什么？答：所有代码编辑前强制通读架构、数据库、部署等全量文档的全局硬性规则。
Q6. Astra是否需要人工指令督促测试自查？答：不需要，Astra可自动完成测试、自查纠错，原有督促指令只会造成无效重复操作。
Q7. 为什么要放宽旧模型的决策边界限制？答：Astra安全性、判断力更强，严苛的旧限制会让它过度谨慎，在合理场景下中途停止工作。
Q8. Astra相比旧模型的典型执行特点是什么？答：做事严谨但偏保守，完成初稿后容易主动暂停，等待人工审核，不会自主完成全流程工作。
Q9. 如何解决Astra中途停工的问题？答：任务初始明确完整完成标准、探索范围和终止条件，要求模型一次性闭环所有工作。
Q10. 本次整体优化的核心逻辑是什么？答：精简冗余指令、场景化适配规则、下放安全操作权限、明确任务闭环标准，适配Astra高自主、高对齐的模型特性。
附录 重新思考 GPT-6 Astra 的技能与提示词 2026 年 9 月 11 日｜Codex
重新梳理技能描述、AGENTS.md 文件以及任务提示词，避免上下文膨胀。 作者：Eric Provencher
代码智能体已经发展了很长一段时间，最佳实践也在快速迭代。随着模型能力变强，过去需要大量引导和脚手架才能完成的工作，如今不再需要。
如果你在过去一年里，一直在项目中使用 Codex 这类智能体，大概率积累了大量指令，用来引导模型产出合格结果。每次模型版本更新，都值得重新审视这些预设逻辑；而对于 GPT-6 Astra，这件事尤为重要。
这些指令有多种形式：技能（skills）、AGENTS.md 和任务提示词，都会影响模型执行任务的方式。
优化技能（Skills）
技能本质上是以 Markdown 文件存储的提示词，还可以附带资源、打包脚本。一般来说，它最适合用于特定工作流指引，或是搭配某些应用使用。
现在大家习惯在项目里打包大量技能，每个技能都带有名称和描述，加载进模型上下文，让模型知道何时调用。但很多技能描述写得过长；当技能数量太多时，Codex 会自动压缩描述文本以适配上下文。模型最终只能读到残缺的描述，难以判断该选用哪个技能。
更糟的是，不同技能描述之间还可能互相冲突，或是过度强调触发条件，导致模型加载对当前任务毫无帮助的指令。
创建技能常用的工作流是调用 $skill-creator技能。我们最近更新了它的指引，用来解决实践中遇到的各类失效问题。
原则 1：技能描述尽量简短，清晰写明适用场景
❌ 较差示例： 创建并校验 Postgres 数据库结构迁移脚本。适用于处理数据库、查询语句、数据模型或持久化存储相关工作。
✅ 较好示例： 创建并校验 Postgres 数据库结构迁移脚本。在新增 / 修改迁移脚本，或审核迁移上线流程时使用。
差的示例会让模型只要碰到任何数据库相关操作就触发该技能，而不是只在处理迁移任务时启用。
原则 2：渐进式披露信息，是优质技能的核心特征
读取技能内容会占用上下文空间，容易触发上下文压缩，还会引入和当前任务无关的指引。 对于包含多条子流程的技能：根文档只做极简路由，指向配套文档与脚本。只给模型足够信息，让它知道去哪里查阅资料，而不是强制它一次性读取所有无关内容。
原则 3：不要再写过于详尽的流程清单
过去很多技能被写成事无巨细的操作步骤。现在模型对细节、模糊场景的理解能力大幅提升，过去有用的强约束指引，如今反而会拖累效果。
仓库内的技能同时也会给其他开发者的智能体使用，而对方可能用别的模型。适合 Sol、Luna 的指引，可能会对 GPT-6 Astra 造成过度约束。编写指令时，要考虑哪些模型会读取这份文档。
保持 AGENTS.md 与时俱进
AGENTS.md 的规则会在模型操作代码仓库时全程生效，需要定期逐条复核指令，判断是否还有保留的必要。
比如仅仅修正一个打字错误，就要求模型先读取一堆文档、完整仓库地图，这就属于过度要求。GPT-6 Astra 能够自行判断需要读取哪些内容，不必在每次修改代码前通读整个项目。
❌ 较差示例：每次编辑代码前，必须阅读 architecture.md、database.md 和 deployment.md。
✅ 较好示例： 服务边界参考 architecture.md；修改数据表结构时参考 database.md；准备上线部署时参考 deployment.md。
强制模型每次改代码前读取文件，会快速耗尽上下文、拖慢工作速度。但基于场景去引用文档依然有用，前提是做到按需引用。同时也要保证文档本身是最新的！
旧版本模型需要反复提示，才会主动运行测试、自查结果。GPT-6 Astra 会自动完成这些工作，沿用旧指令只会产生不必要的重复测试。
GPT-6 Astra 做事严谨，但在任务推进的程度上会比较保守。有时候需要稍加推动，让它继续往下做。你可以在 AGENTS.md 里授权某些安全的工作流，例如本地测试套件：
本地测试使用临时测试数据，不会访问生产环境。直接运行测试，修复本次代码变更引发的失败用例，并且重新执行受影响的测试，每一步无需等待审批。
决策边界的描述
仔细斟酌边界规则的写法。过去的模型会未经许可擅自操作，所以大家会写强硬措辞，强制模型先询问。这类写法曾经有用，但 GPT-6 Astra 是对齐程度最高的版本，判断力更强，只有确认安全才会执行任务，因此要按它的特性调整规则。
如果你之前写边界限制，是为了防止旧模型越权操作，现在切换到 GPT-6 Astra，建议修改这类表述：Astra 会严格遵守限制，可能在你希望它继续推进的地方直接停止工作。
任务持续性
如果你习惯了 GPT-5.6 Sol 接到任务后持续长时间执行，会发现 GPT-6 Astra 更容易中途停下。它完成第一版实现后，就会停下来等待你的审核，即便还有后续工作没做完。
解决办法：在任务开始前就定义好完成标准。你需要推动 Astra，直到任务完整落地。如果任务要求包含：代码实现、验证运行效果、修复报错，要把这些写进任务请求。 如果设置了 “完成初稿后必须暂停等待审核”，模型就会倾向于提前终止。你要确认这个暂停规则是否真的必要。
如果你希望模型在初稿完成后继续深入探索，要写明需要探索的内容，以及停止条件。
换新模型正是清理旧规则的好时机，但不必全部人工复核：你可以让 GPT-6 Astra 根据本文思路做一次审计，然后去尝试开发以前不敢动手的项目！
核心要点提炼（方便快速回顾）
- 技能（Skills）
-
描述精简，只写触发场景，不要宽泛描述； -
多子流程技能采用「根路由文档 + 附属文档」，渐进加载信息，减少上下文占用； -
抛弃冗余步骤化指令，模型现在能处理模糊场景； -
考虑多模型兼容，避免规则对 Astra 过度约束。 - AGENTS.md
-
删除全局强制读取所有文档的旧规则，改为按需引用； -
移除强制重复测试指令（Astra 自带自检）； -
给安全操作（本地测试）下放权限； -
放宽旧的强硬边界限制，防止 Astra 过度保守、提前终止。 - 任务提示词
-
任务开头明确定义「完成标准」； -
指定探索范围与终止条件，解决 Astra 容易中途停住的问题。