最近，OpenAI 官方开发者博客专门发了一篇重磅技术文章：《Rethinking skills and prompts for GPT-6 Astra》。
文章开宗明义地给所有开发者提出了一个反直觉的建议：在使用 GPT-6 Astra 时，需要彻底重构你的 AGENTS.md，并大幅简化各种 Skills 的描述与说明，不要再用过去那种保姆式的繁复微操指令去过度约束模型。
但如果你像我一样，平时并不是把 GPT-6 当成唯一的日常主力（比如日常高并发开发还重度依赖 Sol 和 Luna 这类高性价比模型），盲目照搬官方建议把本地规则“一刀切全删光”，很可能会让其他模型因为缺乏指引而出现明显的执行偏差。
如何在拥抱新一代模型推理红利的同时，兼顾多模型的稳定性？
今天这篇文章，我就结合自己近期的实操记录、三模型分流策略与 Codex 实际配置，手把手带你完成一次系统性的规则瘦身与避坑梳理。
一、 为什么 OpenAI 建议给 GPT-6 提示词“大瘦身”？
认真读完 OpenAI 的这篇官方博文，它的核心论点可以总结为一句话：当底层模型的长程规划与自主验证能力实现代际飞跃后，过去为了防止模型“降智”而编写的繁复微操规则，反而变成了阻碍模型发挥的噪音。
在以往 5.6 或更早的模型阶段，大模型在复杂任务中容易出现发散、遗忘或执行偏差。为了让 Agent 稳定工作，开发者们习惯在 AGENTS.md、系统提示词和各种 Skills 里塞入极其详尽的步骤指令：从每一步的思考步骤、参数规范、异常捕获，到冗长的格式约束。
但在 GPT-6 Astra 这一代模型中，继续堆叠海量冗余规则会带来三大副作用：
- 严重浪费 Token 与上下文：海量规则占据宝贵窗口，导致实际有效代码与业务上下文被挤压；
- 引发无意义的死循环测试：GPT-6 本身已经具备自动验证意识，如果在规则里反复强调“必须运行单测验证”，模型在收到重复催促后容易陷入“改一行代码 -> 跑全量测试 -> 再跑一次测试”的冗余循环，消耗大量额度；
- 过度约束与死板：过细的死板流程会剥夺模型的动态探索与自纠错能力。
其实，这个“给 Agent 规则做减法”的趋势并不是突然出现的：
- 在 5.6 模型时期与 Agent 降智现象出现时，我在之前的两篇文章《删了试试，AI降智秒解（上篇）》与《删了试试，AI降智秒解（下篇）》中，就已经系统分析过规则过载的弊端：冗余而死板的微操指令不仅无法提高稳定性，反而会吃满上下文窗口，导致模型的执行与推理能力出现断崖式下滑。当时我就建议大家对
AGENTS.md和 Skills 进行极简瘦身与分层治理； - 在 GPT-6 刚发布后的实测中，我在测评文章《把 GPT-6 当默认模型两天后，我把 Codex 改回了 Sol／Medium》里也明确提醒过大家：GPT-6 的自主规划与逻辑推理能力已经非常成熟，“别把模型当傻子教”。开工第一步不是盲目给它写一堆微操规则，而是先让它审视本地环境，把阻碍它发挥的冗余流程砍掉；
- 更早之前，在 Anthropic 推出 Claude Code 的 Fable 5 模型时，官方指南其实也强调过类似的原则：清晰定义目标和验收边界，减少对执行细节的保姆式微操。
二、 千万别一刀切！多模型环境下的规则分流矩阵
OpenAI 在博文中特别强调：这套“极简规则”主要是针对 GPT-6 Astra 的。
对于能力画像不同的模型（例如日常做高并发、日常补全、小步迭代的 Sol 和 Luna），如果直接把规则砍光，模型依然可能会因为缺乏明确的执行指引和验收标准而出现偏差。
以我自己的日常工作流为例：在日常 VibeCoding 开发中，我的主力模型是以 Sol 和 Luna 为基准，在需要架构重构、复杂算法或深度推理时才切换到 GPT-6。
这就要求我们设计一套向下兼容、向上释放的三模型规则分流矩阵：
| 适用范围 | 核心策略与实施方案 | 避坑重点 |
|---|---|---|
| 所有模型共用基准 | 清理重复冗余要求；准确收紧 Skills 的触发范围；按需加载文档；以真实产物为准检查。 | 严禁多处维护同质化规则，避免规则打架。 |
| Sol / Luna 主力工作流 | 保留简短但必要的执行步骤、验收清单（Checklist）、失败兜底处理与核心安全边界。 | 保持轻量可控，不堆砌繁复的长篇理论。 |
| GPT-6 (Astra) 任务 | 在明确授权范围内持续做到验收完成；大幅减少固定步骤的逐轮停顿与无意义重复验证。 | 避免首次实现后就停下来等指令，明确退出条件。 |
三、 针对 3D 与视觉任务：OpenAI 官方工程师的实用锦囊
在日常涉及前端页面、3D 渲染或视频编辑等任务时，OpenAI 工程师 Vaibhav Srivastav (@reach_vb) 分享了一条经过实战验证的提示词经验：让模型在工作流中必须对实际产物进行多角度验证，能显著提升成品质感。
▲ OpenAI 工程师 @reach_vb 推荐加入项目 agents.md 的视觉任务验证提示语
官方推荐的提示词英文原文如下：
Verify your work after each meaningful change. For visual tasks, inspect the actual output using browser screenshots, 3D renders from multiple angles, or video playback.
Fix issues and check again before finishing. Report anything you couldn't verify.
将这段提示词加入到你项目的 AGENTS.md 中，能确保模型在交付视觉产物时，自动调起浏览器截图、3D 多角度渲染或视频播放进行对比自检，而不是停留在“代码写完了但页面其实跑偏了”的假象里。
四、 实操演示：把官方指南扔给 Codex，微调本地 AGENTS.md
与其凭空猜测，不如直接让 AI 审视自己的规则。
我的实操方法非常简单：直接把 OpenAI 的官方博文链接发给 Codex，并告诉它我的多模型使用现状。为了保证评估的深度与严谨性，我将 Codex 的推理强度设定为 GPT-6 Astra（中推理）。
我的 Prompt 非常明确：
“看看这篇文章（OpenAI 官方博客链接），结合我们的情况：Astra 不是我主要用的模型，我主要用的是 Sol 和 Luna，看一下我们的 agents.md 和 skills 这些要怎么调整。此外如果是用 Astra，OpenAI 的开发者建议加上图片里的视觉验证提示语。”
▲ 在 Codex 中将 OpenAI 官方指南与本地多模型使用现状结合进行系统性评估
Codex 在通读原文、审查了本地全局 AGENTS.md 以及调试、验证、设计等相关 Skills 后，给出了具体的落地修改建议。
现有的核心保护边界（如 Git 防护、生产数据隔离、用户授权确认）必须严格保留，不能因为使用 Astra 就擅自删除安全红线。最终在 AGENTS.md 中补充的规则主要在以下两处：
▲ Codex 针对 AGENTS.md 产物检查与阶段流转给出的精准修改方案
补强一：细化产物验证与证据复用机制（避免重复测试浪费 Token）
- 每个可独立验收的实质性改动完成后，执行覆盖其影响范围的检查。视觉任务必须检查实际产物：网页查看渲染截图并操作关键交互，3D 查看相关角度的渲染，视频检查播放效果、关键转场和音画同步。修复问题后重查受影响部分；无法检查的内容明确标为未验证。
- 检查已覆盖当前最终状态，且没有新增改动、失败或风险时，复用已有证据，不因再次汇报或进入下一步骤而重复运行。
补强二：明确技术阶段划分不等于必须“轮轮停顿”
- 在已授权范围内，连续完成实现、必要验证和问题修复；阶段划分用于组织工作与记录证据，不自动构成等待确认的节点。只有缺少影响结果的关键信息，或下一步超出授权时才暂停。
五、 重点 Skills 的“瘦身避坑清单”
相比微调 AGENTS.md，对各类臃肿 Skill 的优化收益更为显著。在这次审查中，我们重点对 4 类典型 Skill 进行了精简：
verification-before-completion（完成前验证）：- 旧问题：死板要求验证命令必须在“本条消息内重新执行”，导致明明代码没变却反复重跑全量测试；
- 优化方案：改为“验证证据必须对应当前最终状态”；状态未变时直接复用已有测试证据。
systematic-debugging（系统化排障）：- 旧问题：哪怕遇到一个微小拼写错误也强制触发 283 行完整流程，逐阶段输出大篇幅报告；
- 优化方案：入口仅保留核心环节（复现 -> 取证 -> 定位 -> 修复 -> 验证），复杂排障方法改为二级按需读取。
test-scope-routing（测试范围路由）：- 旧问题：小任务也强迫填写冗长的测试规格与报表；
- 优化方案：小任务仅执行最小验证集，免除大篇幅格式化填表。
- 设计类与样式类 Skill（如
gpt-taste/huashu-design）：- 旧问题：即使开发者已经指定了明确的设计风格，依然强制生成三套方向并停轮等待确认，甚至强加复杂的模拟 Python 随机动效脚本；
- 优化方案：限定为“仅在用户要求比较或方向未定时提供多套方案”，已选定方向直接推进，取消花哨的模拟执行记录。
六、 总结与自检清单
给 Agent 做减法，本质上是将人类的精力从琐碎的过程微操，转移到目标定义、验收标准与核心边界的界定上。
针对日常开发，建议对照以下清单进行自查：
- 提示词瘦身：是否已清理
AGENTS.md中重复催促测试的规则？ - 多模型兼容：是否为 Sol / Luna 保留了简短明确的验收清单，而不是一刀切全删？
- 视觉任务保障：涉及 3D / 前端 / 视频时，是否已加入产物多角度截图与播放验证提示词？
- 证据复用：是否已将“测试命令强制重跑”优化为“产物状态未变时复用已有证据”？
- 流程解耦：复杂 Skill 是否已将详尽方法论改为二级按需加载？
互动交流： 你在日常使用 GPT-6 或其他主力模型时，有没有遇到过“重复测试浪费 Token”的情况？你最常用的提示词规则是哪一条？欢迎在评论区留言交流！
