Skills 正在成为 Agent 领域的新标准，但个人开发者玩得很嗨，企业却对此很谨慎。企业落地 Skills 需要作用域隔离、技能审计、自定义机制等四个前提，更需要 AI 产品经理在业务与技术之间搭建桥梁。这不仅是技术升级，更是组织变革。
2026年初，如果说AI圈爆火的技术是什么，Skills这个词一定会被提及。
从Anthropic开放Agent Skills规范，到OpenAI在Codex CLI采用相同格式，再到GitHub涌现出上千个开源技能库——Skills正在成为Agent领域的新标准。
但如果你仔细观察，会发现一个有趣的现象：个人开发者玩得很嗨，企业却对此很谨慎。
为什么会这样？带着这个思考，假期我也全面研究了下Skills，并从中得到一个启发：
一个新AI技术的落地，考验的不只是合适的应用场景、充足的技术储备，更要在组织上做好变革。
这篇文章，就来和大家聊聊这个观点。
Skills的全称，是Agent Skills，名字很直观，这是给Agent用的，用来让它具备各种“实操技能”的。
一个Skills，是以文件夹形式存在的，这个Skills文件夹里有什么呢？
一个SKILL.md文件(说明了如何使用这个SKILL和具体的执行步骤)
可选的脚本、参考文档和资源包
详细的结构说明如下：
my-skill/
├── SKILL.md # 必须有，包含了指导智能体如何执行任务的说明
├── scripts/ # 可选，包含着可执行任务的代码
├── references/ # 可选，参考文档
└── assets/ # 可选，模板、资源
智能体可以在读取Skills文件夹后，按照里面的指导说明，更准确、高效地完成特定任务。
比如pdf skill，可以让AI精确解析并提取PDF中各种特定格式的内容；java-best-practices skill，可以让AI按规范写Java代码；pr-creator skill，可以让AI自动创建符合规范的GitHub Pull Request。
理解一下，Skills本质上是个模板，用来把一些共性的步骤、流程、资源抽象成配置文件，让它可以被不同智能体调用，实现能力复用。
为什么它能在2026年初爆火？
因为Skills的出现，解决了通用AI的一个很大的痛点——能力边界。
通用模型再强大，也无法在所有领域达到生产级标准，比如对复杂文件格式的解析精度不足、对特定技术栈的工程规范理解有限、缺乏与外部系统的直接交互能力等等。
Skills的本质，则是将专业能力封装为标准化模块，你可以根据任务要求，灵活组合不同能力，让AI可以实现“按需调用”。为方便理解，我画了一张图帮你理解：
这背后体现着Skills一个很重要的设计理念：渐进式加载（Progressive Loading）。即：如果有多个Skills，智能体在启动时，会先读取每个Skill的名字和描述，了解它们的能力。等用户下达任务后，由系统判断和某个Skill匹配，才按需加载它的完整指令、脚本和参考资料。这样既节省上下文空间，又能在真正需要时提供完整能力。
那接下来问题来了：这么厉害的新技术，企业是不是也可以用起来？
听起来很有道理，Github上有上百种现成技能，直接都导进来，是不是就能覆盖大多数业务场景了？
但深入研究下来你会发现，远没有那么简单。
作为个人使用，Skills是很好用的“提效工具库”，但企业应用则是完全不一样的要求，因为它要真实嵌入流程、嵌入职责分工的能力模块，不做好额外准备就很容易推行失败。为此，我总结了四项企业应用Skills的关键机制：
个人用Skills完成任务很简单，让模型能读懂指令，成功调用工具输出结果即可。但企业则完全不一样。
财务的技能、法务的技能、研发的技能、销售的技能，它们的边界都非常敏感，不可能放在同一个上下文里混着跑。更不可能让一个部门随意调用另一个部门的能力。
所以企业首先要考虑的，是：
只有先做好隔离，才能提前把风险限定在可控范围内。
个人用智能体，很少有人会在意Agent的执行过程。
但企业必须知道谁触发了技能、什么时候触发的、执行的是哪个技能、产出了什么结果，以及有没有越权。
目的是合规和透明。
所以企业级Skills的背后，一定要有日志、链路和回滚机制，以确保过程安全可控。
对企业而言，真正有价值的部分，是那些专属于所在业务场景下的特有流程、判断标准、字段定义和实施链路，在执行时要遵循的内部合规要求和决策逻辑，最终输出的话术也是常年沉淀下来的。
因此无论Github上有多少现成的Skills，企业也是没法直接复用的。
如何把内部的SOP、判断逻辑、流程细节，封装成可维护的技能。才是决定Skills能否成为企业能力资产的关键。
尽管渐进式加载能极大减少每次模型读取上下文的token数，但企业应用不像个人，其使用规模一上量，成本就会变成肉眼可见的压力：响应时间、调用次数、并发量、缓存策略、成本分摊……这些都必须提前设计。
在这个基础上，企业必须提前确立调用配额，制定缓存和降本策略，并把成本分摊到每个使用Skills的部门，只有这样，才能让Skills从试点切换成全域覆盖的基础设施。
如果要从上述4个机制中选一个最重要、最优先要建立的，当属“技能自定义机制”。
也许你会说，现在开源社区里的技能已经几百个了，全都装上，让模型根据需求选择合适的技能不就好了？
看起来是这样，但一旦把需求放进企业现场，你马上会发现：通用技能最多帮你解决三成，剩下七成全是每家公司的独有规则，根本没有现成的替代品。
举个最直观的例子：企业想做一套合同审核流程。你可以用现成的pdf skill提取合同内容，但模型不知道什么技能可以判断合同哪一条属于争议条款，也不知道你们公司惯用的审核报告长什么样。因为它没有你们内部的判断口径，也不知道企业的流程细节。只有把合同审核规则、报告呈现格式按企业自己的规范拆出来，一条条写进技能里，才能让其变成稳定、可复用的能力模块。
说白了，通用技能给的是工具，而定制技能给的是规则，而规则才是企业真正的价值所在。
但这里面也有个很大的陷阱。
很多企业会认为：
“让业务人员把自己的经验转化为Skills，不就能快速积累技能库了吗？”
听起来很合理，但真正落到执行层面，你会发现：绝大多数技能不是靠写两段提示词就能完成的。
我们可以打开awesome-claude-skills这个著名的Skills仓库看看，上面的热门技能，要么要写代码，要么要写极其专业、结构化的提示词。
处理PDF的要写Python，处理Word、Excel的也一样要写代码；不需要写代码的那类技能，往往要求你把流程拆得非常精细，把输入输出写成工程化的格式。这不是在文档里写几句经验就能完成的事。
那业务人员到底能做什么？
更多时候，他们能沉淀的是“规则类”的技能，也就是把自己的判断逻辑拆出来，让模型按规矩走。
只要技能涉及底层能力调用、文件解析、流程自动化、复杂结构化生成，基本都要靠工程团队来落地。业务懂经验，但技能的工程化落地，则需要另一套方法论和技能栈。
Skills技术的优势，在于把重复的流程结构化、标准化，实现自动执行。
那构建技能的思路，也可以从2个层面展开：技术层和规则层。
技术层解决的是怎么做的问题。
比如怎么把PDF里的表格百分之百准确提出来，怎么按照财务规范生成一张标准化的Excel，怎么去对接企业的ERP接口。这些都是底层能力，本质上是软件工程的活，可以由技术人员来负责产出。
规则层解决的是按什么标准做的问题，本质上是规则配置。
比如针对合同审核规则，可以这样配Skills：
类似上面的这些判断逻辑，基本不需要写代码，只要把规则描述清楚即可。而业务人员能做的，大多是这一类，把自己的SOP和判断口写成明确的规则。
你可以把这两类Skills想象成做Excel。技术人员开发了Excel软件，实现了计算引擎、格式处理、图表生成能力；而业务人员则负责写公式，把自己的逻辑填进去。一个负责能力，一个负责规则，两者缺一不可。
在此基础上，就可以形成如下的组织协同模式：
业务人员梳理 SOP
↓拆分为两类需求：
├─ 能力需求（需要技术实现）→ 技术人员创建 Skills
└─ 规则需求（只是规则配置）→ 业务人员创建 Skills
↓编排2者组合而成的工作流
↓形成完整智能体
业务先把流程和口径梳理清楚，再把内容拆成能力和规则两部分。
能力部分交给技术做成技能，规则部分由业务自己创建单独的Skills。最后再在一套平台里把这些拼起来，变成会跑、有判断、能闭环的智能体。这样做，技能库才能越滚越大，企业也才能真正把 AI 落进业务里。
当我们明确要把撰写Skills的任务，分成技术层和规则层后，接下来要面临的问题是：
“业务人员提了个需求，谁来判断这属于技术能力还是业务规则？”
如果只让业务人员判断，他们会认为创建个合同审核skill很简单，就是把条款读一读，让模型给个结论。但一拆就知道，这背后需要解析Word文档、识别条款语义，甚至还要调用法务知识库，这些全是工程活。
但如果完全由技术来判断，又会出现另一种情况。像客户投诉处理这种场景，技术天然会往系统能力上靠，觉得要调CRM、发邮件、记日志，所以都是技术能力。可真正让这个流程跑起来的关键，是响应时限、分类逻辑、回访规则，这些又全是业务规则。一个轻估复杂性，一个过度技术化，两边都不太准。
所以问题不是该听谁，而是需要一个能把两种语言都听懂的岗位角色来负责。
我认为，这个角色必须能同时具备如下能力：
他的工作方式大概是这样：
业务提了个需求，说想做一个供应商审核的智能体。
他不会立刻下结论，而是先问从哪里拉数据、要检查哪些资质、最后要生成什么产物。
问完后，自然就知道哪些步骤是技术能力，比如查ERP、解析证照、生成报表，都需要写代码实现；
而如何把ERP中解析过的资料进行标准对比，判断资质是否合格，则要通过业务逻辑来写清楚。
最终形成如下结论：
这样拆开后，该给工程给工程，该让业务自己写规则就让业务写规则，最后再在平台里把这些步骤串起来，形成一个完整的智能体。
而这样的工作职能，通常都会落在产品经理身上。
这项工作的价值在于，需要把混乱的需求拆成清晰的能力，再拼成企业真正需要的AI流程。只有这样，技能库才会越做越丰富，智能体才能真正走进业务。
写这篇文章，是想站在企业咨询顾问的角度，给正在研究 Skills、想要真正落地到业务里的企业一个更贴近现实的参考。
现在市面上已经有非常多介绍Skills的技术教程，但这些内容大多都集中在原理、开发方法和个人应用上。而我认为，企业在导入新的AI技术之前，真正该想清楚的，是组织准备得怎么样，流程和规范有没有打好基础，团队有没有形成一致的理解。如果这些环节没准备好，再先进的技术也很难跑出效果。
Skills带来的不只是技术升级，更应该是组织上的变革。
传统的软件开发里，产品经理负责判断需求优先级，形成需求文档；技术团队去落地；业务人员最后拿来用。
而这套逻辑在AI时代会变成：AI产品经理先判断需求是要用技术技能还是业务技能；技术团队需要把能力封装成可复用的技能；业务不再只是提需求，而是要把自己的判断口径拆成规则写进去。一套完整的智能体，其实是技能之间的编排和组合，而不是简单的写提示词。
本质上,这是需求工程的一种升级。
如果你的企业准备规模化应用Skills，记住三件事:
如果你在企业里负责或参与AI项目，不妨想一想：你所在的组织，有没有人提到要尝试引入Skills能力？在引入前，有没有人能分清公司需要搭建的技能库中，哪些是技术负责，哪些要业务参与？
本文由人人都是产品经理作者【申悦】，微信公众号：【互联网悦读笔记】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。