企业官网建设流程全解析

1. 从"高中生都在用"说起：Claude Skills 到底是个什么东西

第一次听到"高中生都开始用 Claude Skills"这个说法，我的反应是有点不以为然——毕竟这两年 AI 工具的宣传语一个比一个夸张。但真正花了两周时间把 Skills 从概念到落地跑了一遍之后，我承认这句话虽然有点标题党，但方向没说错。它的门槛确实低到让一个会写 Markdown 的高中生就能上手，而它解决的问题，恰恰是过去一年里所有 AI 重度用户最头疼的那件事：怎么让 AI 稳定地、可复用地、按我的规矩干活。

先把概念说清楚。Claude Skills 是 Anthropic 在 Claude 生态里推出的一套"技能包"机制。你可以把它理解成给 Claude 装插件，但和传统插件不同的是，它不需要你写复杂的后端服务，也不需要你懂 API 调用协议。一个 Skill 的核心，往往就是一个叫SKILL.md的 Markdown 文件，加上若干辅助脚本、模板、参考资料。Claude 在需要的时候会自动读取这个文件，按照里面写的流程、规范、示例来执行任务。

这件事为什么重要？因为在此之前，我们让 Claude 做一件稍微复杂的事，比如"帮我把这份会议纪要整理成固定格式的周报"，通常有两种做法：一种是在对话里反复贴提示词，每次都要重新解释一遍格式要求；另一种是写一个 MCP Server，用代码把能力封装起来。前者的问题是提示词越写越长、越写越乱，换个会话就失效；后者的问题是门槛高，得会写代码、会调试协议，对非程序员极不友好。

Skills 卡在中间。它比提示词工程更结构化、更可复用，又比 MCP 开发更轻量、更接近自然语言。你写的是一个"说明书"，而不是一段"程序"。Claude 读说明书的能力本来就强，所以这套机制跑起来意外地顺。

那它适合谁？我的判断是三类人。第一类是内容工作者，比如运营、编辑、市场，天天要产出格式固定的东西，Skills 能把你的模板和规范固化下来。第二类是开发者，尤其是前端和全栈，Skills 可以封装代码规范、项目脚手架、调试流程，配合 Claude Code 用起来非常顺手。第三类是学生和研究者，做文献整理、数据清洗、报告生成这类重复劳动，Skills 能省掉大量复制粘贴。至于"高中生都在用"这个说法，我实测下来觉得不夸张——只要你会写清楚步骤，会用 Markdown，就能做出一个能用的 Skill。

这里必须先把一个容易混淆的点讲明白：Skills 和 MCP 不是一回事，也不是替代关系。MCP 解决的是"Claude 能不能连上外部工具和数据源"的问题，比如连数据库、连浏览器、连设计稿平台；Skills 解决的是"Claude 知道该怎么做事"的问题，是流程和知识的封装。一个管"手能不能伸出去"，一个管"脑子知不知道怎么做"。实际项目里，两者经常一起用：MCP 负责取数据，Skill 负责按规范处理数据。理解了这一层，后面很多设计决策就顺了。

2. 核心机制拆解：SKILL.md 为什么能指挥 Claude

2.1 一个 Skill 的最小结构长什么样

很多人以为做 Skill 很复杂，其实最小可用的 Skill 简单到让人怀疑。一个文件夹，里面放一个SKILL.md，就成立了。Claude 在运行时会扫描可用的 Skills，读取每个SKILL.md开头的元信息（通常是名称和描述），判断当前任务是否需要调用这个技能。如果需要，它就把整个文件读进来，按里面的指示执行。

一个典型的SKILL.md结构大概是这样几块：

• 元信息区：用 YAML front matter 写清楚 name 和 description，这是 Claude 判断"什么时候该用这个技能"的依据，写得越准，触发越精准。
• 角色与目标：一句话说清楚这个 Skill 是干什么的，让 Claude 建立上下文。
• 执行流程：分步骤写清楚要做哪些事，这是核心。
• 输入输出规范：明确用户要给什么、产出是什么格式。
• 示例：给一两个输入输出的样例，Claude 模仿能力极强，示例比规则更管用。
• 注意事项：边界情况、禁忌、常见错误。

我一开始犯的错是把SKILL.md写成了"需求文档"，全是抽象描述，结果 Claude 执行时经常跑偏。后来改成"操作手册"风格——每一步都是动词开头、可执行、有明确产出——效果立刻不一样。这个转变很关键：你不是在描述一个系统，你是在给一个聪明但需要明确指令的实习生写 SOP。

2.2 description 字段决定了 Skill 会不会被触发

这是最容易被忽视、但影响最大的一个细节。Claude 决定用不用某个 Skill，主要看 description。如果 description 写得太泛，比如"帮助处理文档"，那它几乎不会被精准触发，或者在不该触发的时候乱触发。如果写得太窄，又可能该用的时候用不上。

我的经验是，description 要包含三个要素：做什么、什么场景下用、产出什么。举个例子，一个整理周报的 Skill，description 可以写成："将零散的每日工作记录整理成结构化周报，适用于用户提供多条工作流水、需要按项目分类汇总的场景，输出包含本周完成、进行中、风险项三部分的 Markdown 周报。" 这样 Claude 一看就知道什么时候该调用。

实测下来，description 里带上具体的触发词（比如"周报""工作记录""汇总"）命中率会明显提升。这跟搜索引擎的关键词逻辑有点像，但更依赖语义匹配，所以自然语言写清楚比堆关键词更好。

2.3 Skills 和 Claude Code、MCP 的协作关系

把这三者的关系理清楚，能省掉很多弯路。Claude Code 是命令行/桌面端的开发环境，它本身支持加载 Skills；MCP 是连接外部能力的协议；Skills 是流程知识。三者组合起来的典型场景是这样的：

你在 Claude Code 里说"帮我把这个 Figma 设计稿转成前端组件"。Claude Code 通过 MCP（比如设计稿平台的 MCP）拿到设计数据，然后调用一个前端开发的 Skill，这个 Skill 里写清楚了项目的组件规范、命名约定、样式方案、目录结构，Claude 按规范生成代码。整个过程里，MCP 负责"拿到设计稿"，Skill 负责"知道怎么写出符合团队规范的组件"。

没有 Skill 会怎样？Claude 也能生成代码，但每次风格都不一样，命名随缘，目录乱放，你还得手动改。有了 Skill，产出的一致性大幅提升。这就是 Skills 的核心价值：把"每次都要重新交代的规矩"变成"一次写好、永久生效的标准"。

3. 从零做一个 Skill：完整实操流程

3.1 环境准备与 Claude Code 安装

先说环境。Skills 本身是纯文本，理论上任何能编辑 Markdown 的地方都能写。但要真正跑起来、调试、验证，还是建议用 Claude Code。安装方式根据系统不同略有差异，主流的是通过包管理器安装命令行版本，或者用桌面版。

安装完成后，第一件事是确认 Skills 的存放目录。不同版本的 Claude Code 目录约定可能不同，常见的是在用户主目录下的配置文件夹里，比如.claude/skills/这样的路径。每个 Skill 一个子文件夹，文件夹名就是 Skill 的标识。我建议一开始就养成规范命名的习惯，用英文小写加连字符，比如weekly-report、frontend-component，避免中文和空格，省得后面路径出问题。

提示：安装过程中如果遇到系统组件相关的报错，先确认系统版本和依赖是否满足要求，很多"装不上"的问题其实是环境没到位，而不是工具本身的问题。

装好之后，可以先用一个最简单的 Skill 验证链路通不通。建一个文件夹，写一个只做一件事的SKILL.md，比如"把用户给的文字转成大写"。然后在 Claude Code 里触发它，看能不能正常调用。这一步跑通，后面就都是内容活了。

3.2 写第一个 SKILL.md：以"会议纪要转周报"为例

我拿一个真实需求来演示：把零散的会议纪要整理成固定格式的周报。这个需求足够典型，几乎每个职场人都有。

第一步，确定 Skill 的边界。它只做"整理和格式化"，不做"内容创作"，也不做"发送"。边界清晰，Claude 才不会越界。

第二步，写元信息。name 用meeting-to-weekly，description 写清楚触发场景和产出。

第三步，写执行流程。我把它拆成五步：读取用户提供的所有纪要、按项目归类、提取每条的结论和待办、按周报模板组织、输出 Markdown。每一步都写清楚"做什么"和"产出什么"。

第四步，给模板。直接把周报的 Markdown 骨架贴进去，Claude 照着填就行。

第五步，给示例。放一组输入输出对照，这是提升稳定性的关键。

第六步，写注意事项。比如"如果某条纪要没有明确结论，标注为待确认，不要自行编造"、"待办事项必须带负责人，没有负责人的标注为未指派"。

写完这个 Skill，我实测了十几次，前几次输出还有点飘，调整了 description 和示例之后，稳定性明显上来了。这里的心得是：示例的质量直接决定输出的质量，与其写一堆规则，不如给两三个高质量的例子。

3.3 参数与格式规范：让输出可预测

Skills 里最值钱的部分，其实是"规范"。因为 Claude 本身能力够强，你不需要教它怎么写字，你需要教它"按什么格式写"。所以格式规范要写得极其具体。

比如日期格式，不要写"用标准日期"，要写"统一用 YYYY-MM-DD"。比如标题层级，不要写"分层次"，要写"一级标题用 ##，二级用 ###，最多到三级"。比如列表符号，统一用-，不要混用*和+。

这些细节看起来琐碎，但正是它们决定了产出能不能直接用。我踩过的坑是：早期 Skill 里没规定标点，结果 Claude 一会儿用中文标点一会儿用英文标点，复制到正式文档里还得手动统一。后来在 Skill 里加了一条"全文使用中文标点，代码块内除外"，问题就没了。

还有一个技巧是用表格把规范列出来。比起大段文字描述，表格更清晰，Claude 读取时也更不容易漏。比如：

这种表格放在SKILL.md里，效果比写十句话都好。

3.4 调试与迭代：怎么知道 Skill 写得好不好

Skill 写完不是终点，调试才是重头戏。我的方法是准备一组"测试用例"——五到十个典型输入，覆盖正常情况、边界情况、异常情况。每次改完 Skill，都跑一遍这组用例，看输出是否稳定。

判断标准有三个：格式是否一致、内容是否准确、边界是否处理得当。格式不一致，说明规范没写清楚；内容不准，说明流程有歧义；边界处理不好，说明注意事项没覆盖到。

迭代的时候，优先改 description 和示例，这两块对结果影响最大。流程和规范是其次。我见过有人花大量时间优化流程描述，结果 description 写得含糊，Skill 根本触发不了，白费功夫。

注意：不要指望一次写出完美的 Skill。好的 Skill 都是迭代出来的，第一版能跑通就行，后面根据实际使用中的问题慢慢补。我现在的习惯是，每次用 Skill 发现一个不满意的地方，就顺手在SKILL.md里加一条规则，积少成多，几个月下来就非常成熟了。

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

4.1 Skill 不触发或者乱触发怎么办

这是最高频的问题。表现是：明明写了 Skill，Claude 却不用；或者在不相关的任务里乱用。

排查思路分三步。第一，检查 description 是否清晰。把 description 单独拿出来读一遍，问自己"只看这句话，我知道什么时候该用它吗"。如果答案是否定的，就是 description 的问题。第二，检查 Skills 目录路径是否正确，Claude 有没有扫描到。第三，检查是否有多个 Skill 的 description 语义重叠，导致 Claude 选择困难。

解决办法：description 里加入明确的触发词和排除条件。比如"当用户提到周报、工作汇总、周总结时使用；当用户只是询问单个任务状态时不要使用"。这种正反两面的描述，能显著提升触发准确率。

4.2 输出格式总是不稳定

格式飘是第二高频问题。根因通常是规范写得太抽象，或者示例不够。

我的排查清单是这样的：

实测下来，把这张表里的每一项都在 Skill 里写死，格式稳定性会有质的提升。核心逻辑是：凡是你能想到的"可能不一致"的地方，都提前规定死。

4.3 Skills 和 MCP 该用哪个

这个问题我被问过很多次。判断标准很简单：如果这件事需要连接外部系统取数据或执行操作，用 MCP；如果这件事是"知道怎么做"的流程和知识，用 Skill。

举个例子，"从数据库查销售数据"是 MCP 的活，"把销售数据整理成分析报告"是 Skill 的活。两者经常配合使用。如果你不确定，就问自己：这件事需要"伸手"吗？需要就是 MCP，不需要就是 Skill。

还有一点要注意：MCP 的配置通常涉及连接信息、权限、协议，门槛比 Skill 高不少。如果一件事用 Skill 能解决，就别上 MCP，杀鸡不用牛刀。

4.4 常见坑与避坑清单

最后整理一份我踩过的坑，供参考：

• Skill 名字用中文或空格：路径容易出问题，坚持用英文小写加连字符。
• description 写得太长：Claude 判断时反而抓不住重点，控制在两三句话。
• 流程步骤太抽象：每步都要有明确产出，动词开头。
• 没有示例：示例是稳定性的命根子，至少给两个。
• 一次改太多：改完不知道是哪条起的作用，一次改一个变量。
• 忽略边界情况：输入为空、格式错误、信息缺失，都要在 Skill 里写明怎么处理。
• 把 Skill 当代码写：它是给 AI 看的说明书，不是给编译器看的程序，自然语言写清楚就行。

我个人在实际操作中的体会是，Skills 这套东西最大的价值不在于"让 AI 更聪明"，而在于"让 AI 更听话"。它把过去散落在各个对话里的提示词、规范、模板，收敛成一个个可复用、可维护、可分享的文件。你花一个小时写一个好的 Skill，可能省下的是未来几十个小时的重复沟通。对于天天和 AI 打交道的人来说，这笔账怎么算都划算。至于"高中生都在用"——等你写完第一个 Skill，大概就明白为什么了。