企业官网建设流程全解析

1. Claude Skills 到底是什么

我第一次接触 Skills 这个概念的时候，说实话有点懵。因为 "Skills" 这个词本身太宽泛了——你说它是能力、是插件、是扩展包，好像都能沾上边。但真正上手用了几轮之后，我的理解就清晰了：Skills 本质上是一套给 Claude 配备的专用行为包，让这个通用助手在特定任务上表现得像一位有经验的专职人员，而不是一个什么都懂一点点的"万金油"。

打个比方你就明白了。你请一个全科医生来家里，他能给你看感冒、包扎伤口、量血压，但你要是让他做一台心脏搭桥手术，他肯定不行。但如果你提前给这位医生配好一套"心外科手术专用工具包"——里面包含了手术指南、器械清单、操作流程、常见并发症处理手册——他就能在心外科场景下给出接近专科医生的表现。Claude Skills 干的就是这件事：把某个垂直领域的方法论、步骤、规则、注意事项打包成规范文件，在需要的时候让 Claude 加载并按照这套规范去执行任务。

这个功能解决了一个很实际的问题：通用大模型的"什么都懂一点"和业务场景需要的"特定领域深度专业"之间的矛盾。你可能试过靠写一大段 prompt 来约束 Claude 的行为，但 prompt 越长，前面越容易"忘掉"；每换一个任务就要重写一遍；同事之间想复用还得复制粘贴。Skills 的出现，就是为了把这些碎片化的、散落在 prompt 里的专业知识，沉淀成结构化的、可复用、可共享的模块。

适合谁来学？我觉得三类人最应该关注：

• 重度使用 Claude 做内容生产、数据分析、代码开发的人，他们被重复性问题折磨过，想让 Claude 更懂自己的业务；
• 团队管理者或技术负责人，他们想让团队每个人用 Claude 的方式统一、规范，不要十个同事十个 prompt 风格；
• 对 AI 应用层开发感兴趣的人，想理解"模型之外的能力扩展"是怎么做出来的。

三种角色视角不同，但底层要掌握的概念是同一套。接下来我把核心概念一个个拆开讲。

2. 核心构成：一个 Skills 到底由什么组成

2.1 目录结构与最小的 Skills 长什么样

一个标准的 Skills 通常是一个目录，目录名就是技能名，里面至少包含一个说明书文件。以最常见的开源风格为例，目录结构大概是这样的：

my-project/ ├─ .claude/ │ └─ skills/ │ └─ code-review/ │ ├─ SKILL.md │ └─ references/ │ ├─ checklist.md │ └─ security-rules.md

这里面最关键的就是SKILL.md。它是 Claude 读取技能时的入口文件，同时承担两个职责：告诉 Claude"这个技能是干什么的"，以及"具体怎么干"。它的头部是 YAML 格式的元信息，接着是正文。

--- name: code-review description: 对代码变更进行系统化审查，重点关注安全问题、性能隐患和可维护性。 --- # 代码审查流程 当 Claude 需要执行代码审查任务时，请遵循以下流程... ## 第一步：定位变更范围 ...

description这段非常关键——它不是给人看的，是给 Claude 看的"技能索引"。当用户提出一个需求时，Claude 会先扫描所有可用技能的 description，判断这个需求跟哪个技能匹配。所以 description 写得越具体、越贴近真实用户表达习惯，技能被正确调用的概率就越高。

如果你觉得"这不就是个 Markdown 文件吗"，那你就抓到了本质：Skills 的底层确实是文本指令，不是魔法，不是微调模型，更不是给模型加了一个秘密开关。它是通过结构化的方式，在 Claude 需要的时候，把更完整、更专业、更一致的指令上下文注入进来。

2.2 元信息：name 和 description 的设计要点

先说name。它应该简短、语义清晰，用短横线连接而不是空格。比如code-review、>description: 审查代码变更发现问题。当用户询问代码是否安全、性能如何、哪里需要改进、是否有 bug 隐患，或要求做代码评审时使用。

效果立竿见影。这里面的门道是：description 不要只描述"技能本身是干什么的"，还要列出"用户在什么场景下会触发它"。你是在教 Claude 做"需求到技能的匹配"，而不是做一个静态的功能介绍。

2.3 正文指令：技能的灵魂

SKILL.md 的正文部分是 Claude 执行任务时遵循的详细指令。这里有个体验上的关键点：写完正文之后，这个 Skills 在每一次被调用时都会把全文注入给 Claude。所以正文不需要惜字如金，但也不能啰嗦到稀释 Claude 的注意力。

我一般把正文分成三个层次：

• 流程层：完成任务要经过哪几个阶段，先做什么后做什么。这一层回答"执行路径"的问题。
• 规则层：哪些事情必须做，哪些事情绝对不能做。这一层回答"边界"的问题。
• 质量层：输出结果达到什么标准才算合格。这一层回答"交付物"的问题。

三个层次缺一不可。只写流程不写规则，Claude 可能跑偏；只写规则不写质量，Claude 交付的东西可能"流程都对但不好用"。比如一份博客写作技能，流程可能是选题—大纲—初稿—修订，规则可能是"不使用 emoji、不编造数据"，质量层则是"每段不少于 150 字、大标题必须编号"。三层叠加，Claude 的输出才稳定。

2.4 辅助资源：references 目录的用途

除了 SKILL.md，很多 Skills 还会带一个references/子目录，里面放的是各种支撑材料——核查清单、示例模板、知识文档。这里要理解一个底层机制：Claude 不会从一开始就把 references 里的所有内容都塞进上下文，而是在执行过程中需要时主动去读取。这让 Skills 既能加载大量的专业资料，又不会一次性占用太多上下文窗口。

打个比方，SKILL.md 是地图和任务书，references 是沿途可以打开的行李箱。地图告诉 Claude"走到哪一步该开哪个箱子"，箱子里的东西只在需要时展开。这种"按需加载 + 延迟展开"的设计，让技能可以做得非常厚——哪怕挂十几个参考文档，日常调用也不会有明显的性能损耗。

3. 设计思路：怎么想清楚一个 Skill 该不该做、该怎么做

3.1 Skills 与普通 Prompt、System Prompt 的边界

在动手写 Skills 之前，有个概念必须先厘清：到底什么样的能力值得做成 Skills，什么样的能力用普通 prompt 就够了？

我的判断标准有三条：

• 是否高频：这个任务你每周要触发几次？一次性的任务不值得做成技能。
• 是否复杂：任务是否需要多个步骤、多种规则、多项判断？一句话就能说清的事情，prompt 就够了。
• 是否可复用：换个项目、换个人，这套方法论是否依然适用？只绑定在某一个项目内部的流程，更适合写在项目文档里，而非做成技能。

有一个真实的例子。我做技术博客的时候，经常需要把一段零散的会议记录转成结构化文章。这件事我一开始用 prompt 干，后来发现每次都要重复描述格式要求，就把它做成了note-to-article技能。但如果是针对某一次特定活动的宣传文案，哪怕要求很细，我也不会做成技能——因为下个月活动做完就不会再用了。

那 Skills 和 System Prompt 的区别呢？System Prompt 是全局的，每次对话都会生效；Skills 是局部的，只在匹配到的任务中加载。如果你有"所有任务都要遵守"的底线规则（比如不输出违法违规内容），放 System Prompt 合适；如果你只有"做数据分析时才需要的统计规范"，放 Skills 才是对的，否则它会对无关任务产生干扰。

3.2 一个核心心智模型：Skills 是"给 Claude 看的文档"

很多人写 Skills 的姿势不对，因为他们把 SKILL.md 当成"写给人的文档"。但实际上，你的读者是 Claude，不是同事，更不是未来的自己。写给人看的文档讲究逻辑的严密性和措辞的精炼；写给 Claude 看的文档讲究指令的明确性和场景的覆盖度。

举个例子。给人看的代码审查标准会写"审查变更的合理性"，这个模糊表述人类能懂，Claude 看了就不知道具体该干什么。我会写成：

对每一处变更，依次检查： 1. 是否存在 SQL 注入风险（拼接字符串进查询语句） 2. 是否存在越权访问（接口未做权限校验） 3. 是否捕获了所有可能抛出的异常 4. 是否记录关键操作日志

每个"检查点"都要具体到 Claude 不需要猜测就能执行的程度。记住，Claude 不是不聪明，它只是不知道你在说什么"废话"之外的东西。你给它的指令越像一份可操作的 SOP，它产出的结果就越稳定。

3.3 技能之间的组织：粒度与分层

用久了，你的技能数量会膨胀。这时候就会遇到一个组织问题：技能拆得多细才算合理？

我自己的经验是：一个技能只干一件事，但这件事要足够完整。比如你做一个python-code-review和一个frontend-code-review，不如一个code-review在正文里分板块处理不同语言。反过来，把"写周报""写月报""写会议纪要"合并成一个report-writing，又会在具体场景下缺乏针对性。

一个实用的折中是"主技能 + 子参考文档"的模式：

report-writing/ ├─ SKILL.md # 通用流程：收集信息→确定格式→撰写→校对 └─ references/ ├─ weekly-template.md ├─ meeting-minutes-template.md └─ project-report-template.md

SKILL.md 负责统一流程和规则，references 为不同报告类型提供具体模板。这样既保持了技能数量的精简，又保证了每个子场景的深度。

4. 实操全流程：手把手做一个"可用"的技能

4.1 场景定义：先别急着写文件，先写一段话

做任何技能，第一步都是场景定义。我推荐一个方法：先用一段话描述"我期望用户说什么话、我期望 Claude 做什么事"。

以我做过的一个release-notes技能为例。当时的场景定义写在纸上大概是这样的：

用户会说："帮我把这次上线的内容整理成发布说明。" 用户可能还会说："写一下这周发版的重点和注意事项。" Claude 需要：读取 git 提交记录或变更清单，筛选出用户可见的功能变化，按"新功能、改进、修复、已知问题"分类，用面向用户的语气输出。

这段描述里包含了触发场景、任务目标、输出结构三个关键信息。稍后把它们分别映射到 description、流程层和质量层里。

场景定义的功夫做足了，后面的编写基本是机械工作。最忌讳的是跳过这一步直接开写，最后写出来的技能描述和实际行为对不上，调用率极低。

4.2 编写 SKILL.md：一版能直接用的模板

下面是经过多次迭代后我比较常用的 SKILL.md 模板，你可以直接复制骨架改造：

--- name: 技能英文短名 description: 一句话说清技能功能 + 列举用户可能的触发话术（"当用户...时"） --- # 技能名称 ## 触发与适用条件 明确说明 Claude 在什么输入下使用本技能，什么情况下不要使用。 ## 执行流程 ### 第一步：收集输入 需要哪些信息？如何向用户询问缺失的信息？ ### 第二步：处理分析 按照什么逻辑处理信息？有哪些判断分支？ ### 第三步：组织输出 输出格式是什么？用哪种结构？要用表格还是列表？ ## 硬性规则 - 必须遵守的事项 - 严禁出现的事项 ## 质量标准 - 哪些指标/特征代表输出合格 - 提交前自查哪些项目

注意几个细节：

• 每一步流程尽量写"怎么做"，而不是"做什么"。比如"收集输入"要写清楚"需要哪些字段、缺失时怎么询问"，而不是泛泛一句"先收集信息"。
• 硬性规则用否定句效果更好。告诉 Claude"不要输出 emoji"比"输出应保持严肃"更不容易出错。模型对否定指令的执行力比对肯定指令更强，这个经验是实测出来的。
• 质量标准里要有可量化的指标。比如"每个功能点必须对应一条变更记录""日期格式必须统一为 YYYY-MM-DD"，而不是"规范、准确"这种虚词。

4.3 References 参考文档的写法

References 里的文档，每一份都应该能被独立阅读和理解。因为 Claude "按需读取"时，读到的只有那一份文档，它不会自动联系 SKILL.md 里的其他内容。

所以每个 reference 文件的开头，我都会写一段"本文件的用途和使用时机"。比如在一份发布说明模板的开头：

# 发布说明模板 本文档用于生成标准的版本发布说明。当用户确认发布类型（正式版、内测版、 补丁版）后，按下方结构填充内容。模板中的【】处为待填写信息，填写后删除 【】符号。

这样的开头让 Claude 即使单独读到这份文档，也知道自己身处什么任务、应该做什么。

References 里放模板还有一个优点：Claude 对"填空式输出"的把握往往比自己自由发挥更准确。给模板，不是为了限制创造力，而是为了减少输出方差。实测下来，同样的需求，有模板和无模板的输出质量差距非常明显。

4.4 首次测试：验证技能有没有被正确触发

写完技能文件之后，先别急着正式用，做一次触发测试。我把测试分成三步：

1. 测试一：能不能被找到。直接用接近 description 里写的用户话术提问，比如"帮我把这次上线的变化整理一下"，看 Claude 是否表现出正在使用技能（通常它会明确提到"我将按照发布说明技能来处理"）。
2. 测试二：能不能走完流程。给一个中等复杂度的真实输入，观察它是否完整走完 SKILL.md 里设计的流程步骤，还是跳步、漏步。
3. 测试三：偏航测试。问一个跟技能无关但沾边的问题，比如"我昨天看到的代码报错是什么意思"，确认 Claude 不会错误触发这个技能。

常见的问题是：测试一就失败，也就是技能没被触发。这时候九成是 description 写得对不上用户的真实表达。解法是回到场景定义，把用户可能说的大白话原话写进 description。比如光写"整理发布说明"不行，要写"帮我把这次上线的变化整理一下""写写这周的更新日志"这种真实说法。

4.5 迭代技巧：用对话记录反推技能改进

技能不是一次性写好的。我的习惯是：用上一两周，把 Claude 表现不佳的对话保存下来，逐一分析失败原因，然后反推是 SKILL.md 的哪个环节没写清楚。

如果 Claude 忘了某个约束，就在硬性规则里把那句话用更强烈的措辞重申一遍；如果输出结构跟模板不一致，就把模板的占位说明写得更细；如果某类情况经常被误判，就在"什么情况下不要使用"里补充一条排除说明。

记住一个原则：每次只改一个变量，改完单独测试这一个点。我犯过的错误是一次性改了七八处，结果确实变好了，但根本不知道是哪一处改动起了作用，下次想复现都没法复现。

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

5.1 技能没被触发，或者触发不准确

这是最高频的问题。排查思路按顺序来：

• 检查 description 是否匹配用户表达：你是不是用了"官方语"？用户说的是大白话，description 也得是大白话。
• 检查名字是否冲突：多个技能名字相似或者 description 高度重叠的时候，Claude 会难以抉择。给每个技能划清边界，必要时在 description 末尾加一句"本技能不处理……，此类需求请交给XX技能"。
• 检查是否加载了技能：确认技能目录位置正确、文件名大小写正确。有些目录对大小写敏感，路径写错会直接找不到。

一个排查技巧：直接问 Claude "你刚才处理我的问题时，是否使用了 XX 技能？用了的话请复述技能里的关键指令。" Claude 往往会展示它实际读到的文本，你能借此确认它"看到"的和你预期的是否一致。

5.2 技能执行结果不一致，时好时坏

Skills 的底层是文本指令，所以它天然有概率性。但如果你觉得波动太大，通常不是概率问题，而是指令本身存在二义性。

排查方向：

• 把模糊形容词换成可验证的标准。"简洁"不如"不超过 200 字"；"专业"不如"必须包含数据来源和引用标注"。
• 把并列选项变成优先级。写"如果 A 和 B 冲突，优先保证 A，因为……"，给 Claude 提供冲突处理的决策依据，而不是让它自由发挥。
• 把步骤之间的依赖关系写明。"第二步的输出是第三步的输入，如果第二步没有产出，先回到第一步确认信息完整性"，这类显式连接能显著降低"跑飞"概率。

我常用的验证方法是同输入多轮测试：同一个输入跑三次，对比输出差异。差异大就说明指令约束力不足，回到上文把约束收紧。

5.3 技能目录越来越多，维护成负担

这是进阶者一定会遇到的痛点。技能数量到了十几个之后，维护成本开始超过收益。

我的做法是定期做一次"技能体检"：

体检不需要太频繁，一个季度一次足够。删技能比写技能需要更大的决心，但保持技能库的"瘦而精"，长期来看对输出质量的帮助远比数量重要。

6. 进阶心得：把 Skills 玩出花来的一些经验

6.1 先用"伪技能"跑通流程，再固化成正式技能

我有个习惯：先在普通对话里用 prompt 模拟技能流程，验证流程本身靠谱，再固化成 SKILL.md。这能避免一个尴尬情况——花了一小时写技能文件，结果发现这套流程本身走不通。

具体做法是：先用一段 prompt 把流程、规则、质量标准都写进去，跑几个真实案例看效果。如果效果不错，把这段 prompt "搬家"进 SKILL.md 再做微调；如果效果不行，直接在 prompt 层迭代到满意为止。这套方法省了我大量时间，因为 prompt 调整的反馈速度远快于技能文件调整的反馈速度。

6.2 在技能里嵌入"自检步骤"

我写技能有个保留项目：在流程最后加一个"交付前自检"小节。让 Claude 在给出最终输出之前，按照质量标准逐条自查一遍，并标注出有疑问的地方。

比如发布说明技能的自检步骤是：

自检： - [ ] 每个功能变更是否都对应了具体的原始记录编号？ - [ ] 是否有用户看不懂的术语（如有，给出解释）？ - [ ] 日期和版本号是否正确对应？ - [ ] 是否遗漏了"已知问题"板块？ 自查完成后，如果发现遗漏，主动补充后再输出。

这一个小改动让我的人工返工率降了一半。模型的自查环节不是万能的，但它能把多数低级的遗漏问题拦截在交付之前。原理也很简单：你给了它一份清单，它就会照着清单过一遍，那些"本来会忘"的细节就变"本来会查"了。

6.3 技能之间可以组合出"流水线"

单个 Skills 解决单点任务，组合起来就能解决串联任务。我目前的工作流里，note-to-article技能产出初稿之后，editorial-pass技能做润色和校对，最后publish-format技能把文章格式化成标准发布模板。三个技能各干各的，接口就是"上一步的输出作为下一步的输入"。

这个模式的爽点在于：每个技能都可以单独换掉。哪天我觉得润色效果不行，只改editorial-pass一个技能，其他环节纹丝不动。这就是模块化的价值——不需要等一个"完美的全能技能"，只需要把每个环节的小技能打磨到够用，然后串起来。

6.4 团队协作：技能是对齐认知的工具

最后说一个很多人忽略的用法：Skills 是团队对齐认知的好工具。你不需要让每个同事都懂怎么写高质量 prompt，只需要让他们使用同一个技能，输出自然就趋同了。技能文件里沉淀的是团队认可的流程、规则和质量标准，新成员加入时读一遍技能，就基本理解了团队的做事方式。

我现在的做法是：团队内部用一个共享的技能仓库，任何人在使用中发现问题，就在对应的 SKILL.md 里提修改建议，评审通过后合入主分支。技能成了活的、迭代中的团队手册。这个过程本身，比"写一份没人看的流程文档"要有用得多。

写到这里，想起我第一次建技能时犯过的错——一上来就想搞一个覆盖所有写作场景的"超级技能"，写了几百行才发现自己根本想不清楚所有场景，最后拆成五个小技能才顺过来。所以如果你也是刚开始，我的建议是：从小处着手，挑一个你每周都会干、且干得不够顺畅的任务，把它固化成第一个技能，用起来，然后让它替你工作。从一个小技能里获得的体感，比读十篇概念文章都更有价值。