员工 skills 开始进入公司视野并不是因为“AI 又能做什么新功能”而是因为同一个团队里不同员工使用 AI 的产出质量差距太大。有人用 Claude Code、Cursor、Codex、OpenCode 这类 Agent 工具能把会议纪要、代码审查、前端排错、PPT 初稿做到接近可直接交付有人却还在反复试提示词。企业开始意识到与其让每个人在对话里各自摸索不如把已经验证过的工作方法、模板、脚本和边界规则沉淀成标准化 skills 包统一安装到员工的 AI 客户端里。所谓 skills可以理解成“能被 AI 智能体在合适场景下自动加载的一套技能模块”。它不只是提示词而是一个包含说明文件、脚本、示例和约束规则的目录。模型遇到对应任务时会读取这个技能包按照里面的步骤执行调用需要的工具最后按统一格式输出。这篇文章会从概念讲起再写一个可落地的会议纪要归档 Skill最后补充企业级分发、评估、排错和推广建议。1. 员工 skills 是什么从提示词碎片走向团队技能库1.1 Skills、Prompt、Tool、Agent 的边界很多人在聊 skills 时会把提示词、插件、工具、Agent 混在一起。实际上它们各有分工。Prompt 是一次性给模型的文本指令适合临时任务但不容易版本化也很难跨人复用。Skill 是一组结构化材料通常是一个目录里面有说明文档、脚本、模板和例子模型按需加载。Tool 是模型可以调用的具体函数比如读写文件、执行命令、调用 API它的行为是确定性的。Agent 是负责拆解任务、规划步骤、决定何时加载哪个 Skill、调用哪个 Tool 的执行器。它们的关系可以用一句话概括Agent 负责“想怎么做”Skill 负责“按什么方法做”Tool 负责“具体动作谁来做”。形式是否版本化是否可团队共享主要解决什么问题Prompt通常不版本化不方便共享临时指导模型输出Skill可以进 Git 仓库适合团队共享把工作方法、模板和约束包装成可加载模块Tool是代码接口可以共享提供确定性的原子能力Agent是执行调度者可以共享决策如何完成任务在员工技能的语境下最重要的资产不是某一条写得很好的提示词而是把提示词、规则、脚本、模板做成一个可维护、可评估、可灰度的 Skill 包。1.2 公司为什么开始把它当作“员工技能”来管理公司做员工 skills本质上是在做知识管理只不过知识不再是文档而是“能被 AI 执行的操作手册”。有几个推动因素很现实高频场景需要稳定输出。会议纪要、周报、测试用例、PPT 初稿、代码 review 这类任务重复度高但不同人的输出格式差异大。新人上手成本高。新人不知道公司的文档模板、代码规范、发布流程Skill 可以把这些隐性知识直接放进 AI 工作流。提示词容易失传。员工离职后个人积累的提示词和脚本很难移交Skill 进入 Git 仓库后知识归属从个人变成组织。结果可度量。Skill 可以记录版本、执行次数、成功率和人工修正率比“某员工 AI 用得不错”更可量化。这里要注意员工 Skills 不是让 AI 替员工做判断而是让 AI 承担可标准化的步骤员工把精力放在确认、决策和异常处理上。1.3 典型使用场景不同岗位适合先做的 Skill 不一样。场景示例 Skill适合团队会议纪要把转写稿整理成决议、待办、风险列表全员会话归档把当天 AI 对话中的关键结论写入团队知识库研发、产品前端开发按团队规范生成组件、修复样式问题、补充 Playwright 测试前端测试执行基于页面操作生成测试用例并跑断言QA、前后端PPT 初稿按讲稿生成大纲、逐页要点和备注运营、行政项目脚手架用 Spring Boot 3 生成统一结构的项目Java 后端运维排查按日志关键字、系统指标给出排查步骤SRE、运维论文写作整理文献、生成综述初稿、检查引用格式高校、研究岗这些场景的共同点是有明确输入、有稳定输出结构、有可检查的中间产物。这样的任务最适合先做成 Skill。2. 先把 Skill 的目录结构和格式搞清楚2.1 一份 SKILL.md 就是技能的核心目前最常见的一种 Skill 格式是目录化结构核心文件是SKILL.md。模型加载技能时首先读取这个文件通过 front matter 里的name和description判断是否应该在当前场景触发。下面是一个会议纪要 Skill 的最小示例。--- name: meeting-minutes description: 根据会议录音转写稿或原始笔记生成结构化会议纪要提取决议和待办项并按团队模板归档到 docs/meeting-minutes 目录。适合会议结束后立即使用。 version: 1.0.0 --- # 会议纪要生成 ## 使用场景 输入是一段会议转写稿、语音识别文本或手写会议笔记片段。 ## 执行步骤 1. 先阅读完整输入区分事实、观点、决议和待办。 2. 按 resources/meeting_template.md 输出会议纪要。 3. 待办事项必须包含负责人、截止日期、优先级三列。 4. 无法从原文确认的信息标记为“待确认”不要自行补全。 5. 将结果写入 docs/meeting-minutes/YYYY-MM-DD.md。 6. 如果存在多个主题用二级标题拆开不要全部塞进一个段落。 ## 禁止事项 - 不要编造没有出现在原文中的发言。 - 不要省略有明确负责人的待办项。 - 不要把口语化寒暄写入“会议结论”。这段SKILL.md看起来像提示词但它的价值在于进入了目录结构可以被版本管理也可以被 Agent 在合适时机自动加载。description字段特别重要。很多 Skill 不生效不是因为规则写得不好而是描述里的触发词和用户请求对不上。描述要写清楚“什么时候用”和“什么时候不用”例如“适合会议结束后立即使用”这样 Agent 才不会在写代码时误加载会议纪要技能。2.2 目录里除了 SKILL.md 还放什么一个技能目录通常可以包含以下内容。meeting-minutes/ ├── SKILL.md ├── resources/ │ └── meeting_template.md ├── scripts/ │ └── archive_meeting.py └── examples/ └── sample_output.mdresources放模板和参考资料scripts放模型可以直接调用的小脚本examples放输入输出样例帮助模型理解预期的产出形式。不是每个 Skill 都必须有脚本。如果任务只是“按模板整理文本”纯SKILL.md就够了。但一旦涉及文件路径、日期计算、API 调用、数据去重脚本能让结果更稳定因为模型直接写 Shell 或 Python 代码时容易在细节上出错。2.3 安装和分发方式Skills 的安装方式取决于团队接入的运行时。个人使用时最直接的是把技能目录放到配置目录例如 Claude Code 的项目级.claude/skills或用户级~/.claude/skills目录。Codex、Cursor、OpenCode 等工具也有各自的技能配置目录具体路径要以使用的版本说明为准。如果团队把 skills 封装成 npm 包员工可以通过类似命令安装。npx skills install team-skills/meeting-minutes npx skills list npx skills update meeting-minutesnpx skills是什么简单说就是一个命令行入口用来安装、列出和更新本地技能包。具体命令名都由团队封装决定不一定所有环境都叫skills但思路一致把技能包从仓库分发到员工本机。注意不要直接把从网上下载的 Skill 解压到生产环境。目录里的脚本会以当前用户权限执行必须先检查脚本内容、依赖和网络请求。3. 实现一个可用的员工技能会议纪要归档3.1 需求拆解先明确输入输出。输入是会议转写文本输出是一份符合团队模板的 Markdown 会议纪要并且自动归档到指定目录。拆解后的步骤是读取转写文本。识别会议主题、参会人和时间。整理讨论要点、决议、待办项。如果原始文本中有“负责人张三截止周五”这样的表达提取成结构化待办。按模板生成 Markdown 文件。写入docs/meeting-minutes/2025-07-01.md。这个 Skill 不需要复杂模型调用它更多的是把 Agent 的“思考步骤”和脚本的“稳定能力”结合。3.2 编写 SKILL.md继续使用上一节中的meeting-minutes/SKILL.md但要加上脚本调用说明。--- name: meeting-minutes description: 将会议转写稿整理成结构化会议纪要提取决议和待办项并调用 archive_meeting.py 归档。适合会议结束后立即使用。 version: 1.1.0 --- # 会议纪要生成 ## 输入 - 会议转写稿 - 原始笔记 ## 步骤 1. 先识别会议主题、日期、参会人。 2. 将内容分为“背景”“讨论”“决议”“待办”四类。 3. 将待办整理为表格字段为待办内容、负责人、截止时间、优先级。 4. 按 resources/meeting_template.md 拼装 Markdown。 5. 将结果传给 scripts/archive_meeting.py脚本会写入 docs/meeting-minutes/ 目录。 6. 如果输出文件已经存在不要覆盖先向用户确认。 ## 约束 - 不要编造事实和具体时间。 - 不要删除原文中的风险提示。 - 如果输入是语音转写文本注意处理同音词和口语重复。这里的重点是第 5 步。脚本负责“文件写入”模型负责“内容整理”分工明确。3.3 脚本和模板归档脚本用 Python 写一个最小示例。#!/usr/bin/env python3 import argparse import pathlib from datetime import date def main() - None: parser argparse.ArgumentParser(description归档会议纪要) parser.add_argument(--content, requiredTrue, help会议纪要 Markdown 内容) parser.add_argument(--date, defaultdate.today().isoformat(), help会议日期 YYYY-MM-DD) parser.add_argument(--output-dir, defaultdocs/meeting-minutes, help归档目录) args parser.parse_args() output_dir pathlib.Path(args.output_dir) output_dir.mkdir(parentsTrue, exist_okTrue) output_path output_dir / f{args.date}.md if output_path.exists(): raise SystemExit(f文件已存在: {output_path}) output_path.write_text(args.content, encodingutf-8) print(f已写入: {output_path}) if __name__ __main__: main()这个脚本不复杂但解决了三个问题保证目录存在、避免覆盖已有文件、输出明确的写入路径。模板文件resources/meeting_template.md可以写成# 会议纪要{主题} - 日期{date} - 参会人{participants} ## 背景 ## 讨论要点 ## 决议 ## 待办 | 待办内容 | 负责人 | 截止时间 | 优先级 | | --- | --- | --- | --- |模板的价值是固定输出结构。没有模板时模型每次生成的格式都可能不一样人工汇总反而更累。3.4 验证一个 Skill 是否可用验证不能只看“模型能回答”要看模型是否能完整走完整个技能流程。最直接的方式是先脚本级验证。python scripts/archive_meeting.py \ --content # 测试会议 \ --date 2025-07-01 \ --output-dir /tmp/meeting-test预期结果是终端输出“已写入: /tmp/meeting-test/2025-07-01.md”。然后再做一个端到端验证输入一段模拟会议转写观察模型是否正确加载SKILL.md是否按模板生成是否调用了归档脚本输出文件是否出现在目标目录。不要只验证程序能启动还要验证输入、输出、异常分支和日志是否符合预期。4. 在不同研发环境里接入 skills4.1 常见运行时的接入方式不同 AI 编程工具的 skills 接入方式不完全一样。下面是一个常见参考落地前要以实际版本说明为准。运行时常见接入方式使用入口Claude Code项目.claude/skills/name/SKILL.md或用户级~/.claude/skillsAgent 对话中自然触发CodexCodex 支持的配置目录中放置 Skill 目录CLI 或 IDE 会话中自动加载Cursor项目.cursor/skills或 Agent 自定义指令区域Agent 对话中按描述触发OpenCode配置目录下的 skills 目录命令行 Agent 会话VSCode CodeBuddy将技能目录作为 Agent 技能配置配合 Playwright 等工具编辑器 Agent 面板安装前先确认两个问题当前版本是否支持目录式 Skilldescription是否会被 agent 索引。如果索引不到Skill 写得再好也不会被加载。4.2 前端、测试和后端落地示例前端团队可以做一个“前端开发 Skill”里面包含团队使用的组件库文档链接、样式规范、代码规范、示例组件。Agent 在收到“实现一个列表页”这类请求时先读 Skill再动手而不是凭训练数据里的通用写法输出。测试团队可以把 Playwright、CodeBuddy 和 VSCode 结合做一个“端到端测试 Skill”。技能里写上测试环境地址需要覆盖的关键路径断言模板脚本运行方式后端团队做 Spring Boot 3 项目时可以把“标准项目生成”做成 Skill里面记录包结构、依赖版本、统一返回体、异常处理类的生成规则。这类 Skill 真正解决的不是“模型不会写代码”而是“模型不知道团队习惯怎么写代码”。4.3 团队技能库怎么组织技能分散在员工本机没有意义团队需要有一个集中来源。可以是一个 Git 仓库目录按业务域组织skills-hub/ ├── README.md ├── meeting/ │ └── meeting-minutes/ ├── frontend/ │ └── react-component-generator/ ├── testing/ │ └── playwright-e2e/ └── java/ └── springboot3-project-generator/也可以是内部服务器上的一个静态页面展示每个 Skill 的名称、适用场景、维护人、版本和安装命令。重点是让员工知道“有这个技能”而不是每次靠别人口头推荐。5. 企业化运营评估、版本、权限和 Java 后端接入5.1 入库前先评估六个问题不是所有提示词都值得做成公司级 Skill。入库前可以先用下面六个问题过滤。场景是否高频至少每周出现一次才值得维护。是否有明确输入输出如果任务本身模糊Skill 也很难稳定。是否可验证能否用一组样例输入和预期输出做回归测试。是否有业务风险涉及写库、发消息、操作生产环境的必须设权限。是否有维护人没有维护人的 Skill 三个月后会变成僵尸技能。是否已有更好的工具如果 MCP 工具或插件已经能完成不需要重复包装。这六条总结成一句Skill 要解决的问题必须是“高频、结构化、可验证、有维护责任”的。5.2 版本管理和灰度发布技能也会迭代。模板改了、脚本 bug 修了、规则变了都需要有新版本。企业内部可以用一个 manifest 文件记录基本信息下面是一个示意apiVersion: skills.example.com/v1 kind: EmployeeSkill metadata: name: meeting-minutes version: 1.2.0 owner: platform-team spec: triggers: - 会议纪要 - 转写稿整理 runtime: claude-code files: - SKILL.md - resources/**/* - scripts/**/* approval: required这不是行业标准只是一种团队内部约定。关键作用是让版本、维护人和文件范围变得可追溯。发布流程建议按顺序走开发者在分支上修改 Skill。用示例输入跑一遍记录输出 diff。提交 PR由至少一位同事 review 脚本和规则。先发给 5 到 10 个试点员工使用。试点正常后全量发布。如果出现严重问题回滚到上一个稳定版本。5.3 安全与权限边界企业做员工 Skills 时必须把安全放在前面。Skill 里的脚本可以读写文件、执行命令、请求网络如果设计不当等同于给所有员工发了一个可执行脚本分发工具。最低要求包括技能仓库不存放任何密钥和令牌。脚本必须经过代码 review。运行时按最小权限配置不允许 Skill 随意执行危险命令。对敏感信息做脱敏处理SKILL.md 里的示例不要贴真实业务数据。记录每个 Skill 的调用时间和结果便于审计。这里的安全边界是一条基本原则AI Agent 的权限不能超过员工本人在业务系统里的权限。5.4 Java 后端自建 Spring AI 时的轻量接入如果公司用 Spring AI Alibaba 或 Spring AI 自建 Agent不一定需要完全复刻 Claude Code 的目录机制。可以做一个简单实现把 SKILL.md 当作提示词模板加载再配合工具调用。String skillText skillLoader.load(meeting-minutes); String prompt skillText .replace({{input}}, transcript) .replace({{template}}, templateContent); LoggingAiMessage message assistant.chat(prompt);核心不是框架叫什么而是是否支持“根据任务选择技能内容”。只要模型能按路径读取技能包再组合工具调用就已经具备员工 Skill 的雏形。6. 常见问题和排查链路6.1 Skills 不生效的常见原因下面的表格汇总了实际项目里最常见的几类问题。问题现象常见原因检查方式处理建议Agent 对话中完全不使用 Skilldescription触发词不匹配查看 Skill 是否被列出检查描述重写描述明确使用场景和用户习惯措辞安装后提示找不到 Skill目录路径错误或 front matter 缺少name检查配置目录确认文件层级按运行时的规则调整目录结构和文件命名Skill 有说明但模型不按步骤执行步骤太长或顺序不清晰阅读 SKILL.md看是否是堆砌文字改成编号步骤增加“必须执行”清单脚本执行失败权限、路径、依赖缺失在终端手动运行脚本看报错修复脚本补充异常输出输出格式仍然不稳定只写规则没给模板和示例查看 resources 和 examples 是否存在补充模板和正反面示例技能被误加载description 没有写“何时不要用”检查触发场景在描述中增加排除条件6.2 从现象倒推问题的排查顺序遇到 Skill 不生效建议按这个顺序查避免一开始就改提示词。先确认 Skill 是否已经安装到正确目录。再确认description和用户请求的关键词是否能对上。然后手动执行 Skill 里的脚本排除脚本本身的问题。接着检查是否有allowed-tools或权限配置限制了模型调用脚本。再看日志里是否记录了 Skill 被加载加载的是哪个版本。最后才判断是规则写得不清楚还是模型能力不足。排查时最好准备一组固定的测试输入。没有测试输入就没法区分“Skill 本身坏了”和“这次会话中的问题”。6.3 模型自由发挥过度怎么办Skill 的规则再详细模型也可能在输出时加入自己的偏好。解决办法是尽量把主观判断变成可选列表。比如不要写“格式要简洁”而要写“每个待办项只保留一行不超过 50 字”。再比如不要写“按公司规范生成”而要在 resources 里放一个真实的规范片段。技能包装得越具体模型的自由发挥空间就越小输出也会越稳定。7. 员工 skills 的编写规范和推广建议7.1 编写 Skill 的十条可落地规范每个 Skill 只解决一个场景不要做成大而全的综合指令。description必须写清楚“什么时候用”和“什么时候不用”。步骤用编号不要只用连续段落。模板放进 resources不要只写在说明里。能用脚本完成的固定动作不要让模型临时生成代码。示例输入和示例输出放进 examples便于回归测试。明确禁止行为例如“不要覆盖已有文件”“不要编造来源”。记录维护人和版本号避免成了无主技能。不存放密钥、令牌和真实业务敏感数据。每个 Skill 至少有一组测试输入和期望输出。这十条可以直接作为团队内部代码评审的检查清单。7.2 试点推广的节奏刚开始不要追求技能数量。一个平台团队能维护好 10 个真正好用的 Skill比拥有 100 个没人看的 Skill 更有价值。推荐节奏是第一周选一个高频低风险场景比如会议纪要。第二周由 5 到 10 个员工试用重点收集输出格式和误触发问题。第三周根据反馈迭代第二版补齐模板和脚本。第四周全量发布同时启动下一个 Skill 的编写。推广时不要只发命令要给员工一份“怎么发现 Skill”的说明例如在内部站维护一个列表按“会议、研发、测试、运维、文档”分类。7.3 一个值得长期坚持的技术判断员工 skills 的本质是把个人使用 AI 的经验变成组织可以继承和评估的资产。它既不是做一个问答机器人也不是让每个部门写一堆提示词。真正有价值的问题是团队里哪些任务的结果是“可以标准化”的以及我们能不能把标准变成 AI 可执行的步骤。如果你的团队还没有开始做员工 skills最值得做的不是搭建一个庞大的技能市场而是先选择一个高频、低风险、结果可验证的场景找几个人试点把第一个 Skill 从编写、安装、使用到复盘完整跑一遍。这个闭环跑通之后再谈标准、权限和平台。