企业官网建设流程全解析

第一次接触 Claude Skills 这个概念时，我把它理解成：给 Claude 写一张“上岗证”。后来用得多了，才意识到它远不止一份说明文档——它是一整套把个人经验、业务规则和工具用法打包起来，让模型在合适的时刻自动调用的机制。如果你是做 AI 应用开发的，或者经常用 Claude 处理重复性任务，非常值得花半小时搞清楚这套体系。这篇文章不准备讲太多上层包装，直接把核心概念掰开说清楚，包括它解决什么问题、怎么工作、和 Tools 与 MCP 的区别，以及一个能直接照抄的最小实现。

1. 先搞清楚：Claude Skills 到底解决什么问题

1.1 长提示词为什么撑不住

很多朋友最初看到 Skills 这个词，会默认它和插件是同一个东西。我自己第一周也是这么以为的。直到我实际做了几个 Skill 并让 Claude 在真实对话里使用之后，才意识到它的设计思路和插件完全不一样。插件是“用户手动安装、模型按需调用”，而 Skill 更像是“模型自己在对话中判断是否需要学习一套新方法”。

在很长一段时间里，想让 Claude 完成稍微复杂的任务，最常见的方式是写一条超长系统提示词。举个例子，假设你想做一个“项目数据分析助手”：需要规定它先读取数据文件，再按指定规则清洗缺失值，接着用统计工具做计算，最后按公司模板生成分析报告。这些内容全部拼在一起，经常超过一两千字。实际跑起来你会发现，Claude 在对话早期还能严格遵守，一旦任务步骤变多，后面那些规则很容易被忽略。原因倒不是模型变笨，而是上下文中的指令太多太杂，模型需要同时处理用户请求、历史消息和整段规则，注意力被稀释了。更麻烦的是，你很难单独修改其中某一部分——每次微调都要把整段提示词重新复制一遍，换一个任务场景又得另起炉灶。

长提示词还有一个隐藏问题：每一次对话都要把这些规则全部加载进上下文，哪怕这次根本用不到其中八成内容。这在 token 成本上很浪费，也会让模型对真正重要的指令变得不敏感。你会发现，在同一个系统提示词里加的功能越多，模型的表现就越不稳定。Claude Skills 很大程度就是为了缓解这个问题而设计的。

1.2 从“一次性指令”到“可复用能力包”

Skills 的思路，是把原本堆在提示词里的“任务处理知识”——包括判断条件、操作步骤、工具用法、输出格式、注意事项——拆成一个独立单元。这个单元平时不占用上下文，只有当用户请求涉及到它的适用场景时，模型才会把这个单元加载进来，当作执行任务的操作手册。这样既避免了一次性塞入太多指令，又让每部分规则可以单独维护、测试和共享。

我拿一个生活中的例子来类比。新员工入职时，公司不会让他把整套员工手册背下来，而是先做基础培训，再告诉他“遇到报销问题去翻第 5 章，遇到数据导出问题去翻第 8 章”。员工只有在具体任务发生时才会查阅相关章节，读完后按步骤执行。Claude Skills 就相当于这些“章节”，它把特定场景的最佳实践沉淀下来，让模型在需要时按图索骥。和一次性提示词相比，几个优势非常明显：

• 按需加载：不用的 Skill 不占上下文，有效降低 token 消耗；
• 独立迭代：每个 Skill 可以单独改版，不会牵一发动全身；
• 团队共享：一份写好的 Skill 可以放到公共目录，大家共同复用；
• 组合使用：遇到复杂任务时，模型可以串行调用多个 Skill，分别处理不同环节。

1.3 谁应该关注这套机制

如果你属于下面这几类人，我建议认真了解一下 Claude Skills：

• 经常用 Claude 处理重复任务的效率爱好者，比如固定格式的会议纪要、周报、代码审查；
• 正在做 AI 应用或自动化流程的开发者，需要让模型稳定执行一套业务规则；
• 负责提示词工程或智能体编排的技术人员，想找到比长提示词更可控的方案。

当然，如果只是偶尔让 Claude 写个文案，不一定会用到 Skills 这种结构，但理解它的核心概念后，你会更清楚模型在什么情况下需要“外部知识注入”，这对后续设计 Agent 应用也有帮助。

2. 拆开看：Skill 的结构、加载机制与执行链路

2.1 一个 Skill 的物理结构

一个标准的 Skill 通常由两部分组成：主体说明文件和资源文件。主体说明文件一般叫作 SKILL.md，里面用 Markdown 写清楚这个技能是做什么的、怎么执行、输出格式是什么。资源文件可以放在配套目录里，比如示例模板、参考数据、辅助脚本等。一个典型的目录结构长这样：

weekly-report/ ├── SKILL.md ├── examples/ │ └── report-template.md └── scripts/ └── collect_git_stats.sh

第一次见到这个结构时，我的疑惑是：为什么核心文件不用 JSON 或 Python 脚本，非要选 Markdown？后来想明白了。SKILL.md 不是给机器执行的程序，而是给模型读的说明书。模型对自然语言和日常文档的理解能力更强，Markdown 又自带标题、列表、代码块的层级结构，能让模型快速定位关键信息。它可以是人读的文档，同时又是模型的指令，一份文件两用。

2.2 frontmatter 和正文，各写什么

SKILL.md 的头部通常会有一段简单的元信息，常见字段包括 name、description、allowed-tools 等。下面是一个结构示例：

--- name: weekly-report description: 根据 git 提交记录和任务清单生成项目周报。用户提到“周报”“本周总结”“项目进展”时使用。 allowed-tools: - bash - read_file - write_file ---

name 是技能的唯一标识，用于区分不同 Skill。description 是整个文件里最重要的一段，因为它直接决定模型会不会在合适的时机加载这个 Skill。这里不要简单写“生成周报”，而是要描述出“什么任务、什么触发词、什么场景”适合使用它。allowed-tools 是可选字段，用来限制执行时允许调用哪些工具，相当于给技能加一个权限边界，避免模型在尝试完成任务时去调用明显不相关的能力。

frontmatter 之后是正文。正文没有严格模板，但高质量的 Skill 一般都会包含这几块：目标说明、执行步骤、示例、注意事项。目标说明告诉模型“这个 Skill 要达到什么效果”；执行步骤是按顺序写的具体操作；示例是给模型看的输入输出样例；注意事项用来处理边缘情况。写正文时记住一个原则：尽可能具体，但不是把整本书抄进去。

2.3 加载流程：匹配、读取、执行

Claude Skills 和传统插件的最大区别是加载方式。插件通常由用户手动启动，而 Skill 是由模型在对话中自行判断是否需要加载。整个流程大致分三步。

第一步是匹配阶段。用户输入问题后，模型会根据对话内容，把它和所有可用 Skill 的 description 做语义匹配。如果用户说“帮我整理一下本周的提交记录”，模型有概率会想到 weekly-report 这个 Skill；如果用户只是问“今天天气怎么样”，显然不会加载它。

第二步是读取阶段。一旦模型决定使用某个 Skill，它会把 SKILL.md 读入上下文。这里的“读入”是后台行为，用户不一定看得到，但对模型来说，这相当于在原有指令之外临时多了一本手册。如果 SKILL.md 里引用了资源文件，模型也会在需要时用文件读取工具把它们拉出来。

第三步是执行阶段。模型不再只是机械地背诵指令，而是结合用户请求、实时环境和 Skill 里的步骤，动态完成任务。它可能会调用允许的工具、运行脚本、生成文档，也可以根据实际情况调整步骤顺序。整个执行过程更像一个“有经验的人拿到标准作业流程后自己动手干活”，而不是按固定代码跑一遍。

2.4 执行链路：Skill 不是工具，而是“上下文增强”

理解执行链路的关键，是分清“Skill”和“工具”这两个概念。工具是模型可以直接调用的外部函数，比如执行命令、读写文件、发送请求；Skill 则是一段指导模型如何完成任务的说明。工具负责“能做什么”，Skill 负责“应该怎么做”。在实际运行中，一个 Skill 往往需要依赖若干个工具才能完成工作，它会告诉模型“去调用哪个工具、按什么顺序调用、从返回结果里提取哪些信息”。

所以更准确地说，Skill 是一种“上下文增强”机制。它不改变模型的基础能力，而是通过临时注入高质量指令，让模型在特定任务上表现得像一位熟手。这种设计也让 Skill 非常适合复用：同一套工具接口，配不同的 Skill，就能支撑完全不同的业务场景。

3. 分清边界：Skills、Tools、MCP 的定位差异

3.1 Tools 是“接口清单”，Skills 是“接口使用手册”

在很多 AI 应用架构里，Tools 是开发者预先写好的函数，模型可以调用它们但一般不能修改函数本身。举个例子，假设你注册了一个 get_weather(city) 工具，模型知道签名是 city 字符串，返回天气数据，但它不一定知道什么时候该调、返回结果里的哪个字段是关键。这时候 Tools 只能解决“能不能调用”的问题，不能解决“调用得好不好”的问题。

Skills 恰好补上后面这部分。在同一套工具之上，你可以写一个“天气预报助手”Skill，里面规定：先判断用户提供的城市是否完整，再调用 get_weather；如果接口返回错误码，提示用户补充城市信息；最后用口语化语言播报温度、降水和风力。你看，Tools 是能力本身，Skill 是告诉模型怎么用好这些能力。用开车的类比来说，Tools 是方向盘、油门和刹车，Skill 是导航地图和驾驶教程。没有地图，你能开车，但容易走错路；没有教程，你会操作，但遇到突发情况可能不知道怎么处理。

3.2 MCP 是“数据与能力插座”，Skills 是“插座上的说明书”

MCP 是模型上下文协议，常被用来解决一个问题：如何以统一方式让模型访问外部数据和服务。以前你要对接一个数据库、一个内部系统，可能要写很多专用代码；有了 MCP，服务器可以把数据库查询、文件读取、业务接口统一封装成标准工具集，模型通过这些工具连接外部世界。

那 Skills 和 MCP 是什么关系？MCP 负责打通“连接”，Skills 负责教会模型“如何正确使用这些连接”。一个 MCP 服务器可以提供查询订单、读取库存、调用报表接口等能力，但如果模型不了解业务报表口径，不知道要先清理哪些异常数据，它仍然可能给出不靠谱的结果。正确的做法是写一个“业务报表生成”Skill，里面描述清楚查询范围、清洗规则、汇总方式，同时告诉模型去调用 MCP 暴露出的哪些工具。这样 MCP 负责提供原材料，Skill 负责把原材料加工成标准成品。

3.3 什么时候选哪种方案

我经常遇到朋友问：到底该用 Tools、MCP 还是 Skills？这其实不是互斥选择，而是一个分层设计。简单固定、参数明确的单次操作，可以直接用 Tools；需要多步骤、带业务规则和输出规范的流程，适合用 Skills；需要连接外部实时数据或异构系统的，用 MCP 做接入层，再配合 Skills 做流程编排。大多数复杂业务场景，最后都会是三方协作，而不是只押注单一方案。

4. 手把手：从零写一个可复用的 Skill

4.1 选一个足够典型的场景

为了让你能直接照着做，我用“生成项目周报”作为例子。为什么选它？因为它足够常见，不依赖第三方服务，只有两类输入：git 提交记录和任务清单。同时它的输出有明确格式，容易验证效果。

在动手前，先明确 Skill 的目标：当用户提到周报需求时，Claude 要能自动从 git 仓库收集本周提交，读取当前任务状态，最后按固定模板输出一份周报。这个目标听起来简单，但如果不写 Skill，每次让 Claude 生成周报时，你都要重新解释“先跑什么命令、过滤哪些信息、按什么格式输出”，非常重复。写成 Skill 后，一句“给我生成本周周报”就够了。

4.2 编写核心文件 SKILL.md

我通常先写 frontmatter，再写正文。下面是一个可直接参考的简化版本：

--- name: weekly-report description: 根据 git 提交记录和任务清单生成项目周报。当用户提到“周报”“本周总结”“项目进展汇报”时使用。 allowed-tools: - bash - read_file - write_file --- # 项目周报生成 ## 目标 根据当前项目的 git 提交记录和任务清单，生成一份结构清晰的中文周报。 ## 执行步骤 1. 使用 `git log --since="last monday" --pretty=format:"%h|%s|%an|%ad" --date=short` 收集本周提交。 2. 用 read_file 读取任务清单文件（如果没有指定，先找项目根目录下的 TASKS.md）。 3. 把提交记录按模块归类，和任务清单中的条目对应起来。 4. 按下面的“输出格式”生成周报。 5. 如果 git log 没有任何提交，不要编造，明确写“本周无代码提交”。 ## 输出格式 ## 注意事项 - 所有数据必须来自实际命令输出或文件内容，禁止凭空补全。 - 如果任务清单中有条目未在提交记录里体现，单独保留在“进行中”一栏。

写完之后你会发现，正文其实非常像一份标准操作流程。frontmatter 里的 description 是触发入口，正文“执行步骤”规定怎么做，“输出格式”规定结果长什么样，“注意事项”处理边界。模型一旦加载这个 Skill，就会严格按照这个流程干活。

这里要特别强调一下：SKILL.md 里的步骤不需要追求字字精确，但一定要让模型能执行。比如步骤里的 git 命令，最好直接给出完整命令，而不是写“收集本周的 git 提交记录”就结束。因为大语言模型对具体命令的复现能力比对自己“推测”更可靠，你把该有的参数写清楚，它照做就好。

4.3 配套资源目录有什么用

上面的例子很简单，所以只有一个 SKILL.md 就够了。但实际项目中，Skill 经常需要配套资源。比如周报模板可能有好几套，适合不同项目组；git 统计脚本可能很复杂，不适合塞在说明文件里。这时候你可以在 examples 目录放模板样例，在 scripts 目录放脚本文件，然后在 SKILL.md 里用一句话引导模型：“需要时读取 examples/report-template.md，或执行 scripts/collect_git_stats.sh”。

资源目录的真正价值，是避免把 SKILL.md 变成一个大杂烩。有些朋友一开始把所有代码、模板、历史数据全部内联进 SKILL.md，导致文件超过几千行。表面上看信息很全，实际上模型在读取时会被大量无关内容干扰，而且每次加载都要消耗大量上下文。正确的做法是：把最核心的步骤、最关键的判断写进 SKILL.md，把大段的模板、长脚本放到外部资源中，让模型按需读取。

4.4 让模型“想起来用”这个 Skill

写好文件只是第一步，更关键的是测试它会不会在合适时机被触发。你可以直接问一句：“帮我生成本周项目周报。”看输出是否符合模板。如果模型没有加载 Skill，而是用通用知识硬答，通常原因是 description 与你问法之间的匹配不够强。

比如 description 里如果只写“根据 git 提交记录和任务清单生成周报”，用户说“整理一下这周的工作”，模型就很有可能认为这不是“周报”场景。我的做法是在 description 里多写几组同义表达，例如“周报”“本周总结”“项目进展汇报”“commit 汇总”等，让触发覆盖面更广。但也不要写成关键词堆砌，否则无关请求也会触发，反而造成干扰。这个度需要反复测。

4.5 版本化管理与团队共享

Skill 本质上是普通文件，所以完全可以放到 Git 仓库里做版本管理。每次修改后进行测试，确认没问题再提交。团队协作时，只要约定一个公共目录存放 Skills，大家就可以共享同一套任务执行规范。我在实际项目中，会把每个 Skill 作为一个独立目录，里面附带 README 说明适用场景和版本变更。这样即使几个月后再回来，也能快速知道这个 Skill 是干什么的、改过什么。

5. 设计高质量 Skills：我最看重的四个原则

5.1 description 是触发入口，写清“什么时候用”比“怎么用”更重要

前面反复提到 description，因为它是一个 Skill 能否被正确调用的关键。很多人写 description 时习惯写“这是一个生成周报的技能”，这个表述过于自我中心，没有站在模型匹配的角度考虑。模型不是先遍历所有技能再选一个，而是从当前对话内容和所有 description 中做语义匹配，所以 description 应该描述任务场景，而不是描述技能名称。

我经常用的写法是：“当用户需要生成某类文档时使用，例如提到‘周报’‘总结’‘汇报’等关键词”。也就是把触发条件放在最前面，把典型场景逐一举出来。这样做的好处是，即使模型的语义理解没完全命中，也能通过关键词真实命中。反过来说，如果 description 写得过于宽泛，比如“处理文档”，那么用户让模型翻译一段话时，模型也可能误加载这个 Skill，反而带偏输出。控制触发边界，是设计 Skill 的第一课。

5.2 给足示例，少写抽象定义

大语言模型有一个很明显的特点：给它三到五个具体示例，效果往往比解释一大段抽象规则好很多。因此在 SKILL.md 正文里，我尽量把示例放在比较靠前的位置。比如周报模板，不只是写“格式包含完成、进行中、风险”，而是直接放一段填充了虚拟数据的周报样例，让模型看到真实的表达风格。

示例的作用不只是展示格式，还能帮助模型理解“什么内容该放在哪个部分”。比如样例里“本周完成”下面每一条都包含功能标题和 commit 号，那么模型生成时也会主动去匹配这种结构。如果某个 Skill 涉及多种边界情况，建议每种情况各放一个正例或反例。反例尤其重要，因为很多错误是无法通过正例规避的，模型看了反例才知道“原来这样写是不行的”。当然，示例也不要无限制堆叠，能把典型情况覆盖住就可以了。

5.3 控制上下文成本，把大内容挪到外部资源

上下文长度是有限的资源，Skill 加载后会占用 token，占用越多，留给用户对话和模型推理的空间就越少。所以一个高质量的 Skill，SKILL.md 本身应该尽量精简。我的经验是：优先用简洁步骤和 checklist 描述流程，不要写大段解释性文字；需要完整模板、历史样例、长脚本时，放在 resources 里，并明确指示模型按需读取。

这里有个常见误区：很多人害怕模型读取不到外部文件，于是把内容又复制了一份进 SKILL.md，结果两份内容不一致，模型也不知道该信哪份。正确的做法是确定一个唯一来源。SKILL.md 只写“读取 examples/report-template.md 作为模板”，这样模板更新时只需要改一处，SKILL.md 不用动，测试成本也低。

5.4 在 Skill 里内置错误兜底和最终检查

模型执行 Skill 时，环境往往不会像示例中那么完美。git 仓库可能还没初始化，任务清单文件可能不存在，命令可能因为权限失败。这些情况如果不在 Skill 里说明，模型要么编造结果，要么陷入反复重试。所以我写 Skill 时会在注意事项里明确“如果某个命令失败，不要猜测结果，把错误信息反馈给用户，并尝试替代方案”。比如 git log 没有输出时，明确要求模型输出“本周无代码提交”，而不是硬凑内容。

此外，在输出环节加一道检查步骤也很有效。比如周报 Skill 的末尾写“生成完成后，检查是否所有条目都来自真实数据，是否存在凭空生成的 commit 号”。这个检查步骤会让模型的输出更稳定，因为它相当于在生成结果前多了一次自我验证。一开始我觉得加这一步是多余的，后来测了几个 Skill 后坦诚说，有没有这一步，错误率差距很大。

6. 实战避坑：Skill 开发中常见的五个坑

6.1 Skill 怎么都不触发

这是刚上手时最容易遇到的问题。文件写好了，放在目录里，但用户怎么问都不生效。大部分原因是 description 与用户表达方式之间差距太大。比如用户习惯说“帮我整理一下这周的东西”，而 description 只写了“周报”，语义上没有明显关联，模型就不会加载。

解决办法是在 description 里加入来自真实用户提问的表述。你可以先不写 Skill，直接和 Claude 聊几天，把大家实际说法的变体记下来，再原样写进 description。不要只从自己的预期出发，要站在用户实际说的话上看匹配概率。如果改了几轮还不触发，可以临时把 description 写得略宽泛一点，宁可多触发几次，先确认链路是通的，再慢慢收紧边界。

6.2 触发了，但没遵守输出格式

另一种常见情况是模型确实加载了 Skill，但输出格式和定义不一致。比如要求先写“本周完成”，模型却先写“本周总结”，或者漏掉了风险一栏。这通常不是模型看不到格式，而是 Skill 里对输出格式的约束不够强，或者示例不够贴近目标格式。

我的对策是：在“输出格式”中直接给一个可复制的骨架，甚至可以在末尾写“严格按以上结构输出，不要增删一级标题”。同时把示例放在紧邻输出格式的位置，让模型在生成时更容易参考。之前还有一个问题，就是 frontmatter 和正文中的格式要求说法不一致，导致模型不知道该听谁的。后来我把所有格式细节统一到一处，效果明显改善。

6.3 上下文被大段模板塞爆

这个在 5.3 里提过，但实际操作中还是有很多人踩坑。有人为了保证模型有足够信息，把几套模板、几十条历史示例全写进 SKILL.md，结果每次加载都消耗大量上下文，对话稍长一点，模型就开始忽略后面的步骤。

正确思路是只保留当前任务真正需要的信息。如果模板很多，可以做一个索引列表放在 SKILL.md 里，让模型先读索引，再按需读取具体模板。这样既能覆盖多种场景，又不会一次性把上下文占满。别小看这个设计，我在一个数据报表项目里，光是把 SKILL.md 从很长很长精简到一屏不到，模型输出质量就提升了一个档次。

6.4 多个 Skill 互相冲突

当项目里的 Skill 越来越多，就会出现多个 Skill 的 description 同时匹配一个任务的情况。比如你有一个“周报生成”Skill，又有一个“会议纪要生成”Skill，用户说“把本周会议记录整理成周报”，两个 Skill 都可能被触发。如果模型选择错误，后续输出就会混乱。

解决办法是在写 description 时主动声明边界。把“哪些情况不要用”也写进去，例如会议纪要 Skill 的 description 末尾加一句“如果用户明确要求生成周报，请优先使用周报 Skill”。同时，两个 Skill 的触发条件尽量在语义上区分开，避免重叠区域过大。当冲突实在无法避免时，还可以考虑把一个 Skill 拆成更细的子 Skill，或者合并成一个综合 Skill 并在内部做分支判断。

6.5 测试结果不一致，同一个 Skill 时灵时不灵

最后一个坑是稳定性问题。同一个 Skill，同样的输入，昨天效果很好，今天突然不行了。这里可能有三个原因：一是模型版本更新，不同版本对指令的遵循能力有差异；二是上下文里加了很多无关内容，干扰了模型判断；三是 Skill 本身的指令不够显式，导致执行差异被放大。

针对这个问题，我能给的建议有三个。第一，把最关键的要求放在 Skill 文末再强调一次，比如“所有数据必须来自真实命令输出”，这种末尾重复能提升遵循概率。第二，在测试时固定温度参数，避免随机性干扰判断。第三，每次修改 Skill 后记录当时的模型版本、测试输入和输出，形成一份小日志。时间一长，你会看清楚哪些改动真正有效，哪些只是看起来有效。

如果只留一句话做心得，我会说：Claude Skills 的核心价值，不是让你写出更长的提示词，而是把“什么时候用、怎么用、出错怎么办”这三件事说清楚，剩下的交给模型自己去执行。你在设计每一个 Skill 时，都把自己想象成一位带新人的老师傅：手册少写废话，流程清晰可执行，常见问题提前预警。做到这几点，哪怕是最简单的 SKILL.md，也能比堆砌几千字的长提示词可靠得多。