Skills 不是插件清单：AI 编程工作流的三层设计

Skills、MCP、CLI 和 AI 编程助手正在一起变热，但很多团队把 Skills 做成了“提示词收藏夹”，结果越装越乱。一个可复用 Skill 应该回答三件事：什么时候触发、按什么流程做、怎样验收。本文给出三层设计法、一个可复制的 Skill 模板、评审清单和边界条件，帮助团队把 AI 工作流从个人经验沉淀为可维护的工程资产。

趋势观察

今天可见的掘金推荐内容里，Skills 和 MCP 相关讨论明显升温。有人关心“装哪些 Skills”，有人关心“Skill 和 MCP 怎么分工”，还有人把 Skill 当作 AI 编程工具的效率入口。问题在于：如果没有设计原则，Skills 很快会从资产变成噪声。

好的 Skill 不追求长，而追求路由准确、流程明确、验证可执行。

三层设计法

第一层是路由层：描述这个 Skill 什么时候应该被使用。不要写“提升代码质量”这种泛化描述，而要写“当任务涉及数据库迁移脚本评审时使用”。路由越清楚，AI 越不容易误触发。

第二层是执行层：描述完成任务的步骤、优先级和禁止事项。它不应该只是“认真检查”，而应明确先读 schema，再读 migration，再检查回滚，再检查索引和锁表风险。

第三层是验证层：定义完成标准。没有验证层的 Skill 只能产生建议，不能稳定交付。

模板：一个可维护的 SKILL.md

下面是一个数据库迁移评审 Skill 的简化模板。

# db-migration-review ## When To Use Use this skill when a task adds or changes database migration files, schema files, ORM models, or data backfill scripts. ## Inputs To Inspect - Migration files changed in this branch - Current schema definition - ORM model changes - Query paths that depend on changed columns or indexes ## Workflow 1. Identify whether the migration is schema-only,>Skill 和 MCP 的分工
可以用一句话区分：MCP 负责接系统，Skill 负责把事做稳。
MCP 更像能力接口，把数据库、浏览器、工单、文件系统等能力暴露给模型。Skill 更像工作方法，告诉模型在某类任务中如何使用这些能力、先后顺序是什么、哪些风险必须停下来确认。
如果团队把“怎么连 Jira”写进 Skill，就会让 Skill 变成接口文档；如果把“代码评审应该先看什么”写进 MCP，就会让工具协议承担流程知识。两者都能跑，但维护成本会越来越高。
评审清单
一个 Skill 合并到团队仓库前，至少过下面这张清单：
触发条件是否具体，能否和其他 Skill 区分。
步骤是否可执行，是否依赖模糊形容词。
是否列出必须读取的文件或上下文。
是否有明确的停止条件，例如需要人工确认的危险动作。
是否定义输出格式，方便进入 PR 评论、文档或任务系统。
是否有验收标准，能判断任务完成而不是“聊完了”。
反例
下面这些写法通常会失败：
“你是高级工程师，请写高质量代码。”这只是角色扮演，不是流程。
“检查所有问题。”范围无限，AI 不知道先查什么。
“尽量安全。”没有具体风险枚举，无法触发停顿。
“参考最佳实践。”没有本团队约束，输出会随模型习惯漂移。
更好的写法是把隐含经验展开：哪些路径必须读、哪些命令可以跑、哪些风险必须报、哪些结果才算完成。
边界条件
Skills 不能替代测试，也不能替代权限控制。它能改善模型执行路径，但不能保证模型永远正确。对于删除数据、部署生产、修改安全策略、外发用户数据等动作，Skill 应明确要求人工确认。
此外，Skills 不宜过多。一个团队更需要 5 个高频、清晰、可验证的 Skill，而不是 50 个互相重叠的提示词包。
总结
Skills 的价值不是“让 AI 更像专家说话”，而是把团队做事的方法变成可复用流程。先从高频、风险明确的任务开始，例如迁移评审、前端视觉回归、接口兼容性检查、发布前清单。每个 Skill 都按路由、执行、验证三层设计，AI 编程工具才会从个人技巧变成团队能力。