强指令模型时代，技能与代理规则要大扫除

一、问题的本质：旧规则假设正在失效

很多团队现有的技能说明、代理规则和上下文文件，形成于上一代模型能力还不够稳定的时期。那时，智能编程代理经常不知道主动查找项目文档，于是人们倾向于在全局规则里写满“每次编辑前必须阅读架构说明、数据库说明、部署说明”，在技能描述里写宽泛的领域关键词，希望模型尽可能多地加载背景材料。这个策略在当时有其合理性：规则越多，模型遗漏关键信息的概率似乎越低。

但当模型进入强指令遵循阶段，规则的行为逻辑发生了变化。模型会更认真地执行写下来的约束，包括那些范围过宽、彼此重复、边界模糊的规则。过去“写了但模型未必照做”的规则，现在会被逐条落实。于是，一条本来用于兜底的全局规则，可能变成每次修改一个字符串都要完整阅读多份文档；一条本来用于覆盖数据库领域的技能描述，可能在普通查询修复、对象关系映射字段调整时被误触发，连带迁移规范、检查步骤和参考资料一起进入上下文。

这就是所谓的“合规性放大”：规则越宽，模型执行得越机械；上下文越多，信噪比越低。最终结果不是更准确，而是上下文计量开销上升、任务时延增加、关键信息被稀释，甚至因为规则冲突而提前暂停、反复询问用户或阻塞任务。清理技能与代理规则，不是削弱模型能力，而是把上下文从“堆料”改为“路由”。

二、三类典型坏味道

1. 技能触发条件按领域关键词，而不是任务动作

常见坏写法是：

技能描述：处理数据库、查询、模型或持久化相关任务时使用。

这段描述覆盖范围过大。“数据库”可以指表结构变更、迁移脚本、查询优化、连接配置、对象关系映射字段调整，甚至只是读取一条记录。只要任务中出现相关词语，技能就可能被判断为相关，随后迁移规则、检查步骤、参考资料全部进入上下文。对于普通逻辑修改，这些材料大多无效。

更合理的写法应包含动作、对象、时机和排除项：

技能描述：仅在新增或修改数据库迁移脚本，或审查迁移回滚与发布步骤时使用。
不适用于普通查询修复、字段读取、对象关系映射字段调整等日常逻辑修改。

触发条件从“领域相关”收紧为“具体任务动作”，模型就不容易在无关任务中加载迁移技能。技能说明不是关键词列表，而是加载策略的一部分；它应该告诉模型“什么时候用”，也要告诉模型“什么时候不用”。

2. 全局规则强制每次阅读所有文档

另一种常见坏写法是：

每次编辑前，必须阅读架构说明、数据库说明和部署说明。

在早期代理能力不足时，这种规则很常见，因为模型可能不会主动找文档。但在强指令模型下，模型真的会反复执行这个约束。你只改一个字符串，它也会完整读取几份说明；改第二次，它又会重新读取一遍。整个过程除了增加上下文计量开销、拖慢进度，几乎没有实际收益，而且上下文会快速膨胀，导致幻觉风险上升。

推荐把它改成简单的上下文路由表：

当前任务类型	应加载材料	通常不加载
调整服务边界	架构说明中的服务边界部分	部署说明、数据库迁移规范
修改表结构或迁移	数据库说明、迁移规范	前端组件说明、部署总览
准备部署	部署说明、回滚清单	数据库查询规范、界面样式说明
普通界面缺陷	相关组件说明	数据库说明、部署说明

路由表的价值在于把“何时读什么”显式化。文档仍然存在，知识没有被删除，只是从“每次全量加载”变成“按任务精准加载”。普通界面缺陷不需要读部署说明，单条查询修复也不一定需要迁移规范。

3. 规则重复、冲突、范围过宽

当项目变大，规则文件往往会出现多处重复：全局规则写一遍，领域规则写一遍，任务模板再写一遍；措辞不同，语义相近；有的规则说“必须优先保证兼容性”，有的规则说“允许快速修改”。强模型遇到冲突时，可能选择保守路径，提前暂停询问，或者在不同规则之间反复权衡，造成任务阻塞。

治理方式不是继续增加解释，而是建立分层与单一事实源：

• 全局层只保留少量稳定硬约束，例如安全边界、不可修改目录、必须运行的基础检查。
• 领域层按目录、文件路径或任务标签加载，例如数据库迁移规范只在迁移任务中生效。
• 任务层使用短小模板，只包含当前任务必要步骤。
• 明确冲突解决规则，例如“任务级规则可以补充领域规则，但不得违反全局安全约束”。

规则越少、边界越清楚，强模型越容易稳定执行。规则越多、措辞越模糊，模型越可能把“认真执行”变成“过度执行”。

三、清理方法：盘点、收紧、路由、回归

1. 盘点与分类

先列出所有技能说明、代理规则、任务模板和检查清单，按四个维度分类：触发范围、加载时机、冲突关系、最近触发记录。标记三类对象：从未命中的、频繁误命中的、与其他规则重复的。没有日志时，可以先人工抽样常见任务，记录哪些材料被加载但实际上没有被使用。

2. 收紧触发条件

每个技能尽量单一职责，描述中写清动作、对象、时机和排除项。例如把“数据库相关任务使用”改为“仅在新增或修改迁移脚本、审查回滚与发布步骤时使用，不用于普通查询修复”。技能加载的资料数量也要限制，避免一个技能携带过多参考文件。

3. 建立上下文路由

用任务类型到材料的映射替代全局强制阅读。示意性配置如下：

routing:
  - match: { change: "service_boundary" }
    load: ["architecture/service-boundaries"]
  - match: { change: "schema_migration" }
    load: ["database/schema", "database/migration-policy"]
  - match: { change: "deployment" }
    load: ["deployment/runbook", "deployment/rollback"]
  - default:
      load: ["repository/overview#minimal"]

全局规则可以保留最小硬约束，例如“不得修改受保护目录”“提交前运行基础检查”。领域材料和任务模板按需加载。这样既保留知识，又避免无关上下文进入窗口。

4. 评审与回归

每次新增或修改规则都应经过评审，回答三个问题：现有规则能否覆盖？触发条件是否足够具体？是否引入冲突？同时建立小规模评测集，覆盖常见任务类型，观察技能触发准确率、无效加载比例、任务暂停率和完成时延。规则治理不是一次性大扫除，而是持续维护。

四、可观测指标与治理机制

清理效果不能只凭感觉，可以用以下指标衡量：

• 技能触发准确率：正确触发次数除以总触发次数。
• 无效上下文占比：加载后未被任务使用的材料比例。
• 平均加载文档数：单任务加载的材料数量。
• 任务暂停与询问率：因规则模糊或冲突导致的暂停比例。
• 上下文计量开销与完成时延：单任务平均开销和耗时。
• 重试率与冲突次数：规则冲突引发的重试或阻塞。

治理机制上，建议“删除优先于新增”：新增规则必须证明现有规则无法覆盖；连续低命中的技能合并或删除；高误触发的技能收紧描述；高冲突规则重构分层。每季度做一次规则审计，把技能说明和代理规则当作代码资产维护。

五、常见误区

第一，认为强模型需要更多规则。实际上，强模型更需要清晰边界；规则越多，过度执行和冲突概率越高。第二，把清理理解为删知识。正确做法是保留文档，删除不合适的触发条件和加载策略。第三，只改技能描述，不改全局强制阅读。全局规则往往是上下文膨胀的主要来源。第四，描述缺少排除项。只写“何时使用”，不写“何时不用”，模型仍可能过度触发。第五，没有度量就清理。缺少触发日志和回归评测，容易把有效规则误删。

六、落地清单

可以从一份最小清单开始：全局规则只保留少量硬约束；每个技能单一职责，包含触发条件、排除项、输入输出和停止条件；建立覆盖常见任务的上下文路由表；为技能触发和材料加载记录日志；设定触发准确率、无效加载占比、暂停率等指标；每季度审计一次，优先合并和删除低价值规则。

强指令模型时代，上下文治理的核心从“堆更多材料”转向“在正确时机加载正确材料”。技能与代理规则的大扫除，不是减少知识，而是把知识放到合适的触发条件下。让模型在该用时加载，不该用时保持上下文干净，才能把强指令遵循能力转化为稳定、可维护、可度量的开发效率。