场景
一个 B2B SaaS 团队每天都要处理客户工单:判断分类、紧急程度、起草首轮回复,并把账务、安全、故障类问题升级给对应负责人。他们希望把这个重复流程做成一个给支持团队使用的 Codex skill。
用户请求
请把我们反复使用的客服工单分诊流程做成一个团队可复用的 skill。输入包括原始工单文本、客户等级、产品模块和近期故障记录。输出需要包含问题分类、紧急程度、首轮回复草稿、升级负责人和判断依据。不要把 PII 泄露到报告里。
评审标准
- 是否有清楚的触发边界和近邻排除。
- 是否是可复用的 skill 包结构,而不只是一个提示词。
- 是否定义了分类、紧急程度、回复、升级和证据的输出契约。
- 是否处理 PII 和客户内容的隐私风险。
- 是否有能发现错误升级和泛泛回复的评测方案。
方案 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 泄露的失败分类。
你的判断
只根据评审标准和页面里可见的两个输出做判断。选择会保存到当前浏览器的本地存储里,也可以回到入口页导出。