平台通知密鑰可能外洩時，你知道哪些服務要換嗎？
部署平台通知環境變數可能外洩，你打開後台，卻想不起來哪些服務用了這些密鑰。做得出來不代表維護得了，先備好一份清單，出事時才答得出要換甚麼。
你用 AI 做好的網站已經有人在用。某天部署平台通知環境變數可能外洩，你打開後台，卻想不起來哪些服務用了這些密鑰，也不知道換完會不會讓網站掛掉。
2026 年 10 月，我從 Zeabur 搬到 Railway 後，又看到 Railway 傳出環境變數可能被存取。這讓我想到，AI 讓我們更快做出東西，但做得出來，不代表已經有能力維護。至於搬離 Zeabur 後怎麼用 AI 讀它開源的程式碼，我另寫了這篇文章。
平台出事，跟用不用 AI 寫程式有甚麼關係？
平台或套件出問題，不管程式是誰寫的，都可能受影響。 當時有人看到漏洞消息就嘲笑 Vibe Coding，但只要依賴同一個平台或套件，都得面對同一則公告。
我越來越覺得，AI 讓產出速度超過人類理解、驗證與維護的速度。 我們能用更低的成本做出更多東西，卻不代表扛得起隨之而來的責任。
AI 也能幫忙調查和修復，但要判斷它找對了沒，你得先知道服務部署在哪裡、用了哪些套件，密鑰又放在哪裡。
收到通知時，先找哪些東西？
平常先準備一份清單，目標是出事時能在半小時內回答三個問題。 這是準備的目標，不是保證半小時就能查完或修好；服務越多、資訊越分散，可能要花更久。
| 出事時要回答 | 平常先記下甚麼 |
|---|---|
| 我有沒有中？ | 各服務部署在哪個平台、主要套件與版本，還有誰負責處理 |
| 要換哪些密鑰？ | 密鑰的用途、存放位置、哪個服務發行的，以及哪些應用在用；清單不存密鑰本身 |
| 要更新哪些版本？ | 正在用的語言和套件版本、部署方式與基本測試，方便對照公告和驗證更新 |
AI 可以讀專案幫你整理第一版，但平台後台的設定未必都在程式碼裡。拿清單對照實際部署環境，新增服務或換密鑰時也一起更新。
比如收到平台環境變數可能外洩的通知，先照清單找出放在該平台的密鑰，以及用到它們的服務。再去發行密鑰的各個服務建立新密鑰、更新部署設定，確認相關功能正常後撤銷舊密鑰；先更新還是先撤銷，要看服務能不能讓新舊密鑰並存。接著查看用量或存取紀錄有沒有異常。換完密鑰不代表所有影響都排除了，還要確認事件通知涵蓋的範圍。
每個小專案都要這樣準備嗎？
看它碰到甚麼資料，還有出問題會影響誰。 只在本機跑、沒有真實機敏資料或密鑰的練習，先簡單記一下就好；有真實資料、付費密鑰或別人在用時，就值得先準備好。就算是本機工具，只要碰到重要資料，一樣要有對應的保護和備份。
有維運團隊的話，先搞清楚誰收公告、誰負責處理，還有你的服務算不算他們管的。責任有分工，不代表你可以不知道找誰。
下次要把 AI 做好的服務交給別人用，先確認自己答不答得出這三件事：我有沒有中、要換哪些密鑰、要更新哪些版本？ 答不出來，就從那份清單開始。
