AI 寫程式很快，不代表產品會更快完成；缺少規格、驗收與回饋閉環，只會更快產生返工。
這套五段流程把核心規格、MVP、快速原型、Cursor 輔助與持續整合串起來，讓非技術負責人也能管理開發品質。
很多人第一次用 Cursor，幾分鐘就做出登入頁、資料表與漂亮按鈕，於是以為產品開發的瓶頸已經消失。幾天後卻發現功能彼此衝突、畫面反覆修改、舊問題修好又重現，團隊開始在對話框裡不停下指令。
真正拖慢產品的，通常不是程式碼寫得太慢，而是沒有人說清楚：替誰解決什麼問題、這一版不做什麼，以及什麼結果才算完成。
AI 不會自動消除混亂；它只會把你原本的清楚或混亂，一起放大。
▋ Belief 信念：程式碼是候選答案，不是完成的產品
在 BDI 模型中，Belief 是團隊共同相信的事實與限制。第一個信念是：產品開發不是把所有想法都變成功能，而是用最低可承受成本，驗證一個值得解決的問題。
第二個信念是：Cursor 產生的程式碼仍須檢查、測試、版本紀錄與使用者驗收。它可以加快施工，不能替產品負責人決定該蓋什麼。
把 Cursor 想成動作極快的施工隊
蓋房子時，怪手挖土很快，不代表房子會更快完成。若沒有用途、格局、承重、管線與驗收圖，挖得愈快，填錯洞的成本愈高。
非技術負責人不必親自砌每一塊磚，但必須守住藍圖、施工順序、驗收標準與變更紀錄。規格不是官僚文件，而是避免所有人各自腦補的共同介面。
▋ Desire 渴望：把「做一個厲害產品」改成可驗證目標
Desire 是想達成的結果。「我要一套專業客戶管理系統」太模糊；「顧問能在會議後建立客戶紀錄、安排下一次跟進，並在首頁看見逾期事項」才具備驗收可能。
有效的需求像在餐廳點餐。只說「做一份好吃的」，廚師再快也可能端出你不吃的食材；說明份量、禁忌、熟度與可接受替代方案，才可能穩定出餐。
因此，不要只告訴 Cursor「幫我做預約系統」，而要說明誰預約、時段如何限制、重複預約怎麼處理、資料失敗怎麼提示，以及送出後必須看到什麼。
產品不是功能總和，而是一段使用者能完成、團隊也能驗收的價值流程。
▋ Intention 行動：建立五段開發閉環
第一段：核心規格
先用一頁說清楚目標使用者、核心問題、價值結果、資料來源、限制、完成條件與排除範圍。規格不必描述所有細節，但一定要寫出「這一版不做什麼」，避免 AI 自動擴張功能。
- 目標使用者：誰實際操作？誰負責購買或核准？
- 核心問題：目前哪一段最耗時、最易錯或最難追蹤？
- 成功結果：完成後能觀察到什麼改變？
- 限制條件：預算、期限、法規、權限與既有系統有哪些邊界？
- 排除範圍：哪些功能留到下一輪？
第二段：最小可行產品
MVP 不是粗糙成品，而是保留一條完整價值路徑。預約服務的 MVP 可以只有選擇服務、挑選時段、填寫聯絡資料與收到確認；會員積分、進階報表與多語言先延後。
每個功能都問三次：沒有它，使用者能否完成核心任務？團隊能否驗證主要假設？延後是否造成不可接受風險？若答案都不支持立即開發，就先不要做。
第三段：快速原型與介面體驗
先用手繪流程、可點擊畫面、靜態網頁或假資料驗證操作，不急著接正式資料庫與付款。請實際使用者完成任務，觀察他在哪裡停住、誤解按鈕或找不到下一步。
UI/UX 不只是顏色漂亮，還包括資訊順序、錯誤提示、手機操作、空白狀態、載入等待與返回路徑。這些狀態若沒有先定義，AI 只會用自己的假設補滿。
第四段：Cursor 語意搜尋與小步修改
不要每次要求 Cursor 重寫整個專案。先用語意搜尋找出相關頁面、資料模型、權限規則、共用元件與既有測試，再要求它解釋目前如何運作。
修改前，請它列出預計更動的檔案、影響範圍、風險與驗證方式；確認後每次只處理一張需求卡。搜尋結果只是線索，不是讓 AI 任意改動整個系統的授權。
- 先找：相關程式、規則、資料與測試在哪裡？
- 再說：用非技術語言解釋目前行為與可能影響。
- 後改：限制修改範圍，一次完成一個可驗收結果。
- 必驗：執行測試，再由人走完核心流程。
第五段：測試、版本控制與持續整合
測試把驗收條件變成可重複檢查的企業資產；版本控制保存每次修改的差異、原因與可回復狀態；持續整合則在程式更新時自動執行檢查、測試與建置。
它們不能保證產品永遠無錯，卻能阻止許多已知問題悄悄進入正式環境。當測試失敗或使用者卡住時，先更新需求卡與規格，再進入下一輪修改，閉環才真正回到起點。
▋ 可直接複製的需求卡
- 需求名稱：用動詞與結果命名。
- 目標使用者：誰會操作這項功能？
- 目前問題：現在如何處理，卡在哪裡？
- 期望結果：完成後能做到什麼？
- 正常流程：從開始到完成依序發生什麼？
- 異常情境：缺漏、重複、逾時、無權限與連線失敗如何處理？
- 驗收條件：哪些可觀察結果出現才算完成？
- 排除範圍：這一輪明確不做什麼？
- 資料與權限：會接觸哪些資料，誰能讀寫或刪除？
- 測試方式：自動測試與人工驗收如何執行？
- 回復方案：失敗時如何退回可用版本？
▋ 九十分鐘啟動流程
- 零至十五分鐘：選一類使用者與一個最痛任務，寫出現況與期望結果。
- 十五至三十分鐘：完成核心規格、資料來源、限制與排除範圍。
- 三十至四十五分鐘：切出一條完整 MVP 路徑，其他想法移到候選清單。
- 四十五至六十分鐘：做低成本原型，找一位接近目標使用者的人操作。
- 六十至七十五分鐘：交給 Cursor 搜尋相關程式並提出小步修改方案，不立即大改。
- 七十五至九十分鐘：定義測試、人工驗收、版本紀錄與失敗回復。
九十分鐘的目標不是完成產品，而是留下下一位成員也看得懂的決策資產。若核心問題仍說不清楚，就停在規格階段，不要用程式碼掩蓋決策空白。
▋ 成本與投資報酬：不要只看 Cursor 訂閱費
總成本包括工具訂閱、規格整理、原型、程式審查、測試維護、版本管理、持續整合、雲端服務與資安治理，也包括需求反覆修改、修好一處又破壞另一處的返工。
先記錄導入前後完成同類需求的總工時、返工次數、正式環境錯誤、驗收等待時間與使用者任務完成率。可驗證的節省工時與新增價值，扣除工具、人力、維護與風險成本，才是比較接近真實的投資報酬。
測試會增加短期工作，但能降低每次修改都從頭人工檢查的成本。低風險的一次性原型不必建立過度複雜的測試，高頻且關鍵的功能則值得投資完整回歸檢查。
▋ 不適用情境與資安邊界
醫療判斷、金融交易、公共安全、關鍵基礎設施或高度監管資料，不應由缺乏資格的人只靠 AI 直接上線。需要領域專家、資安、法遵與有經驗工程人員共同審查。
不要把正式資料庫內容、密碼、金鑰、存取權杖或未去識別化的客戶資料貼進對話。測試優先使用假資料，權限採最小必要原則，涉及登入、付款、刪除與資料匯出的程式碼必須由人複核。
若舊系統沒有測試、文件與可回復版本，也不要立刻讓 Cursor 大規模重構。先建立備份、盤點依賴，補上最重要的回歸測試，再進行小步修改。
▋ 結語：高效不是寫得快，而是更快辨認錯誤方向
核心規格說清楚為何而做，MVP 集中最重要假設，原型提早暴露理解差異，Cursor 加速有限範圍實作，測試與版本控制則讓成果可被證明與回復。
真正的開發效率，不是一天產生多少程式碼，而是能否用更小成本修正方向，並讓正確做法留下來、下次繼續使用。
