title: AI Skill构建的十个层次——从提示词到业务闭环的体系化实践
author: 于兆鹏
date: 2026-06-28
topic: AI Skill构建
word_count: 4200
target_audience: 通用技术读者
AIGC:
ContentProducer: '001191110102MAD55U9H0F10002'
ContentPropagator: '001191110102MAD55U9H0F10002'
Label: '1'
ProduceID: '6cad8bf0-e925-418e-a843-5df209e6f4d1'
PropagateID: '6cad8bf0-e925-418e-a843-5df209e6f4d1'
ReservedCode1: 'c073d3a4-443a-49bc-aa6b-ef64ec462780'
ReservedCode2: 'c073d3a4-443a-49bc-aa6b-ef64ec462780'
大模型应用正在从"对话式问答"向"技能式执行"演进。当一个AI助手不再只是跟你聊天，而是能自动完成一整套业务流程时，它需要的就不再是一个好prompt，而是一个结构化的Skill体系。
但问题是：Skill到底该怎么构建？从最简单的提示词文件到端到端的业务闭环，中间的跨度极大，很多团队在实践中常常不知道自己处在哪个阶段，更不清楚下一步该往哪里走。
本文将AI Skill的构建提炼为十个递进层次，从最基础的纯提示词Skill到最复杂的大师级业务闭环，形成一套完整的体系化框架。每一层都有明确的能力边界、典型结构和判断标准，帮助你定位当前水平和规划升级路径。
第一层：纯提示词Skill——零代码的起点
这是Skill构建的最基本形态：一个Markdown文件，里面包含角色定义、行为规则和输出格式要求。没有任何代码、没有任何脚本，完全依赖大模型的语言理解能力来执行任务。
典型结构：单个SKILL.md文件
核心能力：通过精心设计的提示词，让AI在特定场景下产生更准确、更规范的输出。比如一个"会议纪要整理Skill"，只需要在Markdown中写清楚：从哪些维度提取信息、输出什么格式、哪些字段是必填的。
判断标准：你的Skill只有一个文件，AI执行时不调用任何外部工具，完全靠"读指令→理解→输出"完成任务。
这一层的价值常被低估。一个写得好提示词Skill，效果可能比一个写得差的代码Skill更好。关键在于：规则是否足够具体、边界是否足够清晰、示例是否足够典型。
第二层：组件Skill——带资源的结构化增强
当纯提示词不够用时，你需要给AI"配装备"。这就是组件Skill：在SKILL.md的基础上，增加references目录（参考资料）、scripts目录（执行脚本）和assets目录（模板资源）。
典型结构：SKILL.md + references/ + scripts/ + assets/
核心能力：AI在执行时可以查阅参考文档、调用脚本处理数据、使用模板生成文件。信息提取器（Info-Extractor）就是典型代表——SKILL.md定义提取规则，references里放着字段映射表，scripts里可能有格式化脚本。
判断标准：你的Skill有多个文件，AI执行时需要读取references中的文档来指导行为，或调用scripts中的脚本来完成特定操作。
这层的关键突破是从"AI自己想"到"AI有据可查"。参考资料让AI的判断有依据，脚本让AI的动作有保证。
第三层：工作流Skill——多步骤决策树
单次调用难以完成的任务，需要拆解为多个步骤，每个步骤有自己的判断逻辑。工作流Skill引入了决策树结构：先做什么、再做什么、在什么条件下走哪条分支。
典型结构：SKILL.md中包含Workflow部分，Step 1 → Step 2 → Step 3，每步有前置条件和输出物。
核心能力：将复杂任务拆解为有序的步骤序列，每步有明确的输入、处理逻辑和输出。比如数据分析Skill：Step 1数据校验→Step 2统计计算→Step 3异常检测→Step 4洞察生成。
判断标准：你的Skill有清晰的步骤序列，步骤之间有数据传递，且存在条件分支（if-else逻辑）。
这层的突破在于"从一次性到流程化"。AI不再是"看到问题就回答"，而是"按步骤逐一执行"，每步的输出都成为下一步的输入。
第四层：编排Skill——多Agent协同
当一个Skill的步骤过于复杂，或者某些步骤需要完全独立的上下文时，你需要让多个AI Agent各自负责一个步骤，再通过结构化数据在它们之间传递信息。这就是编排Skill的核心思想。
典型结构：Phase-Orchestrator强制编排协议——每个Phase由独立sub-Agent执行，Phase间通过JSON传递数据。
核心能力：真正的多Agent并行或串行协作。Phase 1的Agent做完信息提取后，把结果以JSON格式传给Phase 2的Agent做分析，Phase 2的结果再传给Phase 3做安全审查，如此接力。
判断标准：你的Skill明确使用Phase-Orchestrator调度，每个Phase是独立的sub-Agent，Phase间有结构化的JSON数据传递协议。
这是Skill构建的分水岭。前三层都是"一个Agent干所有事"，从第四层开始，变成"多个Agent协作完成一件事"。好处是每个Agent的上下文更干净、职责更单一，坏处是编排复杂度显著上升。
第五层：安全Skill——权限管控与防护
当Skill开始具备调用外部工具、访问数据库、操作文件的能力时，安全就成了必须内置的能力，而不是可选的附加项。安全Skill的核心是最小权限原则：默认不给权限，一切权限必须显式声明和审批。
典型结构：Security-Guard组件——检查权限配置、数据访问范围、敏感字段处理、外发/删除动作、审计日志，输出风险分级与整改建议。
核心能力：在Skill执行前进行安全审查，识别过度权限、敏感数据泄露风险、高危操作，给出L1-L5的风险分级。
判断标准：你的Skill体系中有专门的安全检查组件，任何涉及数据访问、外部通信、文件操作的Skill都必须先通过安全审查才能执行。
这层解决的痛点是"AI太能干了反而危险"。没有安全管控的Skill就像没有刹车的汽车——速度越快，风险越大。
第六层：评分Skill——规则引擎参数化
业务场景中经常需要"按规则打分"：客户商机评分、供应商评估、流失风险预警……这些评分规则会随业务变化而调整。如果把规则硬编码在Skill里，每次规则变化都要改Skill；如果把规则参数化到YAML配置中，业务人员修改配置就行，Skill不用改。
典型结构：Scoring-Engine——规则存在YAML配置中，Skill只负责"读取规则→执行评分→输出结果"，4-Phase强制编排（信息提取→知识检索→数据分析→报告生成）。
核心能力：业务规则与执行逻辑分离。规则变了我改YAML，流程变了我改Skill，二者互不干扰。
判断标准：你的Skill使用外部配置文件（YAML/JSON）存储业务规则，Skill执行时动态读取规则而非硬编码。
这层体现的是一个重要的工程原则：配置与代码分离。在Skill语境下，它的意义更加重大——因为Skill的"代码"就是提示词，改起来更容易出问题，所以更需要把易变的部分外置。
第七层：验证Skill——多源证据交叉验证
当决策依赖多个数据源时，单一来源的信息可能不可靠。验证Skill的核心能力是从多个独立来源提取证据，互相交叉验证，检测矛盾，最终给出带置信度的判断。
典型结构：Evidence-Chain——接收多源数据（投诉记录、系统告警、操作日志、SLA指标），提取证据→交叉验证→冲突检测→置信度评估→根因推断。
核心能力：不是"信一个数据源"，而是"让多个数据源互相印证"。如果三个数据源中有两个说A、一个说B，不是简单地少数服从多数，而是要分析为什么B与A矛盾——是数据延迟、是口径不一致、还是确实存在异常。
判断标准：你的Skill从至少2个独立数据源获取信息，有显式的交叉验证逻辑，输出包含置信度评分。
这层解决的是"信息可信度"问题。在企业级AI应用中，单一信息源导致的误判代价极高，多源交叉验证是降低风险的关键手段。
第八层：审批Skill——人在回路风险控制
当AI要执行高风险操作时（发送群消息、修改客户数据、删除工单记录），不能让它直接执行，必须经过人工确认。审批Skill就是"人在回路"（Human-in-Loop）的机制实现。
典型结构：Human-In-Loop组件——自动评估操作风险等级（L1-L5），中高风险操作生成审批单（含风险提示、内容预览、确认选项），经人工确认后执行，全过程留痕归档。
核心能力：将"AI先做，人后看"变为"高风险操作，人先批"。L1-L2级操作AI自动执行，L3级提示用户注意，L4-L5级必须人工确认后才能执行。
判断标准：你的Skill体系有明确的风险分
