AI 專案的第一個月：一份可執行的落地計畫

第一週：定義與基準

1. 選定一個窄任務。不要選「做一個 AI 助理」，要選「把客服工單自動分類到八個類別」。
2. 寫下成功定義：什麼算對、什麼算錯、可接受的錯誤率是多少。
3. 建立 50 題評測集：典型 20、邊界 20、歷史失敗 10。
4. 跑三條基準線：零樣本、少樣本、更大模型。

檢核點：能說出「目前最好的做法達到 X%，我們的目標是 Y%」。做不到就不要進入第二週。

第二週：做出可用的第一版

1. 用四段式結構寫提示，開啟結構化輸出。
2. 實作容錯解析與基本的錯誤處理。
3. 接上日誌：提示版本、模型版本、token 用量、trace_id。
4. 把評測跑成一行指令。

檢核點：能重複執行評測並得到穩定分數；能從日誌撈出任一次執行的完整內容。

第三週：內部試用

1. 做一個最簡單的介面（甚至只是一個命令列工具或內部網頁）。
2. 讓三到五位真實使用者用一週。
3. 每天收集失敗案例並分類。
4. 把失敗案例補進評測集。

檢核點：評測集從 50 題長到 100 題以上，且失敗樣態已經能分成三到五類。

第四週：加固與決策

1. 針對最大宗的失敗樣態改進（改提示、加規則、或調整流程）。
2. 補上三層用量上限與基本告警。
3. 做一次簡單的紅隊測試。
4. 寫一頁決策文件：要不要繼續投入、下一步是什麼。

第一個月要刻意不做的事

• 不要微調——除非基準線已經證明提示做不到。
• 不要建 RAG——除非任務真的需要外部知識。
• 不要做多 Agent。
• 不要自架推理服務。
• 不要一次支援多個任務。

這些都是真實的需求，但都應該由證據驅動，而不是一開始就假設需要。第一個月的目標是建立證據，不是建立系統。

第二個月的分岔

評測分數達標且穩定     → 進入灰度上線，補監控與回滾
分數不夠但失敗有規律   → 針對性改進：RAG（缺知識）/ 微調（缺行為）
分數不夠且失敗很雜亂   → 回到第一週，任務可能定義得太寬
使用者不用            → 問題不在模型，在流程或介面