凌晨的 Incident Review 結束時,大家都只想趕快睡覺。
會議開了快兩個小時。
有人查 Log。
有人翻最近的 Change。
有人提出可能是 Network,有人懷疑是某個 Service 重啟後沒有正常恢復。
最後 Incident 暫時解除,AI 也把整場討論整理成一頁:
Incident Summary
- Timeout started after service restart
- Network instability caused request failures
- Retry recovered most affected requests
- Next step: monitor service health
看起來很好。
比逐字稿短。
比聊天紀錄乾淨。
第二天早上,接手的人直接照這份 Summary 往下查。
他先找 Network Team。
「昨天已經確認是網路不穩對吧?」
對方看了一眼。
「誰確認的?」
他把摘要貼過去。
幾分鐘後,昨晚參加會議的人回覆:
「Network 只是我們當時的 Hypothesis,沒有驗證完成。」
真正有 Log 證據的只有兩件事:
Fact 1: timeout 在 service restart 之後開始
Fact 2: retry 後部分 request 恢復
至於:
Network instability caused request failures
那只是大家當晚準備優先驗證的一個方向。
AI 沒有捏造這句話。
會議裡真的有人講過。
它只是把所有重要句子整理成了同一種句子。
工作紀錄裡的句子,並不是只有「對」和「錯」兩種。
很多時候我們同時會有:
在討論現場,大家通常知道差別。
因為語氣、上下文、前後對話都還在。
有人會說:
「目前只能先假設是這個。」
或:
「先往這個方向查,但還沒證明。」
當 AI 把兩小時的會議壓成四個 Bullet,這些上下文很容易先被拿掉。
留下來的句子看起來就會變成:
Network instability caused request failures.
文字更俐落。
確定性也跟著變高了。
這才是問題。
整理資訊,不應該把資訊目前所處的工作狀態一起洗掉。
如果這份摘要只是給昨天參加會議的人看,問題可能不大。
大家知道那句話只是暫定方向。
但文件一旦進入交接,它就會變成下一個人的起點。
接手的人通常不會重新聽兩個小時的錄音。
他會相信整理後的版本已經保存重要內容。
於是:
Hypothesis
↓ 摘要
Statement
↓ 下一位讀者
Fact
中間只少了一個標記,工作的下一步卻完全改變。
如果它是 Hypothesis,下一步應該是找 Evidence。
如果它是 Fact,下一步可能已經是根據它做 Action。
同一句話,Work State 不同,後面的路徑就不同。
團隊沒有要求 AI 保留完整推理鏈。
也沒有把每一句話做成複雜的 Knowledge Graph。
Incident Summary 仍然是一頁。
只是幾個會影響後續判斷的句子旁,多了三種標記:
[F] Fact
[A] Assumption
[H] Hypothesis
例如:
[F] Timeout started after service restart
[H] Network instability may be related
[F] Retry recovered part of the affected traffic
如果某句話在會議裡根本沒有得到支持,也不會因為 AI 覺得「很合理」就被補成 Fact。
這個做法不會讓摘要變得更聰明。
它只是保留一件原本很容易在壓縮內容時消失的東西:
我們現在到底知道到哪裡。
又一次 Incident 發生後,凌晨班留下一份 AI Summary。
早班的人打開文件。
最上面三句:
[F] Service B stopped responding at 02:14
[A] Recent configuration change may be related
[H] Rollback should restore normal behavior
他沒有直接開始 Rollback。
也沒有先找人問「昨天是不是已經確認了」。
他先去找第二句和第三句還缺的 Evidence。
文件仍然只有一頁。
只是那一頁不再把「我們看到了什麼」和「我們正在猜什麼」寫成同一種語氣。