企业官网建设流程全解析

Claude Skill 官方指南一发布，我当天就把文档翻完了。作为一个常年把各种指令、格式规范、工具说明往 System Prompt 里硬塞的开发者，我最初以为这不过是又一份“工具使用手册”，读完才反应过来，这份指南真正在讲的是：大模型应用的工程结构，正在从“单块巨型 Prompt”走向“可插拔能力模块”。标题里那句“能力模块化正在改变大模型工程结构”不是营销词，它直接冲击的是我们过去写应用、组织代码、协作分工的方式。

如果你也在用大模型做产品，或者负责维护一个智能体应用，这篇文章值得看完。接下来我会把 Skill 的核心概念、工程影响、从零上手的写法，以及我在实际测试中踩过的坑，一次讲清楚。

1. 官方指南发布之后，我重新理解了Skill到底是什么

1.1 一句话说清Skill：给模型装一个可插拔的“岗位说明书”

Skill 本质上是一个文件夹，里面至少有一个 SKILL.md 文件。这个文件用 Markdown 写成，开头是 YAML 格式的元信息，后面是模型执行这个技能时需要遵循的行为说明。可以理解成给 Claude 装了一份“岗位说明书”：模型本身还是那个模型，但你告诉它，在收到某类任务时，应该按什么流程、什么格式、什么原则来处理。

我举一个容易理解的例子。同样是刚入职的实习生，能力底子差不多，但带他的师傅给了不同的岗位SOP：一个人拿到的是“会议纪要怎么写”，另一个人拿到的是“周报怎么写”。过两周再看，前者的输出明显更像一份可同步的会议记录，后者则更像一份向上汇报的周报。模型也一样，底子好只是基础，给它一套清晰的“技能包”，它才能在不同场景里稳定输出合格结果。

这里要强调，Skill 不是模型新能力，而是模型已有能力的“规范化使用方式”。Claude 本来就懂怎么整理纪要、怎么分析 CSV，但它不一定知道你的团队要什么格式、要避开哪些坑。Skill 把这些隐性要求固化成文件，让模型在遇到任务时不再自由发挥，而是按照你写好的步骤走。

1.2 官方指南里真正值钱的信息，不是用法而是设计意图

翻完这份指南，我的第一感觉是：它没有花太多篇幅讲“怎么注册一个技能”，反而花了很多力气讲“SKILL.md 怎么写才算合格”。尤其是 description 字段，官方反复强调要写清楚三件事：什么时候该用这个技能、这个技能能做什么、能做到什么程度。

这个细节看起来很基础，实际上是整个模块化设计的核心接口。模型在对话过程中会先读技能描述，判断当前用户请求是否需要激活这个技能。描述写得太泛，模型就不知道该在什么时候调用它；写得太窄，模型又会把很多本应触发技能的情况当成普通对话处理。我后来在测试里发现，description 写得具体与否，直接决定了技能被正确唤起的概率，差两句话，触发率可能从三成涨到八成。

指南里还有一句话让我印象很深，大意是：技能描述应当回答“完成了什么任务才算结束”。这其实是给每个技能定义了一个“验收标准”。有了验收标准，模型就知道什么时候该停下来，不会把简单任务无限延伸。

1.3 Skill和插件、工具、function calling到底有什么区别

很多人在聊这类功能时会把 Skill、插件、Function Calling 混在一起，其实它们不在同一层。

举一个具体场景说明。你给 Claude 装了一个天气查询工具，这是 Function Calling，模型知道它有一个 get_weather 函数可以调用。但用户说“明天去上海出差，帮我看看穿什么”，模型虽然有天气查询能力，却不清楚你的穿衣偏好、出差场景和格式要求。如果你把这个场景写成一个 Skill，里面包含“先查天气，再结合温差与活动场景给出穿衣建议，按简洁清单输出”这样的流程，模型的输出就会立刻顺手很多。

Skill 和插件之间也不是对立的。插件可以理解为面向用户的完整功能模块，它内部可能集成多个 Skill，也可能自己做 UI 和权限管理。Skill 是能力封装层，插件是产品交付层，两者可以嵌套组合。

2. 为什么说能力模块化在重构大模型应用的工程结构

2.1 过去为什么越做越乱：一个巨型System Prompt的失控过程

我观察身边不少团队做大模型应用，第一步几乎都是从“往 System Prompt 里堆规则”开始的。最开始是加一两段示例，效果提升明显；接着加语气要求、格式模板、业务禁忌；再后来把各个功能模块的判断逻辑也塞进去。等到 Prompt 膨胀到几千字时，问题就来了：规则之间开始打架，模型在小任务上表现得比以前更“碎”。

这就是典型的单块架构失控。所有的指令都常驻在上下文里，每一个词都会干扰模型对当前任务的重点判断。加上更新困难，几乎没有团队敢动老规则，因为删掉哪一句都可能让某个功能悄悄失效。我见过一个内容助手类应用的 Prompt，里面同时存在“回答要简洁”和“完整保留所有细节”这两条规则，模型每次都在两种风格之间摇摆，改谁都不敢删，最后只能堆更多补丁。

这种情况和软件工程里的“上帝对象”非常像：把所有职责放在一个类里，类越来越臃肿，耦合越来越重，最后没人能安全修改它。大模型应用的 System Prompt 如果一直这么长下去，迟早会重蹈覆辙。

2.2 模块化之后，工程组织方式发生的四个变化

Skill 带来最直接的改变，是把原来混在 System Prompt 里的各种规则，拆成一个个独立的能力包。这个过程我整理下来，至少有四个层面的变化。

第一个变化是上下文从“全量常驻”变成“按需加载”。以前几千字规则无论当前任务用不用，都会占用上下文窗口，影响注意力分配。拆成 Skill 之后，主 Prompt 只保留身份、语气和全局红线，具体业务规则等到需要时才加载，模型在处理无关任务时不会被多余规则干扰，token 消耗也更可控。

第二个变化是职责边界从“软约束”变成“物理隔离”。以前两条规则放在同一个 Prompt 里，互相影响是“软性”的，只能靠措辞小心避免。拆分成独立文件后，每个技能只负责自己的场景，规则冲突的概率大幅下降。

第三个变化是测试从“整体回归”变成“单点验证”。以前改一句 Prompt 要担心影响全局，现在改某个技能的描述和步骤，只需要在对应场景里测试一遍，其他技能根本不受影响。这特别像从单体应用拆成微服务之后，团队终于敢频繁发布。

第四个变化是协作方式从“人人改同一个 Prompt”变成“各自维护技能包”。以前所有规则挤在一个文件里，谁改都会撞车。现在可以把技能库当作代码库来组织：一个人负责客服话术技能，另一个人负责数据报表技能，各自有独立的文件，协作起来就像维护多个小项目。

这四个变化叠加在一起，其实是在把大模型应用的开发方式，拉回到我们熟悉的工程化轨道上。

2.3 一个团队从“全塞Prompt”改造成“技能库”的例子

假设你所在的团队维护一个内容助手，过去主 Prompt 里堆了语气规则、摘要长度、表格格式、敏感词过滤等一堆内容。每次有运营同事提新的格式要求，都要去改那个几千字的 Prompt，改完还要反复回归测试。

迁移到技能库之后，主 Prompt 只保留身份设定和不可逾越的底线规则；摘要生成、表格处理、敏感词检查各自拆成独立 Skill。运营要求调整表格样式，直接打开表格处理那个 Skill 的文件改两行描述就行，其他规则完全不用碰。

这个改造最明显的变化是：出问题时的定位时间大幅缩短。以前模型输出格式错了，你猜不到是哪个规则在打架；现在只要看当前对话激活的是哪个技能，问题基本就锁定在那个文件里。即便模型自主选择技能选错了，也只需要调整对应技能的 description，而不是回滚一整个 Prompt。

当然，这种拆分不是免费的。它要求团队提前做能力域分析，想清楚哪些规则属于全局、哪些规则适合封装成技能。但这个成本一次性投入之后，后续维护的边际成本会显著降低。

3. 从零写一个可用的Skill：目录、SKILL.md与最小约定

3.1 Skill的标准目录结构：SKILL.md、scripts、references

官方指南里给出了一个很清晰的约定，我已经照着搭了好几个技能，建议你也按这个结构来：

skills/ ├── meeting-minutes/ │ └── SKILL.md └── csv-stats/ ├── SKILL.md └── scripts/ └── stats.py

每个技能是一个独立文件夹，文件夹名通常用小写字母加连字符，比如 meeting-minutes、csv-stats。文件夹里最核心的文件是 SKILL.md，它是模型读取技能定义时的入口。如果技能需要执行代码，就在子目录里放 scripts；如果需要参考材料，比如示例输出、行业规范、数据字典，就放在 references 里。

我自己的经验是，scripts 和 references 不是必须的，但一旦技能涉及确定性逻辑，尽量把逻辑写进脚本，而不是让模型“自由发挥”。模型擅长的是理解上下文、做判断、写叙述，不擅长的是精确计算和固定流程，后者交给脚本更可靠。

3.2 SKILL.md的frontmatter怎么写才不容易被误读

SKILL.md 的 YAML 部分非常关键，它决定了模型何时唤起这个技能。我通常会把 name 写得和文件夹名一致，把 description 当作“触发条件 + 能力边界 + 输出承诺”三合一。

--- name: csv-stats description: 当用户提供 CSV 文件或 CSV 内容，并希望了解数据概况、字段质量或统计摘要时使用。输出包含行数、字段列表、非空字段数量等指标。 ---

对比一下“坏”的写法：description: 处理CSV文件。。看起来没毛病，但模型读到这句话时，并不知道“处理”到底指什么、用户说什么话时才该触发。好的描述应该像一个接口注释：调用者看一眼就知道该不该调它。

另一个容易忽略的点是：description 里不要写“不要做某事”，因为模型在判断技能匹配度时，很少会基于否定语句做出正确选择。更靠谱的做法是正面描述触发场景，然后把禁止事项写进正文部分。

3.3 最小示例A：会议纪要整理技能

这个技能不需要脚本，纯靠 SKILL.md 的指令就能跑，很适合作为第一个练手项目。我把写好的文件直接贴出来。

--- name: meeting-minutes description: 当用户提供会议转写文本、会议笔记或聊天记录，并要求整理成会议纪要时使用。输出结论、行动项、责任人和截止日期。 --- # Meeting Minutes Skill ## 目标 把杂乱的会议内容整理成可直接同步给团队的会议纪要。 ## 处理步骤 1. 通读输入内容，识别背景信息和讨论主题。 2. 提取已确认的结论，每条结论单独编号。 3. 提取行动项，按“负责人-动作-截止时间”组织；未指定责任人的标记为“待确认”。 4. 将讨论中的分歧如实列出，不掩盖不偏袒。 ## 输出格式 - 会议主题 - 目标和背景 - 结论 - 行动项表格：行动、负责人、截止时间、状态 - 待确认事项 ## 注意事项 - 不要添加输入中不存在的事实。 - 保持中立语气，不确定的地方明确标注“根据原始记录无法确认”。

注意我刻意在 description 里写了“并要求整理成会议纪要”，这就是触发条件。用户只是闲聊几句，模型不会平白调用它；一旦用户说“帮我整理一下这份会议记录”，技能就会被唤起。

3.4 进阶示例B：带Python脚本的CSV统计技能

当技能需要做确定性计算时，就轮到 scripts 登场了。我以 csv-stats 为例，它负责生成 CSV 文件的数据概览。SKILL.md 的重点是告诉模型“什么时候用脚本、怎么用脚本”，而不是让模型自己在回复里心算数字。

--- name: csv-stats description: 当用户提供CSV文件或粘贴CSV内容，并需要数据概览、字段质量检查或统计摘要时使用。 --- # CSV Stats Skill ## 能力边界 本技能负责生成结构化数据概览，不做数据清洗和建模，不写复杂分析结论。 ## 执行方式 1. 如果用户提供了CSV文件，优先调用 scripts/stats.py 统计文件基本信息。 2. 结合脚本输出和数据样例，向用户说明字段质量。 3. 用户要求深入分析时，基于统计结论进一步提问。

配套脚本如下：

#!/usr/bin/env python3 """CSV quick stats.""" import csv import sys def main(path: str) -> None: with open(path, newline="", encoding="utf-8") as f: rows = list(csv.DictReader(f)) if not rows: print("rows: 0") return cols = list(rows[0].keys()) print(f"rows: {len(rows)}") print(f"columns: {', '.join(cols)}") for col in cols: filled = sum(1 for r in rows if (r.get(col) or "").strip()) print(f"- {col}: {filled}/{len(rows)} non-empty") if __name__ == "__main__": main(sys.argv[1])

这段脚本只依赖 Python 标准库的 csv 模块，不需要额外安装任何依赖，并且在设计上只做只读操作，不会修改用户的数据文件。这样执行环境崩溃的概率很低，也方便跨机器复用。

我把确定性统计放到 Python 脚本里，把对统计结果的解读与叙述交给模型，这是模块化里很核心的思维方式：能用代码保证的，就别让模型自由发挥；需要判断和表达的，再交给模型处理。

4. 把Skill跑起来的完整步骤与调用方式

4.1 在Claude客户端中通过@唤起技能

实际用起来没有想象中复杂。我习惯的流程是：先按上面的目录结构建好技能文件夹，把 SKILL.md 和 scripts 放进去，再将整个技能目录放到 Claude 客户端的技能识别路径下。路径在官方文档里有详细说明，不同客户端版本可能略有差异，找不到时直接查对应文档就行。

放好之后，需要重新启动或刷新客户端，让模型重新扫描技能目录。接着新建一个对话，直接输入 @meeting-minutes，后面跟上你要整理的会议内容，模型就会按照技能里定义的流程工作。

值得留意的是，技能并不是每时每刻都被自动加载的。只有在派发到 @技能名，或者模型根据用户输入判断应当激活某个技能时，它才会读取对应的 SKILL.md。这既是好事也是坑：好处是上下文干净，坏处是你的描述如果不清晰，技能可能不会被自动唤起。所以前面才反复强调 description 要写清楚触发条件。

4.2 测试迭代的三个边界条件

我每次写新技能，都会在本地跑三轮底测试，专门测那些容易被忽略的边界情况。

第一轮测空输入和极简输入。比如给它一句话“今天开会聊了进度”，看它是不是硬生生输出一堆空表格。好的技能应该在这种情况下明确说“信息不足，无法整理成完整纪要”，而不是制造一堆空壳子。

第二轮测超长输入。会议转写文本动辄几万字，模型容易在前半段记得清、后半段开始丢信息。我的做法是在技能步骤里加一条“先分段摘要再合并提炼”，并且要求模型在处理前先说明它计划分几段。这招实测下来能明显提升长输入的完整度。

第三轮测歧义输入。把闲聊、口头禅、非正式表达混在真实结论里，看技能能不能自动过滤掉干扰信息。如果输出里混进了太多废话，说明指令不够明确，我会在注意事项里加一条“区分事实陈述与闲聊内容，只保留与会议目标相关的信息”。

一个有用的经验是：每次修改 SKILL.md 之后，必须开一个新对话测试。模型在旧会话里可能已经缓存了技能定义，旧文件的修改不会生效。一开始我没意识到这一点，改了很多次都没反应，后来才反应过来是没开新对话。

4.3 发布与分享：技能目录/技能集合的整理习惯

当技能数量超过三四个之后，光靠零散文件夹管理就会开始乱。我现在习惯按领域分组，比如办公效率、数据分析、内容创作，每个领域一个目录。目录外层加一个 README.md，记录每个技能是干什么的、依赖什么脚本、适合谁用。

这样做还有一个额外好处：方便分享。当你想把一个技能分享给别人时，只需要把整个文件夹打包，对方放到自己的技能目录里就能用。这很像开源社区里的“插件包”或“项目脚手架”，天然适合二次修改和接力改进。

如果技能里有相对完善的脚本，我会在 README 里明确写出脚本运行需要的 Python 版本和依赖，避免别人拿到手后因为环境问题跑不起来。版本管理也是一样，技能改到一定稳定程度就打个标记，之后大改时出新版本，而不是在同一个文件上反复横跳。

5. 我踩过的坑和几个反直觉的结论

5.1 描述含糊导致“召之不来”

我最早写的技能描述是“处理CSV文件”。结果在实际对话里，用户明明贴了一大段 CSV 内容，模型却完全没想起来调用这个技能，直接自己用规则解析，输出的格式和我的预期完全不一样。后来我把描述改成“当用户提供CSV文件或粘贴CSV内容，并希望了解数据概况、字段质量或统计摘要时使用”，触发率立刻好看了很多。

这个坑让我意识到，description 本质上是一段“意图识别文本”，它要写的是“模型在什么输入下应该唤醒该技能”，而不是“这个技能能做什么”。能做什么是正文里的事，什么时候该登场才是描述的事。

5.2 指令太满导致“技能变成了枷锁”

我在另一个技能里写了一大堆严格步骤，连每句话的语气、每个段落的顺序、每种情况的详细分支都写了。结果模型输出变得非常机械，明明用户问的是边缘情况，它也非要按既定模板硬套，产出内容反而像在填表。

后来我调整了写法，把技能内容分成两层：必须遵守的规则和可以参考的指导。必须遵守的规则只有少数几条，比如“不要编造事实”“按行动项组织输出”；参考指导则写得宽松，允许模型根据实际输入调整表达方式。换句话说，**要给模型留出判断空间，而不是把它当代码执行器。**这是 Skill 设计里最反直觉的一点：写得越满，效果反而越差。

5.3 技能之间互相打架该怎么处理

试过一个场景：数据类技能要求“输出 Markdown 表格”，内容类技能也要求“输出 Markdown 表格”，但在某些子步骤里一个要求左对齐、一个要求居中对齐。当两个技能同时参与处理时，模型不知道该听哪个，输出时可能在同一个表格里来回切换对齐方式。

解决思路不是把所有技能改得更细，而是把公共规则上移到主 Prompt。比如“全局使用左对齐表格”属于公共约定，就只放在 System Prompt 里，业务技能里不再重复。这样技能文件本身保持精简，公共规则也不至于散落多处。这个原则和多个微服务共享统一授权策略是一样的逻辑。

5.4 什么时候不应该用Skill

技能不是银弹，有些场景不适合封装成 Skill。最容易判断的例子是：一次性任务。如果一个任务你只处理一次，以后再也不复现，那就没必要单独建个技能文件夹，直接在对话里交代清楚就行。

也要警惕那些高度依赖当前对话上下文的场景。比如一个技能如果要求“根据前面三轮对话中的非正式信息生成周报”，这种高度动态的上下文很难被固化成稳定指令，硬封装反而会让模型误判用户意图。

更基础的一个原则是：如果规则本来就属于全局，比如“不要输出政治观点”“不要编造数据”，那就放在主 Prompt，不要埋进业务技能里。否则你会在每个技能里重复写一遍，还容易漂移，最后改起来几乎要全部技能同步，非常糟糕。

6. 写在最后：能力模块化对普通开发者的两个机会

6.1 机会一：把个人工作流沉淀成资产

Skill 真正吸引我的地方在于，它把大模型的应用开发从“每次对话都从零开始”变成了“持续积累资产”的过程。以前我处理周报、整理会议记录、清洗 CSV，每次都靠对话描述一遍诉求，下一次还得重新描述。有了技能库之后，这些固定流程全部沉淀成文件，随时按需调用。

你可以把自己的高频工作一个个“技能化”：邮件起草、竞品信息整理、数据概览、文章初稿排版。每个技能都是一个可复用资产，积累到一定数量后，你的工作效率会有一个台阶式的提升。我自己已经把工资表核对、会议纪要、博客排版三个高频场景做成了技能包，日常使用量很大。

6.2 机会二：技能市场/技能集合的生态位

当技能目录越来越常见，围绕技能包的生态就会出现：有人做技能集合分享，有人做同领域技能的质量评测，有人专门针对特定行业做“开箱即用技能包”。这和当年软件从“单机可执行文件”进化到“插件生态”的路径非常像。

对普通开发者来说，现在是个不错的入局时机。你不需要做大平台，只要在自己熟悉的领域里做出几个高质量技能包，把它们整理清楚并公开出来，就能帮到大量同场景的人。技能包是可以二次修改的，这天然鼓励协作和迭代，社区一旦滚起来，生态位就逐渐成型。

6.3 我的实操体会与下一步方向

我自己的下一个方向是给技能目录加上更严格的版本管理和自动化测试。现在技能还是装在一个文件夹里靠手维护，等技能数量上来之后，至少要能记录每个技能的变更历史，最好能自动跑一遍样例输入来验证行为没有退化。希望官方后续能在这一块提供更多标准化的能力，让技能包的诞生、分发、升级都变得像软件包一样可靠。

能力模块化正在改变大模型工程结构这件事，已经不只是标题上的判断，而是我拆了几个技能包之后真实的体感。如果你还没上手，建议今天先挑一个你每周都会重复做的任务，把它写成第一个 SKILL.md。不用完美，可以从能用的最小版本开始。