企业官网建设流程全解析

每次让 Claude 干活，我都得把那段写了几十遍的提示词重新贴一遍，改几个字，再等它理解我的意思。后来我把常用 prompt 整理成文件，放在固定目录里，Claude 自己就会去读，一句简短的话就能触发完整流程，输出格式还特别统一。这就是 Claude Skills。这篇保姆级教程不整虚的，从目录怎么建、配置文件怎么写，到手把手教四个能直接用的技能，全部按"照做就行"的标准来写。你不需要懂编程，只要能打开文本编辑器，跟着往下走就能用出效果。

1. Claude Skills 到底是什么？先搞懂它解决问题的思路

1.1 一句话理解 Skills 的运行逻辑

Skills 说白了就是把一段"给 Claude 的工作指令"打包成一个文件，放在指定目录里。这个文件通常叫 SKILL.md，里面用大白话或者 Markdown 写清楚：这个技能是干什么的、接到任务后应该按什么步骤做、最后输出成什么样子。

你可能会说，这不就是自定义提示词吗？和直接在对话框里粘贴一大段要求有什么区别？

区别在于触发方式。没有 Skills 的时候，你每次都要把那段长长的指令手动贴进去，粘贴错了还得重新来。有了 Skills 之后，你只需要用一句人话描述需求，比如"帮我把这个月的工作记录整理成周报"，Claude 看到这句描述，会自动去匹配技能目录里的文件，找到描述匹配的那个 SKILL.md，按里面的流程执行。你根本不用提"请使用周报技能"这种话，它是自己判断的。

这个机制有点像手机里的快捷指令，你把"打电话给某人""打开某个应用并导航"这些重复操作编排好，之后只需要一个动作就能触发整条链路。Skills 就是把这种思路搬到了 Claude 身上，只不过编排的内容不是手机操作，而是让模型按特定流程干活的具体指令。

1.2 它适合谁用、能解决什么实际痛点

我用了几个月，最大的感受是三个词：省事、统一、可复用。

省事，不用反复写提示词。以前写周报，每次开头都是"你是一名项目管理助理，请根据以下内容输出周报，格式包括本周进展、风险、下周计划……"这段话五百字，我复制了三个月。现在这四个字就够了："整理周报"。

统一，输出不再随心情变。你直接用对话让 Claude 写方案，它今天给你输出三段式，明天给你列五条要点，后天给你画个表格，全看它当时怎么理解。但 Skills 里的 SKILL.md 如果写死了格式模板，它每次都会严格按模板来，交付物像同一个模子刻出来的。

可复用，技能文件能到处带。一个 SKILL.md 就是一份纯文本文件，你可以复制给同事，放到新电脑上，甚至针对不同项目各建一套。我手头有个某跨平台系统的开发项目，项目目录里放了一套专门查代码、提缺陷、生成提交说明的技能，换新环境之后把这些文件放回去，技能就回来了。

适用场景我列一下，你看看有没有对应的：

不论你是职场人、开发者还是学生，只要你有"反复让 AI 做同一类事情"的需求，这个功能就值得花半小时折腾一下。

2. 动手之前：环境与目录需要准备什么

2.1 需要装好的运行环境

要跑通 Skills，你手里得先有一个能正常对话的 Claude 环境。目前支持技能机制的，主要是 Claude 桌面应用，以及官方命令行工具（就是常说的工作区模式），二选一就行。

桌面应用适合日常写作、整理资料、分析文档这类场景，操作直观，适合多数人。命令行工具适合开发者，好处是可以直接进入项目目录，在那个目录下启动对话，Skills 自动读取项目级配置，配合代码仓库用起来更顺手。

这里要提醒一句：网络环境要能正常访问官方服务。怎么访问属于基础问题，我不展开，你自己按平时能用 Claude 的方式来就好。如果模型一直提示连不上，先排查基础连接，再回来弄 Skills。

2.2 目录结构与文件摆放标准

Skills 不是随便丢个文件就能识别的，它要求严格的目录结构。技能文件要放在一个叫 skills 的目录下，这个目录可以出现在两个位置：

全局位置：当前系统用户目录下的.claude/skills/，放在这里对所有对话生效。

项目位置：当前项目根目录下的.claude/skills/，放在这里的技能只对该项目里的对话生效。

目录结构长这样：

~/.claude/skills/ ├── 技能名1/ │ ├── SKILL.md │ └── 资源文件.md ├── 技能名2/ │ ├── SKILL.md │ └── templates/ │ └── 模板.md └── 技能名3/ └── SKILL.md

每个技能单独建一个文件夹，文件夹里必须有一个 SKILL.md，其他辅助文件可根据需要添加。技能文件夹的名字建议用小写英文字母加短横线，比如weekly-report、meeting-notes，这样在命令行里操作方便，也不容易出现编码问题。

创建目录的命令，终端里执行：

mkdir -p ~/.claude/skills/my-first-skill

这会在当前用户目录下生成.claude/skills/my-first-skill/这个文件夹，里面暂时是空的。接下来就在这个文件夹里创建 SKILL.md 文件。

提示：macOS 和 Linux 下~代表当前用户主目录，Windows 下对应的路径一般是C:\Users\你的用户名\.claude\skills\。如果你用的是命令行工具，Windows 上同样可用这套路径规范。

3. 新手必看：三分钟建好第一个专属技能

3.1 最小可用的 SKILL.md 文件长什么样

用文本编辑器新建一个文件，命名SKILL.md，注意文件名全大写，扩展名是.md。里面写入下面这段内容：

--- name: weekly-report description: 当用户需要根据工作记录生成周报、整理本周工作内容时使用。接收用户提供的原始记录，输出结构化周报。 --- # 周报生成 你是一名项目助理，请根据用户提供的工作记录生成周报。严格按以下步骤执行： 1. 从用户输入中提取工作事项，按项目或主题归类。 2. 每类工作提炼出具体进展，用一两句话描述清楚。 3. 识别风险与阻塞项，如果没有则写"无"。 输出格式： ## 本周进展 - [工作项]：[进展描述] ## 风险与阻塞 - [风险描述] 或 无 ## 下周计划 - [计划事项]： [预期结果]

这个文件就是技能的全部核心。最上面用三根短横线包起来的部分叫 frontmatter，里面两个字段是关键：

• name：技能名称，建议全小写加短横线，只用来唯一标识。
• description：技能描述，这一句话决定了 Claude 什么时候调用它。

下面从# 周报生成开始的内容，就是你给 Claude 的具体工作指令。它会完整地被模型读取，相当于你每次对话时手动粘贴的那一大段 prompt。

3.2 description 写得好不好，直接决定调用准不准

很多人的 Skills 不生效，不是文件放错位置，就是 description 写得太模糊。这个字段是 Claude 判断"用户需求是否匹配技能"的唯一依据，它的质量直接决定技能能不能被正确触发。

什么是不好的描述？

description: 处理周报相关任务

"周报相关任务"太泛了，用户说"帮我总结一下这周的工作"，模型可能觉得这算周报相关，也可能不算，完全靠猜。

什么是好的描述？

description: 当用户需要根据工作记录生成周报、整理本周工作内容、汇报本周进展时使用。接收用户提供的原始记录，输出结构化周报。

这句描述把触发条件说得很清楚：用户表达里出现"生成周报""整理本周工作内容""汇报本周进展"这类需求时，技能就会被调用。描述里还提到了"接收原始记录，输出结构化周报"，这告诉模型这个技能的动作逻辑，让它更有把握做匹配。

实操经验：写 description 时，把用户可能说的不同说法都覆盖进去。比如你做一个翻译技能，描述里写"将中文翻译成英文、中译英、翻译这段文字"，多种说法对应同一种需求，匹配成功率更高。

3.3 验证技能是否生效的测试方法

文件建好后，回到对话界面，用一句简短的话描述需求测试：

"这周完成了登录模块开发、修复了三个接口缺陷、整理了数据库设计文档，帮我整一下周报。"

如果系统正确匹配了技能，它会按 SKILL.md 里规定的步骤和格式输出。怎么确认它确实读了技能文件？就看输出格式和你在文件里定义的是否一致，如果它输出的周报严格包含"本周进展、风险与阻塞、下周计划"这三块，就说明技能生效了。如果它只是普通地列了个清单，格式天马行空，那就是没有读到技能。

有时候模型也会偷懒，技能生效了但输出没完全按格式。这时候可以补一句"按技能里定义的格式来"，它会立刻纠正。

4. 把技能调出好效果：正文指令的设计细节

4.1 给模型一份"干活清单"，而不是一段含糊要求

SKILL.md 的正文部分，本质上是一份工作说明书。写得越结构化，模型执行越稳定。我总结了一条核心原则：把任务拆成明确的步骤序列，每一步都给出判断标准和产出要求。

继续用周报技能举例。正文里如果只写"生成周报"，模型很自由，输出什么样全看心情。但如果写成：

1. 从用户输入中提取工作事项，按项目或主题归类。
2. 每类工作提炼出具体进展，用一两句话描述清楚。
3. 识别风险与阻塞项，如果没有则写"无"。

模型就明确知道先做什么、后做什么。步骤化的指令天然适合模型的思维链模式，它按步骤走的时候，每步的输出都会更扎实。

还有一个小技巧：在正文里明确"角色"。你可以在开头写"你是一名项目助理""你是一名资深代码审查员"，这能让模型以对应的专业视角来输出。虽然普通对话里你也可以让它扮演角色，但写进技能里之后，每次触发都会自动带上前置设定，省去重复交代。

4.2 输出格式要"锁死"：模板先行

输出格式是技能设计里最容易被忽略、又最能体现专业度的一部分。格式不写死，模型就会按自己的偏好发挥，同一个技能每次输出都不一样，那就失去了用 Skills 的意义。

我的做法是：在正文末尾，用"输出格式：加 Markdown 模板"的方式锁死格式。就像周报技能里那段：

## 本周进展 - [工作项]：[进展描述] ## 风险与阻塞 - [风险描述] 或 无 ## 下周计划 - [计划事项]： [预期结果]

这种写法有两个好处：一是告诉模型输出的整体结构，二是中括号里的占位文本本身就是"提示"，告诉它每一项该填什么样的内容。模板可以设计得很细，包括标题层级、列表符号、表格字段，全部按你的标准来。

如果你有现成的历史文档，比如以前写过一份很满意的周报，直接把它整理成模板放到正文里。这样产出就会和你之前的风格完全一致，几乎不需要后期修改。

4.3 资源文件怎么组织：把素材和模板放进技能文件夹

有些技能除了指令，还需要配套资源。举例来说，你做一个"产品文案生成"技能，希望它每次按特定品牌风格写文案，那你可以在技能文件夹里放一个brand-style.md，里面写清楚品牌口吻、禁用词汇、参考案例。

放好之后，在 SKILL.md 正文里这样引用：

在创作文案前，先阅读同目录下的 brand-style.md 文件，严格遵循其中的品牌规范。

Claude 在触发技能时，会查看技能目录下的相关文件，并根据你的指示去读取和遵循。这种方式非常适合封装那些"经验性内容"：你的写作方法、品牌的调性总结、常见错误清单等。

目录结构类似这样：

~/.claude/skills/copywriter/ ├── SKILL.md └── brand-style.md

资源文件能大大扩展一个技能的能力边界。同样一个文案技能，配上不同品牌的风格文件，就能服务不同的产品线，而 SKILL.md 本身不需要改动。

5. 拿来即用：四类高频技能实操案例

5.1 案例一：每周周报助手

这个技能就是前面示例的完整版，适合每周都要写汇报的人。把工作记录丢给它，它帮你整理成统一格式。

--- name: weekly-report description: 当用户需要根据工作记录生成周报、整理本周工作内容、汇报本周进展时使用。接收用户提供的原始记录，输出结构化周报。 --- # 周报生成 你是一名项目助理，请根据用户提供的工作记录生成周报。严格按以下步骤执行： 1. 从用户输入中提取工作事项，按项目或主题归类。 2. 每类工作提炼出具体进展，用一两句话描述清楚。 3. 识别风险与阻塞项，如果没有则写"无"。 4. 基于当前进展提出下周的工作计划。 输出格式： ## 本周进展 - [工作项]：[进展描述] ## 风险与阻塞 - [风险描述] 或 无 ## 下周计划 - [计划事项]： [预期结果]

这个技能我已经用了十几周，稳定输出，每次交付基本不用改。你甚至可以再加一个要求："进展描述不超过 20 字"，防止它把每项工作写成长篇大论。

5.2 案例二：会议纪要整理器

开会一小时，记录三行字，回头要写纪要想半天。这个技能解决的是：把零散的语音转文字或随手记的要点，整理成结构化的会议纪要。

--- name: meeting-notes description: 当用户需要整理会议记录、生成会议纪要、梳理会议结论和待办事项时使用。接收会议原文或要点，输出结构化纪要。 --- # 会议纪要整理 你是一名会议记录专员。将用户提供的会议内容整理成会议纪要，执行以下操作： 1. 提取会议主题、参会角色和核心议题。 2. 将讨论内容按议题分类，每类总结出关键讨论点和结论。 3. 明确每一项待办事项：事项内容、负责人（如原文未提及则写"待确认"）、截止时间（如未提及则写"待定"）。 输出格式： ## 会议主题 [主题名称] ## 关键结论 - [议题]：[结论] ## 待办事项 - [事项] 负责人：[姓名/待确认] 截止：[日期/待定]

实际使用中，我通常把腾讯会议的转写文本直接贴进去，一分钟内就能得到一份干净清晰的纪要草稿，比手动整理省下至少半小时。

5.3 案例三：文章观点提炼与改写

做内容的人经常要处理长文章，提取核心观点、换一种写法、做摘要。这个技能把"处理文章"的常见动作封装在一起。

--- name: article-refiner description: 当用户需要提炼文章核心观点、改写段落、缩写长文、生成摘要时使用。接收文章原文，输出结构化结果。 --- # 文章观点提炼与改写 你是一名资深内容编辑。根据用户提供的文章，按需执行以下操作： 1. 提炼全文核心观点，列出 3 到 5 条关键信息。 2. 对文章进行分段摘要，每段一段话。 3. 如用户提出改写要求，保留原意，调整语气为更口语化的表达。 输出格式： ## 核心观点 - [观点一] - [观点二] ## 分段摘要 [段落内容摘要] ## 改写版本 [口语化改写后的全文]

这个技能厉害在"多用途合一"：喂一篇文章，既能拿到观点列表，又能拿到摘要，还可以顺便让它改成发朋友圈的口吻。适合做自媒体、写文案、做课程笔记的人。

5.4 案例四：代码审查员

开发者向的福利技能。把一段代码贴给它，它会按一套固定的审查维度去检查，输出问题列表。比临时让它"看看这段代码"要稳定得多。

--- name: code-reviewer description: 当用户需要审查代码、检查代码质量、寻找潜在缺陷时使用。接收代码片段，输出审查意见。 --- # 代码审查 你是一名资深软件工程师。对用户提供的代码进行审查，按以下维度检查： 1. 正确性：是否存在逻辑错误、边界条件遗漏、空指针风险。 2. 健壮性：异常处理是否完善，输入校验是否充分。 3. 可读性：命名是否清晰，函数是否过长，是否需要拆分。 4. 性能：是否存在不必要的计算、循环内重复操作等。 输出格式： ## 问题列表 - [严重程度（高/中/低）] [问题描述] 位置：[代码位置] ## 优化建议 - [具体建议] ## 总体评价 [两到三句话总结代码质量]

开发者定期拿它过一遍代码，能明显感觉到交付质量的提升。它不会替代真正的代码审查，但可以帮你提前发现一堆低级问题。

6. 踩坑记录：常见问题与排查思路

6.1 技能完全不被触发，怎么办

最典型的现象：你描述需求后，模型的输出看着挺正常，但完全没有按 SKILL.md 里的格式来，说明它压根没读到这个文件。

按这个顺序排查：

1. 确认文件路径正确。全局技能放~/.claude/skills/，项目技能放项目目录下的.claude/skills/，别放反了。
2. 确认目录结构正确。技能文件夹内直接放 SKILL.md，不要多套一层。比如~/.claude/skills/my-skill/SKILL.md是正确的，~/.claude/skills/my-skill/docs/SKILL.md是读取不到的。
3. 确认文件名正确。必须叫SKILL.md，大小写也要对上。写成skill.md或者Skill.md都不行。
4. 确认 frontmatter 完整。开头的---不能丢，name和description两个字段必须都有。漏了---会直接导致整个文件解析失败。

还有一点很隐蔽：如果你改了 SKILL.md 之后，技能一直没变化，可以新开一个对话窗口。某些情况下模型会缓存对话上下文，旧窗口里可能沿用旧指令，新窗口干净环境下重新测试最准。

6.2 description 引起误调用或调用失败

description 写得太宽泛，会导致用户只是随口说一句话，模型也强行去触发技能。比如你写"处理文字相关任务"，那用户问任何文字问题都会触发这个技能，反而干扰正常回答。

正确做法是把触发条件收敛到精确范围。你希望它在什么需求出现时介入，就写什么需求。另外，description 里尽量去覆盖用户可能用的自然说法，你覆盖得越全，一次命中率越高。

我自己的习惯是写完 description 后自己读一遍，问自己一个问题："如果我是用户，说哪句话时会希望这个功能出现？" 如果这句话隐约对得上，描述就合格；如果有模糊地带，继续修。

6.3 多个技能功能重叠，优先级怎么处理

技能装多了会撞车。比如你有一个"会议纪要整理器"，又有一个"待办事项提取器"，用户贴一段会议记录说"帮我整理一下"，两个技能的描述都能对上，模型只能二选一，选错就尴尬。

解决思路有两个方向：

一是合并技能。把相关的功能放进同一个 SKILL.md，用条件分支处理不同子需求。比如会议纪要技能里可以加一句："如果用户只要求提取待办，则只输出待办清单，省略其他板块。"

二是把描述写得更精细，做明确的边界划分。比如"会议纪要整理器"描述里写"需整理完整会议信息时使用"，"待办事项提取器"描述里写"当用户仅需提取任务清单、不关心会议背景时使用"。边界清楚了，模型匹配时就不容易糊涂。

6.4 文件编码和格式的坑

SKILL.md 本质是文本文件，但有几个细节不处理会出问题：

第一，文件编码建议保存为 UTF-8。如果你的编辑器默认是 GBK 这类编码，中文内容可能变成乱码，模型读到乱码指令，行为就不可控。写中文技能时，保存的时候留意一下编码选项。

第二，frontmatter 里的冒号后面要有空格。YAML 格式里name: weekly-report的冒号后面那个空格别省略，写成name:weekly-report会解析失败。

第三，正文里的特殊符号。如果你的指令里有大段代码示例，注意代码块标记要配对，别只开不闭。模型解析指令时比人更较真，格式不完整它会漏读后半段。

我遇到过一个很折腾的问题：某个技能文件里写了一个表格，表格的竖线符号没对齐，模型读完之后输出就一直格式混乱，最后我把表格删掉换成分点列表，问题立刻消失。遇到诡异表现，优先怀疑文件格式。

最后说几句实操体会

Skills 这东西，我用了这段时间最大的感受是：它把"调教 AI"这件事从一次性变成可积累的。今天调好的技能，明天还用得上，下周还能改进，慢慢就有了一套属于自己的"专属工具库"。

如果你现在想让 AI 做重复性工作，我建议从一个最小技能开始，比如周报或者纪要。先建出来，跑两轮，感觉哪里输出不顺手就回去改 SKILL.md 的文字，半小时的投入换来的便利是长期的。

另外分享一个小技巧：别贪多。一个技能只专注做一件事，做透比做大重要。我最初尝试做一个"全能助手"技能，什么都往里塞，结果模型经常忽略后面的指令，输出反而不稳定。拆成四五个专注的小技能之后，每个都灵得很。你先从一两个开始，跑顺了，自然就知道哪些技能值得做成自己的常用装备。