企业官网建设流程全解析

每天都要花十分钟告诉 AI "你是谁、要干嘛、输出什么格式"的人，一定会在看到 Claude Skills 的那一刻拍大腿：这不就是我一直在手动做的事吗？

作为一个几乎把 Claude 当成第二个工作台来用的人，我过去一年里最大的时间黑洞，不是写需求、不是调代码，而是反复向 AI 解释规则。每次换新对话，我都得像第一次见面一样，把我的身份背景、任务要求、输出格式、禁忌事项重新说一遍。后来我甚至把这段"自我介绍"存成了一个长文本，每次对话开头直接粘贴，结果它越来越长，越来越难维护，还会在复制粘贴的过程中莫名弄丢几行关键规则。

Claude Skills 解决的就是这个问题。它把"身份设定 + 执行步骤 + 输出规范 + 质量检查清单"打包成一个独立的技能文件，放进指定目录后，Claude 就能在相关任务出现时自动调用，或者在对话里直接唤起。这相当于给 AI 装了一本可随时翻阅的岗位手册，而不是只给它一句口头交代。这篇文章我会从原理、编写方法、真实场景、避坑经验一路讲到我自己的技能管理节奏，看完你就能自己动手写一套趁手的技能包。

1. 为什么需要把"说话方式"打包成技能文件

1.1 我每天重复的那句提示词，就是最早的"技能"

你回想一下自己平时是怎么用 AI 的。是不是经常这样开头："你是一个资深的公众号编辑，请帮我写一篇关于XX的文章，要求标题吸引人、正文口语化、段落不能太长，最好再给三个备选标题。"这种提示词说得好听叫"自定义指令"，说得直白点就是一次性的口头交代。

问题在于，每次开新对话，这个口头交代都要重新来一遍。哪怕你已经把这句话优化得非常完善，换一个会话又要重新粘贴。更麻烦的是，如果你今天既要写公众号文章，又要做会议纪要，还要审一段代码，你要么在同一个对话里反复切换角色，要么开好几个对话分别解释规则。前者会让上下文变得混乱，后者则是一遍遍重复劳动。

我有一段时间就是这么干的。写文章用一个固定开头，写周报用另一个固定开头，做竞品分析再用第三个固定开头。每次粘贴大段提示词的时候，我心里都在想：这些东西本质上不就是一个"技能"吗？为什么不能让 AI 自己记住呢？当时我也尝试过把提示词保存成笔记文件，需要的时候打开复制，但复制模板的过程依然很烦，而且模板本身也会过期。

1.2 Claude Skills 到底改变了什么：从"临时指令"到"可复用资产"

Claude Skills 出现之后，我整个使用习惯都被重构了。它的逻辑其实很简单：把一段完整的"工作方法"写成一个 Markdown 文件（核心文件名通常叫 SKILL.md），放到 Claude 能读取的技能目录里。以后当我让 Claude 做某类事情时，只要对话内容跟技能的描述能匹配上，它就会自动加载这个技能文件，然后按文件里写好的流程来执行。

这个转变看起来只是把"粘贴提示词"变成了"保存技能文件"，但本质上是两套完全不同的心智模型。过去我的提示词是放在对话里的，它是上下文的一部分，会随着对话变长而稀释，也会因为后面聊了别的事情而"跑偏"。而技能文件是放在对话之外的，它像一份固定的操作规程，Claude 每次执行任务时都能回到文件本身去查阅，不会因为聊了半小时天气就把你的输出规则忘掉。

另一个核心区别是复用性。一个写好的技能文件，不仅能在你自己的所有对话里被调用，还能复制给别人，或者从社区里安装别人做好的技能。我第一次从朋友那里拿到一个做会议纪要的技能时，感觉就像拿到了一份免费的岗位培训手册——里面不仅写了纪要格式，还写了怎么提炼决策项、怎么区分"待办"和"知会"。这种东西，靠口头提示词是很难完整传递的，因为它太长了，长到没人愿意每次手打一遍，而技能文件天然就是为了承载这种长度的。

2. Claude Skills 与一堆相关概念的边界：别把它们混为一谈

网上讨论 Claude Skills 的时候，经常有人把它和自定义指令、MCP、Project 混在一起说。我在实际使用中踩过不少混淆的坑，这里把边界彻底捋清楚。

2.1 它和自定义指令（Custom Instructions）的差异：粒度完全不同

自定义指令是全局的，一旦设置好，它会在你所有对话里默默生效，相当于给 AI 设定了一个"基础人格"。它的优势是省事，劣势也正是因为它太全局了——你今天聊编程，它带着"你的文风要轻松活泼"这种全局设定；明天聊数据分析，它还是带着这套设定。

Skills 则完全不同。它是按需触发的，一个技能只负责一个特定场景，彼此之间互不干扰。我可以同时装"代码审查技能""周报生成技能""文章润色技能"，这三个技能可以有不同的角色设定、完全不同甚至互相矛盾的输出要求，但只要触发条件设置得合理，它们就不会打架。

打个比方：自定义指令像是给员工统一配发的工牌，上面写的是公司价值观；而 Skills 像是不同岗位的操作手册，财务有财务的SOP，运营有运营的SOP。空泛的价值观不能替代具体的操作手册，反过来也一样。

2.2 它和 MCP / 工具调用的关系：Skills 不是工具，是"用工具的说明书"

很多人第一次接触 Skills 时，看到里面可以指定要调用外部工具，误以为 Skills 就是 MCP（模型上下文协议）或者说是某种工具插件。实际上这俩是完全不同的层次。

MCP 或者普通的工具调用，解决的是"AI 能操作什么外部系统"的问题，比如读数据库、调API、查文件。它像是给 AI 接上了手和脚。Skills 解决的是"AI 应该怎么思考和干活"的问题，它定义的是流程、规则、判断标准、输出模板，相当于给 AI 一份"用脚手做事的方法论"。

更好的理解方式是：工具给你的是可能性，技能给你的是纪律。比如我电脑里装了一个可以跑代码的工具，如果没有技能约束，AI 可能会写一段能跑但是毫无代码风格可言的脚本；而一旦我加载了"项目代码规范技能"，它就知道跑测试之前先看 lint，提交代码之前要先写 changelog。工具本身不会教它做这些事，这些只能靠技能文件里的文字规则来约束。

2.3 它和 Project（项目）的差异：一个打包给工作区，一个打包给模型

如果你用过 Claude 的 Project 功能，可能也疑惑过：Project 里也能配置指令和知识库，是不是有 Skills 就够了？我的体会是，两者解决的问题完全不同。

Project 更像是围绕一个具体工作建立的"信息环境"。你可以在里面放参考文档、设定这组对话的知识背景，让 Claude 在这个项目的语境里干活。它的核心是"信息"——和这个项目相关的资料都堆在这里。而 Skills 的核心是"行为"——不管在哪个项目里，只要需要做这类任务，这套行为标准都能通用。

一个典型的例子：我写代码时会遇到两个项目，一个用 React，一个用 Vue。它们都有自己的 Project，里面放了各自的技术文档。但"代码审查"这个行为，在两个项目里是高度相似的：都要检查边界条件，都要看错误处理是否完整，都要确认命名规范。所以"代码审查技能"只需要写一份，放在全局技能目录里，任何项目都能用。Project 管的是"你在做什么"，Skills 管的是"你该怎么做"。

3. 手把手编写第一个 Skill：从需求拆解到文件落盘

下面这部分是重点。我会拿"会议纪要技能"来做例子，完整走一遍从需求拆解到文件写好的全过程。

3.1 准备工作：搞清楚 Claude Skills 的存放位置与结构

不同客户端安装 Skills 的入口有差异，但绝大多数情况下，技能都是放在某个固定的目录下的，比如~/.claude/skills/这一类路径。每个技能占一个文件夹，文件夹名字就是技能名，里面至少有一个 SKILL.md 文件。你也可以在同一文件夹里放一些辅助文件，比如示例数据、提示词模板、参考范文等，这些文件在技能被触发时同样会被加载，供模型查阅。

如果你是第一次接触，建议先别急着手工建目录，先在 Claude 的设置界面里找到技能管理入口，看看当前版本支持的目录路径和命名规范。不同版本的入口位置可能不一样，但机制基本一致：你需要在指定目录下创建"一个技能一个文件夹"的结构。

示例结构如下：

~/.claude/skills/ ├── meeting-notes/ │ ├── SKILL.md │ └── template.md ├── code-reviewer/ │ └── SKILL.md └── writing-assistant/ └── SKILL.md

也就是说，meeting-notes这个技能文件夹里可以只放一个 SKILL.md，也可以再加一个 template.md 作为纪要模板。文件放好后，到设置里刷新一下技能列表，就能看到新技能了。

3.2 第一步：把任务场景拆成"触发条件、执行步骤、输出模板"三块

任何技能在动笔写之前，都要先想清楚三件事：什么时候用它、做了哪些步骤、最后交付什么。我习惯用一个很笨的办法：先不开技能，直接手动开一个对话，以"正常聊天"的方式让 Claude 帮你处理一次这个任务，然后把过程记录下来。记录时特别留意这三个环节。

以会议纪要为例。触发条件很简单：用户提供一段会议录音转写文本，或者粘贴一堆聊天记录，并明确说"帮我做会议记录"。执行步骤则可以拆成：先通读全文，提取参会人和讨论主题；然后按议程梳理讨论过程；最后标记结论、待办事项、负责人和截止时间。输出模板则是一份标准的会议纪要格式：会议主题、时间、参与人、讨论要点、决策项、行动项。

为什么要在动手写之前先拆这三块？因为技能文件最容易犯的错就是"只写目标不写步骤"。如果你只在文件里说"你是一个会议纪要助手"，模型确实能干活，但它的干活方式每次都会漂移。只有把步骤和模板都写清楚了，输出质量才能稳定。

3.3 第二步：在 SKILL.md 里写清楚人设规矩与心法

SKILL.md 本质上就是一个 Markdown 文件，前半部分通常有一段元信息描述，用来说明这个技能的名称和用途；后半部分是正文，也就是你要交给 Claude 的具体指令。我可以给你一个可以直接套用的骨架：

--- name: meeting-notes description: 当用户需要整理会议记录、生成纪要、提取行动项时使用。适用于会议录音转写、聊天记录整理等场景。 --- # 角色 你是一位经验丰富的会议纪要整理专家，擅长从冗长混乱的对话中提炼有效信息。 # 执行步骤 1. 通读用户提供的全部对话内容，识别会议主题和参会人。 2. 按讨论顺序梳理主要议题，删除与议题无关的闲聊内容。 3. 对每个议题提炼讨论要点，标注出各方观点和分歧。 4. 识别明确的结论和待办事项，整理成行动项表格。 # 输出格式 输出一份结构化的会议纪要，包含以下章节： - 会议主题 - 参会人 - 讨论要点 - 结论与决策 - 行动项（含负责人和截止时间） # 注意事项 - 如果原文中没有明确截止时间，不要编造，标注"待确认"。 - 行动项要具体到负责人，找不到负责人的写"待指派"。 - 保持客观中立，不使用口语化评价。

写这份文件最核心的心法是：把你自己希望 AI 怎么做事的标准，都变成明确的句子，而不是模糊的形容词。不要写"要专业"，要写清楚什么叫专业：比如"结论要和讨论过程分开"、"行动项必须包含负责人"。技能文件不怕啰嗦，怕的是含糊。

3.4 第三步：用实际对话反复测试、迭代版本

写完第一次版本之后，一定不要直接宣布成功。我每次新写一个技能，都要准备一组真实的历史数据来测。比如写会议纪要技能，就找一段以前开会的对话记录喂进去，看输出是不是符合预期。

测试时重点关注三个维度：第一，技能有没有被正确触发。如果我在对话里只说"帮我总结一下这段聊天记录"，没提"会议"两个字，它还会不会主动加载这个技能？第二，执行步骤有没有被完整走完。如果模型看到步骤一就直接跳到输出，说明步骤写得太轻。第三，输出格式是否完全遵守。有些技能写得很细，模型却容易在最后一个环节放飞自我，这时候就该把输出模板的示例放在显眼位置。

迭代不是一次性的。我用一个新技能的前两周，基本上每隔几天就会改一次 SKILL.md：要么是把新增的例子补充进去，要么是删掉那些让 AI 过度发挥的啰嗦指令。这个习惯比写作本身更重要。

4. 几个真实场景的 Skills 示例与拆解

光讲方法论很难让人真正上手，我把我常用的几个技能拆开来展示一下。不是让你照抄，而是看一个成熟的技能文件长什么样。

4.1 编程代码审查技能

我做代码审查技能时，最核心的写法是"把多年的 code review 经验变成可检查的清单"。单纯说"请审查这段代码"是没有意义的，模型只会给你一些正确的废话。所以我把审查过程拆成了几个层次：

--- name: code-reviewer description: 当用户提供代码片段或 PR 变更，要求审查代码质量时使用。 --- # 执行流程 1. 先通读代码，理解功能意图，直到能用自己的话概括这段代码要做什么。 2. 检查正确性：边界条件、空值处理、异常分支是否完整。 3. 检查可维护性：命名、函数拆分、重复代码、注释质量。 4. 检查性能隐患：不必要的循环、明显的重复计算。 5. 输出分级问题列表：严重问题、建议修改、风格优化。

这是最有价值的一步：不要直接让 AI 输出"代码很好"或者"有几个小问题"，而是规定它先理解再检查再分级输出。分级列表非常关键，否则所有问题都会被平铺成一大段，项目经理根本没法判断优先级。

4.2 个人周报生成技能

周报技能是我用得最频繁的一个。它最大的难点不是格式，而是"如何从一堆工作记录里识别值得一提的成果"。我的技能文件里专门有一段写"筛选标准"：只有对业务有明显改进、或者解决了关键问题的工作，才值得写进重点成果；零散的日常沟通不算成果。

这个筛选标准如果不写清楚，AI 就会把所有事情都平铺直叙地列进去，周报变成了流水账。而一旦写清楚，AI 就会主动帮你做增量筛选。所以你看，技能文件里的"心法"往往比步骤更值钱。

我还在技能里加了一个强制规则：最终输出的周报里，至少要有一个量化指标，实在没有量化条件的就写"进度状态"，不能写"正常推进"四个字敷衍过去。

4.3 内容平台风格化写作技能

做内容的人应该都会喜欢这个场景。我给 AI 设计写作技能的时候，刻意规避了"写一篇爆款文章"这种空泛目标，而是把风格拆成了非常具体的约束条件。

比如我写小红书风格的技能时，文件里会规定：开头前两行必须出现"你也能用"这种利他感很强的句子；正文必须分成短段落且每段不超过三行；结尾必须引导用户收藏或关注，但不能用"家人们"这种烂大街说法。你看，这些约束看起来很小，但它们加起来就决定了一篇文章是否像真人写的。

一个很重要的经验：风格类技能要多给正反例。我在 SKILL.md 里专门放了两段对比示例：一段是"看了就划走的机械文案"，一段是"让人愿意读到底的自然文案"，然后告诉 AI 输出要靠近后者。模型看到具体例子之后，风格还原度会明显高于只听抽象描述。

4.4 数据整理与报表技能

数据清洗这类技能和前面几种不同，它更依赖确定的规则。我做一个周期性销售数据整理技能时，把步骤写成了几乎接近程序逻辑的流程：先识别表头，再检查缺失值和空值，再按指定维度做透视汇总，最后生成结论摘要。

这种技能最大的坑是：模型会在默认情况下帮你"脑补"数据。比如某一列数据缺失了，它可能默认按零处理，然后在结论里告诉你"同比上升"。所以我在这类技能的注意事项里永远会写一句：任何缺失值必须在输出中明确标出，禁止猜测补全；所有计算必须显示计算依据。

我建议你做类似技能时，把"不许做什么"放在"要做什么"的前面。数据类任务的容错率很低，防呆规则比效率规则更重要。

5. 安装、切换、共享：Skill 的日常管理与避坑

5.1 从社区安装 Skill 时的资质审查要点

现在网上已经有不少人分享自己的技能文件，可以直接克隆到目录里使用，但千万别看到一个标题就无脑安装。我身边就有朋友因为装了一个"万能提示词技能"，结果后续对话质量反而严重下降，因为那个技能文件里写了一大堆互相矛盾的规则。

从陌生来源安装技能时，我必做三件事：第一，打开 SKILL.md 全文通读，看它的指令是不是和你的使用场景匹配；第二，特别留意有没有"忽略之前的指令"这类改写性描述，这种句子要么是调试残留，要么是刻意做Prompt注入攻击；第三，先在一个非关键任务里测试一轮，不要直接让它在重要任务中生效。技能文件本质上是可执行的行为逻辑，它的重要性相当于一个脚本，你不能运行不看内容的脚本。

5.2 为什么"技能没生效"往往不是格式问题而是触发问题

通常在社区里最常见的求助帖是："我已经把技能放到目录里了，刷新也刷新了，但它就是不触发。"这种情况九成不是文件格式问题，而是描述信息没写好。

技能触发靠的是 SKILL.md 头部的 description 字段与用户对话之间的语义匹配。如果你把 description 写得太窄，比如只写了"当用户提到周报两个字时使用"，那用户实际说的是"帮我写一下本周工作总结"，技能就不会被唤起。反过来，如果 description 写得太宽，比如动不动就写"所有分析任务都使用本技能"，那么它会被频繁误触发，后面你还得手动关闭，更麻烦。

我的经验是：description 里必须写至少两个常见的同义说法，宁可多列几种表达方式，也不要漏掉用户可能会说的一个词。触发逻辑是语义匹配不是关键词匹配，所以写得太死的效果更差。

5.3 最容易把技能写烂的三种错误写法

我看了不下几十份别人写的 SKILL.md，总结了三种最常见的翻车写法。

第一种是功能堆叠。一个技能文件夹里既写代码审查，又写简历制作，还指导用户怎么养猫。模型加载这个技能后，反而不知道该优先执行哪套规矩。技能一定要窄，一个技能只负责一类任务。

第二种是只给目标不给流程。比如"你是资深运营，请把文章改得更好"，这句话放在技能文件里等于没写。模型确实能改，但它不知道怎么改才算"更好"，输出只能靠猜。好的技能要有可以逐步执行的步骤，哪怕是"先列出现有标题，再写五个优化方向，再选择最优"这样简单的流程。

第三种是没有任何约束条件。技能文件只告诉模型"做什么"，完全没写"不做什么"。这会导致 AI 在边界处放飞自我。比如写作技能没写"不要编造数据和案例"，AI 就可能在文章里虚构一个不存在的调查结果。约束和步骤同样重要。

6. 我的实战心得：值得构建的"技能矩阵"和迭代节奏

6.1 不同身份角色的技能矩阵建议

如果你还是不知道从哪下手，我建议别一次性写十个技能，而是先想想自己一周之内重复了哪些"明明做过很多次、却每一次都要重新讲一遍规则"的事。这些事情才是你第一批发力点。我从不同角色角度给你列一个参考矩阵。

内容创作者可以优先做：文章风格化写作、标题生成、选题头脑风暴、竞品拆解。程序员可以优先做：代码审查、错误信息解读、重构建议、commit message 生成。运营岗可以优先做：活动复盘、数据周报、用户反馈归类。研究者可以优先做：文献摘要、论点梳理、报告润色。

这些技能有一个共性：它们都是"骨架稳定但内容多变"的任务。所谓骨架稳定，指的是你每次都要遵循同样的步骤和输出规范；内容多变则是说每次处理的具体材料不同。这种任务特别适合做成技能，因为你的经验可以直接沉淀成规则，减少每次从头思考的成本。

6.2 我的迭代节奏：先手动跑通，再固化成技能

最后聊聊我自己管理技能的节奏。我现在不会看到一个新场景就立刻写技能，而是坚持一条简单原则：同一个任务类型，如果我在两周之内手动做了三次以上，我就会专门开一个对话，先手动把流程走一遍，然后把每一步需要 AI 执行的规则记录下来，整理成 SKILL.md。

这看起来比直接套用网上的模板要慢，但它有一个巨大的好处：你写出来的技能文件是从真实需求里长出来的，它只包含你真正用得上的规则，不会有一堆看着有用但实际用不上的花哨配置。我的技能目录里也淘汰过很多版本，每次淘汰都不是因为功能坏了，而是因为我在真实使用中发现那个技能被调用得太少，不值得维护。

现在每次想写新技能时，我都会先问自己一句：这个流程如果一周要做两次以上，我就该固化下来。如果一个任务只是偶尔做一次，那就让 AI 用通用能力自由发挥吧，技能带来的稳定反而会变成拖累。真正好的技能库，永远是在"够用"和"简洁"之间找到了自己的平衡。