企业官网建设流程全解析

1. 从"skills"这个模糊词说起：它到底指什么

第一次看到"skills"这个词单独出现，很多人会一头雾水。它不像"Claude Code 安装教程"那样指向明确，也不像"数学建模 skills 推荐"那样有具体场景。但恰恰是这种模糊性，说明它已经从一个普通英文单词，演变成了一个特定语境下的专有概念——在 AI 编程助手和智能体（Agent）的生态里，skills 指的是一套可复用、可组合的能力模块，通常以SKILL.md这样的文件形式存在，用来告诉 AI 在特定场景下该怎么做、按什么流程做、遵循什么规范。

你可以把它理解成给 AI 助手准备的"操作手册合集"。没有 skills 的时候，你每次都要在对话里反复交代"帮我写代码时先检查类型定义""做数学建模时先做数据清洗再选模型"；有了 skills，这些经验就被固化下来，AI 在需要时自动调用，不用你重复啰嗦。这就是为什么最近围绕 skills 的讨论突然多了起来——它解决的是"如何让 AI 稳定地按专业标准干活"这个核心痛点。

这篇文章适合几类人看：刚接触 Claude Code 或类似 AI 编程工具、想搞清楚 skills 到底是什么的新手；已经在用但觉得每次都要重复交代背景、想提升效率的中级用户；以及想自己动手写 skills、把个人经验沉淀成可复用模块的进阶玩家。我会从概念拆解讲到实操安装，再讲到怎么写自己的第一个 skill，中间穿插我踩过的坑和实测有效的做法。

需要先说明一点：skills 这个概念目前主要活跃在 Claude 生态里，尤其是 Claude Code 这个命令行工具和 Claude Desktop 桌面端。不同工具对 skills 的支持程度不一样，有的直接读SKILL.md，有的需要额外配置。下面讲的内容以 Claude Code 为主，其他工具会顺带提。

2. skills 的核心机制：SKILL.md 里到底装了什么

2.1 一个 skill 的最小结构

很多人以为 skill 是个很复杂的东西，其实拆开看，它的核心就是一个 Markdown 文件。文件名通常叫SKILL.md，放在特定的目录下，AI 工具启动时会扫描这些目录，把符合条件的 skill 加载进来。一个最简的 skill 大概长这样：

--- name: code-review description: 对提交的代码进行结构化审查，检查类型安全、边界条件和命名规范 --- # 代码审查流程 1. 先通读改动，理解意图 2. 检查类型定义是否完整，有没有 any 滥用 3. 检查边界条件：空值、越界、并发 4. 检查命名是否表意清晰 5. 输出审查意见，按严重程度排序

上面这段里，---包起来的部分叫 frontmatter，是元数据，告诉工具这个 skill 叫什么、什么时候该用它。下面的正文才是真正的"操作指令"。AI 在判断当前任务和某个 skill 的 description 匹配时，就会把这个 skill 的正文加载进上下文，然后按里面的步骤执行。

这里有个关键点：description 写得好不好，直接决定 skill 会不会被正确触发。我见过太多人把 description 写成"一个有用的工具"这种废话，结果 AI 根本不知道什么时候该用它。正确的做法是把触发场景写具体，比如"当用户要求审查代码、检查代码质量、或提交 PR 前需要自查时使用"。

2.2 skills 和 prompt、和普通文档的区别

有人会问：那我直接把要求写在对话里不就行了，为什么要搞个 skill 文件？区别在于三个字：可复用。

写在对话里的要求，这次用完就没了，下次还得重打。写成 skill，它就变成了一个持久化的资产，任何一次对话只要场景匹配就能自动加载。而且 skill 可以被版本管理、可以分享给别人、可以组合调用——这些是临时 prompt 做不到的。

那它和普通的说明文档又有什么区别？普通文档是给人看的，skill 是给 AI 看的。这个区别体现在写法上：给人看的文档可以含糊、可以靠常识补全，给 AI 看的 skill 必须把每一步都写清楚，因为 AI 不会"猜"你的意图，它只会严格执行你写的东西。所以写 skill 的时候，宁可啰嗦，不要留白。

2.3 为什么是 Markdown 而不是别的格式

用 Markdown 有几个实际好处。第一，它天然支持结构化，标题、列表、代码块都能表达，AI 解析起来也顺。第二，它人也能读，你写完 skill 自己扫一眼就知道逻辑对不对。第三，它和 Git 配合得好，改了什么一目了然。相比之下，如果用 JSON 或 YAML 写 skill 逻辑，嵌套一深就没法看了。

我实测下来，一个 skill 控制在 50 到 200 行之间比较合适。太短了信息不够，AI 执行时还得自己发挥；太长了会占用大量上下文，而且 AI 容易抓不住重点。如果某个 skill 确实需要很长的流程，建议拆成多个小 skill，用命名区分，比如>node -v npm -v

如果版本太老（Node 低于 18），先去官网升级。然后全局安装：

npm install -g @anthropic-ai/claude-code

装完之后在终端输入claude，如果能看到交互界面就说明成功了。这里有个高频坑：Windows 用户有时候会遇到"无法将 claude 项识别为 cmdlet、函数、脚本文件或可运行程序的名称"，这通常是 npm 全局 bin 目录没加到 PATH 里。解决办法是找到 npm 的全局路径：

npm config get prefix

把这个路径加到系统环境变量 PATH 里，重启终端即可。另一个 Windows 上常见的问题是提示需要启用虚拟机平台（virtual machine platform），这是因为 Claude Code 的某些依赖需要 WSL 支持，按提示在"启用或关闭 Windows 功能"里勾选对应项，重启后就好。

3.2 skills 放在哪个目录

Claude Code 加载 skills 有几个约定位置，优先级从高到低大致是：

我的建议是：通用能力放用户目录，项目特有的放项目目录。比如"代码审查""提交信息规范"这种到哪都用得上的，放~/.claude/skills/；而"这个项目的数据库迁移流程"这种只跟特定仓库相关的，放项目里的.claude/skills/。

每个 skill 一个独立文件夹，文件夹里放SKILL.md。目录结构大概是这样：

~/.claude/skills/ ├── code-review/ │ └── SKILL.md ├── commit-message/ │ └── SKILL.md └──>git clone https://github.com/xxx/awesome-skills.git cp -r awesome-skills/typesafe-review ~/.claude/skills/

第三步，检查 frontmatter 是否完整。有些分享的 skill 缺name或description，这种加载时会出问题。打开SKILL.md确认一下，缺了就补上。

第四步，重启 Claude Code。skills 是在启动时扫描加载的，改完不重启不生效。重启后在对话里描述一个匹配的场景，看 AI 有没有按 skill 里的流程走，以此验证是否加载成功。

注意：从网上拿来的 skill 不要直接无脑用。先通读一遍内容，确认里面没有奇怪的指令，比如让它执行某些你不清楚的命令。skill 本质上是给 AI 的指令，来源不明的要谨慎。

3.4 验证 skill 是否生效的土办法

官方没有提供"列出已加载 skills"的命令，我一般用两个土办法验证。第一个是直接问 AI："你现在加载了哪些 skills？"它有时候能答出来。第二个更可靠：故意触发某个 skill 的场景，看它的行为是否符合 skill 里定义的流程。比如你的code-reviewskill 要求"先通读再检查类型"，那你就丢一段代码给它，看它是不是按这个顺序来的。如果它跳过了通读直接挑毛病，说明 skill 没加载或者没被匹配上。

匹配不上的常见原因是 description 写得太泛。这时候把 description 改得更具体，加上明确的触发词，重启再试。

4. 自己写一个 skill：从需求到落地

4.1 先想清楚"这个 skill 解决什么重复劳动"

写 skill 之前先问自己：我是不是每次做某类任务时，都要重复交代同样的背景和要求？如果是，那它就值得被写成 skill。反过来，如果一件事你只做一次，写 skill 就是浪费时间。

举几个我实际写成 skill 的例子：每次让 AI 写 SQL 都要提醒"用 CTE 不要用嵌套子查询""字段名用下划线""加注释说明索引意图"——这三条重复了十几次之后，我就写了个sql-styleskill。再比如数学建模，每次都要交代"先做缺失值处理，再标准化，再选模型，最后做交叉验证"，这套流程固定下来就成了modeling-workflowskill。

判断标准很简单：重复三次以上的交代，就该沉淀成 skill。

4.2 frontmatter 的写法细节

frontmatter 里最关键的是description。它的作用是让 AI 判断"当前任务要不要用这个 skill"，所以写法上要包含触发场景和关键词。对比一下：

差的写法：

description: SQL 相关

好的写法：

description: 当用户要求编写、优化或审查 SQL 查询时使用，涵盖 CTE 写法、命名规范、索引注释和性能考量

好的写法里，"编写、优化、审查 SQL"是触发场景，"CTE 写法、命名规范"是关键词，AI 匹配时命中率会高很多。

name字段用短横线连接的小写单词，比如code-review、sql-style，别用中文或空格，避免路径问题。

4.3 正文怎么写才让 AI 执行得稳

正文是 skill 的灵魂。我的经验是遵循三条原则。

第一，用编号步骤，不用大段描述。AI 对有序列表的执行准确率明显高于散文式段落。把流程拆成 1、2、3、4，每步一句话说清楚做什么。

第二，给出判断标准，不给模糊要求。比如不要写"检查代码质量"，要写"检查是否存在未处理的 Promise rejection、是否有硬编码的密钥、函数是否超过 50 行"。有具体标准，AI 才知道怎么算通过。

第三，关键处给正反例。有些要求光说不够，得给例子。比如命名规范，写一句"变量名用 camelCase，常量用 UPPER_SNAKE_CASE"，再附上一两个正例反例，AI 执行起来就准了。

下面是一个相对完整的 skill 正文示例：

# 数据建模工作流 ## 步骤 1. 读取数据后，先输出字段类型和缺失值比例 2. 缺失值超过 30% 的字段，建议删除并说明理由 3. 数值字段做标准化，类别字段做独热编码 4. 按 7:3 划分训练集和测试集，随机种子固定为 42 5. 至少尝试三种模型，输出对比表格 6. 对最优模型做五折交叉验证，报告均值±标准差 ## 注意事项 - 不要在划分数据集之前做标准化，会造成数据泄漏 - 类别字段如果基数过高（超过 50 类），改用目标编码 - 所有随机操作必须固定种子，保证可复现

这个 skill 里，步骤是编号的，判断标准是量化的（30%、50 类），注意事项点出了容易犯的错。AI 拿到这样的指令，执行起来就稳。

4.4 写完之后的调试循环

skill 不是一次写好的，得反复调。我的调试流程是：写第一版，找个真实任务跑一遍，观察 AI 哪一步没按预期走，针对性改那一句，再跑。通常改个三四轮就稳定了。

有个细节值得注意：如果 AI 总是跳过某一步，可能是那一步写得太靠后，或者表述不够强。把它提到前面，或者加上"必须""务必"这类强调词。反过来，如果 AI 在某一步上过度发挥，说明那一步写得太模糊，得收紧。

5. 不同场景下的 skills 实战案例

5.1 前端开发场景

前端开发里重复交代最多的是组件规范。我写过一个react-componentskill，核心是几条硬性要求：组件用函数式写法、props 必须有 TypeScript 类型、样式用 CSS Modules 不用内联、副作用统一放 useEffect 并注明依赖。写完之后，让 AI 生成组件时基本不用再纠正风格问题。

前端还有个高频场景是"改完代码要跑什么检查"。我把它也写进 skill：改完先跑类型检查，再跑 lint，再跑单元测试，三步都过了才算完成。这样 AI 不会改完就交差，而是会自己走完验证流程。

5.2 数学建模场景

数学建模比赛里时间紧、任务重，skills 的价值特别明显。我整理过一套建模 skill，覆盖从数据预处理到论文撰写的全流程。其中>