把已解决工单整理成诊断案例卡

这个场景解决什么问题

FAQ 说明通常怎样做，案例卡说明相似现象当时怎样排查、哪些方法无效、什么条件下才适合借鉴。把已解决工单的过程留下来，能减少新人遇到故障就反复问资深同事。案例里的最终原因必须有确认依据，不能由 AI 补成漂亮故事。

开始前需要准备什么

准备完整脱敏工单、操作记录、错误码和版本、处理结果及最终原因确认记录。标明实际已解决、暂时绕过、仍待观察。需要客户身份或系统权限才能做的动作单列，不能作为人人可执行步骤。

具体怎么做

第一步：确认案例资格。 让 WorkBuddy 检查结果证据，客户未回复不等于已解决；没有根因确认仍可写处理经验，但明确原因待核，不放入已确认根因库。

第二步：还原诊断链。 按表面现象、发生环境、尝试动作、验证结果、最终方案和确认依据整理。失败动作也保留，避免下一位重复做无效尝试。

第三步：划出可复用边界。 提取共同条件和排除条件。例如安卓某版本白屏案例，不能直接套用到网页支付页转圈。个案补偿、特殊权限、临时绕行写入不可复制部分。

第四步：审核与试查。 业务或技术负责人确认诊断过程后，以现象、版本、错误码等组织检索。用相似但条件不同的新问题测试，要求先核条件再推荐排查。

可以直接交给 WorkBuddy 的完整要求

根据指定完整工单、操作和结果证据，整理客服诊断案例卡。
每卡写表面现象、产品渠道环境、版本与错误码、已尝试动作及效果、最终处理、结果确认、根因状态、适用前提、排除条件、不可复制的权限或个案措施、责任确认人。
每项结论保留内部证据定位，区分已解决、暂时绕过和待观察。未确认原因不得补写；客户未回复不当解决。
给出检索标签和两条边界测试：相似且条件满足、相似但条件不同。只输出案例审核稿，不公开客户身份、不自动执行排查或发布知识。

完成后会得到什么

示例：现象：登录后白屏｜环境：安卓、指定版本｜无效动作：重登｜确认方案：技术修复后客户复测通过｜适用：同版本同入口｜排除：网页端支付页转圈｜原因：以技术确认记录为准。

结果应该怎么检查

时间线与实际操作一致；效果有证据；已确认原因和推测明确分开；失败动作不被删成一步成功；可复用条件足够具体；特殊客户措施没有变成标准流程。

遇到这些情况怎么处理

只有简短结案备注，先补过程，不强行写完整案例。处理有效但原因不明，标为经验方案并保留限制。产品升级后案例可能失效，关联复核日期或停用状态，不默认永久有效。

哪些必须人工决定

技术或业务人员确认原因与适用性，知识负责人审核入库。AI 不能把相似现象判成相同故障，更不能执行设备危险操作、越权改账号或向客户保证复用必定成功。