AI 開發的門檻正在改變：最稀缺的能力不再只是把程式碼逐字打出來，而是能否清楚定義需求、指揮 AI 執行，並判斷成果是否真的可用。對沒有程式背景的學員而言，最快的學習路徑不是先背語法，而是在安全邊界內完成一次從需求、預覽、版本控制到後續部署藍圖的完整閉環。
一套 1.5 小時的語音建站 MVP 教學，價值不在於保證每個人都能做出成熟產品，而在於讓學員親眼看見：自己的口語需求可以被整理成規格、被轉化成可操作介面，最後成為可版本管理的數位資產。這種「完成一次」的經驗，往往比聽十堂工具介紹更能建立真正的行動信心。
▋ Belief：為什麼從語法開始，反而可能讓初學者離成果更遠？
傳統程式教學常從變數、條件判斷與語法規則開始，這對培養工程深度仍然重要，但未必適合一位只剩 1.5 小時、筆電電量有限，而且目標是驗證工作點子的非技術學員。當時間高度受限，教學設計必須先回答：「今天結束前，哪一個成果最值得被完成？」
如果學員真正需要的是一個符合個人工作方式的專案追蹤頁面，那麼一開始就比較十種套裝軟體，容易把注意力耗在功能清單與方案選擇。更有效的方法，是先讓學員直接說出自己的真實情境：要追蹤哪些欄位、最常忘記什麼、希望首頁先看見什麼、哪些資訊不能公開。
AI 降低的是執行門檻，不是思考責任。需求說得越模糊，自動生成得越快，返工也可能越快。
語音輸入的優勢，是讓不熟悉規格文件的人先用自然語言表達需求；它的限制則是口述容易跳躍、遺漏與自相矛盾。因此，語音不是規格的終點，而是需求蒐集的起點。AI 必須把口述整理成可檢查的清單，學員則要負責確認優先順序與限制。
為什麼 MVP 不是「做得陽春」？
MVP 的意思不是隨便做一個不能用的頁面，而是用最小範圍驗證最重要的價值。對專案追蹤網站而言，第一版也許只需要新增項目、查看狀態、更新進度與保留資料；登入、多人權限、通知、自動報表與資料庫整合，都可以在核心流程被證明有用後再加入。
這種做法能保護學員免於「第一堂課就想做完整 SaaS」的認知過載，也符合成本治理。功能越多，不只開發時間增加，測試、資安、維護與後續修改的成本也會同步上升。真正專業的第一版，往往不是功能最多，而是刪得最有理由。
▋ Desire：學員真正想得到的是什麼？
非技術學員通常不是想成為全職工程師，而是想把自己腦中的工作方法變成一個可操作工具。他真正渴望的是掌控感：不必每次等待廠商、不必為了不需要的功能支付整套軟體費用，也能清楚描述問題並與 AI 或工程師合作。
因此，這堂課的教學目標不該只寫「完成網站」，而應包含四個可遷移能力：把痛點轉成需求、把需求分成必要與延後、用驗收情境檢查成果，以及用 GitHub 保存每一版變更。這些能力不只適用於網站，也能用在表單、自動化流程、內部知識庫與客戶管理工具。
- 從消費者變成需求定義者：不再只能從現成工具中挑選最接近的方案。
- 從一次生成變成可迭代開發：知道第一版只是可被檢查與改進的起點。
- 從單一檔案變成版本資產：每次修改都有紀錄，可以回復，也能交接。
- 從工具崇拜變成系統思維：理解前臺、部署、資料庫與權限是不同層次。
▋ Intention：1.5 小時內如何完成一次建站閉環？
第一階段：用語音把需求說清楚
1，先說使用情境：誰會使用、在什麼時候使用、目前卡在哪裡。避免只說「我要一個漂亮的專案管理網站」，改成「我每週要追蹤五類專案，希望首頁能立刻看出逾期、等待與已完成項目」。
2，再說必要欄位：列出名稱、負責人、期限、狀態、下一步等真正會使用的欄位。若是單人版本，就不要提前加入複雜權限；若資料敏感，則必須明確限制不得上傳真實個資到未核准服務。
3，最後定義驗收：用生活化句子描述成功畫面，例如「我可以新增一筆專案，重新整理後仍看得到」「手機寬度下按鈕不會跑版」。驗收句比「做得專業一點」更能指揮 AI。
第二階段：讓 Codex 規劃、開發並即時預覽
人類負責目標、限制與優先順序，Codex 負責拆解工作、產生程式碼、執行檢查與修正錯誤。若系統一次提出七個階段與十多項任務，學員不必逐項理解底層語法，但必須能指出哪些屬於本次 MVP、哪些應移到後續藍圖。
預覽階段不是只看「漂不漂亮」。應依序檢查核心按鈕能否操作、資料是否符合預期、錯誤輸入是否被處理、手機版是否可讀，以及頁面是否包含不該公開的資訊。視覺是驗收的一部分，不是全部。
看見畫面只代表程式跑起來；完成驗收，才代表需求被實現。
第三階段：用 GitHub 完成第一次版本閉環
GitHub 的教學重點不是背指令，而是建立「變更有歷史」的觀念。建立儲存庫後，先確認不包含密碼、權杖、個資與不必要的大型檔案，再提交第一版。提交訊息應說明這一版完成了什麼，而不是只寫「更新」。
完成本地版本與遠端儲存庫後，再畫出後續演進路徑：GitHub 管理版本，Vercel 類服務負責自動部署，Supabase 類服務處理需要登入、多人協作或持久資料的後臺。這三者解決不同問題，不必在第一堂課全部導入。
▋ 如何控制工具與維護成本？
第一版可以優先使用既有帳號、免費額度與靜態網站驗證需求，但「免費」不等於沒有成本。帳號管理、學習時間、網域、部署流量、資料庫、備份與資安責任，都會在專案成長後出現。若網站只供個人短期驗證，靜態頁面可能足夠；若開始儲存客戶資料或提供多人登入，就必須重新評估資料治理與付費方案。
- 低成本驗證：先做本機或靜態預覽，不急著購買網域與資料庫。
- 開始對外使用：補上部署監控、備份、隱私告知與基本安全檢查。
- 開始多人協作：再評估登入、角色權限、資料庫與操作紀錄。
- 成為營運系統：建立責任人、維護週期、故障處理與退出方案。
▋ 教學者如何避免「代做成功、學員不會」？
教學者應刻意把關鍵決策交還給學員：由學員口述需求、選擇 MVP 範圍、親自執行至少一次驗收，並用自己的話解釋 GitHub 保存了什麼。AI 可以代寫程式，但不能代替學員形成判斷。
課程結束前，要求學員完成一張簡短演進卡：下一版只加一項功能；寫下為什麼要加；寫下如何判斷它有用；同時列出一項暫時不做的功能。這張卡能把興奮感轉成下一輪可控行動。
你不必一次做完所有事；你要在限制中完成最重要的閉環。
如果您想把個人經驗、教學流程或企業內部工作方式，轉成能持續迭代的 AI 工具，而不是只停在一次展示，與蔡教練聊聊您的數位轉型需求，一起找出最適合先驗證的 MVP 與治理邊界。
