系列：《我用 AI 養出一個 AWS 維運同事》｜撰於 2026-09｜Kiro IDE 1.0

維運人的日常：一個人顧一票帳號

做維運的都懂，你手上通常不是一個 AWS 帳號，是一整排。正式區、測試區、災備區、某個客戶的 PoC、某個內部專案……每個帳號的用途、region、跑了哪些服務都不一樣。

痛點是：這些「帳號基本資料」你自己都常常記混，更別說一個每次對話都失憶的 AI。你問它「幫我看那個測試帳號的費用」，它根本不知道「那個測試帳號」是哪一個。

前傳我提過可以把帳號資料寫成 Steering 檔。但這一季我要講兩件前傳沒講的事：怎麼讓這些帳號檔「按需載入」不佔成本，以及怎麼讓它「自己更新」不用我手動維護。

第一件：帳號檔要「按需載入」

我幫每個帳號各寫一個檔（像 account-測試環境.md），裡面記帳號 ID、用途、region、主要資源清單。但這裡有個成本考量——

如果每個帳號檔都設成「永遠載入」，那我十個帳號的清單每次對話都塞進 AI 腦袋，光是這些就吃掉一大把 context。可是我大部分對話只跟其中一個帳號有關啊。

所以我把帳號檔設成**「講到才載入」（auto 模式）**：在檔案開頭寫好觸發關鍵字，我一提到某個帳號的代號，Kiro 才把對應的那份拉進來，其他九份乖乖待在硬碟上不佔位。

---
inclusion: auto
name: account-測試環境
description: 某測試帳號資源清單。當使用者提到 測試帳號、這個帳號代號、相關服務名 時自動載入。
---
# 某測試帳號
- 帳號 ID：尾碼 xxxx
- 用途：內部測試 / PoC
- Region：東京
## 主要資源
- EKS 叢集 ×1、RDS ×1、數個 NAT Gateway（注意：閒置也計費）

這就是「該用才出現」的智慧——知識放著不刪，但只在相關時才佔用 context。維運管越多帳號，這個設計省越多。

第二件（重點）：清單會「自己更新」

帳號清單最大的問題不是寫，是維護。你今天記了「這帳號有 3 台 EC2」，下週砍了一台、又開了一顆 RDS，清單立刻就過時了。手動追？不可能。

所以我設了一個背景 hook（sync-account-memory），觸發時機是「每次對話結束」。它做一件事：

掃描這次對話，如果我有查過某帳號的 AWS 資源、而且發現跟清單記的不一樣（狀態變了、版本升了、資源增減了），就自動把差異更新回對應的帳號檔，並標上日期。

舉個實際的：某次我請 AI 查某帳號的 RDS 狀態，它發現「清單記著 running，實際已經 stopped」。對話結束後這個 hook 自動醒來，把帳號檔那筆改成 stopped、加一行 - 2026-XX-XX：RDS 已停止。我什麼都沒做，清單自己就跟上了現實。

為什麼這對維運是質變

因為它解決了所有「資產清單」的宿命——清單一定會過時。

我們維運寫過多少 Excel 資產表、Confluence 架構頁，最後都因為「沒人更新」變成廢紙？這個 hook 的價值就是把「更新清單」這個永遠會被遺忘的動作，綁進「反正你本來就會做的事」（查資源）裡面。你查的當下，順手就更新了，不用另外開一個維護任務。

這也呼應前面幾天的主軸：能自動的紀律，就別靠人的意志力。 資產清單的準確度，不該建立在「某個勤勞的人記得更新」上面。

一個誠實的限制

這個機制不是萬能的。它只更新「這次對話有實際查到」的東西——你沒查的帳號、沒碰到的資源，它不會通靈幫你補。所以它是「你走到哪、清單準到哪」的漸進式更新，不是一次性的全帳號盤點。全盤盤點還是得靠專門的巡檢（那又是另一個 skill 的活，後面會講）。誠實講清楚工具的邊界，比吹它無所不能重要。

照著做：我的實際設定

一個帳號一個檔（.kiro/steering/account-<代號>.md），關鍵在 frontmatter 用 auto——講到這個帳號才載入，不佔平常成本：

---
inclusion: auto
name: account-<代號>
description: <帳號用途一句話>。當使用者提到 <代號>、<12 碼 account id>、<主要 region>、<命名前綴>、<常見資源名> 時自動載入。
---

# <帳號代號> 資源清單

- **Account ID**：<12 碼>
- **Account Alias**：
- **所屬 Organization**：<org id / master 帳號>
- **登入身分**：<IAM user 或 SSO permission set，標註唯讀或可寫>
- **主要 Region**：<region>（其餘區皆空 / 有哪些例外）
- **命名前綴**：`<prefix->`

## EC2
| Name | Instance ID | 型別 | 狀態 | 用途 |
|---|---|---|---|---|

## RDS / 資料庫
| 識別碼 | 引擎版本 | 規格 | 加密 | 備註 |
|---|---|---|---|---|

## 網路
- VPC / CIDR：
- 對外入口：
- VPN / 對接：

## 備註與變更紀錄
- YYYY-MM-DD：[變更描述]

description 是這整套的靈魂——它就是「什麼時候該想起這個帳號」的觸發條件。我會把帳號代號、account id、region、命名前綴、甚至那個帳號裡最常被問到的資源名全塞進去。塞得越具體，它越不會在你問 A 帳號的時候載入 B 帳號。

清單怎麼自己更新？ 靠一段掛在對話結束時的規則（我把它併在淺睡 hook 裡，不另外開一個）：

## 帳號資源增量同步
先過閘門：本次對話**有無透過 AWS CLI/MCP 實際查詢或操作帳號資源**？
沒有 → 整段跳過、不輸出。
有 → 只做增量：發現新資源、狀態變更（running↔stopped、版本升級、設定修改），
或與現有 account-*.md 矛盾 → 以本次確認的最新事實增量更新對應檔案，
在備註區加 `- YYYY-MM-DD：[變更描述]`。
規則：只改有實際變動處、不覆蓋既有內容、不大規模重整、不輸出分析過程。

那個「先過閘門」很重要。沒有它，它每次對話結束都會想去「檢查一下帳號」，等於你每聊一句天就多打一輪 API。閘門的邏輯很簡單：這次真的有查過資源，才有資格更新清單。

還有「只改有實際變動處、不大規模重整」——這條是防它熱心。我遇過它自己覺得「這個表格排版可以更好」，然後把我整份清單重寫一遍，順手改掉幾個我刻意寫的備註。讓 AI 維護文件，一定要framing成「增量」，不然它會幫你重構。

帶走的三個重點

1. 帳號檔設成「講到才載入」。 管越多帳號，這個 auto 模式省越多 context。
2. 讓清單自己更新。 把「更新資產表」綁進「查資源」這個你本來就會做的動作裡。
3. 資產清單的準確度別靠人的勤勞。 這是資產管理的通病，自動同步才治本。

明天開始連續兩篇成本實戰——先從一個經典誤區開刀：EC2 關機 ≠ 省錢。我一句話請 AI 盤點閒置資源，結果它挖出一堆「關了機還在燒錢」的東西。

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