customer-support 插件：工单分诊、多源研究、回复起草、升级打包、知识库写作——5 个命令 · 5 个技能 · 连接器以支持平台为核心。本篇是对 Anthropic 官方插件的中文转译与编目。
一句话定位
把「接票→查清→回复→升级→沉淀」这条支持流水线变成五个命令，每一环都有结构化模板；解决过的票自动变成知识库文章，让同一类票不再来。
命令表
| 命令 | 干什么 |
|---|---|
/triage | 分诊：分类、定级（P1-P4）、路由建议 + 建议的首回话术 |
/research | 多源研究：综合知识库/工单史/账户信息回答客户问题，带置信度评分 |
/draft-response | 起草客户回复：按情境、紧急度、渠道定制语气 |
/escalate | 升级打包：完整上下文+复现步骤+业务影响，递给工程/产品/管理层 |
/kb-article | 把已解决的事故写成知识库文章 |
技能地图（5 技能 = 支持五环）
ticket-triage—— 分类法（Bug/功能请求/账户/账务/如何做/性能）、P1-P4 优先级框架（影响面 × 客户等级 × 核心功能受损度）、路由规则、重复票检测customer-research—— 多源研究方法论：信源优先级（产品文档>内部运行手册>工单史>社区）与答案综合，给置信度而不是硬编response-drafting—— 沟通最佳实践：承认-解释-解决-时限四段式、分场景模板、坏消息的语气纪律customer-escalation—— 升级三级（工程/产品/领导层）、结构化升级简报格式（ESCALATION: 一行摘要+ 影响 + 描述 + 已试过什么 + 复现步骤 + 客户沟通现状）、跟进节奏knowledge-management—— 文章结构标准（症状-原因-解决-预防）、为可搜索性写作、复审节奏与维护
方法论精华
1. P1-P4 定级是乘法不是排序：核心功能受损 × 企业客户 = P1；小功能问题 × 免费用户 = P4。定级规则写死在框架里，不靠当班人手感。
2. 升级简报的「已试过什么」节——多数升级烂在工程师重复排查支持已查过的东西。简报强制包含已尝试项，一分钟省下工程师一小时。
3. 票的终局不是关闭，是沉淀：每解决一张不常见的票，/kb-article 转成「症状→原因→解决→预防」四段文章进知识库——支持团队的复利来自这里。
连接器地图
| 类别 | 预置 | 可替换 |
|---|---|---|
| 支持平台 | Intercom | Zendesk、Freshdesk、HubSpot Service Hub |
| CRM | HubSpot | Salesforce、Pipedrive |
| 知识库 | Guru、Notion | Confluence、Help Scout |
| 项目跟踪 | Jira/Confluence | Linear、Asana |
| 聊天 | Slack | Teams |
| 邮件/云存储 | Microsoft 365 | — |
编者注
五技能是完整闭环里最「自洽」的一个域——分诊的输出就是研究的输入，研究的输出就是回复的素材，回复不了就升级，升完级沉淀成 KB。对任何做 toC/toB 产品的人，这套流程图本身值得画在墙上。