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 编程工具才会从个人技巧变成团队能力。
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 编程工具才会从个人技巧变成团队能力。
