skill 约束要区分「补模型短板」与「替模型做判断」

**模型足够强时,很重的 skill 约束反而会限制它的能力 —— 判据是:这条约束在「补模型当下做不到的事」,还是在「替模型做它本可动态判断的决策」。前者该留,后者在强模型上只换来延迟和返工。**

这条判断的由来

用户在使用 Superpowers 这类重流程 skill 时的两个体感:

  1. 重的 skill 约束了模型能力 —— 模型(sol)已经很强,很多步骤本来可以由它自己判断。
  2. 但不敢全砍 —— 担心完全不用 skill 体验反而更差,想保留一部分开发流程规范。

所以问题不是「用不用 skill」,而是约束的边界划在哪。

判据:补短板 vs 替判断

约束类型例子强模型下的处理
补模型短板强制先复现再改、强制跑验证、强制记录决策保留 —— 模型不会自发保持一致性
替模型做判断规定每一步先做哪个子任务、固定探索顺序可放宽 —— 强模型能动态决定

流程规范(评审、验证、分支纪律)属于第一类:它们约束的不是「怎么想」,而是「不许跳过」。见 开发流程要按任务大小分级 —— 那份分级里「小功能不该走重流程」是同一条判据在流程粒度上的落地。

待验证

这是用户转述的外部说法(原话:「听别人说的,但是我还没测试过」),尚未 A/B 验证。

可验证方式:同一批任务分别用「重 skill / 轻 skill / 无 skill」跑,对比耗时与结果质量,重点看「去掉某条约束后,模型是否仍然自发做到了它」。只有「去掉就退化」的约束才算补短板。

相关

  • 开发流程要按任务大小分级 —— 同族判据:验证强度按任务大小与阶段分级,而非一刀切
  • Agent编排层薄自建优先于重型框架 —— 抽象/框架的成本要对着真实规模算
  • 工作模式切换改变的是harness而非模型 —— 约束来自 harness,不是模型本身