企业官网建设流程全解析

1. 从"会聊天"到"能干活"：Skills 到底解决了什么核心问题

大模型能写诗、能编故事、能陪你聊哲学，但真让它按公司规范走一遍报销流程、按团队约定生成一份接口文档、按固定模板输出周报，十有八九会翻车。问题不在于模型不够聪明，而在于它缺少一套可复用、可约束、可组合的专业工作流。Anthropic 开源的 Skills 机制，本质上就是给 AI 装上一本"岗位操作手册"——你告诉它这个岗位该干什么、按什么顺序干、每一步的输入输出长什么样，它就能稳定地按这套流程执行，而不是每次靠临场发挥。

我最初接触 Skills 这个概念时，第一反应是"这不就是提示词模板吗"。实际用下来才发现差别很大。普通提示词是"一次性指令"，你这次说清楚了，下次换个会话它又忘了；而 Skills 是一份结构化的、带元信息的、可被系统自动发现和加载的能力包。它的核心载体是一个叫SKILL.md的文件，里面用约定好的格式描述这个技能叫什么、什么时候该触发、具体执行步骤是什么、需要哪些配套资源。模型在运行时能根据当前任务自动匹配到对应的 Skill，然后按里面的流程走。

这套机制真正有意思的地方在于它把"专业能力"从模型权重里剥离出来，变成了可编辑、可版本管理、可团队共享的文本资产。以前你想让 AI 按你们团队的代码规范写前端组件，得反复在对话里贴规范文档；现在你把规范写成一个 Skill，团队里所有人调用同一个 Skill，输出风格就统一了。这对工程团队来说价值极大——它把"AI 输出不稳定"这个老大难问题，转化成了"维护一份 Markdown 文档"这种可控的日常事务。

适合谁来研究这套东西？我梳理了三类人。第一类是一线开发者，尤其是做前端、测试、后端接口的，你们日常有大量重复性的代码生成、文档撰写、用例编写工作，Skills 能直接把这些流程固化下来。第二类是AI 应用搭建者，不管你是用 Coze、Dify 还是自己写 Agent 框架，Skills 的设计思路都能借鉴，它解决的是"如何让 Agent 稳定执行多步任务"这个通用难题。第三类是团队技术负责人，你需要考虑的是怎么把团队积累的最佳实践沉淀成 AI 能理解的资产，Skills 提供了一套现成的组织方式。

需要提前说明的是，Skills 不是银弹。它擅长的是流程明确、步骤可枚举、输出格式相对固定的任务。如果你的任务本身就需要大量创造性判断、边界模糊、每次都要重新定义问题，那 Skills 帮不上太多忙，甚至可能因为流程约束太死而限制模型发挥。搞清楚这个边界，比盲目上手更重要。

2. Skills 的整体设计思路与核心机制拆解

2.1 为什么是 Markdown 而不是代码或 JSON

Anthropic 选择用 Markdown 作为 Skill 的主要描述格式，这个决策背后有很实际的考量。Markdown 是人和模型都能高效读写的格式。对模型来说，Markdown 的层级结构（标题、列表、代码块）天然对应任务的分解逻辑，模型解析起来比 JSON 更自然，因为它在预训练阶段见过海量的 Markdown 文档。对人来说，Markdown 不需要任何工具就能编辑，Git diff 清晰，评审方便，非技术人员也能看懂和修改。

我试过用 JSON 写类似的流程描述，问题是嵌套一深就极其难读，而且模型在生成时容易漏掉括号或引号导致解析失败。Markdown 没有这个负担，它的容错性高得多。另一个隐性好处是，Markdown 里可以直接嵌代码块、嵌表格、嵌示例，这些恰恰是描述专业工作流时最需要的东西。比如你要描述一个"生成 React 组件"的 Skill，直接在文档里放一段标准组件代码作为范例，模型照着模仿就行，比用自然语言描述"请生成符合某某规范的组件"有效得多。

2.2 SKILL.md 的典型结构长什么样

虽然官方没有强制规定死格式，但根据我实际拆解和使用的经验，一个能稳定工作的SKILL.md通常包含这么几个部分。开头是元信息区，用 YAML front matter 或者简单的键值对写明技能名称、一句话描述、触发条件。触发条件这块特别关键，它决定了模型什么时候会想起用这个 Skill。写得太宽泛，模型动不动就触发，干扰正常对话；写得太窄，该用的时候想不起来。

中间是流程主体，一般用有序列表或分步骤的标题来组织。每一步要写清楚：这一步的目标是什么、输入从哪来、具体怎么操作、输出是什么格式、有什么注意事项。我个人的经验是，步骤不要超过七步，超过就该考虑拆成多个 Skill 了。人的工作记忆有限，模型的上下文注意力也有限，步骤太多容易在中途丢失上下文。

最后是资源引用区，可以链接到配套的模板文件、示例数据、参考文档。Skills 支持引用外部文件，这意味着你可以把大段的模板、复杂的配置样例放在单独文件里，SKILL.md只负责描述流程和引用关系，保持主文档清爽。

2.3 自动发现与按需加载的机制

Skills 最巧妙的设计是渐进式披露。模型不需要一次性把所有 Skill 的完整内容都读进上下文，那样会撑爆窗口。系统先只加载每个 Skill 的元信息（名称和描述），当判断当前任务和某个 Skill 匹配时，才把完整的SKILL.md内容加载进来。这就像你电脑里的软件，快捷方式图标一直显示在桌面上，但只有双击时才真正把程序加载到内存。

这个机制带来的直接好处是可以挂载大量 Skill 而不影响性能。你可以给一个 Agent 配几十个 Skill，覆盖代码审查、文档生成、数据分析、测试用例编写等各个场景，模型平时只看到这些 Skill 的名字，需要哪个调哪个。我实测下来，挂载二十多个 Skill 时，元信息占用的上下文大概只有一两千 token，完全在可接受范围内。

2.4 与普通提示词工程的根本差异

很多人会把 Skills 和提示词工程混为一谈，我觉得有必要把差异讲透。普通提示词是会话级的，你在这个对话里设定的角色和规则，换个对话就没了。Skills 是资产级的，它独立于任何一次具体会话存在，可以被反复调用、被不同人调用、被程序化调用。

另一个差异是可组合性。普通提示词很难组合，你把两个提示词拼在一起，经常互相干扰。Skills 设计上就支持组合，一个主 Skill 可以在流程中调用其他 Skill。比如一个"发布新版本"的 Skill，里面可以依次调用"运行测试"Skill、"生成变更日志"Skill、"更新文档"Skill。这种组合能力让 Skills 能覆盖复杂的长流程任务，而普通提示词一到多步骤就力不从心。

还有一点是可测试性。因为 Skill 的输入输出相对固定，你可以像测试代码一样测试 Skill。给它一组标准输入，看输出是否符合预期，不符合就改SKILL.md，改完再测。这种迭代方式比调提示词科学得多，提示词调优基本靠感觉，Skill 调优可以靠用例。

3. 核心细节解析与实操要点

3.1 触发条件的写法决定 Skill 的可用性

触发条件是 Skill 的门面，写不好这个 Skill 基本就废了。我踩过的坑是描述写得太抽象，比如"用于处理文档相关任务"，结果模型在任何涉及文字的场合都想触发它，反而干扰了正常回答。后来我改成具体的场景描述，比如"当用户要求将 Markdown 格式的技术文档转换为带目录和页码的 Word 文档时使用"，触发就精准多了。

写触发条件有个实用技巧：用"当……时"的句式，把用户可能的原话或意图写进去。比如"当用户说'帮我写个接口测试'、'给这个 API 生成测试用例'、'补充一下单元测试'时触发"。这样模型做意图匹配时，能直接和用户输入做语义对齐，命中率高很多。另外要注意排除条件也要写，比如"当用户只是询问测试概念时不要触发"，避免误触发。

3.2 步骤描述要具体到"可执行"

我见过不少 Skill 写得很像教科书目录，"第一步：分析需求；第二步：设计方案；第三步：实现"。这种描述对模型来说等于没说，因为每一步该怎么做完全没交代。好的步骤描述应该具体到模型看完就知道下一步该输出什么。

举个例子，描述"生成接口测试用例"这个步骤，差的写法是"根据接口文档生成测试用例"。好的写法是："读取用户提供的接口文档，提取每个接口的 URL、请求方法、请求参数、响应字段。对每个接口，至少生成三类用例：正常参数用例、边界值用例、异常参数用例。每个用例用表格输出，包含用例名称、请求参数、预期状态码、预期响应体关键字段。如果接口文档中缺少参数类型信息，在用例表格下方单独列出需要确认的字段。"后面这种写法，模型执行起来几乎没有歧义。

3.3 示例的质量比数量重要

在 Skill 里放示例是提升输出稳定性的有效手段，但示例不在多而在精。我建议每个关键步骤配一个完整的输入输出示例，而不是放一堆零散片段。完整的示例能让模型看到从输入到输出的完整映射关系，包括格式、粒度、详略程度。

示例的选择也有讲究。要选有代表性但不过于复杂的案例。太简单的示例模型学不到东西，太复杂的示例会占用大量上下文还容易让模型过度拟合。我通常选一个中等复杂度的真实案例，脱敏后放进去。如果流程中有分支判断，每个分支至少给一个示例。

注意：示例里的数据一定要脱敏。我见过有人直接把生产环境的接口地址、密钥、用户数据放进 Skill 示例里，然后这个 Skill 被团队共享，等于把敏感信息散播出去了。养成习惯，示例数据一律用假数据。

3.4 资源文件的组织方式

当一个 Skill 需要引用外部资源时，目录结构要规划好。我常用的结构是这样：Skill 根目录下放SKILL.md作为入口，然后建templates/放模板文件，examples/放示例，references/放参考文档。SKILL.md里用相对路径引用这些文件。

这样组织的好处是可移植。整个 Skill 目录打包发给同事，或者提交到团队的 Skill 仓库，别人拿到就能用，不依赖任何外部路径。另外模板文件和参考文档独立出来后，SKILL.md本身可以保持精简，模型加载时上下文占用更少，需要细节时再去读具体文件。

3.5 版本管理与团队协作

Skills 既然是文本资产，就应该纳入版本管理。我的做法是在团队 Git 仓库里建一个skills/目录，每个 Skill 一个子目录，用 Pull Request 的方式做变更评审。改 Skill 和改代码一样，要说明改了什么、为什么改、影响哪些使用场景。

这里有个容易忽略的点：Skill 的变更要做回归测试。你改了一个步骤的描述，可能影响下游所有依赖这个 Skill 的流程。我建议维护一组标准测试用例，每次改完 Skill 跑一遍，确认输出没有意外变化。如果团队用 CI，可以把 Skill 测试也接进去，改完自动跑。

4. 实操过程与核心环节实现

4.1 从零搭建一个"接口测试用例生成"Skill

我拿一个真实场景来演示完整搭建过程。需求是：团队里后端改了接口，测试同学要快速生成测试用例，以前靠手工写，现在想用 AI 按统一格式生成。

第一步，确定 Skill 的边界。这个 Skill 只负责"根据接口文档生成测试用例表格"，不负责执行测试、不负责生成测试代码。边界清晰了，触发条件才好写。

第二步，写元信息。名称定为api-testcase-generator，描述写"当用户提供接口文档并要求生成测试用例时使用，支持 REST 风格接口，输出 Markdown 表格格式的用例集"。触发条件里列了几个典型用户说法："生成接口测试用例"、"给这个 API 写测试"、"补充接口的边界测试"。

第三步，设计流程步骤。我把它拆成五步：读取并解析接口文档、提取接口清单、为每个接口生成三类用例、汇总成表格、标注待确认项。每步都写清楚输入输出。

第四步，准备示例。我找了一个真实的用户查询接口，脱敏后作为示例，展示了从接口文档片段到完整用例表格的映射。

第五步，测试迭代。拿三个不同风格的接口文档喂进去，看输出是否稳定。第一次测试发现，当接口文档里参数是嵌套对象时，模型生成的用例覆盖不全。我在步骤描述里补了一句"对于嵌套对象参数，至少对每个一级字段生成一个边界值用例"，再测就正常了。

4.2 关键步骤的参数与格式设计

在"生成三类用例"这一步，参数设计直接决定输出质量。我明确规定了每类用例的数量下限和覆盖要求。正常参数用例至少覆盖所有必填参数的典型值组合；边界值用例要覆盖字符串长度边界、数值范围边界、数组空和满的情况；异常参数用例要覆盖必填缺失、类型错误、超长输入。

格式上我强制要求用 Markdown 表格，列固定为：用例编号、用例名称、请求方法、请求路径、请求参数、预期状态码、预期响应关键字段、备注。固定列的好处是输出可以直接被下游工具解析，比如导入到测试管理平台。如果不固定列，每次生成的表格列都不一样，后续处理很麻烦。

提示：预期响应关键字段这一列，我要求只写关键字段而不是完整响应体。完整响应体太长，表格会撑爆，而且大部分字段对测试判断没意义。只写状态码和业务关键字段，比如code、data.id、message，足够判断用例是否通过。

4.3 实操现场：一次完整的 Skill 调用记录

我把接口文档贴给模型，输入是"帮我给这个用户查询接口生成测试用例"。模型识别到触发条件，加载了api-testcase-generatorSkill，然后按流程执行。

它先解析出接口信息：GET /api/v1/users/{id}，路径参数id为整数，查询参数page和pageSize为可选整数。然后生成用例。正常用例覆盖了有效 id 加默认分页、有效 id 加指定分页。边界用例覆盖了 id 为 1、id 为最大整数、pageSize 为 1、pageSize 为 100。异常用例覆盖了 id 为 0、id 为负数、id 为非数字、pageSize 超过上限。

输出表格一共十二行，格式整齐。最后它标注了两个待确认项：id 的最大值范围文档没写，pageSize 的上限文档没写。这两个标注很有价值，提醒测试同学去和后端确认。

整个调用从输入到输出大概十几秒，生成的用例质量比我手工写初稿还高，而且格式统一。后续我只需要补充一些业务特定的用例，比如权限相关的、并发相关的，基础用例完全不用重写。

4.4 把 Skill 接入现有工作流

单独用 Skill 已经能提效，但接入工作流价值更大。我们团队的做法是在 CI 流程里加一步：当后端接口文档有变更时，自动触发 Skill 生成测试用例，生成结果作为 MR 的评论贴出来，测试同学 review 后决定是否采纳。

实现方式不复杂，写个脚本调用模型接口，把接口文档和 Skill 内容一起传进去，拿到输出后调 GitLab 或 GitHub 的 API 发评论。关键是 Skill 内容要作为系统提示的一部分传进去，确保模型按 Skill 流程走。这个脚本我大概花了一个下午写完，之后每次接口变更都能自动出用例初稿，测试同学的重复劳动少了一大半。

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

5.1 Skill 不触发或误触发怎么办

这是最高频的问题。不触发通常是触发条件写得太窄或太书面化。排查方法是把触发条件里的描述和用户实际会说的话做对比，如果用户说的是"帮我测测这个接口"，而触发条件写的是"生成接口测试用例"，语义匹配可能失败。解决办法是把用户口语化的说法也列进去。

误触发则是触发条件太宽泛。比如描述写"处理测试相关任务"，那用户问"什么是单元测试"时也可能触发。解决办法是加排除条件，明确写出"当用户仅询问测试概念、不涉及具体接口时不要触发"。

我总结了一个判断标准：触发条件应该描述"任务"而不是"领域"。"生成接口测试用例"是任务，"测试"是领域。任务描述越具体，触发越精准。

5.2 输出格式不稳定的排查思路

模型有时不按 Skill 里规定的格式输出，原因通常有三个。一是格式描述不够具体，比如只说"用表格输出"，没说表格有哪些列。二是示例里的格式和文字描述不一致，模型会优先学示例。三是流程步骤太多，模型执行到后面忘了前面的格式要求。

排查顺序建议这样：先检查示例和文字描述是否一致，不一致就统一；再检查格式描述是否具体到列名和顺序；最后看步骤数量，超过七步考虑拆分。我遇到过一次格式飘忽的问题，查了半天发现是示例表格的列顺序和文字描述里的列顺序不一样，模型无所适从。统一之后立刻就稳了。

5.3 Skill 之间冲突的处理

当挂载多个 Skill 时，可能出现两个 Skill 都觉得自己该触发的情况。比如一个"生成测试用例"Skill 和一个"生成测试代码"Skill，用户说"给这个接口写测试"，两个都可能触发。

处理办法有两个层面。Skill 设计层面，把触发条件写得更互斥，测试用例 Skill 明确"输出用例表格"，测试代码 Skill 明确"输出可执行的测试代码文件"。系统层面，如果框架支持优先级，给更专用的 Skill 设更高优先级。我个人的经验是，宁可把 Skill 拆得细一点，也不要让一个 Skill 管太宽，细粒度的 Skill 冲突少、维护也容易。

5.4 常见问题速查表

5.5 几个我踩过的坑

第一个坑是在 Skill 里写太多背景知识。我一开始想把接口规范、命名约定、错误码定义全塞进一个 Skill，结果SKILL.md写了三千多字，模型加载后注意力被分散，执行流程时反而丢三落四。后来我把背景知识拆到references/目录，SKILL.md只留流程和关键约束，效果好很多。背景知识按需加载，不干扰主流程。

第二个坑是用 Skill 处理需要创造性判断的任务。我曾经想做一个"根据需求描述生成技术方案"的 Skill，写得很详细，但实际用下来输出很套路化，因为流程约束把模型的创造性压住了。这类任务还是适合开放式对话，Skill 更适合流程明确的任务。认清这个边界能省很多无用功。

第三个坑是忽略 Skill 的维护成本。Skill 不是写完就完事，业务变了、规范变了、模型升级了，Skill 都可能需要调整。我建议给每个 Skill 指定一个负责人，定期 review。没有维护的 Skill 会慢慢失效，最后没人敢用。

6. 从 Skills 看 AI 工作流的未来形态

用了一段时间 Skills 之后，我对"AI 怎么才能真正干活"这件事有了更具体的感受。模型能力本身在快速提升，但能力提升不等于能干活。一个聪明的新人如果不知道公司的流程规范，照样干不好活。Skills 补的就是这块——把组织积累的流程知识，用模型能理解的方式喂给它。

我观察到的一个趋势是，工作流正在从"人操作工具"变成"人定义流程，AI 执行流程"。以前我们用 Coze、Dify 这类平台拖拽工作流，节点是固定的，AI 只在个别节点里做判断。Skills 的思路更进一步，流程本身用自然语言描述，AI 理解流程后自主执行，灵活性高得多。这两种方式会长期共存，简单固定的流程用可视化编排，复杂多变的流程用 Skills 这类自然语言描述。

另一个感受是，Skill 的复用和组合会催生出新的协作方式。想象一下，团队里每个人都可以贡献 Skill，有人擅长写测试，他的测试 Skill 被全团队用；有人擅长写文档，他的文档 Skill 被全团队用。Skill 成了个人专业能力的可复用封装。这种协作模式下，团队的整体 AI 使用水平会被拉齐，不再依赖个别人的提示词技巧。

我现在维护着十几个 Skill，覆盖日常开发的大部分重复性工作。最常用的几个是接口测试用例生成、代码审查清单、变更日志生成、技术文档格式转换。这些 Skill 帮我省下的时间，粗算下来每周至少有五六个小时。更重要的是，它们让我的输出质量更稳定，不会因为状态好坏而波动。

如果你刚开始接触 Skills，我的建议是从一个你每周都要重复做、步骤相对固定的任务开始，把它写成 Skill，用两周时间迭代到稳定。不要一上来就搞大而全的 Skill 体系，从小处着手，跑通了再扩展。Skill 的价值在于持续使用和迭代，写一个用一次就丢的 Skill 没有意义。