企业官网建设流程全解析

1. 从“skills”这个热词说起：它到底是什么，为什么突然火了

最近几个月，不管是在技术社区还是各种开发者群里，“skills”这个词出现的频率高得离谱。很多人第一次看到它，会以为是某种新出的编程语言或者框架，其实不是。这里的skills，特指围绕 Claude 生态（尤其是 Claude Code、Claude Desktop 这类工具）构建的一套可复用的能力模块机制。你可以把它理解成给 AI 助手装的“技能插件”——每个 skill 就是一份结构化的说明文件，告诉模型在特定场景下该怎么思考、该调用什么工具、该遵循什么流程。

我最早接触这个概念，是因为身边做前端的朋友在群里晒他的SKILL.md文件，说配好之后 Claude Code 写 React 组件的风格突然就“对味”了。后来自己上手折腾了一段时间，才发现这东西的价值远不止“让 AI 听话”这么简单。它真正解决的是一个老问题：通用大模型什么都会一点，但在具体领域里总差那么一口气。skills 就是把这“一口气”补上的手段。

这篇文章适合几类人看：一是刚听说 Claude Code、想搞清楚 skills 到底怎么用的新手；二是已经在用 Claude 但觉得输出不够稳定、想通过 skills 做定制的老用户；三是做数学建模、前端开发、AI 内容创作这类具体工作，想找现成 skills 直接抄作业的从业者。我会从设计思路讲到实操细节，再到踩过的坑，尽量把我知道的都倒出来。

需要先说明一点：skills 不是某个官方垄断的东西，它的核心就是一份 Markdown 格式的说明文件（通常叫SKILL.md），加上可选的辅助脚本和资源。这意味着它的门槛极低，你不需要会写复杂的代码，只要能把“我希望 AI 在这个场景下怎么做”用清晰的语言描述出来，就能做出一个能用的 skill。这也是它能在短时间内爆发的根本原因。

2. skills 的整体设计思路：为什么是 Markdown，而不是插件系统

2.1 核心机制拆解：一份文件如何改变模型行为

要理解 skills 为什么这么设计，得先明白大模型的一个基本特性：它对上下文里的指令极其敏感。你在对话开头塞一段“你是一个资深前端工程师，写代码时优先使用函数式组件”的说明，模型的输出风格立刻就会变。skills 本质上就是把这个“塞说明”的动作标准化、持久化了。

一个典型的 skill 目录结构大概是这样：

my-skill/ ├── SKILL.md # 核心说明文件，必须有 ├── scripts/ # 可选，放辅助脚本 │ └── helper.py └── resources/ # 可选，放参考文档、模板 └── template.md

SKILL.md是整个 skill 的灵魂。它通常包含几个部分：元信息（名称、描述、适用场景）、行为指令（模型应该遵循的规则）、工具调用说明（如果需要调用外部工具）、示例（输入输出样例）。模型在加载这个 skill 后，会把这些内容作为系统级上下文的一部分，从而在后续对话中持续遵循。

为什么用 Markdown 而不是 JSON 或 YAML？我的理解是，Markdown 对模型来说是最“自然”的格式。大模型的训练数据里充斥着大量 Markdown 文档，它对标题层级、列表、代码块的理解非常到位。你用 Markdown 写指令，模型几乎不会误读；换成严格的 JSON schema，反而可能因为格式问题导致解析失败。这是一个非常务实的选择。

2.2 和其他方案对比：为什么不用传统插件或微调

有人会问，要做定制化，为什么不直接微调模型，或者写一个传统的插件系统？这里有几个现实考量。

微调的成本太高了。且不说需要大量标注数据，光是训练和部署的资源投入，就不是个人开发者能轻松承担的。而且微调后的模型是“死”的，场景一变就得重新训。skills 则是“活”的，改几行文字就能调整行为，迭代成本几乎为零。

传统插件系统（比如某些平台的 function calling）要求你定义严格的接口，模型只能在你划定的框框里调用。skills 更灵活，它不仅能定义工具调用，还能定义思维方式。比如你可以写一个“数学建模 skill”，里面规定模型必须先分析问题类型、再选择模型、最后做敏感性分析。这种流程性的指导，传统插件很难表达。

还有一个关键点：skills 是可组合的。你可以同时加载多个 skill，让模型在不同场景下切换不同的能力。比如一个“前端开发 skill”加一个“代码审查 skill”，写代码时用前者，review 时用后者。这种灵活性是单一微调模型做不到的。

2.3 适用场景判断：什么时候该写 skill，什么时候不该

不是所有场景都值得写 skill。我的经验是，满足以下条件之一才考虑：

• 重复性高：同一个任务你会反复让 AI 做，比如每周都要生成周报、每次都要按固定格式写组件。
• 要求稳定：你对输出格式、风格有严格要求，不能每次都不一样。
• 有领域知识：任务涉及特定领域的规则、术语、流程，通用模型容易出错。

反过来，如果只是一次性的、探索性的任务，直接对话就行，没必要写 skill。写 skill 本身也是要花时间的，别为了用而用。

3. 核心细节解析：一个高质量 SKILL.md 该怎么写

3.1 元信息部分：名称和描述决定模型会不会用对

元信息看起来简单，其实很关键。模型在决定是否激活某个 skill 时，主要看的就是名称和描述。名称要具体，不要叫“helper”这种模糊的词，叫“react-component-generator”就清楚多了。描述要写清楚什么时候用，而不是这是什么。

举个例子，差的描述是“这是一个用于生成 React 组件的 skill”。好的描述是“当用户需要创建新的 React 函数式组件、且项目使用 TypeScript 和 Tailwind CSS 时使用此 skill”。后者给了模型明确的触发条件，避免在不该用的时候乱用。

我踩过的一个坑是：早期写 skill 时描述太宽泛，结果模型在任何涉及代码的对话里都试图激活它，反而干扰了正常交流。后来把触发条件写具体，问题就解决了。

3.2 行为指令部分：把“潜规则”显式化

这是 SKILL.md 里最需要花心思的部分。你要把平时靠经验积累的“潜规则”全部写出来。比如写前端组件，你心里知道“不要用 any 类型”“样式优先用 Tailwind 而不是内联”“组件要拆得足够小”，这些都要明确写进指令里。

指令的写法有几个技巧。第一，用肯定句而不是否定句。与其说“不要使用 class 组件”，不如说“始终使用函数式组件配合 Hooks”。模型对肯定指令的遵循度更高。第二，给出理由。模型在理解“为什么”之后，泛化能力会更强。比如“使用 Tailwind 是因为项目统一了设计系统，避免样式碎片化”。第三，分优先级。如果规则很多，标注哪些是必须遵守的，哪些是建议。

一个实用的结构是用三级标题分块：

### 必须遵守 - 始终使用 TypeScript 严格模式 - 组件文件使用 PascalCase 命名 ### 建议做法 - 优先拆分可复用逻辑到自定义 Hook - 样式使用 Tailwind 类名

3.3 示例部分：少而精，覆盖边界情况

示例是模型学习行为模式的重要参考。但不要堆砌大量相似例子，那样反而会让模型抓不住重点。我的做法是给2 到 3 个例子，一个标准情况，一个边界情况，一个错误示范。

错误示范特别有用。你可以写“以下是不推荐的写法”，然后给出反例，再说明为什么不好。模型通过对比，能更准确地理解你的意图。这比单纯说“要这样做”效果好得多。

3.4 工具调用说明：什么时候需要，怎么写

如果你的 skill 需要调用外部工具（比如执行脚本、读取文件），就要在 SKILL.md 里说明。这部分要写清楚：什么时候调用、传什么参数、怎么处理返回值。

比如一个“数据清洗 skill”可能需要调用 Python 脚本：

当用户提供 CSV 文件路径时，调用 scripts/clean_data.py， 传入文件路径作为第一个参数。脚本会返回清洗后的文件路径， 后续分析基于清洗后的数据。

注意不要写得太技术化，模型需要的是“意图层面”的说明，而不是完整的 API 文档。把调用时机和目的说清楚就够了。

4. 实操过程：从零搭建一个可用的 skill

4.1 环境准备：Claude Code 的安装与配置

在写 skill 之前，得先把运行环境搭好。Claude Code 是官方提供的命令行工具，安装方式根据系统不同有所差异。在 macOS 或 Linux 上，通常通过包管理器安装；Windows 用户需要注意，某些功能可能依赖虚拟化平台，安装过程中如果提示需要启用相关组件，按提示操作即可。

安装完成后，第一次运行需要完成认证配置。这里有个常见问题：如果提示命令无法识别，多半是环境变量没配好。检查一下安装路径是否加进了 PATH。另外，部分地区可能遇到服务不可用的情况，这是正常的网络限制，需要自行确认所在区域的支持情况。

配置完成后，你可以通过claude命令进入交互模式。建议先跑一个简单的对话测试，确认基础功能正常，再开始折腾 skills。

4.2 创建第一个 skill：从需求到文件

假设我要做一个“数学建模辅助 skill”，用于比赛时快速生成建模思路。步骤如下：

第一步，确定 skill 的存放位置。Claude Code 通常会在特定目录下查找 skills，具体路径可以在配置文件中查看。一般是用户主目录下的某个隐藏文件夹。

第二步，创建目录和文件：

mkdir -p ~/.claude/skills/math-modeling touch ~/.claude/skills/math-modeling/SKILL.md

第三步，编写 SKILL.md 内容。我会先写元信息，再写行为指令，最后加示例。行为指令部分重点写：先判断问题类型（优化、预测、评价等），再推荐合适的模型，最后要求给出敏感性分析。这些都是数学建模的“套路”，写进去之后模型输出会专业很多。

第四步，测试。重启 Claude Code，在对话里提一个建模问题，观察模型是否按照 skill 的指令来回答。如果没生效，检查文件路径和格式是否正确。

4.3 参数与配置：让 skill 更精准的几个关键点

有几个配置项会显著影响 skill 的效果。触发阈值决定了模型多“积极”地使用这个 skill，设太高会漏用，设太低会滥用。优先级在多个 skill 冲突时起作用，比如同时加载了“简洁回答”和“详细解释”两个 skill，得指定谁优先。

还有一个容易被忽略的点：skill 的加载顺序。后加载的 skill 可能会覆盖先加载的部分指令。如果发现行为不符合预期，可以调整加载顺序试试。

我在配置数学建模 skill 时，特意把“必须给出模型假设”这条放在指令最前面，因为这是建模里最容易被忽略但最重要的部分。实测下来，放在前面的规则被遵循的概率明显更高。

4.4 验证与迭代：怎么判断 skill 写得好不好

写完不是结束，得验证。我的方法是准备一组测试用例，覆盖典型场景和边界场景，每次修改 skill 后都跑一遍，看输出是否稳定。

比如数学建模 skill，我会准备三个问题：一个优化问题、一个预测问题、一个评价问题。好的 skill 应该能让模型对这三类问题都给出结构化的、符合建模规范的回答。如果某一类表现差，就针对性调整指令。

迭代时要注意一次只改一个变量。同时改多处，出了问题都不知道是哪里的锅。改完记录一下改动内容和效果，积累几次之后你就对“什么样的指令有效”有感觉了。

5. 常见问题与排查技巧实录

5.1 skill 不生效的几种典型原因

这是新手最常遇到的问题。根据我的排查经验，原因通常集中在以下几类：

我遇到最多的是路径问题。不同版本的 Claude Code 可能从不同位置读取 skills，建议先查官方文档确认当前版本的约定路径。另外，文件名必须是SKILL.md，大小写敏感，写成skill.md可能识别不了。

5.2 输出不稳定的调试思路

有时候 skill 生效了，但输出时好时坏。这通常是因为指令本身有歧义。比如你写“尽量简洁”，模型对“简洁”的理解可能每次都不一样。改成“回答控制在三句话以内”就明确多了。

另一个原因是上下文干扰。如果对话历史很长，早期的内容可能会稀释 skill 的影响力。解决办法是在关键节点重新强调 skill 的规则，或者开新对话。

还有一个技巧：在 skill 里加入自检指令。比如“在给出最终答案前，确认是否满足以下所有要求”。模型在执行自检时，会更严格地遵循规则。

5.3 多个 skill 冲突时的处理

当你加载了多个 skill，它们之间可能打架。比如一个说“用中文回答”，另一个说“用英文回答”。这时候模型会随机选一个，结果就是不稳定。

处理原则是明确优先级。在配置里指定哪个 skill 优先，或者在 skill 的元信息里标注适用范围。更好的做法是合并相关 skill，把不冲突的部分整合到一个文件里，减少冲突面。

我个人的习惯是，功能相近的 skill 尽量合并，保持加载的 skill 数量在三个以内。太多 skill 不仅容易冲突，还会拖慢响应速度。

5.4 性能与资源占用的注意事项

skill 本身是文本文件，占用资源可以忽略。但如果 skill 里引用了大量外部资源（比如大文件、复杂脚本），就可能影响性能。建议把非必要的资源做成按需加载，不要一股脑塞进 skill 目录。

另外，skill 里的指令越长，消耗的上下文窗口越多。如果你的对话本来就长，再加上冗长的 skill，可能会触及上下文上限。所以指令要精炼，把最重要的规则放在前面。

6. 进阶玩法：让 skills 真正融入工作流

6.1 组合使用：前端开发加代码审查的联动

单独一个 skill 能解决的问题有限，真正提效的是组合。我现在的配置是：一个“前端组件生成 skill”负责写代码，一个“代码审查 skill”负责检查。写完组件后，直接让模型用审查 skill 过一遍，能抓出不少低级问题。

组合的关键是职责清晰。生成 skill 只管生成，审查 skill 只管审查，不要互相越界。如果生成 skill 里也写了审查规则，两边就会重复甚至矛盾。

6.2 团队协作：skill 的共享与版本管理

如果是团队使用，skill 最好纳入版本管理。把 skill 目录放进 Git 仓库，每个人拉取最新版本。这样能保证团队成员的 AI 行为一致，避免“你生成的代码风格和我生成的不一样”这种问题。

共享时要注意脱敏。skill 里可能包含项目特定的路径、密钥、内部规范，共享前检查一遍，别把敏感信息带出去。

6.3 持续优化：根据使用反馈迭代 skill

skill 不是写完就完事的。用一段时间后，你会发现某些指令没效果，某些场景没覆盖到。这时候就迭代。我的习惯是每次遇到不满意的输出，就想想“如果 skill 里加一条什么规则能避免”，然后加上去。

积累几个月后，你的 skill 会越来越贴合自己的需求，变成一个真正个性化的“AI 工作伙伴”。这个过程本身也是对自己工作流程的梳理，挺有意思的。

6.4 从 skills 到个人知识库的延伸

再往深了想，skills 其实可以和个人知识库结合。比如把你常用的代码片段、设计模式、业务规则都整理成 skill 的一部分，模型在需要时就能直接调用。这相当于把你的经验“外化”成了可执行的指令。

我现在维护着一个“个人开发规范 skill”，里面记录了我这些年积累的各种最佳实践。每次开新项目，加载这个 skill，AI 就能按照我的习惯来工作，省去了大量重复解释的时间。这大概就是 skills 这个机制最有价值的地方——它让 AI 真正开始“懂你”。