昨天我們介紹 Replit Free Mode。
它最吸引人的地方是：
日常聊天、規劃與第一版工作，可以先少碰月度 credits。
但今天真正要學的不是：
怎麼把 Free Mode 用到極限。
而是一個更重要的動作：
準備讓 Replit 修改 App 前，先不要讓它改。
先開：
Plan Mode。
Plan Mode 是做什麼的？
一般 Build Mode 裡，
你說：
幫我替客戶管理系統新增搜尋功能。
Agent 可能直接開始：
讀程式、
修改檔案、
新增功能、
測試結果。
Plan Mode 不一樣。
你可以先讓 Agent：
分析問題、
整理步驟、
比較不同方法、
建立 Task List。
但是：
先不修改你的 Code 或 Data。
等你確認計畫，
才進入真正執行。
Replit 官方目前就是這樣定位 Plan Mode：先 Brainstorm、Planning、Review，再開始 Build。
今天只做一個動作
下次準備修改 App 時，
不要第一句就說：
幫我把這個功能做好。
先切到 Plan Mode。
然後輸入：
我要新增這個功能。
先不要修改任何程式或資料。
請先列出：
- 要修改什麼
- 哪些地方不需要修改
- 修改後我要怎麼確認它真的成功
如果還缺少資料，先問我。
等我確認計畫後再開始 Build。
就這樣。
今天真正要學的就是：
先看計畫，再讓 AI 動手。
為什麼這反而比較省？
假設你有一個簡單庫存 App。
現在只想增加：
搜尋商品。
如果直接說：
幫我改善庫存系統，讓它更好用。
這句話範圍太大。
Agent 可能理解成：
重新整理首頁、
修改資料結構、
增加篩選器、
調整表格、
改導航、
順便重做介面。
最後你發現：
「我明明只想加一個搜尋框。」
接著又要再說：
其他改回去。
這才是真正浪費。
不是因為 AI 模型太貴。
而是：
它做了你根本沒有要做的工作。
所以 Plan Mode 第一個要看：它準備改什麼
不要只看 Task List 很完整就直接批准。
先找：
範圍有沒有變大。
你只是要：
新增搜尋。
如果計畫裡突然出現：
重新設計 Database、
更換登入方式、
重做整個 UI，
先不要 Accept。
直接說：
範圍太大。
這次只修改商品搜尋。
不修改資料庫 Schema、登入、導航與其他畫面。
請重新規劃。
這一句非常有用。
因為 AI 最容易發生的不是：
完全不做。
而是：
做太多。
第二個要看：哪些東西不能動
很多人寫 Prompt 只寫：
我要什麼。
卻沒有寫：
什麼不要改。
例如：
在商品列表增加搜尋。
可以再補：
保留目前：
- 商品新增方式
- 商品編號
- 庫存資料
- 使用者登入
- 現有版面
這次不要修改這些部分。
這就是：
保護既有正常功能。
因為一個 App 已經有五個功能可以正常使用，
新增第六個功能時，
真正成功不是：
第六個可以用。
而是：
前五個也沒有被弄壞。
第三個要看：它準備怎麼證明完成
這一步最容易被忽略。
假設 Agent 說：
「新增商品搜尋功能。」
很好。
但是完成標準是什麼？
你可以要求計畫裡先寫：
修改完成後至少測試：
- 輸入完整商品名稱可以找到
- 輸入部分名稱也能找到
- 找不到商品時不會報錯
- 清除搜尋後恢復完整列表
- 原本新增商品功能仍然正常
這樣最後你檢查的不是：
AI 說完成了。
而是：
這五件事情到底有沒有成功。
所以一份好的 Plan，只需要三格
今天不需要搞複雜。
記住：
要改
這次真正新增或修改什麼？
不改
哪些原本正常的地方不能碰？
驗證
做完以後怎麼證明成功？
就這三格。
可以直接複製這個 Prompt
先使用 Plan Mode。
目前不要修改任何 Code、Database 或 Project Data。
我要完成的目標是：
【把我要做的功能寫在這裡】
請先整理成三區：
一、要改
列出為完成這個功能真正需要修改的部分。
二、不改
列出這次不需要碰到的既有功能、資料結構與畫面。
不要自行擴大範圍。
三、驗證
列出修改完成後，我可以實際操作確認的測試步驟。
如果需求不完整、不同做法有重大取捨，或你不確定某個既有功能能不能修改，請先問我，不要自行決定。
先只提出計畫。
等我確認後再開始 Build。
為什麼這特別適合 Free Mode？
Replit 官方現在建議 Free Mode 用在：
發想、
問問題、
規劃、
第一版建置、
小型修改。
而且官方也特別建議：
一個清楚的下一步一次做。
不要一開始把所有可能功能一起塞進同一個要求。
所以最順的工作方法其實可以變成：
先 Plan → 確認範圍 → 再 Build。
不是：
先 Build → 發現錯 → 再叫 AI 重做。
舉一個更完整的例子
假設你做了一個：
小型工作室預約 App。
現在只想新增：
「客戶可以選上午或下午。」
不要說：
幫我改善預約流程。
改成：
使用 Plan Mode。
我要替現有預約 App 增加「上午／下午」時段選擇。
先不要修改程式。
請告訴我：
要改
哪些畫面、欄位或邏輯一定需要修改？
不改
現有客戶資料、登入、通知、其他預約流程都先保持原樣。
驗證
修改完成後我要測試哪些情況，才能確認上午與下午預約都正常，而且舊功能沒有壞掉？
先給我 Plan。
不要開始 Build。
你會先看到 AI 準備怎麼做。
如果計畫有問題，
現在改。
還沒有真正動程式。
什麼情況特別應該先 Plan？
你自己也還沒有想清楚
先討論。
不要讓 AI 猜完就直接做。
已經存在很多功能
修改一個地方可能影響其他地方。
先確認範圍。
涉及 Database
資料一旦改錯，
後果通常比按鈕顏色改錯嚴重。
先 Plan。
涉及登入或權限
先弄清楚誰可以看到、誰可以修改。
涉及付款
更不要直接 Build 完就上線。
先把流程、資料與測試想清楚。
什麼情況不用每次都搞一大份 Plan？
如果只是：
把一段文字改短。
換圖片。
調整按鈕位置。
修一個你已經知道原因的小問題。
就不需要把 30 秒的工作規劃成一個大型專案。
Plan Mode 的目的不是：
讓每件事情變慢。
而是：
在錯方向成本開始變高以前，先看一次方向。
Plan Mode 本身也不是保證
這點一定要分清楚。
Agent 列出一份很漂亮的計畫，
不代表：
計畫一定正確。
它仍可能：
漏掉某個既有功能、
誤解資料結構、
沒有想到 Edge Case。
所以 Plan Mode 的價值不是：
AI 規劃過就可以放心。
而是：
原本看不到的執行方向，現在可以在修改以前先被人看到。
這就是差別。
計畫沒問題後再做什麼？
確認：
要改的範圍正確。
不改的部分清楚。
驗證方式合理。
這時再：
Approve Plan。
Agent 才開始 Build。
Replit 的 Plan Mode 本來就提供先產生 Task List、讓使用者 Review／Revise，再批准開始建置的流程。
如果工作真的很難呢？
那才處理第二個問題：
要不要從 Free 升到 Power 或 Max？
例如只是：
規劃小功能，
Free 可能已經足夠。
開始修改一般既有專案，
可以考慮 Power。
真正遇到：
大型 Codebase、
困難功能、
深度除錯、
Production-grade 工作，
才考慮 Max。
Replit 官方也明確表示，沒有任何一個模式永遠最好；Free 適合開始與探索，Power 偏日常工作與成本平衡，Max 才留給最複雜的工作。
所以順序不要搞反。
不是：
先開 Max，再想要做什麼。
而是：
先把要做什麼規劃清楚，再決定需要多少 AI 能力。
還有一個價格上的實際好處
Replit 官方的成本管理文件甚至直接把 Plan Mode 列為降低 AI 成本的方法之一。
原因並不神祕：
先討論方法，
先縮小範圍，
再批准真正必要的修改，
就比較不容易把 credits 花在：
錯方向、
不需要的功能、
來回重做
上。
所以：
省 credits 最有效的方法，有時不是換更便宜的模型。
而是：
不要讓模型做錯工作。
但有一個方案限制要注意
目前 Replit 官方文件顯示：
Plan Mode 需要 Core。
Starter 免費方案使用者不能直接使用這項功能。
所以如果你使用 Starter，
仍然可以用 Prompt 模擬同樣流程：
先不要修改任何程式。
先只告訴我你準備怎麼做。
等我確認後再開始修改。
雖然這和真正的 Plan Mode 系統狀態不完全相同，
但至少可以先把：
規劃
和：
執行
拆開。
今天只記住這個操作
下一次要 Replit 幫你改 App：
不要先想：
Free？
Power？
Max？
第一個問題先變成：
我要不要先看 Plan？
只要這個修改：
範圍不確定、
可能影響其他功能、
做錯會花很多時間重做，
就先開 Plan Mode。
要求它先回答三件事：
要改什麼。
什麼不能改。
最後怎麼驗證。
看完再 Build。
今天真正要記住的一句話
使用 AI 寫程式最便宜的錯誤，是還沒寫下去以前就把它發現；先看 Plan，再讓 Agent 動 Code。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
