Anthropic 前几天开源了一批 Knowledge Work Plugins，专门给 Cowork（他们的桌面 AI 工具）用。11 个插件覆盖销售、法务、金融、产品管理等领域。
我把其中的 Customer Support Plugin 拆了个底朝天。
一句话总结：整个插件没有一行代码，全靠 Markdown 和 JSON 驱动。 5 个 SKILL.md 文件，加起来 2000 多行，把客服行业十年的最佳实践塞进了 AI 能理解的格式里。
这篇文章讲三件事：它做了什么，怎么做的，有什么值得偷的。
它到底做了什么
5 个斜杠命令，覆盖客服工作的完整链条：
命令
干什么
产出物
/triage
拿到客户消息，分类、定级、推荐路由
结构化分诊卡
/research
跨多个数据源调研某个问题
带置信度评分的调研报告
/escalate
把问题打包成升级简报发给工程/产品/领导
标准化升级文档
/draft-response
根据情境和客户关系起草回复
可发送的专业回复
/kb-article
把已解决的工单转成知识库文章
可发布的 KB 文章
直觉上会以为这 5 个工具各干各的。实际上它们形成了一张网：
收到工单 → /triage → /research → /draft-response
│ │
↓ ↓
/escalate /kb-article
│
↓
/draft-response
分诊完了可以研究，研究完了可以起草回复，也可以沉淀成知识库文章。升级完了也可以起草客户更新。每个命令执行完，都会主动问你"要不要接着做下一步"——自然地把单点工具串成了工作流。
文件结构和技术栈
customer-support/
├── .claude-plugin/
│ └── plugin.json # 身份：名称、版本（v1.2.0）、描述
├── .mcp.json # 连接：9 个外部工具的 HTTP 端点
├── CONNECTORS.md # 关键设计：~~category 占位符体系
├── README.md # 文档 + 工作流示例
└── skills/
├── ticket-triage/SKILL.md
├── customer-research/SKILL.md
├── customer-escalation/SKILL.md
├── draft-response/SKILL.md
└── kb-article/SKILL.md
9 个 MCP 端点配在 .mcp.json 里：Slack、Intercom、HubSpot、Guru、Notion、Atlassian、Microsoft 365、Gmail、Google Calendar。全部是 HTTP 类型的远程连接。
有意思的是，部分端点由 SaaS 厂商托管（比如 mcp.slack.com），部分由 Anthropic 代建（比如 microsoft365.mcp.claude.com）。MCP 生态在走"厂商自建 + 平台代建"的双轨路线。
我觉得最值得偷的 7 个设计
1. ~~category 占位符——工具抽象做到了极致
SKILL.md 里写的是这样：
- **~~support platform**: 搜索类似的已开/已解决工单
- **~~knowledge base**: 检查已知问题
- **~~project tracker**: 检查现有 Bug 报告
~~support platform 可以是 Intercom，也可以是 Zendesk 或 Freshdesk。SKILL.md 完全不关心你连的是哪个工具，它只认类别。
CONNECTORS.md 列了一张映射表：
类别
占位符
默认工具
可替换为
Chat
~~chat
Slack
Teams
Support
~~support platform
Intercom
Zendesk, Freshdesk
CRM
~~CRM
HubSpot
Salesforce
Knowledge
~~knowledge base
Guru, Notion
Confluence
Tracker
~~project tracker
Atlassian
Linear, Asana
传统做法：给每个工具写一套集成。10 个工具 × 5 个 skill = 50 套逻辑。~~category 把 O(n×m) 降到了 O(n+m)。skill 写一遍，工具随便换。
偷法：你的 skill 里别写死 "Jira" "飞书"。写 "~~项目管理工具" "~~即时通信"。
2. Markdown 表格当决策引擎
整个项目用了至少 15 张表格来编码"什么时候做什么"。
分类体系是表格：
类别
信号词
路由
Bug
error, broken, crash
Tier 2 / Engineering
How-to
how do I, configure
Tier 1
Billing
charge, refund
Billing/Finance
Security
data breach, GDPR
Security（立即升级）
优先级框架是表格：
级别
条件
SLA
P1 致命
生产宕机、数据丢失、安全事件
1 小时响应
P2 高
核心功能中断、无变通方案
4 小时响应
P3 中
部分异常、有变通方案
1 工作日响应
P4 低
美观问题、功能请求
2 工作日响应
跟进节奏是表格、升级路径是表格、语气选择是表格、文章维护周期还是表格。
为什么表格好？因为 LLM 解析表格的精确度比段落高一个量级。段落有歧义，表格没有。段落需要推理，表格直接查找。
偷法：skill 里的分支逻辑，别用段落描述。写成表格，LLM 查表比理解文章准多了。
3. 五层置信度体系——教 AI "知道自己不知道什么"
customer-research 这个 skill 设计了一套信息源分级制度：
层级
来源
信心
Tier 1
官方文档、知识库
高
Tier 2
CRM、工单历史
中高
Tier 3
Slack 消息、邮件
中
Tier 4
网页搜索、社区
中低
Tier 5
推断和类比
低
每次调研产出都必须标注置信度。高置信度可以直接答复客户，低置信度必须让人工确认。
还有一条明确的分界线——什么时候自己答，什么时候移交给人：
直接答：官方文档明确，多源验证过，问的是事实，不涉及承诺。
交给人：涉及产品路线图、定价、法务合规、安全、客户定制化配置。
偷法：给你的 AI 工具设置"能力边界"。AI 知道自己不确定的时候说"我拿不准，你看下"，比它自信地给出错误答案好一百倍。
4. 反面规范——告诉 AI 不该干什么
draft-response 的写作规范有一段 DON'T 清单：
❌ 用企业黑话（synergy、leverage、paradigm shift）
❌ 往其他团队/系统/流程上甩锅
❌ 被动语态逃避责任（"Mistakes were made"）
❌ 加太多条件限定，显得没信心
❌ 感叹号过多（每封邮件最多一个）
LLM 执行正面指令的能力很强。但在"别做什么"这件事上容易滑坡。你不说"别用被动语态"，它就会用。你不说"别堆企业废话"，它就会堆。
反面规范就是刹车片。正面规范告诉 AI 踩油门往哪开，反面规范保证它不翻车。
偷法：每个 skill 除了写"做什么"，加一个 DON'T 清单。对 LLM 来说，10 条 DON'T 的价值可能比 20 条 DO 还高。
5. 固定输出模板——消灭输出的随机性
每个 skill 都定义了一个严格的输出骨架。拿分诊来说：
## Triage: [一句话摘要]
**Category:** [Primary] / [Secondary]
**Priority:** [P1-P4] — [简要理由]
**Product area:** [Area/team]
### Issue Summary
### Key Details
### Routing Recommendation
### Suggested Initial Response
### Internal Notes
AI 的输出被硬约束在这个框架里。每次分诊出来的文档长一个样。任何人拿到都能快速扫完。
对比一下"自由格式"的 AI 输出——今天给你写 3 段，明天写 10 段，后天换个结构。使用者每次都要重新"学习"如何阅读 AI 的产出。
偷法：你的 skill 产出什么格式，用 Markdown 代码块写死。别让 AI 自己决定格式。
6. 优雅降级——没工具也能干活
README 里有一句话：
Without these connections, the plugin will ask you to provide context manually and offer frameworks and templates you can fill in with your own data.
MCP 工具没接？不崩溃，不报错。退化到手动模式：请你口头提供背景信息，然后把框架和模板给你，你自己填数据。
核心设计原则：工具连得越多越好用，但不连也不瘫痪。
想想我们日常遇到的多少软件，数据库挂了整个系统就黑屏了？这个插件的设计哲学是——砍到只剩 Markdown 文本输入也能提供 80% 的价值。
偷法：设计 skill 的时候，假设所有外部依赖都挂了。核心能力应该在零上下文模式下依然能跑。
7. 知识沉淀闭环——每次干活都在攒资产
customer-research 调研完一个问题之后：
"要我把这些结论保存到你的知识库里吗？"
"要我基于这次调研创建一个 FAQ 条目吗？"
kb-article 更直接——把已解决的工单变成可搜索的自助文章。
看链条：客户提问 → 研究答案 → 解决问题 → 沉淀为文章 → 下次类似问题客户自助解决 → 工单量下降。
每一次客服交互都在积累组织的知识资产。不只是"解决了一个 ticket"，还"生产了一篇可复用的文档"。这是复利。
几个细节设计也值得看
根因归类。分诊有一条规则："客户说登不上去，但如果原因是系统 Bug，分类为 Bug 而不是 Account。根因决定分类。" 不确定的时候偏向 Bug——宁可过度调查，不可草率关闭。
语气光谱。draft-response 定义了 8 种情境语气：好消息用"庆祝"、坏消息用"坦诚"、故障用"紧急"、升级用"管理者"。还按客户关系阶段（新客户/老客户/受挫客户）做了语气微调。
知识库文章的搜索优化。有一张好标题 vs 坏标题的对比表：
✅ 好
❌ 坏
原因
"如何用 Okta 配置 SSO"
"SSO 设置"
包含客户会搜的工具名
"修复：仪表板显示空白页"
"仪表板问题"
包含客户看到的症状
"错误：'Connection refused'"
"导入问题"
包含精确错误信息
文章生命周期管理。Draft → Published → Needs Update → Archived → Retired。季度审计高流量文章，月度标记 6 个月未更新的内容，每周刷新已知问题的状态。
局限性在哪
说完优点，说不足。
没有个性化配置机制。分类体系、优先级框架、SLA 参数全部硬编码在 SKILL.md 里。想改？直接改源文件。没有 config 层。
没有质量反馈循环。分诊准不准、回复客户满不满意——没有度量指标，没有闭环。工业级部署需要这些数据来持续优化。
只有英文。模板、信号词、沟通规范全是英文的。做中文客服？所有内容需要本地化重写。
纯建议型。AI 只负责起草，不负责执行。没有自动创建工单、自动路由、自动回复的能力。人始终是最后一关。
安全合规空白。PII 处理规则？数据保留策略？审计日志？通通没有。企业用需要自己补这层。
Anthropic 在下什么棋
放远点看，这 11 个开源插件的战略意图很清晰：
第一步，用开源插件定义"AI 工作助手应该长什么样"。你看到这个客服插件觉得"哦，原来 AI 可以这样帮人做客服"——标准就被他们种下了。
第二步，Cowork 平台是运行这些插件的地方。插件免费给你，平台收费。用生态吸引用户，用平台变现。
第三步，MCP 协议。所有工具通过 MCP 连接到 Claude。今天支持 Slack、Intercom、HubSpot。明天其他 SaaS 厂商也来建 MCP 端点。协议层被 Anthropic 事实标准化了。
底层协议 + 中间平台 + 上层内容。这套飞轮和 Google 的 Android 一个味道——开源系统拉生态，Play Store 做分发，Google 服务做变现。
给自己的 Skill 体系抄什么
学什么
怎么学
~~category 抽象
用语义类别（"~~数据源"）取代硬编码的工具名
固定输出模板
每个 skill 用代码块定义输出骨架
决策用表格
分支逻辑从段落改成 Markdown 表格
DON'T 清单
每个 skill 加一段反面规范
技能间串联
"Next Steps" 环节推荐下一个可用的 skill
优雅降级
假设外部依赖全挂，核心功能仍可用
置信度标注
AI 产出需标注信心等级，低信心走人工审核
拆到这儿，最打动我的一点：Anthropic 把整套客服专家的判断力、决策直觉、沟通经验，用 Markdown 文件编码了出来。没写一行 Python，没搞一个 API endpoint，没建一个数据库。
5 个 Markdown 文件，就是一整套客服 AI 的大脑。
这可能就是 AI 原生时代做软件的方式——别写逻辑，写知识。LLM 自己会把知识变成行动。
📎 原始仓库：anthropics/knowledge-work-plugins
📎 分析版本：customer-support v1.2.0