| name | log-analysis-correct |
| description | 用实际环境日志校正代码提取的日志表格。时序、遗漏、分支条件全部用真实日志验证,输出校正后的完整表格。触发词:校正日志、用实际日志校正、日志校正。 |
日志校正器
用实际环境日志校正代码提取的表格,解决三个问题:时序不准、遗漏日志、分支不明。
触发词
校正日志、用实际日志校正、日志校正
输入
| 输入 | 必需 | 说明 |
|---|
| 代码提取的日志表格 | 必需 | log-analysis-structurize 输出的 CSV |
| 实际环境日志 | 必需 | 真实运行的日志文件或粘贴内容 |
| 功能描述 | 必需 | 该日志属于哪个功能 |
输出
| 输出 | 格式 | 说明 |
|---|
| 校正后的日志表格 | CSV 文件 | 9列,同 structurize 格式 |
校正四步
第一步:时序校正
代码中的静态顺序可能与实际执行顺序不同。
操作:
- 在实际日志中找到每条代码日志对应的真实日志行
- 按实际日志的时序重新排列编号
- 如果实际日志的时间戳顺序与代码执行顺序不一致,以实际日志为准
判断依据:
- 实际日志有时间戳 → 按时间戳排序
- 实际日志无时间戳 → 按日志出现的上下文推断(请求 ID、trace ID 关联)
第二步:遗漏补充
实际日志中出现了但代码搜索没找到的日志。
可能原因:
- 动态拼接的日志字符串
- 宏展开后才显示的日志
- 跨仓库调用链路的日志
- 第三方库打的日志
操作:
- 扫描实际日志,找出代码表格中没有的日志行
- 补充进表格,标注
[实际日志补充]
- 填写所有 9 列(遗漏的列尽量推断,推断不出的写"待确认"
第三步:条件确认
有些代码中的日志有条件分支(如 if (ret != 0) LOG_ERROR),实际只走了其中一个分支。
操作:
- 在实际日志中确认哪些条件分支真正走到了
- 没走到的分支在表格中标注
[未触发]
- 走到过的分支更新"出现场景"为更精确的实际触发条件
第四步:去噪
同一日志在循环或高频调用中被多次打印,实际日志只保留一条。
操作:
- 识别高频重复的日志(如循环内每次迭代都打)
- 在表格中只保留一条,含义列注明"循环中重复"
- 在备注列注明:
[去噪] 实际日志中该日志在循环内重复 N 次,表格中只保留一条
校正报告模板
校正完成后,输出以下报告(放在 Markdown 文档的"关键说明"中):
## 校正报告
- **总条目数**:X 条(代码提取 Y 条 + 实际日志补充 Z 条)
- **时序调整**:X 处
- **遗漏补充**:X 条
- **条件确认**:X 条未触发分支已标注
- **去噪处理**:X 条重复日志已合并
> 本文档基于代码提取,并使用实际环境日志校正了时序和补充了 X 条遗漏日志。
注意事项
- 时序校正时,如果实际日志和代码顺序矛盾,以实际日志为准
- 遗漏补充时,推断不出的列先写"待确认",不要凭空填值
- 去噪只针对同一日志在循环内的重复,不合并不同日志
- 校正后的 CSV 覆盖原 CSV 文件