Skill 技能层：做好一件事
一句话： Skill 是 OPC 的地基。一个 Skill 只做一件事，并且要能被清楚地评估「做得好不好」。
一、是什么
Skill 是把某一件具体的事做好的、可复用的能力单元。
判断一个东西是不是合格的 Skill，看三条：
| 特征 | 含义 | 反例 |
|---|---|---|
| 边界窄 | 只负责一件事 | 「处理所有客服问题」——太宽，不是 Skill |
| 可评估 | 有输入、有期望输出、有对错标准 | 「让客户满意」——无法判断对错 |
| 可复用 | 换场景、换平台也能用 | 只对某一个订单写死的脚本——不可复用 |
一个好 Skill 的名字通常能写成「对【什么输入】做【什么处理】得到【什么输出】」。比如：「对【订单号】查询【物流状态】并生成【安抚话术】」。
二、为什么用
构建数字员工最大的误区，是一上来就想「让 AI 搞定电商客服的所有事」。这就像招一个新人，不培训任何具体技能就让他上岗——结果必然是崩。
Skill 层解决的三个核心问题：
- 把模糊的任务变具体：「做好客服」是模糊目标，「根据订单号查物流并生成话术」才是可执行的。
- 能独立验证：只有窄到一件具体的事，才能说清「做得好不好」。
- 能力可累积：做出 10 个靠谱的 Skill，封装岗位才立得住。反之 10 个半吊子，岗位就是空壳。
关键纪律：永远从最小的、能做好的一件事开始。 OPC 三层里，Skill 层是你花时间最多的第一层——地基不牢，上面全是危房。
三、怎么用
第 1 步：用模板定义一个 Skill
定义一个 Skill 时，把下面几项填清楚：
Skill 名称：<一句话，动宾结构>
解决什么问题：<这个 Skill 存在的理由>
输入：<需要什么信息才能开始>
处理：<要做哪几步>
输出：<产出什么，什么格式>
做好的标准：<什么样算合格、什么样算优秀>
适用场景：<在哪些情况下会用到>
示例——电商客服的「查物流生成话术」：
Skill 名称：根据订单号生成物流催促话术
解决什么问题：客户催发货时，客服要快速给出得体、准确的回复
输入：订单号
处理：查物流状态 → 判断是否延迟 → 套用对应话术模板
输出：一段可直接发给客户的话术
做好的标准：信息准确、语气得体、无需人工二次修改
适用场景：客户咨询「我的货到哪了」「怎么还没发」
第 2 步：把做好的标准拆成「合格」和「优秀」两档
合格线：信息准确，不需要人工大改，可直接发送
优秀线：语气贴合品牌调性、主动安抚情绪、客户不再追问
没有这两档，评估就是「凭感觉」。而且两档之间有明确的优化方向——合格到优秀，差在哪几个维度。
第 3 步：收集测试样本并逐条打分
准备 ≥20 条真实输入，逐条按标准判分，统计：
| 指标 | 定义 | 记录方式 |
|---|---|---|
| 准确率 | 输出信息正确的比例 | 20 条里对 18 条 = 90% |
| 可用率 | 无需人工修改可直接用的比例 | 20 条里 15 条免修 = 75% |
| 一次通过率 | 第一次运行就达到合格线的比例 | — |
| 失败类型分布 | 错在哪（编造信息 / 语气差 / 漏关键点） | 分类统计，指导改进 |
第 4 步：三种打分手段（按难度选）
规则判分：输出能用明确规则判对错（如订单状态是否正确）→ 直接写脚本统计。
对标判分：找一个别人已经做出真实结果的案例，让你的 Skill 去逼近它：
- 有真实结果 → 用你的 Skill 产出结果，对比差距。
- 没有真实结果 → 让一个更强的 AI 模拟出「标准答案」，再对比。
AI as Judge：产出好坏难用规则界定（如语气是否得体），让 AI 按给定维度打分并说明理由。注意：
- 给 AI 明确的评分维度（准确性、语气、完整性……）
- 配 1~2 个好/坏示例让它对齐标准
- AI 裁判也会错，评分标准越具体越好
第 5 步：写成简历式结论
Skill「物流催促话术」评测：
基线（人工）：平均 5 分钟/条，口径不统一
结果（数字员工）：40 秒/条，准确率 90%，可直接发送率 75%
一句话：把话术产出从 5 分钟降到 40 秒，准确率 90%。
完整的三层量化评测方法（含 Post/Company 层、反馈闭环）见 07 · 数字员工效果评测。
四、案例
案例 1：一家女装淘宝店的「查物流话术」Skill 构建全过程
背景： 杭州一家日均 300 单的女装淘宝店，大促期间每天收到 150+ 条「我的快递到哪了」，客服人均回复 5 分钟/条，客户满意度差。
第 1 步——定义：
Skill 名称：根据订单号生成物流催促话术
输入：订单号
做好的标准：物流信息 100% 准确，话术能直接发送，客户收到后不再追问
第 2 步——准备样本： 从过去一个月提取 30 条真实催件消息作为测试集。
第 3 步——跑第一版：
- 准确率 70%（9 条物流状态查错）
- 可用率 40%（18 条需要人工改）
第 4 步——定位问题： 失败的集中在两个情况——「包裹已签收但客户说没收到的」「跨境物流状态描述不清」。Skill 没有处理这两种分支。
第 5 步——迭代后第二版：
- 准确率 93%
- 可用率 80%
- 响应时间：15 秒（原来是 5 分钟）
- 客户追问率：从 40% 降到 12%
简历句： 把大促催件话术从 5 分钟/条压到 15 秒，可用率 80%，客户追问率降 70%。
关键教训： 第一版失败不是因为「不够智能」，而是因为测试样本不够真实。最初的 5 条测试都是「正常物流」场景，等换上 30 条真实数据，两个高频边缘情况立刻暴露。
案例 2：在线教务的「作业催收提醒」Skill
背景： 一家 K12 在线机构的教务每天花 2 小时手动发催收消息，家长回复率仅 15%。
定义：
Skill 名称：根据学生数据生成作业催收提醒
输入：学生姓名、已逾期天数、科目、上次提交时间
输出：一条针对性的催收消息（含鼓励/紧迫感）
做好的标准：家长回复率 ≥ 50%，不引起家长反感
测试： 50 个真实逾期学生，对比人工催收 vs 数字员工催收。
| 指标 | 人工 | 数字员工 Skill |
|---|---|---|
| 家长回复率 | 15% | 52% |
| 催收耗时 | 2h/天 | 3 分钟 |
| 家长投诉 | 0 | 0 |
为什么数字员工表现更好？ 因为 Skill 每次都能根据不同逾期天数调用不同话术模板（刚逾期 → 温和提醒；逾期 3 天 → 紧迫提醒；逾期 7 天 → 升级话术），而人工教务容易疲劳，下午发的催收消息质量明显下降。
五、简单 Skill vs 高级 Skill
| 维度 | 简单 Skill | 高级 Skill |
|---|---|---|
| 步骤 | 单步、一次问答 | 多步、有流程和分支 |
| 依赖 | 只靠模型本身 | 需要查资料、调工具、读记忆 |
| 例子 | 「把这段话改得更礼貌」 | 「查订单 → 判断问题类型 → 走对应处理流程 → 生成回复」 |
| 什么时候用 | 事情本身很简单 | 一件事内部还有分支和依赖 |
原则：先能做出简单 Skill 并评估合格，再升级成高级 Skill。 不要一上来就追求复杂。大多数失败的高级 Skill，拆开来看是几个简单的子步骤都没跑稳。
六、Skill 是通用的
一个真正做好的 Skill，不绑定某一个平台。同一个 Skill 的定义（要解决的问题、输入输出、评判标准）应该能在不同的运行环境里复用。这是判断你有没有真正「抽象出一件事」的试金石：
如果换个平台就要重写，说明你做的不是 Skill，而是一段一次性脚本。
七、常见误区
| 误区 | 表现 | 为什么错 |
|---|---|---|
| Skill 太宽 | 一个 Skill 想解决一整个岗位的活 | 边界模糊，无法评估，等于没做 |
| 只做不评估 | 跑通一次就觉得完了 | 换真实数据立刻崩；没有基线的「结果」是耍流氓 |
| 没有做好的标准 | 说不清「什么叫好」 | 无法迭代优化，也无法向别人证明价值 |
| 测试样本太干净 | 用 5 条自己编的测试 | 真实场景的边缘情况才是杀手——必须 ≥20 条真实输入 |
| 追求复杂 | 一上来堆多步流程 | 简单情况都没跑稳，叠加上去只会雪崩 |
| 做太多 Skill 不聚焦 | 一个人做 10 个半吊子 Skill | 不如做好 1 个并拿评估数据说话 |
| 把平台配置当 Skill | 「我在 WorkBuddy 里配了一个工作流」 | Skill 定义是能力和标准，不绑定平台 |
八、与其他工具的关系
- 上游：05 · 细化分析法——从这里找到你该做的第一个 Skill
- 下游：03 · Post 岗位层——做好 ≥3 个 Skill 后，进入岗位封装
- 配套：07 · 数字员工效果评测——Skill 层的完整量化评估方法论
- 约束：01 · OPC 模型——没有靠谱 Skill 就别想往上走
九、下一步
技能做好了，下一步——把 3 个以上相关 Skill 封装成一个能独立成事的岗位 → 03 · Post 岗位层