系列：《我用 AI 養出一個 AWS 維運同事》｜撰於 2026-09｜Kiro IDE 1.0
本篇是實戰驗收，兩個案例都是真實事件，客戶與帳號資訊已全部去識別化。

昨天講完那三個「審稿員」，今天來驗收。

我挑了兩個案例，因為它們剛好是同一種危險的兩張臉：一次是 AI 差點唬我，一次是我差點唬自己。 兩次都是靠「不准憑印象、去翻官方」這條紀律撈回來的。

案例一：一個看似無聊的合規需求

有天客戶問一件很無聊的事：「我們 RDS 上的資料庫能不能強制密碼複雜度？長度、大小寫、多久要換那種。」

聽起來很好答對吧。但這種「聽起來簡單」的問題最容易翻車，因為同一個服務底下不同引擎的機制常常天差地遠，而你腦袋裡通常只記得其中一種。我手上那幾套環境剛好 Oracle 跟 SQL Server 都有，我就直接問我的 AI 同事。

它很快給了我一套條理分明的說法。其中一句我當下覺得怪怪的：

SQL Server 在 RDS 上可以透過參數群組設定密碼最小長度，上限很寬……

因為前一天才看它上演「自己抓自己包」，這次我沒照單全收，逼它去翻官方文件實際確認。結果出入不小：

你看那個「最小長度上限只有 14」。如果我照第一版「上限很寬」回客戶，客戶興沖沖要求設 20、結果設不上去——那就是我專業破功的現場。

更陰的是那個 master 使用者不受約束。合規稽核最愛戳這種洞：你以為全庫都強制複雜度了，結果權限最大的那個帳號根本沒管到。

案例二：指令查嘸資料，心臟漏一拍

另一天要盤點某個帳號裡的 DMS（資料庫遷移服務）任務，評估要不要清掉。我照習慣下指令：

aws dms describe-replication-tasks --region <region>

回空的。 什麼都沒有。

心臟漏一拍。明明有在跑遷移，怎麼一個任務都查不到？被誰刪了？region 打錯？維運看到「應該有東西卻查無」那種不安，你懂的。

我把困惑丟給 AI，它幾乎同時做了兩件事：確認這帳號的 DMS 是哪種型態、比對兩種型態的指令差異。結論是——這是 Serverless 型的 DMS，而它跟傳統佈建型用的根本是兩套指令：

• describe-replication-tasks：只看得到傳統佈建型
• describe-replications：才撈得到 Serverless 型

所以東西沒不見，是我拿「看舊版」的望遠鏡去看新版。這個雷很陰，因為指令不會報錯、不會提醒你用錯，它就乖乖回你一個空陣列，害你往「東西被刪了」的方向想。「查無資料」跟「查錯地方」，症狀長得一模一樣。

連清理流程也是兩套：Serverless 型要先 stop-replication 再 delete-replication-config，而且帶的是 --replication-config-arn，不是舊版的 task 識別。刪除不可逆、會把整套資源收掉，動之前一定要確認清楚。

兩個案例，同一個心法

第一個是 AI 講得太順，第二個是我自己嚇自己。共同點是：兩次的救命繩都不是「更聰明」，是「去對帳」。

我想強調的是：AI 最危險的時刻，是它答得很順的時候。 答得結結巴巴你還會警覺，答得行雲流水你反而容易繳械。有數字、有上限、有「不支援」三個字的答案，全部都要複查——這種句子錯一個字，交出去就是事故。

還有一件我沒讓它船過水無痕的事：這兩次的結論都被沉澱進我的「錯題本」（Day 5 會講這套知識庫）。現在再有人問 RDS 密碼規則，它直接記得「SQL Server 上限 14、master 不受約束」；再碰到那個帳號的 DMS，它直接記得該用 describe-replications。踩過的坑要變成資產，不是每次重踩。

帶走的三個重點

1. 「聽起來很順」是最危險的訊號。 越流暢的答案越要複查，尤其是帶數字、帶上限的。
2. 「查無資料」常常是「查錯地方」。 指令回空又不報錯最騙人，先懷疑自己問錯方式，別急著懷疑東西不見。
3. 查證的結論要沉澱成知識，否則你只是每次都重新查一遍，沒有累積。

治唬爛的段落到此告一段落。明天進入記憶的深水區——我用一陣子後發現，光有前傳那套「工作日誌」還不夠，AI 其實需要第二種完全不同的記憶。這是前傳沒講過的東西。

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