從 Day 8 到 Day 15，一連八篇都是生產環境的真實事故現場。今天先停下來，不開新案子，回頭盤點這八篇裡反覆出現的模式——AI 什麼時候會系統性地出錯、什麼時候反而很可靠，人在中間做的那些事，到底哪幾件是真正無法外包的。
第一種：脈絡沒餵齊，它就會很有自信地走錯方向。 這是出現次數最多的模式。Day 07 的 trixie 案例，AI 繞了七八輪套件相容性，直到我補上「這台機器 Docker 18、Ubuntu 16」才一句話破案；Day 11 追查全表鎖死時，同一個問題在兩個沒有共享記憶的工作階段裡，AI 給出的解釋精確度完全不同；Day 15 的 WebSocket 案例，AI 順著一張沒講清楚涵蓋範圍的截圖，一路推導出一個邏輯自洽、卻建立在錯誤前提上的結論。這些都不是 AI 能力不夠，是它手上的資訊本來就不完整，它沒辦法知道自己不知道什麼。
第二種：它會被自己第一個想到的方向黏住。 Day 08 的 CentOS 7 案例，AI 一路懷疑 webhook 設定，直到我反問「不是應該往前查嗎」才鬆手；Day 12 的撞號偵探故事裡，AI 連續七次提出各自成立、卻都被業務規則戳破的假設。AI 的假設生成能力很強，但沒有天生的煞車機制去質疑「我是不是又在同一個方向鑽牛角尖」——除非有人從外部把它拉出來。
第三種：它有先天做不到的事，自己會混淆能力邊界。 Day 09 的台灣地圖，AI 憑空手繪畫不出精確海岸線，這不是努力不夠，是生成式繪圖本來就沒有精確幾何座標的概念；同一篇的浮水印案例更隱蔽——AI 連續四次誤判一個 PDF 指令有沒有生效，因為它自己也分不清楚「讀取 PDF」用的是解析文字層還是視覺辨識。這種錯不會主動舉手，它會給一個聽起來很完整、甚至附帶比較表的答案，讓人以為問題解決了。
系列一路強調 AI 會出錯，但八篇故事裡也有不少「AI 沒有辜負期待」的橋段，這些同樣值得記下來，不然容易寫成只有恐懼、沒有信任的協作。
Day 10 清理資料夾時，AI 面對自己量到「深度不減反增」的詭異數字，沒有照單全收，反而先質疑量測方法本身可能失真，說出「這個我沒辦法採信」；Day 14 的稽查系統需求討論，AI 沒有接受我「有完整單元測試」的樂觀說法，先做了一次測試覆蓋盤點才回答，結果真的挖出漏洞；Day 07 的 trixie 案例裡，AI 一看到「53KB 卻報記憶體不足」的矛盾，幾乎立刻猜對是環境版本問題。AI 可靠的時候，往往是它被要求或習慣性地「先查證再回答」的時候，不可靠的時候，往往是它在資訊不足的狀況下，還是得硬給一個答案的時候。
把八篇攤開來看，人做的事可以歸納成幾類，而且每一類都不是「比 AI 更懂技術」，是幾種 AI 拿不到的東西：
餵脈絡。 Day 07 的 trixie 案例的機器版本、Day 11 的歷史包袱記憶（Sequelize 條件被省略的舊坑）、Day 15 那句「這張截圖其實也經過 nginx」——這些都是只存在人腦中、AI 沒有主動管道去取得的背景資訊。
用業務知識或部署事實戳破假設。 Day 12 的「送件編號是中央單位發的，不可能重複」、「沒有用 PM2，是單一 process」，這些是業務規則和維運事實，不是靠邏輯推導，是靠記得。
回報現場的即時狀態。 Day 10 的「都是空資料夾」、Day 13 的「跟隨轉址就變慢了」——AI 看不到螢幕，只能靠人告訴它現在真正發生了什麼。
設計實驗、決定下一步要驗什麼。 Day 13 那組連續打跟間隔打的對照測試，是人自己想到要做的，AI 沒有主動提議；決定「這個異常值要不要推翻整個理論」的判斷，也是人做的。
在危險的地方多問一句。 Day 10 那句「這是什麼意思」，攔下了一個可能波及其他專案的操作建議。
設定分工的邊界。 Day 14 那句「程式或邏輯錯誤可以順手修正，業務動作要先問過我」，是把權責提前講清楚，而不是等出事才追究。
八篇故事表面上主題都不一樣——鎖死、崩潰、撞號、效能、需求討論、斷線——但拆到最後，結構其實高度重複：AI 提供的是處理速度和系統性方法，人提供的是脈絡、記憶、現場觀察，跟叫停的判斷力。 少了前者，很多排查會慢到不切實際；少了後者，AI 會很有自信地在錯的方向上跑得又快又遠。
這也是為什麼「AI 協作紀律」聽起來抽象，落到實際案例裡卻很具體——它不是什麼玄妙的心法，就是這幾件事：脈絡給齊、假設別照單全收、現場的事自己去看、危險的地方多問一句。八篇事故，講的其實都是同一件事的不同展現。
明天要換一個場景——從救火現場切到合規稽核。同樣是人機協作，但規則變了：這次不是「東西壞了要修」，是「東西沒壞，但稽核單位覺得不夠安全」，而多數安全標頭建議，做了也不會有等值的回報。哪一個才是真正值得花力氣做的，AI 給的答案，跟弱點掃描報告給的答案，常常不一樣。
iThome鐵人賽
看影片追技術