企业官网建设流程全解析

这两年，AI 编程助手从“能用”进化到“好用”，最近又有一个新词在技术圈里被越来越多地提起：员工 skills。你可能会好奇，这不就是给 AI 配技能包吗？个人玩玩可以，怎么还有公司大规模给员工做 skills？还专门开会讨论怎么沉淀、怎么分发、怎么考核？

这个趋势背后，其实是企业 AI 落地从“工具使用”向“能力资产沉淀”的一次拐点。

如果你的团队还停留在“谁会用 AI 谁就多干点”的阶段，那么这篇文章值得认真读完。我会从企业为什么开始认真做员工 skills 讲起，然后解释它和普通提示词、Agent 的区别，再给出一套可以直接落地的 skills 编写规范、归档方式、分发流程和治理建议。文章最后会附上常见问题排查表，方便你直接对照使用。

1. 这篇文章真正要解决的问题

先说结论：公司级 skills 的本质，是把“个人怎么用 AI”变成“团队怎么用 AI”，再把“团队怎么用 AI”变成“组织可复用的资产”。

过去一年里，大部分公司遇到的真实问题是这样的：

• 某同事用 AI 写代码特别快，但他离职后，大家发现他那些“特别灵”的套路别人根本学不会。
• 某个部门积累了很规范的运维检查清单，但每次都是靠老员工口口相传，新员工上手依然慢。
• 客服团队整理了一套标准话术，但每次都是复制粘贴到聊天框里，质量和效率都不稳定。
• 测试团队有一些非常可靠的测试用例生成方法，但换一个人操作，结果就完全不一样。

这些问题的共同点是：个人的 AI 使用经验是碎片化的，没有变成团队可共享、可复用、可迭代的标准能力。

所以，当一些公司提出“给员工做 skills”的时候，它们真正在做的，是把隐性的经验显性化，把显性的经验标准化，把标准化的经验工具化。这件事的意义，比“提升生成代码速度”大得多。

什么样的人最该读这篇文章？我认为有三类：

1. 技术负责人和 AI 落地推动者，你需要判断公司要不要投入做 skills 体系。
2. 一线研发、测试、运维工程师，你可能是负责编写团队第一个 skills 的人。
3. 对 Agent、AI 工程化感兴趣的开发者，你需要理解 skills 在整套 AI 工具链里的定位。

这篇文章要解决的问题，不是“skills 的 API 怎么调用”这种单一技术问题，而是：当公司准备把 skills 作为员工能力来建设时，技术侧要怎么做才靠谱。

2. AI Skills 的核心概念与适用场景

2.1 什么是 AI Skills

AI Skills 可以简单理解成：给 AI Agent 或 AI 编程助手准备的一套“专业技能包”。

它通常包含三个部分：

• 技能描述：告诉 AI 这个技能是干什么用的，什么时候应该调用。
• 操作流程：告诉 AI 按什么步骤执行，每一步要注意什么。
• 示例与规范：给 AI 参考输入输出，让它输出的结果符合团队期望。

你可以把它理解为“AI 世界的 SOP（标准作业程序）”。传统 SOP 是给人看的，员工 skills 是给 AI 看、又由人来维护的。

2.2 AI Skills 与 Prompt 的区别

很多人一开始会把 Skills 误认为“高级一点的提示词”，这其实是个误区。

普通 Prompt 是一次性输入给模型的话术，它随用随写，没有结构，不好维护，换个人写质量就完全靠个人水平。

而 Skills 是结构化的技能定义，它独立于具体对话存在，可以被检索、加载、复用、更新、版本管理。

举个例子：

普通 Prompt 可能是这样的：“你帮我把这段需求描述拆成开发任务，注意要写清楚技术方案和验收标准。”

Skills 则是一个有明确元信息的技能包，AI 会在合适场景下自动识别并加载使用。

2.3 AI Skills 与 Agent 的区别

这是我在社区里看到最多的困惑之一。不少人问：skills 和 agent 到底是什么关系？

Agent 是一个能够自主规划和执行任务的智能体，它负责理解目标、拆解步骤、选择工具、调用能力。

Skills 是Agent 可以调用的能力模块，它告诉 Agent “某类任务应该怎么做更专业”。

可以打个比方：Agent 是一个新入职的实习生，Skills 是公司给这个实习生准备的岗位操作手册和工具箱。没有 Skills 的 Agent 也能工作，但效率和规范性全看运气；有了高质量的 Skills，Agent 才能稳定输出符合团队标准的成果。

在 Claude Code、Codex、Cursor、OpenCode 等主流工具中，Skills 的加载方式各不相同，但核心思路是一致的：先定义能力边界，再在具体任务中按需调用。

2.4 适合做员工 Skills 的场景

不是所有公司都适合一上来就大规模做 skills。从目前社区和企业实践来看，适合落地的场景有这些共同特征：

• 高频重复：任务每周都会发生，且流程相对固定。
• 有明确标准：输出物可以量化验收，比如代码格式、测试覆盖率、文档结构。
• 专家经验依赖强：做得好不好，很大程度取决于老手的经验。
• 协作链路长：需要多个环节配合，AI 介入后能显著减少交接成本。

典型的例子包括：前端代码审查、后端接口联调、测试用例设计、运维故障排查、PPT 生成、文档撰写、客服话术生成、学术论文格式校对等。

3. 公司级 Skills 的典型形态与落地路径

3.1 从个人 Skills 到公司级 Skills

个人 skills 通常是自己写给自己用，可以不讲究规范，但公司级 skills 完全不同，它必须考虑复用、维护、安全和迭代。

公司级 skills 的典型形态通常分三层：

这里真正容易踩坑的地方在于：很多人一开始就想做公司级技能库，结果发现没人维护、没人更新、没人用。更稳妥的判断是从这个团队最痛的场景切入，而不是一开始就追求大而全。

3.2 企业建设 Skills 的四个阶段

从社区和招聘信息中透露出来的企业实践来看，公司建设员工 skills 通常经历以下四个阶段：

阶段一：个人探索期。少数工程师自己写 skills，自己用，还没有团队规范。这个阶段的核心目标，是验证场景是否适合 AI 介入。

阶段二：团队标准化。技术负责人收集个人 skills，挑选有价值的，统一格式和命名规范，放进团队共享目录。同时整理一套“编写 skills 的 skills”，也就是元技能。

阶段三：平台化分发。平台团队搭建内部技能市场或技能中心，支持检索、安装、版本更新、权限控制。这时候，skills 已经更像一个内部开源项目。

阶段四：能力运营化。把 skills 的编写和更新纳入员工的日常工作，类似提交代码一样提交技能改进，并有相应的评估和激励机制。

多数公司现在处于第一、第二阶段，能走到第四阶段的还很少。这也意味着，如果你能率先把团队某个高频场景做成高质量 skills，你的经验会非常有价值。

3.3 技术选型：用什么工具承载 Skills

承载 skills 的工具链选择，需要和团队现有 AI 工具对齐。

目前主流方案有以下几类：

• 基于 Claude Code / Codex / Cursor 等 AI 编程工具：这类工具对 skills 的支持比较原生，可以直接在项目配置目录中定义。
• 基于通用 Agent 框架：比如可以自定义技能加载逻辑的 Agent 平台。
• 基于企业内部知识库系统：把 skills 当作知识库的一种结构化文档，通过 MCP 等协议接入 AI 工具。
• 自建技能仓库：大公司通常会自建内部技能中心，支持 skills 的上传、审核、分发、统计。

在选型时，不要只看当前热不热，更要看团队已经习惯用哪个工具，以及这个工具的 skills 生态是否活跃。毕竟，工具迁移成本往往比技能编写成本高得多。

4. 编写公司级 Skills 的环境准备与目录规范

这一节开始进入实操。假设你的团队已经决定尝试做第一个员工 skills，下面是一套可以直接参考的目录结构和编写规范。

4.1 基础目录结构

我推荐使用按“类型/场景/技能名”分类的方式，而不是把所有 skills 堆在一个目录里。这样后续复杂度上来时，检索和权限控制都更好做。

company-skills/ ├── README.md # 技能库总说明 ├── skills/ │ ├── frontend/ │ │ ├── fe-code-review/ # 前端代码审查技能 │ │ │ ├── SKILL.md # 技能定义主文件 │ │ │ ├── reference/ # 参考资料 │ │ │ │ ├── review-checklist.md │ │ │ │ └── team-standards.md │ │ │ └── examples/ │ │ │ ├── bad-review.md │ │ │ └── good-review.md │ ├── testing/ │ │ └── test-case-gen/ # 测试用例生成技能 │ └── docs/ │ └── meeting-notes/ # 会议纪要技能 └── templates/ └── skill-template.md # 新 Skill 模板

这只是一个示意结构，具体字段和路径可以按团队习惯调整。关键是保证三个特性：可检索、可维护、可扩展。

4.2 元信息规范

每个 skills 都应该包含明确的元信息。下面是一个通用的骨架示例：

name: fe-code-review description: 前端代码审查技能，适用于 React/Vue 项目的 MR 审查 version: 1.0.0 author: frontend-team tags: - frontend - code-review - react - vue trigger: - "审查前端代码" - "检查 MR 中的样式问题" - "review 组件代码" dependencies: - nodejs >= 18.0.0 - typescript >= 5.0.0

这里需要特别提醒的是 description 和 trigger 这两个字段。它们决定了 AI 在什么情况下会自动加载这个技能。

写得模糊，AI 就抓不到；写得过于具体，又会把场景限制死。一个经验法则是：用团队实际会说的话来描述触发条件，而不是用官方文档风格。

4.3 Skill 主文件的结构

Skill 主文件，通常叫 SKILL.md 或类似名字，建议包含以下章节：

• Overview：一句话说明这个技能解决什么问题。
• When to Use：什么场景用，什么场景不用。
• Workflow：具体的执行步骤，越具体越好。
• Rules：必须遵守的规则，如禁止使用某些 API、必须输出测试用例等。
• Examples：一个完整的输入输出示例。
• References：参考资料，可以是团队规范文档的索引。

下文会用一套完整的“前端代码审查”示例来展示这种结构。

5. 完整示例：一套可直接上手的前端代码审查 Skills

为了让这套方法论落地，我来演示一个最小可用版本。这个技能解决的具体痛点是：团队里代码审查质量不一致，有的成员只看逻辑，不看样式规范，不看性能隐患，不看可访问性。

这个技能其实可以写成任何语言，这里使用 Markdown 加 YAML 元信息的方式，主流 AI 工具基本可以直接采用或做少量字段适配。

5.1 文件一：SKILL.md

--- name: frontend-code-review description: 前端代码审查技能。用于审查 React/Vue/小程序等前端 MR，关注正确性、性能、可访问性与团队规范。 version: 1.1.0 tags: [frontend, code-review, performance, a11y] trigger: - "审查前端代码" - "review 这个 MR" - "帮我检查一下这段组件代码" --- # Frontend Code Review Skill ## Overview 按团队统一标准审查前端代码，输出结构化审查意见。 ## When to Use - 提交 MR 前进行自审 - 评审他人的前端 MR - 识别代码中的性能隐患和可访问性问题 ## Workflow ### Step 1: 了解变更范围 - 检查 MR 描述，确定涉及的功能模块。 - 如果有疑问，优先向提交者确认需求和背景。 ### Step 2: 按维度审查 按以下顺序逐项检查： 1. **正确性** - 状态更新是否同步，有无竞态条件 - 异步请求是否有异常处理 - 边界情况是否覆盖 2. **性能** - 是否存在不必要的重渲染 - 列表是否缺少稳定的 key - 是否在循环中执行高开销计算 3. **可访问性** - 按钮和链接是否有可理解的文本 - 表单是否有 label - 交互是否支持键盘操作 4. **规范一致性** - 是否符合团队 ESLint/Prettier 配置 - 组件命名是否清晰 - 样式是否按模块约束组织 ### Step 3: 输出审查意见 格式如下： - 严重程度: [严重/一般/建议] - 位置: 文件:行号 - 问题: 具体描述 - 原因: 为什么这是问题 - 建议: 如何修改 ## Rules - 不修改代码，只输出审查意见。 - 如果问题不存在，不要强行提出。 - 对拿不准的建议，标注为“待确认”。 - 每个问题必须给出修改建议，不能只报问题。 ## Examples ### 用户输入 请审查这个组件： ```tsx function ItemList({ items }) { return ( <div> {items.map((item) => ( <div key={item.id}>{item.name}</div> ))} </div> ); }

期望输出

• 严重程度: 建议
• 位置: src/components/ItemList.tsx:4
• 问题: 列表项使用 div 包裹，可访问性不佳；缺少可读的语义标签。
• 原因: 使用无序列表 ul/li 可以更好支持屏幕阅读器。
• 建议: 将外层 div 替换为 ul，列表项替换为 li，保证每个 li 有 key 且内容清晰。

### 5.2 文件二：reference/review-checklist.md 这个文件是审查时使用的检查清单，独立成文件是为了方便后续单独更新： ```markdown # 前端审查清单 ## 通用 - [ ] 没有硬编码敏感信息 - [ ] 没有 console.log 遗留 - [ ] 类型定义完整，没有 any 滥用 ## React 专项 - [ ] 状态提升是否合理 - [ ] useEffect 依赖数组是否完整 - [ ] 列表 key 是否稳定 ## Vue 专项 - [ ] computed 和 watch 使用是否恰当 - [ ] v-for 的 key 是否稳定 - [ ] 组件 props 类型是否定义 ## 样式 - [ ] 没有内联样式硬编码颜色 - [ ] 没有过度嵌套选择器 - [ ] 布局是否适配移动端 ## 可访问性 - [ ] 图片有 alt - [ ] 交互元素可聚焦 - [ ] 颜色对比度符合 WCAG AA

5.3 如何在 Claude Code / Cursor 等工具中接入

不同工具的 skills 加载机制不一样，但思路是相通的：把 skill 目录配置到 AI 工具的技能目录中。

以类 Claude Code 结构为例，你的配置文件可能长这样：

{ "skills": { "enabled": true, "paths": [ "~/.claude/skills", "./.skills", "../company-skills/skills" ] } }

放到团队项目里时，我建议项目根目录放一个.skills文件夹，把团队级技能放进去，这样提交代码时技能会跟着项目走，新成员 clone 下来就能直接用，不需要额外安装。

需要注意的是，各工具的具体配置字段可能不同，第一次配置时看对应工具的官方文档即可，核心逻辑是一样的。

5.4 如何用代码命令验证

验证 skills 是否被 AI 正确加载，有一个简单方法：直接输入 trigger 里的短语，看 AI 是否采取了你定义的 Workflow。

# 进入项目目录 cd your-project # 在 AI 工具对话窗口输入： 审查这个 MR 中的前端代码变更

如果 AI 输出的格式与你定义的严重程度-位置-问题-原因-建议结构一致，说明技能生效。如果 AI 还是在自由发挥，优先检查路径配置。

6. 从“会写 Skills”到“能运维 Skills”

写完第一个 skills 只是开始。真正决定一个公司 skills 体系能否持续运转的，是后续的维护和治理能力。以下是我认为企业推进 skills 时最需要关注的技术问题。

6.1 版本更新与兼容

Skills 和项目代码一样，会面临迭代：团队规范变了，Skill 要跟着改；某个步骤写得不好，要优化；某个触发词不生效，要调整。

推荐做法：

• 为每个 skills 配置version字段。
• 变更时更新版本号，并简要记录变更内容。
• 定期评审过时技能，考虑下架或重写。

6.2 权限与安全边界

这里有一个很现实的风险：如果员工可以随意往公司级技能库提交内容，恶意代码或者不合规的生成策略可能通过技能分发到全公司。

建议设置分级审核：

• 个人级技能：完全自由，只影响自己。
• 团队级技能：需要在团队内做评审，至少负责人确认。
• 公司级技能：必须经过平台团队审核，关注内容是否合规、是否有安全风险、是否占用过多上下文。

涉及生成代码的场景，还应该规定：禁止技能中自动执行高权限命令，必须保留人工确认环节。

6.3 效果评估机制

怎么评价一个技能写得好不好？我建议包含以下维度：

如果你想做更细致的评估，可以给每个技能设置一个“评估提示词”，要求 AI 在输出后给出一段自我评估，包括是否按照工作流、是否遗漏了规则、还有哪些可以优化。这其实就是用 AI 来评估 skills 的质量。

7. 常见问题与排查思路

在社区里看到大家讨论最多的问题，我整理成了下面这个排查表：

这里特别强调一个点：大多数 skills 不生效的问题，不是模型能力不够，而是目录路径配置错了。排查时先看路径，再看触发词，最后才怀疑模型。

8. 最佳实践与工程建议

8.1 从三个“高频高痛”场景切入

与其一口气做 20 个技能，不如先把 3 个场景做透。推荐优先考虑这三个方向：

• 代码审查：复用度高，质量验收标准明确。
• 测试用例生成：对规范型团队影响大，能显著提升测试覆盖率。
• 技术文档生成：上手简单，能快速让团队感受到 AI 提效。

8.2 给技能编写团队建立“元技能”

所谓元技能，就是“如何编写好技能”的技能。团队可以积累一个通用的 skill 模板，包含章节、示例、描述规范。新成员编写第一个技能时，可以直接套用模板，学习成本会大幅降低。

8.3 为每个技能建立反馈回路

每次技能被调用后，应该鼓励使用者留下反馈。具体做法可以很简单：在技能文件中加一个“反馈记录”章节，AI 会根据使用情况自动整理问题，维护者定期复盘。这比等用户主动提意见要高效得多。

8.4 安全与合规底线

这一块必须强调：在加入公司级技能库前，所有技能都应该经过安全审查，特别关注：

• 是否包含自动执行命令。
• 是否会将内部敏感信息发送到外部服务。
• 是否包含不合规的生成建议。

生产环境变更、数据库操作、权限提升等场景，技能默认必须保留人工审批环节。最小权限原则在这里同样适用。

9. 总结与后续学习方向

现在回到开头的问题：为什么有些公司开始给员工做 skills？

说到底，是因为 AI Agent 的能力越来越强，但“AI 会不会用、用得好不好”的差距正在成为团队生产效率的鸿沟。单纯靠提示词工程已经不足以支撑大规模协作，企业需要把优秀员工的使用经验沉淀成标准化的技能包，让所有人在 AI 帮助下都能达到一个稳定的水准线。

这篇文章讲清楚了几个关键点：

• Skills 不是高级提示词，而是结构化的技能定义，和 Agent 是互补关系。
• 公司级 skills 建设的核心难点不是编写，而是目录管理、版本迭代、权限治理和效果评估。
• 最小可用切入方式是选一个高频高痛场景，写成带元信息的主文件加参考资料，然后配置到团队的 AI 工具中。
• 一套好的 skill 要有清晰的触发条件、可执行的工作流、明确的规则和参考示例。

如果你准备在团队里推动这件事，我的建议很简单：不要先搭平台，先写一个能解决真实痛点的技能，让两三个同事用起来。

下一步可以深入研究的方向有三个：一是主流 AI 编程工具的 skills 格式差异与通用方案；二是如何通过 MCP 协议把内部技能中心和安全工具接起来；三是如何基于团队真实使用数据建立 skills 评估指标体系。

如果你也在做公司级 skills，欢迎在评论区分享你们踩过的坑。建议先收藏这篇文章，等真正开始写第一个技能时再对照着操作。