如何將 AI 原型推進到正式上線

要將 AI 原型推進到正式上線，你必須縮小「我試用時它能運作」與「其他人使用時它也能持續運作」之間的差距。實際上需要做到五件事：每次修改都測試主要流程、鎖定誰能查看與修改什麼資料、確保在使用者告訴你之前就先得知錯誤、備份資料並證明能夠還原，以及讓應用程式在手機上保持夠快的速度。這些都不需要重寫——它是一份檢查清單，你可以和打造原型的同一個 AI 一起逐一完成。

原型與正式上線：實際上有什麼不同

原型只有一位謹慎的使用者：就是你。你知道該按哪些按鈕，會輸入合理的內容，而且如果出了問題，你只會聳聳肩，請 AI 修好。正式上線則會面對許多粗心的使用者、一些好奇的人，偶爾還有一位懷有敵意的人。程式碼不需要變得「企業級」；它需要能處理原型從未遇到過的情況。

本指南的其餘部分將逐一說明上表的每一項。

步驟一：凍結範圍並寫下主要流程

在加強任何功能之前，先確定第一版包含什麼。列出最重要的三到六個流程，例如「註冊、建立專案、邀請團隊成員、付款」。這些流程將成為你的測試腳本、監控目標，以及每次修改後要檢查的項目。

不在清單上的功能，要麼砍掉，要麼清楚標示為測試版。把四個流程做到穩定，遠比把十四個流程都做好容易得多。

步驟二：像陌生人一樣測試，然後讓測試可重複執行

AI 建構工具很擅長產出在正常情況下能運作的程式碼。正式上線的問題，往往出在非正常的路徑上。請針對每個主要流程測試以下情況：

• 錯誤的輸入：必填欄位留空、輸入 5,000 個字元的名稱、沒有 @ 符號的電子郵件、負數的數量、過去的日期。
• 重新整理與上一頁按鈕：在結帳進行到一半時重新整理；提交表單後按上一頁。是否有任何東西被重複建立？
• 兩個分頁、兩位使用者：用兩個不同的帳號登入，並嘗試透過更改網址中的 ID 開啟對方的頁面。
• 慢速與小螢幕：使用手機大小的螢幕並限制網路速度（瀏覽器的開發者工具可以模擬）。
• 空白狀態：全新的帳號、沒有任何資料。原型通常是用範例資料打造的，沒有資料時就會看起來壞掉。

接著讓檢查可以重複執行。至少要保留一份書面清單，並在每次發布前執行。更好的做法是請 AI 為最重要的流程撰寫自動化測試：

為以下流程新增自動化端對端測試：使用電子郵件註冊、建立專案、邀請第二位使用者，並在 Stripe 測試模式中完成結帳。另外新增測試，確認使用者無法透過更改網址查看或編輯其他使用者的專案。

原型最常缺少的，正是那些證明使用者「不能」做某件事的測試。

步驟三：原型常忽略的基本資安

AI 打造的應用程式，大多數資安問題並不罕見，而是缺少檢查。請逐項檢視以下清單，並參閱更完整的AI 打造應用程式資安檢查清單：

• 伺服器端的權限驗證。隱藏按鈕不等於安全。每一個讀取或修改資料的請求，都必須在伺服器端確認已登入的使用者有權限執行。如果你的應用程式使用具有資料列層級規則的資料庫，請確認這些規則已啟用並經過測試。
• 機密資訊不放在瀏覽器中。付款、電子郵件或 AI 服務的 API 金鑰，應放在伺服器端的環境變數中，絕不能放在前端程式碼裡。如果你不確定這代表什麼，請閱讀什麼是環境變數與機密資訊。
• 伺服器端的輸入驗證。瀏覽器的檢查可以被繞過，因此任何重要的驗證都要在伺服器端再做一次。
• 正確實作登入功能。請使用經過充分測試的驗證函式庫或服務，而不是自行實作密碼儲存。我們的為應用程式加入登入功能指南介紹了各種選項。
• 速率限制：針對登入、註冊、重設密碼，以及任何會寄送電子郵件或呼叫付費 API 的功能。
• 友善的錯誤訊息。使用者應該只看到「發生錯誤」；詳細資訊應記錄在日誌中，而不是顯示在畫面上。
• 更換任何已外洩的金鑰。如果正式金鑰曾經被貼到聊天、程式碼提交或截圖中，請到服務供應商處更換。

一次涵蓋許多面向的提示詞範例：

請針對正式上線的資安審查這個應用程式。檢查每個 API 路由是否都會驗證已登入的使用者擁有其讀取或修改的紀錄、是否沒有將任何機密金鑰傳送到瀏覽器、輸入是否都在伺服器端驗證，以及登入與重設密碼功能是否有速率限制。請先列出你發現的問題，再進行任何修改。

要求先列出清單，能讓你看清問題並決定處理順序，而不是一次收到一個龐大的修改。

步驟四：知道什麼時候出問題——日誌與監控

在預覽中，你可以即時看到錯誤。但在正式環境中，你需要應用程式主動通知你。以下三個層級，由成本最低到最有用：

1. 伺服器日誌。確保錯誤會被記錄，並附上足夠重現問題的資訊：發生在哪個路由、哪位使用者的 ID（不要記錄密碼或卡號）、輸入的資料格式。如果應用程式只會輸出到主控台，請要求 AI 加入結構化的日誌記錄。
2. 錯誤追蹤。Sentry 或類似的服務可以擷取前端與後端的例外狀況、加以分類，並寄送電子郵件通知你。對小型應用程式來說，這些服務的免費方案通常已經足夠；請到官方網站確認最新的用量限制。
3. 可用性檢查。由外部服務每隔幾分鐘載入你的首頁與一個關鍵 API 路由，若失敗就發出警示。這能偵測到那些讓應用程式連日誌都無法記錄的問題。

還要養成另一個習慣：每次發布後，開啟正式上線的應用程式，並在真實網址上執行你的主要流程檢查清單，而不只是在預覽中測試。

步驟五：備份與還原途徑

有兩件不同的事物需要保護，而且很容易搞混。

• 程式碼。將專案保存在版本控制中，讓任何修改都能復原。許多 AI 建構工具會保留你檔案的檢查點；同步到 Git 儲存庫，則能在建構工具之外多留一份副本。
• 資料。復原程式碼並不會復原資料庫。錯誤的資料庫遷移或有問題的刪除按鈕，可能會刪除任何程式碼檢查點都無法找回的資料列。

針對資料，請設定定期備份，並存放在應用程式主機以外的地方。以 Postgres 資料庫來說，常見的做法是排程使用 pg_dump 將備份存到獨立的儲存空間，許多受管理的資料庫主機也提供自動備份或時間點還原功能。然後，請做大多數人會略過的一步：把備份還原到一個暫存資料庫中，並檢查資料是否完整。

也可以請 AI 讓破壞性操作更安全：刪除前加入確認步驟，並對使用者可能想找回的資料採用「軟刪除」（將資料列標記為已刪除，而不是真的移除）。

步驟六：在手機上也能維持的效能

原型之所以感覺很快，是因為只有你一個使用者，而且資料量很小。正式上線前請注意：

• 載入接近真實規模的資料。請 AI 植入數千筆資料，觀察哪些頁面會變慢。清單通常需要分頁，資料庫通常需要為你篩選與排序的欄位建立索引。
• 縮小圖片。過大的圖片是頁面載入緩慢最常見的原因。請要求提供調整尺寸、壓縮過的圖片，並對首屏以下的內容使用延遲載入。
• 實際測量。在手機模式下，於 Chrome 的開發者工具中對正式網址執行 Lighthouse。Google 的 Core Web Vitals 是合理的目標：最大內容繪製（LCP）在 2.5 秒以內，互動至下一次繪製（INP）為 200 毫秒以內，累計版面配置位移（CLS）為 0.1 以內。
• 留意「喚醒」延遲。閒置時會休眠的主機可以節省費用，但在一段時間沒有人造訪後，第一次的載入會比較慢。對新應用程式來說，這通常是可以接受的取捨；但要知道它會發生。

專案頁面在有 5,000 筆資料時很慢。請加入伺服器端分頁（每頁 25 筆）、為我們篩選與排序的欄位加入資料庫索引，並在載入下一頁時顯示載入狀態。

步驟七：營運基本功

有幾件小事，能讓一個業餘的應用程式與一個值得讓人信任的應用程式區分開來：

• 具備 HTTPS 的自訂網域。參見如何連接自訂網域。
• 交易型電子郵件，從已驗證的網域寄出，用於註冊確認與重設密碼，內容請參見如何從應用程式寄送電子郵件。
• 隱私權政策與服務條款，必須如實描述你實際蒐集的資料。不要抄錄你尚未達成的合規聲明。
• 客服管道，即使只是一個有人監看的電子郵件信箱。
• 付款與電子郵件的測試金鑰與正式金鑰分開，並清楚記錄每個環境使用哪一組金鑰。

步驟八：順暢的交接

遲早會有其他人接手這個應用程式：自由工作者、新的共同創辦人，或是六個月後的你自己。請讓這件事變得容易：

• README，說明如何執行、需要哪些環境變數（只寫名稱，絕不寫數值），以及如何部署。
• 主要流程檢查清單與自動化測試。
• 簡短的架構說明：前端、後端、資料庫、第三方服務，以及每一項託管的位置。
• 存取權限清單：誰擁有網域、主機、資料庫、付款與電子郵件帳號的管理員權限。這些帳號應該使用事業電子郵件註冊，而不是個人信箱。
• 程式碼存放在 Git 中，最好同步到你擁有的儲存庫。如果日後可能更換主機，請閱讀如何匯出 AI 打造的應用程式並自行架設。

AI 可以替你草擬大部分的內容：

為這個專案撰寫一份 README，供從未接觸過它的開發者閱讀：說明應用程式的功能、技術堆疊、如何在本機執行、它讀取的每一個環境變數（只寫名稱與用途），資料庫結構如何組織，以及如何部署。

正式上線準備檢查清單

• 主要流程已寫下並經過測試，包括「無法存取他人的資料」
• 每個資料路由都在伺服器端進行權限與輸入驗證
• 前端程式碼中沒有機密金鑰；已外洩的金鑰已更換
• 針對登入與任何會產生費用的功能設定速率限制
• 錯誤追蹤與可用性警示會寄到你會定期查看的信箱
• 資料庫備份存放在應用程式主機以外，並已成功測試過一次還原
• 已用接近真實的資料檢查分頁與索引
• 自訂網域、已驗證的寄件網域、隱私權政策
• 為接手的人準備好 README 與存取權限清單

在 Mythex 中完成這些工作

如果你是在 Mythex 中建立原型，這些步驟大多可以在同一個專案中用提示詞完成。輸入 /test，Mythex 會像使用者一樣在即時預覽中逐一點擊，並回報失效的流程——參見應用程式測試。金鑰會放入專案機密設定中，而不是放在聊天中；每次成功的代理程式回合都會儲存一份你的檔案檢查點，可以隨時還原；發布後你會得到一個正式的網址，主機與資料庫的費用則從同一個點數餘額扣除（主機限制說明了應用程式與資料庫如何休眠與喚醒）。檢查點涵蓋的是檔案，而不是資料庫的資料列，因此仍需自行規劃資料備份。在 Pro 方案中，你可以連接自訂網域，並將程式碼匯出或同步到你自己的 GitHub 儲存庫，以便交接。

常見問題