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

大语言模型在知识问答、文本生成、代码编写等任务上展现出强大的“理论能力”，但当企业试图将其引入工厂、医院、办公室等真实业务场景时，普遍会遇到同一个问题：模型更像一位“懂理论的教授”——能背诵规范、能解释流程，却难以稳定地“把活干完”。生成结果格式漂移、操作步骤遗漏、工具调用不当、输出口径不统一，这些细节问题构成了AI落地的“最后一公里”。

2025年下半年起，一个以“技能”（Skills）命名的范式在行业内快速流行：某海外头部AI实验室率先提出并让自研大模型原生支持该能力，随后国内外多家主流厂商与智能体平台陆续跟进，部分平台还上线了“技能商店”类功能，将Skills译作“技能”在国内推广开来。它试图解决的，正是“懂理论不会实操”的痛点：把难以言传的操作诀窍封装成标准化模块，让模型精准调用。

但对技术团队而言，真正的决策问题并不是“要不要用技能”，而是：在提示词工程、检索增强生成（RAG）、微调、智能体框架与技能封装这几条“能力注入”路径之间，当前业务应该选哪条？它们各自解决什么问题、代价是什么、边界在哪里？本文将围绕这些问题展开系统对比。

二、对象定义：几条路径分别在做什么

1. 提示词工程：把业务经验写成提示词，在每次请求时随上下文传给模型。它改变的是“这一次对话的输入”，不改变模型本身，也不引入外部系统。

2. 检索增强生成（RAG）：将业务文档、规范、案例等知识放入知识库，检索模块按问题召回相关片段，再交给模型组织答案。它解决的是“知识在模型之外且频繁更新”的问题，本质是让模型“开卷考试”。

3. 微调：用业务数据对模型做进一步训练，把知识和风格“内化”进模型参数。适合沉淀稳定、可复用的表达风格与领域模式，但训练与评估周期较长，效果与特定模型版本强绑定。

4. 智能体：在大模型之上增加规划、记忆、工具调用等运行框架，让模型能拆解任务、循环决策、调用外部接口。它解决“多步骤任务的编排与决策”问题，是行为框架而非知识载体。

5. 技能：把某类任务的步骤、规范、模板、脚本等“操作诀窍”封装成标准化模块（通常是一个包含操作说明、可执行脚本与参考资源的文件包），由模型在任务匹配时按需加载并执行。它解决的是“程序性知识”的复用问题，让经验从“只可意会”变成AI可执行、可版本化、可流通的资产。

需要强调：技能并不与其他方案互斥。一个成熟的企业AI应用，常见形态是“基座模型 + 知识库（陈述性知识）+ 技能包（程序性知识）+ 智能体框架（任务编排）”的分层组合。

三、相同点分析

尽管实现路径不同，这几种方案在更深层面有明显的共同点：

• 目标一致：都是为了缩小“通用模型”与“业务要求”之间的差距，让输出更准确、更稳定、更贴合规范，而不是改变模型的基本能力形态。
• 同一底座：都以大语言模型为推理核心，遵循“以模型为中心组织能力”的基本格局；无论提示词、检索结果还是技能说明，最终都转化为上下文进入模型。
• 依赖评测：任何一条路径都需要建立业务评测集持续验证效果。没有评测，就无法判断注入的经验是否真的生效，也无法在迭代中防止效果回退。
• 本质都是“经验的外化或内化”：提示词、RAG与技能把经验放在模型之外，微调把经验写进参数，路径不同，回答的却是同一个问题——“如何让模型具备业务经验”。

四、核心差异分析

1. 知识形态：陈述性知识 vs 程序性知识

这是最关键的差异。RAG与提示词主要承载陈述性知识（“是什么”：规范条文、产品资料、历史案例）；技能主要承载程序性知识（“怎么做”：步骤、顺序、判断条件、格式要求、异常处理）。微调对两者都有一定吸收能力，但对精确操作步骤的控制力较弱——参数化记忆难以保证“每次都严格按第3步执行”。因此，当业务痛点集中在“步骤错、格式乱、流程漏”时，技能的匹配度天然更高；当痛点是“答案不准、知识过时”时，RAG更对症。

2. 确定性与可执行性

技能包中可以包含可执行脚本：数据清洗、格式校验、报表生成等确定性操作交由代码完成，模型只负责理解意图与编排调用。这把“可意会的经验”变成“可执行的代码”，输出的确定性和可审计性显著优于纯生成路径。提示词与RAG的最终产出仍由模型逐token生成，天然带有概率性；微调改变的是输出分布上的倾向，同样不提供执行保证。这也是技能被视为让AI从“聊天”走向“干活”的关键原因。

3. 加载方式与上下文成本

提示词方式每次请求都要携带完整经验文本，长提示词带来持续且重复的token开销；技能按需加载——只有任务命中该技能时才注入对应说明，长尾请求不必为此付费。RAG按检索结果注入片段，成本与知识库规模及召回策略相关；微调将知识压入参数，推理时无额外上下文开销，但训练成本前置。对于高频调用且经验文本较长的业务，按需加载的结构性优势会随调用量放大。

4. 迭代速度与维护成本

• 提示词：改动即生效，迭代最快；但经验散落在大量对话与代码中，难沉淀、难复用、难做版本管理，团队规模扩大后维护成本快速上升。
• 技能：改文档、换脚本、发版本，迭代以小时到天计；技能是独立文件包，可命名、可测试、可分享，这也是“技能商店”类能力出现的逻辑基础——把技能当作可流通的工程资产。
• RAG：迭代重点在知识库治理（切分策略、更新频率、去重、权限），工程量中等，长期看质量取决于治理投入。
• 微调：每轮迭代都涉及数据准备、训练、评估、发布，周期最长，失败回滚成本最高，且需要专门的训练与评估管线。

5. 安全与合规边界

技能包含可执行逻辑，意味着新的攻击面：脚本需要在受控环境（沙箱）中运行，权限应最小化，操作需要审计；从外部引入的技能还需要来源审核机制。RAG的关注点是数据隔离与召回权限（不同角色可见的知识范围不同）；微调的关注点是训练数据的合规性与输出可控性；提示词的关注点是提示词注入风险；智能体的关注点是工具调用的权限控制。五者的安全建设重点完全不同，不能互相替代。

6. 迁移性与抗变化能力

技能、提示词与RAG的知识以外部文件或数据形态存在，原则上可跨模型、跨平台迁移（前提是目标平台支持兼容的技能规范与脚本运行环境）；微调产物与特定模型版本强绑定，基座模型升级时往往需要重新训练。在基座模型快速演进的当下，外置经验的抗变化能力明显更强，这也是把操作经验封装为技能而非全部压进参数的现实理由之一。

7. 与智能体的分工

智能体提供“决策与编排”（什么时候做什么），技能提供“具体怎么做”（做这件事的标准动作）。没有技能的智能体，每一步都要靠模型即兴发挥，稳定性差且难以审计；没有智能体的技能，只能响应单点任务，无法处理多阶段流程。两者是互补关系而非竞争关系，实际系统往往是“智能体调度、技能执行”的组合。

五、对比总览表

维度	提示词工程	RAG	微调	智能体	技能
承载内容	临时操作要求	陈述性知识	风格与领域模式	任务编排框架	程序性知识
知识位置	请求上下文	外部知识库	模型参数	运行时框架	独立技能包
生效方式	每次随请求注入	按检索结果注入	训练后内化	运行时规划调用	任务命中时按需加载
输出确定性	低	低	中	中	中高（可绑定脚本）
迭代周期	分钟级	天级	周级	天级	小时至天级
上下文成本	每次重复支付	与召回相关	推理时低	视编排而定	按需支付
版本管理	弱	中	与模型版本强绑定	框架管理	强（文件包形态）
安全重点	提示词注入	数据隔离与召回权限	训练数据合规	工具权限控制	脚本沙箱与来源审核
典型问题	临时定制	“是什么”类问答	风格与术语内化	多步骤流程	“怎么做”类任务

六、一个通用技能包示意

skills/
└── quarterly-report/
    ├── instruction.md      # 操作说明：步骤、输出规范、易错点
    ├── build_report.py     # 可执行脚本：取数、校验、生成报表
    └── templates/          # 参考模板：报表样式、字段口径

调度逻辑（伪代码）：

def handle(task):
    skill = registry.match(task)          # 1. 任务匹配技能
    if skill is None:
        return llm.direct(task)           # 兜底：直接生成
    ctx = skill.load_instruction()        # 2. 按需加载操作说明
    data = sandbox.run(skill.script) if skill.needs_script(task) else None  # 3. 受控执行脚本
    return compose(llm, ctx, data)        # 4. 组装最终输出

关键在于：指令、脚本、模板三者配套，操作知识不再依赖口头传承或散落各处的提示词，而是变成可测试、可回归、可分发的独立单元。

七、典型场景选择

• 场景A：知识密集型问答（产品资料、制度条文咨询）。答案存在于文档中且频繁更新——RAG为主，辅以提示词约束输出格式。
• 场景B：强规范输出（按企业模板生成报表、合同初稿、检查单）。痛点是格式与步骤——技能为主，把模板与校验逻辑固化进技能包。
• 场景C：领域风格与术语体系内化（行业表达习惯、统一口径）。稳定且要求全局一致——可评估微调或系统级提示词，再配合技能处理具体任务。
• 场景D：多环节业务流程（从原始数据到分析报告、从需求到排期）。需要拆解与决策——智能体做编排，技能承担每个环节的标准动作，RAG提供事实依据。
• 场景E：临时性、一次性任务。快速验证——提示词即可，不值得沉淀为技能；待同类任务重复出现再考虑封装。

八、选型建议（条件化）

1. 先判断问题类型：用户抱怨集中在“答案不准、不知道”——优先RAG；集中在“步骤错、格式乱、不稳定”——优先技能。这一步判断错误，后续投入容易事倍功半。
2. 再看知识变化频率：频繁更新且由业务人员维护的内容，适合外置为知识库与技能；长期稳定且追求响应风格统一的诉求，可评估微调。
3. 看团队工程能力：没有训练与评估管线能力的团队，不宜把微调作为首选；技能与提示词的维护门槛更贴近应用团队。
4. 看复用与流通需求：多个应用、多个团队需要共享同一套操作规范时，技能的文件包形态天然支持版本化与分发，明显优于各自维护提示词。
5. 平台化路线：若团队自建与运维能力有限，可评估百度智能云等云厂商在大模型平台中提供的知识库、组件编排、智能体构建等通用托管能力，把精力聚焦在技能内容与业务评测上，而不是底层基础设施。

九、迁移与使用注意事项

• 从提示词迁移到技能：先做提示词资产盘点，把高频、稳定、有明确步骤的经验优先封装；为每个技能写清楚触发条件与适用边界，避免技能之间冲突或重叠。
• 跨平台迁移技能：确认目标平台对技能目录结构、说明格式与脚本运行环境的兼容程度；不兼容时优先迁移说明文档，脚本需按目标环境适配并重新测试。
• 引入外部技能：坚持来源审核、最小权限、沙箱执行与操作审计；外部技能应先在隔离环境通过评测，再进入生产链路。
• 微调与技能的取舍：已有微调模型不必急于替换，可并行引入技能，用同一评测集对比效果，再决定是否收敛到单一方案。
• 建立回归机制：技能是“可执行的经验”，任何改动都必须跑评测；建议为每个技能维护最小用例集，发布前自动回归，防止经验更新引入退化。

十、总结

回到最初的问题：技能之所以被视为大模型从“懂道理”走向“会干活”的关键一跃，在于它把此前只能“口头传授”的程序性经验，变成了可版本化、可执行、可流通的工程资产，从而缓解了通用AI“懂理论不会实操”的核心痛点。但它与提示词、RAG、微调、智能体并非替代关系：提示词解决临时定制，RAG解决“是什么”，微调解决风格内化，智能体解决编排决策，技能解决“怎么做”。选型的正确姿势不是二选一，而是按知识类型与变化频率做分层组合，并用统一的评测体系持续验证——这才是AI真正跨过落地“最后一公里”的工程路径。