企业官网建设流程全解析

直接抛个结论：Skill 这个词，最近在 AI 圈子里火得不像话，但你要是以为它是什么高深莫测的新算法，那就想多了。它其实是一套很朴素的工程思路：把大模型从“只会聊天”改造成“能动手办事”。我自己从最早被这个概念绕晕，到后来亲手搭出十几个可用技能，中间踩了不少坑，今天这篇就把 Skill 的来龙去脉、内部结构、实操方法和常见问题一次性聊透。不管你是刚接触大模型应用的新手，还是已经在折腾 Agent 的老鸟，这篇文章都能给你一些能直接拿去用的东西。

1. 先搞清楚 Skill 解决的是什么问题

1.1 大模型看起来很聪明，但“缺手缺脚”

我最初接触大模型时的心态其实很简单：它能写文案、能总结文档、能写代码，感觉无所不能。但等我真的想让它“干点正事”时，第一个问题就来了——让它帮我查一下今天北京的实时天气，它只能告诉我“我无法获取实时信息”；让它帮我查一下订单物流，它只能给出一段礼貌的道歉。

这不是模型不够聪明，而是它天生就少了两样东西：第一，没有实时获取外部信息的能力；第二，没有操作外部系统、执行真实动作的能力。大模型本质上是一个基于历史文本训练出来的概率模型，它的知识截止于训练数据，它说不出来训练之后才发生的事，也没法主动去调用你手机里的 App 或公司的内部接口。

这就像你雇了一个知识渊博的顾问，他能给你讲清楚各种理论，但真要让他去仓库搬个箱子、给客户打个电话，他动不了手。大家天天喊着要让大模型“落地”，落地的前提就是你得给它安上“手”和“脚”，而 Skill 就是现在主流的安装方式。

1.2 Skill 的完整工作链路：感知、决策、执行

既然大模型缺手缺脚，Skill 要做的就是把外部能力补上去。一条完整的 Skill 调用链路，通常包含三个环节：

• 感知：接收用户输入，把“帮我看看北京明天会不会下雨”这样的自然语言，变成系统能识别的结构化需求。
• 决策：大模型根据用户意图和 Skill 的描述信息，判断“这个请求应该调用哪个技能”，并且把参数从对话里抽取出来。
• 执行：真正去调用外部 API、运行代码或者触发工作流，拿到结果后再交回给模型整理成自然语言回复。

我之所以说“决策”这个环节容易被忽略，是因为很多人第一次搭 Skill 时，把所有精力都花在“写执行代码”上，结果模型根本不知道该在什么时候调用它，或者把参数传得乱七八糟。实际上，决策是否准确，很大程度上不取决于代码多复杂，而取决于你对 Skill 的名字和描述写得够不够清楚。这块后面我会重点展开。

1.3 知识库和 Skill：一个负责“知道”，一个负责“做到”

有个问题我几乎在每个新手群裡都见过：知识库和 Skill 到底有什么区别？这俩确实容易混，因为它们都能让模型回答得更好，但作用维度完全不同。

知识库解决的是“模型不知道”的问题。通过检索增强生成（RAG），把外部文档切块、向量化、存进数据库，用户提问时先搜出相关内容，再塞给模型做回答。它的核心是给模型补充背景知识，让回答更准确、更贴合你的业务。

Skill 解决的是“模型做不到”的问题。它的目标不是让模型“说对”，而是让模型“办成”。用户要查天气，你给它接天气 API；用户要建工单，你让它调工单系统。知识库喂的是“料”，Skill 给的是“手”。

我之前做过一个内部知识助手，一开始只挂了知识库，它能流畅回答员工手册里的各种问题，但一碰到“帮我提交一个请假申请”就直接卡壳。后来给助手增加了一个“提交请假单”的 Skill，调用 OA 系统的接口，问题才彻底闭环。简单说，想让你的应用更有“行动力”，就上 Skill；想让你的应用“懂得更多”，就上知识库。两者可以共存，但别搞混。

2. Skill 的结构拆解：一段描述、一堆参数、一段执行逻辑

2.1 元信息：给模型一张“找得准”的入场券

任何一个 Skill，第一步都是定义它的“元信息”，也就是技能的名字和描述。你可能会觉得这有什么好讲的，随便起个名不就行了？但模型判断“该调用哪个技能”的时候，靠的就是这些文本。

我举个例子。你做了一个天气查询技能，如果名字叫“test123”，描述写成“一个查询天气的功能”，模型看到用户说“北京明天冷不冷”，它可能根本就不会联想到这个技能。但如果你把名字改成“get_weather”，描述写成“查询全球任意城市当前或未来数日的天气，包括温度、降水、风力等信息”，模型就能很自然地把它和用户的提问对上号。

这里有个很实用的技巧：描述写完后，可以默念三遍“如果我只看到这段描述，能不能判断出这个技能什么时候该用、什么时候不该用？”如果拿不准，就继续补充触发场景，比如“当用户询问出行建议、是否需要带伞、穿衣搭配时，也可以参考本技能返回的天气数据”。描述不是写给用户看的，是写给模型看的，这一点务必时刻记住。

2.2 参数清单：把自然语言翻译成代码能吃的结构化数据

Skill 要执行，就不能只靠一句自然语言。比如“帮我看看北京明天的天气”，你需要在后台把“北京”解析成城市编码，“明天”解析成具体日期，然后才能去请求气象 API。Skill 里的参数定义，就是给大模型一张“如何转化”的说明书。

常用 JSON Schema 来定义参数结构，核心字段一般包括：

• type：参数类型，比如 string 字符串、integer 整数、object 对象。
• properties：包含各字段的详细定义，每个字段都需要给类型、是否必填，以及关键的一句描述。
• required：必填字段列表。
• enum：可选值范围，比如天气单位是摄氏度还是华氏度，提前锁死能避免很多解析错误。

我贴一个实际使用过的天气技能参数定义，你感受一下：

{ "name": "get_weather", "description": "查询指定城市指定日期的天气信息，包括气温、天气现象、风向风速等", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，尽量使用标准中文名，例如北京、上海、广州" }, "date": { "type": "string", "description": "要查询的日期，格式为 YYYY-MM-DD，默认为今天" }, "unit": { "type": "string", "enum": ["celsius", "fahrenheit"], "description": "温度单位，默认 celsius" } }, "required": ["city"] } }

注意看，我在每个字段的 description 里都写了比较充分的解释。这样做的目的很简单：模型决策时，要看这些描述才能从对话里准确地抽出参数。假如描述写得太简略，比如只写“城市名”，模型遇到“去上海出差那天怎么样”这种口语化提问时，很有可能抽取失败。

2.3 执行逻辑：里面到底跑的是什么

Skill 的“执行逻辑”最常见的三种形式，我一个个说。

第一种，直接调外部 API。这是最典型的方式。比如查天气、查汇率、发短信、创建订单，本质上都是给某个 HTTP 接口发请求，接收返回值。Skill 里面存的是接口地址、请求方法、请求头、参数映射规则，以及如何把返回结果的 JSON 转成用户能看懂的文字。

第二种，运行一段代码。有些需求不依赖外部服务，比如数据清洗、格式转换、数学计算，直接在技能里放一段 Python 或 JavaScript 就行。这种方式非常轻量，特别适合在做内容处理类的应用时使用。

第三种，触发一个工作流。一些复杂任务涉及多个步骤或多个系统的协作，你可以把 Skill 理解成“总开关”，一旦被触发，就启动一个预设的流程。比如“查客户逾期账单并发送提醒短信”，这个动作涉及查询数据库、判断逾期状态、选择短信模版、调用短信通道，把它编排成一个工作流，再把入口封装成 Skill，使用起来非常顺手。

在执行逻辑这个环节，我想特别提醒一点：Skill 的边界要小。很多人恨不得一个 Skill 搞定所有事情，结果把它搞得又大又重，模型一触发就出各种幺蛾子。更好的实践是“一个 Skill 只做一件事”，把多个技能串起来交给上层的智能体去编排。后面我还会专门聊这个问题。

3. Skill 为什么火了？从四个层面看

3.1 从“建议型助手”到“执行型助手”的质变

前两年大家做聊天机器人时，关注点基本都在“话术像不像人”“回答专不专业”，本质上还是一个“建议型助手”——你说你感冒了，它建议你多喝热水；你说想学编程，它给你列个学习计划。这种助手有一个比较大的尴尬：它的价值止步于“动嘴”。

引入 Skill 之后，AI 应用完成了一次明显的定位升级。它不再只是给建议，而是真正能替你执行：你说“帮我约明天下午三点的会议室”，它直接调用会议室系统的接口把房间订好；你说“把这份表格按金额从高到低排序，再发给我邮箱”，它能跑代码完成处理并发送邮件。

从产品视角看，这一步跨越非常关键。用户为“建议”付费的意愿，跟为“结果”付费的意愿，完全不是一个量级。这也是为什么各家平台最近都在大力推 Agent、推技能市场，本质原因是“能干活”的应用才有可持续的商业价值。

3.2 一次定义、到处复用，Skill 成了团队的数字资产

Skill 还有一个容易被忽视的价值：复用性。我以前做项目时，很多基础能力是散落在不同代码里的，比如“查询天气”这个功能，A 项目写一遍，B 项目再写一遍，每个项目的写法还不一样，维护起来很痛苦。

用 Skill 的方式把它沉淀下来之后，情况完全变了。所有“查询天气”的逻辑就这一份，谁要用谁引入。你甚至可以把它发布到团队内部的技能库里，其他同事做任何需要天气信息的应用，直接拖过去就能用，不用关心底层是你用的哪个天气服务商。

这个思路放到公司层面就是实打实的资产积累。你把业务里那些通用能力挨个包装成 Skill，以后任何新项目启动，等于站在一个现成的零件仓库上干活，开发效率翻倍只是起步。

3.3 比“重新训练”省钱，比“提示词工程”稳定

很多人可能会问，想要模型完成特定任务，为什么不直接写个长提示词？或者干脆微调一个模型？这里面的账，我跟你算一算。

长提示词确实能引导模型完成一些事，但它的不稳定是出了名的。你把十几条指令塞在一起，模型很可能抓不住重点，或者在某个环节理解偏差，而且每次请求都要把大段提示词送给模型，token 成本并不低。微调模型的成本就更不用说了，数据准备、算力开销、模型维护，都不是一般团队能随便扛下来的。

Skill 的思路是“让模型做决策，让代码做执行”。决策部分只消耗少量 token，执行部分走 API 或本地代码，成本和稳定性都可控。我实测过同样一个“生成周报并发送邮件”的场景，纯提示词方案不仅经常格式跑偏，还偶尔会编造数据，而改成 Skill 方案后，格式由代码强制保证，模型只需要把用户这周做了什么转成结构化摘要，整个流程的质量明显稳定了许多。

3.4 平台生态正在把它变成“标准件”

还有一个不可忽略的助推因素：各个大模型平台和应用平台都在主动推“技能化”。类似 ChatGPT 的插件机制出来后，“让模型调用工具”就已经成了行业共识；到后面 LangChain、Coze、Dify 这类工具又把这个模式逐渐标准化，大家定义函数、绑定 API、给模型传工具清单的流程越来越一致。

标准化的意义在于：它大大降低了学习成本和迁移成本。你今天在一个平台上学会怎么搭 Skill，换到另一个平台，核心逻辑依然通用。生态里的技能市场也慢慢起来了，有些别人做好的技能，你稍微改改参数就能拿来用。Skill 能火，不仅仅是技术原因，更是因为它踩中了“基础设施标准化”这个节奏。

4. 实操：从零做一个“查天气” Skill

4.1 需求分析与接口准备

概念聊得再多，不如亲手搭一个。我拿最经典的“查天气”来演示，这个例子虽然简单，但该涉及的环节一样不少。

第一步，先想清楚你到底要实现什么效果。用户说完“查一下上海明天的天气”，你的应用能返回明天的气温、天气现象、风力这些信息，这就够了。先别急着加“要不要带伞”“适不适合跑步”这些衍生判断，第一步要把主链路跑通。

第二步，找一个能用的天气数据接口。我习惯用和风天气的 API，注册后可以拿到一个免费额度，返回的 JSON 里有温度、天气代码、风向等字段。你不需要专门买服务器，也不需要准备数据库，一个能发 HTTP 请求的环境就够。

第三步，准备好接口的调用方式。你需要知道自己要请求哪个 URL、需要哪些参数、返回结构是什么样的。这一步做扎实，后面写执行逻辑会很顺。

4.2 在平台上创建一个新技能

现在的应用平台大多支持可视化的技能编辑，以国内常见的智能体平台为例，操作路径大致是：进入项目空间，找到“技能”或“插件”入口，新建一个技能，然后选择“使用 API”或者“自定义代码”。

创建时需要填三样核心内容，正好对应前面讲的元信息、参数定义和执行逻辑：

• 技能名称和描述：根据 2.1 节的原则，往具体里写。
• 入参定义：定义 city、date、unit 这些字段，注意 city 用字符串、unit 用枚举。
• 执行逻辑：在代码区写入调用天气 API 的逻辑，并在末尾把结果转成模型可读的文本。

我用一段伪代码来说明后端逻辑长什么样，方便你理解整体结构：

import requests from datetime import datetime def get_weather(city: str, date: str = None, unit: str = "celsius"): # 1. 城市名转城市ID：实际项目中这里一般会调用地理编码接口 city_id = geo_code(city) # 2. 请求天气服务商接口 resp = requests.get( f"https://api.example.com/v7/weather/forecast", params={"location": city_id, "date": date or datetime.now().strftime("%Y-%m-%d")} ) data = resp.json() # 3. 把盘根错节的JSON整理成一句人话 temp = data["daily"][0]["temp"] text = data["daily"][0]["text"] wind = data["daily"][0]["wind_dir"] unit_label = "摄氏度" if unit == "celsius" else "华氏度" return f"{city}{date}的天气是{text}，气温约{temp}{unit_label}，风向{wind}。"

这段代码不是完整的生产级实现，但结构是对的：先解析参数，再请求外部接口，最后把结构化的 JSON 转成自然语言。模型拿到这段返回文本后，只需要做简单润色就能直接回复给用户，你的应用就跑通了。

4.3 参数设计的几个实操注意点

参数设计这一步，我把容易出问题的细节单独拎出来说。

一是城市名的标准化。用户可能说“上海”“上海市”“SHANGHAI”甚至“魔都”，但天气接口不一定认这些叫法。最稳妥的做法是加一道“地理编码”步骤：先把用户给的城市文本送到一个地理编码接口，换成一个标准的城市 ID，再拿着 ID 去查天气。这一步虽然多消耗一次请求，但能明显提高准确性。

二是日期的模糊表达。“明天”“后天”“下周三”这些说法，模型能理解，但接口只认具体的“YYYY-MM-DD”。所以你要在参数设计里让模型先把自然语言转成格式化的日期，或者在后端代码中处理相对日期。我建议前者，因为模型对“明天”的解释通常很可靠。

三是单位问题。不同用户习惯不同，有人在摄氏度、华氏度之间来回切换，你最好提供 unit 参数，并在描述里写清楚默认值。别在代码里硬编码单位，这是我在产品上线后被用户吐槽过最多次的细节。

4.4 联调测试要看的几个关键点

技能配置完成后，别急着接进对话流，先做一轮针对性测试。我会准备一组典型提问，逐条跑一遍看效果，重点观察这几个维度：

• 能不能触发：问“上海今天多少度”，看模型是否自动选中这个技能。
• 参数抽得准不准：看模型是不是正确把“上海”填进 city、“今天”填进 date。
• 返回结果顺不顺：最终给到用户的回答是否自然，有没有把 JSON 原文直接漏出去。
• 边界情况处理：问一个冷门城市，或者干脆不提供城市名，看技能会不会报错。

我实测过一版早期配置，当时城市参数解析经常失败，后来在描述里加了“尽量使用标准中文城市名，比如北京、上海、广州”这句话之后，成功率一下子就上去了。别看这句话简单，模型读不读得懂你的参数，很多时候就差在这些描述细节上。

5. 从调试到上线：我踩过的坑和排查思路

5.1 模型死活不触发技能？九成是描述写得像“废话”

我见过最多的问题就是：技能配好了，但用起来一点反应都没有。用户明明问了相关的问题，模型还是只靠自己的知识硬答。

排查思路只有一条：把技能名称和描述当作一个“独立判断题”再审一遍。如果描述本身写得太宽，比如“一个天气查询工具”，模型没有足够依据判断该不该用；如果描述和用户问题用词差异太大，比如描述里全是英文术语，用户却用中文问，模型也可能栽在匹配上。

真正管用的写法是“场景列举式”。不只要写“查询天气”，还要写“当用户询问明天是否适合出行、该穿什么衣服、会不会下雨时，也要调用本技能获取天气情况”。描述里包含足够的触发场景和同义表达，命中率马上不同。

5.2 参数传错、类型不对、日期变成乱码

技能能触发之后，第二个高发区是参数。参数层面的问题，通常一眼就能看出来，因为你会看到代码报错，或者后端收到一坨明显不对的数据。

我归纳常见的三类参数问题：

• 必填缺失：用户问“北京天气”，没有说时间，如果你把 date 设为必填，模型就会强行从上下文里猜一个，猜错了整个请求就废了。合理做法是改成可选参数，后端默认取今天。
• 类型不对：用户明明只说了一个城市，模型却传进来一个数组，或者把日期传成了时间戳。解决办法是严格定义 JSON Schema 里的 type，并加描述说“这是一个字符串，不要使用数组格式”。
• 语言混用：用户说的是“魔都”，模型原样传给后端，后端不认识。前端先做一步“别名清洗”能很大程度上化解这个问题。

5.3 返回结果不自然：JSON 原文直接露给用户

这个问题新手也常碰到。技能执行后拿到了天气接口的 JSON，结果模型没有做任何加工，直接把这些大括号、字段名甩给了用户。

解决方式有两种。第一，后端代码先把 JSON 转成一段很自然的文本，把“温度”“天气现象”“风力”糅进一句话里，模型拿到的是已经加工好的内容，出错概率就低。第二，如果确实需要让模型做二次总结，那就在技能的输出说明里明确写一句“这是一段机器返回的原始文本，不要原样输出，请结合上下文改写成自然回答”。

我个人的习惯是优先用第一种方案，能“简单干净”就别让模型二次发挥。

5.4 常见问题速查表

我把日常调试过程中的高频问题整理成一张表，方便你以后排查：

5.5 一个省心的发布习惯：日志与版本管理

Skill 这种模块，出问题常常是运行一两天后才暴露的，不是测一两轮就能看出来。我的建议是在技能后端里把每次调用的入参、出参、耗时、报错信息都打印到日志里。日志是你排查真相时最重要的依据，尤其是当用户反馈“答案感觉不对”但你又复现不了的时候。

另外，我强烈建议给每个技能做版本管理。不要“改完直接冲线上”，我吃过不少这方面的亏：有一次为了修日期解析问题，我把参数逻辑改了，结果老版本的兼容场景反而被打破了，线上用户的请求挂在数据库查询上，足足折腾了两小时。现在我的习惯是：每次修改都生成一个新版本，先在测试环境跑完回归用例，再决定是否切主版本。一套流程下来，踩坑率明显低了很多。

6. 进阶：从单个 Skill 到复杂任务的编排

6.1 一个任务同时需要多个 Skill，怎么编排

技能做多了之后，你会发现单个技能往往撑不起一个完整任务。比如用户说“帮我查一下去杭州的高铁，顺便看看杭州这几天下雨不”，这就涉及“查票”和“查天气”两个技能，甚至还要再叠加“计算日期范围”。

这时候你不需要去写一个更大的“万能技能”，更合理的做法是让上层智能体同时挂载多个技能，让它根据用户指令自行决定调用顺序。有些场景还有先后依赖关系，比如先查天气再给出行建议，这时候就要在工作流里把两个技能串起来，前一个的输出作为后一个的输入。我的经验是：优先让语音层“动态决策”怎么调用多个技能，只有当顺序完全固定时，再考虑用固定工作流去串。

6.2 技能多了之后，怎么才能“找得对”

等你把团队里的技能积累到几百个之后，一个新的问题会冒出来：模型怎么在几百个技能里快速选中正确的那一个？每个技能的描述都直接塞给模型，既不现实，效果也差，模型在长上下文里反而更容易“看走眼”。

现在行业内比较流行的做法是引入“技能检索”：把所有技能的名称和描述向量化，用户提出请求后，先通过向量相似度检索出 Top 5 或 Top 10 个候选技能，只把这几个技能的完整描述交给模型去决策。简单说，这就是给技能装了一个“目录”，避免模型在大海里捞针。等你真的管理了几百个技能，就会理解这一步有多必要。

6.3 企业落地时，别忘了安全和权限

最后必须聊聊安全边界。Skill 一旦能执行真实操作，它就不再是一个“聊天玩具”，而是一个真实工作入口。想象一下，如果你的智能体能调用“发送邮件”“创建订单”“删除文件”这类技能，那就必须对权限做好管控。

我常用的几个安全习惯，分享给大家参考：

• 最小化授权：每个技能只申请完成任务所需的最小权限，不要用一个通用 key 打通所有服务。
• 建立审计日志：所有技能调用都要可追溯，关键时刻能查出哪一次调用做了什么事。
• 严格校验输入：外部接口请求体里凡是涉及跳转地址、文件路径、代码执行的内容，都做白名单或正则校验。
• 分级审批：涉及资金、隐私、重要数据变更的操作，建议设计人工审批环节，而不是让模型全权代办。

这些不是空话。我看到过不少项目，技能本身做得很好，最后却在权限上翻了车，这种事一次就够长记性了。

关于 Skill，我在实际项目里最大的体会是：它本质上是“给模型立边界、给代码补能力”的工程思路，而不是什么学不会的魔法。想入门，就从做一个像天气查询这样的小技能开始，把描述的功夫练到位，把参数边界划清楚，再把日志和版本管理养成习惯，你会发现自己对大模型应用的掌控力明显提升了一个台阶。等你把这个流程跑顺了，回头再看那些复杂的 Agent 应用，拆开来看，也无非是一个又一个边界清清楚楚的 Skill 在协同工作。