炸掉的那一項，兩週前顯示正常

回頭翻上個月出事的那件案子，前兩週的週報上它完全正常。

每一項都有狀態，每一個延遲都有標註，格式整齊到可以直接貼給主管。後來出問題的那個環節，當時顯示的是「等待對方回覆」，而且已經這樣顯示了兩週。沒有紅字，因為它沒有逾期；沒有人追，因為它看起來只是在等。兩週之後它變成擋住四個人的那一站。

整理得再好，回答的還是同一個問題

週報沒有寫錯任何一件事，它誠實地回答了「現在發生什麼」。

生成式 AI 在這件事上已經很成熟：哪些工作完成、哪些 ticket 延遲、誰手上壓最多事，本質上是把現有資料換一個形狀呈現，又快又不太會錯。但工作裡最需要判斷力的地方，通常不在已經成形的事實上，而在還沒有明確答案的訊號裡。那個 dependency 兩週沒動，會不會變成 critical path。同一類問題最近冒出三次，是三個獨立意外，還是某個東西正在壞掉的早期症狀。

這類問題的共同點是：現在的資料不足以回答，而等到資料足夠，通常也來不及了。

把模糊的觀察寫成可以被推翻的句子

格式很土，但有用：

目前看到的是 A，所以暫時假設 B。如果接下來出現 C，這個假設值得提高關注；如果出現 D，就直接劃掉。

套進剛剛那一格：目前看到某個 dependency 兩週沒動，假設對方那一側的優先序已經掉了。如果下週回覆依然停在「還在確認」，假設成立，要主動去談；如果對方給了具體日期，這條結案。

這跟預測不一樣。預測追求猜中，猜中會上癮，猜不中會讓人放棄記錄。假設追求的是讓下一週的觀察變得有意義，因為你已經先說好要盯哪一個訊號。

這一步不適合整段外包。篩選「哪些項目停滯超過兩週」給 AI 很合理；但「這個停滯代表什麼」需要的是對組織的理解，包括那個人的做事風格、那個部門這一季的壓力、上次類似狀況怎麼收場。這些不在 Jira 裡。

今天可以做的一件事

最常見的問法是這一句：

幫我看看這個專案目前有哪些風險。

回來的會是一張已經延遲、已經標紅的清單，上面每一項你都早就知道了。風險清單只整理得出已經發生的事，而今天要練的是還沒有發生的那一類。

下面兩段 prompt 可以直接複製，建議在 demo 站台上跑。

第一段：生成今天主題的測試資料

請先列出我有權限寫入的 Jira 專案，挑一個名稱或 key 含 test、demo
或 sandbox 的；如果都沒有，就挑清單中的第一個，並在開始前告訴我你
選了哪一個。

在那個專案建立 8 張練習用 issue，summary 一律以 [DEMO-WEAK] 開頭，
內容全部虛構。情境是一家線上教育平台公司的「客服工單自動分流」專案，
情境時間設定在 2026/10/31。

Jira 的建立日與更新日由系統寫入、改不動，所以時間線一律寫在描述裡：
每一張 issue 的描述第一行固定寫成「最後聯繫：YYYY/MM/DD」。
另外，8 張全部指派給我，負責人欄位不要留空。

要建立的 8 張：
1. 狀態「等待第三方回覆」，最後聯繫 2026/10/17，due date 設
   2026/11/20，所以它沒有逾期、不會標紅。內容是等待外部簡訊
   供應商確認 API 額度。
2~4. 三張分屬不同元件（匯入、排程、通知），表面上互不相關，但三張的
   描述裡都提到「同一批舊工單資料的欄位格式不一致」。最後聯繫分別是
   10/14、10/22、10/29。
5. 一張 due date 設在 2026/10/29、已經逾期兩天的 issue，內容是補
   一份規格文件，影響很小。最後聯繫 10/29。
6~8. 三張正常推進的 issue，最後聯繫落在 10/28 到 10/30 之間。
   這三張必須彼此無關：不共用資料來源、不共用待驗證的項目，
   描述裡也不要出現任何一張與另一張相同的專有名詞。

不要在任何一張裡寫出「風險」「警訊」「需要注意」這類字眼，
也不要用標籤或優先序暗示哪一張比較重要。

完成後只列出 8 張的 key、狀態、描述第一行的最後聯繫日與 due date。

第二段：把今天的主題跑在這批資料上

請讀取那批 [DEMO-WEAK] issue。情境時間是 2026/10/31。
時間一律以每張描述第一行的「最後聯繫」為準，不要用 Jira 的系統更新日。

不要做狀態彙整，也不要列出已經逾期的項目，那些我已經知道了。
不要把欄位空白當成訊號：沒有留言、沒有附件、彼此之間沒有關聯連結，
都只代表這批練習資料沒有填，不代表發生過什麼。

請找出「目前資料還不足以下判斷，但值得先提出假設」的位置，
每一個寫成四行：
- 目前看到的是什麼（附 issue key 與最後聯繫日）
- 因此暫時假設什麼
- 接下來出現什麼，這個假設就該提高關注
- 接下來出現什麼，就可以直接劃掉

最後告訴我：這些假設裡有哪幾個無法用這批 issue 的描述驗證，
必須由人去問，以及該問誰。

跑完之後不要通篇讀，只做三個動作。

先找那兩個一定要出現的。 一個是等簡訊供應商確認額度那張，最後聯繫停在 10/17、due date 還沒到，所以整個畫面上毫無標示。另一個是匯入、排程、通知那三張，描述裡指向同一批舊資料格式。第二個難很多，因為它要跨票比對描述文字，而不是讀狀態欄位。多數追蹤工具做不到，是因為它們按元件切分，三張票各自待在自己那一區都很正常。

剩下的每一個假設，只讀「目前看到的是什麼」那一行。 那一行引用的如果是描述裡的句子，留著，那是你沒設計到但確實存在的訊號。那一行如果寫的是「沒有留言」「沒有負責人」「三張之間沒有關聯連結」，直接劃掉。

這個分辨在真實專案裡一樣要做而且更難，一個空欄位到底代表沒人處理，還是代表這個欄位本來就沒人在用。這一題沒有捷徑，只能去問。

順帶一提 Jira 的更新日是系統寫的、生成資料時改不動，所以這個練習的時間線才要寫進描述第一行。你以為在讀的那個欄位，不一定在記錄你以為的那件事。週報上那格「等待對方回覆」也是同一回事，它記的不是進度，是有沒有人改過它。

搬回自己的專案時，找一個停超過兩週、但沒有任何紅字的項目，寫兩行：一行假設，一行下週要盯的訊號。三個月後回頭看，被推翻的那些假設通常比猜中的更有價值，它們會告訴你自己對這個組織的理解錯在哪裡。

留到明天的問題

週報從來沒有騙過人，它只是誠實回答了一個比較安全的問題。早期訊號沒有欄位可以填，不會變紅，也不會出現在任何一份彙整裡，於是它們每一次都合法地通過了所有檢查，一路走到不再是訊號、而是事故的那一天。工具愈整齊，這件事愈不容易被看見。

假設寫下來了。下週打開 AI 給的那份分析，你會重新算一次，還是會因為它看起來很完整就直接接受？

再往下想一層，願意為還沒發生的事情擔心，是人特有的麻煩。系統只回報已經成立的狀態，而人會在資料不足的時候先感覺到不對勁，然後花力氣去查一件可能根本沒事的事。這種力氣事後看常常是白費的，可是組織裡每一次沒有變成事故的事，背後通常都有人白費過一次力氣。

那些沒有發生的意外不會有人記得，也不會出現在任何一份報告上。