处理指令冲突前检查作用范围

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

你在维护两份 Agent 指南。教学根指南 R 规定代码修改运行集成测试，docs 指南 D 规定仅改文档时运行链接检查；当前改动只涉及 docs 文本。看到不同命令，先判断它们是否作用于同一任务，不按提交先后直接删一条。

具体做法

对每条规则记录所在位置、适用目录/文件、触发任务和实际加载时机。不同作用域各自保留；同一任务同时适用且要求不能兼容时，引用双方位置并按已确认的指令层级与产品约束处理。历史可帮助解释来由，但更晚提交不自动代表正确或有权限。无法确定的真实冲突单列，别修改项目之外的配置来掩盖它。

反例

根指南 R 的集成测试规则比 docs 指南 D 更旧。为当前文档改动删掉 R，让以后所有代码修改也只做链接检查。

改进写法

先比较上述 R、D 的作用范围：R 适用于代码修改，D 适用于仅文档修改；当前是 docs 文本，因此按 D 检查链接，同时保留 R 的代码要求。列出规则位置与适用依据。若有另一条规则明确要求所有改动都做集成测试，再记录它与 D 的同任务冲突，按有效层级核对，不仅凭提交时间改写或削弱。

为什么这样改

不同措辞可能只是不同触发条件。先比较作用范围，能避免把合理分工当作重复或矛盾；真实冲突则留下具体任务与证据，而不是用“较新”把任意规则提升为权限。

如何验证

教学的文档改动应得到 D 的链接检查计划，代码改动仍得到 R 的集成检查。加入“所有改动必须集成测试”的规则后，应显露同任务冲突并引用位置。

检查是否保留了不受当前任务影响的要求；无作用域证据就删除根规则，或改项目外配置，都不满足本方法。

适用边界

这是一种冲突诊断，不改变宿主的指令优先级。安全规则、明确用户范围和权威产品约束不能仅凭仓库提交顺序覆盖；含糊的加载语义应先核实。