关于 support-escalation-engineering-review
此技能将支持升级整理为工程协作方案，涵盖分流、责任归属、客户更新和结案标准，适用于协调可复现问题与客户解决方案的支持和工程团队。
主要功能
- 01升级分类与严重程度
- 02受理与复现要求
- 03分流节奏与责任归属
- 04临时方案与客户更新规则
- 05结案依据与待办反馈
适用场景
- 01设计支持到工程的分流流程
- 02制定问题复现标准
- 03改进调查期间的客户更新
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/support-escalation-engineering-review确认已加载。
附带文件agents/openai.yamlreferences/support-escalation-engineering-patterns.md
详细介绍
支持升级工程评审
使用此技能，将支持升级、工程分诊、缺陷受理、复现、解决方法、SLA 和客户更新相关问题转化为具体产物，其中包含负责人、关卡、指标和恢复路径。
工作流
- 确定支持渠道、问题分类、严重性规则、客户细分、复现材料、日志/跟踪记录、负责团队、当前队列、SLA 承诺和客户沟通缺口。
- 阅读
references/support-escalation-engineering-patterns.md。 - 将升级分类为使用方法、已知问题、缺陷、事件、数据修复、账单更正、安全/隐私、功能请求、产品缺口或工程调查。
- 定义受理要求、严重性、责任归属、分诊频率、复现标准、解决方法政策、客户更新频率、关闭证明和待办反馈闭环。
- 生成升级运营模型、状态机、决策表、事件架构、分诊检查清单，以及支持/工程 RACI。
不适用场景
- 对于基础模型无需此技能的特定产物规范即可处理的一般性建议，请勿使用。
防护措施
- 若工单缺少客户影响、复现细节、环境、日志以及预期/实际行为（条件允许时），请勿升级模糊工单。
- 请勿将事件、安全/隐私问题或数据丢失案例混入普通缺陷队列。
- 除非支持团队可见的解决方案、解决方法或客户沟通已就绪，否则请勿关闭工程升级事项。
- 不要让支持团队成为产品缺陷的唯一记录渠道；应将反复出现的问题纳入产品和质量体系。
输出格式
Escalation context:
Audience / source of truth / risk boundary:
Support-engineering plan:
| Area | Decision | Evidence | Risk | Owner |
| --- | --- | --- | --- | --- |
Severity, ownership, workarounds, and closure proof:
- <trigger> -> <policy, metric, edge case, support note>
评论
支持 Markdown