改一个页面文案，助手先读完架构、数据库和部署文档；代码已经改好、测试也通过，它又停下来问要不要继续检查界面。这些绕路，有时来自项目里积累的旧指令。
模型升级后，过去为弥补能力不足而写的规则，也需要重新检查。保留项目事实、风险边界和完成标准，给具体执行留出判断空间。 这是清理指令时最值得坚持的原则。
Eric Provencher 在 2026 年 9 月 5 日发布的文章中，讨论了 GPT-6 Astra 与 Skills、AGENTS.md、任务提示词之间的关系。OpenAI 当前的 Astra 使用指南也建议审查这些文件：模型对指令更敏感，含糊或冲突的要求可能让它提前停下；小任务也可能触发过宽的验证。
下面把这些建议整理成一次可以在自己项目中完成的检查。文中的中文模板是根据这些原则编写的示例，使用前应替换成项目的真实条件。
先看指令放在哪一层
同一句话放在不同位置，会影响不同范围的任务。
| 位置 | 适合保存什么 | 检查重点 |
|---|---|---|
AGENTS.md | 项目约定、必要命令、稳定的限制 | 是否把偶发流程变成了每次必做事项 |
技能的 description | 何时调用这个技能 | 是否把触发条件写得过宽 |
| 技能正文与参考文件 | 特定工作的步骤、资源与检查 | 是否一次加载了所有分支 |
| 当前任务提示词 | 本次目标、验收结果、停止条件 | 是否只说了开始做什么，漏掉完成到哪里 |
官方 AGENTS.md 文档说明，Codex 会组合全局和项目路径上的指令，更靠近当前工作目录的规则可以覆盖前面的规则。因此，发现行为异常时，要检查实际生效的文件，单看仓库根目录可能漏掉覆盖项。
技能描述要能排除无关任务
原文用数据库迁移展示了一个常见问题：技能只负责迁移，描述却把数据库、查询、模型和持久化都列成调用理由。这样一来，普通查询优化也可能带进迁移流程。
可以把描述收窄为：
name: postgres-migration-review
description: 创建或检查 PostgreSQL 迁移；用于新增迁移、修改迁移或审查迁移发布计划。这段描述让任务范围更容易判断。为表达“这个技能很有用”而加入大量相邻领域，只会增加误选的机会。
这里还有实际的上下文成本。官方技能文档说明，Codex 先看到技能名称、描述和路径，选中后再读完整 SKILL.md。初始技能列表有预算限制；技能较多时，描述会先被缩短，集合很大时还可能省略部分技能并显示警告。完整技能正文的读取与这份列表预算分开计算。
所以，关键用途应尽量靠前。检查一个描述是否合适，可以用两个相邻任务试一下：
- “检查这次新增的数据库迁移”应当命中迁移技能。
- “解释这条查询为什么慢”通常无需进入迁移发布流程。
观察助手实际选择了什么，再调整描述。只数技能数量，无法看出这些边界是否清楚。
把长技能改成按需入口
一个技能同时处理创建、检查和发布时，入口文档可以告诉助手当前该读哪份资料。只有真正进入对应流程，才加载细节。
例如，假设团队维护一个发布技能，且下列参考文件都已存在，入口可以写成：
# 发布工作
先判断当前任务：
- 准备发布：读取 references/prepare.md，生成候选版本和检查结果。
- 排查发布失败：读取 references/troubleshoot.md。
- 执行发布：确认本次发布已获授权，再读取 references/deploy.md。
只读取当前任务需要的参考文件。原文将这种组织方式称为渐进披露：先给足够的线索，再按任务补充细节。它能减少无关流程进入上下文，也让文档维护者更容易看出每一部分的用途。
对于只有几条规则的技能，留在一个文件里就够了。拆文件应当解决实际的阅读负担。路径必须有效，关键约束也应放在执行动作之前，避免把发布边界藏到最后才会读到的附录里。
原文还提醒，仓库技能可能被使用其他模型的贡献者读取。删减时应保留可复核的输入、输出和检查要求，避免把某个模型当前的能力假设写成整个团队永久依赖的前提。
让阅读和验证随改动范围变化
原文的另一个例子是“每次编辑前都读完几份项目文档”。这条规则容易让小修改承担整个项目的阅读成本。可以写成条件明确的导航：
涉及服务职责或跨服务调用时，查阅架构说明。
涉及数据结构变更时，查阅数据库约定。
准备发布时，查阅部署说明。这仍然要求助手理解相关代码和调用关系。被删掉的是与当前修改无关的固定阅读流程。
验证也需要区分范围。比如一个内容站点，修改错别字可以检查文章格式和链接；调整共享布局需要检查受影响页面；更改构建配置需要完成生产构建。项目已有的必要检查应写清楚，让助手知道什么结果算通过。
Astra 指南建议完成与改动相称的验证，通过后仅在新修改、失败或尚未解决的问题出现时扩大或重复检查。可以据此写下：
完成与本次改动相关的必要检查。
检查通过后，只有新改动、失败或未解决的问题才需要追加或重跑。
报告运行了什么、结果如何，以及尚未验证的部分。这类规则的价值在于明确验证停止的条件。涉及权限、资金、数据一致性等重要逻辑时，验收仍需覆盖对应风险。
把能继续做的事写清楚
如果曾经遇到助手越界操作，很容易补上一句“任何下一步都先问我”。这也会影响原本可以连续完成的本地工作。
原文给出的例子是说明测试环境的真实边界：如果本地测试使用可丢弃数据，且无法访问生产环境，就可以明确授权助手运行、修复本次改动引入的失败，再重跑受影响测试。
对应的中文写法可以是：
本地测试使用可丢弃的测试数据，无法访问生产环境。
可自行运行测试、修复本次改动造成的失败并重跑相关测试。
生产发布需要我明确授权。采用这段文字前，要先确认测试确实满足这些条件。提示词里的声明无法改变脚本真正连接的数据库，也不会改变运行环境的权限设置。
如果助手仍然停下，可以要求它指出导致暂停的具体文件和原句。这样更容易发现“发布前确认”被扩展到了“准备发布材料前确认”，或旧技能残留着额外的等待步骤。
把验收写进任务
“做一个设置页面”只交代了实现目标，缺少可观察的完成结果。可以把任务写到能够检查的程度：
实现设置页面，并完成本地验收：
打开页面，检查桌面和手机布局；
验证保存成功、输入错误和请求失败时的提示；
修复本次改动引入的问题，完成相关检查。
结束时说明修改内容、验证结果和仍存在的限制。
本次范围到本地验收，不执行生产发布。这是一个设置页任务的示例。真正使用时，需要根据页面功能调整验收项。如果只是改一个按钮文案，就不必照搬整套流程。
原文强调提前定义完成条件；官方指南也指出，Astra 在信息可能影响结果时更倾向于询问。明确目标、授权范围和终点，有助于它判断哪些工作应当连续完成，哪些地方需要用户作决定。
用三个真实任务验证删改
建议先在可回退的分支中修改指令，保留原版本，然后用以下三类任务检查效果：
- 一个小修改。 观察是否还会读取大量无关文档或执行无关检查。
- 一个典型功能任务。 观察是否完成实现、运行和验收，是否在半途反复等待确认。
- 一个涉及授权边界的任务。 观察是否仍能在约定的位置停下，并提供足够的材料供人判断。
比较时尽量保持模型、任务描述和项目状态一致。记录误选技能、无关阅读、重复检查和遗漏验收项，比凭感觉判断“这次好像更快”更有帮助。一次成功只能说明该样例有效，还需要覆盖团队经常遇到的任务。
最适合先动手的地方，是最近一次让你觉得助手绕路的指令：找到它，确认它原本解决什么问题，再把触发条件和完成结果写具体。仍然保护真实边界的规则继续保留，已经失去用途的流程才值得删除。
Aide Hub 会继续分享 AI 助手、开发工具与软件工程实践中的具体做法。