Skills爆火，但企业为什么不敢用？

2026年初，如果说AI圈爆火的技术是什么，Skills这个词一定会被提及。

从Anthropic开放Agent Skills规范，到OpenAI在Codex CLI采用相同格式，再到GitHub涌现出上千个开源技能库——Skills正在成为Agent领域的新标准。

但如果你仔细观察，会发现一个有趣的现象：个人开发者玩得很嗨，企业却对此很谨慎。

为什么会这样？带着这个思考，假期我也全面研究了下Skills，并从中得到一个启发：

一个新AI技术的落地，考验的不只是合适的应用场景、充足的技术储备，更要在组织上做好变革。

这篇文章，就来和大家聊聊这个观点。

一、什么是Skills？为什么它突然爆火？

Skills的全称，是Agent Skills，名字很直观，这是给Agent用的，用来让它具备各种“实操技能”的。

一个Skills，是以文件夹形式存在的，这个Skills文件夹里有什么呢？

• 一个SKILL.md文件(说明了如何使用这个SKILL和具体的执行步骤)

• 可选的脚本、参考文档和资源包

详细的结构说明如下：

└── assets/      # 可选，模板、资源

智能体可以在读取Skills文件夹后，按照里面的指导说明，更准确、高效地完成特定任务。

比如pdfskill，可以让AI精确解析并提取PDF中各种特定格式的内容；java-best-practicesskill，可以让AI按规范写Java代码；pr-creatorskill，可以让AI自动创建符合规范的GitHub Pull Request。

理解一下，Skills本质上是个模板，用来把一些共性的步骤、流程、资源抽象成配置文件，让它可以被不同智能体调用，实现能力复用。

为什么它能在2026年初爆火？

因为Skills的出现，解决了通用AI的一个很大的痛点——能力边界。

通用模型再强大，也无法在所有领域达到生产级标准，比如对复杂文件格式的解析精度不足、对特定技术栈的工程规范理解有限、缺乏与外部系统的直接交互能力等等。

Skills的本质，则是将专业能力封装为标准化模块，你可以根据任务要求，灵活组合不同能力，让AI可以实现“按需调用”。为方便理解，我画了一张图帮你理解：

这背后体现着Skills一个很重要的设计理念：渐进式加载

（Progressive Loading）。即：如果有多个Skills，智能体在启动时，会先读取每个Skill的名字和描述，了解它们的能力。等用户下达任务后，由系统判断和某个Skill匹配，才按需加载它的完整指令、脚本和参考资料。这样既节省上下文空间，又能在真正需要时提供完整能力。

那接下来问题来了：这么厉害的新技术，企业是不是也可以用起来？

听起来很有道理，Github上有上百种现成技能，直接都导进来，是不是就能覆盖大多数业务场景了？

但深入研究下来你会发现，远没有那么简单。

二、企业应用Skills前，必须具备的四个关键前提

作为个人使用，Skills是很好用的“提效工具库”，但企业应用则是完全不一样的要求，因为它要真实嵌入流程、嵌入职责分工的能力模块，不做好额外准备就很容易推行失败。为此，我总结了四项企业应用Skills的关键机制：

1）作用域隔离机制

个人用Skills完成任务很简单，让模型能读懂指令，成功调用工具输出结果即可。但企业则完全不一样。

财务的技能、法务的技能、研发的技能、销售的技能，它们的边界都非常敏感，不可能放在同一个上下文里混着跑。更不可能让一个部门随意调用另一个部门的能力。

所以企业首先要考虑的，是：

• 多租户作用域隔离。不同岗位职责的能力之间不能相互调用。

• 项目级作用域隔离。技能的启用和失效，要跟随项目的生命周期而触发和关闭。

• 作用域权限控制。不同角色只能调用指定权限内的技能集。

只有先做好隔离，才能提前把风险限定在可控范围内。

2）技能审计机制

个人用智能体，很少有人会在意Agent的执行过程。

但企业必须知道谁触发了技能、什么时候触发的、执行的是哪个技能、产出了什么结果，以及有没有越权。

目的是合规和透明。

所以企业级Skills的背后，一定要有日志、链路和回滚机制，以确保过程安全可控。

3）技能自定义机制

对企业而言，真正有价值的部分，是那些专属于所在业务场景下的特有流程、判断标准、字段定义和实施链路，在执行时要遵循的内部合规要求和决策逻辑，最终输出的话术也是常年沉淀下来的。

因此无论Github上有多少现成的Skills，企业也是没法直接复用的。

如何把内部的SOP、判断逻辑、流程细节，封装成可维护的技能。才是决定Skills能否成为企业能力资产的关键。

4）成本控制机制

尽管渐进式加载能极大减少每次模型读取上下文的token数，但企业应用不像个人，其使用规模一上量，成本就会变成肉眼可见的压力：响应时间、调用次数、并发量、缓存策略、成本分摊……这些都必须提前设计。

在这个基础上，企业必须提前确立调用配额，制定缓存和降本策略，并把成本分摊到每个使用Skills的部门，只有这样，才能让Skills从试点切换成全域覆盖的基础设施。

三、自定义技能的重要性

如果要从上述4个机制中选一个最重要、最优先要建立的，当属“技能自定义机制”。

也许你会说，现在开源社区里的技能已经几百个了，全都装上，让模型根据需求选择合适的技能不就好了？

看起来是这样，但一旦把需求放进企业现场，你马上会发现：通用技能最多帮你解决三成，剩下七成全是每家公司的独有规则，根本没有现成的替代品。

举个最直观的例子：企业想做一套合同审核流程。你可以用现成的pdf skill提取合同内容，但模型不知道什么技能可以判断合同哪一条属于争议条款，也不知道你们公司惯用的审核报告长什么样。因为它没有你们内部的判断口径，也不知道企业的流程细节。只有把合同审核规则、报告呈现格式按企业自己的规范拆出来，一条条写进技能里，才能让其变成稳定、可复用的能力模块。

说白了，通用技能给的是工具，而定制技能给的是规则，而规则才是企业真正的价值所在。

但这里面也有个很大的陷阱。

四、陷阱：可以直接让业务人员创建Skills吗？

很多企业会认为：

"让业务人员把自己的经验转化为Skills，不就能快速积累技能库了吗？"

听起来很合理，但真正落到执行层面，你会发现：绝大多数技能不是靠写两段提示词就能完成的。

我们可以打开awesome-claude-skills这个著名的Skills仓库看看，上面的热门技能，要么要写代码，要么要写极其专业、结构化的提示词。

处理PDF的要写Python，处理Word、Excel的也一样要写代码；不需要写代码的那类技能，往往要求你把流程拆得非常精细，把输入输出写成工程化的格式。这不是在文档里写几句经验就能完成的事。

那业务人员到底能做什么？

更多时候，他们能沉淀的是“规则类”的技能，也就是把自己的判断逻辑拆出来，让模型按规矩走。

只要技能涉及底层能力调用、文件解析、流程自动化、复杂结构化生成，基本都要靠工程团队来落地。业务懂经验，但技能的工程化落地，则需要另一套方法论和技能栈。

五、企业落地Skills的前提：把技能分层分类

Skills技术的优势，在于把重复的流程结构化、标准化，实现自动执行。

那构建技能的思路，也可以从2个层面展开：技术层和规则层。

技术层解决的是怎么做的问题。

比如怎么把PDF里的表格百分之百准确提出来，怎么按照财务规范生成一张标准化的Excel，怎么去对接企业的ERP接口。这些都是底层能力，本质上是软件工程的活，可以由技术人员来负责产出。

规则层解决的是按什么标准做的问题，本质上是规则配置。

比如针对合同审核规则，可以这样配Skills：

• payment-ruleskill - "预付款规则，上限不得超过30%"

• penalty-ruleskill - "违约金规则，赔付不得超过 20%"

• compliance-checkskill - "合规检查规则：合同必须包含保密条款"

类似上面的这些判断逻辑，基本不需要写代码，只要把规则描述清楚即可。而业务人员能做的，大多是这一类，把自己的SOP和判断口写成明确的规则。

你可以把这两类Skills想象成做Excel。技术人员开发了Excel软件，实现了计算引擎、格式处理、图表生成能力；而业务人员则负责写公式，把自己的逻辑填进去。一个负责能力，一个负责规则，两者缺一不可。

在此基础上，就可以形成如下的组织协同模式：

形成完整智能体

业务先把流程和口径梳理清楚，再把内容拆成能力和规则两部分。

能力部分交给技术做成技能，规则部分由业务自己创建单独的Skills。最后再在一套平台里把这些拼起来，变成会跑、有判断、能闭环的智能体。这样做，技能库才能越滚越大，企业也才能真正把 AI 落进业务里。

六、构建Skills时，谁来负责判断分类、指派分工？

当我们明确要把撰写Skills的任务，分成技术层和规则层后，接下来要面临的问题是：

"业务人员提了个需求，谁来判断这属于技术能力还是业务规则？"

如果只让业务人员判断，他们会认为创建个合同审核skill很简单，就是把条款读一读，让模型给个结论。但一拆就知道，这背后需要解析Word文档、识别条款语义，甚至还要调用法务知识库，这些全是工程活。

但如果完全由技术来判断，又会出现另一种情况。像客户投诉处理这种场景，技术天然会往系统能力上靠，觉得要调CRM、发邮件、记日志，所以都是技术能力。可真正让这个流程跑起来的关键，是响应时限、分类逻辑、回访规则，这些又全是业务规则。一个轻估复杂性，一个过度技术化，两边都不太准。

所以问题不是该听谁，而是需要一个能把两种语言都听懂的岗位角色来负责。

七、Skills的定义和分类：AI产品经理的新职责

我认为，这个角色必须能同时具备如下能力：

• 理解业务 - 知道业务场景、流程和痛点在哪里

• 理解技术 - 知道哪些需要代码，哪些可以用参数配置

• 理解架构 - 知道如何拆分需求，如何设计 Skills 层级

• 沟通能力 - 能在业务和技术之间相互翻译需求

他的工作方式大概是这样：

1. 业务提了个需求，说想做一个供应商审核的智能体。

2. 他不会立刻下结论，而是先问从哪里拉数据、要检查哪些资质、最后要生成什么产物。

3. 问完后，自然就知道哪些步骤是技术能力，比如查ERP、解析证照、生成报表，都需要写代码实现；

4. 而如何把ERP中解析过的资料进行标准对比，判断资质是否合格，则要通过业务逻辑来写清楚。

最终形成如下结论：

这样拆开后，该给工程给工程，该让业务自己写规则就让业务写规则，最后再在平台里把这些步骤串起来，形成一个完整的智能体。

而这样的工作职能，通常都会落在产品经理身上。

这项工作的价值在于，需要把混乱的需求拆成清晰的能力，再拼成企业真正需要的AI流程。只有这样，技能库才会越做越丰富，智能体才能真正走进业务。

八、写在最后

写这篇文章，是想站在企业咨询顾问的角度，给正在研究 Skills、想要真正落地到业务里的企业一个更贴近现实的参考。

现在市面上已经有非常多介绍Skills的技术教程，但这些内容大多都集中在原理、开发方法和个人应用上。而我认为，企业在导入新的AI技术之前，真正该想清楚的，是组织准备得怎么样，流程和规范有没有打好基础，团队有没有形成一致的理解。如果这些环节没准备好，再先进的技术也很难跑出效果。

Skills带来的不只是技术升级，更应该是组织上的变革。

传统的软件开发里，产品经理负责判断需求优先级，形成需求文档；技术团队去落地；业务人员最后拿来用。

而这套逻辑在AI时代会变成：AI产品经理先判断需求是要用技术技能还是业务技能；技术团队需要把能力封装成可复用的技能；业务不再只是提需求，而是要把自己的判断口径拆成规则写进去。一套完整的智能体，其实是技能之间的编排和组合，而不是简单的写提示词。

本质上,这是需求工程的一种升级。

如果你的企业准备规模化应用Skills，记住三件事:

1. 不要让业务人员直接创建Skills。他们只能创建规则配置，不创建技术能力

2. 设立AI产品经理角色。他是业务和技术之间的桥梁

3. 从小范围试点开始。先在一个部门验证价值，再推广到全公司

如果你在企业里负责或参与AI项目，不妨想一想：你所在的组织，有没有人提到要尝试引入Skills能力？在引入前，有没有人能分清公司需要搭建的技能库中，哪些是技术负责，哪些要业务参与？

欢迎在评论区留言，说说你对Skills落地企业的看法。

我是申悦，前互联网大厂产品人，现在是一名All in AI的企业AI转型咨询顾问。欢迎加我好友互相交流。

回复“ 微信 ”，加我 个人微信