不知不覺，這次的鐵人挑戰賽已經走過一半。
前半段幾乎每天都在實作新功能、處理問題，再把服務部署上線。今天先不做新的功能，也不急著繼續往下一站走，想插播一篇不同的內容：回頭整理這段時間實際使用 Codex Sol、Terra 和 Luna 的心得。
這不是一篇模型規格比較，也不是要替三個模型排高低。我想從前幾次真正完成的功能出發，看看面對不同形狀的任務時，我為什麼會選擇不同模型，以及實際合作後各自帶來什麼感受。
這段期間，我用 Codex 持續替 LINE Cafe Bot 加功能。
它先學會在正確時間提醒我去收藏的咖啡廳，接著記住我喜歡安靜、有插座、適合工作的店；後來又能直接在推薦卡片裡選時間、加入 Google Calendar，最後再補上一個一直看得見的 Rich Menu。
這幾次開發剛好分別使用了 Codex Sol、Terra 和 Luna。
一開始我也很容易把模型想成一條由強到弱的直線：重要的工作用最強的，簡單的工作再往下選。但真的把三個模型放進同一個產品、處理不同功能後，我的想法改變了。
選模型真正要看的，不是功能有多大，而是任務的形狀。
需求還很模糊嗎？過程中有多少取捨？完成條件能不能清楚列出來？工作可以拆成一段一段驗證嗎？這些問題，比「哪個模型排名比較高」更有用。
我第一次明顯感受到 Sol 的價值，是替 Cafe Bot 加入主動提醒。
表面上的需求只是一句話：
週六下午兩點去第二間，提前一小時提醒我。
真正拆開後，卻同時牽涉自然語言時間、Firestore、Cloud Tasks、Cloud Run、OIDC 驗證、LINE Push Message、失敗重試與避免重複通知。
這種任務的麻煩不在某一段程式特別難，而是每個決定都會影響下一段。如果只想到「失敗時要重試」，就可能忘記重試造成重複提醒；如果只確認 Cloud Build 成功，也可能漏掉新版其實還沒有部署到 Cloud Run。
後來做 Rich Menu 時，我又一次選了 Sol。這次程式量不算大，但問題更開放：固定選單到底該放哪些入口？哪些功能一定要留在對話脈絡裡？換圖失敗時怎麼保住舊版？圖片、座標、API、安全與部署要如何一起驗證？
Sol 適合我的地方，不只是能處理更多程式碼，而是能在答案還不明確時，協助我把系統、產品與風險放在一起判斷。
如果一個任務需要先回答「怎樣才算做得對」，而不只是「規格有沒有做完」，我會優先想到 Sol。
提醒功能完成後，我想讓 Bot 記住使用者明確設定的咖啡偏好。
這次需求的邊界清楚許多：定義合法的偏好 key、儲存到 Firestore、擴充 Gemini Function Calling、套用到地圖推薦、補上確認流程與測試，再部署到 Cloud Run。
它不是單檔的小修改，仍然要讀懂既有程式，也要跨資料模型、訊息流程、AI 呼叫和雲端服務整合。但每一步都有明確目的，也能各自驗證。
這正是我使用 Terra 最舒服的地方。
Terra 並不是「少思考的 Sol」。在這次實作裡，它把力氣放在資料模型、流程一致性與可驗證的修改上，沒有因為能做更多，就把第一版變得過度複雜。
例如偏好記憶沒有一開始就偷偷分析聊天紀錄、猜測使用者喜好，而是只保存使用者明確說出口、看得見、改得掉也刪得掉的設定。對產品來說，這樣反而更可靠。
遇到日常但跨模組的功能，要穩定完成讀程式、修改、測試、部署與檢查，我會把 Terra 當成很務實的起點。
接下來的 Datetime Picker，目標非常具體：使用者在咖啡廳推薦卡片上選好時間，Bot 就能找回正確店家，並建立時間不偏移的 Google Calendar 連結。
我可以很清楚地寫出完成條件：
雖然它也碰到 LINE postback、Firestore、時區和 Calendar，但工作可以切成很小的步驟：先讀現有流程，再補 session、訊息處理與測試，最後部署和實機驗證。
這種「知道好結果長什麼樣子，而且每一步都能檢查」的工作，很適合 Luna。
Luna 帶來的不是省略驗證，而是讓驗證成為推進方式。它可以快速處理邊界清楚的小範圍改動；而資料驗證、時區、部署狀態和手機實測，仍然是我自己不會省略的交付條件。
OpenAI 官方文件目前把 Sol 定位為適合複雜、開放式、需要更多分析與打磨的工作；Terra 是日常工作的務實主力；Luna 則適合目標清楚、可重複執行的任務。
放回我的實作經驗，我會這樣理解：
| 模型 | 我會在什麼情況使用 | 這次的實作 |
|---|---|---|
| Sol | 問題模糊、跨很多層、需要判斷與取捨 | 主動提醒、Rich Menu 的設計與安全部署 |
| Terra | 範圍清楚，但需要穩定完成跨模組整合 | 個人偏好記憶 |
| Luna | 完成條件明確，可以拆小並反覆驗證 | Datetime Picker 與 Calendar 流程 |
這不是說同一件事只能交給某一個模型。需求寫得更清楚後，原本需要 Sol 探索的工作，可能就能交給 Terra 或 Luna；反過來，一個看似很小的按鈕，如果牽涉模糊的產品決策、安全邊界和既有系統，也可能需要 Sol。
所以現在選模型前，我會先問自己三個問題：
答案還很模糊，我會從 Sol 開始；需要完成日常而完整的整合，我會選 Terra；規格與驗收條件都很清楚，我會讓 Luna 快速推進。
這四次實作也讓我更確定：選對模型，不等於工作已經完成。
主動提醒要真的等到 LINE 訊息出現；偏好要確認下一次推薦有正確套用；Datetime Picker 要在手機上檢查店名與時區；Rich Menu 的圖片則一定要打開來看，因為檔案成功產生，不代表圖示沒有壓住文字。
模型可以幫我分析、實作和檢查，但最後決定功能能不能交付的，仍然是測試、部署狀態與真實使用流程。
如果要替這段經驗留下一句話，我會寫：
不要先問哪個模型最強；先看眼前的問題，究竟需要探索、整合，還是穩定地重複完成。
iThome鐵人賽
看影片追技術