Vibe Coding 做完產品後，下一步呢？上線前必做的 10 項檢查

用 AI 做產品時，最容易出現一個很有成就感的瞬間：你描述需求、來回調整幾輪，畫面真的出來了；按鈕會動、資料也看起來能送出。

接著很自然地會想問：「那我是不是可以上線了？」

答案通常是：快了，但還沒。

產品「能跑」和「能交給別人使用」之間，差的不是多幾個功能，而是一輪有意識的驗收。因為你自己知道怎麼操作、知道哪些欄位要填、知道哪個資料是測試用；第一個陌生使用者不知道。他只會用自己的方式點、在手機上打開、輸入你沒預期的內容，然後在卡住時決定要不要離開。

這篇給你一套適合 Vibe Coding 專案的上線前檢查。你不需要一次做到企業級，而是先守住「第一位真實使用者不會立刻撞牆」的基本盤。

先釐清：上線不是把網址貼出去

許多人把上線理解成「部署成功，拿到一個網址」。但對產品而言，上線至少包含三件事：

1. 使用者能完成你承諾的核心任務。

2. 重要資料不會因為一次操作就遺失、外流或寫錯。

3. 出錯時，你看得見、知道怎麼處理，也有退回上一版的方法。

你不必等所有功能完美才發布；MVP 本來就是用來學習的。但「功能還不完整」和「核心流程還沒驗收」是兩件不同的事。

最常見的錯誤是一直加功能，卻沒有先確認最短路徑是否順暢。假設你做的是預約工具，使用者能不能從進入網站、看懂服務、選到時段、收到確認？這條路徑比新增深色模式、更多篩選器或一堆動畫都重要得多。

上線前的基本原則：先檢查一條「黃金路徑」

先用一句話寫下你的產品最重要的承諾：

[哪一種使用者] 可以在 [哪個情境] 完成 [一件重要任務]，並得到 [明確結果]。

例如：「第一次來的自由工作者，可以在 3 分鐘內建立一份報價單並匯出 PDF。」

接下來所有檢查，都先圍繞這條路徑。不要一開始測每個角落；先把最重要的入口、操作、結果與後續通知走完。

上線前必做的 10 項檢查

1. 用「新使用者」身份走一次核心流程

不要用已經登入、已有資料的帳號測。請開無痕視窗，或建立一個全新的測試帳號，從首頁開始走。

你要確認的是：

- 一進來是否知道這個產品能幫什麼忙？

- 第一個該做的動作是否明確？

- 註冊、登入或付款流程有沒有卡住？

- 完成後，使用者是否看得懂自己成功了？

如果你在測試時需要靠「我知道它本來應該怎樣」才能走下去，就代表新使用者也可能卡住。把每個猶豫超過 3 秒的地方記下來，通常就是最值得優先修的地方。

2. 在手機上重新走一次，而不是只縮小瀏覽器

多數人第一次看到你的產品，很可能是在手機上。桌機版排得整齊，不等於手機版可用。

請實際用手機打開網址，檢查：

- 主要按鈕有沒有被遮住，是否足夠容易點？

- 文字是否需要放大才能讀？

- 表單鍵盤跳出後，送出按鈕還看不看得到？

- 彈窗、下拉選單、圖片或表格有沒有超出畫面？

- 載入時間是否讓人以為網站壞了？

這一步很樸素，但它常常比再做一個新功能更能提升轉換。

3. 檢查輸入資料：正常、空白、錯誤都要試

AI 幫你生成的表單，通常先處理「理想使用者」：每一欄都剛好填對。但真實世界裡會有空白、錯字、過長文字、重複送出，甚至把 Email 填成電話號碼的人。

至少試這四種情況：

好的錯誤提示不是「Error」或「Something went wrong」，而是告訴使用者：哪裡有問題、怎麼修正、資料是否已經送出。

4. 確認資料真的有被保存，也只有對的人看得到

畫面上顯示「已儲存」，不等於資料真的寫進資料庫。請送出一筆測試資料後，重新整理頁面、重新登入，確認資料仍然存在。

接著換另一個帳號試著查看：

- 是否能看到不屬於自己的資料？

- 修改網址中的 ID，會不會進到別人的頁面？

- 管理者與一般使用者能看的內容是否有差別？

若產品有帳號、名單、訂單、個人資料或付款資訊，這項不能省略。AI 可以協助你檢查程式，但權限與資料邊界仍要用真實帳號測過才算數。

5. 每一個「送出」都要有明確結果與通知

使用者填完表單、建立訂單、預約成功後，最怕的是不知道有沒有成功。

檢查每一個重要動作是否至少有一種確認方式：

- 畫面上有清楚的成功狀態或下一步。

- Email、訊息或後台有收到通知。

- 重新回到頁面時，能看見剛才建立的紀錄。

也別只測成功通知。故意填錯 Email、關掉網路或讓通知服務失敗，確認系統不會假裝一切完成。

6. 把「壞掉時的畫面」也當成產品的一部分

外部服務會斷線、資料可能空白、網址可能打錯。產品不是不會出錯，而是出錯時能不能讓人知道下一步。

至少打開這幾種情境：

- 找不到頁面時，有沒有回首頁或聯絡方式？

- 資料載入失敗時，有沒有重試按鈕？

- 使用者沒有權限時，是不是清楚說明而不是空白頁？

- 第三方服務失效時，是否避免直接把技術錯誤丟給使用者？

你可以請 AI 協助列出錯誤情境與建議訊息，但每一個訊息都要自己確認：使用者讀得懂嗎？知道下一步嗎？

7. 檢查公開資訊：文字、連結、聯絡方式與信任感

產品還沒大規模被使用時，使用者對你的信任多半來自細節。

請逐頁檢查：

- 頁面標題、按鈕、說明文字是否仍有測試字樣、英文預設文案或錯字？

- 隱私權、服務條款、付款說明或取消規則是否符合你的實際做法？

- 聯絡方式是否真的收得到？

- 社群連結、下載連結、分享圖片是否指向正確位置？

若你還在測試階段，也可以坦白標示「Beta 測試中」，並寫清楚如何回報問題。這通常比假裝產品毫無瑕疵更能降低使用者的不安。

8. 確認基本效能，不讓第一屏變成等待畫面

你不一定要把效能優化到極致，但要避免明顯拖慢核心任務的問題。

用一般網路與手機測試首頁、登入後第一頁、主要操作頁。特別注意：

- 首頁圖片或影片是否大到很久才出現？

- 點擊按鈕後，有沒有載入狀態，避免使用者一直重複點？

- 列表資料多一點時，畫面會不會卡住？

- 外部 API 等待過久時，使用者是否有回饋？

如果你不會看技術指標，也可以先用一個簡單標準：在一般手機與網路上，使用者能不能知道系統正在處理，而不是以為它死當。

9. 裝好基本的觀測工具：你得知道使用者卡在哪裡

發布不是交卷，而是開始收集真實使用資料。至少先準備三種訊號：

1. 行為數據：有多少人進入、完成註冊、完成核心任務。

2. 錯誤訊號：哪個頁面或哪種操作最常失敗。

3. 主觀回饋：使用者在哪一步困惑、期待什麼、願不願意再回來。

不需要一開始塞滿所有分析工具。先定義一個最重要轉換，例如「完成第一份報價單」或「成功預約」，並確定你看得到它的完成次數。否則你只會知道有人來過，卻不知道產品有沒有真的幫上忙。

10. 先準備回滾與求救方式，再按發布

「回滾」聽起來很工程，但意思其實很簡單：新版本出問題時，你有沒有辦法回到上一個可用版本？

上線前，至少回答這四個問題：

- 上一個可用版本在哪裡？

- 如果這次更新壞掉，誰可以處理？

- 最重要的資料有沒有備份或匯出方式？

- 使用者回報問題時，要找誰、從哪裡找？

把這些答案放在一個你找得到的地方。當問題真的發生時，最需要的不是更多靈感，而是一條清楚的處理路徑。

一份可以直接使用的上線前檢查表

在發布前，把以下清單跑一遍。若其中任何一項是「不確定」，先不要把它當成已完成。

【核心體驗】
□ 用全新帳號完成一次核心任務
□ 完成後有明確成功訊息與下一步
□ 在手機上重新完成一次

【資料與權限】
□ 正常、空白、錯誤與重複送出都測過
□ 重新登入後，資料仍存在
□ 不同帳號無法查看或修改彼此資料

【例外處理】
□ 找不到頁面、載入失敗、無權限時有清楚說明
□ 重要通知或 Email 實際收得到

【公開資訊】
□ 沒有測試文字、壞連結、錯誤聯絡方式
□ 隱私、付款與取消規則符合實際做法

【上線後】
□ 能看見核心轉換與基本錯誤訊號
□ 有上一版、資料備份與問題回報管道

別自己測完就算：找 3 個「不會客氣的人」

自己做的產品，最難看見自己的盲點。找 3 位接近目標使用者、但不熟悉你產品的人，請他們各自完成同一個任務。

重點不是問「你覺得好不好看？」而是給一個情境：

「你現在想在 3 分鐘內完成 [核心任務]。請一邊操作、一邊說出你正在找什麼、哪裡覺得不確定。」

過程中先不要教他怎麼按。觀察他在哪裡停下來、誤解了哪一句、忽略了哪個按鈕。三個人中有兩個人在同一處卡住，那通常不是使用者不夠聰明，而是產品需要調整。

AI 在這個階段最適合做什麼？

上線前，AI 很適合當你的 QA 助理，而不是替你宣告「可以發布」。你可以請它：

- 根據產品描述列出可能的邊界情境。

- 將模糊的錯誤訊息改寫成使用者看得懂的說明。

- 幫你產生測試案例與測試資料。

- 檢查畫面文案是否前後矛盾。

- 根據回饋紀錄，把問題整理成修正優先順序。

但「這個產品是否可以交給真實使用者」仍然需要你判斷。因為發布不是程式碼通過，而是你願不願意對使用者的時間、資料與期待負責。

先讓一件重要的事可靠，再慢慢擴大

Vibe Coding 最大的改變，是讓更多人能把想法做成可互動的產品；而產品真正開始有價值的時刻，是有人能在不需要你站在旁邊教的情況下，把事情完成。

上線前的檢查，不是要把你拖回漫長開發，而是把有限時間放在最值得修的地方：核心流程、資料邊界、錯誤處理與真實回饋。

下一次想按下發布前，先問自己：**一個第一次來、用手機、在忙碌中操作的人，能不能安心完成最重要的那件事？** 如果答案還不確定，就從這 10 項檢查開始。