企业落地 AI Skill 的 12 个疑问

企业落地 AI，常见路径是 Prompt → RAG → AI 应用，复杂度依次递增。Prompt 灵活但不稳定，RAG 能接入知识库但工程量大，AI 应用功能完整但开发周期长、维护成本高。Skill 提供了一种介于 Prompt 和 AI 应用之间的务实选择：把反复出现的任务流程写成结构化文件，让 AI 按统一标准执行。它不依赖硬编码，是企业落地 AI 的一条轻量路径。

目前，企业内 Skill 落地仍在探索阶段。本文整理了实践中 12 个典型疑问及当前应对思路，供参考。

• Skill 是什么？
  • Q1: Skill 到底是什么？和 Prompt、MCP、AI 应用有什么区别和联系？
  • Q2: 企业内部哪些场景适合用 Skill？
• Skill 怎么建？
  • Q3: 不用 Claude，用其他模型落地效果差多少？怎么补救？
  • Q4: Skill 该让业务专家写，还是技术人员写？
  • Q5: Skill 文件存哪儿？需要像代码一样管版本吗？
  • Q6: 多语言/跨国团队，Skill 要分语言建吗？
  • Q7: Skill 需要测试吗？怎么测？
• Skill 怎么用？
  • Q8： Skill建好了怎么让用户发现并愿意用？
  • Q9： Skill 多了会不会识别错乱？怎么解决？
• Skill 怎么管？
  • Q10：Skill 需要监控和错题本吗？怎么持续优化？
  • Q11：Skill 可能改数据，怎么管权限保安全？
  • Q12：怎么避免 Skill 三个月热度，确保投资收益？

---

Part 1：是什么

❓ 1：Skill 到底是什么？和 Prompt、MCP、AI 应用有什么区别和联系？

Skill是什么

Anthropic Skill 是可复用的结构化指令集，采用“渐进式披露”架构，Claude 先只加载各个 Skill 的元数据（名称、描述等关键字段），等用户的任务意图匹配时，才拉取完整内容。这种设计让 Skill 成了嵌在对话流中的“智能顾问”，能自动发现并应用背景知识，在不超出上下文限制的情况下，输出更符合用户意图的结果。

从结构上看，Skill 不是“更长的 Prompt”或 Prompt 模板，而是一个完备的能力单元。一个标准的 Skill 通常包含：

• 任务边界：解决什么问题、不处理什么情况
• 输入/输出契约：参数、格式、结构约定
• 执行指令：任务步骤和判断条件
• 知识上下文：领域术语、规则文档、示例
• 工具调用：检索、表格处理、外部 API（可选）
• 校验机制：格式检查、规则核对
• 版本管理：CHANGELOG + 语义化版本号（参见疑问 5）

所以，Skill 的核心不是提示词技巧，而是把经验固化成可调用、可迭代、可治理的能力模块。

Skill vs. Prompt vs. MCP vs. AI应用

Prompt 用一次写一次；Skill 写一次可反复用，在 Claude 等原生支持的平台上，AI 能自动判断是否调用（其他模型需要自建路由）；MCP 不管业务逻辑，只负责连接外部系统；AI 应用是完整的工程方案，Agent 是其中专门负责任务编排的能力层，本文不做区分。

Skill 与 Prompt， MCP，AI 应用之间的联系

用户说："分析一下客户 12345 的健康度，如果风险高就创建跟进工单"

        │
        ▼
    [调度层] 识别意图，匹配"客户健康度分析"Skill
        │
        ├─→ 步骤 1：调取客户数据 ──→ [MCP] 查询 CRM 系统
        │
        ├─→ 步骤 2：分析评分 ────→ [Skill] 按内置规则计算
        │
        ├─→ 步骤 3：判断风险 ────→ [Skill] 评分<60 且 工单>2 则高风险
        │
        └─→ 步骤 4：创建工单 ────→ [MCP] 调用 Jira API
                                    │
                                    ▼
                            [AI 应用] 在飞书/自建系统展示结果
                                    │
                                    ▼
                            遇到流程未覆盖的异常情况 
                                    │
                                    ▼
                            [Prompt] 人工介入处理

案例 1：企业简历批量筛选与初评

某企业 HR 每天需要处理上百份格式各异的简历，流程涉及从招聘系统获取简历、解析内容、根据岗位要求评估匹配度、生成初评意见并录入系统。如果用 Agent + Skill + MCP 的方式拆解：

案例 2：企业合同法务预审流程

业务线提交商务合同后，法务需要核对付款条款、违约责任等，确保符合公司底线。使用协同架构的拆解方式：

小结：在分工上，Agent 决定做什么、按什么顺序做；Skill 提供环节执行方法和质量标准；MCP 负责连接外部系统，完成数据读写。在没有完整 Agent 能力的场景下，Skill 和 MCP 仍可单独或组合使用，由人工代替 Agent 统筹调度。

---

❓ 2：企业内部哪些场景适合用 Skill？

Skill 适用的场景条件

• 每周出现 3 次以上
• 有明确的SoP、判断标准和输出格式，不能靠"感觉"
• 多人要做同样的事，目前大家做得参差不齐
• 出错成本可控，人工能复核，不涉及资金或合规红线
• 不强依赖外部系统实时数据，需实时数据的场景通常要配合 MCP

Skill， Prompt， MCP和 AI应用的各自适用场景

说明：表格中的标记指单独使用时的适用性。实际场景中 Skill + MCP 组合使用是常见模式，比如用 Skill 定义分析流程，用 MCP 拉取实时数据。

---

Part 2：怎么建

❓ 3：不用 Claude，用其他模型落地效果差多少？怎么补救？

能力差异对比

补救思路：自建 Skill 路由

# 简化版 Skill 路由的工作流程描述（面向非技术人员）
路由注册表:
  可用服务清单: 
    - 财务报告
    - 客户健康度分析
    # ... 系统中登记的核心场景，类似于派单专员手里的“业务黄页”

路由作业流程:
  步骤1_服务发现与匹配:
    输入: 用户的自然语言请求
    匹配动作: 
      - 【方案 A】外接一个小巧便宜的 AI 模型专门负责意图打标签和分类
      - 【方案 B】提取请求关键词，去“可用服务清单”中做相似度匹配（当前实测性价比最高）
    输出: 智能锁定最对口的“目标 Skill”
    
  步骤2_工作指令组装:
    读取: 从系统中偷偷抽出该目标 Skill 身后的“专业处方模板”
    拼接: 将“专业处方”和“用户刚才的具体提问”揉合拼接在一起
    输出: 生成一段精确、充实、不缺漏上下文数据的系统指令
    
  步骤3_模型推演与沙箱保护:
    生成答复: 将上述组装好的饱满指令正式发送给主力大模型（如 Kimi、DeepSeek 等）去干活
    安全沙箱: （可选兜底保障）如果返回的答复中带有需要运行的数据处理代码，绝不能直接跑。
              系统必须将其扔进完全隔离的“安全沙箱”环境中试运行，切断搞坏系统的可能。
    交付落库: 最终将干净、加工好的分析结论呈现给终端用户

取舍提示：

• 不追求与 Claude 完全一致，先保障核心 Skill 的识别准确率
• Skill 总量控制在 20 个以内，降低路由复杂度
• Prompt 与业务逻辑解耦，后续如果切换模型，迁移成本可控

---

❓ 4：Skill 该让业务专家写，还是技术人员写？

我们试过三种模式，目前用的是第三种：

双人配合的具体分工：

建议每个部门培养 1-2 名"AI 翻译官"：既懂业务流程，又理解 AI 的能力边界，负责筛选需求和质量把关。

---

❓ 5：Skill 文件存哪儿？需要像代码一样管版本吗？

存储位置：Git 仓库，和普通代码同级管理。

目录结构：

skills-repo/
├── 财务/
│   ├── 月度报告/
│   │   ├── SKILL.md              # 当前版本（只读）
│   │   ├── CHANGELOG.md          # 变更记录：改了什么、为什么改
│   │   ├── test-cases/           # 黄金测试用例
│   │   │   ├── case_001.yaml
│   │   │   └── case_002.yaml
│   │   └── versions/             # 历史版本归档
│   │       ├── v1.0.0_20250115.md
│   │       ├── v1.1.0_20250320.md
│   │       └── v2.0.0_20250610.md  # 格式变更，影响下游解析
│   └── 预算审查/
├── 销售/
│   └── 客户健康度/
└── 研发/
    └── 代码安全审查/

版本规则：

我们踩过一个坑：更新了财务 Skill 的输出格式但没通知下游，导致依赖该格式的 Python 解析脚本报错，影响了月度关账。之后强制要求：输出格式变更必须走大版本升级，提前 3 天通告。

---

❓ 6：多语言/跨国团队，Skill 要分语言建吗？

我们的做法：核心英文 + 区域变体

核心 Skill（英文，逻辑层）
    │
    ├── 中文变体（描述、示例本地化）
    │       └── 关键词双语："客户健康度分析 / Customer Health Analysis"
    │
    ├── 日文变体
    │       └── 遵守当地个保法等数据合规要求
    │
    └── 德文变体
            └── GDPR 数据脱敏规则集成

分两层管理：

• 通用层：跨地区一致的流程，如数据分析算法与计算逻辑
• 区域层：本地化合规要求和术语差异，如国内个保法与欧盟 GDPR 间的脱敏规定

技术团队用英文编写 Skill 保障底层逻辑一致，业务团队用本地语言交互。只保留关键描述字段为英文以方便模型识别。

---

❓ 7：Skill 需要测试吗？怎么测？

分阶段测试：

黄金测试集示例（YAML 格式）：

# test-cases/case_001_high_risk.yaml
id: 001
desc: "高活跃但高投诉客户应标中风险"
input:
  customer_id: "12345"
  login_count: 25
  ticket_count: 4
  ticket_sentiment: "negative"
expected:
  health_score: 65
  risk_level: "中"
  action: "本周内主动触达，了解投诉详情"
  must_contain: ["投诉", "主动触达", "65"]
  must_not_contain: ["健康", "无需关注", "低风险"]
  
# test-cases/case_002_error_handling.yaml  
id: 002
desc: "客户 ID 不存在时应报错提示"
input:
  customer_id: "99999"
  error_simulation: true
expected:
  behavior: "error_graceful"
  output_should: "提示检查 ID"
  output_should_not: "崩溃/空指针/乱码"

自动化测试脚本：

# 简化版自动化测试工作流描述（面向非技术人员）
自动化测试流水线:
  执行频率: 每天凌晨自动对核心 Skill 测一遍，新版本发布前必须测一遍
  
  流水线作业步骤:
    步骤1_发送考题:
      动作: 批量调取当前 Skill 的“黄金测试集”（比如 100 道极端、易错的考题）
      执行: 逐一扔给 AI 去处理，不带任何人工干预
      
    步骤2_机器阅卷:
      格式体检: 检查 AI 交上来的卷子是不是标准的格式（例如必须是结构化的 JSON）
      得分点扫描: 核验答卷里是否必须包含了“指定关键词”（比如高风险等级的触发词）
      踩雷点排查: 核验答卷里绝对不能出现“违禁词”（比如明明有投诉，却不准出现“健康”）
      
    步骤3_巡检报告与飞书报警:
      评估: 汇总最终的批改成绩，计算总体不合格率
      处罚: 如果 100 道题里有超过 5 道答错（即错误率 > 5%）
      通知: 立马拉响警报，并在群里强行 "@该 Skill 的业务和技术负责人" 要求去修错题

补充说明：关键词断言适合格式和关键信息的检查，但对于主观性较强的输出（比如分析报告的行文质量），可以考虑用另一个模型做主观评判，按预设的评分标准打分。这部分我们还在试验中。

---

Part 3：怎么用

❓ 8：建好了怎么让用户发现并愿意用？

可通过三个层面引导：

1. 发现层：主动推送，不依赖用户搜索

• 按角色推：财务登录飞书，首页工作台直接展示财务相关的 Skill
• 按场景推：检测到用户上传 Excel，提示"是否用【数据分析 Skill】？"
• 按热度推：展示"同部门同事本周在用"（不显示具体内容）

2. 使用层：上手门槛尽量低

用户输入："分析一下这个月的销售数据"
        │
        ▼
系统提示："将使用【销售数据分析 Skill】，包含：趋势分析、环比、异常检测"
        │
        ├─→ 用户确认：执行
        └─→ 用户切换：展示其他可选 Skill 或转人工
        │
        ▼
输出结果（附分析依据的说明）

3. 引导层：在使用中学习

• 首次使用时，侧边栏展示 Skill 能做什么与不能做什么的能力边界
• 提供"示例输入"一键填充，降低启动门槛
• 输出旁标注分析依据，如"因工单情绪为负面，风险等级上调"

---

❓ 9：Skill 多了会不会识别错乱？怎么解决？

遇到的问题：Skill 从 5 个增到 20 个后，开始出现错配，比如该调"客户健康度分析"却调出了"客户画像生成"。

五个应对办法：

描述字段优化前后对比：

# 优化前
description: "帮助财务同事生成报告"

# 优化后
description: "财务月度管理报告：读取 Excel 经营数据，计算环比/同比，识别异常科目，输出 Markdown 格式报告，包含数据血缘说明"

---

Part 4：怎么管

❓ 10：Skill 需要监控和错题本吗？怎么持续优化？

建议监控的几个指标：

上述基线是我们根据自身情况设定的参考值，各团队可按实际调整。

错题本模板（Markdown 格式）：

## 错题记录 2025-06-15

**Skill**: 客户健康度分析 v1.2.1  
**发现人**: 王五（客户成功经理）  
**问题描述**: 
客户近 7 天登录 0 次，但支持工单激增 5 个且情绪负面。
Skill 标记为"健康"，没有提示风险，后来客户流失了。

**根因分析**: 
评分算法只考虑了"使用活跃度"，没有纳入"工单情绪"维度。

**修复方案**: 
v1.3.2 增加工单情感分析步骤，负面工单 >2 个且情绪为负时，风险等级强制上调一级。

**验证结果**: 
用 10 个历史流失案例复测，准确率从 70% 提升到 92%。

**负责人**: 张三（业务）+ 李四（技术）  
**修复期限**: 3 个工作日内

优化节奏：每月一次 Skill 评审会，过一遍错题本，决定修复、合并或淘汰。

---

❓ 11：Skill 涉及数据操作，怎么管权限和安全？

五类风险和对应措施：

Skill 默认只读。如果涉及诸如创建工单、更新 CRM 等写操作，需要满足三个条件：

1. 用户显式确认
2. 高风险场景加人工复核节点
3. 完整的操作日志

---

❓ 12：怎么避免 Skill 用了三个月就没人用？

Skill 推广失败通常不是因为 Skill 本身写得不好，而是没有解决使用动力的问题。常见原因：旧习惯更顺手、没有人要求必须用、出了问题没人维护、效果好坏也没人知道。

常见轨迹

• 第 1 个月：兴奋，全员使用 Skills，效率提升明显
• 第 3 个月：新鲜感消退，部分人回归老方法
• 第 6 个月：Skills 无人维护，逐渐废弃

长效运营机制

---

写在最后

基础模型的能力日新月异，复杂的 AI 应用工程化成本很高，Skill 提供了一种轻量的 AI落地方式。Skill 更为核心价值在于：把组织中个人零散的 AI 使用经验，转化成组织集体可复用的“数字知识资产”。无论基础模型能力如何发展，这些“数字知识资产”都能持续发挥作用，不会随着基础模型升级而失效。

不知大家在落地 Skill 的实践中遇到了哪些疑问呢？有没有不一样的心得呢？欢迎在评论区留言交流。