你给 GPT-6 装的 Skills，可能正在帮倒忙

本文作者：sitin（@sitinme）。版权归作者所有，未经授权禁止转载。

“修改前，先把项目文档读完。”

“完成第一版后，等我确认再继续。”

这两句要求都能用，但如果不分任务、一律照办，就会有些麻烦。改一个错字，也要先阅读架构说明；已经交代要完成修改和检查的任务，做到第一版又停下来。

模型升级的时候，这些要求值得一起检查。

Eric Provencher 最近写了一篇关于 GPT-6 Astra 的文章，讨论的就是积攒下来的旧指令。OpenAI 的使用指南也明确提到，Astra 对 Skills、AGENTS.md 中的要求可能更敏感，含糊或冲突的指令可能让它提前停止。

AGENTS.md 保存的是项目规范和长期工作约定，Skills 保存的是某类任务的具体做法。模型换了，这些文件里的要求还在。以前为解决某个问题加上的一句话，是否仍然适合现在的任务，需要重新判断。

Skills 装得多，模型未必选得准

Skill 通常是一份 Markdown 说明，还可以附带脚本和参考资料。模型需要处理对应任务时，再读取里面的详细做法。

但在选择之前，它要先看到技能的名称和描述。

Eric 在原文中提到，如果装了太多技能，描述又写得很长，Codex 会缩短描述来适应上下文。原本用来说明适用场景的文字少了，模型反而更难判断该选哪一个。

描述写得宽，也会带来问题。原文举了一个数据库迁移技能的例子：它本来负责迁移，描述却把所有数据库相关任务都算了进去。

只是查看表结构，也可能加载一整套迁移说明。技能被调用了，里面的步骤却未必适合眼前这件事。

这种描述需要写清具体用途。例如，一项负责数据库迁移的技能，就说明它用于编写、检查迁移方案，不要笼统地写成处理一切数据库问题。

技能正文也一样。如果一份 Skill 同时包含几种流程，可以在入口说明怎样选择，把详细步骤放在对应的参考文件里。确定需要哪条流程，再读取哪份材料。

这样，模型在使用某项能力之前，不必先读完其他几种任务的操作手册。

AGENTS.md 里，留意那些“每次都要”

AGENTS.md 里的长期约定，影响范围比一次对话里的要求更广。

“每次修改前，阅读所有项目文档”，看起来很稳妥。可同一份规则既会遇到模块重构，也会遇到一处拼写修正。两件事需要的背景显然不同。

假设任务只是把按钮文案从“提交”改成“保存”，要求模型先阅读数据库设计和部署说明，就没有帮助。

这条规则可以改得具体一些：

修改前，先读取相关文件和项目约定。涉及跨模块调用或接口变化时，再补充对应模块的说明。

文档依然要读，只是阅读范围跟着任务变化。对真正需要的流程，具体步骤仍然可以保留。

测试也有类似情况。OpenAI 的 Astra 指南提醒，小任务可能引出超出需要的测试。如果规则里又规定每次都运行完整检查，就值得看看这项要求原本针对什么改动。

涉及重要逻辑时，相关验证当然要完成。检查已经通过，没有新的修改、报错或未解决的问题，就不必继续扩大范围。

“等我确认”，究竟要等在哪一步

有些要求影响的不是工作量，而是任务什么时候结束。

如果我们正在讨论方案，让模型先交一版设计、等待反馈，很合理。但已经确定方案，要求它完成修改和验证时，同一句“第一版完成后等待确认”就可能让工作提前停下。

这也是为什么一句“继续”有时只能解决眼前的停顿。真正需要讲清楚的是，这次任务包含哪些工作，哪些地方需要人来决定。

例如，一项已经确定范围的修改，可以这样交代：

完成这次修改，并运行相关检查。修复由本次修改引入的问题，复查通过后交付结果。如果遇到需要我决定的范围或方案变化，先说明具体问题。

这里的重点是把修改、检查和修复一起写进完成标准。发布、付费或改变任务范围等需要单独决定的事情，仍然保留相应的确认要求。

如果模型还是停在不合适的位置，就让它指出依据：哪份文件里的哪句话，怎样影响了这次任务。对照原文后，再决定要不要调整。

直接让 Codex 检查现有规则

在 Codex 中打开需要检查的项目，直接粘贴下面这段提示词即可：

请检查当前打开项目中的 AGENTS.md，以及与该项目相关的 Skills。只读取文件并输出报告，不修改文件，不执行技能里的脚本或业务操作。先列出检查范围，区分已读取的规则、仅发现存在的文件和未覆盖的内容。重点检查： 1. 技能描述是否把不相关任务也算进来，容易触发错误的流程。 2. 多流程技能是否要求一次读完所有材料，缺少按需读取的安排。 3. 是否无论任务大小，都要求阅读全部文档或运行全部检查。 4. 停止和确认条件是否冲突，或让已授权任务在第一版后提前结束。 5. 固定步骤是否有明确用途，还是限制了针对不同任务选择做法。每项发现给出文件位置、相关原文、可能的影响和修改建议。区分确定的问题和需要结合使用场景判断的建议，不凑问题数量。核对官方、团队和个人规则的来源，不把确认流程一概视为多余。不要读取或输出密钥、凭据内容；无法确认的地方明确说明。

报告里最值得看的，是具体哪句话影响了哪类任务。“建议优化”“可以精简”本身还不够，得能对着原文判断。

确认需要调整的部分，再让它修改，并用一项常做的任务验证。旧规则有用就保留，不合适就限定范围。体检完成的标准，是下一次处理任务时，能读到相关材料，也能按约定完成工作。