Skills、微调与提示词：大模型能力注入方式对比

一、对比背景：AI落地的“最后一公里”卡在哪

近年来，大语言模型（LLM）在知识问答、文本生成、代码编写等“理论型”任务上表现出色：它能背诵百科知识、推导数学公式、模仿各种文风写作。但当企业试图把AI真正引入办公室、工厂、医院等现实业务场景时，一个残酷的事实浮出水面——模型像一位“懂理论的教授”，知道报表该长什么样，却不知道贵司的月报要按哪套口径、走哪几步流程、用哪个模板输出。

为了让模型从“懂道理”转向“会干活”，业界主流存在三种能力注入方式，这也是本文明确对比的三类对象：

• 方案A：提示词工程——把任务要求、背景知识、输出格式以自然语言写进对话上下文；
• 方案B：模型微调——用领域标注数据对基座模型做再训练，把能力“烧进”参数；
• 方案C：Skills技能包——把某项任务的“操作诀窍”封装成标准化模块，供模型按需精准调用。

Skills这一概念由海外某头部模型厂商于2025年10月率先提出并在其模型中率先支持，随后国内外主流厂商产品陆续跟进，国内也有智能体平台上线了“技能商店”类功能，使其成为当前AI应用层最受关注的技术方向之一。下文将围绕三种方式的相同点、差异点、适用场景与选型依据展开系统分析。

二、对象定义：三种方式分别是什么

1. 提示词工程（方案A）

把任务要求以自然语言写入系统提示或对话上下文，依靠模型的“阅读理解”临时改变行为。特点是零训练、见效快，适合控制输出风格与格式；但所有指令都常驻上下文窗口，任务越复杂，指令遵循的稳定性越容易下降，且经验散落在各次对话中，难以沉淀为团队资产。

2. 模型微调（方案B）

用标注好的领域数据对基座模型进行再训练，使模型在参数层面记住领域语言习惯、格式偏好与任务模式。适合改变模型的“底层表达习惯”，但对流程性、操作性的“诀窍”表达能力有限——模型学会的是“像什么”，而不是“怎么一步步干”；且每次迭代都需要数据准备、算力投入与评估流程，周期以天计。

3. Skills技能包（方案C）

把某项任务的操作规程、参考模板、可执行脚本等，组织成结构化的技能包。模型先“看到目录”（技能名称与用途描述），再按任务需要“按需加载”具体内容，像调用插件一样精准取用。其加载流程可用通用示意表达：

用户请求 → 意图理解 → 匹配技能描述(仅名称与用途) → 按需加载技能正文
        → 按规程执行(必要时调用脚本) → 结构化输出

一个典型技能包的目录结构如下（通用示意，非任何专有工具）：

skill_package/
├── manifest.json        # 技能描述：名称、适用场景、触发条件
├── instructions.md      # 操作规程：分步骤执行说明
├── scripts/             # 可执行脚本：确定性处理逻辑
│   └── transform.py
└── templates/           # 输出模板与参考样例
    └── report_template.xlsx

需要特别说明的是，Skills与智能体（Agent）不是竞争关系：Agent负责“决策与编排”，Skills负责“提供干活的本事”。业界常概括为——LLM懂理论，Agent会决策，Skills才是AI落地的“手术刀”。

三、相同点分析

三种方式虽然在实现路径上差异明显，但在目标与底层逻辑上高度一致：

• 目标一致：都是为了弥合通用模型与具体业务之间的鸿沟，让模型输出符合业务标准的“结果”，而非泛泛而谈；
• 依赖同一基座：三者都不改变大模型本身的推理架构，能力都建立在通用基座模型之上；
• 都需要知识显性化：无论写成提示词、做成训练数据，还是编写技能规程，前提都是把原本存在于人脑中的领域知识整理出来；
• 都服务于落地质量：三种方式的最终检验标准相同——业务场景中的准确率、稳定性与合规性。

四、核心差异分析

1. 作用层面：上下文、参数与资源层

提示词作用于上下文层，会话结束即失效，能力不随对话留存；微调作用于参数层，能力固化但难以解释、难以热更新；Skills作用于资源层，以文件形式存在，可版本管理、可独立迭代，与基座模型解耦。层次不同，决定了三者在灵活性、可维护性上的根本差异。

2. 知识载体：隐性经验如何被封装

提示词中的诀窍散落在各处对话里，人走茶凉；微调把经验压进参数，但“只可意会”的流程性知识很难用问答对表达；Skills则把诀窍显性化为“规程+脚本+模板”的组合，把“只可意会”的经验变成AI可执行的代码——这是Skills最关键的突破，也是它被称为落地“手术刀”的原因。

3. 上下文开销与调用精度

提示词方案把所有要求一次性塞进上下文，任务越多、规则越长，无关信息干扰越大，指令遵循越不稳定；Skills采用“先注册描述、按需加载正文”的渐进式机制，模型先匹配技能名称与用途，再加载具体规程，显著降低无关信息干扰，调用更精准，token成本更可控。

4. 更新与迭代成本

改提示词最快，但难以沉淀复用；微调一次迭代以天计，需要数据、算力与评估闭环；Skills的更新以“改文档、改脚本”为单位，以小时甚至分钟计，且可以做灰度发布与回归验证，业务规则一变，当天即可生效。

5. 复用、分发与组合

Skills天然面向复用：一个数据整理技能包，可以在报表、清洗、归档等多个场景中组合调用；技能包可在团队内外共享分发，这正是“技能商店”类功能出现的产业背景。提示词难以标准化分发，微调模型则与特定基座版本绑定，换基座几乎要重做。

6. 安全与治理

• 提示词：主要风险是提示注入与信息泄露，治理手段相对成熟；
• 微调：训练数据合规需提前评估，模型行为难以逐条解释，出问题定位成本高；
• Skills：技能包边界清晰——描述、规程、脚本分离，脚本可沙箱执行、可审计，权限可按技能粒度分配；但脚本执行引入了新的安全面，需要白名单机制与运行时隔离配套。

7. 成本结构

提示词人力成本低，但长期token开销高、质量波动带来的隐性返工成本高；微调前期投入高、后期边际成本低，但基座升级时迁移成本接近重做；Skills前期需要梳理流程、编写规程，投入居中，长期维护成本低，且不随基座模型升级而失效。

差异总览表

维度	提示词工程	模型微调	Skills技能包
作用层面	上下文层	模型参数层	资源/知识资产层
知识载体	自然语言指令	训练数据→参数	规程+脚本+模板
更新成本	低（改文本）	高（数据+算力）	低-中（改文件）
上下文开销	全量常驻，开销大	无额外开销	按需加载，开销可控
流程稳定性	长任务易失焦	稳定但难控制具体步骤	步骤明确，稳定性高
复用与分发	弱	弱（绑定基座）	强，可组合、可商店化
安全治理	注入/泄露风险	数据合规、不可解释	脚本沙箱、权限、审计
适合任务	风格与格式控制	领域语言、固定风格	多步骤业务流程
主要局限	难沉淀、难复用	迭代慢、迁移成本高	依赖流程可显性化

五、典型场景选择

• 输出风格、格式、语气控制：提示词优先，改动快、成本最低；
• 领域术语与固定文风，且任务模式简单：可考虑微调，例如统一客服话术风格；
• 多步骤业务流程：如“把原始数据按指定口径整理成月报”，Skills优先；
• 复杂AI应用：组合使用——微调打底、提示词做轻量控制、Skills承载核心流程。

以“生成月度经营报表”为例，三种方式的工作方式差异非常直观：

1. 提示词方案：在对话中贴出全部口径与格式要求，模型每次生成都要“重新读一遍规则”，字段一多就容易遗漏；
2. 微调方案：用历史报表训练模型，模型能模仿格式，但口径一变就要重新准备数据、重新训练；
3. Skills方案：把口径、步骤、脚本封装成“报表生成”技能包，模型按规程调用脚本处理数据，口径变更只需更新技能包版本并回归验证。

六、选型建议

选型不应看“哪种更先进”，而应看条件匹配：

• 团队缺乏训练资源或标注数据不足时，优先“提示词+Skills”组合，避开微调的高门槛；
• 对输出风格一致性要求极高、任务模式简单稳定时，微调的收益更明显；
• 流程性强、规则频繁变化的业务，Skills的版本化更新能力优势最大；
• 从企业整体落地看，建议以Skills为骨架沉淀业务流程资产，以提示词处理轻量控制，把微调留给真正需要改变模型“语言习惯”的场景；
• 以百度智能云为代表的大模型服务平台，普遍提供提示词模板、模型微调、智能体编排以及工具与插件接入等通用能力，团队可结合自身工程能力，评估各环节在平台侧与自建侧的合理分工。

七、迁移与使用注意事项

1. 从提示词迁移到Skills：先盘点散落在各业务中的提示词，把“高频、多步骤、有明确流程”的部分重构为技能包；描述文件的质量直接决定调用准确率，必须写清适用场景与触发条件；
2. 技能粒度设计：一个技能包对应一个可清晰命名的任务，粒度过粗难以复用，过细则增加模型匹配负担；
3. 脚本安全：可执行脚本必须限定运行环境、遵循最小权限、做输出校验，并纳入代码审计与版本管理；
4. 回归测试：为每个技能包建立评测集，每次更新执行回归，防止规程修改引起输出漂移；
5. 与既有链路兼容：Skills的加载机制需与现有智能体编排框架的工具调用方式对齐，避免形成双轨维护；
6. 版本与权限管理：技能包纳入统一版本管理，按团队与角色控制可用范围，操作留痕以满足审计要求。

八、总结

三种能力注入方式不是替代关系，而是作用于不同层面的互补关系：提示词解决“临时怎么说”，微调解决“底子像不像”，Skills解决“具体怎么干”。Skills之所以在短时间内从海外AI企业出圈到国内、引发广泛跟进，是因为它把AI落地“最后一公里”的操作诀窍，变成了可版本化、可分发、可组合的工程资产，让AI从“聊天机器人”走向“业务能手”。对技术团队而言，正确的决策思路不是押注单一路线，而是按任务性质分层组合——轻量控制交给提示词，风格与语言习惯交给微调，核心业务流程交给Skills，并配套做好安全治理与回归测试，才能真正让大模型在业务中“会干活、干好活”。