机器人报修实操：保留多行异常记录的完整上下文

机器人报修软件弹出异常后，提交人往往只复制屏幕最后一行。技术人员收到一句错误名称，却不知道它出现在哪个程序路径、前面还有哪些相关信息。多行异常记录的整理重点，是固定原始输出并保留足够的上下文，让接手人员能够定位材料；这一步不等于已经找到机器人本体故障原因。下面以Python软件的异常输出为例说明记录方法，不展示真实客户日志。

先固定原始日志及观察范围

保留获准取得的日志文件、导出时间、系统或程序版本及相关报修事项。日志仍在持续写入时，应使用系统提供的导出方式取得可说明范围的副本，避免从正在滚动的窗口随意截取后声称记录完整。若只有截图，注明截图覆盖区域以及是否可能有上方或下方未显示的内容。

整理前确认资料权限。文件路径、用户名、请求内容和业务字段可能出现在异常输出中，对外发送时应按实际内容制作脱敏副本，并保留有权限的原件。脱敏改变了显示内容，应在副本说明中标出处理范围，不把删减后的材料标成未经处理的原始日志。

识别一个异常输出块，而不是逐行数故障

Python官方traceback文档介绍了提取、格式化和打印调用栈与异常信息的接口。一个异常输出可能包含多个调用位置以及异常名称、说明等内容。屏幕上的多行文本不能直接按行换算成多个独立故障；一条看起来简短的信息，也不能据此断定只有一个相关事件。

记录时保留可定位的行范围、时间字段及已有的请求或任务标识。若输出包含异常链，应把相关段落一起留存，再由技术人员解释它们之间的关系。不能只挑一行符合预想原因的内容，把其余段落删掉；也不要为使文本整齐而重新排列调用位置。

区分日志消息和附带的异常详情

Python logging的Logger.exception说明指出，该方法会在日志消息之外添加异常信息。整理者因此可能看到一条带时间或级别的消息，后面跟着多行异常详情。是否属于同一条日志输出，应结合实际格式、程序配置和上下文确认，不能只靠每行是否带时间戳判断。

在复查副本中，可以用另附索引标明“这里是消息行”“这里是后续异常详情”，但不要把这些整理标签写回原始文件。若多条并发任务的输出交错，保留原次序和已有标识，说明当前无法可靠归组的部分；没有证据时不强行把相邻文本拼成同一次故障。

把操作经过作为另一项材料补充

询问提交人当时正在进行什么操作、看到什么页面状态、是否发生重复尝试，将回答注明为人员陈述。日志能够说明软件记录了什么，人员陈述说明使用者记得什么，两者可以相互帮助定位，但不应合并成一段没有来源区分的事实。涉及设备状态时，应遵循现场既有报修和停机流程，不为获取更完整日志而擅自重复危险动作。

需要重现的问题，应由负责人员安排受控条件，并另行记录尝试范围与结果。本文仅讨论已取得资料的整理，不要求重新运行控制程序。若原始材料不足，应说明缺少哪个时间段、哪个程序或哪一部分输出，不用推测内容填补空白。

提交可定位的记录，保留诊断的不确定性

交接材料可包含原件位置、相关行范围、程序版本、操作陈述、脱敏说明和待解释问题。引用片段时保留与原件的对应关系，方便技术人员回到完整材料。发现新的解释后，新增诊断记录及其依据，不把原先的观察直接改写成当时已经确定的原因。

两张配图为原创AI辅助概念示意，没有真实工单、日志行或诊断结果。相关内容见机器人报修记录栏目和文章目录。保留多行异常记录的完整关系，可以让后续诊断拥有更清楚的材料起点，同时避免把日志外观或输出长度误写成实际故障数量。