日志与时间线诊断（V10）

现场问题最常见的误区是：看到最后一条 Error，就把它当成根因。

实际上最后一条错误往往只是连锁反应。

V10 日志分析优先回答：

正常流程从哪一刻开始偏离？第一个可证明的异常点是什么？

1. 先收窄时间窗，不要一上来读整天日志

第一轮通常只需要：

text

异常现象
大概发生时间
用户当时做了什么
是否以前正常
有哪些日志源

然后收窄：

text

异常前 10–60 s
→ 异常时刻
→ 异常后 10–60 s

如果问题是数小时后出现，再按关键阶段切片，而不是一次让 AI 吞完整日志目录。

2. 多源日志先对齐时间

可能同时有：

应用业务日志；
通信 TX/RX；
设备错误队列；
WPF/UI 操作日志；
MES/外部系统日志；
Windows/System 日志；
波形/采样文件；
Git 版本和配置快照。

先确认：

text

Timestamp format
Timezone
Clock source
是否有时钟漂移
是否有缺口/gap

如果设备时间和工控机时间相差 3 秒，不先校正时间就可能把响应看成“请求之前发生”。

3. 建最小事件时间线

推荐结构：

Time	Source	Event	State	Evidence
10:20:01.100	UI	点击 Start	Ready	operation log
10:20:01.130	App	Start accepted	Starting	app log
10:20:01.180	SCPI TX	`...`	session=1	raw log
10:20:01.235	SCPI RX	`...`	session=1	raw log
10:20:02.010	App	state=Running	Running	state log
10:20:04.200	RX	unexpected length	Running	raw + parser log
10:20:04.205	Parser	frame rejected	Running	parser log
10:20:06.210	App	timeout	Alarm	app log

这里真正需要调查的可能是 10:20:04.200，而不是两秒后的 timeout。

4. 找“第一个异常点”，再向前看触发条件

常见第一个异常点：

第一帧长度异常；
第一次序号跳变；
第一个 CRC 错；
第一次状态没有按预期转换；
第一次队列积压；
第一次设备查询没有响应；
第一次出现第二 Session；
第一次 UI 延迟明显升高；
第一次保存失败。

然后看它前面的 3–10 个关键事件：

text

发生异常前
用户做了什么？
状态是什么？
刚发了什么命令？
配置有没有变化？
是否发生重连/停止/恢复？

5. 通信问题要同时看 Transport 和 Protocol

不要看到 timeout 就自动说“网络抖动”。

Transport 证据

Socket disconnect；
SerialPort exception；
TCP reset；
VISA session error；
物理链路丢失。

Protocol 证据

长度字段不一致；
半包/粘包处理错误；
CRC/校验失败；
命令字/序号不匹配；
parser 丢弃合法帧；
请求响应关联错误；
状态恢复后仍按旧协议上下文解析。

两者都存在时写 Mixed，不要强行只选网络或软件。

6. 请求—响应关联要看“谁等谁”

建议把通信日志至少记录：

text

Timestamp
Direction
Session
Command/Sequence
Raw
ParsedResult
Elapsed

然后核对：

text

TX A
→ RX A?
→ 是否被别的请求插入？
→ 是否超时后迟到？
→ 是否被错误地匹配给 B？

如果协议没有序号，尤其要关注并发发送和多个 Session。

7. 日志结论分三层就够了

8. 近期回归：时间线还要叠加 known-good

如果用户说“昨天还正常”：

text

新版本异常时间线
vs
known-good 正常时间线

对比：

多了哪条命令；
顺序是否变化；
timing 是否变化；
状态是否提前/延后；
配置值是否变化；
是否多了第二 Session；
某一步是否从异步变成同步等待。

这种差异比“当前代码某方法看起来奇怪”更接近 regression cause。

9. 偶发问题要优先生成 Replay 资产

一旦抓到一次现场问题，尽量保留：

text

Raw input
Timing
State snapshot
Expected behavior
Observed behavior

把它转成：

Captured Replay；
focused parser test；
workflow scenario；
最小 harness。

以后就不需要每次等现场“再偶发一次”。

10. “重试后恢复”只提高某类假设概率

重试后恢复可能与：

设备瞬态状态；
Session 残留；
超时窗口；
状态机未复位；
缓存旧数据；
并发竞态；
网络/驱动瞬态；

有关。

但单凭“第二次好了”不能确认其中任何一个。

正确标签：

text

SuspectedTransient

下一次重点补缺少的状态/命令/时间戳证据。

11. 日志太多本身也可能制造问题

高频采集项目要注意：

每帧写全文日志；
每次异常重复打印完整堆栈；
UI 同时展示全部日志；
Raw HEX 无限制保存；
日志锁阻塞 receive thread。

如果日志本身影响性能，先保留关键诊断语义，再节流/采样/分层。

进入：性能与长稳诊断。

12. 操作员日志和维护日志不要混成一层

操作员需要：

text

发生了什么
当前是否继续/停止
下一步怎么办

维护人员需要：

text

原始错误
命令/响应
状态
错误码
时间线

详见操作员界面与维护诊断。

13. 最短日志分析 Prompt

text

$host-computer-dev
请按日志时间线分析当前问题，不要先猜根因。

现象：
【填写】

异常时间范围：
【填写】

是否以前正常：
【是/否；known-good 如有请说明】

日志/报文：
【提供或指定文件】

请输出：
1. 关键时间线；
2. 第一个异常点；
3. 异常前的触发上下文；
4. Evidence / Inference / Unknown；
5. 如果是通信问题，区分 Transport / Protocol / Mixed；
6. 下一组最有区分力的证据。

14. 和其它流程怎么衔接

需要确认根因 → Bug / 回归定位
通信原始证据 → 通信证据包
性能时间线 → 性能与长稳诊断
Session/停止问题 → 资源生命周期
近期回归 → known-good-first Temporal Regression

一句话原则

日志分析不是找最后一条 Error，而是把多源证据按时间串起来，找到系统第一次偏离正常行为的位置。

日志与时间线诊断（V10） ​

1. 先收窄时间窗，不要一上来读整天日志 ​

2. 多源日志先对齐时间 ​

3. 建最小事件时间线 ​

4. 找“第一个异常点”，再向前看触发条件 ​

5. 通信问题要同时看 Transport 和 Protocol ​

Transport 证据 ​

Protocol 证据 ​

6. 请求—响应关联要看“谁等谁” ​

7. 日志结论分三层就够了 ​

8. 近期回归：时间线还要叠加 known-good ​

9. 偶发问题要优先生成 Replay 资产 ​

10. “重试后恢复”只提高某类假设概率 ​

11. 日志太多本身也可能制造问题 ​

12. 操作员日志和维护日志不要混成一层 ​

13. 最短日志分析 Prompt ​

14. 和其它流程怎么衔接 ​

一句话原则 ​

日志与时间线诊断（V10）

1. 先收窄时间窗，不要一上来读整天日志

2. 多源日志先对齐时间

3. 建最小事件时间线

4. 找“第一个异常点”，再向前看触发条件

5. 通信问题要同时看 Transport 和 Protocol

Transport 证据

Protocol 证据

6. 请求—响应关联要看“谁等谁”

7. 日志结论分三层就够了

8. 近期回归：时间线还要叠加 known-good

9. 偶发问题要优先生成 Replay 资产

10. “重试后恢复”只提高某类假设概率

11. 日志太多本身也可能制造问题

12. 操作员日志和维护日志不要混成一层

13. 最短日志分析 Prompt

14. 和其它流程怎么衔接

一句话原则