AI Skill构建的十个层次——从零开始手把手教你搭建技能体系

很多同学问：AI Skill到底怎么构建？写个提示词就算Skill了吗？多个Agent怎么编排？安全怎么管控？今天这篇文章把Skill构建拆成10个层次，从最简单的Markdown文件到8+Skill协同的业务闭环系统，每层给出结构和代码示例，照着做就能上手。

---

步骤1：纯提示词Skill——零代码起步

做什么：用一个Markdown文件定义AI的行为规则，让它在特定场景下产出更规范的输出。

结构：单个 SKILL.md 文件

代码示例：

# 会议纪要整理Skill

## 角色
你是一个专业的会议纪要整理助手。

## 提取规则
从会议内容中提取以下5类字段：
- 会议时间：格式YYYY-MM-DD HH:mm
- 会议地点：线上/线下+具体位置
- 参会人员：列出所有参会者姓名和职务
- 决议事项：逐条列出，每条包含决议内容、负责人、截止日期
- 待办任务：格式为"任务描述 | 负责人 | 截止日期 | 优先级(高/中/低)"

## 输出格式
使用Markdown表格呈现决议事项和待办任务，其他字段用列表呈现。

## 注意
- 如果原文缺少某类字段，标注"未提及"，不要自行补充
- 决议事项必须是明确的行动约定，排除讨论性发言

关键技巧：

• 规则要具体，不要写"整理得好看一点"
• 边界要清晰，明确告诉AI什么不该做
• 示例要典型，覆盖常见和边界情况

注意：纯提示词Skill的效果常被低估。一个精心设计的提示词Skill，可能比一个写得差的代码Skill效果更好。

---

步骤2：组件Skill——给AI配装备

做什么：在SKILL.md基础上加入参考资料、执行脚本和模板资源，让AI有据可查、有工具可用。

结构：

Info-Extractor/
├── SKILL.md              # 提取规则定义
├── references/
│   └── field_mapping.md  # 字段映射表
├── scripts/
│   └── format_output.py  # 格式化脚本
└── assets/
    └── template.xlsx     # 输出模板

代码示例——字段映射表 references/field_mapping.md：

# 工单字段映射表

| 原始字段名 | 标准字段名 | 数据类型 | 是否必填 |
|------------|-----------|---------|---------|
| 投诉内容   | complaint_desc | text   | 是      |
| 客户手机   | customer_phone | string | 是      |
| 故障地址   | fault_address  | string | 否      |
| 处理时限   | sla_deadline   | datetime| 是     |

代码示例——格式化脚本 scripts/format_output.py：

# 格式化提取结果为标准JSON
import json
from datetime import datetime

def format_extracted_data(raw_data: dict) -> dict:
    """将原始提取数据格式化为标准输出"""
    result = {
        "complaint_desc": raw_data.get("投诉内容", "").strip(),
        "customer_phone": _normalize_phone(raw_data.get("客户手机", "")),
        "fault_address": raw_data.get("故障地址", "未提供"),
        "sla_deadline": _parse_datetime(raw_data.get("处理时限")),
        "extract_time": datetime.now().isoformat()
    }
    return result

def _normalize_phone(phone: str) -> str:
    """手机号脱敏：13812345678 -> 138****5678"""
    if len(phone) == 11:
        return phone[:3] + "****" + phone[7:]
    return phone

def _parse_datetime(dt_str: str) -> str:
    """统一时间格式为ISO 8601"""
    # 支持多种输入格式的解析逻辑
    for fmt in ["%Y-%m-%d %H:%M", "%Y/%m/%d %H:%M", "%Y年%m月%d日"]:
        try:
            return datetime.strptime(dt_str, fmt).isoformat()
        except ValueError:
            continue
    return dt_str

判断方法：你的Skill有2个以上文件，AI执行时需要读取references或调用scripts。

重要：这一层的核心突破是"AI自己想"变成"AI有据可查"。参考资料给判断以依据，脚本给动作以保障。

---

步骤3：工作流Skill——多步骤决策树

做什么：把复杂任务拆成有序步骤，每步有输入、处理逻辑和输出，步骤之间有数据传递。

结构：SKILL.md中包含Workflow，Step 1 → Step 2 → Step 3，每步有前置条件和输出物。

代码示例——数据分析工作流：

## Workflow

### Step 1: 数据校验
- 输入：原始数据集
- 处理：检查字段完整性、数据类型一致性、空值比例
- 输出：校验报告（通过/警告/失败 + 问题列表）
- 前置条件：无

### Step 2: 统计计算
- 输入：Step 1校验通过的数据
- 处理：计算均值/中位数/标准差/同比环比
- 输出：统计摘要表
- 前置条件：Step 1状态为"通过"或"警告"

### Step 3: 异常检测
- 输入：Step 2的统计结果
- 处理：基于3σ原则和业务阈值检测异常值
- 输出：异常点列表（含异常类型、偏离程度、可能原因）
- 前置条件：Step 2完成

### Step 4: 洞察生成
- 输入：Step 2统计结果 + Step 3异常列表
- 处理：综合分析，生成业务洞察和建议
- 输出：结构化分析报告
- 前置条件：Step 3完成

条件分支示例：

### Step 2的条件分支
- IF Step 1状态 = "失败"：
  - 不执行统计计算
  - 直接输出"数据质量不达标，建议修复后重新提交"
- ELIF Step 1状态 = "警告"：
  - 执行统计计算，但标注"数据存在轻微质量问题"
  - 在最终报告中增加数据质量说明章节
- ELSE：
  - 正常执行统计计算

判断方法：你的Skill有3个以上步骤，步骤间有数据传递，且有if-else条件分支。

---

步骤4：编排Skill——多Agent协同

做什么：让多个AI Agent各负责一个步骤，通过结构化JSON传递数据，用Phase-Orchestrator统一调度。

结构：每个Phase由独立sub-Agent执行，Phase间JSON传递数据。

代码示例——4-Phase编排协议（写在SKILL.md中）：

## 编排协议

本Skill使用Phase-Orchestrator强制编排，4个Phase由独立sub-Agent执行：

### Phase 1: Info-Extractor（信息提取）
- 执行者：独立sub-Agent-A
- 输入：用户原始请求
- 输出JSON：
```json
{
  "phase": "info-extraction",
  "extracted_fields": {
    "customer_id": "C12345",
    "query_type": "complaint_analysis",
    "time_range": "2026-06-01~2026-06-28"
  },
  "confidence": 0.92
}

Phase 2: Knowledge-RAG（知识检索）

• 执行者：独立sub-Agent-B
• 输入：Phase 1的输出JSON
• 输出JSON：

{
  "phase": "knowledge-retrieval",
  "matched_rules": ["规则A", "规则C"],
  "relevant_docs": ["处理规范v3.2"],
  "rule_confidence": 0.88
}

Phase 3: Data-Analyst（数据分析）

• 执行者：独立sub-Agent-C
• 输入：Phase 1 + Phase 2的输出JSON
• 输出JSON：

{
  "phase": "data-analysis",
  "analysis_result": {
    "trend": "上升",
    "anomaly_count": 3,
    "root_cause_candidates": ["原因1", "原因2"]
  }
}

Phase 4: Report-Generator（报告生成）

• 执行者：独立sub-Agent-D
• 输入：Phase 1 + Phase 2 + Phase 3的输出JSON
• 输出：最终结构化报告（DOCX/Markdown）

**判断方法**：你用了Phase-Orchestrator调度，每个Phase是独立sub-Agent，Phase间有JSON数据传递。

> **注意**：这是Skill构建的分水岭！前三层是"一个Agent干所有事"，从第四层开始变成"多个Agent协作"。好处是每个Agent上下文更干净，坏处是编排复杂度显著上升。

---

## 步骤5：安全Skill——权限管控与防护

**做什么**：给Skill体系加上安全审查组件，遵循最小权限原则，默认不给权限，一切显式声明。

**结构**：Security-Guard组件，在Skill执行前进行安全审查。

**代码示例**——安全审查检查清单（写在Security-Guard的SKILL.md中）：

```markdown
## 安全审查检查项

### 1. 权限配置检查
- [ ] 是否遵循最小权限原则？
- [ ] 是否存在不必要的全局权限（如 *.* 读取）？
- [ ] 文件操作权限是否限定在必要目录？

### 2. 数据范围检查
- [ ] 数据访问范围是否与业务需求匹配？
- [ ] 是否存在全表扫描操作？
- [ ] 查询是否包含合理的LIMIT限制？

### 3. 敏感字段检查
- [ ] 手机号、身份证等是否脱敏输出？
- [ ] 密码、密钥是否在日志中暴露？
- [ ] 敏感字段是否有访问控制？

### 4. 高危操作检查
- [ ] 是否包含DELETE操作？如果有，是否有二次确认？
- [ ] 是否包含批量写入操作？是否有数量限制？
- [ ] 是否有外发操作（HTTP请求/邮件发送）？目标白名单？

### 5. 审计日志
- [ ] 关键操作是否记录操作人和操作时间？
- [ ] 日志是否包含操作前后的数据快照？

风险分级输出示例：

{
  "skill_name": "customer_query_skill",
  "risk_level": "F",
  "risk_label": "禁止上线",
  "issues": [
    {
      "category": "高危操作",
      "detail": "存在delete_file权限且无二次确认",
      "severity": "CRITICAL"
    },
    {
      "category": "数据范围",
      "detail": "export_all允许导出全部客户数据",
      "severity": "HIGH"
    },
    {
      "category": "防御规则",
      "detail": "缺少defense_rules，无法抵御Prompt注入",
      "severity": "HIGH"
    }
  ],
  "remediation": [
    "移除delete_file权限或增加二次确认机制",
    "将export_all收敛为export_filtered+数量限制",
    "添加defense_rules防护Prompt注入"
  ]
}

判断方法：你的Skill体系有专门的安全检查组件，涉及数据访问/外部通信/文件操作的Skill必须先过安全审查。

重要：没有安全管控的Skill就像没有刹车的汽车——速度越快，风险越大。到这一层才能说你的AI系统有了"安全底线"。

---

步骤6：评分Skill——规则引擎参数化

做什么：把业务评分规则从Skill中剥离出来放到YAML配置里，业务规则变了改配置不改Skill。

结构：Scoring-Engine，规则存YAML，Skill动态读取执行。

代码示例——评分规则配置 scoring_rules.yaml：

# 政企客户商机评分规则
scoring_config:
  name: "政企客户商机评分"
  version: "2.1"
  total_weight: 100

dimensions:
  - name: "行业潜力"
    weight: 25
    rules:
      - condition: "行业类别 == '金融'"
        score: 25
      - condition: "行业类别 == '制造'"
        score: 18
      - condition: "行业类别 == '零售'"
        score: 12
      - condition: "default"
        score: 8

  - name: "信息化成熟度"
    weight: 30
    rules:
      - condition: "已有5G专网 == true"
        score: 30
      - condition: "上云比例 >= 0.6"
        score: 22
      - condition: "有数字化转型规划 == true"
        score: 15
      - condition: "default"
        score: 5

  - name: "关系紧密度"
    weight: 25
    rules:
      - condition: "合作年限 >= 3"
        score: 25
      - condition: "合作年限 >= 1"
        score: 15
      - condition: "default"
        score: 5

  - name: "决策人触达"
    weight: 20
    rules:
      - condition: "有CTO/CIO联系方式 == true"
        score: 20
      - condition: "有IT部门负责人联系方式 == true"
        score: 12
      - condition: "default"
        score: 3

# 评级阈值
rating_thresholds:
  high_opportunity: 80
  medium_opportunity: 55
  low_opportunity: 0

4-Phase编排：

Phase 1: Info-Extractor → 提取客户信息字段
Phase 2: Knowledge-RAG → 加载scoring_rules.yaml匹配规则
Phase 3: Data-Analyst → 按维度计分+加权汇总
Phase 4: Report-Generator → 输出评分报告+建议

判断方法：你的Skill用外部YAML/JSON配置驱动业务规则，而不是硬编码在提示词里。

注意：Skill的"代码"就是提示词，改起来更容易出问题，所以更需要把易变的部分外置到配置文件。

---

步骤7：验证Skill——多源证据交叉验证

做什么：从多个独立数据源提取证据，互相验证，检测矛盾，给出带置信度的判断。

结构：Evidence-Chain组件，接收多源数据执行交叉验证。

代码示例——交叉验证逻辑：

# 多源证据交叉验证核心逻辑
from dataclasses import dataclass
from typing import List

@dataclass
class Evidence:
    source: str       # 数据来源
    claim: str        # 主张内容
    confidence: float # 单源置信度 0-1

@dataclass
class ConflictResult:
    claim: str
    sources_for: List[str]    # 支持该主张的数据源
    sources_against: List[str] # 反对该主张的数据源
    resolution: str            # 矛盾原因分析
    final_confidence: float    # 最终置信度

def cross_validate(evidences: List[Evidence]) -> ConflictResult:
    """对同一主张的多源证据进行交叉验证"""
    sources_for = [e.source for e in evidences if e.confidence >= 0.7]
    sources_against = [e.source for e in evidences if e.confidence < 0.3]

    if not sources_against:
        # 无矛盾：取加权平均置信度
        final_conf = sum(e.confidence for e in evidences) / len(evidences)
        return ConflictResult(
            claim=evidences[0].claim,
            sources_for=sources_for,
            sources_against=[],
            resolution="多源一致，无矛盾",
            final_confidence=round(final_conf, 2)
        )
    else:
        # 存在矛盾：分析原因
        resolution = analyze_conflict(sources_for, sources_against, evidences)
        # 矛盾情况下降低最终置信度
        conflict_ratio = len(sources_against) / len(evidences)
        final_conf = (1 - conflict_ratio) * 0.6
        return ConflictResult(
            claim=evidences[0].claim,
            sources_for=sources_for,
            sources_against=sources_against,
            resolution=resolution,
            final_confidence=round(final_conf, 2)
        )

def analyze_conflict(for_sources, against_sources, evidences):
    """分析矛盾原因"""
    reasons = []
    # 检查是否为数据延迟
    if "实时监控" in for_sources and "日报系统" in against_sources:
        reasons.append("可能为数据延迟：实时系统与日报系统存在时间差")
    # 检查是否为口径不一致
    if any(e.confidence > 0.5 and e.confidence < 0.7 for e in evidences):
        reasons.append("可能为统计口径不一致")
    # 检查是否确实异常
    if len(against_sources) >= 2:
        reasons.append("多个独立数据源报告异常，需重点关注")
    return "；".join(reasons) if reasons else "原因待查"

判断方法：你的Skill从至少2个数据源获取信息，有显式交叉验证逻辑，输出包含置信度。

重要：单一信息源导致的误判代价极高！多源交叉验证是企业级AI应用降低风险的关键。

---

步骤8：审批Skill——人在回路风险控制

做什么：高风险操作执行前自动评估风险等级，中高风险必须人工确认后才执行。

结构：Human-In-Loop组件，L1-L5风险分级 + 审批流。

代码示例——风险分级定义：

## 操作风险分级标准

| 等级 | 风险描述 | 操作示例 | 处理方式 |
|------|---------|---------|---------|
| L1 极低 | 无副作用，可逆 | 查询统计数据 | AI自动执行 |
| L2 低 | 轻微影响，可回滚 | 更新客户标签 | AI自动执行，记录日志 |
| L3 中 | 有一定影响 | 发送内部通知 | AI提示用户注意，用户可确认/取消 |
| L4 高 | 影响较大，难回滚 | 修改客户核心数据、导出客户列表 | 必须人工确认后执行 |
| L5 极高 | 不可逆或涉及外部 | 删除工单、发送外部邮件、执行系统命令 | 必须人工确认+二次确认 |

审批单JSON格式：

{
  "approval_id": "APR-20260628-001",
  "risk_level": "L4",
  "operation": "export_customer_list",
  "operation_desc": "导出江西分公司的全部政企客户信息",
  "risk_alert": "将导出327条客户记录，包含联系方式和合同金额",
  "data_preview": {
    "record_count": 327,
    "fields_included": ["客户名称", "联系方式", "合同金额", "到期日期"],
    "sensitive_fields": ["联系方式", "合同金额"]
  },
  "options": ["确认执行", "取消", "修改范围后重新提交"],
  "require_double_confirm": false,
  "created_at": "2026-06-28T14:30:00Z"
}

执行闭环：

AI判断操作风险等级 → 生成审批单(含风险提示+内容预览)
    ↓
L1-L2：自动执行，记录审计日志
L3：提示用户，用户选择确认或取消
L4-L5：必须人工确认，可选二次确认
    ↓
执行结果归档（含操作人、时间、操作内容、审批记录）

判断方法：你的Skill体系有风险分级和人工审批机制，存在"AI请求→人工确认→执行"三步闭环。

注意：人在回路不是对AI的不信任，而是对业务安全的必要保护。AI再强也有不该独自做决定的场景。

---

步骤9：组合Skill——5+Skill编排成完整链路

做什么：将5个以上基础Skill编排为端到端业务流水线，用户一句话触发整条链路。

结构：以"智能数据查询面板"为例，5个Skill + 1个Gateway编排器。

代码示例——Gateway编排协议：

## 智能数据查询面板 - Gateway编排协议

用户输入自然语言 → 5个Skill依次执行 → 输出结构化结果或可视化图表

### 调用链路

```mermaid
graph LR
    A[用户输入] --> B[NL2Query 意图识别]
    B --> C[Security-Guard 权限校验]
    C --> D[Data-Executor 安全查询]
    D --> E[Data-Aggregator 聚合计算]
    E --> F[Visualization-Renderer 图表渲染]
    F --> G[输出结果]

技能职责

Skill	职责	输入	输出
NL2Query	自然语言转SQL	用户输入文本	结构化查询对象
Security-Guard	权限校验	查询对象	校验通过的查询
Data-Executor	执行SQL	校验后的查询	原始查询结果
Data-Aggregator	统计聚合	原始结果	聚合后数据
Visualization-Renderer	图表渲染	聚合数据	HTML/图片图表

数据传递协议

• Skill间通过JSON传递
• 每个Skill必须声明 input_schema 和 output_schema
• 上游失败时整个链路终止并返回错误信息

**判断方法**：5个以上Skill通过统一编排链接，用户一个自然语言输入即可完成端到端流程。

> **重要**：组合的难度远高于单个！接口协议、数据格式、错误传播、性能瓶颈，每一个都是工程挑战。

---

## 步骤10：闭环Skill——8+Skill端到端业务操作系统

**做什么**：构建8个以上Skill协同的完整业务闭环，覆盖"理解→分析→决策→执行→归档"，支持自进化。

**结构**：以"政企客户智能运营助手"为例，8步闭环 + 11个Skill协同。

**代码示例**——8步闭环定义：

```markdown
## 政企客户智能运营助手 - 8步闭环协议

Step 1: 理解意图
  - Skill: Info-Extractor
  - 输入：用户原始需求
  - 输出：结构化客户信息 + 查询意图

Step 2: 多源查询
  - Skill: Knowledge-RAG + Data-Executor
  - 输入：Step 1输出
  - 输出：客户全景数据（业务数据+知识库+外部信息）

Step 3: 规则评分
  - Skill: Scoring-Engine
  - 输入：Step 2输出 + scoring_rules.yaml
  - 输出：多维度评分结果（商机评分/流失风险/信用评级）

Step 4: 证据验证
  - Skill: Evidence-Chain
  - 输入：Step 2 + Step 3输出
  - 输出：交叉验证结果 + 置信度

Step 5: 根因定位
  - Skill: Root-Cause-Mapper
  - 输入：Step 4输出
  - 输出：根因推断 + Mermaid拓扑图

Step 6: 人工确认
  - Skill: Human-In-Loop
  - 输入：Step 5输出（高风险时触发）
  - 输出：人工审批结果

Step 7: 执行归档
  - Skill: Archive-Manager
  - 输入：Step 6输出
  - 输出：归档记录 + 标签 + 脱敏数据

Step 8: 可视化输出
  - Skill: Report-Generator + Visualization-Renderer
  - 输入：Step 6 + Step 7输出
  - 输出：DOCX报告 + HTML运营看板

自进化机制：

# 每次闭环执行后自动沉淀经验
experience_log = {
    "execution_id": "EXEC-20260628-001",
    "customer": "江铃集团",
    "scoring_result": {"business_opportunity": 84, "churn_risk": 55},
    "key_insights": [
        "制造业客户对5G专网需求最强",
        "合作3年以上客户流失风险低但增值空间有限"
    ],
    "corrections": [],  # 人工纠正的判断
    "timestamp": "2026-06-28T14:30:00Z"
}
# 写入self-evolving-agent的记忆，后续执行自动参考

判断方法：8个以上Skill协同，覆盖完整业务闭环，具备自进化和可观测能力。

---

总结：十层速查表

层级	核心特征	一句话判断标准	所需新能力
1	纯提示词	写过可复用的SKILL.md	提示词工程
2	带资源	Skill有references或scripts	文件组织
3	工作流	有多步骤决策树+条件分支	流程设计
4	多Agent编排	用Phase-Orchestrator调度sub-Agent	编排调度
5	安全管控	有安全审查机制和风险分级	安全工程
6	规则引擎	用YAML配置驱动评分规则	配置化设计
7	交叉验证	从多源数据交叉验证+置信度	证据推理
8	人在回路	高风险操作需人工审批	审批流设计
9	组合编排	5+Skill端到端完整链路	系统集成
10	业务闭环	8+Skill闭环+自进化+可观测	架构设计

务实的升级路径：先到第3层（工作流） → 再到第5层（安全） → 然后到第8层（审批） → 最后冲击第10层（闭环）。

核心原则：先让Skill跑起来，再让Skill跑得安全，最后让Skill跑成系统。

---

常见问题FAQ

Q1：我只会写提示词，连代码都不会，能做Skill吗？

能。第1-3层完全不需要写代码，纯Markdown就能搞定。从第4层开始才涉及JSON和脚本，但也只是配置而非编程。

Q2：每个Skill都必须走满10层吗？

不用。大部分业务场景3-5层就够了。第8层（审批）只在高风险场景才需要，第10层是终极目标，不是每个项目都要到。

Q3：Phase-Orchestrator和普通工作流有什么区别？

关键区别：普通工作流是一个Agent串行执行所有步骤；Phase-Orchestrator是每个步骤启用独立Agent，Agent间通过JSON传递数据。独立Agent的上下文更干净，不会"前面步骤的信息干扰后面步骤的判断"。

Q4：安全审查会不会拖慢开发速度？

短期会，长期不会。在Skill数量少的时候安全审查看起来"多此一举"，但当Skill超过10个、多个Agent协作时，没有安全审查就像盲开——你不知道哪个Skill在越权操作。建议从第5层开始就内置Security-Guard。

Q5：YAML配置和硬编码提示词，到底差在哪？

改YAML改一次配置文件30秒搞定，改提示词可能改出连锁问题。更重要的是：YAML可以由业务人员维护，提示词只能由技术人员维护。配置与代码分离，是这层最大的工程价值。

Q6：组合Skill和闭环Skill的区别是什么？

组合Skill（第9层）是一条业务链路，有明确的起点和终点；闭环Skill（第10层）是一个持续运转的系统，能自进化、可追溯、有降级策略。类比：组合Skill是流水线，闭环Skill是整个工厂。

Q7：人在回路会不会让AI变得不好用？

恰恰相反。人在回路只在高风险操作时介入，L1-L2级操作AI自动执行，用户根本感觉不到。它让用户更放心地把任务交给AI——因为有明确的"刹车"机制。

AI生成