以前大家都在花时间绞尽脑汁研究怎么写出完美的提示词，试图调教一个更好的结果。但 Anthropic 最近发布的一份 33 页的完整构建指南释放了一个非常明确的信号：依赖临时对话和长提示词的玩法，正逐渐被系统化的工程设计所取代。

这份《Claude Skill 构建指南》详细拆解了如何把松散的 AI 能力打包成结构化的“技能”。它不是一份教你怎么聊天的手册，而是一份面向开发和重度用户的系统工程文档。

整份指南按照一个标准工程项目的生命周期，划分为几个核心模块。从底层的技能运行机制到典型的场景应用，本质上就是在教会我们如何高效的构建AI Agent，把AI能力打包成一个个核心技能（即skills），从而得到更稳定、可复制的结果。

提示词正在升级为文件夹

过去让 AI 帮你干活，每次新建对话都得重新铺垫背景、解释业务逻辑。现在不用了，Claude 的 Skill 机制把这些零散的指令打包成了一个结构化的实体。

它不再是一段几千字的纯文本，而是一个包含了核心 SKILL.md 指令文件、执行脚本、参考文档和模板资产的文件夹。你只需要教 Claude 一次，这套标准操作程序就会固化下来，无论是用来生成前端代码，还是按固定格式输出报告，它都能保持高度的一致性。

这里的核心门道在于渐进式披露（Progressive Disclosure）的设计理念。

AI 面临的最大瓶颈往往是上下文过载，什么都塞进提示词只会让模型失焦。Skill 在设计上采用了三层架构，最外层是极轻量的 YAML 前置数据，只负责告诉 Claude 这个技能的触发条件。只有当任务命中触发词时，主体 Markdown 指令才会被加载；而在执行过程中如果遇到特定问题，它才会进一步读取深层的参考文档。

这种按需加载机制既避免了 Token 的无谓消耗，又保证了模型在真正需要专业知识时有据可查。

只给AI建个厨房是不够的

前面很多人在折腾 MCP（模型上下文协议），以为只要把本地文件、Notion、GitHub 等外部工具的访问权限丢给大模型，自动化就算完成了。这是目前关于 AI 自动化最大的错觉。

Anthropic 在指南里用了一个极具画面感的比喻：MCP 只是建了一个“专业厨房”，它赋予了 Claude 获取工具、食材和设备的权限。但如果把一个拥有顶级厨房的厨师留在那里，却不告诉他业务流程和交付标准，结果往往是用户不知道该干嘛，或者因为措辞的微小差异导致调用失败。

Skill 就是那本“菜谱”。

MCP 决定了 Claude “能做什么”，而 Skill 教导 Claude “该怎么做”。

当你把 MCP 和 Skill 结合时，工作流才算真正跑通。指南中提到了一种跨服务的协同编排模式。以设计到开发的交接为例，如果没有 Skill，你每天都要发号施令要求它先去 Figma 导图，再去 Linear 建任务，最后发 Slack。而有了 Skill 打底，触发指令下达后，后台会严格遵循预设的阶段顺序自动执行提取资产、云端存储、任务分配、群组通知，且每一阶段都自带错误处理机制。

另一种更高级的应用是注入领域专业知识。单纯的 MCP 只是个没有立场的执行器。但你可以通过 Skill 要求 Claude 在调用支付接口前，必须先执行一套合规检查逻辑，比如核对制裁名单或评估风险级别。合规通过才允许调用付款工具，否则直接拦截并生成审计报告。

这种结合把单纯的工具访问权变成了自带纪律和大脑的标准化生产线。

测试指标取代了盲盒式抽卡

指南里最能体现这种工程化转变的，并不是代码规范，而是它引入的量化评估标准。

传统的提示词调优，往往是依靠肉眼看结果的好坏。但构建一个合格的 Skill，你需要监控触发准确率、工具调用的步数以及失败率。开发者需要针对这些具体的指标去优化 YAML 中的触发词，或者在指令中增加针对特定错误代码的重试逻辑。

AI 开发正在从基于直觉的对话式调试，走向一套可衡量、可审计的系统工程。如果你还在靠每次跟 AI 聊天时的运气来保证输出质量，这样的工作流在真实的业务场景下是无法存活的。

这套体系目前已经具备了很强的跨端通用性。做好的 Skill 可以直接在 Claude.ai 网页版、Claude Code 甚至 API 开发中无缝调用。作为一种开放标准，行业里类似的机制也正在被广泛复用。

当系统工程逐渐取代提示词的魔法，我们需要重新审视自己手里搭建的工作流。你现在接入的那些 AI 自动化流程，是在靠模型每次临时发挥去猜你的意图，还是你已经为它写好了一份包含容错机制的菜谱？

指南下载地址：https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf?hsLang=en