企业官网建设流程全解析

1. 从零理解 Claude Skills 到底是什么

1.1 一个被低估的能力扩展机制

Claude Skills 是 Anthropic 为 Claude 模型引入的一套能力扩展机制。简单说，它允许你把一套可复用的指令、脚本和资源打包成一个“技能包”，让 Claude 在需要的时候自动加载并执行。你可以把它理解成给 Claude 装了一个“插件系统”——但这个插件不是代码层面的 API 调用，而是以文件目录的形式存在，Claude 在运行时按需读取。

我第一次接触这个概念的时候，直觉反应是“这不就是系统提示词的模块化版本吗”。用下来发现远不止如此。系统提示词是全局的、静态的，你写多少它就吃多少上下文；而 Skills 是按需加载的，Claude 先看到技能的元数据（名称和描述），判断当前任务是否需要这个技能，需要才去读取完整的 SKILL.md 文件。这个设计直接解决了上下文窗口被大量无关指令占满的问题。

它解决的核心痛点有三个。第一，上下文效率。你不需要把所有能力说明都塞进系统提示词里，Claude 自己会判断什么时候该加载什么。第二，可组合性。不同技能之间可以独立开发、独立维护，互不干扰。第三，可分发性。一个技能包就是一个文件夹，你可以直接拷贝给别人用，不需要改任何代码。

适合谁来参考？如果你已经在用 Claude 做日常开发、文档处理、数据分析或者任何重复性工作，Skills 能帮你把这些工作流固化下来。如果你只是偶尔问 Claude 几个问题，那暂时用不上。但如果你发现自己每天都在给 Claude 写类似的提示词，那就是时候把它们封装成 Skill 了。

1.2 Skills 和传统提示词工程的根本区别

传统提示词工程的核心逻辑是“把所有可能用到的信息都塞进上下文”。你写一个系统提示词，里面包含角色设定、输出格式要求、注意事项、示例等等。问题是，当你需要 Claude 同时具备多种能力时，系统提示词会膨胀到几千甚至上万 token，其中大部分内容在当前对话中根本用不到。

Skills 的思路完全不同。它采用的是渐进式披露（progressive disclosure）策略。Claude 启动时只加载所有技能的元数据——每个技能就一行名称加一行描述，几十个技能加起来可能也就几百 token。当用户的请求匹配到某个技能的描述时，Claude 才会去读取那个技能的完整 SKILL.md。如果技能里还引用了其他文件（比如参考文档、脚本模板），Claude 会在真正需要的时候再去读那些文件。

这个机制的好处是显而易见的。你可以同时挂载几十个技能，但实际消耗的上下文只跟你当前任务相关的技能有关。我实测下来，一个包含 20 个技能的环境，在单次对话中通常只会触发 1 到 3 个技能，上下文占用比把所有技能说明写进系统提示词少了 80% 以上。

另一个关键区别是文件系统的介入。Skills 不仅仅是文本指令，它还可以包含脚本文件、模板文件、参考数据等。Claude 可以读取这些文件，甚至执行其中的脚本（在允许的工具范围内）。这意味着你可以把一些确定性的计算逻辑写成 Python 脚本放在技能包里，让 Claude 调用脚本而不是自己“心算”，大幅提高结果的准确性。

2. 技能包的文件结构与核心组成

2.1 一个标准技能包的目录长什么样

一个 Claude Skill 的最小结构非常简单，就是一个文件夹加一个 SKILL.md 文件。但在实际使用中，为了发挥完整能力，通常会包含以下几类文件：

my-skill/ ├── SKILL.md # 必需，技能的主描述文件 ├── scripts/ # 可选，存放可执行脚本 │ ├── process.py │ └── validate.sh ├── references/ # 可选，存放参考文档 │ └── api-spec.md ├── assets/ # 可选，存放模板、配置等静态资源 │ └── template.json └── examples/ # 可选，存放使用示例 └── sample-input.md

SKILL.md 是整个技能的核心。它由两部分组成：YAML frontmatter和Markdown 正文。Frontmatter 里必须包含name和description两个字段，这两个字段就是 Claude 在“扫描”阶段能看到的全部信息。正文部分则是技能被激活后 Claude 会读取的详细指令。

我建议把 scripts 目录下的脚本写得尽量独立、无副作用。原因是 Claude 调用脚本时，传入的参数和运行环境可能跟你本地测试时不完全一样。脚本最好只依赖标准库，输入输出都用明确的格式（比如 JSON），这样出问题的概率最小。

references 目录适合放那些“Claude 可能需要查阅但不是每次都需要”的内容。比如你做一个 API 对接的技能，可以把 API 的完整参数文档放在 references 里，SKILL.md 正文只写“需要查询具体参数时请阅读 references/api-spec.md”。这样又一次利用了渐进式披露的思路。

2.2 SKILL.md 的 frontmatter 怎么写才有效

Frontmatter 里的description字段是整套机制里最关键的几个字。Claude 就是靠这个描述来判断“当前任务是否需要加载这个技能”。写得好，技能触发准确；写得不好，要么该触发的时候不触发，要么不该触发的时候乱触发。

我总结了一个 description 的写作公式：能力动词 + 处理对象 + 适用场景 + 不适用场景。举个例子：

--- name: csv-data-cleaner description: > 清洗和转换 CSV 数据文件。适用于处理包含缺失值、格式不一致、 编码混乱的表格数据。当用户需要合并多个 CSV、统一列格式、 或做基础数据校验时使用。不适用于复杂的统计分析或可视化任务。 ---

这个描述里，“清洗和转换 CSV 数据文件”说明了能力，“包含缺失值、格式不一致、编码混乱”说明了处理对象，“合并多个 CSV、统一列格式、做基础数据校验”说明了适用场景，“不适用于复杂的统计分析或可视化”划定了边界。实测下来，这种写法的触发准确率明显高于只写一句“处理 CSV 文件”。

注意：description 不要写得太短，也不要写得太长。太短了 Claude 判断不准，太长了浪费元数据扫描阶段的上下文。我的经验是控制在 50 到 150 个中文字之间比较合适。

2.3 正文指令的组织逻辑

SKILL.md 的正文部分，我建议按照“目标 → 步骤 → 约束 → 示例”的结构来组织。先说清楚这个技能要达成什么目标，然后给出推荐的操作步骤，接着列出必须遵守的约束条件，最后附上一两个简短的示例。

为什么要这个顺序？因为 Claude 读取技能文件后，会按照你给的逻辑来规划执行路径。如果目标不清晰，它可能会走偏；如果步骤不明确，它可能会自己发明一套流程；如果约束不写清楚，它可能会做出你不期望的操作。

约束条件这部分特别重要。比如你做一个文件处理的技能，必须明确写“不要删除原始文件”“所有输出文件放在 output 目录下”“遇到无法解析的行跳过并记录到 error.log”。这些约束看起来是常识，但如果不写，Claude 在某些情况下确实会做出不同的选择。

示例部分不需要太长，一两个输入输出的对照就够了。示例的作用不是教 Claude 怎么做（步骤已经写了），而是给它一个“格式锚点”，让它知道输出应该长什么样。

3. 从零构建一个可用的 Skill：完整实操

3.1 确定技能边界与命名

动手写之前，先想清楚一件事：这个技能到底负责什么，不负责什么。我见过太多人一开始就想做一个“万能助手”技能，结果写出来的东西又长又杂，触发率极低，效果也不好。

正确的做法是单一职责。一个技能只做一件事，把这件事做到极致。比如“把 Markdown 转换成带样式的 HTML”就是一个好技能，“处理所有文档格式转换”就是一个坏技能。

命名也有讲究。name字段用英文小写加连字符，要能一眼看出功能。description用中文写（如果你的主要使用场景是中文），因为 Claude 对中文描述的理解同样准确，而且你自己维护起来更直观。

我一般会先列一个清单：这个技能需要接收什么输入？产生什么输出？中间需要哪些步骤？有哪些边界情况需要处理？这个清单列完，技能的边界基本就清楚了。

3.2 编写 SKILL.md 的实操示范

假设我们要做一个“周报生成器”技能，接收一周的工作记录，输出格式化的周报。下面是我实际会写的 SKILL.md：

--- name: weekly-report-generator description: > 根据零散的工作记录生成结构化周报。适用于用户提供每日工作条目、 会议记录、任务完成情况等原始素材，需要整理成规范周报的场景。 输出包含本周完成、进行中、下周计划、风险与阻塞四个板块。 不适用于月报、季报或项目总结报告。 --- # 周报生成器 ## 目标 将用户提供的零散工作记录整理成结构化周报，确保信息不遗漏、 分类准确、语言简洁专业。 ## 步骤 1. 阅读用户提供的所有原始记录，识别每条记录的类型 （已完成任务、进行中任务、计划任务、风险项）。 2. 按照四个板块分类整理：本周完成、进行中、下周计划、风险与阻塞。 3. 每个条目用一句话概括，以动词开头，不超过 40 字。 4. 如果原始记录中有数据指标（如完成率、耗时），保留在对应条目中。 5. 按以下格式输出： ## 本周完成 - [条目1] - [条目2] ## 进行中 ... ## 约束 - 不要编造原始记录中不存在的信息。 - 如果某个板块没有对应内容，写“无”而不是省略该板块。 - 不要添加评价性语言（如“表现出色”“进展顺利”）。 - 保持原始记录中的专有名词不变。 ## 示例 输入： 周一完成了用户登录模块的联调，周二周三在改支付接口的 bug， 周四开了需求评审会，下周一要开始做数据导出功能。 支付接口那边还差一个第三方回调没对接，有延期风险。 输出： ## 本周完成 - 完成用户登录模块联调 - 修复支付接口相关缺陷 - 参加需求评审会 ## 进行中 - 支付接口第三方回调对接 ## 下周计划 - 启动数据导出功能开发 ## 风险与阻塞 - 支付接口第三方回调未完成，存在延期风险

这个 SKILL.md 写完之后，放到~/.claude/skills/weekly-report-generator/SKILL.md（具体路径取决于你使用的客户端），Claude 就能在检测到相关任务时自动加载。

3.3 脚本文件的编写与调用

有些技能需要确定性的计算或处理，这时候光靠 Claude 的“推理”不够可靠，最好写一个脚本让 Claude 调用。比如上面周报技能里，如果需要对工作条目做去重和排序，写一个 Python 脚本会比让 Claude 自己判断更稳定。

脚本放在scripts/目录下，在 SKILL.md 里用相对路径引用。我一般会在 SKILL.md 里写清楚脚本的调用方式和参数格式：

## 可用脚本 - `scripts/dedup.py`：对工作条目去重。用法： `python scripts/dedup.py --input items.json --output deduped.json` 输入输出均为 JSON 数组，每个元素是一个字符串。

脚本本身要写得健壮一些。我踩过的坑是：脚本在本地测试时用的是 Python 3.11，但某些运行环境可能是 3.9，用了新语法就会报错。所以脚本尽量用兼容性好的写法，避免使用太新的语言特性。

另外，脚本的输入输出最好用文件而不是标准输入输出。原因是 Claude 调用脚本时，通过文件传递数据更可靠，也方便调试。如果脚本执行失败，Claude 可以读取错误输出并尝试修复，这比标准输入输出的交互模式要稳定得多。

4. 技能触发机制与调试方法

4.1 Claude 是怎么“决定”加载哪个技能的

理解触发机制是调试技能的关键。Claude 在每次对话开始时，会扫描所有已安装技能的name和description，形成一个“技能索引”。当用户发出请求时，Claude 会根据请求内容与技能描述的匹配程度，决定是否加载某个技能的完整内容。

这个匹配过程不是简单的关键词匹配，而是语义级别的判断。举个例子，你的技能描述里写的是“处理 CSV 数据”，用户说“帮我整理一下这个表格文件”，Claude 仍然能匹配到，因为它理解“表格文件”和“CSV 数据”在语义上的关联。

但这也意味着，如果你的描述写得太窄，可能会漏掉一些本该触发的场景；写得太宽，又会在不该触发的时候触发。我的一般原则是：描述里覆盖 80% 的常见说法，剩下 20% 的边缘情况靠正文里的说明来兜底。

还有一个细节：Claude 在一次对话中可以加载多个技能。如果你的任务同时涉及数据清洗和图表生成，而这两个功能分别在不同的技能里，Claude 会依次加载它们。所以技能之间的职责划分要清晰，不要有重叠，否则可能出现两个技能都被加载但指令冲突的情况。

4.2 调试技能触发的实用技巧

调试技能触发问题，我常用的方法是在 SKILL.md 的正文开头加一行“调试标记”，比如：

# 周报生成器 <!-- DEBUG: weekly-report-generator loaded -->

这样当你不确定技能是否被加载时，可以问 Claude“你当前加载了哪些技能”，如果它读取了这个文件，就会看到这行注释并可能提及。当然更直接的方法是看客户端的日志，但不同客户端的日志详细程度不一样，这个方法作为补充挺有用的。

另一个技巧是故意制造边界情况。比如你的技能描述里写了“不适用于月报”，那你就试着让 Claude 生成月报，看它是否会错误地加载这个技能。如果加载了，说明你的“不适用”描述不够明确，需要加强。

我还建议在技能刚写完的时候，用五到十个不同的请求来测试触发情况，覆盖典型场景、边缘场景和完全不相关的场景。记录下哪些触发了、哪些没触发，然后针对性地调整 description。

4.3 常见触发问题与修复对照表

这张表是我在实际调试中慢慢积累出来的，基本上覆盖了 90% 以上的触发问题。每次遇到新问题，我会先对照这张表排查，大部分情况下都能找到原因。

5. 进阶技巧：让技能更可靠、更高效

5.1 用“检查清单”模式减少遗漏

Claude 在执行多步骤任务时，偶尔会漏掉某个步骤，尤其是在步骤比较多的情况下。我在技能正文里加入“检查清单”模式后，这个问题明显改善了。

具体做法是在步骤描述的最后，加一个“完成前检查”小节：

## 完成前检查 在输出最终结果之前，确认以下事项： - [ ] 所有四个板块都已包含 - [ ] 每个条目以动词开头 - [ ] 没有编造原始记录中不存在的信息 - [ ] 专有名词与原始记录一致

这个检查清单不需要很长，四到六项就够了。关键是每一项都必须是可验证的，不能写“确保质量良好”这种模糊的要求。Claude 会逐项核对，漏掉的可能性大大降低。

5.2 版本管理与迭代策略

技能不是写完就完了，需要持续迭代。我建议在技能目录下放一个CHANGELOG.md，记录每次修改的内容和原因。这样做的好处是，当你发现技能行为发生变化时，可以快速定位是哪次修改导致的。

版本号我一般用简单的日期标记，比如2025-01-15。不需要搞语义化版本那一套，因为技能的“接口”就是 description 和正文指令，很难用 major/minor/patch 来区分。

迭代的时候，一次只改一个地方。比如你觉得触发不够准确，就只改 description，改完测试一轮。如果同时改了 description 和正文步骤，测试结果不好时你就不知道是哪个改动导致的。这个原则跟写代码时调试 bug 是一样的。

5.3 技能组合使用的注意事项

当你同时使用多个技能时，有几个坑需要注意。第一，指令冲突。如果技能 A 说“输出用 JSON 格式”，技能 B 说“输出用 Markdown 表格”，Claude 可能会困惑。解决办法是在技能正文里明确写“如果同时加载了其他输出格式相关的技能，以本技能的格式要求为准”，或者干脆在设计时就避免这种冲突。

第二，加载顺序。Claude 加载技能的先后顺序可能影响最终行为。我的一般建议是，把“基础性”的技能（比如数据读取、格式解析）和“应用性”的技能（比如报告生成、图表绘制）分开，在应用性技能的正文里写明“假设基础数据已经准备好”。

第三，上下文预算。虽然 Skills 机制本身很节省上下文，但如果你同时加载了多个大型技能，上下文占用还是会上去。我的经验是，单次对话中加载的技能总正文长度控制在 3000 字以内比较稳妥，超过这个量就可能影响 Claude 对其他指令的响应质量。

6. 实际使用中踩过的坑与解决方案

6.1 脚本执行权限问题

这个问题我遇到过好几次。脚本在本地测试时运行正常，但 Claude 调用时报“权限不足”。原因是脚本文件没有可执行权限，或者运行环境的用户与本地不同。

解决办法有两个：一是在 SKILL.md 里明确写调用命令为python scripts/xxx.py而不是./scripts/xxx.py，这样不依赖可执行权限；二是在技能包里附一个setup.sh，让用户在安装技能时运行一次，设置好权限。

我更推荐第一种方法，因为它不依赖用户的额外操作。写调用命令时统一用解释器前缀，比如python、node、bash，这样最稳妥。

6.2 中文编码问题

处理中文文本时，编码问题几乎一定会遇到。脚本读取文件时如果没指定编码，在某些系统上会默认用 ASCII 或 Latin-1，导致中文乱码。

我的做法是在所有脚本里强制指定 UTF-8 编码：

with open(input_path, 'r', encoding='utf-8') as f: content = f.read()

输出时也一样：

with open(output_path, 'w', encoding='utf-8') as f: f.write(result)

另外，在 SKILL.md 里也提醒一句“所有文件读写均使用 UTF-8 编码”，这样 Claude 在生成临时文件时也会注意编码问题。

6.3 技能描述被忽略的情况

有时候 Claude 明明加载了技能，但没有按照技能里的指令执行。这种情况通常是因为技能正文太长，关键指令被“淹没”了。

解决办法是把最重要的指令放在正文的最前面，并且用加粗或引用块突出。比如：

> 重要：输出必须使用 Markdown 表格格式，不要使用其他格式。 ## 步骤 ...

Claude 对正文开头和突出标记的内容注意力更高。把关键约束放在这些位置，执行准确率会明显提升。

6.4 多轮对话中的技能保持问题

在多轮对话中，Claude 不一定会在每一轮都重新加载技能。如果第一轮加载了某个技能，第二轮用户换了一个话题，Claude 可能会“忘记”之前加载的技能内容。

这个问题的根源是上下文管理机制。解决办法是在技能正文里写清楚“本技能适用于整个对话过程，即使后续话题变化，之前加载的技能指令仍然有效”。当然，更可靠的做法是让用户在切换话题时明确说“继续使用之前的技能”或“换一个技能”。

我在实际使用中，如果发现多轮对话中技能行为不一致，会主动提醒 Claude“请重新读取 xxx 技能的指令”。这虽然多了一步操作，但能保证行为的一致性。

6.5 技能包分发的兼容性问题

当你把自己写的技能包分享给别人时，最常见的问题是路径依赖。你的 SKILL.md 里如果写了绝对路径，别人拿到后路径对不上，技能就废了。

所以从一开始就要用相对路径。所有对脚本、参考文件、模板的引用都相对于技能包的根目录。比如写scripts/process.py而不是/home/user/skills/my-skill/scripts/process.py。

另外，在技能包里放一个简短的README.md，说明这个技能的用途、依赖项（比如需要 Python 3.9+）、安装方法。这样别人拿到后能快速上手，不需要来问你。

7. 技能设计的经验法则

7.1 从“我每天重复做什么”开始

如果你不知道第一个技能该做什么，就回想一下过去一周你给 Claude 发的重复性请求。是不是每天都在让它帮你格式化某种数据？是不是每次都要给它同样的背景说明？是不是总在纠正它同样的错误？

这些重复性的模式就是最好的技能候选。把它们固化下来，你以后就不需要每次都写一遍了。我自己的第一个技能就是“把会议记录整理成待办事项”，因为每周开会后我都要做这件事，每次给 Claude 的指令都差不多。

7.2 先写“手动版”，再改“自动版”

不要一上来就追求完美的自动化。先手动写一遍完整的指令，用几次，看看效果。效果稳定了，再把它整理成 SKILL.md 的格式。

这样做的好处是，你在手动阶段就已经发现了哪些指令有效、哪些无效、哪些边界情况需要处理。这些经验直接反映到技能文件里，比凭空想象要靠谱得多。

7.3 保持技能“薄”而“准”

一个技能不要试图覆盖太多场景。我见过有人写了一个“文档处理”技能，里面包含了格式转换、内容摘要、翻译、校对等一堆功能。结果就是 description 怎么写都不对，触发率很低，加载后正文又太长，Claude 执行时经常顾此失彼。

正确的做法是拆成多个技能：doc-format-converter、doc-summarizer、doc-translator、doc-proofreader。每个技能只做一件事，description 精准，正文简短，触发准确，执行可靠。

7.4 定期清理不再使用的技能

技能装多了，元数据扫描阶段的上下文占用也会增加。虽然每个技能的元数据不多，但几十个技能加起来也不容忽视。我一般每季度清理一次，把过去三个月没触发过的技能归档或删除。

判断一个技能是否还有用，可以看它的触发频率。如果一个技能一个月都没被触发过，要么是 description 写得有问题，要么是这个需求本身就不常出现。前者需要修复，后者可以考虑删除。

8. 关于技能生态的一些个人观察

Claude Skills 这个机制目前还在快速演进中。从我自己的使用体验来看，它最大的价值在于把“提示词工程”从一种手工艺变成了可管理、可复用、可分发的工程实践。以前你写一个好用的提示词，只能自己用，或者复制粘贴给别人；现在你可以把它打包成技能，别人安装即用。

另一个有意思的变化是，技能让“非程序员”也能扩展 Claude 的能力。你不需要会写 API 调用、不需要理解函数签名，只需要会写 Markdown 和（可选的）简单脚本，就能做出一个实用的技能。这降低了很多门槛。

不过也要看到局限性。技能目前主要解决的是“指令复用”和“流程固化”的问题，对于需要复杂外部交互（比如调用第三方 API、访问数据库）的场景，还是需要配合其他机制来实现。技能里的脚本可以做一些本地处理，但涉及网络请求和认证的部分，还是得靠更完整的集成方案。

我个人的做法是把技能当作“工作流模板”来用。那些我反复执行的、步骤固定的、输入输出格式明确的任务，统统做成技能。而那些一次性的、探索性的、需要灵活调整的任务，还是直接对话解决。这个分界线目前来看挺清晰的，用起来也顺手。

最后分享一个小技巧：如果你在团队里使用 Claude，可以把团队共用的技能放在一个共享目录里，每个人安装后都能用。这样团队里的“最佳实践”就能以技能的形式沉淀下来，新成员入职时安装几个技能，就能快速对齐工作方式。这比写文档要有效得多，因为技能是“活”的，Claude 会直接按照它来执行。