企业官网建设流程全解析

Skills 在 AI 助手圈子里已经吵了大半年。我第一次看到它的时候，第一反应也是“这不就是给提示词换了个文件夹装起来吗”，一度觉得它被吹过头了。直到我在真实项目里用了三个月，踩了五六个坑，又把十几个技能从能用磨到好用，才对这东西有了完全不同的判断：Skills 没那么神，也没那么废。它不是改变模型智商的外挂，只是一种改变调用方式和工作流程的标准化载体。你理解了它背后的逻辑，上手创建真的只需要两分钟；但真正让一个 Skill 有效的，不是创建速度，而是它能不能准确回应你反复遭遇的真实痛点。

这篇我打算把三层东西讲透：Skills 的底层逻辑到底是什么；一个普通用户怎么在两分钟内从零建好一个能用的 Skill；以及那些口碑很好、真正好用的 Skill，到底是怎么从“痛”里长出来的。如果你还在纠结 Skill 值不值得用、该怎么写，或者看了一堆教程还是不知道自己该建什么，这几个角度应该能帮你把思路理顺。

1. 别把Skills想神了：它的本质是一份岗位说明书

我最早看别人演示 Skill 的时候，确实觉得有点神奇：一句话丢过去，AI 自动调起工具、执行多步流程、还按固定格式输出，简直像给 AI 装上了一个领域大脑。后来我自己拆了个开源 Skill 的源码，发现里面的秘密一捅就破：所谓的技能，核心就是一个带固定结构的说明文件，外加可能存在的参考样例、脚本或资源目录。模型在运行时会把它当作“工作手册”来读，然后严格照着手册里的流程、边界和输出格式去执行。

1.1 为什么说它像“岗位说明书”

你可以把 AI 助手想象成一个刚入职的聪明毕业生。脑子很好使，知识面很广，但你如果只跟他说“把这个活儿干好”，他大概率会用自己的理解去干——也许干得还不错，也许方向完全跑偏。而一份岗位说明书会写清楚三件事：什么情况下需要接手这项工作；具体操作的步骤和红线；最后交付物长什么样、按什么标准验收。

Skill 干的就是这件事。它本质上不是在“教”AI 更多知识，而是在对同一个模型做运行时行为约束。有人觉得把大量背景知识塞进 Skill 是大杀器，其实 Skill 内联的知识密度相当有限，真正起作用的，是它把“什么时候调用、按什么步骤执行、以什么格式输出、碰见边界怎么处理”变成了每次运行都会生效的工作规则。

你当然完全可以在普通提示词里把这些约束写清楚。问题是：如果每次都想复用这套约束，难道每次对话都要重写一遍吗？如果某一套约束已经写了六十行，塞进每次会话里既不优雅也容易写漏。Skill 的意义恰恰是复用——把那六十行变成一次加载的工作手册，让 AI 在合适的时机自动按手册做事。

1.2 一个Skill的物理结构到底藏着什么

我实际打开过一个写得不错的 Skill 目录，通常会看到这几类东西：

• 一个核心说明文件，里面用了 YAML 格式的元信息和一大段 Markdown 正文。元信息里定义了技能名称、描述、使用场景、关键词触发条件；正文则是具体的执行流程、步骤、注意事项、输出格式和样例。
• 一个脚本目录，放着供 AI 调用的脚本，比如某个提取数据的 Python 脚本。模型可以读脚本并执行，或者把脚本当作工具来用。
• 一个引用目录，放着参考文档、模板片段，方便 AI 在执行时翻书。

可能有人会觉得：这不就是给模型加了一份检索知识库吗？不完全是。检索知识库偏向给模型补知识，而 Skill 偏向给模型定行为。同一个模型，有知识但不按你的流程走，照样能给你一个漂亮的错误答案。Skill 玩得转的人，都是把重心放在行为约束上，而不是全知全能上。

这个认知我觉得特别重要。因为很多人期待 Skill 能让 AI 瞬间懂得某个垂直领域，结果发现它并没有带来多少新知识，于是大呼上当。其实方向从最开始就搞错了——Skill 的价值是稳定地按你的预期办事，而不是把自己变成另一个模型。

2. 两分钟上手：从零到跑通的最小技能全流程

理论说多了没用，还是动手。我以一个最典型的应用场景——会议纪要归纳并提取待办事项为例，带你走一遍完整流程。整个过程熟练之后真的用不了两分钟，哪怕你是第一次弄，也就五六分钟的事。

2.1 第一步：想清楚触发条件和输入输出

很多人一上来就写“帮我整理会议纪要”，这句话作为 Skill 描述太模糊了，既不告诉 AI 什么时候该用，也没说清楚输入是什么、输出长什么样。我会先把需求拆成四件事：

• 触发场景：用户给出一段会议原始文本，或者粘贴了一份语音转写稿；
• 处理动作：抽取主题、结论、分歧点、待办事项、负责人和截止时间；
• 输出格式：用固定模板输出，最好带 Markdown 标题和复选框；
• 边界条件：如果原始文本太短、缺少负责人信息，该怎么处理？

这四件事想清楚，一个 Skill 的骨架就已经出来了。你根本不用等灵感，按这个清单填空就行。

2.2 第二步：把约束写进说明文件

打开你正在用的客户端技能管理界面，新建一个技能，填上名称、描述，然后往正文区写入下面这些内容：

--- name: meeting-minutes description: 适用于把会议原始文本、转写稿或聊天记录归纳成结构化纪要，并提取待办事项。当用户提供一段会议记录并要求整理时，使用本技能。 --- # 会议纪要与待办提取 ## 执行步骤 1. 将输入文本按逻辑分段，识别主题和结论。 2. 提取关键分歧点，用“未决议题”单独列出。 3. 提取待办项，每条标注负责人、截止时间和优先级。 4. 按模板输出。 ## 输出模板 ### 会议主题 ### 核心结论 ### 未决议题 ### 待办事项 - [ ] 事项（负责人：xxx，截止：xxxx-xx-xx，优先级：xx） ## 注意事项 - 如果输入文本中未提及负责人，输出时标注“负责人未明确”。 - 不要改写原文的实际含义，只做整理和归纳。 - 如果输入内容少于三句话，提示用户补充材料，不要强行生成纪要。

这段内容的核心就三块：开头用元信息告诉 AI 什么时候触发，中间列了执行步骤，末尾给了输出模板和边界。看起来简单，但已经能直接用。

2.3 第三步：立刻用真实样本跑一遍

文件写好之后，重点来了——千万别直接收藏，一定要立刻找一份真实的原始记录来测。我第一次做这个技能时，兴致勃勃保存，然后丢了一段很规整的会议纪要给它，结果输出异常漂亮。我差点以为自己成功了。

后来我把一段真实且凌乱的语音转写稿丢进去，问题全暴露了：没有标题、说话人混在一起、掺杂大量口头语和无法识别的指代词。我的技能因为没有写“输入可能很乱”的提示，AI 就按相对规整的文本来处理，结果提炼出的待办事项里混进了好几条根本不是结论的口语片段。

于是我在注意事项里加了一条：

- 输入文本可能包含口语化表达、重复语句和指代不清的内容。处理前先做“去噪”步骤：删除口头语、合并重复句、对指代不清的人名做标注。

这才算一个真正能打的技能。所以两分钟创建，五分钟测试，半小时打磨，这才是正常节奏。

2.4 关于是否放脚本的补充

有的场景光靠说明文件确实不够，比如要处理一百个 CSV 文件，或者批量重命名一批图片，这时候就需要在技能里附带脚本，并让 AI 在合适时机执行它。我的建议是：先别急着上脚本。能用说明文件加模板解决，就保持纯文本；确定有绕不开的重复操作，再加脚本。

因为脚本的加入会带来新的调试成本和运行环境依赖，对你的使用体验要求也更高。单一说明文件可读性最强，也最容易被模型理解，对大多数知识型任务完全够用。我见过有人一上来就给技能配了三个 Python 脚本，结果每次运行还要先处理脚本报错，反而把最核心的输出模板给丢了，这属于本末倒置。

3. 好用的Skill都是“痛”出来的：从真实痛点反向推导

我观察到一个现象：市面上那些口碑不错的 Skill，作者分享的时候经常说“我是因为某个需求太痛苦才写了这个”。这句话不是客气话，而是这些技能的真实孵化路径。

3.1 痛点识别：重复三次以上的事就该固化

判断一个场景适不适合做成 Skill 的标准很简单——这件事你是不是已经重复做了三次以上，而且每次做的时候都要重复交代同样的背景和格式要求？是的话，就该驯化它了。

我给你讲个我的真实例子。我有一段时间经常需要做零散的数据分析，每次都是同样的动作：把一张混乱的 Excel 表粘贴给 AI，要求“先识别表头，再统一日期格式，再做去重，最后按某个维度分组汇总”。这段话我打了没有二十遍也有十五遍，每次打完可能还要纠正它一次“别把百分比算成绝对值”。实在受不了，我才做了个“脏表格清洗”的技能，把清洗步骤、常见坑全部写进去，比如：

• Excel 里日期偶尔会以序列号形式出现，需要换算成正常日期；
• 数值字段可能有千位分隔符，直接相加会出错；
• 表头可能有合并单元格，需要先平铺再识别。

第一次用就发现，效果惊人地稳定，因为技能里已经包含了那些我曾经一遍遍口头纠正过的话。从此之后我就记住了一个方法论：技能不是凭空设计的，而是从一次次重复劳动中被痛出来的。

3.2 打磨路径：每一次用得不顺都是迭代机会

技能写好不意味着一劳永逸。真正好用的技能往往经历了一个“用→发现问题→改规则→再用”的循环。我自己总结的具体做法是这样的：

• 每次使用技能时，如果 AI 输出的某一部分让我不满意，我不会当场换一个说法重新问，而是把“它哪里做得不对”记录下来，退回技能配置文件里新增一条规则。
• 规则要写成模型听得懂的指令，比如“遇到金额字段时，必须按千分位逗号处理后再计算”，而不是写成“你注意数值可能带逗号”这种模糊建议。
• 每隔一段时间，把技能里的多条规则做一次去重和合并。因为规则太多了会让模型抓不住重点，需要梳理出哪些是真正高频的。
• 凡是这个技能确实不该处理的场景，直接在描述里写排除条件。例如“本技能只处理表格清洗，不负责图表生成；用户需要可视化时请退出技能”。

这套路径走下来，一个技能才会越来越像一个领域内真正有经验的老师傅，而不是一个装了很多零碎规则的大杂烩。

3.3 从“一句话需求”到“结构化技能”：一个演进实例

我再拿一个更具体的小技能来演示这种演进。我最初的需求是“帮我把长邮件回一下”。这个需求每个人都有一千种理解，我最早也真就这么写了一个技能，效果自然很一般。AI 回的邮件要么太热情，要么太冷淡，要么整篇都是在复述原邮件内容。

后来我复盘发现，问题出在我自己没想明白“回邮件”这件事拆开是五六个子环节：

1. 先判断是询价、投诉、合作还是日常同步；
2. 再站在我的角度决定是婉拒、接受还是进一步确认；
3. 接着抓对方的真实诉求；
4. 最后才是措辞风格。

于是我把“判断邮件类型”作为一个前置步骤写进技能里，又加了一条“回复正文控制在三到五个自然段，第一段指出收到的信息和对方核心关切”，顿时就不一样了。这个过程就是典型的痛出来的过程。它不是一个天才灵光一现想出来的，而是一封又一封糟糕的回复把我逼出来的。

4. 什么情况别用Skills，什么情况必须用

Skill 是个好东西，但不是万金油。用错了地方，反而会添乱。结合我自己的实际体会，这部分我分三种情况来说。

4.1 不建议用Skill的三类场景

第一类是“一次性任务”。比如你突然想帮朋友写个特别的祝福语，这种任务你根本不会复用，没必要建技能。建了反而增加维护成本，还会污染技能库。技能不是收藏癖的玩具，它必须服务高频动作。

第二类是“需要大量创意探索的任务”。这个比较反直觉，很多人以为越复杂的任务越该用 Skill，其实恰恰相反。技能的核心价值是稳定可复现，而创意探索需要的是发散和试错，如果你把发散过程固化成规则，模型很容易陷入模板化的表达，产出会很平庸。想清楚你是要“稳定标准答案”还是要“千奇百怪的可能性”，这两者对技能的需求完全不同。

第三类是“技能之间边界重叠”的情况。如果你建了两个技能，一个叫写文案提纲，另一个叫写营销脚本，结果两个技能描述里的触发条件几乎一样，模型在调用时就很容易犯迷糊，甚至同时激活两份规则，输出互相打架。这种情况还不如只保留一个。我的建议是：一个领域只保留一个主技能，最多再有一个功能完全不重叠的辅助技能。

4.2 必须用Skill的场景：当“稳定输出”成为刚需

反过来，下面三种场景我认为 Skill 是必需品。

第一种，你的任务里包含固定流程，比如数据分析的清洗、建模、验证、报告，每一步都有硬性要求。Skill 可以把流程的粒度精确到每一步该做什么，不会漏步，也不会跳步。

第二种，你的业务有行业级术语、规范或格式要求。普通对话里模型可能不熟悉这些术语，但 Skill 里可以内置术语表和参考格式，让它在调用时按规矩说话。以排版规范为例，如果你的工作要求标题层级固定、图表编号固定，把这些写进技能后，AI 每次产出的排版都能直接进系统。

第三种，你需要把个人风格稳定地表达出来。比如固定的写作风格、固定的周报模板、固定的对外话术，Skill 是承载这种风格包的好容器。它比单纯把几段提示词存起来更有效，因为它把触发时机和使用边界也一并约束了。

4.3 维护与退役：技能也需要“断舍离”

我见过有些人建了二十几个技能，最终真正用的只有三四个，太正常了。更好的管理方式是每过一个月就翻一下自己的技能列表，做一次断舍离：使用次数很低的技能，先问问自己是“这个场景真的没了”，还是“技能不好用所以不想用了”。前者删除，后者重新打磨。

另外，如果你开始用某个技能，却发现它的执行结果和直接对话差别不大，那也说明这个技能没有创造足够的行为差异。要么重构，要么删除，别留着占心理空间。技能在精不在多，这个道理和手机 App 一样。把那些吃灰的规则清走，剩下几个真正能打的核心技能，你的日常效率会明显不一样。

我在写完几个技能之后最大的一个感受是：Skill 真正改变的，不是我用了多聪明的提示词，而是我逼自己把那些“我以为很明白，其实根本没想清楚”的做事流程，一条条写成规则，让 AI 照着做。这个过程反过来又让我更懂自己手头的业务。所以哪怕你最后不打算用任何现成技能，我也建议你亲手建一个最小最简单的，比如就把你的一个日常工作流程变成技能。等你写完，你会发现，原来你对手头这件事的理解，比你以为的要模糊得多。

另外分享一个我在使用中养成的习惯：每次让 AI 跑完一个技能，我都会顺口追问一句“你刚才执行技能时有没有哪条规则你觉得模糊或者有歧义？”它的回答经常能指出我自己没发现的漏洞。把反馈收回技能文件里，会比你自己闷头改效率高很多。技能这东西，说到底是人机之间用来对齐规则的小容器，它不神秘，也没有那么复杂。用起来，然后持续修，它才真正值钱。