最近在技术社区里，越来越多人在讨论一个现象：一些公司开始给员工做“skills”了。这个词最近频繁出现在 Claude Code、Codex、Cursor 这些 AI 编程工具和 Agent 框架里，也出现在企业内训、技术分享和人力资源管理的话题中。很多团队想搞明白：员工 skills 到底是什么，为什么公司要专门去做，它和普通的提示词、插件、工作流有什么区别，以及如果自己的团队也想落地，应该从哪里开始。
这篇文章会用比较直接的方式，把员工 skills 这件事拆开讲清楚。内容包括：skills 的基础概念和技术结构、企业为什么要在这个时间点做员工技能沉淀、公司级 skills 库的搭建方法、与 Claude Code / Codex / Cursor / Spring AI Alibaba 等工具的结合方式，以及落地过程中的合规、安全和效果评估问题。不管你是技术负责人、企业培训岗，还是想给自己团队引入 AI 工作流的一线工程师，都可以从这篇文章里找到可参考的路线。
1. 员工 skills 是什么：先把这个概念拆清楚
先从最基础的问题说起：员工 skills 是什么。
在 AI Agent 和编程助手的语境里，skills 可以理解为一组“可以被 AI 调用和执行的结构化能力模块”。一个 skill 不仅仅是几段提示词，它通常包含：
| 组成部分 | 作用 |
|---|---|
| 能力描述 | 说明这个 skill 什么时候该被触发，能解决什么问题 |
| 执行步骤 | 告诉 AI 按什么顺序去处理任务，避免乱来 |
| 参考示例 | 给 AI 提供输入输出的范本，提高结果稳定性 |
| 依赖脚本或工具 | 让 AI 能调用外部程序、接口或命令完成实际操作 |
| 边界与限制 | 明确哪些情况不该使用，防止被滥用或误用 |
在实际落地中，最常见的形式是类似 Claude Skills 的目录结构。一个完整的 skill 通常以一个文件夹为单位，里面包含一个SKILL.md主文件，以及若干辅助脚本、模板和参考资料。比如：
employee-onboarding/ ├── SKILL.md ├── scripts/ │ ├── generate_onboarding_todo.py │ └── fetch_company_policy.py ├── templates/ │ ├── welcome_email.md │ └── first_week_plan.md └── references/ ├── company_org_chart.txt └── faq.md这里面的SKILL.md是核心，它通过 YAML frontmatter 和正文 Markdown 告诉 AI“什么时候用、怎么用、注意什么”。举个例子，一个“员工入职引导” skill 的框架可能是这样：
--- name: employee-onboarding description: 在新员工入职时，根据部门、岗位和入职日期生成入职待办清单、欢迎邮件和第一周计划。 --- ## 使用条件 - 用户提到新员工入职、onboarding、新人报道等场景时使用。 ## 执行步骤 1. 确认新员工的部门、岗位、入职日期和直属上级。 2. 调用公司内部政策文档，提取与入职相关的流程节点。 3. 根据岗位模板生成三份交付物：入职待办清单、欢迎邮件、第一周计划。 4. 输出前检查清单里是否包含 IT 账号申请、邮箱开通、门禁权限、培训安排等常见事项。公司做的“员工 skills”，本质就是把优秀员工的经验、业务流程、岗位 SOP 和技术决策沉淀成这种结构化文件，让 AI 能复用这些能力。普通提示词是一次性的对话模板，而 skills 是有版本、有目录、可组合、可校验的工程产物。这个东西的价值不在于多炫技，而在于把隐性经验变成显性资产。
2. 为什么公司开始做员工 skills
理解了概念之后，再来看现象：为什么是现在，为什么越来越多的公司开始投入做员工 skills。
核心原因是企业面对 AI 时出现了几个很现实的问题。
第一个问题是“员工问了 AI 等于没沉淀”。很多公司已经开放了 ChatGPT、Claude、通义千问等工具给员工使用，但每个人都在重复问相似的问题，答案好坏全凭个人 prompt 水平。员工离职后，他总结的那套提问思路和工作经验也一起带走，公司什么都没剩下。skills 的出现，刚好能把这些零散的提问和经验变成公司资产。
第二个问题是“传统培训效率太低”。过去新人入职要花一到两周甚至更长时间去了解公司流程、项目背景和技术规范。如果这些信息被整理成 skills，AI 就能在对话中直接调用，新人在提问时就能获得带业务上下文的回答，培训周期可以明显缩短。这不是把培训材料扔给新人自己看，而是让 AI 扮演一个“懂公司内部业务”的助手。
第三个问题是“AI 用得越多，规范越重要”。公司让员工用 AI 写代码、写文档、做数据分析，如果不做统一约束，每个人的输出风格、代码规范、技术选型都可能不一样。把公司内部的最佳实践做进 skills，员工通过 AI 产出内容时，天然会遵循这些规范。质量和一致性问题可以部分靠 AI 兜底。
第四个问题是“通用 AI 不懂业务细节”。通用大模型对公开知识很熟悉，但对公司内部的项目代号、历史决策、遗留系统、产品逻辑一无所知。员工 skills 相当于给 AI 插上了“公司业务知识接口”，让它能在合规范围内使用内部知识库、调用内部 API、遵循内部流程。
所以，公司开始做员工 skills，本质上是在做三件事：把零散经验产品化、把个人能力组织化、把 AI 使用规范化。这件事能同时影响效率提升、知识管理和人才培养，自然会在技术圈引发讨论。
3. skills 的通用结构与编写格式
想在公司层面推动 skills 落地，不能只停留在概念，必须先把技术格式统一。目前市面上的 skills 在命名和实现上会有些差异，比如 Claude Code Skills、Codex 的 agent skills、Cursor 的 rules 和自定义指令，但核心思路是共通的。
一个团队在起步阶段，可以先约定一套内部格式，不必一开始就追求和某个商业产品完全兼容。下面是一套经过社区验证的通用结构，适合大多数企业场景。
3.1 skill 目录结构
建议每个 skill 单独一个目录，目录名使用中划线命名法，例如：
skills/ ├── code-review/ ├── api-design-review/ ├── incident-response/ ├── employee-onboarding/ ├── sales-proposal-writing/ └──>--- name: skill-name description: 一句话说明这个 skill 的适用场景和触发条件。 --- ## 背景 说明这个 skill 为什么存在，解决什么问题。 ## 使用条件 列出 AI 应该在什么情况下调用这个 skill。 ## 执行步骤 分步骤描述 AI 完成任务的路径。 ## 输入要求 定义用户需要提供哪些信息，以及缺失时的处理方式。 ## 输出格式 明确最终交付物的格式要求，避免 AI 自由发挥。 ## 注意事项 写明禁止做的事、需要人工确认的节点、以及可能的失败情况。这里有一个容易被忽略的点：description 字段很重要，它直接影响 AI 是否会在正确时机触发这个 skill。好的 description 应该包含触发关键词和使用场景，而不是写抽象的官话。
3.3 一个具体的员工 skill 示例
以“销售方案撰写”为例，写一个简化的SKILL.md：
--- name: sales-proposal-writing description: 当销售需要生成客户提案、投标方案或产品介绍时使用，可结合客户背景生成结构化文档。 --- ## 背景 用于提升销售提案的质量和生成效率，统一公司对外输出风格。 ## 使用条件 - 用户需要写客户提案、解决方案、投标文件。 - 用户提供客户名称、行业、需求背景等信息。 ## 执行步骤 1. 确认客户所属行业、决策链角色、预算范围和使用场景。 2. 从公司产品知识库中匹配对应的产品模块和案例。 3. 按照公司模板生成提案框架，包括客户痛点分析、解决方案、实施计划、报价说明。 4. 提示用户补充特殊要求，再进行最终润色。 ## 输出格式 Markdown 或 Word 兼容的提案正文，包含标题层级、重点摘要和行动号召。 ## 注意事项 - 不允许编造客户预算、签约时间等敏感数据。 - 涉及商务报价时，必须由销售负责人确认后再输出。这种 skill 的价值在于：每个销售的输出水平会向公司内的高水平文案靠拢，并且生成过程有固定的步骤可审计。这就是公司级 skills 和普通 prompt 的重要区别。
4. 企业落地 skills 的四个层级
公司做员工 skills，不会一步到位，通常会经历四个层级。了解这些层级有助于团队制定合理的目标和节奏。
4.1 个人级：员工自己整理 AI 使用技巧
第一阶段是个人自发的。比较常见的现象是员工用 Claude Code、Codex 或 Cursor 时，发现自己常用的指令和工具配置很有效，于是整理成个人配置。这一步还没有公司层面的组织，但它是所有后续工作的种子。
这个阶段的产出物通常是个人目录、个人配置项、个人 prompt 模板。最容易出现的问题是“人走配置没”，员工离职后这些配置就失效了。所以公司如果发现员工开始大量自发整理 AI 使用技巧，就应该及时介入，引导到团队级沉淀。
4.2 团队级：围绕核心业务场景做沉淀
第二阶段是在某个技术团队或业务团队内部，把高频、可复用、有明确收益的场景转写成 skills。典型场景包括代码审查、接口设计、故障排查、数据分析、测试用例生成、发布检查。这个阶段的核心任务是选对场景，不需要贪多。
团队级 skills 的验收标准很简单：团队里的新成员能不能通过这个 skill 在更短时间内完成过去需要老员工指导的任务。如果能，就说明沉淀有效；如果只是写得好看但没人用，就要重新审视使用门槛和触发条件。
4.3 部门级：跨团队共享与统一规范
第三阶段是从一个团队走向多个团队，开始出现 skills 共享平台、统一仓库和审核机制。此时公司需要解决的就不再是“写一个 skill”，而是“让多个团队按同一套标准写 skill”。部门级落地需要配套的命名规范、版本管理、负责人制度和效果评估机制。
部门级 skills 通常会分专业线管理，比如研发线、产品线、设计线、销售线各有一套 skills，但可以共享公共基础设施类 skills。这个阶段对稳定性、安全性和质量控制的要求会明显提高。
4.4 公司级：技能资产化与人才赋能
第四阶段是把员工 skills 上升到公司层面，作为知识资产进行投入和运营。公司级 skills 库会和内部知识库、权限系统、审计系统打通，形成一套“AI 赋能员工”的基础设施。此时 skills 既是培训工具，也是生产力工具。
公司级落地的关键不是技术，而是治理。所有权归谁、谁能修改、谁能调用、如何更新、如何评估 ROI，这些问题必须在第四阶段给出明确答案。否则 skills 库会变成一个新的“文档垃圾场”。
5. 企业 skills 库怎么建：从零起步的实操路线
下面给出一套从零起步的实操路线，适合还没开始或者刚起步的团队参考。
5.1 第一步：选一个试点场景
不要一开始就铺开做几十个 skills，而是挑一个明确、高频、容易量化收益的场景。推荐选择以下几类之一：
| 场景类型 | 示例 | 量化指标 |
|---|---|---|
| 代码审查 | 新代码合并前的自动审查 | 单次审查时间、发现的问题数 |
| 客户方案 | 销售提案生成 | 方案产出时间、交付质量评分 |
| 入职培训 | 新员工 onboarding 计划生成 | 入职准备完成时间 |
| 故障排查 | 常见故障的诊断步骤指导 | 平均恢复时间 |
| 测试设计 | 产品需求的测试用例生成 | 用例覆盖率和生成耗时 |
选择试点的原则是：业务价值高、边界清晰、AI 有能力完成大部分操作、失败风险可控。
5.2 第二步：收集业务知识和优秀案例
选好场景后，找该领域最优秀的 1 到 2 位员工，收集他们的工作流程、判断标准、常用工具和交付模板。这一步的关键是提取“隐形知识”，不要只复制公开文档。可以通过访谈、观察和复盘来完成。
产出物是：一份业务流程图、一份决策规则清单、几个高质量输入输出示例。
5.3 第三步：转写成 SKILL.md 并测试
把整理出来的知识转写成前面说的SKILL.md格式，然后用 AI 工具反复跑测试。测试时重点看三个问题：
- skill 是否在正确场景被触发；
- 执行步骤是否稳定可靠；
- 输出结果是否达到内部质量标准。
测试阶段不要怕失败。一个 skill 通常要迭代 5 到 10 次才能真正稳定。常见问题是描述写得太宽泛导致误触发、步骤太抽象导致输出发散、缺少边界规则导致 AI 做了一些不该做的事。
5.4 第四步：建立评审与更新机制
skills 不是写一次就完事，它像代码一样需要维护。建议在团队内指定一名 skills 负责人，负责内容审核、版本更新和效果监控。更新频率可以跟着业务节奏走：业务流程变了、产品功能更新了、员工反馈有问题了，都要及时改。
每一条 skill 都建议在头部记录维护人、更新日期、适用版本范围。这能避免多人在同一文件上互相覆盖。
5.5 第五步：统一存放与权限管理
skills 的存放方式可以从一个 Git 仓库开始，这是目前最稳妥的选择。所有修改有记录，有合并请求，有代码审查。到后期如果需要更细的权限控制，再考虑接入专业平台。
仓库结构可以参考：
company-skills/ ├── README.md ├── catalog.yaml ├── engineering/ │ ├── code-review/ │ └── api-design-review/ ├── sales/ │ └── proposal-writing/ └── hr/ └── employee-onboarding/catalog.yaml可以维护一份总索引，方便后续开发内部 skills 市场或接入到 AI 工具时快速检索。
6. 员工 skills 与现有 AI 工具的结合方式
做员工 skills 不是另起炉灶，而是要嵌入到员工已经在用的工具链里。目前主流结合方式有几种。
6.1 结合 Claude Code / Codex / Cursor 等编程工具
编程场景是目前最成熟的 skills 落地场景。Claude Code 支持通过目录方式加载自定义技能，Codex 也在持续推进 agent skills 和自定义技能机制，Cursor 可以通过 rules 和自定义指令实现类似能力。团队可以把内部编码规范、项目架构说明、代码审查清单整理成 skills，让 AI 在编码过程中自动遵守。
比如一个公司规定所有后端接口必须包含限流、熔断、审计日志。这个规定如果只写在文档里，AI 大概率不会主动想起来；如果做成 skill，AI 在生成代码时就会默认带上这些组件。这就是 skills 在工程规范落地上的价值。
6.2 结合 Spring AI Alibaba 等企业级框架
在 Java 生态里，Spring AI Alibaba 这类框架也在讨论如何实现 skills。企业级框架里做 skills 的优势是：可以跟 Spring 的现有机制结合，统一管理模型调用、工具注册和上下文，更适合需要和业务系统深度集成的团队。如果公司的 AI 应用是基于 Java 技术栈开发的，可以考虑把 skills 作为能力模块注入到已有 AI Agent 服务中。
这种方式适合更正式的 B 端系统集成场景。比如内部工单机器人、智能客服、知识问答系统，都可以通过 skills 扩展能力，而不是每次更新都改代码。
6.3 理解 skills 与 agent、tools 的区别
很多人容易把 skills 和 agent、tools 混在一起，这里说一下基本区别。
| 概念 | 定位 | 举例 |
|---|---|---|
| Agent | 能自主规划并完成一个目标的 AI 执行体 | 一键生成每周数据分析报告 |
| Tools | AI 可调用的外部功能接口 | 查询数据库、发邮件、调用 API |
| Skills | 让 AI 知道“怎么做对一件事”的方法包 | 公司内部代码审查流程 |
可以把三者理解成：Agent 是司机，Tools 是方向盘和油门，Skills 是地图和交规。在落地时，skills 经常会调用 tools，也会被 agent 作为执行步骤之一，但它们本身不是同一个东西。
7. 员工 skills 落地中的安全与合规边界
企业做员工 skills，和普通开发者自己玩 skills 最大的区别在于安全、隐私和合规要求。这块必须提前想清楚，否则后期很容易出问题。
7.1 权限隔离与最小访问原则
skills 可以访问企业内部知识库、API 和文档，因此必须严格执行权限隔离。不同岗位、不同等级的员工能调用的 skills 和知识范围应该不一样。比如销售可以调用产品方案类 skills，但不应该能调用薪酬绩效类 skills。
建议在接入权限系统时，按照“最小访问原则”设计，每个 skill 只声明自己需要的数据和接口，不图省事给 all_access。
7.2 敏感信息脱敏与审计
如果 skills 里包含公司战略、客户信息、员工个人信息，必须做脱敏处理。内部测试时可以使用虚构数据，避免把真实敏感数据直接写进 skill 示例。同时，所有通过 AI 调用 skills 产生的操作，都应该记录日志，方便审计和追溯。
这一点对于涉及人脸、声音、个人数据处理的场景尤其重要。无论是员工 skills 还是其他 AI 应用，只要涉及个人信息，都必须严格遵守个人信息保护相关法规。
7.3 避免技能被滥用
员工 skills 本身没有攻击性，但如果设计不严谨，AI 可能通过 skill 执行超出预期的操作。比如一个“自动生成付款申请”的 skill，如果缺少人工审批节点，就可能被恶意利用。建议在涉及资金、权限、账号、合同、对外发布等高风险动作时，强制设置人工确认环节。
7.4 版权与合规提醒
编写 skills 时如果参考了外部资料、同行方案、开源项目，要注意版权问题。公司内部沉淀的经验一般问题不大，但如果直接复制外部资源，需要确认授权范围。同时，对外输出内容如果由 AI 基于 skills 生成，公司也要对内容质量负责，不能以“AI 生成”为由推卸责任。
8. 员工 skills 常见问题与排查方向
在实际推进员工 skills 的过程中，团队会踩到不少坑。下面整理一些常见问题和排查方向。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| AI 不触发某个 skill | description 写得太窄或太宽，触发条件不清晰 | 查看该 skill 被其他场景错误触发或从不触发的情况 | 重写 description，明确触发关键词和使用场景 |
| 输出结果不稳定 | skill 步骤太抽象，缺少输入输出示例 | 用同一输入连续测试 5 次，观察差异点 | 补充更详细的执行步骤和参考示例 |
| skill 互相冲突 | 多个 skill 的描述存在重叠，AI 无法判断用哪个 | 检查 catalog 里各 skill 的 description | 明确边界，必要时合并或加优先级 |
| 员工不愿使用 | skills 使用门槛高、输出质量不达标 | 统计实际调用频率，收集反馈 | 简化调用方式，先做高质量试点再推广 |
| 更新困难 | 没有维护人，版本混乱 | 检查仓库 commit 记录和文件头维护信息 | 指定负责人，建立按业务节奏更新的机制 |
| 知识泄密风险 | skills 文件包含敏感信息 | 审查所有入库内容 | 删除敏感信息，接入权限系统，加强审计 |
| 与现有工具不兼容 | 格式不符合特定工具要求 | 对照工具官方文档检查格式 | 做一层转换层，或统一采用兼容格式 |
这些坑几乎每个团队都会遇到。核心应对策略是：把 skills 当代码维护，而不是当文档整理。走小步、勤反馈、持续迭代，远好过一开始就追求大而全。
9. 最佳实践与使用建议
结合目前社区讨论和企业落地情况，提出几条比较实用的建议。
9.1 从最小闭环开始，不要追求数量
先做 3 到 5 个真正高频且价值明显的 skills，把它们做深做透，再逐步扩展。数量上去但质量不够，只会消耗员工的信任。技能库最怕的不是空，而是充满让人用不下去的废品。
9.2 每一次迭代都要有评估指标
不要用“感觉好用”来评估 skills。建议每个 skill 定一到两个可量化指标：生成时间、一次性通过率、员工使用率、返工次数。每次更新后对比指标变化，用数据决定保留还是重写。
9.3 把 skills 纳入培训和 onboarding
员工 skills 最直接的价值场景是新人培训和岗位交接。建议在新员工入职第一天就教他使用内部的 skills 库，让它成为工作习惯的一部分，而不是等到遇到了问题再想起来用。
9.4 保留纯人工流程作为兜底
即使 skills 的效果再好，也要保留人工审核环节。尤其是在代码上线、商务报价、对外发布、招聘决策等高风险场景，AI 的产出必须经过人工确认。AI 是放大器，不是责任转移工具。
9.5 定期复盘，防止技能库腐化
业务一变化，老 skills 就可能失效。建议每季度做一次技能库盘点，删除不再使用的、更新已过时的、修复质量不稳的。保持技能库新鲜，比持续新增更重要。
10. 总结：下一步可以先做什么
公司开始做员工 skills，这个趋势背后反映的问题很实在：AI 时代，企业不能再让个人经验靠人传人，必须用工程化手段把能力沉淀到组织层面。skills 是目前看最接近这一目标的载体。它有结构、有版本、可组合、能接入主流 AI 工具，也能配合企业现有权限和审计体系。
如果你所在的公司也想尝试，建议先从最值得做的三件事开始：选一个高频业务场景、找一位优秀员工做经验访谈、把经验转写成第一个SKILL.md并跑通一轮测试。只要这三点完成，你就已经站在了“员工 skills 落地”的起点上。
最容易踩的坑也很明确：一是把 skills 当成普通文档写，缺少结构化和可执行性；二是一开始就要做几十个 skills，结果维护不过来；三是忽略了权限和安全问题，给后续埋雷。避开这三个坑，剩下的主要靠持续迭代和团队反馈。
后续可以继续关注的方向包括：skills 格式的标准化与跨工具兼容、企业内部 skills 市场和共享平台的成熟、以及 skills 和 Agent 深度结合后带来的效率上限提升。这个话题还在快速发展中，今天建立的 skill，可能半年后就会被更好的方案取代。但有一点不会变：把员工经验变成可复用、可治理、可调用的组织能力，这件事在任何技术路线下都值得做。
