返回入口下一个

客服工单分诊 Skill

A/B 盲测评审。记录完判断前,不要打开答案钥匙。

场景

一个 B2B SaaS 团队每天都要处理客户工单:判断分类、紧急程度、起草首轮回复,并把账务、安全、故障类问题升级给对应负责人。他们希望把这个重复流程做成一个给支持团队使用的 Codex skill。

用户请求

请把我们反复使用的客服工单分诊流程做成一个团队可复用的 skill。输入包括原始工单文本、客户等级、产品模块和近期故障记录。输出需要包含问题分类、紧急程度、首轮回复草稿、升级负责人和判断依据。不要把 PII 泄露到报告里。

评审标准

  1. 是否有清楚的触发边界和近邻排除。
  2. 是否是可复用的 skill 包结构,而不只是一个提示词。
  3. 是否定义了分类、紧急程度、回复、升级和证据的输出契约。
  4. 是否处理 PII 和客户内容的隐私风险。
  5. 是否有能发现错误升级和泛泛回复的评测方案。

方案 A

来源已隐藏

建议 Skill:support-triage

目的

创建一个简洁的 skill,帮助 Codex 对 B2B SaaS 客服工单进行分诊,并起草首轮回复。

建议包结构

support-triage/
  SKILL.md
  agents/openai.yaml
  references/
    triage-taxonomy.md
    escalation-policy.md

SKILL.md 草稿

---
name: support-triage
description: 对 B2B SaaS 客服工单进行分诊并起草首轮回复。当用户提供原始工单文本、客户等级、产品模块、故障记录,或需要紧急程度、分类、升级建议时使用。
---

# 客服工单分诊

使用这个 skill 对入站工单分类、起草合适的首轮回复,并识别是否需要升级。

## 工作流
1. 阅读工单文本、客户等级、产品模块和近期故障记录。
2. 将工单归为一个主分类:账务、访问权限、缺陷、故障、功能请求、安全、数据/隐私、上手问题或其他。
3. 标记紧急程度:低、普通、高、严重。
4. 起草首轮回复:确认问题、只询问必要补充信息,并避免没有依据的承诺。
5. 对安全、隐私、严重故障、数据丢失或企业客户影响问题进行升级。
6. 汇报判断依据,但不要复制不必要的 PII。

## 输出格式
- 分类:
- 紧急程度:
- 首轮回复:
- 升级负责人:
- 判断依据:
- 缺失信息:

## 参考资料
- 分类规则见 `references/triage-taxonomy.md`。
- 升级标准见 `references/escalation-policy.md`。

agents/openai.yaml

display_name: 客服工单分诊
short_description: 对客服工单分类,并起草首轮回复。
default_prompt: 请分诊这个客服工单,并起草首轮回复。

资源

  • `references/triage-taxonomy.md`:分类定义、紧急程度提示和示例。
  • `references/escalation-policy.md`:升级负责人和升级标准。

验证

用账务、安全、故障和功能请求等代表性工单测试。确认输出会最小化 PII,并且严重问题会被升级。

方案 B

来源已隐藏

Skill 包建议:support-triage

边界

负责重复出现的客服工单分诊:用户提供工单文本以及客户/产品上下文,需要结构化路由决策。不要用于一次性文案润色、泛泛的客服同理心训练、CRM 配置,或超出升级范围的法律/安全事件处置。

输出契约

这个 skill 必须返回:

  • `category`
  • `urgency`
  • `first_response_draft`
  • `escalation_owner`
  • `evidence_used`
  • `missing_information`
  • `pii_handling_note`

包结构

support-triage/
  SKILL.md
  agents/interface.yaml
  references/
    triage-taxonomy.md
    escalation-policy.md
    privacy-redaction.md
  evals/
    trigger_cases.json
    output/
      cases.jsonl
      fixtures/
  reports/
    output-risk-profile.md
    output_quality_scorecard.md

SKILL.md

---
name: support-triage
description: 将重复出现的 B2B SaaS 客服工单分诊为分类、紧急程度、首轮回复、升级负责人、判断依据和缺失信息。当输入包含原始工单、客户等级、产品模块、故障记录或支持队列上下文时使用。不要用于一次性文案润色、CRM 设置、法律建议或最终安全事件处置。
---

# 客服工单分诊

## 工作流
1. 确认这是重复的工单分诊任务,而不是一次性文案润色。
2. 阅读工单文本、客户等级、产品模块和故障记录。
3. 使用 `references/triage-taxonomy.md` 判断分类和紧急程度。
4. 按 `references/escalation-policy.md` 检查升级标准。
5. 起草首轮回复:确认问题、避免无依据承诺,只请求最少的缺失信息。
6. 按 `references/privacy-redaction.md` 对 PII 做脱敏或摘要。
7. 严格按输出契约返回。

## 必填输出
使用这些字段:
- category
- urgency
- first_response_draft
- escalation_owner
- evidence_used
- missing_information
- pii_handling_note

agents/interface.yaml

display_name: 客服工单分诊
short_description: 对工单分类、起草首轮回复,并给出升级依据。
default_prompt: 请用分类、紧急程度、回复、升级负责人和依据来分诊这个客服工单。

评测用例

1. 企业客户在已知故障期间提交工单:必须标为 `critical`,并升级给 incident commander。

2. SMB 客户的账务困惑:不应过度升级。

3. 带客户邮箱和 token 片段的安全披露:必须脱敏 token,并升级安全团队。

4. 伪装成投诉的功能请求:应归类为功能请求,紧急程度为普通。

5. 近邻请求:“把这段回复改得更温和”不应触发包级分诊。

发布门禁

  • 触发评测:正例、反例、近邻文案润色。
  • 输出评测:首轮回复不能编造 SLA,升级必须匹配策略。
  • 隐私检查:报告不能保存原始工单 PII。
  • 审查备注:如果分类规则或升级负责人未提供,标记为 `missing evidence`,不要编造。

下一步

加入 3 个匿名工单 fixture,运行输出评测,并记录错误升级、泛泛回复和 PII 泄露的失败分类。

你的判断

只根据评审标准和页面里可见的两个输出做判断。选择会保存到当前浏览器的本地存储里,也可以回到入口页导出。