企业官网建设流程全解析

员工 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 负责“具体动作谁来做”。

在员工技能的语境下，最重要的资产不是某一条写得很好的提示词，而是把提示词、规则、脚本、模板做成一个可维护、可评估、可灰度的 Skill 包。

1.2 公司为什么开始把它当作“员工技能”来管理

公司做员工 skills，本质上是在做知识管理，只不过知识不再是文档，而是“能被 AI 执行的操作手册”。

有几个推动因素很现实：

• 高频场景需要稳定输出。会议纪要、周报、测试用例、PPT 初稿、代码 review 这类任务重复度高，但不同人的输出格式差异大。
• 新人上手成本高。新人不知道公司的文档模板、代码规范、发布流程，Skill 可以把这些隐性知识直接放进 AI 工作流。
• 提示词容易失传。员工离职后，个人积累的提示词和脚本很难移交；Skill 进入 Git 仓库后，知识归属从个人变成组织。
• 结果可度量。Skill 可以记录版本、执行次数、成功率和人工修正率，比“某员工 AI 用得不错”更可量化。

这里要注意，员工 Skills 不是让 AI 替员工做判断，而是让 AI 承担可标准化的步骤，员工把精力放在确认、决策和异常处理上。

1.3 典型使用场景

不同岗位适合先做的 Skill 不一样。

这些场景的共同点是：有明确输入、有稳定输出结构、有可检查的中间产物。这样的任务最适合先做成 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.md

resources放模板和参考资料，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-minutes

npx skills是什么，简单说就是一个命令行入口，用来安装、列出和更新本地技能包。具体命令名都由团队封装决定，不一定所有环境都叫skills，但思路一致：把技能包从仓库分发到员工本机。

注意：不要直接把从网上下载的 Skill 解压到生产环境。目录里的脚本会以当前用户权限执行，必须先检查脚本内容、依赖和网络请求。

3. 实现一个可用的员工技能：会议纪要归档

3.1 需求拆解

先明确输入输出。输入是会议转写文本，输出是一份符合团队模板的 Markdown 会议纪要，并且自动归档到指定目录。

拆解后的步骤是：

1. 读取转写文本。
2. 识别会议主题、参会人和时间。
3. 整理讨论要点、决议、待办项。
4. 如果原始文本中有“负责人：张三，截止：周五”这样的表达，提取成结构化待办。
5. 按模板生成 Markdown 文件。
6. 写入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", required=True, help="会议纪要 Markdown 内容") parser.add_argument("--date", default=date.today().isoformat(), help="会议日期 YYYY-MM-DD") parser.add_argument("--output-dir", default="docs/meeting-minutes", help="归档目录") args = parser.parse_args() output_dir = pathlib.Path(args.output_dir) output_dir.mkdir(parents=True, exist_ok=True) output_path = output_dir / f"{args.date}.md" if output_path.exists(): raise SystemExit(f"文件已存在: {output_path}") output_path.write_text(args.content, encoding="utf-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. 在不同研发环境里接入 skills

4.1 常见运行时的接入方式

不同 AI 编程工具的 skills 接入方式不完全一样。下面是一个常见参考，落地前要以实际版本说明为准。

安装前先确认两个问题：当前版本是否支持目录式 Skill；description是否会被 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

这不是行业标准，只是一种团队内部约定。关键作用是让版本、维护人和文件范围变得可追溯。

发布流程建议按顺序走：

1. 开发者在分支上修改 Skill。
2. 用示例输入跑一遍，记录输出 diff。
3. 提交 PR，由至少一位同事 review 脚本和规则。
4. 先发给 5 到 10 个试点员工使用。
5. 试点正常后全量发布。
6. 如果出现严重问题，回滚到上一个稳定版本。

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 不生效的常见原因

下面的表格汇总了实际项目里最常见的几类问题。

6.2 从现象倒推问题的排查顺序

遇到 Skill 不生效，建议按这个顺序查，避免一开始就改提示词。

1. 先确认 Skill 是否已经安装到正确目录。
2. 再确认description和用户请求的关键词是否能对上。
3. 然后手动执行 Skill 里的脚本，排除脚本本身的问题。
4. 接着检查是否有allowed-tools或权限配置限制了模型调用脚本。
5. 再看日志里是否记录了 Skill 被加载，加载的是哪个版本。
6. 最后才判断是规则写得不清楚还是模型能力不足。

排查时最好准备一组固定的测试输入。没有测试输入，就没法区分“Skill 本身坏了”和“这次会话中的问题”。

6.3 模型自由发挥过度怎么办

Skill 的规则再详细，模型也可能在输出时加入自己的偏好。解决办法是尽量把主观判断变成可选列表。

比如不要写“格式要简洁”，而要写“每个待办项只保留一行，不超过 50 字”。

再比如不要写“按公司规范生成”，而要在 resources 里放一个真实的规范片段。

技能包装得越具体，模型的自由发挥空间就越小，输出也会越稳定。

7. 员工 skills 的编写规范和推广建议

7.1 编写 Skill 的十条可落地规范

• 每个 Skill 只解决一个场景，不要做成大而全的综合指令。
• description必须写清楚“什么时候用”和“什么时候不用”。
• 步骤用编号，不要只用连续段落。
• 模板放进 resources，不要只写在说明里。
• 能用脚本完成的固定动作，不要让模型临时生成代码。
• 示例输入和示例输出放进 examples，便于回归测试。
• 明确禁止行为，例如“不要覆盖已有文件”“不要编造来源”。
• 记录维护人和版本号，避免成了无主技能。
• 不存放密钥、令牌和真实业务敏感数据。
• 每个 Skill 至少有一组测试输入和期望输出。

这十条可以直接作为团队内部代码评审的检查清单。

7.2 试点推广的节奏

刚开始不要追求技能数量。一个平台团队能维护好 10 个真正好用的 Skill，比拥有 100 个没人看的 Skill 更有价值。

推荐节奏是：

1. 第一周：选一个高频低风险场景，比如会议纪要。
2. 第二周：由 5 到 10 个员工试用，重点收集输出格式和误触发问题。
3. 第三周：根据反馈迭代第二版，补齐模板和脚本。
4. 第四周：全量发布，同时启动下一个 Skill 的编写。

推广时不要只发命令，要给员工一份“怎么发现 Skill”的说明，例如在内部站维护一个列表，按“会议、研发、测试、运维、文档”分类。

7.3 一个值得长期坚持的技术判断

员工 skills 的本质，是把个人使用 AI 的经验，变成组织可以继承和评估的资产。

它既不是做一个问答机器人，也不是让每个部门写一堆提示词。真正有价值的问题是：团队里哪些任务的结果是“可以标准化”的，以及我们能不能把标准变成 AI 可执行的步骤。

如果你的团队还没有开始做员工 skills，最值得做的不是搭建一个庞大的技能市场，而是先选择一个高频、低风险、结果可验证的场景，找几个人试点，把第一个 Skill 从编写、安装、使用到复盘完整跑一遍。这个闭环跑通之后，再谈标准、权限和平台。