Skills上架没多久，却极快的占据了Claude产品架构中的核心位置。Skills的出现源于Claude内部员工偶然发现公司里的财务、数据分析等业务部门都在使用自己搭建的skills小工具完成非代码类工作。他们迅速意识到了这个小工具的普世性和易用性，将其作为产品发布了出来，且理所当然的火了。
我认为 Skills 对企业 AI 转型有着巨大的作用。然而其价值不在技术本身，而是在组织结构能力的拆解分工。
一、先看看Skills是什么
简单来说，Skills让模型第一次以“稳定能力”的形式参与到真实任务中。Skills需要用户赋予大模型更高的权限（读取文件夹内容、执行代码等）。结合提供对任务的描述，让AI更智能和稳定地完成特定任务。任务描述中主要包含三个层级的内容：
元数据层（以SKILL.md 文件头部的 YAML 配置文件）：定义工作任务名称与触发条件，使模型知晓该能力的存在与适用场景；
指令层（SKILL.md 中的核心内容）：任务的操作指南与最佳实践，仅在触发后被读取进上下文
资源层（文件夹中的其他文件）：完成任务时所需的辅助文件——包括专项说明文档、可执行脚本及参考材料（如 API 文档、模板）
可以看到，Skills有明确的输入、输出和职责描述，是一组可以被反复调用的 AI 能力。当工作任务以 Skills 的形式存在时，它不再只是一次对话或一个完整的工作流，它成为了一个可以被复用、被组合、被持续优化的业务能力。
二、企业 AI 落地是技术挑战，更是组织挑战
在大型企业环境中，AI 落地反复受阻，原因已经不在模型能力，而在责任无法清晰落位。IT 部门不掌握业务判断的细节，也无法为判断结果承担业务责任。业务部门最清楚规则与边界，却不具备将判断转化为可执行 AI 逻辑的工程能力。
即使是dify等AI工作流平台也没有真正解决这个问题。对业务部门来说，这类平台依然要求理解节点逻辑、数据流转和异常处理。对 IT 部门来说，平台上的判断逻辑又高度业务化，难以长期维护和背书。
因此，在不少已经引入 Dify 的企业中，可以看到一个共同现象：平台搭建完成，因为没有一个合适的责任主体来驱动场景落地导致场景推进却长期停滞。
Skills 的出现，在结构上改变了这一局面。它重新划分了职责边界。业务部门作为Skills的构建方，对 “Skills的建立和输出结果正确” 负责，IT 部门对 “Skills在正确的场景被应用” 负责。AI能力第一次被明确拆分为可以分别治理的两部分。
三、一种更可行的方法论：先验证，再固化，再规模化
在实际推进路径上，更现实的方法并不是一开始就构建 Skills 体系，而是先利用 Dify 等平台完成探索和验证。通过 workflow 和 LLM Block，快速跑通业务场景，验证哪些判断是有价值的，哪些规则是稳定的。
当某些判断在多个场景中被反复使用，且业务部门对其结果形成信任时，再将这些判断从workflow 中拆解出来，固化为 Skills。此时，Skills的建设和迭代由业务部门主导，因为判断标准本身就是业务资产。
IT 部门在这一阶段的职责随之发生变化。他们不再需要参与每一个判断细节的设计，而是专注于端到端流程的编排、系统集成和运行保障。已经建成的 Skills 成为可以被复用的能力组件，被更高效地嵌入不同流程。
这种路径的价值在于，它避免了在不确定阶段过早抽象能力，同时也为后续规模化提供了清晰的治理结构。AI 不再以“项目”的形式存在，而开始以“能力”的形式被管理。
四、Skills 的真正价值，在于组织结构而非技术领先
从技术角度看，Skills 并不具备不可替代的独创性，更多只是一个新范式。判断封装、能力复用、接口调用，在其他平台中同样可以实现。它的意义不在于技术优越性，而在于它为业务部门提供了一种可以被明确授权和承担责任的工具形态。
Skills 是 Anthropic 内部业务部门直接使用 AI 的利器。对于在尝试 AI 转型的企业，Skills 提供了一种拆解 AI 转型责任的参考范式。业务部门负责能力质量，IT 部门负责流程运行，数字化治理因此具备了可执行性。
