第二章 · Skill
01 / 11
?
互动一分钟 · 带着问题听
什么是 Skill？
它和写一段更长的提示词，有什么不同？
很多人第一反应：Skill 不就是把 prompt 写长一点、写细一点？
如果只是这样，为什么 Anthropic 要专门给它一套结构、一套加载机制？
现场讨论 1–2 分钟 下一页揭晓答案
P10 · 一句话定位

Skill 是给 AI 用的，不是给人用的

Skill 不是「提示词扩展」
是把一个场景的经验 / 流程 / 工具 / 输出契约沉淀成可复用资产
给人看的说明书　→　给 AI 用的能力包　·　服务对象是 AI

1固化「容易踩的坑」

把调用工具、跑业务时反复踩的坑写成规则 —— 让 AI 不再每次重新犯错。

2固化垂直知识与 SOP

把垂直领域的专业判断、标准操作流程沉淀下来，AI 按既定路径走。

3消除「业务转技术」的偏差

业务需求 → 技术脚本之间的指令偏差，靠 Skill 的明确契约抹平。

4两个视角看 Skill

一个是 Anthropic 的 Skill 标准，一个是「为 AI 设计」的 研究视角。

P11 · Skill 的结构

SKILL.md + 渐进披露三级加载

左边是三级加载机制，右边用 Anthropic 自带的 Excel（xlsx）Skill 实际展开看一眼 —— 为什么要这样分层。
▌ 机制：三级加载
L1
metadata
常驻上下文 · ~1500 token / 40 个 Skill
只有 name + description 一直在。AI 靠它判断「该不该用这个 Skill」。
▼ 命中后才载入
L2
SKILL.md
按需载入 · 完整操作说明
真的要操作 Excel 时，才把正文读进来 —— 流程、规则、注意事项。
▼ 需要时再取
L3
references / scripts
关联资源 · 脚本运行
脚本不进 context，由 Harness 执行，AI 只读它打印的 stdout。
▌ 实例：把 Excel Skill 目录展开
xlsx/ # Anthropic 自带的 Excel 技能
├─ SKILL.md ◀ L1 metadata（描述常驻）
   └ 正文：怎么读写/格式化表格 ◀ L2
├─ references/ ◀ L3 按需读
   ├ formulas.md # 公式用法
   └ formatting.md # 样式规范
└─ scripts/ ◀ L3 只跑不读
   └ recalc.py # 公式重算引擎
为什么要分层
用户没碰 Excel 时，整个技能只占 SKILL.md 头部那几十字；一旦说「改下这张表」，才逐层把正文、formulas.md、recalc.py 取进来。能力可以很大，context 始终很小。
P12 · 为什么模型需要 Skill【重点】

六大结构性缺陷 —— 都源自训练方式本身

模型能力越强、翻车越多 —— 「能做」和「做得好」之间，有一道根本的鸿沟。
1

知识时效性断层

训练有截止日期。截止之后的库版本、API 变更、新规则，模型一概不知。

例
某 Python 库今年升到 v3、API 全变了，模型仍按一年前的 v2 写法生成代码 —— 一跑就报错。
2

私有知识不可获取

企业内部口径、业务流程、专有方法论从未进入训练语料 —— 模型根本没见过。

例
「单方成本」到底含不含税、按哪个口径算 —— 这是公司内部定义，模型只能瞎猜。
3

会踩坑（毒性遗产）

训练数据里混着大量错误写法，模型学了也会照犯 —— 这是训练的「副作用」。

例
网上大量 Word 代码用 WidthType.PERCENTAGE 设表格宽度，模型照学 —— 实际导出宽度全错。
4

缺质量标准与规范

不知道什么算「好」、输入输出该长什么样 —— 没有契约，结果就飘。

例
同样让写「分析报告」，模型有时给 3 段、有时给 3000 字，结构每次都不一样。
5

不知该用什么工具

同一个任务有多条技术路径，模型不知道哪条是团队认可的最佳实践。

例
查数据该写 SQL 还是调 API？模型可能选了最差的一条 —— 而团队明明有规定。
6

缺样例参考

没有「正确长这样」的范本，模型只能凭概率猜，每次输出形态都不一致。

例
让出一份「投标评分表」，模型从没见过标准范本，只能拼凑 —— 给个样例质量立刻不同。
P13 · Skill 如何逐一解决【重点】

用确定性的规则，覆盖概率性的推断

Skill 不是教模型新知识 —— 是把模型「凭概率猜」的地方，换成「按规则做」。
六大缺陷Skill 的解法
① 知识时效性断层→ references/ 随时更新 —— 知识与模型解耦，改文档不用改模型。 库升级到 v3，只改 references/api.md，AI 立刻按新版写。
② 私有知识不可获取→ SKILL.md 编码私有流程、方法论、业务标准 —— 把没见过的写进来。 把「单方成本=不含税÷可售面积」直接写进 SKILL.md，AI 不再猜。
③ 会踩坑→ 用确定性规则明确「永远这样、永远别那样」—— 排除训练数据的干扰。 docx Skill 写死「Always DXA, never PERCENTAGE」，覆盖错误倾向。
④ 缺质量标准→ 精确定义输入输出规范与验收口径 —— 给模型一份契约。 规定报告必须六段式、每段结论前置 —— 每次产出结构一致。
⑤ 不知用什么工具→ scripts/ 把最佳技术路径编码成脚本 —— 不留选择空间。 查数固定调 query.py，AI 不用纠结写 SQL 还是调 API。
⑥ 缺样例参考→ 正文 / references 内置范本 —— 相当于一份「永久 Few-shot」。 references 里放一份标准评分表样例，AI 每次照着出。
六大缺陷一个统一视角：凡是模型「靠概率猜不准」的地方，Skill 就用「确定性」把它钉死。
P14 · 案例解析一【重点】

Anthropic 自带通用 Skill：docx / xlsx

官方 Skill 直接验证了理论 —— 它们写的不是「知识」，是给模型排错的硬规则。
docx Skill 正文里的真实规则
Always use WidthType.DXA, never PERCENTAGE
模型常因训练数据混入而用 PERCENTAGE，生成的表格在 Word 里宽度错乱。
Never use unicode bullets（•、▪）
—— 用 Word 原生列表样式
直接打 unicode 符号看似「能用」，实际不是真列表，导不出大纲、改不动层级。
xlsx Skill：公式必须用引擎重算，
不要手填计算结果
模型爱直接把算好的数填进单元格 —— 数据一变，整张表就错。

对应缺陷 ③ 会踩坑

这些规则不增加任何「能力」—— 它们存在的唯一目的，就是抵消训练数据里的错误倾向。

为什么是「给 AI 用」的证据

这些话人类开发者根本不需要 —— 人不会犯 WidthType 这种错。它只对 AI 有意义。

P15 · 案例解析二【重点】

真实业务 Skill：成本问数

把成本经理的专业判断、口径校验、归因框架 —— 显性化成一套可执行规则。
5 步执行主线 —— 理解诉求 → 口径校验 → 取数 → 五差归因 → 结论
把成本经理「怎么想这道题」的隐性流程，写成模型每次都走的固定路径。
例 · 用户问「A 项目土建为什么超了」
AI 不直接答 —— 先按主线走：确认是哪个口径的「土建」→ 取目标 vs 实际 → 拆五差 → 才下结论。
口径校验 —— 含税 / 不含税、单方口径、统计范围逐项确认
同一个「金额」可以有好几种口径，不校验，答出来的数就没法用。
例 · 同一个「单方成本」
含税 ¥4,800 / 不含税 ¥4,250；按建筑面积还是可售面积，结果差一截 —— Skill 强制先问清再算。
五差归因框架 + 深挖决策表
差异从哪来、下一步往哪查 —— 给模型一张「按业务路径继续追问」的表。
例 · 超支 200 万怎么拆
五差：量差 / 价差 / 标准差 / 范围差 / 其他。查表 → 发现是「标准差」（精装标准提高）→ 继续下钻该科目。

逐条对照六大缺陷

  • 私有知识 —— 成本口径、归因框架进 SKILL.md
  • 质量标准 —— 口径校验就是输出规范
  • 样例 —— 决策表内置「该怎么追问」的范本

一句话

Skill 把一位资深成本经理的脑子，沉淀成了文件 —— 换谁来问，AI 都按同一套专业方法答。

P16 · 实战 A 现场实战

现场手搓 sql-query-api Skill

理论讲完，现场做一个真的 —— 用售楼数据 API，手搓一个数据查询 Skill。
准备工作（提前做好，现场不演示）：FastAPI + 售楼宽表 → 交易台账查询 API
用户提问
"查海伦广场
已审核合同"
→
Skill
理解意图
抽取参数
→
脚本 query.py
拼 HTTP 请求
→
FastAPI
5 个固化端点
→
数据库
售楼宽表
（mock 兜底）
STEP 01
写 SKILL.md
YAML description 写清触发条件与触发词；正文列 5 个端点、参数、调用流程，强调「API 模式 = 能查什么由端点固化」。
STEP 02
写调 API 的脚本
scripts/query.py 纯标准库胶水脚本：health / tables / contracts / orders / rooms 五个子命令，用 urllib 发 GET。
STEP 03
触发测试
先 query.py tables 自测脚本，再用自然语言「查一下…」验证 Skill 能被自动触发。
Skill 不连数据库、不写 SQL —— 它只做一件事：把人话翻译成对 API 的正确调用。卡壳就切预制副本。
P17 · 实战 A 现场实战

现场跑一个数据查询

一句中文问题进去 —— Skill 当「胶水」，把它转成对 API 的正确调用，拿回真实台账。
用户 查一下海伦广场已审核的合同台账
Claude · 命中 sql-query-api Skill 识别意图：合同台账查询，项目=海伦广场，审核状态=已审核 $ python3 scripts/query.py contracts \
  --project 海伦广场 --audit 已审核 已拿到结果，为你整理 ↓
用户 · 追问 那帮我按置业顾问统计每人的成交套数
Claude 当前 API 没有这个端点 —— 查不了。想加这个维度，得回头改 API、加端点、重启服务。
GET /sales/contracts · 命中 1 条
合同编号HT-2026-0312
项目 / 楼栋海伦广场 / 1栋
审核状态已审核
签约金额¥ 1,286,000
数据来源 sourcemock
⚠ 当前数据库未连通，以上为内置示例数据，非真实生产数据（API 自动降级，链路不受影响）。
追问那一下，正好暴露了 API 模式的取舍 —— 这个伏笔留到 P19。
P18 · 理论 Callback

刚才这个 Skill，印证了前面的理论

把实战 A 的产物拉回来，对照 P10–P13 的理论点 —— 逐条打钩。
✓
固化了工具调用？
query.py 把「子命令 + 参数」映射成「API 端点 + query string」—— 调用方式被钉死。对应 P10-①
✓
固化了业务 SOP？
SKILL.md 写死调用流程：理解需求 → 抽参数 → 调脚本 → 整理回答。对应 P10-②
✓
消除了「业务转技术」偏差？
「海伦广场已审核合同」→ 精确的端点 + 参数，不靠模型每次猜。对应 P10-③ / P13-④
✓
沉淀成可复用资产？
description 决定能否触发，正文是契约，脚本是最佳路径 —— 三级结构齐全。对应 P10-④ / P11
一个不到百行的 Skill，把业务经验、工具调用、输出契约全固化了 —— 这就是「Skill 是给 AI 用的可复用资产」。
P19 · 留个伏笔

但 API 是相对固化的

实战 A 跑得很顺 —— 但那句追问，已经暴露了 API 模式的天花板。
用户问：「为什么海伦广场这个月销售没达成？」
✗ API 没有「销售达成归因」这个端点 —— 这是个分析型问题，不是简单查询。

API 模式的局限

  • · 端点固定 —— 能查什么，上线那天就定死了
  • · 组合能力弱 —— 多维度交叉、下钻归因做不了
  • · 新需求 = 改代码 —— 加端点、重启、重新发布

下一章要解决的

  • · 让 AI 能现场「拼」查询，而不是调死端点
  • · 用 CLI 让 AI 不乱动手
  • · 用 本体 让 AI 不乱理解业务
要让 AI 真正具备分析能力，光有 Skill + API 不够 —— 下一章：CLI 指令系统 + 本体。