企业官网建设流程全解析

1. 从零理解 Agent Skills：它到底是什么，为什么突然火了

第一次看到 “skills” 这个词挂在 Claude 相关讨论里，我其实也愣了一下。毕竟在传统认知里，Claude 就是一个对话模型，你问它答，顶多写写代码、改改文案。但 “Agent Skills” 这个概念出现之后，整个玩法变了——它不再只是“你问我答”，而是让 Claude 能够按照一套预定义的流程去执行任务，像一个真正被培训过的助手，知道先做什么、再做什么、遇到什么情况该怎么处理。

简单来说，Agent Skills 就是一套写给 AI 看的“操作手册”。你把某个任务的完整流程、注意事项、输出格式、常见坑点全部写进一个叫SKILL.md的文件里，Claude 在执行相关任务时就会自动加载这个文件，按照你定义的规则来干活。这跟传统的 prompt engineering 有本质区别：prompt 是一次性的、临时的，而 skill 是可复用、可版本管理、可分享的。

我拿一个实际场景来类比。假设你是一个数学建模比赛的参赛者，每次拿到题目都要经历“读题→选模型→写代码→跑结果→写论文”这一整套流程。如果没有 skill，你每次都要重新跟 Claude 解释一遍你的偏好、你的代码风格、你常用的求解器。但如果你写了一个math-modeling/SKILL.md，里面规定好了“先用 Python 的 scipy 做数值求解，输出必须包含灵敏度分析，论文格式用 LaTeX”，那 Claude 每次都会按这个标准来，省掉大量重复沟通成本。

这也是为什么最近 “skills” 的搜索量暴涨。大家发现，与其每次费劲写长 prompt，不如一次性把经验固化成 skill 文件，之后直接调用。对于前端开发、数学建模、AI 漫剧创作、甚至 STM32 嵌入式开发这些有固定工作流的领域，skills 的价值尤其明显。

注意：Agent Skills 目前主要围绕 Claude 的生态展开，包括 Claude Code（CLI 工具）、Claude Desktop（桌面版）以及通过 API 接入的各种客户端。不同入口对 skill 的加载方式略有差异，后面会详细拆解。

2. SKILL.md 文件结构深度拆解：写什么、怎么写、写多细

2.1 核心字段与最小可用模板

一个能跑的SKILL.md其实不需要多复杂。我见过很多人把它写得像论文一样长，结果 Claude 加载后反而抓不住重点。根据我自己的反复测试，最小可用版本只需要三个部分：元信息、触发条件、执行步骤。

元信息用 YAML frontmatter 写在文件最顶部，格式如下：

--- name: frontend-component-generator description: 根据设计稿描述生成 React + TypeScript 组件，包含样式和单元测试 version: 1.2.0 ---

这三个字段里，name是 skill 的唯一标识，建议用英文小写加连字符；description最关键，它决定了 Claude 在什么场景下会主动加载这个 skill——写得越具体，触发越精准；version是可选但强烈建议加的，方便你后续迭代时追踪变更。

触发条件部分我通常用自然语言描述，比如：

## 何时使用 当用户提出以下类型请求时加载本 skill： - 要求生成新的 React 组件 - 要求将 Figma 设计稿转换为代码 - 要求为现有组件补充单元测试

执行步骤是核心，我习惯用有序列表加代码块的方式写。比如前端组件生成 skill 的执行步骤：

## 执行步骤 1. 确认组件名称和 props 接口，若用户未提供则根据描述推断并列出假设 2. 生成组件文件，使用函数式组件 + hooks，样式优先用 CSS Modules 3. 生成对应的 `.test.tsx` 文件，使用 React Testing Library 4. 输出文件树和安装依赖命令

2.2 触发精度控制：避免 skill 被误加载或漏加载

这是实操中最容易踩的坑。我一开始写了一个通用的 “code-helper” skill，description 写的是“帮助编写代码”，结果 Claude 在任何跟代码沾边的场景都会加载它，导致输出变得冗长且不聚焦。后来我把 description 改成了“当用户明确要求生成 Python 数据可视化代码，且涉及 matplotlib 或 seaborn 时加载”，误触发率立刻降下来了。

反过来，漏加载也很常见。如果你写的触发条件太窄，Claude 可能在你需要的时候反而不加载。我的经验是：在 description 里同时包含“动作词”和“领域词”。动作词比如“生成”“重构”“审查”“转换”，领域词比如“React 组件”“SQL 查询”“LaTeX 表格”。两者组合起来，命中率最高。

另外，Claude Code 在加载 skill 时有一个优先级机制：项目根目录下的.claude/skills/优先级最高，其次是用户主目录下的~/.claude/skills/。如果你在多个位置放了同名 skill，项目级的会覆盖全局的。这个机制可以用来做“项目定制化”——全局放通用 skill，项目里放针对该项目的覆盖版本。

2.3 内容粒度：写到什么程度才算“够用”

我见过两种极端：一种是只写了两行，Claude 加载后跟没加载一样；另一种是写了三千字，Claude 加载后反而不知道该听哪句。经过多次迭代，我总结出一个判断标准：假设你是一个刚入职的实习生，只看这份 skill 能不能独立完成任务。如果能，粒度就够了；如果还需要你口头补充，那就说明 skill 里缺东西。

具体来说，以下内容必须写进 skill：

• 输入输出的格式要求（比如“输出必须是 JSON，字段名用 camelCase”）
• 工具和库的选型偏好（比如“HTTP 请求统一用 httpx，不用 requests”）
• 边界情况的处理方式（比如“如果用户没提供超时时间，默认设为 30 秒”）
• 禁止事项（比如“不要生成任何包含 eval 的代码”）

而以下内容不建议写进 skill：

• 过于通用的编程常识（比如“变量名要有意义”）
• 与任务无关的个人偏好（比如“注释用中文”这种可以放全局配置）
• 频繁变动的信息（比如具体的 API key，应该用环境变量）

3. 手把手实操：从安装到跑通第一个 Skill

3.1 环境准备与 Claude Code 安装

不管你用的是 Windows、macOS 还是 Linux，Claude Code 的安装方式基本一致。前提是你有一个可用的 Node.js 环境（建议 18 以上）。安装命令：

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

安装完成后，在终端输入claude应该能看到交互界面。如果提示 “claude 无法将‘claude’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”，说明 npm 的全局 bin 目录没在 PATH 里。Windows 下可以用npm config get prefix找到路径，然后手动加到系统环境变量里。

提示：如果你在 Windows 上遇到 “requires the virtual machine platform” 之类的提示，那是因为 Claude Code 的某些沙箱功能依赖虚拟化平台。在“启用或关闭 Windows 功能”里勾选“虚拟机平台”和“Windows 子系统 for Linux”即可，不需要额外装虚拟机软件。

安装完成后，第一次运行claude会引导你登录。登录成功后，你就可以在终端里跟 Claude 对话了。但这时候还没有 skill 功能——你需要手动创建 skill 目录。

3.2 创建你的第一个 Skill 目录

Claude Code 默认从两个位置读取 skill：

• 全局：~/.claude/skills/
• 项目级：<项目根目录>/.claude/skills/

我建议新手先在全局目录下建一个测试 skill。以 macOS/Linux 为例：

mkdir -p ~/.claude/skills/hello-skill

然后在里面创建SKILL.md：

--- name: hello-skill description: 当用户说“打个招呼”或“测试 skill”时加载，输出一段带时间戳的问候语 version: 1.0.0 --- ## 执行步骤 1. 获取当前系统时间 2. 输出格式：`[HH:MM:SS] 你好，skill 已生效！` 3. 不要输出任何额外解释

保存后，在 Claude Code 里输入“测试 skill”，如果它回复了带时间戳的问候语，说明 skill 加载成功。如果没有，检查两点：一是文件路径是否正确，二是 description 里的触发词是否跟你输入的内容匹配。

3.3 从 GitHub 手动安装第三方 Skill

网上有很多人分享自己写的 skill，比如 “superpower skills” 和 “typesafe ai skills” 这两个仓库在社区里口碑不错。手动安装的流程其实很简单：

# 假设你要安装的 skill 在 GitHub 的某个仓库里 git clone https://github.com/xxx/superpower-skills.git cp -r superpower-skills/skills/* ~/.claude/skills/

复制完成后，每个子目录里的SKILL.md会被自动识别。你可以用claude的/skills命令（如果版本支持）查看当前已加载的 skill 列表。如果不支持，直接看目录结构也能确认。

注意：从网上 clone 下来的 skill 一定要先读一遍SKILL.md的内容，确认没有奇怪的指令（比如要求读取敏感文件或执行危险命令）。skill 本质上就是给 AI 的指令集，安全性完全取决于写它的人。

3.4 在 VSCode 里配置 Claude Code

如果你习惯在 VSCode 里写代码，可以把 Claude Code 集成进去。最简单的方式是打开 VSCode 的集成终端，直接运行claude。这样 Claude Code 就能感知到你当前打开的项目路径，项目级的 skill 也会自动生效。

更进一步的玩法是装一个 “Claude Code” 扩展（社区维护的），可以在侧边栏直接对话。但根据我的实测，终端方式的稳定性最好，扩展偶尔会出现 skill 加载不全的问题。如果你遇到 skill 不生效的情况，优先用终端方式排查。

4. 高频场景实战：Skills 在不同领域的落地方式

4.1 前端开发：组件生成与代码审查

前端是我用得最多的场景。我给自己配了两个 skill：一个是react-component-gen，负责根据描述生成组件；另一个是frontend-review，负责审查现有代码。

react-component-gen的核心逻辑是这样的：

## 执行步骤 1. 解析用户描述，提取组件名、props、交互行为 2. 若描述模糊，列出 2-3 个假设并让用户确认 3. 生成组件文件，规则： - 函数式组件 + TypeScript - 样式用 CSS Modules，文件名 `[Component].module.css` - 状态管理优先用 useState/useReducer，除非用户指定 Zustand 4. 生成测试文件，覆盖渲染、交互、边界情况 5. 输出文件树和依赖安装命令

这个 skill 帮我省掉了大量重复沟通。以前我每次都要说“用 TypeScript”“样式用 CSS Modules”“测试用 RTL”，现在一句话“生成一个带搜索功能的表格组件”，Claude 就按我的标准全自动完成了。

frontend-review则是在我写完代码后调用，它会检查：是否有未处理的 Promise rejection、是否有内存泄漏风险（比如 useEffect 里没清理定时器）、是否有可访问性问题（比如按钮没有 aria-label）。这些检查项都是我踩过坑之后加进去的。

4.2 数学建模：从读题到论文的全流程 Skill

数学建模比赛的时间压力很大，通常三天要完成选题、建模、求解、写作。我帮几个参加华为杯的朋友配了一套 skill，效果很明显。

核心 skill 叫math-modeling-pipeline，执行步骤分四个阶段：

## 阶段一：题目解析 - 提取题目中的关键变量和约束条件 - 判断问题类型（优化、预测、评价、分类） - 列出可能的模型候选，并说明适用理由 ## 阶段二：模型建立 - 优先选择经典模型（线性规划、灰色预测、TOPSIS、随机森林等） - 必须包含灵敏度分析或鲁棒性检验 - 输出模型假设和符号说明 ## 阶段三：代码实现 - 用 Python，数值计算用 numpy/scipy，可视化用 matplotlib - 代码必须包含注释和随机种子设置 - 输出结果要保存为 CSV，方便后续绘图 ## 阶段四：论文撰写 - 用 LaTeX 格式，结构：摘要、问题重述、模型假设、模型建立与求解、灵敏度分析、模型评价 - 摘要控制在 800 字以内，必须包含具体数值结果

这套 skill 最大的价值是强制流程化。比赛时人容易慌，东做一点西做一点，有了 skill 之后，Claude 会按阶段推进，每一步都有明确产出，不容易乱。

4.3 AI 漫剧创作：角色设定与分镜生成

AI 漫剧是最近很火的方向，核心流程是“故事大纲→角色设定→分镜脚本→画面描述→配音文案”。我配了一个ai-comic-skill，重点解决角色一致性问题。

## 角色一致性规则 1. 每个角色在首次出现时，生成一份“角色卡”，包含： - 姓名、年龄、外貌特征（发色、瞳色、服装风格） - 性格关键词（3-5 个） - 说话风格（比如“简短有力”“喜欢用反问句”） 2. 后续所有分镜中，角色的外貌和说话风格必须与角色卡一致 3. 如果剧情需要角色形象变化（比如受伤、换装），必须在分镜中明确标注变化点

这个 skill 解决了一个很痛的问题：AI 生成多幕剧情时，角色形象经常漂移。有了角色卡约束之后，一致性明显提升。

4.4 嵌入式开发：STM32 代码生成与寄存器配置

嵌入式开发对准确性要求极高，一个寄存器配错就可能烧板子。我配的stm32-skill主要做两件事：生成初始化代码和检查配置冲突。

## 执行步骤 1. 确认芯片型号和使用的片上外设（GPIO、UART、SPI、I2C、TIM 等） 2. 生成初始化代码，使用 HAL 库，每个外设单独一个函数 3. 检查项： - 时钟树配置是否与总线频率匹配 - GPIO 复用功能是否与所选外设一致 - 中断优先级是否冲突 4. 输出时附带寄存器级说明，方便对照参考手册

这个 skill 我建议配合具体的参考手册使用。Claude 对 STM32 的寄存器细节记忆不一定完全准确，所以我在 skill 里加了一条：“所有寄存器配置必须标注参考手册的章节号，方便人工复核”。

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

5.1 Skill 不生效的排查清单

5.2 我踩过的三个坑

第一个坑：description 写得太泛。我最早写了一个code-helper，description 是“帮助编写代码”。结果 Claude 在任何代码场景都加载它，输出变得又长又泛。后来改成“当用户要求生成 Python 数据处理脚本，且涉及 pandas 或 numpy 时加载”，精准多了。

第二个坑：执行步骤里放了太多“建议”而不是“规则”。比如我写过“建议使用 TypeScript”，Claude 有时候用有时候不用。后来改成“必须使用 TypeScript，不允许生成 .js 文件”，就稳定了。skill 里的语言要像规章制度，不要像建议。

第三个坑：忘了写输出格式。有一次我让 Claude 生成一个配置文件，它给我输出了一段带解释的 Markdown，但我需要的是纯 JSON。后来我在 skill 里加了一条“输出必须是纯 JSON，不要包含任何解释文字或 Markdown 代码块标记”，问题解决。

5.3 性能与维护建议

Skill 多了之后，加载速度会变慢。我的经验是：全局 skill 控制在 10 个以内，项目级 skill 按需添加。如果某个 skill 很久没用，就把它移到~/.claude/skills-archive/里，需要时再移回来。

另外，建议给每个 skill 加版本号和更新日志。我自己的做法是在SKILL.md末尾加一个## 变更记录段落，每次修改都记一笔。这样当输出不符合预期时，可以快速定位是哪次改动引入的问题。

6. 进阶玩法：Skill 组合与自动化流水线

6.1 用 Skill 串联多步骤工作流

单个 skill 解决单点问题，但真实任务往往是多步骤的。比如“从需求文档到可运行的前端项目”这个流程，可以拆成三个 skill：requirement-parser（解析需求）、component-gen（生成组件）、project-scaffold（搭建项目结构）。然后在 Claude Code 里按顺序调用。

更进一步，你可以写一个“元 skill”，在它的执行步骤里明确引用其他 skill：

## 执行步骤 1. 加载 `requirement-parser`，提取功能点和非功能需求 2. 加载 `project-scaffold`，初始化项目结构 3. 对每个功能点，加载 `component-gen` 生成对应组件 4. 最后加载 `frontend-review` 做整体检查

这种组合方式适合固定流程的项目，比如每周都要做的周报生成、每月都要跑的报表分析。

6.2 把 Skill 接入其他工具链

Claude Code 支持通过 MCP（Model Context Protocol）接入外部工具。你可以写一个 skill，在里面调用 MCP 工具来完成更复杂的操作，比如查询数据库、调用内部 API、操作文件系统。

我自己的一个用法是：写了一个db-query-skill，里面规定“所有数据库查询必须先用 EXPLAIN 检查执行计划，如果扫描行数超过 10000 则拒绝执行并提示优化”。这样即使 Claude 生成了低效查询，也会被 skill 规则拦住。

6.3 Skill 的分享与协作

如果你在团队里用 Claude Code，可以把项目级 skill 提交到 Git 仓库，这样所有成员共享同一套规则。我建议在仓库里建一个.claude/skills/目录，每个 skill 一个子目录，然后在 README 里说明每个 skill 的用途和触发方式。

对于开源分享，GitHub 上已经有不少 skill 集合仓库。你可以参考别人的写法，但不要直接复制——因为每个人的工作流不同，skill 必须根据自己的实际需求定制。我通常的做法是：clone 下来读一遍，提取有用的规则，然后融合进自己的 skill 里。

7. 关于 Skill 设计的一些个人体会

写了这么多 skill 之后，我最大的感受是：skill 的质量取决于你对任务的理解深度，而不是你对 AI 的 prompt 技巧。如果你自己都没想清楚一个任务的完整流程和边界情况，写出来的 skill 一定是模糊的，Claude 执行起来也会飘。

另一个体会是：skill 要迭代，不要一次求完美。我最早的几个 skill 现在回头看简直没法用，但正是通过一次次实际使用、发现问题、修改规则，才慢慢打磨出可用的版本。建议你每用完一次 skill，花两分钟想想“这次哪里不满意”，然后立刻改。改个五六次之后，skill 就会变得非常顺手。

还有一个容易被忽略的点：skill 里要写“不要做什么”。比如“不要生成任何包含eval的代码”“不要在输出里包含 API key”“不要自动执行 git push”。这些禁止项往往比正面规则更重要，因为它们能防止 AI 在你不注意的时候做出危险操作。

最后分享一个小技巧：如果你不确定一个 skill 该怎么写，可以先在 Claude Code 里手动做一遍任务，把每一步的对话记录下来，然后让 Claude 帮你把这段对话整理成SKILL.md格式。这个方法我试过很多次，整理出来的初稿质量相当不错，你只需要再微调一下触发条件和边界规则就行。