企业官网建设流程全解析

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

最近几个月，不管是在技术社区还是各种开发者群里，“skills”这个词出现的频率高得离谱。很多人第一次看到它的时候，脑子里冒出来的可能是“技能”这个通用翻译，觉得无非就是某个新概念换了个马甲。但如果你真的动手去用过 Claude 的 Agent Skills，或者看过别人分享的 SKILL.md 文件，就会发现这东西跟传统意义上的“技能”完全不是一回事。

简单来说，Agent Skills 是一套让 AI 助手按照你预设的流程和规范去执行特定任务的机制。它的核心载体是一个叫SKILL.md的 Markdown 文件，里面写清楚了“什么场景下触发”“执行步骤是什么”“有哪些注意事项”“输出格式长什么样”。你可以把它理解成给 AI 写的一份“岗位操作手册”——当用户提出某个需求时，AI 会自动匹配对应的 skill，然后严格按照手册里的流程来干活。

这件事为什么值得关注？因为在此之前，大多数人用 Claude 或者类似工具的方式是“每次重新描述需求”。你想让它帮你做数学建模，你得把建模的流程、注意事项、输出格式从头讲一遍；你想让它帮你写前端组件，你得把项目规范、目录结构、命名约定重新交代一次。每次对话都是从零开始，效率极低，而且输出质量完全取决于你这次描述得够不够细。

Skills 解决的就是这个问题。它把“怎么干这件事”的知识固化下来，变成可复用、可分享、可版本管理的文件。你写一次，以后每次触发这个 skill，AI 都会按照同样的标准来执行。对于需要反复做同类任务的人来说，这个价值是巨大的。

目前 skills 的生态已经相当丰富了。从数学建模、前端开发、代码审查，到 AI 漫剧脚本生成、STM32 嵌入式开发，甚至华为杯建模比赛都有专门的 skill 推荐。社区里有人在 GitHub 上开源自己的 skill 集合，有人专门做 skill 的评测和推荐，还有人把 skill 和 Claude Code、OpenCode 这些工具链打通，形成了一套完整的 AI 辅助工作流。

这篇文章我会从实际使用的角度出发，把 skills 的核心机制、SKILL.md 的写法、安装配置的完整流程、常见问题的排查方法，以及我在实际使用中踩过的坑，全部拆开来讲清楚。不管你是刚听说这个概念的新手，还是已经在用但总觉得哪里不对劲的老用户，应该都能从中找到有用的东西。

2. Skills 的核心机制与设计思路拆解

2.1 为什么是 Markdown 文件而不是代码

很多人第一次接触 skills 的时候会有一个疑问：为什么 skill 的定义文件是 Markdown，而不是 JSON、YAML 或者某种专门的 DSL？这个问题背后其实涉及到一个很关键的设计取舍。

Markdown 最大的优势是对人类友好。你不需要懂任何编程语法就能写一个 skill，只要你会写文档，就能把自己的工作流程描述清楚。这极大地降低了创建 skill 的门槛。一个数学建模的老手，可能完全不懂编程，但他对建模的流程、常见的坑、论文的写法了如指掌，他就可以把这些经验写成 SKILL.md，让 AI 来执行。

另一个原因是Markdown 的灵活性。JSON 和 YAML 适合结构化数据，但 skill 的定义往往需要包含大量的自然语言描述、条件判断、示例说明。用 Markdown 来写，可以用标题分层、用列表列步骤、用代码块放示例、用引用块标注注意事项，表达力比结构化格式强得多。

当然，Markdown 也有它的代价。因为格式太自由，不同人写的 SKILL.md 质量参差不齐。有的人写得像一份完整的操作手册，AI 读了之后执行得非常精准；有的人写得含糊其辞，AI 只能靠猜。这就引出了下一个问题：一个高质量的 SKILL.md 到底应该包含哪些要素。

2.2 SKILL.md 的触发机制与匹配逻辑

Skills 的工作方式并不是“你手动选择一个 skill，然后 AI 执行”。它是自动触发的。当你在对话中提出一个需求时，AI 会根据 skill 的描述信息来判断是否匹配。这就意味着，SKILL.md 里关于“什么时候触发”的描述至关重要。

我见过很多人写的 skill，功能本身没问题，但触发描述写得太模糊，导致要么该触发的时候不触发，要么不该触发的时候乱触发。比如一个专门做“数学建模论文排版”的 skill，如果触发描述只写了“处理文档”，那 AI 可能在你说“帮我改一下这个 Word 文档”的时候就触发了，但实际上你只是想改个错别字，根本不需要走建模论文的排版流程。

一个好的触发描述应该包含三个要素：场景限定、关键词锚定、排除条件。场景限定是说清楚这个 skill 适用于什么类型的任务；关键词锚定是列出用户可能会说的典型表达；排除条件是明确哪些看起来相似但实际上不应该触发的情况。

2.3 Skills 与 Claude Code 的关系

很多人会把 skills 和 Claude Code 混为一谈，其实它们是两个层面的东西。Claude Code 是一个命令行工具，让你可以在终端里跟 Claude 交互，执行代码相关的任务。Skills 是一套机制，让 Claude 能够按照预设流程执行特定任务。两者可以结合使用，但并不是必须绑定。

你可以在 Claude Code 里使用 skills，也可以在 Claude 的网页版或者桌面版里使用。Skills 的本质是一组文件，只要 AI 能够读取到这些文件，就能触发对应的行为。Claude Code 之所以经常和 skills 一起被提到，是因为它提供了一个非常方便的本地文件访问能力，让 skill 的安装和管理变得很简单。

目前社区里流行的做法是：把 skill 文件放在项目的.claude/skills/目录下，或者放在用户主目录的.claude/skills/下。前者是项目级别的，只对当前项目生效；后者是用户级别的，对所有项目生效。这个设计跟 Git 的配置层级很像，项目级覆盖用户级，灵活性很高。

3. 手把手写一个高质量的 SKILL.md

3.1 文件结构的基本骨架

一个标准的 SKILL.md 通常包含以下几个部分。我用一个“数学建模论文写作”的 skill 作为例子来展示，这样更直观。

文件的开头是元信息区域，用 YAML front matter 的格式写。这部分定义了 skill 的名称、描述、触发条件等。名称要简短好记，描述要一句话说清楚这个 skill 是干什么的。触发条件可以是一个或多个关键词，也可以是更复杂的模式匹配。

接下来是正文部分。正文的第一块通常是“角色定义”，告诉 AI 在这个 skill 下应该扮演什么角色。比如数学建模论文写作的 skill，角色定义可能是“你是一位有十年经验的数学建模竞赛指导教师，熟悉国赛和美赛的论文规范”。

然后是“执行流程”，这是整个 SKILL.md 最核心的部分。流程要写得足够细，每一步都要说清楚输入是什么、输出是什么、需要注意什么。我建议用有序列表来写流程，因为顺序很重要。如果某个步骤有分支条件，可以用嵌套列表或者表格来说明。

再往下是“输出规范”，定义最终产出的格式要求。比如论文的章节结构、字体字号、图表编号规则、参考文献格式等。这部分越具体越好，最好能给出一个完整的示例。

最后是“常见问题与注意事项”，把你在这个领域踩过的坑、容易出错的地方列出来。这部分往往是区分一个 skill 好不好用的关键。因为 AI 在执行过程中遇到边界情况时，会参考这部分内容来做判断。

3.2 触发描述怎么写才精准

触发描述写得好不好，直接决定了 skill 的使用体验。我总结了一个“三层过滤”的写法，实测下来效果比较稳。

第一层是领域词。比如“数学建模”“建模竞赛”“国赛”“美赛”这些词，用户只要提到，就大概率是在这个领域里。第二层是动作词。比如“写论文”“排版”“摘要”“参考文献”，这些词说明用户要做具体的任务。第三层是排除词。比如“帮我改个错别字”“调整一下格式”这种轻量级的编辑需求，不应该触发完整的论文写作流程。

把这三层组合起来，触发描述可以写成这样：当用户提到数学建模、建模竞赛、国赛、美赛等关键词，并且涉及论文写作、排版、摘要撰写、参考文献整理等任务时触发。但如果用户只是要求修改错别字或调整简单的格式，不触发此 skill。

这种写法比单纯列几个关键词要精准得多。因为它不仅告诉了 AI“什么时候该触发”，还告诉了 AI“什么时候不该触发”。后者往往比前者更重要，因为误触发会打断用户的正常操作，体验很差。

3.3 执行流程的颗粒度控制

执行流程写多细才合适？这是一个很实际的问题。写得太粗，AI 执行的时候会自由发挥，输出不稳定；写得太细，又会让 skill 变得冗长，维护成本高。

我的经验是：关键决策点要细，常规操作可以粗。什么叫关键决策点？就是那些“如果选错了会导致后面全错”的地方。比如数学建模论文写作中，选题分析的角度、模型假设的合理性、灵敏度分析的方法选择，这些都属于关键决策点，需要给出明确的判断标准和操作指引。

而像“打开文档”“输入标题”这种常规操作，就不需要写得那么细，一句话带过就行。AI 在这些基础操作上不会出错，写太细反而浪费篇幅。

另外，流程中涉及到参数计算的地方，一定要把计算过程写清楚。比如论文排版中页边距的设置，不要只写“设置合适的页边距”，而要写“上边距 2.5cm，下边距 2.5cm，左边距 3cm，右边距 2.5cm”。如果不同场景下参数不同，就用表格列出来。

3.4 输出规范的写法与示例

输出规范这部分，很多人容易写得过于笼统。比如“论文格式要规范”“图表要清晰”这种描述，AI 读了之后还是不知道具体该怎么做。好的输出规范应该是可检查、可验证的。

举个例子，与其写“参考文献格式要正确”，不如写“参考文献采用 GB/T 7714 格式，期刊论文的格式为：作者. 标题[J]. 期刊名, 年份, 卷(期): 页码.”。再附上一个完整的示例，AI 就能准确执行了。

如果输出涉及多个文件或者多种格式，建议用表格来组织。比如：

这种表格化的输出规范，AI 理解起来准确率很高，而且你自己维护的时候也一目了然。

4. 安装与配置的完整实操流程

4.1 环境准备与前置检查

在开始安装之前，有几个前置条件需要确认。首先是你使用的 AI 工具版本是否支持 skills。目前 Claude 的桌面版、网页版和 Claude Code 都支持，但版本要求不同。建议先把工具更新到最新版本，避免因为版本问题导致 skill 无法加载。

其次是文件目录的确认。Skills 的存放位置有两个选择：项目级和用户级。项目级的路径是项目根目录下的.claude/skills/，用户级的路径是用户主目录下的.claude/skills/。如果你希望某个 skill 只在特定项目中使用，就放在项目级目录；如果希望所有项目都能用，就放在用户级目录。

这里有一个容易踩的坑：目录名必须是.claude，不是.claude-code也不是claude。我见过有人因为目录名写错了，折腾了半天以为 skill 不生效，最后发现是路径问题。另外，.claude目录默认是隐藏的，在文件管理器里需要开启“显示隐藏文件”才能看到。

4.2 从 GitHub 获取和安装 Skills

社区里有很多开源的 skill 集合，GitHub 上搜“claude skills”或者“agent skills”能找到不少。安装方式通常有两种：手动复制和命令行安装。

手动复制是最直接的方式。把仓库 clone 到本地，然后把需要的 skill 文件夹复制到.claude/skills/目录下。每个 skill 是一个独立的文件夹，里面至少包含一个SKILL.md文件。有些 skill 还会附带示例文件、模板文件或者辅助脚本，这些也要一起复制过去。

命令行安装适合批量操作。有些 skill 仓库提供了安装脚本，运行一条命令就能把所有的 skill 安装到指定目录。这种方式的好处是方便更新，坏处是如果脚本写得不够严谨，可能会覆盖你已有的自定义 skill。所以运行安装脚本之前，建议先备份一下现有的 skills 目录。

提示：从 GitHub 获取 skill 的时候，注意看一下仓库的更新时间和 issue 情况。有些 skill 是很久以前写的，可能已经不兼容当前版本的 AI 工具了。优先选择最近有更新、issue 回复比较活跃的仓库。

4.3 验证 Skill 是否生效

安装完成之后，怎么确认 skill 已经生效了？最直接的方法是触发测试。根据 skill 的触发描述，构造一个应该触发该 skill 的对话，看看 AI 的回复是否符合 skill 中定义的流程和输出规范。

如果 AI 的回复明显走了 skill 里定义的流程，说明安装成功。如果 AI 的回复跟平时没什么区别，说明 skill 没有被加载或者触发条件没匹配上。

排查的时候可以按照这个顺序来：先确认文件路径是否正确，再确认 SKILL.md 的格式是否规范（特别是开头的元信息部分），然后检查触发描述是否跟你的测试对话匹配。如果这些都没问题，可能是 AI 工具本身没有开启 skills 功能，需要在设置里确认一下。

4.4 多 Skill 共存时的优先级管理

当你安装了多个 skill 之后，可能会遇到两个 skill 同时匹配一个需求的情况。这时候 AI 会根据 skill 的优先级来决定用哪个。优先级的判断依据通常包括：触发描述的匹配程度、skill 的适用范围、以及你手动指定的偏好。

为了避免冲突，我建议在写 skill 的时候就把适用范围收窄。比如一个“通用代码审查”的 skill 和一个“Python 代码审查”的 skill，如果两个都安装了，当你审查 Python 代码时，后者应该优先。你可以在后者的触发描述里加上“当用户审查 Python 代码时，优先使用此 skill”这样的说明。

另外，定期清理不用的 skill 也很重要。Skills 太多会导致 AI 在匹配时消耗更多的注意力，反而降低响应质量。我一般会每个月检查一次，把最近没用过的 skill 归档或者删除。

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

5.1 Skill 不触发怎么办

这是最常见的问题。你明明安装了 skill，触发描述也写了，但 AI 就是不按 skill 的流程走。排查思路可以按照以下顺序来。

先检查文件是否放在了正确的目录下。项目级是.claude/skills/，用户级是~/.claude/skills/。注意~在不同系统下代表的路径不同，Windows 是C:\Users\用户名\，macOS 和 Linux 是/home/用户名/或/Users/用户名/。

再检查 SKILL.md 的格式。开头的元信息必须用---包裹，而且必须是文件的第一行。如果前面有空行或者注释，可能会导致解析失败。元信息里的字段名也要写对，常见的是name、description、trigger这几个。

然后检查触发描述是否跟你的测试对话匹配。有时候你写的触发词是“数学建模”，但你测试的时候说的是“建模比赛”，虽然意思相近，但 AI 可能没有做同义词扩展。这种情况下，要么在触发描述里补充同义词，要么在测试时使用触发描述里明确列出的词。

5.2 Skill 触发了但输出不符合预期

这种情况通常是因为执行流程写得不够细，或者输出规范不够明确。AI 虽然触发了 skill，但在具体执行时还是按照自己的理解来，没有严格遵循你定义的流程。

解决办法是在关键步骤上增加约束。比如你希望 AI 在写摘要之前先列出大纲让你确认，就在流程里明确写“在撰写摘要之前，必须先输出摘要大纲，等待用户确认后再继续”。这种明确的等待指令，AI 一般都会遵守。

另一个可能的原因是 skill 文件太长，AI 在处理的时候丢失了部分信息。这种情况在上下文窗口有限的工具里比较常见。解决办法是把 skill 拆分成多个小文件，用引用关系来组织。比如主 SKILL.md 只写触发条件和总体流程，具体的操作细节放在references/子目录下的单独文件里，需要的时候再读取。

5.3 多个 Skill 互相干扰

当你安装的 skill 多了之后，可能会出现 A skill 触发了 B skill 的流程，或者两个 skill 的输出混在一起的情况。这通常是因为触发描述有重叠，或者执行流程里有冲突的指令。

排查方法是逐个禁用测试。先把所有 skill 禁用，然后一个一个启用，看哪个 skill 启用后出现问题。找到问题 skill 之后，检查它的触发描述是否跟其他 skill 有重叠，如果有，就收窄触发范围。

还有一种情况是 skill 之间的依赖关系没有处理好。比如 skill A 的输出是 skill B 的输入，但两个 skill 是独立触发的，没有建立传递关系。这种情况下，需要在 skill A 的输出规范里明确说明“输出结果将作为 skill B 的输入”，并在 skill B 的触发描述里加上“当收到 skill A 的输出时触发”。

5.4 常见问题速查表

6. 进阶玩法：把 Skills 接入你的日常工作流

6.1 结合 Claude Code 做自动化

Claude Code 的命令行特性让它非常适合跟 skills 结合做自动化。你可以在项目里配置好 skill，然后用 Claude Code 批量处理任务。比如你有一个“代码审查”的 skill，可以在提交代码之前跑一遍 Claude Code，让它按照 skill 里定义的审查规则检查代码，输出审查报告。

这种用法的关键是把 skill 的输出格式定义成可解析的结构。比如审查报告用 Markdown 表格输出，每一行是一个问题，包含文件路径、行号、问题类型、严重程度、修复建议。这样你就可以用脚本进一步处理这个报告，比如自动创建 issue 或者生成修复任务列表。

6.2 团队协作中的 Skill 共享

Skills 的另一个价值是团队知识的沉淀和共享。一个团队里，资深成员的经验往往只存在于脑子里，新人来了只能靠口口相传。如果把团队的工作流程写成 skill，新人只要安装了这个 skill，就能按照资深成员的标准来工作。

具体做法是：在团队的项目仓库里创建一个.claude/skills/目录，把团队共用的 skill 放在里面。新成员 clone 项目之后，skill 自动就生效了。资深成员在 review 的时候，如果发现某个流程需要调整，直接改 SKILL.md 文件，提交到仓库，所有人下次 pull 的时候就能拿到更新。

这种做法的好处是流程的版本管理和持续迭代。SKILL.md 文件可以像代码一样做 code review，可以追溯修改历史，可以回滚到之前的版本。比传统的“写个文档放在 wiki 上然后没人看”要有效得多。

6.3 从零开始构建自己的 Skill 库

如果你刚开始接触 skills，不知道从哪里入手，我的建议是从你最常做的任务开始。想一想你每天或者每周重复做的事情有哪些，挑一个出来，把它的流程写下来，就是一个 skill 的雏形。

写第一版的时候不用追求完美，先把主要步骤列出来，跑几次看看效果，然后根据实际使用中遇到的问题逐步完善。我自己的经验是，一个 skill 通常要经过三到五次的迭代才能达到比较稳定的状态。第一版可能只有基本流程，第二版加上输出规范，第三版补充常见问题，第四版优化触发描述，第五版做细节打磨。

另外，不要闭门造车。社区里有很多优秀的 skill 可以参考，看看别人是怎么写的，特别是触发描述和执行流程的组织方式。GitHub 上搜“awesome claude skills”能找到不少高质量的合集。参考别人的写法，结合自己的需求做调整，比从零开始效率高得多。

6.4 数学建模场景下的 Skill 实战

数学建模是 skills 应用的一个典型场景，因为建模比赛有固定的流程和规范，而且时间紧、任务重，非常适合用 skill 来提效。我以华为杯或者国赛为例，说一下怎么构建一个建模 skill。

首先是选题分析阶段。Skill 里要定义选题的评估维度，比如问题的可解性、数据的可获得性、模型的创新性、论文的写作难度等。每个维度给出评分标准，让 AI 帮你做初步筛选。

然后是建模流程。把常见的建模方法列出来，比如优化模型、评价模型、预测模型、仿真模型等，每种方法给出适用场景和注意事项。AI 在分析问题之后，会根据 skill 里的指引推荐合适的建模方法。

接着是论文写作。这部分要定义论文的章节结构、每章的字数要求、图表的规范、公式的编号规则、参考文献的格式等。最好能附上一篇优秀论文的示例，让 AI 参考。

最后是时间管理。建模比赛通常有严格的时间限制，skill 里可以定义每个阶段的时间分配建议，以及超时后的应对策略。比如“如果到了第二天下午模型还没有跑通，建议简化模型，优先保证论文的完整性”。

这种场景化的 skill，写起来工作量不小，但一旦写好，在比赛中的提效效果非常明显。我见过有队伍用建模 skill 把论文初稿的完成时间从一天缩短到三个小时，省下来的时间可以用来做模型优化和灵敏度分析。

7. 我踩过的坑和最后分享的几个技巧

说几个我在使用 skills 过程中真实踩过的坑，希望能帮你省点时间。

第一个坑是元信息的格式。我一开始写 SKILL.md 的时候，元信息部分用了---包裹，但我在---前面加了一个空行，结果 skill 死活不触发。后来才发现，---必须是文件的第一行，前面不能有任何内容，包括空行。这个细节在官方文档里没有特别强调，但实际使用中很关键。

第二个坑是触发描述写得太宽泛。我写过一个“文档处理”的 skill，触发描述只写了“处理文档”。结果每次我让 AI 改个错别字、调个格式，它都触发这个 skill，走一遍完整的文档处理流程，非常烦人。后来我把触发描述改成了“当用户要求对文档进行结构性修改、格式规范化、内容重组时触发”，误触发的概率就大大降低了。

第三个坑是执行流程里的等待指令。我希望 AI 在写论文之前先给我看大纲，但我只在流程里写了“先列大纲”。结果 AI 列完大纲之后直接就开始写正文了，根本没有等我确认。后来我改成了“先列大纲，然后停止输出，等待用户确认后再继续”，AI 就乖乖等了。这个“停止输出”的指令很关键，少了它 AI 会默认继续往下走。

最后分享一个小技巧：给 skill 加一个“自检清单”。在 SKILL.md 的最后，加一个 checklist，列出这个 skill 执行完成之前必须确认的事项。比如“摘要是否在 300-500 字之间”“图表是否都有编号和标题”“参考文献是否都引用了”等。AI 在输出最终结果之前会对照这个清单做检查，能有效减少低级错误。

这个自检清单的写法也有讲究。不要写“检查格式是否正确”这种模糊的描述，要写“检查页边距是否设置为上 2.5cm、下 2.5cm、左 3cm、右 2.5cm”这种可验证的具体项。越具体，AI 检查的效果越好。

另外，如果你在 Windows 上使用 Claude Code，可能会遇到“无法将 claude 项识别为 cmdlet”的报错。这通常是环境变量没有配置好，把 Claude Code 的安装路径加到系统的 PATH 变量里就能解决。具体路径取决于你的安装方式，如果是 npm 安装的，通常在%APPDATA%\npm目录下。

Skills 这个生态还在快速演进中，新的玩法和工具不断出现。我目前关注的方向是把 skill 和自动化测试结合起来，让 skill 的输出质量可以被量化评估。这个如果跑通了，后面再找机会分享。