findscripter 何时使用
- 新的支持工单、客户消息或问题描述进来，需要：归类、定优先级、判断负责团队、判重（是否重复或已知问题）后再路由。
- 需要在路由前产出一份结构化分诊评估，并附一段可直接发出的初步回复草稿。
不该用的边界：
- 已确定归属、只需撰写完整客服回复正文 -> 用对应的回复撰写技能，本技能只产出首响草稿。
- 需要正式升级（打包上报、拉相关方）-> 转交升级类技能（如 customer-escalation），本技能只标注升级触发条件。
- 与单条工单无关的批量数据分析、报表统计，不在本技能范围。
步骤
1. 解析问题
从输入中抽取：核心问题（客户实际遭遇什么）、症状（具体行为/报错）、客户上下文（账号、套餐、历史）、紧急信号（是否阻塞、是否生产环境、影响人数）、情绪状态（受挫/困惑/平静/正在升级）。
2. 归类与定级
- 用下方分类法定一个主分类，必要时加一个次分类。
- 用下方优先级框架定 P1-P4。
- 标出对应的产品域/团队。
3. 判重与已知问题
路由前检查可用数据源：
- 支持平台：搜相似的未结/近期已解决工单。
- 知识库：查已知问题或现有文档。
- 项目跟踪器：查是否已有缺陷单或需求单。
按下方「判重流程」处理。
4. 确定路由
按下方路由规则，依据分类与复杂度建议由哪个团队/队列接手。
5. 产出分诊结果
按固定模板输出（见下方示例）。
6. 给出下一步
呈现分诊后主动追问：是否要起草完整回复？是否要再搜更多上下文？是否要在跟踪器里查这是不是已知 bug？是否要升级（可用 /customer-escalation 打包）？
指令
分类法（主分类，可选次分类）
| 分类 | 说明 | 信号词 |
|---|---|---|
| Bug 缺陷 | 产品行为异常/不符预期 | 报错、坏了、崩溃、不工作、异常、错误、失败 |
| How-to 用法 | 客户需要使用指引 | 怎么做、能不能、在哪里、如何设置、配置、求助 |
| Feature request 需求 | 想要尚不存在的能力 | 要是能…就好、希望可以、有没有计划、申请 |
| Billing 账单 | 支付/订阅/发票/定价 | 扣费、发票、付款、订阅、退款、升级、降级 |
| Account 账户 | 访问/权限/设置/用户管理 | 登录、密码、权限、SSO、被锁、登不上 |
| Integration 集成 | 第三方/API 对接 | API、webhook、集成、连接、OAuth、同步、第三方 |
| Security 安全 | 安全/数据访问/合规 | 数据泄露、未授权、合规、GDPR、SOC 2、漏洞 |
| Data 数据 | 数据质量/迁移/导入导出 | 数据丢失、导出、导入、迁移、数据错误、重复 |
| Performance 性能 | 速度/可靠性/可用性 | 慢、超时、延迟、宕机、不可用、降级 |
判定要点：同时有 bug 和需求时，bug 为主分类；因 bug 导致登不上，归 Bug 而非 Account（按根因归类）；「以前能用现在不行」= Bug；「想换种方式工作」= Feature request；「怎么才能用」= How-to；拿不准时偏向 Bug（宁可排查也别误判）。
优先级框架
- P1 危急：生产宕机、数据丢失/损坏、安全事件、全部或多数用户受影响。SLA：1 小时内响应，持续处理直至解决/缓解，每 1-2 小时更新。
- P2 高：核心功能损坏、关键流程受阻、多用户受影响、无变通方案。SLA：4 小时内响应，当天积极排查，每 4 小时更新。
- P3 中：功能部分损坏但有变通方案、单用户或小团队受影响。SLA：1 个工作日内响应，3 个工作日内解决/更新。
- P4 低：轻微不便、外观问题、一般咨询、需求建议。SLA：2 个工作日内响应，正常节奏解决。
优先级自动上调触发器：等待已超 SLA；多客户报同一问题（出现模式）；客户明确升级或提及高管介入；原有变通方案失效；问题范围扩大（更多用户/数据/新症状）。
路由规则
| 路由至 | 何时 |
|---|---|
| 一线支持 Tier 1 | How-to、有文档解法的已知问题、账单咨询、重置密码 |
| 二线支持 Tier 2 | 需排查的 bug、复杂配置、集成排障、账户问题 |
| 工程 Engineering | 已确认需改代码的 bug、基础设施问题、性能劣化 |
| 产品 Product | 需求量大的功能请求、设计决策、流程缺口 |
| 安全 Security | 数据访问顾虑、漏洞报告、合规问题 |
| 账单/财务 | 退款、合同争议、复杂账单调整 |
判重流程
- 按症状搜：相似报错/描述。2. 按客户搜：该客户是否已有同问题工单。3. 按产品域搜：同功能区近期工单。4. 对比已知问题文档。
命中重复时：把新单关联到既有单；告知客户这是正在跟踪的已知问题；把新报告中的新信息补进既有单；若新报告增加紧急度（更多客户受影响等）则上调优先级。
示例
输入：客户反映今早起仪表盘一直白屏
输出模板：
## 分诊：[一句话问题概述]
分类：[主] / [次（若有）]
优先级：[P1-P4] — [简要依据]
产品域：[区域/团队]
### 问题概述
[2-3 句话描述客户遭遇]
### 关键细节
- 客户：[姓名/账号（若知）]
- 影响：[谁、什么受影响]
- 变通方案：[有 / 无 / 未知]
- 相关工单：[相似问题链接（若找到）]
- 已知问题：[是—链接 / 否 / 排查中]
### 路由建议
路由至：[团队或队列]
理由：[简要说明]
### 建议初步回复
[首响草稿：确认问题、设定预期、若有变通方案则给出。
可用下方各分类自动回复模板作为起点。]
### 内部备注
- [接手者所需的额外上下文]
- [若为 bug 的复现线索]
- [需留意的升级触发条件]
各分类首响模板（要点）：
- Bug：感谢上报 + 共情具体影响 + 已按[优先级]登记并在排查 +（有则给变通）+ [SLA 时限]内更新。
- How-to：直接给答案/文档链接，复杂则分步引导，结尾邀请追问。
- 需求：感谢建议 + 认可价值 + 已记录并同步产品团队（不承诺具体时间）+（有则给替代方案）。
- 账单：表示会优先处理 + 简单则直接给结论，复杂则说明正在核对、[时限]内答复。
- 安全：感谢上报 + 已立即升级安全团队 + [时限]内反馈 +（需要则给防护措施建议）。
注意事项
- 先读完整张工单再归类——后续消息里的上下文常改变判断。
- 按根因归类，而非仅看表面症状。
- 优先级拿不准时往高了定——降级比补救漏掉的 SLA 容易。
- 路由前务必查重与已知问题。
- 写清内部备注，让下一个人快速接上上下文。
- 注明已检查/已排除的项，避免重复排查。
- 标记模式——同一问题反复出现时升级该模式，即便单张工单优先级低。
互见
- 升级处理：/customer-escalation（把工单打包上报）。
- 完整回复撰写、知识库检索等后续技能（按本仓库同域条目）。
采编自 anthropics/knowledge-work-plugins（customer-support/ticket-triage），许可证 Apache-2.0。