企业官网建设流程全解析

如果你也在用 Claude Code，先别急着说我标题党。过去我一直把它当成一个“能看懂项目代码的终端助手”，让它写点脚本、改个 bug、跑个测试，感觉已经挺香了。但直到我花了一个周末，陆陆续续给 Claude Code 装了 40 个 Skill，我才发现之前的用法基本等于白给——明明工具箱里全是电钻，我却一直拿它当锤子使。

这篇文章把我从“装 Skill 之前”到“装完 40 个 Skill 之后”的完整路径捋一遍，包括 Skill 和 Agent 到底什么区别、优质 Skill 去哪儿找、怎么手动把 GitHub 上的 Skill 搬进本地、哪些 Skill 装上以后是真香、哪些纯属凑数，以及我翻车之后总结的排查技巧。适合刚接触 Claude Code 的萌新，也适合已经用了一段时间但一直把 Skill 当普通提示词的老用户，更适合理想在 VSCode 里把 Claude Code 变成主力开发环境的实践派。

1. 先搞清楚 Skill 是什么，别拿它当高级提示词

1.1 Skill 与普通提示词的本质差异

很多人第一次接触 Skill 的时候，第一反应是：这不就是预设提示词吗？我刚开始也这么想，但真正用下来才发现，提示词是“说给模型听的一句话”，而 Skill 是一整套“带约束、带流程、带输出规范的可执行知识包”。打个比方，提示词像是你临时告诉厨师“今天做个辣一点的川菜”，而 Skill 是直接递给厨师一本装订好的菜谱，里面除了配方，还有食材采购清单、处理顺序、火候要求、摆盘标准，甚至验收标准。

在 Claude Code 的环境里，Skill 通常落到一个目录中，目录里不仅有一个 SKILL.md 作为说明书，还会带上示例文件、模板、脚本、参考文档等等。激活之后，模型不仅知道你要求它做什么，还知道完成这件事的完整上下文、公司内部约定、命令用法和检查清单。这种“上下文密度”的提升，是单纯在输入框里堆字没办法比的。

1.2 Skill 和 Agent 的分工边界

装 Skill 的过程中经常有人问：这跟 Agent 有什么区别？这里我说一下自己的理解。Agent 强调的是“自动决策和执行闭环”——给它一个目标，它可以自己拆任务、调工具、看结果、决定下一步。Skill 则更像“能力包”或者“经验包”——它不强调自主决策，而是强调把某类任务的方法论沉淀下来，让模型调用时按固定套路输出高质量结果。

所以这两者不是二选一的关系。Agent 可以用 Skill 作为自己的“工具箱”，Skill 也可以内嵌一些 Agent 式的指令来完成自动化环节。比如我自建的仓颉类型项目里，有一个专门负责代码评审的 Skill，它会先跑静态检查、再看仓库约定、最后按评分表输出评审意见，每一步都是自动执行，但从结构上讲它依然是一个 Skill。理解了这个边界，你就不会再去纠结“到底要不要把所有东西都改成 Agent”，而是会自然地按任务类型去选择合适的载体。

1.3 我给 40 个 Skill 做的分类

装 40 个 Skill 之前，我给自己定了一个原则：不允许重复造轮子，同一个方向只保留一个最合适的。我大致分了六类——

• 开发与编码类：包括前端最佳实践、后端脚手架、代码评审、TypeScript 迁移、自动化测试生成这类。
• 写作与内容类：包括技术博客、中英文润色、SEO 标题、书籍结构化整理之类。
• 效率与工作流类：比如会议纪要、任务拆解、信息检索、知识库整理、时间管理。
• 科研与学术类：数学建模、论文检索、文献综述、公式排版、数据可视化图表规范。
• 演示与设计类：PPT 结构生成、原型说明、架构图绘制、流程图绘制。
• 语言与学习类：语言学习陪练、术语对照、翻译审校、口语化改写等。

分类这个过程本身就很有价值，因为你装完 Skill 之后，真正决定好不好用的不是数量，而是“模型能不能快速找到合适的那个”。后面我会专门讲怎么给 Skill 写描述，让它在正确场景下能被自动匹配到。

2. 40 个 Skill 从哪里来：官方源、社区源和 GitHub 手动安装

2.1 Skill 的目录结构与安装原理

先别急着到处找“一键安装包”，你得先理解它为什么能生效。Claude Code 在启动时会扫描指定的 Skill 目录，然后把这些目录里的 SKILL.md 描述信息加载进模型可感知的范围。换句话说，Skill 不是编译进程序里的，而是“运行时被检索到”的。检索的依据主要是文件名、描述字段和目录名里的关键词。

常见目录结构是这样的：

skills/ ├── code-review/ │ ├── SKILL.md │ ├── rules.md │ └── templates/review_template.md ├── blog-writing/ │ ├── SKILL.md │ └── examples/example_post.md └── meeting-notes/ ├── SKILL.md └── scripts/format_notes.py

每个子目录就是一个 Skill，目录名就是它的唯一标识。SKILL.md 里一般写三块内容：它是什么、什么时候用、怎么用。有些社区 Skill 还自带 script 或 template，模型在执行过程中可以调用这些文件，而不是把一堆东西硬塞进上下文里。

2.2 从 GitHub 手动安装 Skill 的完整步骤

我实测下来，手动装一个 GitHub 上的 Skill，流程一般是这样的：

1. 先在 GitHub 上找到目标仓库，确认它的目录里有没有 SKILL.md，以及最近是否还在更新。
2. 把仓库 clone 到本地，或者直接下载 ZIP 包。
3. 在 Claude Code 配置里指定 skills 目录，比如~/.claude/skills，然后把你需要的 Skill 子目录复制进去。
4. 重启 Claude Code，让它重新扫描 Skill 目录。
5. 在会话里用自然语言描述你的需求，观察它是否自动匹配到这个 Skill。

听起来挺简单，但实际容易翻车的地方在于：很多仓库是“一个仓库放几十个 Skill”，你直接整个 clone 下来，里面可能混着大量示例、脚本、测试文件。这时候你就需要手动挑选，只把带 SKILL.md 的子目录放进你的 skills 目录。

2.3 怎么判断一个 Skill 靠不靠谱

装多了你就会发现，社区里 Skill 质量参差不齐。我现在一般用四个标准过滤：

• 描述写没写清楚：如果 SKILL.md 第一段就告诉我适用场景、输入格式、输出格式，那它大概率靠谱。
• 有没有示例：好的 Skill 会附一个 example 或 demo，能直接看出模型调用后的效果。
• 维护时间：超过三个月没更新、issues 没人回，建议直接放弃。
• 有没有依赖外部服务：有些 Skill 需要调第三方 API 才跑得动，如果接口文档不明确，我建议别碰，否则后期排查问题会很痛苦。

这个筛选标准帮我避免了大量垃圾 Skill。40 个看似很多，但我是从上百个候选里挑出来的。

3. 真正值得装的 6 类 Skill 推荐（40 个里挑重点说）

3.1 开发向：vue-best-practices、codex 这类为什么必装

如果你是前端开发者，vue-best-practices 这类 Skill 装上以后，Claude Code 生成的 Vue 代码会自动遵循组件命名规范、props 校验、状态管理分层等约定，而不是每次都给你一套“能跑但很难维护”的代码。这个 Skill 的效果不在于它有多聪明，而在于它把团队规范前置了，模型每次生成都带着“标准答案”来写。

codex skill 可能很多人也听说过。它本质上不是让 Claude Code 去调用 OpenAI 的 Codex，而是定义了一套“在 Claude 环境里模拟 Codex 式任务拆解和代码检索”的思路。对我这种需要同时对比不同模型输出风格的人来说，它最大的价值是提供了一种结构化的任务分解模板，让复杂需求不会漏掉某个环节。

3.2 写作与内容向：book to skill、impeccable 的使用感受

book to skill 是我最近发现的一个很有意思的项目，名字带点“把书变成技能”的意思。它的思路是把一本专业书里的核心方法论提炼成结构化 Skill 文件，比如把《金字塔原理》变成“结构化表达 Skill”，以后你写方案、写汇报时，模型会自动按结论先行、分类分组、逻辑递进的方式来组织内容。这对靠写文档吃饭的人来说，简直是刚需。

impeccable skill 则更像一个“内容质检员”。它主要用来校对你的英文表达、语法、标点和语气。我试过让它润色一篇技术博客摘要，它不只会改语法错误，还会把同一句话按“正式版、口语版、严谨学术版”各给一版，让你自己选。这个设计很聪明，因为它的目标不是取代人，而是减少你从头写的时间。

3.3 效率与工作流向：ponytail、workbuddy、仓颉分别解决什么问题

ponytail 这个 Skill 光看名字你可能猜不到它干嘛，它更像一个“上下文记忆增强器”。它的核心能力是帮你整理一段对话里的关键信息，生成结构化摘要，并把待办事项、决策结论单独拎出来。我一般会在开完长会后用它做总结，比我自己翻聊天记录快得多。

workbuddy 是偏“工作流编排”的 Skill。它能把一个复杂任务拆成若干子任务，并按依赖关系排好序。比如“做一个项目周报”，它会自动把信息收集、数据分析、图表生成、报告排版拆成四步，每一步还可以单独执行。这个 Skill 适合那种“需求很大、无从下手”的场景，先把骨架搭出来，再往里面填肉。

仓颉 Skill 是我在中文项目里用得比较多的一个，主要作用是规范中文技术文档的写作风格。它会让模型注意专有名词大小写、中文和英文之间是否加空格、避免“的、地、得”误用、统一技术名词翻译等等。对中文开发者社区来说，这类 Skill 的实用价值很高，因为它解决的是细节但很烦人的问题。

3.4 科研与学术向：数学建模、论文检索类 Skill 怎么配合

科研方向的人装 Skill 一定不要只看“论文生成”类的，更要看“论文检索”和“论文结构化理解”类的。比如我在做文献综述时，会让 Skill 先按“问题定义—方法分类—实验对比—结论总结”的框架去读一篇 PDF，而不是直接把全文扔给模型让它“总结一下”。后者虽然也能输出摘要，但前者能直接把内容拆成可引用的结构化笔记。

数学建模类 Skill 也很实用，它内置了一套“建模问题求解流程”：先明确变量和约束条件，再选择模型类型，然后给出求解方案和参数敏感性分析。用这种 Skill 生成的内容，比直接让模型“帮我解这道题”要严谨得多，因为模型会主动检查单位是否一致、边界条件是否完整。

3.5 演示与可视化向：show me、grill 这类怎么快速出图

show me 这类 Skill 核心是“把文字变成可视化表达”。你给它一段流程说明，它能生成架构图、流程图或者幻灯片大纲。我用它做技术方案汇报时，最常用的是“把这段需求描述转成一张系统架构图”，输出可能是 Mermaid 语法，也可能是 HTML 页面模板。它的好处不是图多精美，而是结构不会漏，因为它是按逻辑关系一步一步描述出来的。

grill 这个 Skill 比较有意思，名字像“烧烤”，实际是“追问和拷问”的意思。它会在你给出方案后，站在反方角度提出一堆质疑，帮你把方案里模糊的地方提前暴露出来。我用它做技术选型评审时非常上瘾，因为它能把 “为什么选这个数据库”“容灾方案是什么”“成本增长曲线怎么评估”这些问题全问出来，逼着你想清楚再动手。

3.6 语言学习与特色向：哪些 Skill 是氛围组，哪些是真能落地

语言学习类的 Skill 我装过几个，效果最稳定的反而是那种“角色扮演 + 语法纠错”的组合型 Skill。它会把对话场景固定下来，比如模拟面试、模拟客户沟通，同时在对话结束后集中给一份语法修改反馈。缺点是它没法真正解决发音和听力问题，所以更适合用来练口语表达逻辑。

还有些 Skill 属于“氛围组”，装上以后基本想不起来用，比如一些过于娱乐化、或者纯粹为了展示技术堆叠的 Skill。我的建议是，如果你发现某个 Skill 连续两周都没被触发过，直接删掉。40 个听着多，但真正高频使用的可能不到 15 个。

4. 装完 40 个 Skill 后，Claude Code 的正确打开方式

4.1 工作流的变化：从“手动命令”到“Skill 调度”

装 Skill 之前，我的使用习惯是打开 Claude Code 之后手动敲命令，告诉它“帮我看看这个文件哪里有问题”。装完之后，我发现自己变成“调度员”了，我会直接说“用代码评审 Skill 看这个 PR”，或者“用周报 Skill 把这几天的 commit 整理一下”。这个转变很微妙，但效率提升是实打实的。

因为 Skill 里已经写清了全套流程，模型不需要一步步问你“要不要跑测试”“要不要检查 lint”，它会按照 SKILL.md 里的步骤自动把该做的检查做完，最后给你一份结构化报告。你只需要在最开始把需求说清楚，后面基本不用管。

4.2 VSCode 里配置 Claude Code 与 Skill 联动

如果你跟我一样主要用 VSCode，我发现把 Skill 和 Claude Code 的 VSCode 扩展配合起来，体验会好很多。操作上没有想象中复杂：

1. 在 VSCode 扩展市场安装 Claude Code 官方扩展，并确认命令行里 claude 命令可用。
2. 在项目根目录或用户目录下创建skills文件夹。
3. 把 Skill 子目录放进去，并在 Claude Code 配置里指定该目录。
4. 在 VSCode 打开项目后，直接用 Ctrl+` 唤起终端，运行 Claude Code，让它在项目上下文里自动扫描 Skill。
5. 如果是多项目同时开发，我建议把通用类 Skill 放在用户级目录，把项目专属 Skill 放在项目级目录，避免互相污染。

这样配好之后，你选中一段代码，直接在 Claude Code 里说“用 best-practices Skill 帮我 review 这段”，它会把整个仓库约定、Skill 规范和当前选区一起拿来做分析，上下文完整度比开一个独立网页版高很多。

4.3 让 Skill 和不同模型源配合使用

关于 Claude Code 接入 DeepSeek 这件事，我多说一句：很多人担心换模型之后 Skill 就失效了，其实不是。Skill 本质上是一套纯文本的规范文件，模型只要支持读取文件内容并理解指令，就都能配合。DeepSeek 这类模型在代码理解上并不弱，用同一套 Skill 也能跑通。

不过我也发现一个差异：不同模型对 Skill 的“服从程度”不一样。有的模型会老老实实按 SKILL.md 的步骤走，有的模型则会“自由发挥”，跳过一些步骤。遇到这种情况，我的解决办法是在 SKILL.md 里增加一个“执行顺序检查清单”，并且要求模型在输出开头先声明自己会按哪些步骤执行。你可以在描述里写清楚“如果没有特殊情况，必须严格按照以下顺序执行，不得跳过”，语气可以硬一点。

5. 踩坑实录：Skill 不生效、路径错误、版本冲突怎么办

5.1 最常见的问题与排查表

我装完 40 个 Skill 之后，遇到过的问题基本可以归成四类，直接整理成了一张速查表：

如果出现完全加载不到的情况，可以先在 Claude Code 里输入“列出当前可用的 Skill”，看它能不能把你刚装的 Skill 显示出来。这一步能快速判断是路径问题还是文件问题。

5.2 我踩过的 3 个典型坑

第一个坑是大小写问题。Skill 文件必须叫 SKILL.md，不能用小写 skill.md，也不要叫 README.md。我第一次装的时候没注意，复制进去一个 README.md，结果模型完全感知不到。

第二个坑是“Skill 堆太多导致上下文被撑爆”。40 个 Skill 的描述加起来不短，有时会在会话开始阶段占用不少 token。我的解决办法是把那些低频 Skill 的描述写短一点，把关键触发词和输出格式写在最前面，这样模型扫描时开销小，匹配也更准确。

第三个坑是“旧会话里不生效”。如果你在一个已经开了很久的会话里追加 Skill，它可能不会立刻加载。这时候别硬试，退出会话重新进一下，让目录重新被扫描，基本就能解决。

5.3 避坑小技巧：维护自己的 Skill 清单

装完 40 个之后，我现在每周会花十分钟做一次“Skill 大扫除”。具体做三件事：

• 看使用频率：翻一下这周的会话记录，哪些 Skill 从头到尾没被触发过，删。
• 看使用效果：如果某个 Skill 输出质量明显不如预期，考虑是描述写得不好还是 Skill 本身设计有问题，能改描述就改描述，改不了就换。
• 看依赖是否失效：有些 Skill 依赖外部工具，如果升级了环境之后跑不起来了，及时更新或替换。

这一点我觉得很重要。很多人陷入“装得越多越好”的心态，结果就是模型经常匹配错 Skill，反而比自己写提示词还慢。Skill 的正确用法不是堆数量，而是像一个打理得很好的工具架，每样工具都在它该在的位置，你伸手就能拿到。

写在最后

把 40 个 Skill 全部装完并且实际跑了一轮之后，我最大的感受是：Claude Code 本身只是一把锋利的刀，Skill 则是各种刀法。没有刀法之前，我拿它切什么都费劲；有了刀法之后，我只需要判断眼前的食材适合哪种切法，剩下的交给它来办。如果你现在还在把 Claude Code 当普通聊天框使，我建议你花一个下午，挑三五个真正贴合自己场景的 Skill 装上，先把流程跑通，再慢慢扩到 40 个甚至更多。等你真的用顺手了，大概率也会冒出跟我一样的想法：以前那些手动敲提示词的日子，确实是白过了。