Anthropic Agent Skills 体系详解：理念、规范、技术实现，以及大型企业级 Skill 体系背后的顶层设计。
海内外主流厂商持续推出智能体产品与平台能力，企业"有没有平台"的问题，已经被市场解决了。
平台搭好了，但智能体里装什么？大多数企业的回答是：不知道。能力与业务不匹配、经验散落、重复建设严重。
行业共识形成——不是建不建平台，而是怎么挖掘能力、封装 Skill、形成可复用的 AI 资产。
企业级 Skill 体系的建设锚点，必须是业务流程，
而非人或岗位。
流程是组织解决问题的最佳实践沉淀。基于流程拆解原子能力、构建 Skill、再以岗位 Model 聚合分发——这是唯一能保证 Skill 资产完整性、可复用性和持续演进性的路径。
理念、规范与技术实现 —— 从 SKILL.md 文件到三级渐进式披露，从描述黄金法则到 Anthropic 18 个官方 Skill 的开源实践。
Skill 不会一次性全部加载。Claude 仅凭元数据决定要不要打开它——所以你可以装数百个 Skill，而上下文窗口不会被撑爆。
name + description · 约 100 字 · 始终在上下文中。Claude 仅凭它判断是否激活。
判断相关时才加载 · 控制在 5000 字以内 · 包含工作流、规则与示例。
scripts/ · references/ · assets/ ——按需读取，规模不受限。
--- name: flow-diagnostic-report version: 1.0.0 description: > 用华为流程方法论 + APQC PCF + 5Why/鱼骨图， 把会议讨论、用户口述、业务现象，固化成 标准化诊断报告，输出单文件 HTML。 USE WHEN 用户说"做个流程诊断"、 "梳理流程问题"、"业务诊断报告"、 "做成 HTML 报告"。 --- # 流程诊断报告生成器 ## 这个 skill 在做什么 按九步法走完：看目录 → 看清病灶 → 看完链路 → 做完归因 → 对照同行 → 量化差距 → 下诊断 → 画前后 → 再出方案。
flow-diagnostic-report/ ├── SKILL.md # 入口：方法论、流程、规范 ├── README.md # 人读的使用说明 ├── examples/ │ └── sample-report.html # 标杆样例输出 └── templates/ ├── report-skeleton.html # HTML 骨架 ├── methodology.md # 华为流程方法论 ├── checklist.md # 完成度自检 └── example-input.md # 输入样例
描述被注入系统提示词，人称错误会导致发现失败。
✗ 我可以帮你处理…
✓ 处理 Excel 并生成报告
每个描述必须回答：
① 它做什么？（能力声明）
② 什么时候用？（触发条件）
显式列出触发场景，覆盖隐式意图。
USE WHEN 用户问"我知道什么"、"查找笔记"、"加载项目上下文"…
从"帮助处理文档"（20%）→"分析 Excel 创建透视表 USE WHEN .xlsx 文件"（90%）。具体场景 + 示例 = 激活率跃升。
| 方法 | 成功率 | 关键特征 |
|---|---|---|
| 无优化 | ~20% | 基线 / 默认行为 |
| 简单描述 | ~20% | 模糊的触发语言 |
| 优化描述 | ~50% | 明确的 USE WHEN 模式 |
| 添加示例 | 70% – 90% | 具体场景 + 示例 + Pushy 写法 |
关键洞察 ▸ Anthropic 官方建议描述要"pushy"——主动列出所有可能的触发场景，包括用户不会明确说出的隐式意图。Claude 倾向于"under-trigger"，需要描述把它"推"过去。
仅 Markdown 指令，无脚本。
▸ 品牌指南 / 编码规范 / 审查清单 / 写作风格强制
SKILL.md 定义"何时/为什么"，scripts/ 处理"如何"。
▸ 数据转换 / PDF·Excel·图像处理 / 模板文档生成
在 Skill 工作流中调用外部服务或独立子任务。
▸ 创建 Issue → 查 DB → 发 Slack 这类跨系统工作流
类比 ▸ MCP 是厨房（刀具锅具食材），Skill 是菜谱（告诉你怎么用），Subagent 是分厨（独立隔间各做各的）。
| 能力 | 作用 | 示例 |
|---|---|---|
| Skill | 教 Claude 如何行为——分析工作流、编码标准、品牌指南 | 合同审查规范、代码审查清单 |
| MCP 服务器 | 给 Claude 新工具——发送 Slack、查询数据库 | Slack MCP、PostgreSQL MCP |
| Subagent | 让 Claude 在独立上下文中跑独立工作 | 并行处理多文件、隔离测试环境 |
关键洞察 ▸ Skill 解决"怎么做"，MCP 解决"用什么做"，Subagent 解决"在哪里做"。三者可组合，但很多场景仅 Skill 就足够启动。
algorithmic-art
canvas-design
theme-factory
slack-gif-creator
frontend-design
web-artifacts-builder
webapp-testing
mcp-builder · claude-api
brand-guidelines
internal-comms
doc-coauthoring
docx · pdf · pptx · xlsx
标注为 source-available——直接支撑 Claude 商业产品功能。
四种模式 ▸ Create · Eval · Improve · Benchmark。每个测试用例同时跑"有 Skill"和"无 Skill"两个版本，量化 Skill 的实际价值。
两个能跑、能改、能复用的样本——把"什么是好 Skill"翻译成可触摸的代码、目录与产出物。
核心隐喻 ▸ 业务流程是一个病人，这份报告是体检 + 病理分析 + 治疗方案——这一句话决定了整个 skill 的产出形态。
| 章节 | 方法论锦点 | 来源 |
|---|---|---|
| 1 目录 | 信息架构 IA | 工程实践 |
| 2 核心矛盾 | MECE + 一句话定调 | 麦肯锡 |
| 3-5 流程还原 | L1-L5 流程分级 + AS-IS | 华为 IPD/LTC |
| 6 深度归因 | 5Why + 鱼骨图 + R 编号 | 丰田 / 石川馨 |
| 7 行业对标 | APQC PCF + 标杆调研 | APQC |
| 8 能力差距 | Gap Analysis + 风险等级 | IBM BPA |
| 9-10 方案 | AS-IS / TO-BE + 分阶段 Wave | 华为变革 |
SKILL.md 是否存在、frontmatter 是否合法、name 与 description 是否符合长度与字符规则。
10 条正例 + 5 条反例实测命中率，验证 description 能否被真实问法激活，且不误召回。
工作流是否可执行、案例是否真实、产出格式是否锁死、硬规则是否完整。
版本号、更新日期、reference / examples 子文件齐全度、目录结构是否符合标准。
评级 ▸ 优秀 ≥ 85 ｜ 合格 70–84 ｜ 需改进 50–69 ｜ 不合格 < 50
支持目录 / .md / .zip / 粘贴原文四种入口。找不到 SKILL.md 直接报错退出——这是规范维度的硬伤。
提取 YAML 字段并校验 name 长度、description 是否第三人称、是否含触发词列表。
按 rubric.md 4 维度过条款。不允许只打分不说理由——每条扣分必须附原文证据。
构造 10 正例 + 5 反例，给出"正例命中 / 10、反例误触发 / 5"两个具体数字。
严格按模板输出：评分概览表 + 触发实测 + P0/P1/P2 整改清单 + 关键片段参考。
description / frontmatter 有问题时，给出可直接复制替换的完整片段，闭环到下一轮迭代。
# Skill 评测报告：<skill-name> 总分：XX / 100 ｜ 等级：优秀/合格/需改进/不合格 ## 评分概览 | 维度 | 得分 | 判定 | |---|---|---| | ① 规范 | XX/25 | … | | ② 触发 | XX/25 | … | | ③ 内容 | XX/25 | … | | ④ 可维护 | XX/25 | … | ## 触发实测 - 正例命中：X / 10 - 反例误触发：X / 5 ## 整改清单 ### P0 · 不修直接不合格 - [ ] <问题描述> - 位置：<文件:行> - 原文：`...` - 改成：`...` ### P1 · 影响触发或效果 ### P2 · 锦上添花
面向十万级员工、数百上架技能的真实样本——Skill 不是技术演示，是组织级运动。
赋予一线员工和团队自主创建能力，服务垂直细分场景——某个业务系统的运维 Skill、某个产品线独有的分析流程。
强化用户反馈链路（评分、问题上报、改进建议）和 Skill 作者的迭代工具，让每个 Skill 持续进化。
通过调用频次、用户反馈等多维数据持续价值评估，识别高价值 Skill 重点运营，形成度量驱动的治理循环。
技能包 ▸ 按业务线或岗位预推荐最常用的 Skill 组合，新手或跨业务协作的同事可以一键启用，无需逐个挑选。
从防腐层理念到完整落地路径——为什么 Skill 是未来组织 AI 资产的核心组成部分。
这是一个典型的"公地悲剧"。每个团队都在为自己的业务场景沉淀 Skill，但没有人在为整个组织的 Skill 资产体系负责。
A 团队做了"邮件摘要"，B 团队不知道也做了一个，C 团队还准备做第三个。
同一件事——法务一部叫"合同风险检查"，二部叫"条款风险识别"，知产组叫"协议安全扫描"。
有的经过严格评测，有的从未验证就上线。有的有完整业务规则，有的只是几轮 prompt 调试。
没人知道组织内已有什么、自己做的是否重复。每个人都在造轮子，没人在建工厂。
让业务能力与变化解耦——这是 Skill 作为资产被管理的根本理由。
人会离职、转岗、遗忘，但 Skill 把最佳实践固化下来，不随人员流动而流失。
部门会合并、拆分、重组，但 Skill 作为原子能力，不随组织调整而失效。
今天 Coze、明天 Dify、后天自研——Skill 作为标准化能力描述，不随平台迁移而重写。
底层模型从 GPT-4 升到 GPT-5、Claude 3 升到 Claude 4，但 Skill 中封装的业务规则（如"金额>100万标记高风险"）不需要改变。
业务流程是建设锚点，渐进式披露是设计原则，评估驱动是质量保证，防腐层是治理目标。Skill 的价值，在于让组织的最佳实践穿越人事、组织、平台、模型的所有变化。
— END · 谢谢观看 / Thank you —