归并失败日志并整理定位线索

这个场景能帮你做什么

一次问题可能产生许多失败日志，重复建缺陷会分散排查。WorkBuddy 可以按环境、版本、时间和错误模式归并候选，帮助工程师优先定位。

开始前需要准备什么

提供完整相关日志、用例与运行编号、时间时区、环境、版本、已知故障和近期变更。保留上下文与关联 ID，不只给最后一句报错。

具体怎么做

第一步：统一时间与运行身份

记录每条失败对应哪次执行、哪个版本和环境。不同机器时间不同步时先标偏差，不把先后顺序当作可靠因果。

第二步：按证据归并候选

结合错误签名、调用位置、输入与上下文分组，保留每条原记录。相同报错可能不同根因，不同报错也可能同一连锁故障，分组只是排查假设。

第三步：提取关键事件

每组列首个异常、前置事件、状态变化和近期相关变更，区分直接证据与可能解释。缺调用链或数据时列下一步采集。

第四步：形成定位顺序

按影响和可验证性建议检查顺序，说明怎样证实或排除。不要按模型自报概率代替工程证据，也不自动关闭重复工单。

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

整理附件失败日志，先对齐运行ID、环境、版本、时间与时区。
按错误模式及上下文形成候选组，保留全部原记录。每组列共同点、差异、最早异常、相关变更、根因候选与验证办法。
明确哪些只是推断，列缺失日志和采集建议。不把报错相同当同根因，不删原日志、不自动合并关闭缺陷。

完成后会得到什么

一份失败分组表、事件摘要和验证顺序，工程师可从每个结论回到原始日志。

结果应该怎么检查

抽查分组边界和首个异常，检查时区、重试与级联报错。验证高影响候选，不能因为摘要流畅就接受根因。

遇到这些情况怎么处理

日志不全时保留未知。近期变更仅时间接近时不能定为原因。涉及多个服务时补关联 ID 与跨服务记录，再调整分组。

哪些必须人工决定

工程师验证根因、缺陷合并和修复顺序。AI 整理线索，不直接修生产环境或宣布问题已定位。