Knowledge File / AI技能杠杆

2026-09-12 4 浏览免费阅读

GPT-6 Astra 需要更精简的提示与更少的护栏，OpenAI 如此建议

Q: 这篇文章和哪些AI专题相关？

它适合放在Agent工作流、AI工具、AI超级个体专题里阅读。 关联原因：这篇内容命中「Agent、智能体、工作流」等主题信号。；这篇内容命中「模型」等主题信号。；这篇内容命中「技能」等主题信号。

OpenAI 建议开发者在切换到 GPT-6 Astra 时重新审视技能描述、AGENTS.md 与任务提示：过长的技能描述、一刀切的阅读要求和僵化的审批规则会拖累模型，更聪明的模型需要更少的扶植，同时要提前把「完成」定义清楚。

SOURCE / AI技能杠杆 MIN / 9 ACCESS / 免费阅读 POST / 2026-09-12 21:10:11

原贴

查看原文

作者：Matthias Bastian 来源站点：the-decoder.com 原贴时间： 2026-09-12 21:10:11

原文

Overly long skill descriptions, blanket reading requirements, and rigid approval rules can get in GPT-6 Astra's way, according to OpenAI. The company recommends that developers tie instructions more tightly to specific tasks and define more clearly when the job is done. Instructions that have piled up over time can eat up context or cause GPT-6 Astra to stop work too early, writes OpenAI's Eric Provencher. He recommends reviewing skills, AGENTS.md , and task prompts whenever switching models. More capable models need less hand-holding, according to Provencher. That lines up with earlier advice from OpenAI on model transitions . Skills are prompts stored as Markdown files that can include resources and scripts. Provencher says they work best for specific workflows or applications. Their names and descriptions go into the model's context so Codex can pick the right skill for a given task. Ad Too many skills force Codex to truncate descriptions , stripping out information it needs to choose correctly. Conflicting descriptions or overly broad scope can also load instructions the model doesn't need, according to the blog post. Ad Provencher recommends keeping scope descriptions short and precise. A skill for Postgres schema migrations should only fire when creating or modifying a migration or when checking its rollout. If a skill covers multiple workflows, its main document should briefly point to the right supplementary docs and scripts, Provencher writes. That way the model only reads what it actually needs, since every extra read eats context and pushes it closer to summarization. Detailed step-by-step sequences can also slow down newer models, since they handle nuance and ambiguity better on their own, according to Provencher. But shared skills apply to every contributor's agents, so teams need to be careful. What works for Sol or Luna might already be too restrictive for someone running Astra. Ad The rules in AGENTS.md that govern repository work need regular reviews too, Provencher says. Requiring the model to read multiple documents or a full project overview before every change is overkill for a typo fix. Astra can figure out what it needs on its own. Instead of forcing it to read architecture.md , database.md , and deployment.md every time, Provencher suggests pointing to those docs selectively. Architecture info when working on service boundaries. Database docs when changing schemas. Deployment notes when shipping. The docs also need to stay current, he adds. Ad Explicit permissions can also cut down on repeated confirmation requests for safe operations, according to the post. For local tests using throwaway data with no production access, AGENTS.md can explicitly allow the agent to run tests, fix errors caused by the requested change, and re-run affected tests without asking again. Ad If earlier models went rogue and you locked things down with strict approval rules, Provencher says it's time to revisit those when switching to Astra. OpenAI credits the model with better judgment, but it can also interpret old restrictions so literally that it stops even when you want it to keep going. Known, safe workflows should be explicitly allowed, according to the post. Even without restrictions, Astra may stop earlier than GPT-5.6 Sol, Provencher notes. He recommends defining upfront what "done" means. If the agent should implement something, run it, check the results, and fix errors, all of that needs to be in the prompt. A requirement to check in after the first implementation sets an earlier stopping point. OpenAI recently published detailed prompting tips for GPT-6 Astra , and these skill and project instruction recommendations build on that guidance.

中文翻译

据 OpenAI 称，过长的技能描述、一刀切的阅读要求以及僵化的审批规则，会妨碍 GPT-6 Astra。该公司建议开发者把指令更紧密地绑定到具体任务上，并更清楚地定义工作何时算完成。OpenAI 的 Eric Provencher 写道，随时间堆积起来的指令会消耗上下文，或导致 GPT-6 Astra 过早停止工作。他建议每次切换模型时都检查技能、AGENTS.md 和任务提示。Provencher 表示，能力更强的模型需要更少的扶植。这与 OpenAI 此前关于模型迁移的建议一致。技能是以 Markdown 文件形式存储的提示，其中可以包含资源和脚本。Provencher 说，它们最适合特定的工作流或应用。它们的名称和描述会进入模型的上下文，以便 Codex 为给定任务挑选正确的技能。过多的技能会迫使 Codex 截断描述，从而剥离它正确选择所需的信息。根据该博文，相互冲突的描述或过于宽泛的范围，也会加载模型并不需要的指令。Provencher 建议保持范围描述简短而精确。一个用于 Postgres 模式迁移的技能，应该只在创建或修改迁移时、或检查其上线情况时触发。Provencher 写道，如果一个技能覆盖多个工作流，它的主文档应简要指向正确的补充文档和脚本。这样一来，模型只会读取它真正需要的内容，因为每一次额外的读取都会消耗上下文，并把它推向摘要化。据 Provencher 说，详细的逐步步骤序列也会拖慢较新的模型，因为它们自己就能更好地处理细微差别和模糊性。但共享技能适用于每个贡献者的智能体，所以团队需要小心。对 Sol 或 Luna 有效的东西，对运行 Astra 的人来说可能已经过于严格。Provencher 说，AGENTS.md 中管理仓库工作的规则也需要定期检查。要求模型在每次改动前阅读多份文档或完整项目概览，对于修复一个错别字来说属于过度要求。Astra 能自己弄清楚它需要什么。Provencher 建议，不要每次都强迫它读 architecture.md、database.md 和 deployment.md，而是有选择地指向这些文档。处理服务边界时给架构信息。修改模式时给数据库文档。发布时给部署说明。他补充说，这些文档也需要保持最新。根据该博文，显式权限也能减少对安全操作的重复确认请求。对于使用一次性数据、没有生产访问权限的本地测试，AGENTS.md 可以明确允许智能体运行测试、修复由所请求改动引发的错误，并在不再询问的情况下重新运行受影响的测试。Provencher 说，如果更早的模型失控过，而你用严格的审批规则把一切都锁死了，那么切换到 Astra 时就是重新审视这些规则的时候了。OpenAI 称该模型具有更好的判断力，但它也可能把旧的限制解释得过于字面，以至于在你希望它继续时停下来。根据该博文，已知且安全的工作流应被明确允许。Provencher 指出，即使没有限制，Astra 也可能比 GPT-5.6 Sol 更早停止。他建议提前定义「完成」意味着什么。如果智能体应当实现某项东西、运行它、检查结果并修复错误，那么所有这些都需要写进提示里。要求在第一轮实现后汇报，会设定一个更早的停止点。OpenAI 最近发布了针对 GPT-6 Astra 的详细提示技巧，而这些关于技能与项目指令的建议建立在那份指导之上。

核心信息

OpenAI 建议开发者在切换到 GPT-6 Astra 时重新审视技能描述、AGENTS.md 与任务提示：过长的技能描述、一刀切的阅读要求和僵化的审批规则会拖累模型，更聪明的模型需要更少的扶植，同时要提前把「完成」定义清楚。

OpenAI 建议开发者在切换到 GPT-6 Astra 时重新审视技能描述、AGENTS.md 与任务提示：过长的技能描述、一刀切的阅读要求和僵化的审批规则会拖累模型，更聪明的模型需要更少的扶植，同时要提前把「完成」定义清楚。
原贴提到：Overly long skill descriptions, blanket reading requirements, and rigid
来源：the-decoder.com

详细解读

这是什么信号

OpenAI 的 Eric Provencher 在一篇博文中给出了一组很具体的反向建议：当模型变强时，围绕它搭建的工程脚手架应该变薄，而不是变厚。被点名的三类「脚手架」是：过长的技能（skill）描述、要求模型每次都通读多份文档的一刀切阅读规则、以及为上一代模型设置的僵化审批限制。原文明确提到的现象包括：技能太多会迫使 Codex 截断描述，反而丢掉选对技能所需的信息；相互冲突或范围过宽的技能会加载无关指令；逐步操作清单会拖慢新模型；旧的审批规则可能被字面化执行，导致模型在你希望它继续时停下。

同时 Provencher 也给了一个容易被忽略的提醒：Astra 在没有限制的情况下，仍可能比 GPT-5.6 Sol 更早收工。所以「减负」并不等于「放任」，而是把约束从防跑偏的护栏，换成为「完成」下定义的验收标准。

为什么重要

过去两年，团队积累提示与规则的方式基本是加法：模型犯一次错就加一条规则，出错就再加一条。这套做法在模型能力较弱时是合理的，但它在两个层面产生复利式成本。第一是上下文成本：每一次多余的文件读取都占用上下文，把模型更快推向摘要与压缩，信息在压缩中失真。第二是行为成本：规则越多，模型越可能在规则边界上停下来请示，而不是把任务做完。

更关键的是共享层。技能和 AGENTS.md 通常服务于团队里所有人的智能体，一段为 Sol 或 Luna 写的限制，可能在别人跑 Astra 时已经变成不必要的枷锁。模型切换因此不只是换一个 API 名字，而是一次对既有提示资产的清算。

对谁有价值

正在把 Codex 类编程智能体接入团队仓库的工程负责人：这是直接可执行的清理清单。
维护 AGENTS.md、技能库、内部提示规范的人：需要建立随模型版本复审的机制。
做智能体平台或工具链的产品与工程团队：技能选择、描述截断、上下文预算都是产品级问题。
个人开发者：如果你的规则是照着旧模型的失败模式写的，升级模型时值得一并复查。

可以怎么行动

把技能范围写短、写准。原文给的判据很实用：一个 Postgres 模式迁移的技能，只在创建或修改迁移、或检查上线情况时触发。范围之外的不该触发。
一个技能覆盖多个工作流时，主文档只做指路，把细节留在补充文档和脚本里，让模型按需读取，而不是一次全读。
在 AGENTS.md 里把「每次改动前必读 architecture.md、database.md、deployment.md」改成按场景选择性指向：改服务边界看架构，改模式看数据库，发布看部署说明。原文直言，改个错别字还要求通读项目概览属于过度要求。
把逐步操作序列降级为约束或目标。新模型更能自己处理细微差别与模糊性，写死步骤反而拖慢它。
对已知且安全的操作显式授权。原文举例：使用一次性数据、无生产访问权限的本地测试，可以让智能体自行运行测试、修复由本次改动引发的错误、重跑受影响的测试，无需每次确认。
在提示里前置定义「完成」。如果期望是「实现—运行—检查结果—修复错误」，这四步都要写进提示；只要求「第一版实现后汇报」，等于人为设定了一个更早的停止点。
顺手清理文档时效。选择性指向的文档如果不更新，指向本身就是错的。

风险与限制

第一，减护栏的前提是模型判断力真的够。原文提到 OpenAI 对 Astra 的判断力有正面评价，但这属于厂方说法，团队应先用低风险任务验证，再放宽审批，而不是一次性解锁。

第二，共享技能是公共资产，个人放宽可能影响他人的智能体。原文明确提醒，对 Sol 或 Luna 有效的东西，对跑 Astra 的人可能已经过于严格——反过来也成立，为 Astra 精简的规则未必适配仍在跑旧模型的人。团队需要按模型版本分层管理，而不是只维护一份全局规则。

第三，Astra 可能更早停止，这不是靠删规则能解决的，需要靠更清楚的完成定义来补。删掉护栏的同时不补验收标准，风险不是跑偏，而是半途而废。

最后，这套建议来自 OpenAI 自家模型的提示实践，原文也提到它建立在 OpenAI 近期发布的 GPT-6 Astra 提示技巧之上。它更像一份经过验证的经验清单，而不是跨模型的通用规律；换用其他厂商模型时，需要重新做一次同样的审视。

信息差价值

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 the-decoder.com 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《GPT-6 Astra 需要更精简的提示与更少的护栏，OpenAI 如此建议》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

参考来源

Matthias Bastian 原帖

TOPIC HUBS

延伸专题

Agent工作流 Agent工作流：智能体、AI编程与自动化协作

这篇内容命中「Agent、智能体、工作流」等主题信号。

AI工具 AI工具：模型、插件、自动化与实战场景

这篇内容命中「模型」等主题信号。

AI超级个体 AI超级个体：个人品牌、效率系统与技能杠杆

这篇内容命中「技能」等主题信号。

AI SUMMARY

这篇文章回答了什么