企业官网建设流程全解析

最近AI圈子里讨论度最高的一个词，大概就是Anthropic给Claude增加的Skills（技能包）能力。我把它实际用了一轮之后，最大的感受是：这东西终于把AI从"每次都要重新教一遍的实习生"变成了"装满各种工具的收纳箱"。以前想让大模型干点专业的活，你得把提示词、背景规则、处理流程一遍一遍塞进对话框，换个会话全部归零重来。有了技能包之后，思路彻底变了——把某项能力封装成一个文件夹，像手机装App一样装给Claude，它在你需要的时候自己会去取用。

这篇文章我不打算照抄官方文档，而是把我从"听说有这个功能"到"安装别人的技能包"再到"自己动手写了一个"的全过程拆开讲。内容包括：Claude Skills到底是什么、一个技能包内部的文件结构长什么样、安装和调用的完整流程、如何从零编写自己的技能包，以及我实际踩过的坑和排查方法。适合刚接触这个概念、想快速上手的人，也适合已经在用但想弄明白"为什么要这样设计"的开发者。我尽量说人话，遇到文件结构、配置语法这些细节，直接给例子，不绕弯子。

1. Claude Skills到底是什么：AI能力的"可插拔"革命

1.1 从"对话调教"到"技能装载"：解决的核心痛点

先说我自己的痛点。我日常用大模型处理任务算是重度用户，每周都要让它帮忙做数据分析、整理会议纪要、生成周报、批量重命名文件之类的活。每个任务我都要准备一段"专属提示词"——比如告诉它"你是资深数据分析师，请按以下步骤处理CSV"、"你是文档验收专家，请按团队规范检查格式"。这套做法最大的问题有三个。

第一，每次新会话都要重新粘贴提示词，一长串，既占上下文窗口又容易漏。偶尔忘了贴某段规则，模型输出的质量和格式立刻跑偏。第二，遇到需要执行代码的任务，模型要么生成一段代码让你自己去跑，要么在沙箱里跑完但下次对话又要重新说明环境和依赖。第三，多个任务之间会相互干扰，你让模型"擅长写周报"之后，它可能在处理数据分析时也套上周报的格式和口吻，非常拧巴。

Skills解决的就是这三个问题：把提示词变成可复用的声明文件，把可执行的脚本变成技能的一部分，把能力边界用描述文字界定清楚。用一个专业术语说叫"模块化"和"可组合"——说白了，就是把AI的能力做成可以随时抽插的卡槽。以前你想让一个模型干三种专业活，得给它写三套提示词、维护三个沙箱环境；现在三个技能包装上去，各管各的，互不污染。

1.2 为什么说它"像软件一样装技能包"

我理解这个设计最好的类比，就是包管理器。你在项目里用npm装依赖、用pip装库的时候，根本不需要关心那个库内部怎么实现，只需要声明"我要用这个库"，它就把自己挂到项目里供你调用。Claude Skills的设计哲学几乎一模一样：每个技能是一个独立的文件夹，自带说明和使用方法；系统把技能的"名册"交给Claude；Claude判断当前任务跟哪个技能匹配，就主动加载并使用；技能来源可以是社区公开分享、团队内部沉淀，也可以是自己写的。

所以很多人把这种形态叫"AI的App Store"或者"模型的操作系统化"——模型本身还是那个模型，但通过装载不同的技能包，它可以胜任完全不同的专业场景。你给AI装一个"合规审核技能"，它面对合同文本时的表现会接近一个熟悉审核流程的专员，知道先看资质再看条款最后出修改建议；你给它装一个"日志异常分析技能"，它处理服务器日志时的路径就完全不同，会主动去聚合时间窗口、提取错误码、按级别排序。同一个底座，不同的外挂能力，这就是它和"每次临时写提示词"最本质的差别。

1.3 Skills、Tools、MCP三者的关系别搞混

不把概念理清楚，后面看文档一定会懵。我简单说下我的理解。

Skills（技能包），偏向"领域能力"的封装。它描述的是一个完整的工作流程，比如"生成周报"、"审查代码规范"、"分析日志异常"。技能包内部可以引用脚本、模板，也可以只靠提示词，不写一行代码。

Tools（工具），单一功能的可调用接口，比如"读取文件"、"执行Python代码"、"搜索网页"。大模型本身就有原生工具集，技能包里的脚本执行，本质上也是依托工具调用完成的。

MCP（模型上下文协议），是连接外部数据源和服务的标准化协议。MCP提供的是"连接能力"，比如连接数据库、连接企业知识库、连接第三方SaaS。

它们的关系可以粗鲁理解成：MCP是插头，Tools是插座，Skills是用电器。一个技能包内部可能需要用到多个工具调用，甚至可以通过MCP去拉取外部数据。把这三层分清楚，你就明白了技能包解决的是"流程与经验"这一层，而不是底层连接那一层。换句话说，MCP让你能连上数据源，Tools让你能操作环境，Skills让你能"像专家一样干活"。三者是配合关系，不是替代关系。

2. 技能包的内部结构：拆开一个Skill看看

2.1 最小可用结构：一个文件夹加两个部分

我第一次拆开官方的示例技能包时，发现结构比想象中简单得多。一个技能就是一个目录，里面通常包含：

my-skill/ ├── SKILL.md └── scripts/ └── build_report.py

核心是SKILL.md这个文件，它是一份人类可读、模型也可读的说明文档。scripts目录则是可选的，用来放可执行脚本。更复杂的技能包可能还会有assets/放模板文件、reference/放参考资料。这个结构设计得很克制，我后来想，这是刻意为之：越简单的结构，越容易被模型理解和复用。如果你把技能包做成了一个几百兆的工程，模型加载反倒困难，维护成本也直线上升。

2.2 SKILL.md的头部元信息和正文各管什么

SKILL.md的头部有一段YAML格式的元信息，行业黑话叫frontmatter，这是给模型"看简历"用的。最关键的字段有三个。

name是技能包的短名称，比如weekly-report，供系统索引和引用。description是一段精炼的描述，说明这个技能在什么场景下、解决什么问题。这段描述极其重要，重要到什么程度呢——模型就是靠它来判断"当前这个任务该不该用这个技能"的。allowed-tools是可选字段，列一个清单限制该技能可以调用哪些工具，比如只允许bash和read_file，相当于给技能划了权限边界。

正文部分则是给模型看的"使用说明书"，通常包含：这个技能在什么情况下使用、具体操作步骤、输出格式要求、注意事项、边界条件——也就是什么时候不该用。我举个简化例子，一个"会议纪要"技能的SKILL.md大概长这样：

--- name: meeting-minutes description: 将会议录音转写文本整理为结构化会议纪要。适用于产品评审、项目周会、客户沟通会议。 --- # 会议纪要整理 ## 使用条件 当用户提供一段会议录音转写文本，并希望得到结构化会议纪实时使用。 ## 处理步骤 1. 提取与会者角色，区分决策者、记录人、执行人。 2. 按"决议事项 / 待办任务 / 风险问题"三类归纳内容。 3. 每个待办任务必须标注负责人与截止时间，找不到时写"待确认"。 4. 输出格式：Markdown表格，首列为议题，次列为结论。 ## 注意事项 - 不主观添加原文本中没有的意见。 - 转写文本有噪音（重复、口误）时，可轻微修正但不改变原意。

你发现没有，这其实就是你把最好的提示词沉淀成了一个文件。技能包的SKILL.md，本质上是一份结构化的专家提示词。它最大的价值是"一次写好，处处复用"，而且可以版本化、评审、分工协作——这在对话式提示词时代是很难做到的。

2.3 scripts目录：把"建议"变成"执行"

光有提示词，很多东西是干不动的——比如让你处理一个100MB的日志文件，你肯定不想让模型把整个文件都读进上下文再分析。这时候就需要脚本出场。

scripts目录里的脚本，Claude根据SKILL.md里的指示去调用执行。典型的分工是：模型负责"想"，根据SKILL.md的指导决定步骤、参数、判断标准；脚本负责"做"，执行批量操作、计算、文件处理、数据转换。我后来写过一个"CSV数据清洗"技能包，里面有一个clean_csv.py。SKILL.md会这样指示模型："如果文件超过5000行，不要直接读取完整内容，先调用脚本检查列名和前5行数据，再决定清洗策略。"这样一来模型就知道什么时候该碰脚本、脚本输出该怎么解读。

这个设计非常关键，它意味着技能包不仅是教会模型知识，还给了模型"双手"。这也是它和单纯的长提示词之间最核心的区别。单纯的长提示词只能告诉模型"怎么做才正确"，而技能包让模型可以在你自己的环境里真正把事情做掉。从此AI不再只是"出主意"，而是"动手干"。

3. 实操：把技能包装给Claude并跑起来

3.1 前置条件：动手之前你需要准备什么

在动手之前，先说下我建议的准备条件，省得白折腾。第一，一个支持Skills能力的Claude运行环境，官方Agent SDK或者桌面客户端的最新版本都可以，具体以你所用版本的官方支持情况为准。第二，一个专门放技能包的目录。我建议在项目根目录建一个skills/文件夹，所有技能包统一放里面，方便管理，也方便后续做版本控制或打包分发。第三，理解技能的加载机制——不是说你把文件夹放进去就立即全局生效，技能的name和description会成为系统提示信息的一部分，模型看到这份名册并自行判断是否使用。

这意味着两件事：一是你的技能描述写得越准确，技能被正确调用的概率越高；二是你可以在请求层面控制哪些技能进入名册，做按需加载。我刚开始没搞懂这套机制，把十几个技能一股脑全装进去，结果系统提示词被撑得很长，模型反而变得犹豫不决，后来改成按任务只挂两三个技能，效果立刻改善。

3.2 具体安装步骤：三步完成装载

以官方Agent SDK的示例流程为例，大致是这样，细节以官方文档为准。

第一步，创建技能目录。

mkdir -p skills/my-skill

第二步，把技能包内容放进去。如果从社区下载了别人做好的技能包，直接把文件夹解压到skills/下面；如果自己写，就按上一章的结构创建文件。

第三步，在代码里指定技能目录并启用。以TypeScript为例，示意代码如下：

import { Anthropic } from "@anthropic-ai/sdk"; const client = new Anthropic(); const response = await client.messages.create({ model: "claude-...", max_tokens: 4096, messages: [ { role: "user", content: "帮我把刚才那场讨论的结论整理成会议纪要" } ], skills: [ { name: "meeting-minutes" } ] });

不同客户端版本的API可能有细微差异，但核心思路是一样的：在请求里显式声明要启用哪些技能。这一点务必注意，不是所有技能都会默认全量生效，声明启用是第一步。如果你用的是桌面客户端，通常在设置或项目配置里有一个技能管理入口，把技能文件夹路径填进去就行，不需要写代码。

3.3 怎么确认技能真的生效了

装完技能包，最怕的情况就是"看似装上了，实际没用上"。我自己的验证方法是三连测试。

第一，直接点名测试。在对话里明确说"用会议纪要技能处理这段文本"。如果技能真的被加载了，模型的输出会明显贴合技能里定义的格式和步骤——比如立刻套用你定义的三分类结构。如果输出和普通对话没啥区别，说明技能可能没加载成功，或者描述写得不到位。

第二，间接触发测试。不说技能名字，只描述场景，看模型是否能"自觉"调用。比如只说"我刚开完会，这是录音转写，帮我出个纪要"，看它输出的格式是否包含技能里规定的字段。这一步真正测的是description写得好不好，也就是语义匹配的能力。

第三，脚本执行测试。如果你的技能包带着脚本，给它一个必须执行脚本才能完成的任务，观察它是否真的调用了脚本。比如丢给它一个2万行的CSV让它统计各列空值率，如果它不调脚本，而是想硬读整个文件进上下文，说明SKILL.md里的"何时调用脚本"写得不到位，命令不够强制。这三条测完，技能包是否在正常工作，基本心里有数了。

4. 从零编写一个技能包：三步走实战

4.1 什么能力适合做成技能包

我观察到自己日常用AI的场景，适合技能包化的大概有三种。第一种是高频重复型，每周都要做的任务，比如周报、日报、代码评审记录，值得固化流程。第二种是流程复杂型，需要固定步骤、多阶段处理的，比如从需求文本一路生成测试用例，中间涉及拆分、去重、覆盖矩阵、评审清单。第三种是强领域知识型，需要特定术语、规范、注意事项才能干好的，比如某种文档格式标准、某个业务领域的审查清单。

反过来，一次性闲聊、没有固定流程的探索性任务，做成技能包完全是浪费，不但增加管理负担，还可能让模型在不需要的时候硬套技能，把简单问题复杂化。判断标准就一条：你愿不愿意把这件事的流程写成一页纸的SOP？愿意，就值得技能包化；不愿意，就别做。

4.2 实战：从零写一个"周报生成"技能包

我以一个最典型的小例子演示全流程——"周报生成"技能包。这个技能不依赖外部脚本，纯靠SKILL.md提供结构和方法，最直观，也最适合新手练手。

先建目录：

mkdir -p skills/weekly-report touch skills/weekly-report/SKILL.md

然后写SKILL.md文件：

--- name: weekly-report description: 根据用户提供的本周工作内容要点，生成符合团队格式的周报。适用于每周五下班前整理周报的场景。 --- # 周报生成 ## 职责 - 将用户零散的工作内容整理为结构化周报。 - 提炼下周计划，区分"确定事项"和"待确认事项"。 ## 输出格式 使用如下Markdown结构： ## 本周完成 - 按项目/模块分组，每项一条，格式：[项目/模块] 完成内容 + 可量化结果 ## 下周计划 - 使用有序列表，标注预计开始日期 ## 风险与阻塞 - 没有则写"无" - 有则注明：阻塞事项、影响范围、需要谁协助 ## 约束 - 不补充用户未提及的工作内容。 - 如果用户提供的信息不足以生成下周计划，主动询问而不是编造。

写完把这个文件夹放到skills/下并在客户端里启用，一个能用的技能包就诞生了。实操下来我发现几个关键心得。

第一，description要写"场景"而不只是"功能"。不要只写"生成周报"，要写"根据工作内容要点生成周报，适用于每周五总结场景"。因为模型靠语义匹配决定是否调用，场景信息越具体，命中率越高。第二，输出格式要写死。给模型越明确的格式，输出稳定性越高。如果你希望它有弹性，也要明确说"如果没有XX就写无"，而不是含糊地说"酌情处理"。第三，边界条件必须写清楚。我一开始没写"不补充未提及的工作内容"，结果模型在用户信息残缺时就开始自行补全，看起来贴心，实际上失真。

4.3 进阶：写一个带脚本的技能包

如果你想让技能包真正干"重活"，脚本少不了。这里我强烈建议遵循一个原则：脚本做确定性工作，模型做判断性工作。所谓确定性工作，就是输入输出都明确的机械操作，比如格式转换、正则匹配、批量文件重命名、数据统计；所谓判断性工作，就是需要理解上下文和业务含义的，比如"这个异常值得关注吗""这段代码有没有潜在缺陷"。

我写过一个"代码仓库扫描"技能包，目录结构长这样：

repo-scan/ ├── SKILL.md └── scripts/ ├── scan_todos.py # 扫描TODO/FIXME标记 ├── count_loc.py # 统计代码行数 └── analyze_api.py # 分析API调用点

SKILL.md里我明确写了使用流程：先跑scan_todos.py，再跑count_loc.py，如果第二步的输出出现异常指标，再决定是否运行analyze_api.py。脚本负责输出原始数据，模型负责解读数据并生成审查报告。这样分工的收益很明显：脚本结果可复现、可审计，模型的解读有依据，不会信口开河。

写脚本型技能包时，有三个细节容易被忽略。第一，脚本要能接受命令行参数，不要写死路径，因为你无法预判模型会在哪个工作目录下执行。第二，脚本输出要尽量结构化，比如JSON或多行纯文本，方便模型解析。我最开始写的脚本输出了一堆带ANSI颜色码的终端文本，模型解析起来非常费劲，改成JSON输出后流畅多了。第三，脚本错误处理要兜底，至少要把异常捕获住并输出可读的错误信息，让模型知道"是脚本挂了，不是数据有问题"。

5. 踩坑实录：装技能包常见的坑与排查方法

5.1 技能一直不被调用？先查描述，再查加载

这是新手最常遇到的问题：明明技能装好了，模型就是不调用，问它"你会不会整理会议纪要"，它居然说不会。排查思路分三步。

第一步，确认技能已被加载。直接问模型"你现在有哪些技能可用"。如果它列不出来，说明加载环节有问题——路径不对、名称拼错，或者所用版本不支持。这时候别急着优化内容，先确认"能不能看到"。

第二步，检查description的匹配度。模型决定是否调技能，核心依据是任务描述和技能描述之间的语义相似度。如果技能描述写得像一本产品说明书，而用户提问像日常聊天，匹配不上是很正常的。我自己有个技巧：把description写成"当用户提到XX、YY、ZZ这些词时，使用此技能"，把常见触发词直接写进去，命中率会明显上升。

第三步，看看是不是模型已经完全能凭自身能力搞定。如果模型觉得不调用技能也能完成，它可能就不调用。这不是故障，是决策。你想强制它用，就在提示里点名"请使用XX技能"。

5.2 脚本报错了？多半是路径、依赖和环境问题

脚本执行失败，九成是三个原因：工作目录不对、依赖没装、权限不足。我的排查顺序是：先在终端手动执行一遍脚本，确认脚本本身没毛病；再检查模型调用脚本时传的参数是否完整，有时候是SKILL.md里没写清楚参数格式，模型自己猜了一个路径，结果找不到文件；最后确认脚本解释器是否在可执行路径里，技能包如果要在不同机器上跑，最好在SKILL.md里写明启动命令，比如python3 scripts/scan.py --dir <path>，避免模型使用错误的解释器版本。

还有一个很多人忽略的点：脚本要在SKILL.md里声明运行方式，包括是否需要安装依赖。我见过一个写得特别好的技能包，直接在正文里写"首次使用前请执行pip install -r requirements.txt"，模型就会先装依赖再跑，非常省心。反过来，我自己的第一个脚本技能包就是没说依赖，模型跑起来报ModuleNotFoundError，来回折腾了好几次才解决。

5.3 上下文窗口与技能内容的平衡

技能包装多了之后，所有技能的name和description都会占用系统提示词的上下文长度。假设你装了30个技能，每个description平均300 token，光技能名册就要吃掉近万token——这还没算对话本身。系统提示词越长，模型在关键任务上的注意力就越分散，输出质量会下降。

所以有两个实用建议。第一，按需启用，不要全量加载。官方机制支持在请求里指定启用哪些技能，尽量只加载当前任务真正需要的。第二，description尽量控制在200 token以内。写得精炼、信息密度高，既能被模型匹配到，又不浪费上下文。详细的操作步骤放在正文里，不要全堆在description里——正文只在技能被激活时消耗上下文，而description每一次对话都在消耗。

5.4 安全边界：技能包绝对不要乱装

技能包本质上是"提示词 + 可执行代码"的组合，这意味着它既有能力增强，也有供应链风险。我自己的安全实践有四条。

第一，只从可信来源安装技能包。装之前打开SKILL.md和scripts目录逐行看一眼，确认没有可疑操作，比如向外部服务器传输数据、递归删除文件这类危险动作。第二，隔离运行环境。如果技能包里有脚本，尽量在容器或受限的沙箱环境里跑，不要给它本机全部权限。第三，最小权限原则。给技能包声明最小需要的工具集，比如只允许bash和write_file，不需要网络权限就坚决不开。第四，敏感数据不进技能流程。涉及密钥、个人数据、未公开业务信息的任务，宁可不用技能包处理。

注意：任何AI技能包都不应该替代你的人工审查，尤其是涉及敏感数据的时候。脚本是透明的，但只有你逐行看过之后，它才真正算透明。

6. 最后分享几点我自己的体会

6.1 技能包真正带来的变化不是"变聪明"，而是"可固化"

我实际用下来最大的收益，不是模型变聪明了，而是我的工作方法被固化了。以前我写周报、做数据清洗、扫代码，每次都靠临时对话，质量时好时坏，同一个任务今天让模型用A格式输出，明天它可能就换了一套说法。现在我把这些流程做成技能包，输出质量一下就稳定了——因为每次执行的都是一套标准流程，模型只是换了执行人，标准还是那个标准。这种感觉很像从"手工作坊"升级到了"流水线生产"。

6.2 给新手的启动建议

如果你正准备上手，我建议从小处开始：先挑一个你每周都要做的任务，把它写成技能包；用两周时间测试、迭代description；跑顺之后再做第二个。不要一上来就搞十个技能包的巨型体系，技能之间可能互相干扰，维护成本也会反噬你。技能包的级别划分依赖经验的积累，做多了自然就有感觉了。

最后再分享一个小技巧：技能包的版本管理。我后来把skills/目录纳入Git管理，每次修改技能内容都提交一次。这样当某天模型输出突然变差时，我可以快速回溯到之前正常工作的提交版本。AI模型的能力可能飘忽不定，但你的技能配置是可以锁死的——这份确定性，就是技能包给我最大的安全感。