Copilot Pro 心法：月底重置與小型模型比拚（Bakeoff）

如果你使用 GitHub Copilot Pro，有個實用的小技巧：premium 請求額度每月 1 號重置。這表示月末是做「重一點」實驗或 PoC 的好時機，隔天就能滿血復活。

這次我趁月末做了一個「小型模型比拚」。同一份需求，讓不同模型各做幾次實作，不追求上線，只看選擇的技術、工具使用方式，以及在 VS Code 內的端到端體驗。

月末重置：怎麼用

• 額度 1 號重置；把需要多次嘗試的實驗排在月末。
• 準備一份「想試清單」，有空就批次執行。
• 若要跑多堆疊比較，盡量在重置前完成並留存紀錄，隔月再延續。

實驗：快速 bakeoff

相同需求，多模型重跑，讓 Copilot 盡量在編輯器內完成。

我觀察到：

• Grok 選 Flutter，常走 CLI 流程，跨平台支援完整。
• Gemini 2.5 Pro 偏 React Native，但幾次沒完整跑完；推測與 VS Code + Copilot 流程整合仍有摩擦。
• Sonnet 4 選 web + IndexedDB，快速、行動裝置友善，避免原生建置負擔。
• GPT‑5 嘗試多樣；如果不明確鎖定堆疊，重跑的決策會飄，提醒了「約束越清楚，越可重複」。

重點心得

1. 不指定堆疊，模型會替你選，且可能每次不同。若在意穩定，請把語言、框架、套件管理、儲存方案都明確寫出。
2. 先要計畫，再寫碼。5–7 步的計畫能穩定節奏，讓你在關鍵點修正方向。
3. 偏好「編輯器任務」勝過裸命令。請求建立 VS Code tasks / npm scripts，降低環境飄移。
4. 保持短迭代、可重複。以明確驗收標準跑多次小回合，比一次長流程更好比較。
5. 留存產物與自評。程式、日誌、文件與簡短自評，方便客觀比較。

迷你模板

1. 統一規格（功能、非功能、限制、驗收）。
2. 固定輸入：需求、限制（堆疊、套件管理、儲存）、驗收條件。
3. 每模型跑 2–3 次；避免一次過長。
4. 收集：程式、日誌、文件、自評。
5. 評分：設置摩擦、完整性、穩定性、DX。

實用建議

• 月末批次做比較；月初配合重置展開新題。
• 題目與提示越小越尖銳，效果通常更好。
• 用固定模板與系統提示提高一致性。
• 在意結果時，鎖定堆疊細節。
• 要求建立編輯器任務，少用臨時命令。
• 過程即時記錄，避免憑印象判斷。

下次會改進

• 加最小 smoke test（如 Playwright）確保「真的跑起來」。
• 更嚴格的時間盒（10–15 分鐘／回合）。
• 更明確的驗收：例「可新增習慣、勾選、刷新後仍在，顯示連續天數」。

Copilot Pro 的月度重置是小小的節奏槓桿。把較重的探索留到月末，用固定規格做多模型小比拚，再在意結果時鎖堆疊，你會更快得到可靠結論。