目录
最近，OpenAI 开发者博客发了一篇文章：Rethinking skills and prompts for GPT-6 Astra。文章的建议可以概括为：在使用 GPT-6 Astra 时，重新检查 AGENTS.md 里的每一条指令是否还需要，把 Skill 的描述写到尽量短、只说明什么时候该用；过去那种保姆式的繁复微操，不必再照搬。
但如果你像我一样，平时并不是把 GPT-6 当成唯一的日常主力，而是日常开发主要用 Sol 和 Luna，盲目照搬官方建议、把本地规则“一刀切全删光”，很可能会让其他模型因为缺乏指引而出现明显的执行偏差。
如何在用上新一代模型能力的同时，兼顾多模型的稳定性？
这篇文章，我结合自己近期的实操记录、三模型分流策略和 Codex 里的本地规则，梳理一遍哪些要删、哪些要留。
一、为什么文章建议给 GPT-6 提示词做减法？
我理解这篇博文的核心论点是：当底层模型的长程规划和自主验证能力明显提升后，过去为了防止模型“降智”而写下的繁复微操规则，反而可能变成干扰。
在 5.6 或更早的模型阶段，大模型在复杂任务中容易出现发散、遗忘或执行偏差。为了让 Agent 稳定工作，开发者们习惯在 AGENTS.md、系统提示词和各种 Skills 里塞入很详细的步骤指令：从每一步的思考步骤、参数规范、异常处理，到冗长的格式约束。
在 GPT-6 Astra 这一代模型上，继续堆叠这些规则，我判断会带来三个问题。下面三点是我的判断，不是原文的结论，我也没有统计过 Token 消耗：
- 占用上下文：规则占据窗口，留给实际代码和业务上下文的空间就少了；
- 引发不必要的测试：文章的意思是，Astra 本身就会主动验证。如果规则里反复催促“必须运行测试”，就可能导致重复测试。后文 Skill 里“代码没变也要重跑”的要求，就是这一类；
- 过度约束：过细的流程会剥夺模型动态探索和自我纠错的空间。
这个“给规则做减法”的趋势并不是突然出现的：
- 5.6 时期，Agent 降智的讨论刚出来时，我写过上下两篇文章，讲规则过载怎样挤占上下文、拖累模型的执行与推理。当时我就建议对
AGENTS.md和 Skills 做极简瘦身和分层治理。 - GPT-6 发布后的实测：我把 GPT-6 当默认模型用了两天，又把 Codex 改回了 Sol／Medium，还为此写过一篇测评。我的一句判断是：GPT-6 的自主规划与推理已经很成熟，别把模型当傻子教。开工第一步不是给它写一堆微操规则，而是先让它审视本地环境，把阻碍它发挥的冗余流程砍掉。
- 另外，Anthropic 为 Claude Fable 5 写的提示词指南（2026 年 10 月核对）也有类似思路。它建议写清请求背后的目的，用简短指令代替逐条规定行为；它还提醒，为旧模型写的 Skill 往往过于死板，可能反而拖累输出质量。
二、千万别一刀切：多模型环境下的规则分流
这篇文章主要讨论 GPT-6 Astra。它也提醒，同一个仓库里的规则会被不同模型读取，给 Sol、Luna 写的指引，可能会把 Astra 约束得太细。
以我自己的日常工作流为例：在 VibeCoding 开发中，我的主力模型是以 Sol 和 Luna 为基准，在需要架构重构、复杂算法或深度推理时才切换到 GPT-6 Astra。所以只按 Astra 删规则不够，还要照顾另外两个模型。
我设计的是一套“向下兼容、向上释放”的分流方式：
| 适用范围 | 核心策略与实施方案 | 避坑重点 |
|---|---|---|
| 所有模型共用基准 | 清理重复冗余要求；准确收紧 Skills 的触发范围；按需加载文档；以真实产物为准检查。 | 同一条要求只维护一处，避免多处规则互相打架。 |
| Sol / Luna 主力工作流 | 保留简短但必要的执行步骤、验收清单（Checklist）、失败兜底处理与核心安全边界。 | 保持轻量可控，不堆砌长篇理论。 |
| GPT-6 Astra 任务 | 在明确授权范围内持续做到验收完成；减少固定步骤的逐轮停顿和重复验证。 | 写清完成条件和退出条件，避免首次实现后就停下来等指令。 |
三、针对 3D 与视觉任务的一段提示词
在前端页面、3D 渲染或视频编辑这类任务里，Vaibhav Srivastav（X 账号 @reach_vb）分享过一段提示词。他的说法是，让模型在工作中验证自己的产物，能显著提升最终成品的质量。这是他的个人经验，我没有独立测试过。
▲ Vaibhav Srivastav（@reach_vb）在 X 上分享的视觉任务验证提示语
提示词英文原文如下，与截图一致：
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，是要求模型在交付视觉产物前检查实际输出，而不只是确认代码写完了。模型是否真的照做，还是要看留下的截图、渲染或播放检查结果。
四、实操：把官方文章交给 Codex，检查本地 AGENTS.md
与其凭空猜测，不如直接让 AI 看自己的规则。我的做法是把 OpenAI 的博文链接发给 Codex，并说明多模型的使用情况。那次用的是 GPT-6 Astra 中推理（2026 年 9 月实测）。
我的提问大意是：Astra 不是我主要用的模型，我主要用的是 Sol 和 Luna，请结合这篇文章看看 AGENTS.md 和 Skills 该怎么调整；如果用 Astra，再加上 OpenAI 开发者建议的那段视觉验证提示语。
▲ 在 Codex 中，把官方文章和本地多模型使用情况一起交给它审查
Codex 读了原文，核对了本地全局 AGENTS.md，并抽查了调试、验证、设计和视频相关的几个 Skill。这次它只做审查，没有修改配置，也没有做模型对照测试。它的结论是：现有 AGENTS.md 已经比较合理，以 Sol、Luna 为基准的共同规则可以保留，小幅调整即可，暂时不必为三个模型各维护一套规则。它也说明，对 Sol、Luna 的安排是针对我们工作流的建议，不能当成已经验证过的模型性能结论。
Git 防护、生产数据隔离、用户授权和改动保护这些边界应该保留，不能因为换用 Astra 就删掉。Codex 建议的是合并和调整现有条款，而不是再追加一大段重复内容。它给出的主要是两处改动，下面是它的措辞：
▲ Codex 给出的产物检查与阶段推进调整建议
第一处：产物检查与证据复用
- 每个可独立验收的实质性改动完成后，执行覆盖其影响范围的检查。视觉任务必须检查实际产物：网页查看渲染截图并操作关键交互，3D 查看相关角度的渲染，视频检查播放效果、关键转场和音画同步。修复问题后重查受影响部分；无法检查的内容明确标为未验证。
- 检查已覆盖当前最终状态，且没有新增改动、失败或风险时，复用已有证据，不因再次汇报或进入下一步骤而重复运行。
第二处：阶段划分不等于每轮都停下来
- 在已授权范围内，连续完成实现、必要验证和问题修复；阶段划分用于组织工作与记录证据，不自动构成等待确认的节点。只有缺少影响结果的关键信息，或下一步超出授权时才暂停。
这两处建议我后来都写进了全局 AGENTS.md，措辞按自己的习惯做了调整。
五、几个具体 Skill 的问题
除了 AGENTS.md，Codex 在抽查中指出的 Skill 问题更具体。下面是它提出的问题和建议。注意，这是建议清单，并不代表全部 Skill 已经审计并修改完成。
verification-before-completion（完成前验证）- 问题：要求验证命令必须在“本条消息”里运行，容易导致代码没变也要重复跑测试；
- 建议：验证证据要对应当前最终状态，状态没变时可以复用已有证据。
systematic-debugging（系统化排障）- 问题：对任何 Bug 都会触发，正文 283 行，并要求逐阶段执行；
- 建议：入口保留复现、取证、定位、修复、验证，复杂排障方法改为按需读取。
test-scope-routing（测试范围路由）- 问题：已有按影响范围选择检查、避免重复运行的规则，但小任务也要求填写完整的规格和报告清单；
- 建议：保留路由思路，小任务不强制填写完整表格。
- 设计类 Skill（
huashu-design、gpt-taste）huashu-design：即使用户已经指定风格，仍要求给出三套方向并停下来等待选择。建议是只有用户要求比较或方向未定时，才给多套方案；gpt-taste：强制使用 AIDA、GSAP、大面积留白，并要求输出模拟 Python 随机执行的记录。建议是按用户明确选择的风格来，取消这类模拟记录，通用设计不自动套用固定样式。
这几处比“把 Skill 缩短一点”更具体：完成前验证改的是证据条件，排障改的是阅读时机，设计类改的是何时需要给出方案。
不过，这次的结果是抽查和建议。我还没有统计改完后少跑了多少次测试，也没有测量 Token 节省，这些要看后续任务的实际表现。
六、总结与自检清单
给 Agent 做减法，本质上是把人的精力从琐碎的过程微操，转移到目标定义、验收标准和核心边界上。
对照日常开发，可以检查下面几项：
- 提示词瘦身：
AGENTS.md里是否还有重复催促测试的规则？ - 多模型兼容：是否为 Sol、Luna 保留了简短明确的验收清单，而不是一刀切全删？
- 视觉任务保障：涉及 3D、前端或视频时，是否要求模型检查实际产物？
- 证据复用：是否把“测试命令强制重跑”改成了“产物状态未变时复用已有证据”？
- 流程拆分：复杂 Skill 的详细方法，是否改为按需加载？