模型越强越不需要 Skills？我把 AI 编程能力拆成 4 层

最近有一种很有吸引力的说法：模型越来越强，很多 Skill 已经可以删掉了。

这句话只对了一半。

应该被删掉的，是那些只有一段长提示词、没有明确触发条件、没有工具边界、也没有验收证据的"说明书型 Skill"。模型能力提升后，这类内容确实更容易变成上下文噪声。

但在真实项目里，模型越能干，越需要把"它可以做什么"和"这次允许它做到哪里"分开。否则能力升级带来的不只是效率，也可能是更快的越界、更隐蔽的误判和更昂贵的返工。

这篇文章不讨论某个客户端的配置技巧，而是给出一套更稳定的判断方法：把 AI 编程能力拆成四层，再决定某条知识到底应该放在哪里。

先说结论：Skill 不是知识仓库，而是可执行合同

我现在只在四个信号同时出现时创建 Skill：

同类工作已经稳定重复出现；
输入、步骤、输出可以明确描述；
结果能通过命令、清单或人工标准验收；
这套方法需要跨任务或跨成员复用。

缺少其中任何一项，都应该先保留为一次性提示词、实验记录或项目规则。

例如"帮我优化这篇文章"不是 Skill。它没有稳定输入，也没有可重复的质量标准。相反，"将指定 Markdown 文章转换为平台草稿，校验标题、图片、代码块并返回公开页地址"就很接近 Skill，因为它有清楚的输入、状态转换和完成证据。

四层能力模型：别把所有东西都塞进 SKILL.md

第一层：Prompt，解决一次性意图

Prompt 适合表达这次任务的目标、背景和偏好，例如：

text 复制代码

审查这段支付回调代码，重点检查金额单位、签名校验和重复通知。
只做只读分析，按风险等级给出证据位置。

它的价值在于灵活，不需要为了偶发任务增加长期维护成本。只执行一次、方法还没跑通、验收标准仍在变化的任务，先用 Prompt 探索。

第二层：Project Rules，约束长期不变量

项目规则适合放不会因为任务变化而改变的边界，例如：

API 默认只绑定回环地址；
不把 Cookie、密钥和生产数据写入日志；
只读分析不得启动服务或修改文件；
提交、推送、发布属于不同授权。

这些规则不是"做事方法"，而是所有任务都必须遵守的护栏。如果把它们藏进某个 Skill，未触发该 Skill 时，边界就消失了。

第三层：Skill，复用成熟工作流

Skill 负责把已经验证过的方法变成可重复执行的流程。一个合格 Skill 至少要回答：

yaml 复制代码

name: publish-technical-blog
trigger: 用户要求发布一篇有真实技术证据的博客
input:
  - 选题
  - 知识引用
  - 目标平台
workflow:
  - 研究平台信号
  - 生成受管正文
  - 校验图片和代码
  - 创建平台草稿
  - 单独确认公开发布
output:
  - 本地文章路径
  - 公开页地址
stop_conditions:
  - 登录失效
  - 公开页无法回读
  - 知识证据不足

注意，Skill 的核心不是描述得多详细，而是把触发、工作流、输出和停止条件写清楚。

第四层：Tool / Hook，执行确定性动作

能用代码确定表达的动作，不要让模型每次重新理解：

Tool 负责查数据库、运行测试、上传图片、创建草稿；
Hook 负责在特定生命周期强制校验，例如提交前扫描密钥、发布前检查公开页；
CI 负责远程可重复的质量门。

Skill 可以编排这些能力，但不应假装自己已经执行了它们。

为什么模型越强，越要重视分层

强模型擅长在模糊输入下给出看似完整的结果。这也是风险所在：如果没有工程边界，"看起来完成"很容易代替"已经完成"。

我会把完成证据分成三类：

对象证据：目标文件、平台对象 ID、公开地址；
验证证据：命令、退出码、检查报告；
状态证据：当前阶段、失败原因、是否允许重试。

例如发布博客时，编辑器显示"发布成功"只是候选声明。真正完成需要读取公开页面、核对标题和正文，并记录最终 URL。模型再强，也不能用一句总结替代平台真实状态。

一个 Skill 值不值得保留，看测试而不是长度

我通常为 Skill 设计四组样例：

1. 正例：应该触发

用户意图与 Skill 的职责完全匹配，流程应进入正确入口，并产出约定证据。

2. 反例：不应该触发

例如用户只是询问原理，不应该启动有写入副作用的发布流程。

3. 边界例：应该停止

登录失效、授权不清、目标文件存在未合并修改、外部状态未知时，正确结果可能是停止，而不是勉强完成。

4. 回归例：真实故障不能重现

每次遇到漏触发、误触发、路径漂移、脚本失败或越界修改，都追加一个最小样例。修复标准是新样例通过，旧样例不退化。

可以持续记录这些指标：

text 复制代码

任务成功率
路由精确率 / 漏触发率
质量门通过率
平均重试次数
人工修正量
未授权副作用数量

只统计"Skill 被调用了多少次"几乎没有意义。调用频繁但总要人工返工，说明它只是在规模化制造噪声。

一份可直接使用的去留清单

面对现有 Skill，可以按下面的顺序审查：

如果只是背景知识，移到参考资料；
如果只是一次性目标，改成 Prompt；
如果是项目永久边界，放进项目规则；
如果是确定性动作，做成 Tool、Hook 或脚本；
如果流程尚未真实跑通，先保留实验记录；
只有成熟、重复、可验收的工作流，才继续作为 Skill；
一个 Skill 职责过多时，拆成可以组合的小 Skill；
没有正例、反例和失败边界的 Skill，不进入团队默认能力集。

最后

模型变强以后，真正过时的不是 Skills，而是"把一切写进一个 Markdown 文件，然后祈祷模型照做"的设计。

好的 Skill 更像一份轻量的可执行合同：它知道什么时候出现、依赖什么工具、在哪些条件下停止，以及拿什么证明任务完成。

所以我的答案是：模型越强，越可以删除低质量 Skill；但越需要保留那些经过真实工作流、失败恢复和验收标准打磨过的 Skill。