為什麼我讓 AI 只做建議、不做決定

身為軟體工程師，我想大多數的人都有體驗過維運的痛苦。解不完的 bug、突發的資料查詢、其他團隊跑來對你說「這個很急，可以先看嗎？」
所以想來聊聊我們在既有開發排程的縫隙中推動的維運改善計劃。
關於我們怎麼把 AI 放進維運改善流程裡，但不讓它成為最後的決策者。

知識在哪裡？

在團隊資源有限的情況下，許多維運問題會需要跨角色一起處理。雖然應該會有人說：「軟體工程師哪有在分角色？來什麼就做什麼。」但是身為一個轉職仔，真的是自嘆不如那些兵來將擋、水來土掩的同事們。
「那就來寫 Playbook 吧！」 這個是我最初的想法。

Playbook

Playbook 簡單來說就是維運教戰手冊。

憑著印象，我把覺得經常出現的問題類型、以及較有經驗的工程師會採取的調查方法整理成筆記，提供給其他需要處理類似問題的人參考。
但憑藉感覺來決定哪些問題要寫，實在不是一個很科學的做法。於是請出我們的新好同事：AI。

我們整理了一批歷史 issue，請 AI 協助找出高頻問題，然後我們針對這些高頻問題撰寫筆記內容。
但是，不在 Playbook 裡的維運問題呢？
面對不在 Playbook 的內容，就只能依靠記憶以及經驗了。

「感覺以前好像有看過類似的東西」，我們只能靠著微弱的印象在團隊討論紀錄中搜尋關鍵字，試圖找到以前的類似問題，然後參考其中的解決方法。但是這套方法只對有年資的人有效，對於新人來說，出現的都是新的問題。知識沒有消失，只是被鎖在個人記憶裡了。
我們也發現，「高頻問題」其實也只佔了全部 issue 的大約 10%-20%。產品迭代速度實在太快，內容很快就過時，寫 Playbook 不會是最有效的方法。

只寫 Playbook 不夠

而且，面對 issue 過多、人手不足的問題，真正的解法應該不是把每個人都培養成解 issue 速度超快的軟體工程師，而是從根源解決 issue 過多的問題。
雖然這很理想，簡直是軟體世界的烏托邦，但我們還是決定嘗試看看。

Postmortem Notes

我們決定讓處理過的 issue 留下結構化的「事後檢討資訊」，其中包含問題的原因、大略的調查經過，以及後續可以進行優化的地方。
但有的 issue 討論內容動輒一百筆以上的對話，要讀完前因後果、萃取出精華就得花上不少時間，所以我們又再次請出了我們的 AI 好同事。

全自動 vs 半自動——以及半自動的代價

原本的目標是想要讓 AI 一次分析一大批 issue，然後把這些事後檢討資訊，以及後續應該持續關注的優化領域全部寫回既有的內部紀錄系統上。但是考慮到這些資訊未來會作為改善項目的依據，我們不太放心讓 AI 全權決定這一切，畢竟錯誤的內容比沒有內容還要來得更可怕。於是我們決定讓 AI 在寫入前先回報，人工確認沒問題後，再寫回內部紀錄系統。

實際跑起來發現，要同時確認 AI 產出的檢討內容以及後續優化領域，雖然只是「核對」的工作，在簡短的 issue 不需要花費太多時間，但遇到複雜的 issue，我們得讀完上百則對話，才能判斷 AI 的摘要對不對，而這等於把 AI 省下的時間又花了回去。所以我們需要一套系統性的方法衡量 AI 輸出的可信度。

資訊不足請直說——壓制腦補比提升聰明重要

關於 postmortem notes，剛開始我們單純請 AI 讀取討論紀錄做分析，測試少量的 issue 時，跑起來沒有太大的異常，給予的回饋也都蠻合理的。
但是當一次分析的 issue 數量增加的時候，就發現有一些幻覺開始發生：像是明明討論紀錄中只有提到後續要另外再優化，但 postmortem notes 卻提到某某已經完成修正；或是煞有其事地說「因為系統中的某某功能是這樣寫的，所以可以這樣改善」，即使他的上下文裡面根本沒有讀到實際的程式碼。

所以面對 AI，就要明確地告訴他：知之為知之，不知為不知，是知也。
我們在 prompt 裡明確要求資訊不足的地方要直接說明無法分析，不然這些腦補的東西寫進 postmortem 裡，反而會成為雜訊。

後續優化領域，六個類型，不讓模型自由發揮

關於後續優化領域，我們並沒有一開始就讓 AI 自由發揮。我相信有使用過 AI 的都曾經歷過，LLM 沒有跨 session 的記憶。如果讓它自由歸納後續優化領域，這一批跑出來的分類體系，下一批可能就長得不一樣；即使概念相同，用字也會有些微差異，累積幾十筆之後就無法聚合統計。

因此我們和 AI 討論後，最終定案六個後續優化領域類型，並且分別給予這六個類型初步定義，讓 AI 可以根據這些定義替 issue 分類。
其中「可加入 Playbook」這個類型，也讓開頭提到的 Playbook 有了新的定位：它不再是憑印象決定要寫什麼，而是由 postmortem 的分類結果來篩選——只有重複性高、流程明確的問題才會被寫進去。Playbook 依然存在，只是從「主要策略」變成了這套流程的下游產出，也因此不會什麼都塞進去、變得複雜難查；而那些不適合寫成 SOP 的一次性問題，也都留在了結構化、相對容易搜尋的 postmortem notes 裡，不再躺在資深員工的大腦裡。

當時的 prompt：

你是一個專業的技術 issue 分析師。請根據以下團隊討論紀錄內容，分析這個 issue 並提供：

Postmortem Note：用 1-3 句繁體中文說明：

問題是什麼

根本原因

如何解決（若已解決）若資訊不足，請直接說明「資訊不足，無法完整分析。」

後續優化領域：從以下固定選項中選出適合的（可多選，可為空列表）：

可加入 Playbook：重複性、流程明確的人工操作，適合建立 SOP；或調查狀況複雜，適合寫成工程師的調查指引。

產品技術改善：有系統性 / 結構性改善空間的問題。

增加 Log：缺少足夠的 log 記錄，導致排查困難或資訊不透明。

監控：需要主動告警機制，避免問題靜默發生（如資料同步中斷等）。

外部資料規格：來源資料格式、同步規格或資料品質與預期不一致。

操作體驗：流程設計、介面提示或使用者理解落差造成的問題。

可信度來自於約束，但約束有成本

照著上面提到的做法，我們分析了接近 200 則歷史 issue，將 postmortem notes 以及後續優化領域作為依據，再請 AI 依據目前掌握到的技術脈絡，初步產出了 10 個後續改善方向，並計畫未來依序排進排程中。然而這 10 個後續改善項目中，依然有一些被回報與現況不符，而我們也正在持續優化這一整套流程。

對於內部工具來說，其可信度並不來自於模型有多強，而是來自於三個約束——掌握在人類手上的寫入權、封閉的分類空間、不確定時必須承認。
即使如此，這些約束也不是免費的。人工確認的約束或許相對穩定，但產出速度無法擴張，並且會依據不同的人而有不同的判斷。因此我想，從「人類逐筆確認」，慢慢走向「系統性地衡量」會是一個比較理想的做法。

下一篇預計會談談要如何為這個內部工具建立衡量機制，不過這個機制也還在建立當中，也許要幾個月後再見了。