系列：《我用 AI 養出一個 AWS 維運同事》｜撰於 2026-09｜Kiro IDE 1.0
真實案例，環境與識別資訊已去識別化。

一個讓我起雞皮疙瘩的下午

那是一個普通的下午，我在追一個 Kubernetes 的鬼問題：某個節點上的 pod 怎麼樣都起不來。

查了快兩個小時，繞了一大圈——看 event、看 kubelet log、懷疑映像檔、懷疑資源不足、懷疑網路……最後發現根因根本不在 K8s 層：是那台底層的實體宿主機在鬧脾氣（硬體退化）。把實例 stop/start 遷到另一台健康的機器，問題就好了。當下鬆一口氣，記下來，收工。

結果過沒幾天——同一台節點，又掛了。

換作以前，我要重演一次偵探過程

以前遇到這種「似曾相識」的狀況，最痛苦的不是解問題，是**「想起上次怎麼解的」**。

等等，是哪一台來著？上次根因是什麼？我那時候怎麼處理的？翻 log、翻筆記、翻聊天紀錄、翻交接文件……光是「回憶」就要耗掉十幾分鐘，而且常常翻不到，只好硬著頭皮從頭查一次。維運的時間就是這樣一點一點被「重新想起來」給吃掉的。

這次我只丟了一句廢話

但這次我養的 AI 同事已經有了我在前傳（[前傳系列連結]）建的那套「分層動態記憶」——最近 7 天的事永遠在線。所以我只懶懶地丟了一句：

「這台是不是上次那台？」

它秒回：

「對，這個節點（IP 尾碼 x.x）上週出過一模一樣的 pod 起不來問題，當時判定是底層宿主機退化，用 stop/start 遷移解決的。這次建議先確認是不是同一台實體機，別又在 K8s 層繞。」

我盯著螢幕愣了一下。那一刻它不像工具，像一個跟我一起熬過上次那晚、還記得來龍去脈的老戰友。

為什麼它記得？把機制串起來

它會記得，不是因為模型多聰明，而是因為前傳那套分層記憶機制在背後運作：

1. 上次解完問題，這條「宿主機退化→stop/start 遷移」通過了記憶的篩選門檻（屬於「踩雷教訓」），被寫進 Hot 層的工作日誌。
2. 因為是最近 7 天的事，它還在 always 載入的 Hot 層裡，所以這次對話一開始，這條記憶就自動在它腦袋裡了。
3. 我一句「這台是不是上次那台」，它就從那條記憶對上了 IP、對上了根因。

如果那條記憶已經超過 7 天、沉到 Warm 層去了呢？它也不會裝死，會提示我「這好像跟之前某件事有關，要不要我撈一下歷史記憶」，我點頭它再去 Warm 層考古。該在的時候在、該讓路的時候讓路——這就是分層的意義。

維運人最有感的一句話

我特別想講這個案例，是因為它戳中維運最大的隱形成本：我們不是每天都在解新問題，我們花超多時間在「重新想起舊問題」。

輪班交接、事隔數週的重複故障、換手接別人的爛攤子……這些場景裡，「記憶」比「聰明」更值錢。一個記得住脈絡的普通同事，往往比一個很聰明但每天失憶的天才更好用。

帶走的三個重點

1. 維運的隱形成本是「重新想起來」。 重複故障、交接、考古，時間都耗在這。
2. 會記事的普通 AI，勝過失憶的聰明 AI。 「這台是不是上次那台」能秒回，靠的是記憶不是智商。
3. 分層讓記憶該在時在、該讓時讓。 最近的自動在線，久遠的提示你撈——不吵不鬧剛剛好。

記憶讓 AI 記得住「事件」，那「知識」呢？明天換一個更燒錢的實戰現場——一個 CloudWatch log 每天吃掉幾千塊美金的案子，看這套「錯題本」怎麼幫我把破案過程變成一條再也不會忘的知識。

✍️ 關於作者：康子晉，做 AWS 維運與架構，日常跟一堆帳號、費用、架構圖為伍。這個系列記錄我怎麼把 AI 從「會聊天」調教成「能扛維運的同事」。
🔗 LinkedIn