企业官网建设流程全解析

Claude的Agent Skills（大家习惯直接叫SKILL）是我最近几个月用得最多的功能，没有之一。Anthropic官方发布过一套推荐做法，我反复读了几遍，又拿真实项目试了好几轮，发现真正让SKILL好用起来的关键，其实就藏在三个地方。这篇文章不打算复述文档，直接把提炼出的三个技巧、背后的逻辑，以及我踩过的坑一次性讲清楚。不管你是刚接触SKILL的新手，还是已经在用它搭复杂工作流的老手，这篇都值得花十分钟看完。

先给没接触过的人一句话解释：SKILL就是把一套完整的领域知识、操作规范、参考文件和审查要点打包成一个文件夹，让Claude在需要时自动加载，按照你定义的方式输出结果。它和普通提示词最大的区别在于可复用、可分发、可版本管理——你写好一次，之后任何对话里都能反复调用，也能丢给团队其他人直接用。我把它理解成给Claude装上一个"岗位说明书"，AI每次上岗前先读一遍规则，再开始干活。

这三个技巧分别是：用描述事实代替下达命令、用渐进式披露组织SKILL目录、像调试代码一样迭代SKILL。下面一个个拆开讲，每个部分都附上了可以直接抄走的写法和真实案例。

1. 先搞清楚SKILL的底层逻辑

1.1 SKILL到底是什么，它和Workflow有什么区别

很多朋友一上来就把SKILL和coze、dify里搭的工作流等同起来，这是个很普遍的误解。工作流是把操作步骤画成节点图，每个节点做什么、下一步跳到哪，全部写死，本质上是一套自动执行流水线。SKILL完全不是这个思路——它不是一条固定路径，而是一份"领域说明手册"。

Claude拿到你的SKILL后，会理解其中的规则和目标，然后自己决定怎么调用这些知识去完成任务。举个例子：简历筛选工作流里，每个节点可能固定是"提取信息→匹配关键词→输出评分"；而简历筛选SKILL只需要说清楚"技术岗简历重点看哪些能力、哪些信号值得警惕、评分标准是什么"，Claude自己会规划怎么读简历、怎么判断，甚至你给一份缺胳膊少腿的简历，它也知道想办法处理。

这个区别决定了设计思路完全不同。做工作流你关心的是"节点之间的连接对不对"，做SKILL你关心的是"描述是否足够清晰、信息是否足够完整"。刚开始写SKILL的人最容易犯的错，就是把SKILL当成一组if-else命令来写，结果Claude执行得很僵硬，换个场景就失灵。

1.2 官方推荐思路的底层三个原则

我看了Anthropic对SKILL设计的推荐做法，拆解下来核心是三个原则：

第一个是单一职责。一个SKILL只做一件事，把这件事做透。比如"简历筛选"是一个职责，"面试问题生成"是另一个职责，不要揉在一起。这和我们写代码的高内聚低耦合是一个道理，SKILL保持单一职责，Claude加载时指令意图才不会被稀释。

第二个是渐进式披露。SKILL.md这个入口文件只放精简的索引和说明，把冗长的规则、模板、评分细则拆到子文件里，Claude真正需要时才读取。这个技巧能显著减少每轮对话占用的上下文窗口，让模型不把"理解规则"的算力浪费在无关细节上。

第三个是迭代演进。官方推荐先做一个能跑通的最小版本，然后根据真实使用中的失败案例逐步补充。一次做到完美是不可能的，最好的做法是让它先"够用"，再慢慢"好用"。这三条原则贯穿全程，后面三个技巧其实就是它们的落地手法。

2. 技巧一：用"描述事实"代替"下达命令"

2.1 为什么命令式指令会失败

我见过大量刚上手的人这么写SKILL：

当用户提供简历时，你需要：第一步提取姓名，第二步提取工作年限，第三步根据年限打分，第四步输出结果。

这种写法看上去逻辑清晰，实则在跟Claude说"你按我的代码执行"。问题在于，真实场景往往比你的预想复杂——简历格式五花八门，有人写"5年Java经验"，有人写"Java开发，2019年至今"。如果你把步骤锁死，Claude遇到规则没覆盖到的形式就抓瞎，不知道怎么写年份、怎么折算年限，只能硬套导致错误输出。

用描述的思路改写一遍：

技术岗位简历的筛选重点是候选人的编程语言经验、项目复杂度、以及技术栈匹配度。工作年限的表达方式多样，可能为区间、起止年份或月数，需要统一折算为"满X年"口径。产出意见时，需同时给出与岗位描述的匹配程度说明和推荐建议。

区别很明显：第一种告诉Claude"怎么做"，第二种告诉Claude"这个领域是什么样的、重点关注什么、标准是什么"。Claude本身是推理模型，你给它完整的领域图景，它自己会生成比固定步骤灵活得多的执行路径。

2.2 描述式指令的三种写法模板

我总结了三种经过实测有效的描述式写法，也是官方推荐里隐含的套路：

第一种是建立领域全貌。不要急着写流程，先写清楚你的领域是什么、核心目标是什么、常见的边界条件有哪些。比如做项目复盘SKILL，就要写清楚复盘关注的维度、团队角色视角、对事的评价不对人的评价等等。

第二种是定义好与坏的边界。直接告诉Claude什么样的产出是合格的、什么样的信号要警惕。比如简历筛选SKILL里，写清"工作经历频繁短跳"是需要注意的信号，比单纯命令它"检查跳槽频率"效果好得多。

第三种是给出优质范例。在SKILL里放一两份完整的示例输出，让Claude在看到真实参照物的情况下模仿格式和深度。示范的作用远大于指令，我用过几次后发现，放一份范例之后输出质量立刻提升一个档次。

2.3 写完SKILL后自查三个问题

每次写完SKILL.md，我在发布前都会强制过一遍三个自查项，也推荐你试试：

第一个，全文有没有"当...时，你需要"这类硬编码句式？有的话，琢磨下能不能改成描述场景和判断标准，让Claude自己推导动作。

第二个，如果换一个表达方式完全不同的输入，这个SKILL还能不能正确触发？如果它依赖具体措辞才能工作，说明描述不够通用。

第三个，删掉所有步骤性文字后，规则表达还剩多少信息量？大量细节的丢失意味着你过度依赖流程，没把领域知识写透。

这个自查过程大概花费五分钟，但每次都能抓出几个导致输出僵硬的句式，值得养成习惯。

3. 技巧二：用"渐进式披露"组织SKILL目录

3.1 为什么不能把SKILL写成一本百科全书

我在早期踩过一个大坑：为了让SKILL"功能强大"，我把所有规则、模板、FAQ全部塞进了SKILL.md，写了将近三千字。结果Claude每轮对话处理时都要消耗巨大的上下文去理解这些内容，反而导致核心任务上的表现变差。这就像给新员工上岗前丢给他五百页的员工手册，等他想找关键操作时早被淹没在细节里了。

Anthropic官方推荐的思路正好相反：SKILL.md只承载核心索引和触发条件，好比前台接待，负责判断"谁来、什么事、该引导到哪个部门"。详细的评分标准、背景知识、处理模板都放在子文件里，只有在Claude真正需要时才会去读。这个模式让SKILL的固定上下文开销降到最低，也让主指令不被冗长内容拖累。

3.2 一套通用的SKILL目录结构

我经过多轮实践后，稳定使用这样一套目录结构，你可以直接抄：

resume-screener/ ├── SKILL.md # 入口文件：功能概括 + 触发条件 + 子文件索引 ├── reference/ │ ├── scoring-rubric.md # 详细评分标准 │ └── red-flags.md # 需要注意的异常信号 ├── scripts/ │ └── normalize_experience.py # 可选：辅助脚本，规范化工作年限 └── examples/ └── sample-review.md # 样例输出，让Claude模仿格式

SKILL.md内部结构也很有讲究，强烈建议在头部用YAML格式做元信息标注，让Claude能快速识别并决定是否加载。我的入口文件通常长这样：

--- name: resume_screener description: 根据岗位描述与技术能力标准筛选简历，输出结构化评审意见。适用于技术岗位的初筛场景。 --- # 简历筛选专家 当用户提供简历与目标岗位时，你需要结合评分标准给出推荐决定与理由。 ## 评分标准 详细评分维度与权重见 reference/scoring-rubric.md ## 异常信号 需要特别关注的候选特征见 reference/red-flags.md ## 输出样例 一份完整评审输出示例见 examples/sample-review.md

注意看，入口文件里我只写了"结合评分标准"和"见...文件"，真正的细节全部丢给子文件。Claude加载SKILL时，只需要消耗很小的上下文识别出"这是个简历筛选专家，规则详情在子文件里"，等到它真正开始读简历时，才会按需打开scoring-rubric.md。整条链路的信息开销被控制到了最低。

3.3 子文件之间怎么配合，路径引用要注意什么

渐进式披露要想玩得顺，子文件的职责切分必须清晰。我通常按三个维度拆分：标准类文件（比如评分细则）、知识类文件（比如领域背景与行业惯例）、参考类文件（比如输出模板与示例）。分类清晰的好处是Claude在一次任务里不会同时加载所有文件，只读取与当前问题相关的那个。

路径引用是我发现翻车率最高的地方。SKILL内部引用子文件时，建议使用相对路径，并且保持引用名与实际文件名一致。比如在SKILL.md里写"见 reference/scoring-rubric.md"，那reference目录下就必须真的存在这个文件名，大小写都不能错。另外，引用关系不要绕太深，入口文件指向二级文件即可，三级以上的嵌套会把路径系统搞得极难维护，也增大了Claude找错文件的风险。

还有个小技巧：在SKILL.md的description字段里，写清楚"什么样的问题这个SKILL不擅长处理"。比如简历筛选SKILL可以注明"本技能仅针对技术岗位，不适用于设计岗或销售岗"。这个负向描述能有效避免Claude在无关请求上错误触发SKILL，省下不少阿里云token——别笑，这个问题我实际遇到了不下五次。

4. 技巧三：像调试代码一样迭代SKILL

4.1 从最小可用版本起步，不要一次写完美

很多技术出身的朋友写SKILL有个毛病：追求一步到位，总想把所有场景都覆盖了再上线。这个思路会让SKILL的开发周期拖得非常长，而且容易过度设计——你在设计时想象的那些复杂场景，实际根本不会出现。

正确的做法是：第一版只覆盖最简单的场景，先把核心流程跑通。拿简历筛选SKILL举例，第一版只需要做到"根据岗位描述判断候选人整体匹配度并给出一句话结论"就足够了。你甚至可以不加子文件，把规则浓缩进SKILL.md里，总共三百字就拿去用。

跑通以后再观察它哪里表现不好，针对性补齐那块知识：发现年限折算老出错，就加一个normalize_experience的参考规则；发现输出格式不统一，就补一个sample-review.md。每一轮迭代都解决一到两个明确问题，两周下来这个SKILL会变得非常强悍。

4.2 用真实失败案例驱动SKILL升级

我发现最高效的迭代方法不是靠想象，而是收集真实的失败输出。具体操作是：每次使用SKILL时，如果发现结果不对劲，立刻把"当时的输入+错误输出+你期望的正确输出"三件套保存下来，放进一个专门的迭代笔记里，每周集中分析一次。

这个方法来源于代码调试里的回归测试思维，迁移到SKILL上效果出奇地好。举例来说，有个做行业调研的SKILL，早期经常把二手信息当成统计数据用。我把几次出错案例放一起看，发现共性是"没区分数据来源的置信度"。于是我在SKILL里加了一条规则：所有数据必须标注来源与统计口径，未经核实的数据需明确标注"待验证"。之后类似问题再没出现过。

用失败驱动还有一个好处：你能清楚知道每条规则是什么场景下加的、为什么加，而不是凭记忆写一堆泛泛的指导。SKILL的可维护性会好很多，团队协作时尤其明显。

4.3 加版本号，记录每次变更理由

SKILL本质上是代码资产，又因为是纯文本形式，非常容易被随手改乱。我强烈建议在SKILL.md的meta区维护版本信息，记录功能演进轨迹。我的习惯是在description下面加一个history字段：

--- name: resume_screener description: ... version: 1.3 history: - 1.0 初版：基础匹配评估 - 1.1 补充：年限折算规则 - 1.2 新增：异常信号识别机制 - 1.3 修改：输出格式统一为表格 ---

这个做法的价值在于，当SKILL在某次迭代后表现突然变差，你能快速回溯到上一个稳定版本，对比变更内容找出问题。有一次我想给SKILL加多语言支持，结果发现输出质量明显下降，查history后发现是prompt里双语规则互相干扰导致的，对照历史版本一眼就看出来了。

版本管理还有一个意想不到的好处：它能逼着你每次改动都想清楚"我这次为什么这么改"，避免无意义的反复调整。很多人的SKILL越改越乱，就是因为没有版本意识，东一锤子西一棒子。

5. 完整实战：一个"简历筛选"SKILL的拆解

5.1 设计目标与目录搭建

理论讲完了，下面用一个我最近在做的简历筛选SKILL完整走一遍设计流程。目标岗位是"中级后端工程师"，需要从这个场景里提炼出SKILL应该承载什么样的规则体系。

我先明确最小可用版本的定义：输入一份简历和岗位描述，输出结构化评审意见，包括匹配分数、优势、风险点和最终建议。围绕这个定义，我把目录搭建如下：

backend-screener/ ├── SKILL.md ├── reference/ │ ├── scoring-rubric.md │ └── red-flags.md ├── scripts/ │ └── parse_years.py └── examples/ └── sample-output.md

这次我把scripts加进来了，目的是处理一个很常见的痛点：简历里工作年限的表达太混乱。有的人写"2018.03 - 至今"，有的人写"3.5年"，还有的人只写了一段项目经历没写时间。脚本负责把各种格式统一换算成"满X年"，Claude调用它时能拿到标准化数据，再去做后续判断。

5.2 SKILL.md入口文件的完整写法

下面是这个SKILL的SKILL.md完整内容，除了YAML头之外，身体部分我刻意控制在一屏以内：

--- name: backend_screener description: 评估后端工程师简历与目标岗位的匹配度，输出结构化评审意见。仅适用于技术类岗位，不适用于非技术岗位评估。 --- # 后端工程师简历筛选专家 当用户提供候选人简历和目标岗位描述时，需要输出包含匹配度评分、核心优势、关注信号和录用建议四部分的评审意见。 ## 评分标准 评分维度与各维度权重见 reference/scoring-rubric.md ## 风险信号识别 简历中值得警惕的特征清单及解释见 reference/red-flags.md ## 年限折算 简历中工作年限格式多样，如无法直接判断，请先运行 scripts/parse_years.py 进行规范化折算。 ## 输出模板 完整输出格式与样例参照 examples/sample-output.md，如果用户没有特殊要求，请保持输出格式与样例一致。

写完之后特别注意了description中的负面约束"不适用于非技术岗位评估"，这个我在前文提到过，用途是防止其他无关请求错误触发。入口文件把全部细节挡在身后，Claude只在需要读评分细则时才会去reference目录，这比把评分细则直接写在入口里要省很多上下文。

5.3 子文件里具体写了什么，以及踩过的坑

scoring-rubric.md里我定义了五个维度：技术栈匹配度(30分)、后端项目复杂度(25分)、工作年限与职级匹配(20分)、系统设计能力(15分)、团队协作与软技能(10分)。每个维度下都有细致的得分档描述，比如技术栈匹配度在25-30分要求"核心语言与岗位要求一致，且有两个以上深度使用的项目佐证"，15-24分是"核心语言一致但深度不足"，以此类推。

red-flags.md里列了四类风险信号：频繁短跳（三年内换过四家以上公司）、技术栈前后矛盾（简历自我描述与项目经历表述冲突）、空窗期无法解释、过度夸大（开源项目star数量与代码质量明显不符）。每条都附了"出现该信号时建议的追问方向"，让Claude在后续面试环节也能引用这套SKILL生成针对性问题。

踩坑方面最典型的是脚本误用问题。最开始我让Claude"在必要时"跑parse_years.py，它经常自作主张路径写错，浪费好几轮对话。后来我把调用条件写死成"当用户提供的简历中包含无法直观判断的年限表达时"，并给出了脚本的相对调用路径和用法示例，模式识别立刻稳定了。这件事让我意识到：给Claude的条件越模糊，它越容易自由发挥；自由发挥的结果，就是路径写错、参数传错。

5.4 三周迭代记录一览

这个SKILL三周内从1.0迭代到1.4，记录如下，你可以感受下迭代节奏：

每次迭代都只解决上一轮客观暴露出的问题。1.3那次我本来还打算同时加面试追问功能，后来忍住了，专注把输出格式稳定下来。实践证明这个克制是对的，功能边界一旦扩大，反而容易导致主场景表现退化。

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

6.1 高频问题速查表

这几类问题是群里被问了无数次的，直接整理成速查表，方便你定位问题：

如果你的SKILL出现了以上症状，不用大改，优先检查描述方式和目录结构，多半能解决八成问题。

6.2 我踩过最值得说的一次坑

最后分享一次印象深刻的翻车经历。有一次我给SKILL加能力，想让它同时处理"简历筛选"和"面试问题生成"两个功能，寻思这样不是更全能吗？结果上线试跑后发现一个严重问题：当用户同时给两份简历时，Claude完全不知道该走筛选流程还是问题生成流程，输出内容两头不靠，非常尴尬。

事后想明白了，这和单一职责原则完全违背。一个SKILL就是一件事，你要面试问题生成，那就再建一个面试问题生成的SKILL文件。两个SKILL可以同时存在于目录里，但它们必须各自独立、边界清晰。Claude会根据用户请求自动选择加载合适的那个，而不是一个SKILL里塞多个功能。

这个教训让我彻底接受了SKILL的"小而专"定位。它不是一个多功能工具箱，更像一个专家库——一个SKILL就是一位专家，不同的专家组合在一起才能覆盖更多场景。你要做的是让每一个专家都够专业，而不是让一个专家干所有人的活。

我在实际使用中逐渐形成了一套自己的判断标准：哪天我发现某个SKILL的SKILL.md超过了一千字，就会强制自己停下来拆分子文件；哪天哪个SKILL的迭代记录超过五条，我就会考虑它是不是职责太宽了，需不需要拆分。SKILL的设计没有标准答案，但如果你写出来的东西让你自己和Claude都觉得"轻"，那大概率方向是对的。用起来顺手、维护起来轻松，就是好的SKILL。