Astra 都升级了，你的旧规则还在指挥它：把这篇交给 Codex 自检

模型升级了，使用体验却未必一起升级。

改一行字，先读半个仓库；明明已经说了“做完”，它做到一半又问你是否继续；测试通过了，还在不断追加检查。任务迟迟没交，额度先掉了一截。

碰到这些情况，值得检查你给它装过的 Skills，以及 AGENTS.md 里那些越攒越多的规则。

这篇先讲清楚为什么，再给一套完整执行方案。你可以收藏，把文章链接或全文交给有项目文件访问能力的 Codex，让它根据你自己的配置处理。

你攒下来的规则，带着过去模型的毛病。

以前模型总是不测试，你补一句“每次修改都必须测试”。

以前它漏读项目说明，你补一句“动手前必须完整阅读”。

以前它越过你直接做决定，你补一句“任何操作都先确认”。

每条规则单独看，都有来由。但它们未必写清了适用范围，也未必会随着模型升级自动失效。

修业务逻辑，需要测试。改一处错别字，可能只需要检查修改结果。一句“所有修改都必须跑完整测试”，把这两种任务绑在了同一套流程里。

一个普通的本地任务，你可能已经授权它完成。但另一份旧规则又要求“每一步得到用户确认”。它越认真遵守，你越容易觉得它不肯干活。

这些停顿可能有规则上的原因。当然，缺少权限、工具故障、需求确实不清楚，也会造成类似现象。所以清理必须从具体依据开始。

Skill 的成本，从它被选中之前就开始了。

@pvncher 在《Rethinking skills and prompts for GPT-6 Astra》中提醒，Skill 的名称和描述会进入模型上下文，帮助它决定什么时候调用。

描述如果写成“所有涉及代码的任务都必须使用”，一个很小的改动也可能触发一整套流程。多个 Skill 都想接管同一任务，模型还要处理它们各自的要求。

选中之后，如果根文件又塞满所有场景的步骤，它还会读入当前根本用不到的内容。

所以，检查重点有两个：这个 Skill 什么时候应该出现？出现之后，哪些内容是当前确实需要读的？

有价值的专业步骤应该保留。只在某一类任务里用到的细节，可以放到参考文件，由入口说明何时读取。必要指令表达一次，比在几个地方重复强调更容易维护。

模型换了，任务的完成标准也值得重写。

“完成代码后交给我审阅”和“把功能跑通、检查结果、修复本次问题后交付”，是两个不同的终点。

如果你真正要的是后者，却一直用前者约束它，再强的模型也可能停在第一版。

把任务终点写清楚，把常规工作和需要你决定的事项分开，才有办法减少无必要的等待。简单加一句“永远不要问我”，反而会把本来该保留的决策边界一起抹掉。

这次清理，成功标准是工作做得更顺，而不是文档删得更多。

先找出：哪条规则，在什么任务里，造成了什么无必要的动作。

然后只修改有依据的问题，保留产品要求、业务流程、权限边界和验收标准。最后用一个有代表性的任务检查结果：有没有完整交付，有没有漏掉必要检查，是否减少了重复阅读和确认。

没有实际用量对照，就不要把“文件短了30%”说成“省了30%额度”。

下面这套方案把检查、修改和验证放在了一起。它是依据上述资料整理的执行模板，尚未做跨项目实测，不保证每个项目都有问题，也不保证固定节省比例。

交给你的 Agent 执行

打开你要优化的项目，把本文链接或全文发给 Codex，再加一句：

请按本文的执行方案，检查并优化当前项目实际使用的 AGENTS.md 和 Skills。

如果它读不到链接，就直接粘贴全文。普通聊天窗口没有项目文件权限时，只能分析你提供的内容，不能直接完成本机修改。

以下是给 Agent 的完整执行说明：

目标

检查当前项目使用的规则，减少由重复、冲突、过宽触发和模糊完成标准造成的无必要工作。保留现有必要能力、业务要求和明确权限边界。不要以删字数或删 Skill 数量为目标。

确定范围

确认当前项目、实际生效的规则文件、全局规则与项目规则的关系，以及任务可能调用的 Skills。先看入口、名称、描述和引用，再按相关性读取正文，不要先整读所有文件。

当前项目内用户可维护的规则属于本次修改范围。全局规则、其他项目、系统文件和插件缓存只诊断并提出建议，除非用户另外明确授权修改。权限不足或无法定位真实来源时，不猜测、不覆盖。

建立诊断

重点检查：无关任务的前置阅读、重复或冲突的指令、过宽的 Skill 触发条件、脱离风险与改动范围的测试要求、已有授权仍要求重复确认，以及任务完成前的无必要停止。

每个问题引用文件和原句，给出一个受影响的具体任务例子。区分已观察到的问题与待验证假设。文字长本身不构成问题；只对有明确作用的修改继续执行。

任务例子须标明来自真实记录还是推演。可以直接从文本确认的重复或冲突，写清判断依据后修改；仅推测会引发过度阅读、测试或确认的条目，先用已有记录或已授权任务验证。无法验证时保留原规则，交付待验证假设与验证步骤，不把推演写成已发生的问题。

实施修改

为拟修改文件建立可恢复且不覆盖旧备份的备份，记录原始内容及恢复位置。

在授权范围内，合并重复表达、补充适用条件、收窄误触发描述。对多流程 Skill，按需要将细节移到参考文件并保留清楚的读取入口。修改用户维护的真实源文件，保持必要引用和元数据有效。

保留必要测试、业务约束和交付标准。不擅自关闭工具、减少用户要求的产物，或扩大权限。涉及明确审批要求、业务含义或完成标准实质变化的条目，单独列为待用户决定；继续完成不依赖这些决定的部分。

一次处理一组相关问题，记录每项修改预期改善的行为。不要顺手重构无关配置。

检查结果

回读修改，检查语法、引用、触发条件及保留要求。确认哪些文件已修改，哪些规则已能确认被新会话加载；无法确认生效时，说明需要的新会话或重载步骤。

利用已有任务记录或当前已授权的验证条件，对照完成情况、重复阅读、无必要确认和必需检查。比较用量时保持任务、初始状态、模型、档位、工具和计费口径一致。

不为验证自行创建付费模型调用、外部发布或其他未授权动作。缺少对照条件时，提供可执行的验证步骤，并标记效果待测。

交付

给出简短结果：发现了什么、改了哪些文件、每项改动的理由、验证结果、备份与恢复办法，以及还需用户决定的事项。

没发现值得修改的问题，就保持原样。发现修改损害了必要行为，恢复对应部分。没有实际用量证据，不报告 Token 或额度节省比例。

以后换模型、增加一批 Skill，或者发现 Agent 开始反复绕圈，都可以把这篇再交给它检查。

每加一条规则，都值得问：它还在解决问题，还是已经制造了新的问题？

原始资料：
@pvncher · 原始文章 ↗