# 我用 AI 做了產品——如何在不破壞現有功能的情況下持續改進 > 產品上線後的安全維護：git、回復、測試環境、機密保護、託管、備份與日常維護。完整保留全部六個提示詞。 Source: https://ailoot.ai/blog/zh-hant-tw/ai-product-maintenance-after-launch/ Canonical: https://ailoot.ai/blog/zh-hant-tw/ai-product-maintenance-after-launch/ Language: zh-Hant-TW Publisher: Ailoot (https://ailoot.ai/) Translation: guide-033 Revision: sha256-ecfb72623d1a1cb6a89eda66fc1f5725044487fcee3f3285350abda7e6883a02 想進一步了解如何使用模型，請參閱 [Ailoot 說明文件](https://ailoot.ai/docs/)。 ## 為什麼最昂貴的工作從產品上線後才開始？
重點摘要 用 AI 建立產品，只是整體工作中較小的一部分。投入 AI 開發的每一美元，只有 18 美分進入完成品，44 美分則用於修復 AI 自己造成的錯誤。這些事都發生在產品上線之後。消耗大部分金錢與心力的是維護，而非建置。
你花一個晚上做出一個 app，發布連結，傳給朋友。它能正常運作。一週後，第一位真正的使用者出現，操作方式稍有不同，結果一半功能就停止運作。你請 Claude 修好它——它修好一處，卻弄壞另一處。這種情況聽起來熟悉嗎？ 這時，主要問題就浮現了：產品上線後該怎麼辦？第一個可運作原型帶來的興奮感消退之後，你還是得想辦法維護產品。這可以稱為「成熟大人的氛圍編碼」。建置令人興奮、進展快速；維護則需要冷靜的頭腦：了解自己正在改什麼，並持續掌控變更。多數人會在第二部分失敗，因為沒有人為此做好準備。 一項產業研究分析了 2,444 個團隊超過一百萬次程式碼變更，並計算 AI 開發的支出實際流向何處。結果如下： | 每一美元的去向 | 金額 | 實際代表什麼 | |----|----|----| | 真正進入產品 | **18 美分** | 使用者確實能使用的功能 | | 修復 AI 錯誤 | 44 美分 | 修正 AI 已寫好的內容，避免產品出問題 | | 重做 | 27 美分 | 重寫 AI 寫出的、不符合需求的程式碼 | | 審查 | 11 美分 | 理解程式碼並找出錯誤 | [「氛圍編碼的隱藏成本」](https://ailoot.ai/blog/zh-hant-tw/vibe-coding-cost-time/)一文會更詳細說明這些數字。那篇文章討論的是你付錢買到什麼；這裡的問題不同：每一美元有 44 美分花在修復錯誤上，而本文要談的就是如何避免這個比例持續上升。用來控制這個比例的工作，就叫做維護。 像成熟大人一樣做氛圍編碼的人，和只是在照看神經網路的人，差別會在產品上線後顯現。前者的程式碼庫逐漸成長，也能持續改善而不破壞既有功能。一個月後，後者的產品則變成到處漏水、讓人不敢碰的裝置。接下來，我會說明如何成為前者。 ## 實際上會壞在哪裡：上線後的 5 種災難
重點摘要 AI 建立的產品會因為一小串常見問題而出狀況：金鑰和資料庫外洩、AI 刪除正式資料，以及陌生人向客戶收費。每種災難都有一項預防措施。
以下是以 AI 建立的真實產品事後檢討，公開列出數字與日期。把它們想成地雷區地圖——每顆地雷都已經在某人身上引爆，而避開的方法也已知。 | 發生了什麼 | 實際情況 | 原本如何避免 | |----|----|----| | **150 萬個金鑰外洩** | 公開的資料庫金鑰直接放在頁面程式碼中，資料庫也未設密碼便開放存取 | 對每個資料表啟用資料列層級安全性（RLS） | | **170 個 app 資料暴露** | app 使用公開金鑰，從瀏覽器直接連接資料庫，且沒有設定存取規則 | 銷售前檢查資料庫存取權限，不要相信預設值 | | **AI 刪除了正式資料庫** | 代理程式獲准存取正式資料庫，即使明令禁止，仍將其刪除 | 將正式資料庫與代理程式執行環境在實體上隔離 | | **瀏覽器中的付款金鑰：\$87,500** | 付款系統金鑰出現在頁面程式碼中；金鑰被找到後，175 位客戶遭到扣款 | 機密只放在伺服器上，絕不放在瀏覽器中 | | **72,000 張照片與文件外洩** | 檔案儲存空間沒有密碼，因此任何持有連結的人都能下載自拍照和身分證件 | 預設要求使用者驗證才能存取檔案儲存空間 | 這五件事的根本原因都相同。AI 的預設目標是讓東西現在能運作，而不是讓它在一個月後、負載增加時仍安全。你在自己的電腦上開發時看不出差別；等到第一個懷有惡意的陌生人出現，問題才會顯現。 問題不在於沒有親手寫程式碼——很多人都是這樣工作。問題在於沒有問：「資料庫有做好安全保護嗎？」接下來，我會示範一個替你提出這個問題的提示詞。 ## 第一層安全網是 git，以及回到「昨天的狀態」
重點摘要 上線後最重要的安全網，是能夠還原任何變更。這裡有兩層防護：git 作為專案的永久歷史紀錄，以及 Claude Code 的本機快照，讓你快速「復原上一步」。在讓其他人使用產品之前，至少要有私人儲存庫，並將機密檔案加入忽略清單。
Claude 弄壞東西時，你需要一個「回到昨天原樣」的按鈕。技術上，這個按鈕叫做 git，沒有聽起來那麼難。 非程式設計師需要了解的三個詞： 1. **儲存庫**——儲存在雲端（通常是 GitHub）的專案資料夾。你的程式碼副本不會只留在自己的電腦上。 2. **Commit**——一個回復點。你等於是在告訴程式碼：「以這個狀態儲存。」每個 commit 都是可以返回的標記。 3. **Deploy**——部署。程式碼原本在本機，只能在你的電腦上運作。部署會把它傳到外部伺服器，讓所有人都能使用。 只要有最近的 commit 作為回復點，任何故障都能用一句話還原。真的只要一句話。
提示詞：還原至可正常運作的版本 ``` 我弄壞了某個地方——昨天一切正常，今天卻不行了。找出最近一次一切正常的提交，告訴我之後有哪些變更，並將專案還原到那個狀態。 ```
在產品讓其他人看到之前，請立刻落實兩項規則： - **儲存庫必須是私人儲存庫。** 不要設為公開，否則任何人都能閱讀你的程式碼及其中的所有內容。 - **將機密檔案加入忽略清單。** 金鑰、密碼和資料庫存取憑證應放在獨立檔案中（通常是 `.env`），而且絕不放進儲存庫。在 `.gitignore` 加入一行 `.env`，機密就會留在你手上。 另有一篇指南介紹如何在 Claude Code 中安全地還原變更：[如何在 Claude Code 中還原變更](https://ailoot.ai/blog/zh-hant-tw/claude-code-undo-changes/)。沒有回復點就像沒有安全網走鋼索，遲早會摔下來。 ## `/rewind` 會還原什麼？又不會還原什麼？
重點摘要 Claude Code 有一個 `/rewind` 指令——它會在每次編輯前建立快照，並將程式碼和對話還原到選定的時間點。但它只會還原 Claude 自己修改的檔案，不會處理已安裝的套件、上傳到雲端的內容、資料庫變更或外部服務呼叫。git 保存永久歷史；`/rewind` 則是快速的本機「復原」。
Claude Code 會在每次變更前對狀態建立快照。`/rewind` 指令（或連按兩次 Esc）會將檔案和對話都還原到選定的時間點。這很方便：如果你五分鐘前弄壞某個功能，就能回到五分鐘前。 但有個陷阱會讓新手遺失資料。`/rewind` 不會還原所有東西： | `/rewind` 會還原 | `/rewind` 不會還原 | |--------------------------------------|-------------------------------------| | Claude 所做的檔案編輯 | 安裝套件（`npm install`） | | 目前工作階段的對話 | 將程式碼上傳到雲端（`git push`） | | 專案的本機狀態 | 資料庫變更 | | \- | 外部服務呼叫與付款 | Anthropic 說得很清楚：快照是本機的「復原」按鈕，而 git 是永久歷史紀錄。快照可以補足版本控制，但不能取代它。

快照是本機的「復原」功能，而 Git 是永久歷史紀錄。快照能補足完整的版本控制，但不能取代它。

— Claude Code 說明文件，https://code.claude.com/docs/en/checkpointing
對非程式設計師而言，實際的重點是：Claude 剛弄壞某項功能時，`/rewind` 能救你。但如果它已經刪除資料庫中的一筆資料，或將程式碼上傳到雲端，只有 git 和資料庫備份能還原。因此請保留這兩層：快照用來快速回復，commit 用來保存專案的永久歷史。 ## 如何在不破壞現有功能的情況下持續改進？
重點摘要 改進產品時最大的危險是邏輯漂移：你請 AI 修一件事，它可能悄悄改動相鄰的邏輯，因為氛圍編碼的結果並不固定。防護方式是一條黃金法則：不要部署自己無法向別人解釋的程式碼。每次只做小幅變更，以 commit 保存，並且一律仔細檢查實際變更內容。
每兩個人就有一個會陷入這種循環。你請 AI 修一個小錯誤。它提出看起來合理的變更；這個變更又弄壞了別的東西。你再請它修新的問題，結果又冒出兩個問題。如此不斷重複。 這種循環會發生，是因為氛圍編碼的結果並不固定。同一個提示詞問兩次，會得到不同的程式碼。因此，每次編輯都可能悄悄改變周邊邏輯：折扣門檻從 10% 移到 12%，或驗證規則的行為改變——你沒有檢查，也沒有收到任何警告。這就叫做邏輯漂移，它會悄悄損害真正帶來收入的項目：價格、存取權限和付款。 有一條避免漂移的規則，簡單到可以貼在牆上：不要提交任何無法逐字向另一個人解釋的程式碼。 實際上，你可以把這條規則整理成一段每次變更可運作程式碼前都能使用的固定指示。它會讓 AI 採取小步驟，並明確展示變更內容。
提示詞：規劃安全的變更 ``` 變更程式碼之前，請先完成以下事項： 將目前正常運作的狀態儲存為獨立的回復點（commit）。 用文字準確說明你打算變更什麼，以及涉及哪些檔案。 只做解決我這項需求所需的最小變更，不要做其他事。 告訴我變更了什麼，並解釋每一項變更，讓我能向其他人說明。 除非我有要求，否則不要碰定價、存取權限或付款邏輯。 ```
另一個能省下數週時間的原則，是嚴格遵守工作範圍。一次處理一個痛點，做一項變更，快速完成實作。不要在一個提示詞裡要求 AI 重寫半個專案。專業開發者有時也會在只需要一個按鈕時，開始打造整個 Uber，然後拖上好幾個月。你不需要這麼做。 我所描述的一切都建立在一件事上：管理脈絡。若要避免 AI 破壞相鄰邏輯，它必須記住專案的規則。 ## 發布前如何檢查變更？
重點摘要 將變更發布給真實使用者之前，請先測試關鍵情境：付款、註冊、存取權限和價格。最好的最終檢查方式，是使用正式環境的測試副本（開發工具中稱為 staging）。流程是：在開發環境建置、在測試副本確認、部署到正式環境。每次發布都有風險；測試副本能消除這些風險。
「在我的電腦上可以運作」和「所有人都能使用」之間，還有新手常跳過的中間步驟：測試副本。它是正式環境的獨立快照，讓你能在真實使用者看到變更之前先行檢查。工作流程如下： 1. 建置並自行檢查變更（development）。 2. 將變更部署到 staging——正式環境的副本，但沒有真實使用者。 3. 執行關鍵情境，確認功能沒有變化。 4. 到這時才部署到正式環境。 產品上線後，這件事很重要，因為每次發布都有風險。小小的程式碼變更就可能破壞帳戶登入。少一項設定就可能讓整個產品停擺。staging 能在不造成後果的情況下抓出問題；在正式環境中，你會失去客戶。 為了避免每次都手動檢查所有內容，可以給 AI 一段提示詞，請它比較新版本和舊版本在關鍵領域的行為。
提示詞：發布前的回歸檢查 ``` 我準備部署一項變更。請依序檢查產品的主要使用情境，確認每項功能仍和以前一樣正常運作： 新使用者註冊與登入。 付款，以及付款後授予存取權限。 存取權限——一般使用者無法看到其他人的資料或管理區域。 重要的商業邏輯數值（價格、折扣、限制）沒有改變。 如果任何行為和上一個版本不同，請停止並準確告訴我變更了什麼。 ```
## 你的機密放在哪裡？新手最大的漏洞
重點摘要 上線後最常見且代價最高的錯誤，是把機密放在頁面程式碼中。資料庫、付款系統和外部服務的金鑰只能存放在伺服器的環境變數中，絕不能放進瀏覽器。這個漏洞已讓一個產品外洩了 150 萬個金鑰，也讓一位創辦人的客戶遭到總計 \$87,500 的扣款。
我要詳細說明最大的地雷，因為它造成的產品損失比任何其他問題都多。AI 寫程式碼時，最簡單的方式就是把金鑰放在能立即運作的地方——直接放進瀏覽器會開啟的頁面程式碼裡。開發時你不會注意到差異。但任何傳到瀏覽器的內容，都能被任何人開啟開發者工具讀取。 客戶遭到 \$87,500 扣款的創辦人後來說，一個提示詞就能避免這件事。款項最後雖然退回了，但無法退還的手續費和失去的平靜仍然存在。以下就是那段提示詞。
提示詞：檢查機密的儲存位置 ``` 檢查整個專案，確認沒有任何秘密金鑰出現在瀏覽器中： 找出資料庫、付款系統與外部服務的所有金鑰。 確認每把金鑰都只儲存在伺服器的環境變數中，而沒有放在頁面程式碼裡。 檢查專案歷史紀錄——過去是否曾意外把金鑰放進去？ 列出所有找到機密資料的位置，並說明每一處需要怎麼處理。 ```
附近的另一顆地雷，是只在瀏覽器端檢查存取權限。如果產品是由頁面程式碼決定要不要「顯示管理區域」，任何人都能繞過這項判斷。存取權限必須一律在伺服器端檢查。資料庫只能將資料回傳給有權取得的人——這就是資料列層級安全性（RLS）的用途，而且每個資料表都必須啟用。 在販售存取權或讓其他人使用之前，請先對產品進行全面的安全稽核。
提示詞：在產品上線後稽核專案 ``` 像攻擊者一樣檢查整個專案，找出安全漏洞： 秘密金鑰是否儲存在會傳送到瀏覽器的程式碼或專案歷史紀錄中？ 每個資料庫資料表都啟用了資料列層級安全性（RLS）嗎？存取權限是否在伺服器端檢查，而不只是瀏覽器端？ 是否設定了自動資料庫備份？我是否曾確認可以從備份還原？ 正式環境資料庫是否與 AI 代理程式執行的環境隔離？ 請針對每個項目告訴我是否一切正常，或準確指出需要修正的地方。 ```
另有一篇完整指南介紹氛圍編碼的安全性：[如何保護氛圍編碼製作的 app](https://ailoot.ai/blog/zh-hant-tw/vibe-coding-security/)。規則很簡單：在確認之前，一律將 AI 預設做的事視為不安全。 ## 產品要託管在哪裡：託管的階梯
重點摘要 產品該放在哪裡，取決於使用者是誰。沒有個人資料的小型專案和測試可以使用免費託管。若產品有資料庫和真實使用者，請選擇可用一個指令部署的平台。負載變高時，再進一步使用自己的伺服器。不要一開始就採用複雜方案。
你不需要一開始就租用自己的伺服器並手動設定——初期這項工作很複雜，會耗掉大量時間。你可以隨產品成長逐步往上走： 1. **免費託管**（例如 Vercel）——適合自用、測試和小型專案。如果平台能在你的使用者所在地使用，而且你不儲存他們的個人資料，就可以採用。 2. **一個指令即可部署的平台**（Railway）——適合已有後端和資料庫的產品。你只要下一個指令就能部署，不需要設定伺服器。入門門檻很低。 3. **自己的專用伺服器**——適合負載很高、需要完全掌控的情況。等達到平台上限後再遷移。 剛上線、又不是程式設計師的話，最簡單的選擇是使用能透過一個指令部署、無須手動設定伺服器的平台。之後再遷移到自己的伺服器。如果你想參考具體範例走完這個流程，請參閱[使用 Coolify 將氛圍編碼專案部署到自己的伺服器](https://ailoot.ai/blog/zh-hant-tw/coolify-claude-code-deploy/)。 ## 何時該分開 app、資料庫和備份？
重點摘要 產品還小的時候，app 和資料庫可以放在同一台機器上。當尖峰負載持續超過 70–80%，或資料庫與 app 開始互相拖慢時，就該分開。備份要遵守 3-2-1 規則：3 份副本、使用 2 種媒體，其中 1 份放在異地。備份必須自動執行，不能等到「想起來再做」。
三樣東西不應該全放在同一個籃子裡：app、資料庫和備份。使用者不多時，全部放在一起也沒問題。但什麼時候該分開，有明確的訊號。 - **將 app 和資料庫放在不同機器上。** 判斷訊號：尖峰負載時 CPU 和記憶體使用率持續超過 70–80%，請求變慢，而且 app 和資料庫正在爭用相同資源。分開後，你可以強化資料庫而不影響 app，反之亦然。 - **遵守 3-2-1 備份規則。** 資料保留 3 份副本，使用 2 種不同類型的媒體，其中 1 份放在異地。這樣能避免硬體故障和勒索軟體造成損失。關鍵是備份必須自動執行。 備份頻率取決於遺失幾個小時的資料會造成多大損失。線上訂閱服務若無法接受遺失一小時付款紀錄，備份間隔必須短於一小時，或使用已驗證的交易日誌與時間點還原（PITR）。依可容忍資料遺失決定間隔，並另行測試恢復服務所需時間。部落格每天備份一次就足夠。邏輯很簡單：決定自己能承受損失多少資料，再據此設定備份。
提示詞：該把伺服器拆開了嗎？ ``` 幫我判斷產品是否該升級到更完善的基礎架構。請逐項檢查並詢問我： 尖峰時段 CPU 和記憶體的負載如何？使用率是否持續高於 70–80%？ 資料庫和應用程式是在同一台機器上，還是分開？ 是否設定了自動資料庫備份？我是否測試過從備份還原？ 是否有一份獨立的環境副本（staging），可在部署前用來檢查？ 根據結果，請明確建議哪些維持現狀、哪些先分開，以及原因。 ```
另一個問題是要用代管資料庫，還是自己管理。對小型團隊來說，代管資料庫幾乎總是更好：自管的硬體成本較低，卻會耗掉數小時維護。如果你只有一個人，而且你的產品本身不是基礎架構服務，那些時間的成本會高於伺服器價格的差額。 ## 如何讓維護工作自動進行？
重點摘要 維護不必全靠人工。兩種監控工具就能涵蓋基本需求：一種檢查網站是否在線，另一種捕捉產品內部錯誤。你也可以設定 AI 代理程式每天早上巡查：閱讀使用者回報、找出故障，並帶回可直接套用的修正方案。但郵件寄送和大量操作應分批處理，不要一次跑完整個資料庫。
手動維護很累人。你可以透過兩種方式減輕負擔：監控和巡查代理程式。 監控需要用兩種工具處理兩種不同的工作： 1. **「網站還在線嗎？」**——使用 uptime 監控工具（例如 UptimeRobot）。它每隔幾分鐘就會連線檢查產品，如果服務停止就傳送警示。它有免費方案。 2. **「到底是哪裡壞了？」**——使用錯誤追蹤工具（例如 Sentry）。它會收集 app 內的錯誤，並指出問題發生的位置和原因。 第一種工具會發現產品停止運作；第二種會告訴你哪項功能出了問題，以及原因。兩者搭配，就能回答：「我會不會在客戶聯絡客服之前就知道服務故障？」 自動化的第二階段是巡查代理程式。想像一間房仲公司：早上七點，AI 代理程式閱讀網站上的詢問，發現預約表單壞了，從程式碼找出原因，並帶回附有說明、可直接套用的修正方案。你檢查後說「可以」，它就會部署。順序很重要：先解決使用者的問題（授予存取權、道歉），再調查原因和金額。
注意 不要一次對整個資料庫執行大量操作。一次寄信給所有人，伺服器會喘不過氣，還可能有一半的信進入垃圾郵件。正確做法是分批處理：每天 100–1,000 封，分散在數小時內寄出。任何客戶資料庫都適用，包括商店、診所或服務。
AI 存取正式資料庫還有一項規則：給它唯讀帳戶，並透過中介層隱藏個人資料，讓代理程式看到「姓名」而非某人的真實姓名。如此一來，即使它犯錯，也無法實際刪除或破壞正式資料。上表中代理程式清空正式資料庫的事件，正是缺少這項限制的例子。[AI 刪除你的資料庫時該怎麼辦](https://ailoot.ai/blog/zh-hant-tw/ai-deleted-database-recovery/)說明了災難發生後的處理方法。 ## 什麼時候該關閉產品？
重點摘要 不是每個產品都值得繼續維護；有些應該關閉。給一個點子兩週時間證明可行性，最長不超過三個月。如果沒有起色，就關閉產品，不管你多捨不得已投入的心力。殺死產品的不是糟糕的程式碼，而是人們停止使用它。每個人都有一片未完成專案的墓園，這很正常。
最常被低估的維護工作，是知道何時停止維護。大量建置產品的人都有一片專案墓園：做了一個、稍微修修補補，最後就放棄了。這很正常，也不代表失敗。真正的失敗，是因為捨不得花掉的時間，讓沒有人使用的產品拖上好幾個月。 以下是可供判斷的時間門檻： 1. **兩週**——足以看出一個點子是否可行。如果第一批真實使用者願意回來，就繼續做。沒有人回應也是一種答案。 2. **三個月**——硬性上限。如果三個月後仍沒有起色，就關閉產品。氛圍編碼的速度這麼快，花六個月測試一個點子太久了。 結束專案在心理上很難，所以請把它當成決定，而非感受。放下自己投入心力的專案，就像解僱無法勝任工作的員工：令人不舒服，但繼續留下來的成本更高。 維護，是讓產品持續運作並對人們有用的工作。其他一切——git、備份、監控——都只是工具，幫助你走到產品每天開始替你工作的那一步。
### 來源 - [Anthropic - Claude Code 中的檢查點](https://code.claude.com/docs/en/checkpointing) - [Anthropic - Claude Code 安全模型](https://code.claude.com/docs/en/security)
花一個晚上用 AI 建立產品，只完成了一半工作。隨著產品成長，讓它持續運作並保持安全——這才是成熟大人的氛圍編碼。 下一步，前往 [Ailoot](https://ailoot.ai/)。 ## 常見問題：我用 AI 做了產品——如何在不破壞現有功能的情況下持續改進 ### 有付款的服務，應多常備份？ 依最多能容忍多少資料遺失決定。若不能接受損失一小時，備份就要比每小時更頻繁，或使用已驗證交易日誌／PITR；也要實測還原多久。 ### 只用 uptime monitor 就能檢查產品健康嗎？ 不能。它只顯示網站是否回應，錯誤追蹤器才會指出應用程式內部故障。發布前在 staging 測重要使用流程，也要確認備份能還原。 ## Ailoot · 公司及其專案組合 Ailoot以累積的營運經驗、廣大的客戶群、穩定的服務及持續的KPI管理為基礎。 公司及其專案組合：數百萬客戶，每月銷售額達數十億。 Ailoot將這些營運經驗用於API存取，讓客戶的產品、代理、應用程式及自動化流程使用AI功能。