我用 AI 做了產品——如何在不破壞現有功能的情況下持續改進

想進一步了解如何使用模型，請參閱 Ailoot 說明文件。

為什麼最昂貴的工作從產品上線後才開始？#

你花一個晚上做出一個 app，發布連結，傳給朋友。它能正常運作。一週後，第一位真正的使用者出現，操作方式稍有不同，結果一半功能就停止運作。你請 Claude 修好它——它修好一處，卻弄壞另一處。這種情況聽起來熟悉嗎？

這時，主要問題就浮現了：產品上線後該怎麼辦？第一個可運作原型帶來的興奮感消退之後，你還是得想辦法維護產品。這可以稱為「成熟大人的氛圍編碼」。建置令人興奮、進展快速；維護則需要冷靜的頭腦：了解自己正在改什麼，並持續掌控變更。多數人會在第二部分失敗，因為沒有人為此做好準備。

一項產業研究分析了 2,444 個團隊超過一百萬次程式碼變更，並計算 AI 開發的支出實際流向何處。結果如下：

「氛圍編碼的隱藏成本」一文會更詳細說明這些數字。那篇文章討論的是你付錢買到什麼；這裡的問題不同：每一美元有 44 美分花在修復錯誤上，而本文要談的就是如何避免這個比例持續上升。用來控制這個比例的工作，就叫做維護。

像成熟大人一樣做氛圍編碼的人，和只是在照看神經網路的人，差別會在產品上線後顯現。前者的程式碼庫逐漸成長，也能持續改善而不破壞既有功能。一個月後，後者的產品則變成到處漏水、讓人不敢碰的裝置。接下來，我會說明如何成為前者。

實際上會壞在哪裡：上線後的 5 種災難#

以下是以 AI 建立的真實產品事後檢討，公開列出數字與日期。把它們想成地雷區地圖——每顆地雷都已經在某人身上引爆，而避開的方法也已知。

這五件事的根本原因都相同。AI 的預設目標是讓東西現在能運作，而不是讓它在一個月後、負載增加時仍安全。你在自己的電腦上開發時看不出差別；等到第一個懷有惡意的陌生人出現，問題才會顯現。

問題不在於沒有親手寫程式碼——很多人都是這樣工作。問題在於沒有問：「資料庫有做好安全保護嗎？」接下來，我會示範一個替你提出這個問題的提示詞。

第一層安全網是 git，以及回到「昨天的狀態」#

Claude 弄壞東西時，你需要一個「回到昨天原樣」的按鈕。技術上，這個按鈕叫做 git，沒有聽起來那麼難。

非程式設計師需要了解的三個詞：

1. 儲存庫——儲存在雲端（通常是 GitHub）的專案資料夾。你的程式碼副本不會只留在自己的電腦上。
2. Commit——一個回復點。你等於是在告訴程式碼：「以這個狀態儲存。」每個 commit 都是可以返回的標記。
3. Deploy——部署。程式碼原本在本機，只能在你的電腦上運作。部署會把它傳到外部伺服器，讓所有人都能使用。

只要有最近的 commit 作為回復點，任何故障都能用一句話還原。真的只要一句話。

我弄壞了某個地方——昨天一切正常，今天卻不行了。找出最近一次一切正常的提交，告訴我之後有哪些變更，並將專案還原到那個狀態。

在產品讓其他人看到之前，請立刻落實兩項規則：

• 儲存庫必須是私人儲存庫。 不要設為公開，否則任何人都能閱讀你的程式碼及其中的所有內容。
• 將機密檔案加入忽略清單。 金鑰、密碼和資料庫存取憑證應放在獨立檔案中（通常是 .env），而且絕不放進儲存庫。在 .gitignore 加入一行 .env，機密就會留在你手上。

另有一篇指南介紹如何在 Claude Code 中安全地還原變更：如何在 Claude Code 中還原變更。沒有回復點就像沒有安全網走鋼索，遲早會摔下來。

/rewind 會還原什麼？又不會還原什麼？#

Claude Code 會在每次變更前對狀態建立快照。/rewind 指令（或連按兩次 Esc）會將檔案和對話都還原到選定的時間點。這很方便：如果你五分鐘前弄壞某個功能，就能回到五分鐘前。

但有個陷阱會讓新手遺失資料。/rewind 不會還原所有東西：

Anthropic 說得很清楚：快照是本機的「復原」按鈕，而 git 是永久歷史紀錄。快照可以補足版本控制，但不能取代它。

對非程式設計師而言，實際的重點是：Claude 剛弄壞某項功能時，/rewind 能救你。但如果它已經刪除資料庫中的一筆資料，或將程式碼上傳到雲端，只有 git 和資料庫備份能還原。因此請保留這兩層：快照用來快速回復，commit 用來保存專案的永久歷史。

如何在不破壞現有功能的情況下持續改進？#

每兩個人就有一個會陷入這種循環。你請 AI 修一個小錯誤。它提出看起來合理的變更；這個變更又弄壞了別的東西。你再請它修新的問題，結果又冒出兩個問題。如此不斷重複。

這種循環會發生，是因為氛圍編碼的結果並不固定。同一個提示詞問兩次，會得到不同的程式碼。因此，每次編輯都可能悄悄改變周邊邏輯：折扣門檻從 10% 移到 12%，或驗證規則的行為改變——你沒有檢查，也沒有收到任何警告。這就叫做邏輯漂移，它會悄悄損害真正帶來收入的項目：價格、存取權限和付款。

有一條避免漂移的規則，簡單到可以貼在牆上：不要提交任何無法逐字向另一個人解釋的程式碼。

實際上，你可以把這條規則整理成一段每次變更可運作程式碼前都能使用的固定指示。它會讓 AI 採取小步驟，並明確展示變更內容。

變更程式碼之前，請先完成以下事項：

將目前正常運作的狀態儲存為獨立的回復點（commit）。

用文字準確說明你打算變更什麼，以及涉及哪些檔案。

只做解決我這項需求所需的最小變更，不要做其他事。

告訴我變更了什麼，並解釋每一項變更，讓我能向其他人說明。
除非我有要求，否則不要碰定價、存取權限或付款邏輯。

另一個能省下數週時間的原則，是嚴格遵守工作範圍。一次處理一個痛點，做一項變更，快速完成實作。不要在一個提示詞裡要求 AI 重寫半個專案。專業開發者有時也會在只需要一個按鈕時，開始打造整個 Uber，然後拖上好幾個月。你不需要這麼做。

我所描述的一切都建立在一件事上：管理脈絡。若要避免 AI 破壞相鄰邏輯，它必須記住專案的規則。

發布前如何檢查變更？#

「在我的電腦上可以運作」和「所有人都能使用」之間，還有新手常跳過的中間步驟：測試副本。它是正式環境的獨立快照，讓你能在真實使用者看到變更之前先行檢查。工作流程如下：

1. 建置並自行檢查變更（development）。
2. 將變更部署到 staging——正式環境的副本，但沒有真實使用者。
3. 執行關鍵情境，確認功能沒有變化。
4. 到這時才部署到正式環境。

產品上線後，這件事很重要，因為每次發布都有風險。小小的程式碼變更就可能破壞帳戶登入。少一項設定就可能讓整個產品停擺。staging 能在不造成後果的情況下抓出問題；在正式環境中，你會失去客戶。

為了避免每次都手動檢查所有內容，可以給 AI 一段提示詞，請它比較新版本和舊版本在關鍵領域的行為。

我準備部署一項變更。請依序檢查產品的主要使用情境，確認每項功能仍和以前一樣正常運作：

新使用者註冊與登入。

付款，以及付款後授予存取權限。

存取權限——一般使用者無法看到其他人的資料或管理區域。

重要的商業邏輯數值（價格、折扣、限制）沒有改變。
如果任何行為和上一個版本不同，請停止並準確告訴我變更了什麼。

你的機密放在哪裡？新手最大的漏洞#

我要詳細說明最大的地雷，因為它造成的產品損失比任何其他問題都多。AI 寫程式碼時，最簡單的方式就是把金鑰放在能立即運作的地方——直接放進瀏覽器會開啟的頁面程式碼裡。開發時你不會注意到差異。但任何傳到瀏覽器的內容，都能被任何人開啟開發者工具讀取。

客戶遭到 $87,500 扣款的創辦人後來說，一個提示詞就能避免這件事。款項最後雖然退回了，但無法退還的手續費和失去的平靜仍然存在。以下就是那段提示詞。

檢查整個專案，確認沒有任何秘密金鑰出現在瀏覽器中：

找出資料庫、付款系統與外部服務的所有金鑰。

確認每把金鑰都只儲存在伺服器的環境變數中，而沒有放在頁面程式碼裡。

檢查專案歷史紀錄——過去是否曾意外把金鑰放進去？
列出所有找到機密資料的位置，並說明每一處需要怎麼處理。

附近的另一顆地雷，是只在瀏覽器端檢查存取權限。如果產品是由頁面程式碼決定要不要「顯示管理區域」，任何人都能繞過這項判斷。存取權限必須一律在伺服器端檢查。資料庫只能將資料回傳給有權取得的人——這就是資料列層級安全性（RLS）的用途，而且每個資料表都必須啟用。

在販售存取權或讓其他人使用之前，請先對產品進行全面的安全稽核。

像攻擊者一樣檢查整個專案，找出安全漏洞：

秘密金鑰是否儲存在會傳送到瀏覽器的程式碼或專案歷史紀錄中？

每個資料庫資料表都啟用了資料列層級安全性（RLS）嗎？存取權限是否在伺服器端檢查，而不只是瀏覽器端？

是否設定了自動資料庫備份？我是否曾確認可以從備份還原？

正式環境資料庫是否與 AI 代理程式執行的環境隔離？
請針對每個項目告訴我是否一切正常，或準確指出需要修正的地方。

另有一篇完整指南介紹氛圍編碼的安全性：如何保護氛圍編碼製作的 app。規則很簡單：在確認之前，一律將 AI 預設做的事視為不安全。

產品要託管在哪裡：託管的階梯#

你不需要一開始就租用自己的伺服器並手動設定——初期這項工作很複雜，會耗掉大量時間。你可以隨產品成長逐步往上走：

1. 免費託管（例如 Vercel）——適合自用、測試和小型專案。如果平台能在你的使用者所在地使用，而且你不儲存他們的個人資料，就可以採用。
2. 一個指令即可部署的平台（Railway）——適合已有後端和資料庫的產品。你只要下一個指令就能部署，不需要設定伺服器。入門門檻很低。
3. 自己的專用伺服器——適合負載很高、需要完全掌控的情況。等達到平台上限後再遷移。

剛上線、又不是程式設計師的話，最簡單的選擇是使用能透過一個指令部署、無須手動設定伺服器的平台。之後再遷移到自己的伺服器。如果你想參考具體範例走完這個流程，請參閱使用 Coolify 將氛圍編碼專案部署到自己的伺服器。

何時該分開 app、資料庫和備份？#

三樣東西不應該全放在同一個籃子裡：app、資料庫和備份。使用者不多時，全部放在一起也沒問題。但什麼時候該分開，有明確的訊號。

• 將 app 和資料庫放在不同機器上。 判斷訊號：尖峰負載時 CPU 和記憶體使用率持續超過 70–80%，請求變慢，而且 app 和資料庫正在爭用相同資源。分開後，你可以強化資料庫而不影響 app，反之亦然。
• 遵守 3-2-1 備份規則。 資料保留 3 份副本，使用 2 種不同類型的媒體，其中 1 份放在異地。這樣能避免硬體故障和勒索軟體造成損失。關鍵是備份必須自動執行。

備份頻率取決於遺失幾個小時的資料會造成多大損失。線上訂閱服務若無法接受遺失一小時付款紀錄，備份間隔必須短於一小時，或使用已驗證的交易日誌與時間點還原（PITR）。依可容忍資料遺失決定間隔，並另行測試恢復服務所需時間。部落格每天備份一次就足夠。邏輯很簡單：決定自己能承受損失多少資料，再據此設定備份。

幫我判斷產品是否該升級到更完善的基礎架構。請逐項檢查並詢問我：

尖峰時段 CPU 和記憶體的負載如何？使用率是否持續高於 70–80%？

資料庫和應用程式是在同一台機器上，還是分開？

是否設定了自動資料庫備份？我是否測試過從備份還原？

是否有一份獨立的環境副本（staging），可在部署前用來檢查？
根據結果，請明確建議哪些維持現狀、哪些先分開，以及原因。

另一個問題是要用代管資料庫，還是自己管理。對小型團隊來說，代管資料庫幾乎總是更好：自管的硬體成本較低，卻會耗掉數小時維護。如果你只有一個人，而且你的產品本身不是基礎架構服務，那些時間的成本會高於伺服器價格的差額。

如何讓維護工作自動進行？#

手動維護很累人。你可以透過兩種方式減輕負擔：監控和巡查代理程式。

監控需要用兩種工具處理兩種不同的工作：

1. 「網站還在線嗎？」——使用 uptime 監控工具（例如 UptimeRobot）。它每隔幾分鐘就會連線檢查產品，如果服務停止就傳送警示。它有免費方案。
2. 「到底是哪裡壞了？」——使用錯誤追蹤工具（例如 Sentry）。它會收集 app 內的錯誤，並指出問題發生的位置和原因。

第一種工具會發現產品停止運作；第二種會告訴你哪項功能出了問題，以及原因。兩者搭配，就能回答：「我會不會在客戶聯絡客服之前就知道服務故障？」

自動化的第二階段是巡查代理程式。想像一間房仲公司：早上七點，AI 代理程式閱讀網站上的詢問，發現預約表單壞了，從程式碼找出原因，並帶回附有說明、可直接套用的修正方案。你檢查後說「可以」，它就會部署。順序很重要：先解決使用者的問題（授予存取權、道歉），再調查原因和金額。

AI 存取正式資料庫還有一項規則：給它唯讀帳戶，並透過中介層隱藏個人資料，讓代理程式看到「姓名」而非某人的真實姓名。如此一來，即使它犯錯，也無法實際刪除或破壞正式資料。上表中代理程式清空正式資料庫的事件，正是缺少這項限制的例子。AI 刪除你的資料庫時該怎麼辦說明了災難發生後的處理方法。

什麼時候該關閉產品？#

最常被低估的維護工作，是知道何時停止維護。大量建置產品的人都有一片專案墓園：做了一個、稍微修修補補，最後就放棄了。這很正常，也不代表失敗。真正的失敗，是因為捨不得花掉的時間，讓沒有人使用的產品拖上好幾個月。

以下是可供判斷的時間門檻：

1. 兩週——足以看出一個點子是否可行。如果第一批真實使用者願意回來，就繼續做。沒有人回應也是一種答案。
2. 三個月——硬性上限。如果三個月後仍沒有起色，就關閉產品。氛圍編碼的速度這麼快，花六個月測試一個點子太久了。

結束專案在心理上很難，所以請把它當成決定，而非感受。放下自己投入心力的專案，就像解僱無法勝任工作的員工：令人不舒服，但繼續留下來的成本更高。

維護，是讓產品持續運作並對人們有用的工作。其他一切——git、備份、監控——都只是工具，幫助你走到產品每天開始替你工作的那一步。

花一個晚上用 AI 建立產品，只完成了一半工作。隨著產品成長，讓它持續運作並保持安全——這才是成熟大人的氛圍編碼。

下一步，前往 Ailoot。