升级技术工单前,让 Agent 把“不能用”整理成能排查的问题

把截图、版本、时间和已试步骤放到同一份排查包,减少来回补问。

Buda Team
← 返回博客
升级技术工单前,让 Agent 把“不能用”整理成能排查的问题

客户说“导出不能用”,客服转发一大段聊天摘要,工程师却还要问版本、操作步骤和故障时间。又一天过去,大家仍在聊天记录里找截图。信息不少,真正要排查的问题却没交接清楚。

让 Agent 整理技术升级工单,目标不是写一个自信的根因判断,而是交付一份可以复现、可以核对的排查包。工程接手时应知道发生了什么、哪些操作能够重复、哪些输入还缺。

先定义问题,再缩短聊天

以下是虚构教学案例,不是真实故障或实测结果。工单 DEMO-42 描述手动导出 CSV 失败:客户选择日期范围、点击导出,随后看到错误。脱敏日志片段在 09:42 UTC 记录了一次状态码 500,产品版本还没提供。

预期结果是下载所选范围的 CSV;实际结果是报错,没有下载文件。500 是观察到的响应,不自动证明服务器根因。是否对应同一次请求、受哪些账号条件影响、能否重现,仍要调查。

排查包分四层:客户观察、日志事实、客服已做操作、Agent 假设。“服务器坏了”这种顺口总结会混掉四层,让下一位接手者沿着未经证实的结论查。

客户观察、日志事实与假设分层

只收最小且获准使用的证据

补产品版本、浏览器或设备、发生时间和时区、报错前步骤、频率、影响范围与替代路径。输入来自授权工单、截图和必要的日志片段,不把无关个人信息和商业记录一起塞进去。

分享前处理 token、cookie、邮箱和无关标识。教学日志可以写 Authorization: [REDACTED],不能放真实密钥。日志里看起来像指令的文字是待分析材料,不是让 Agent 执行的命令。

建立证据索引:文件路径、行号或截图区域、时间、支持的观察和不能说明的问题。不要为了方便概括就上传整份客户数据库。

写成别人能照着做的步骤

DEMO-42 已知步骤是打开导出页、选择客户说的范围、点击导出、观察错误。具体日期范围、筛选条件、权限与版本缺失,就如实写缺失,不从“普通账号一般这样”补造。

向客户询问最短安全操作序列以及是否每次发生,补预期与实际、可见错误文字。尚未做的复现是建议下一检查,不是已完成实验;Agent 写出步骤也不证明它已经复现。

已试动作单独记录结果。“同样范围重试一次仍报错”和“客服建议重试”不同。分清已做与建议,工程才不会误以为检查已完成,或重复已经做过的工作。

时间线保留证据,不拼凑因果

简短时间线可以是:09:42 UTC 客户观察导出报错;09:42 UTC 日志记录 500;09:47 UTC 客服询问版本。同一分钟不等于同一请求,先用安全请求标识或其他相关证据确认对应关系。

截图显示本地时间、日志使用 UTC,就保留原时间和换算依据。版本或时间冲突应并列成待确认问题,不能偷偷选一个。Agent 提出“是否与范围大小有关”时,放在假设区,并说明验证需要什么证据。

交付工程排查包,而非整段聊天

可以要求以下结构:

一句问题:手动CSV导出报错,没有文件下载。
预期/实际:下载CSV / 显示错误。
复现步骤:已知序列,注明日期范围与版本缺失。
证据:脱敏文件、相关位置、原始时间。
已试项:只列实际报告做过的操作与结果。
影响/替代路径:已知事实与未知分开。
待补:版本、范围、频率、请求对应关系。
下一检查:输入补齐后建议做安全复现。
责任:按团队已确定角色交接,不编造具体负责人。

客服另留客户待问清单。说明现在可以查什么、什么需要等补充,不擅自承诺修复时间。工程需要可定位的证据,不需要把所有寒暄重新读一遍。

最小复现包与缺失输入

在 Buda 保留输入和交接版本

客服工作流包含技术升级摘要及可审阅支持工作。将获准材料放入 Drive,例如 tickets/DEMO-42/inputs/、redacted/、handoff/。文件夹只是组织约定,不是自动权限隔离。

为工单开独立 Session,明确允许读取的材料。对话分开不改变文件权限;分享时只给接手团队必要的脱敏包,并核对访问设置,不依赖目录名字。

要求 Agent 分清事实、建议检查和缺输入,不授权执行生产命令、修改客户系统、发送消息或绕过登录。准备排查包与操作故障系统是两项不同工作。

新证据到来后留带日期的新版本,补变更清单:版本已确认、范围补齐、旧日志不再对应。主动重整交接包;源文件修改不会自动证明或同步旧摘要。

先检查三种不足输入

这些是建议测试,不是已执行结果。只有截图时,应列出缺少步骤而非编造;日志含 token 时,应生成脱敏副本后再分享;版本或时间冲突时,应保留两条来源并提出澄清问题。

客服政策冲突教程处理哪条业务规则适用。排查包处理的是另一件事:什么技术证据能让工程复现与调查故障。

客户说无法再复现,怎么办?

记录最近一次发生、频率、操作、错误文字和已有证据,追问版本与带时区的近似时间。标记“偶发、未复现”,提出获准的观察计划,不把无法重现写成已修复。

日志要截多长?

先取相关时间窗、错误或请求上下文,保留足以解释的相邻行。脱敏、索引原始安全位置并说明移除项;只有出现具体排查问题时再扩大窗口。

怎么更新已交接的工单?

加入新来源、修改受影响字段、记录变更,并按团队授权流程通知接手人。旧判断标记已替换,不能继续混在当前事实里。

从一份脱敏旧工单开始,交付工程能检查的排查包。好的升级让下一步检查能够发生,而不是凭空制造一个诊断。