如何在一個週末建置 MVP：務實的計畫

要在一個週末建置 MVP，請把你的想法縮減為一種使用者的一項工作，在週五晚上寫下來，星期六用 AI App 建置工具建立核心循環，星期日再完成基本功能（保存資料、著陸頁、發布），然後才讓真實的人使用。略過所有無助於回答 MVP 那個核心問題的東西。一個週末足以做出粗略但可運作的版本，但不足以做出完成的產品，這沒有關係。

週末 MVP 是什麼（以及不是什麼）

MVP（最小可行產品）是你能建置出來、用來學習想法是否可行的最小東西。什麼是 MVP完整說明了這個概念。對一個週末而言，這意味著：

• 一種使用者。 不是「自由工作者、代理商與他們的客戶」。
• 一項工作，從頭到尾。 使用者能開始、完成，並取得結果。
• 真實的產品，不是假的示意圖。 它會保存資料、能在手機上使用，並擁有真正的網址。
• 允許粗糙。 設計樸素、設定很少、後台有些手動作業。

它不是完整產品的縮小版，而是驗證你最大假設的那一部分產品。

週末之前：選定要回答的問題

每個 MVP 都在回答一個問題。把它寫下來，因為它決定了要建置什麼：

理想情況下，你在開發前已經與幾位有這個問題的人交談過。如果還沒有，如何驗證 App 構想說明了方法；在週五之前進行幾次對話，會讓整個週末更有價值。

計畫

週五晚上：做決定（2 到 3 小時）

• 寫一句話：「[產品] 幫助 [特定使用者] 完成 [一項工作]，不再受 [目前的痛點] 所困。」
• 列出核心循環的步驟，例如：註冊、貼上職缺說明、取得量身打造的求職信、編輯、複製。
• 列出資料：保存什麼，以及歸誰所有。
• 寫下「本週末不做」清單：設定、團隊、管理後台、電子郵件通知、第二項功能、深色模式。先寫下來，星期六就比較容易說不。
• 為建置工具草擬第一則提示（見下文）。

星期六：建置核心循環

• 上午：用範例資料讓核心循環的第一版運作起來。以小步前進：每則訊息只做一項變更，然後檢查預覽。
• 下午：加入資料庫，讓資料在重新整理後仍然保留，並用真實的輸入親自使用 App。修正阻擋循環的問題，忽略純外觀的部分。
• 晚上：如果使用者需要自己的資料，就加入登入。用兩個瀏覽器、兩個帳號測試，確認彼此看不到對方的資料。

星期日：讓陌生人也能使用

• 上午：簡單的著陸區塊：那一句話、適用對象，以及註冊按鈕。如果你的問題是關於收費，就加入付款功能。
• 中午：在手機上檢查。空白狀態（新使用者在尚未新增任何東西之前看到的畫面）比你想像的更重要。
• 下午：簡短的安全與基本檢查：瀏覽器程式碼中沒有 API 金鑰，沒有會顯示其他使用者資料的頁面。然後發布。
• 晚上：親自把它傳給五到十位相關的人，並附上一個你想得到答案的問題。

略過什麼

感覺必要、但其實可以等的東西：

• 管理後台。 目前直接查看資料庫即可。
• 設定與個人檔案。 使用合理的預設值寫死即可。
• 團隊、角色與邀請。 先做單一使用者帳號。
• 多種定價方案。 一種價格，或免費。
• 超出登入所需的電子郵件流程。
• 整合。 第一次測試時，匯出 CSV 或複製貼上就夠了。
• 完美的設計。 乾淨、易讀就足夠。一致的顏色與良好的間距就能帶來很大幫助。
• 規模。 十位使用者不會對任何東西造成負擔。

給 AI 建置工具的第一則提示

建置一個名為 CoverCraft 的 MVP，服務想應徵工作的初級開發者。核心循環：使用者登入後，貼上職缺說明與自己的履歷文字，選擇語氣（正式或親切），並取得可以編輯與複製的量身打造求職信。使用名為 AI_API_KEY 的密鑰，透過 AI 服務在伺服器端產生信件，絕不讓金鑰暴露在瀏覽器中。每封信都要連同職稱與公司名稱保存在資料庫中；每位使用者只能在簡單的列表中看到自己的信件。加入附一句產品說明與「開始使用」按鈕的著陸區塊。每位使用者每天限制 10 封，並在伺服器端強制執行。設計保持乾淨簡潔，且在手機上運作良好。不要加入設定、團隊或管理後台。

最後一行很重要。AI 建置工具傾向於加入你沒要求的功能，告訴它不要建置什麼，能讓第一版保持精簡。更多說明請參見如何為 AI App 建置工具撰寫提示。

讓週末順利的訣竅

• 每則訊息只做一項變更。 多部分的大型需求較難檢查，也較難復原。
• 每次變更後都要測試，在預覽中以手機尺寸檢查。
• 回復，不要爭辯。 如果某次變更出錯，就回到上一個可運作的版本，並用更清楚的方式重新提問。
• 在做有風險的事情之前使用規劃步驟，例如加入登入或付款。
• 做到八成就停止打磨。 對沒人使用的功能再花力氣打磨最後兩成，是白費的。

常見錯誤

• 沒有問題就開始，因此無法判斷這個週末是否有成效。
• 做兩項功能而不是一項，結果兩項都沒完成。
• 建置「本週末不做」清單上的東西，因為這樣感覺很有生產力。
• 略過資料庫，導致重新整理後一切消失，測試者也失去他們的工作。
• 從未給任何人看。 一個只留在自己手上的週末 MVP，沒有教會你任何東西。
• 問朋友「你喜歡嗎？」 應該觀察真正有這個問題的陌生人實際做了什麼。

何時根本不該開始建置

有時候，一個週末最好不要用來建置。如果這個想法可以用表單、試算表與付款連結來測試，或是為三位客戶手動提供服務，就先這樣做。當價值在於軟體本身時才需要建置：一個工作流程、一項計算，或現有工具無法提供的生成結果。週末過後，如何推出 App 並獲得第一批使用者說明了接下來該做什麼；如何建置 SaaS MVP則說明在想法證明價值之後，如何加入正式的帳號與訂閱。

用 Mythex 建置

Mythex 非常適合週末計畫：你在聊天中描述 MVP，代理程式撰寫程式碼，你在即時預覽中測試，包括手機尺寸的檢視。規劃模式在週五晚上很有用，可以在寫任何程式之前先釐清構想；每次成功的變更都會保存為檢查點，讓你能回復。當你要求保存資料時，Mythex 會為專案加入 Postgres 資料庫。/test 會要求代理程式像使用者一樣在預覽中點擊，並回報故障的流程（App 測試）。發布前，你可以把預覽的分享連結寄給測試者。

有些部分需要你自己處理：使用者的登入採用你選擇的驗證方式，付款使用你自己的 Stripe 帳號，AI 功能使用你自己的模型 API 金鑰。免費方案第一天提供 10 點數，之後每天 5 點；在忙碌的週末，這可能會限制你能建置的量。Pro 方案每月提供 100 點。文件中的從構想到上線的 App流程，也是相似的路徑。

常見問題