Rex 雷：AI 協作省下的是決策次數，不只是寫 code 時間
[原始貼文]
先講結論，我剛才把 Claude 從下一次收費開始降為 Pro，不必再用貴貴的 Max 了！為什麼呢？因為這一週下來(圖一)，完成了一個專案，但實際上 Usage 只有使用不到五分之一！如果你看完不留言互動，你出門會遇到淹水！！！
昨天計算了一下這個專案的開發時間，覺得這段經驗很值得記錄，我用 ChatGPT 搭配 Claude Code 協作開發了一個我公司內部要使用的應用，從 6/18 開始，中間休息兩天，到 6/25，共 5 天，每天最少投入 2 小時，最多投入 5 小時，總共大約 20 小時，如果換算成一般全職工作日，大概是 3 個工作天。
3 個工作天聽起來不長，但在 20 小時裡，我不是只做了一個簡單的 CRUD 網站，因為他一點都不簡單！完成及整合了 CRM、會員資料同步、開店平台訂單同步、商品同步、分類與庫存同步、AI 內容工作台、品牌語氣、知識庫、AI 跨模型設定、內容版本管理、跨平台內容改寫、會員 360、LINE 廣播、權限系統、內容合規，以及多輪正式站部署、驗收和文件整理。
喔！還有針對熱銷及滯銷商品的 AI 機會探索，一路從文案、銷售頁、EDM 分眾、Line 分眾訊息自動生成，嚴格遵守選定的法規資料庫，包含生圖及 Gamma 等，直播腳本、分鏡、商品推薦…等功能。
中間當然也處理了不少真實整合問題，像是資料同步不完整、正式站沒有更新到最新版本、某些欄位沒有正確回填、AI 生成內容需要符合品牌規則＆法規限制，LINE 分眾訊息發送流程需要更接近實際使用情境。
在 Vibe Coding 出現之前，找過工程師詢問，至少需要三到四個月的開發期。
■ 真正省下的不是寫程式時間，而是決策次數
如果只看結果，很容易說「AI 真的讓開發變快」，但我現在覺得，這句話只講到表面，更精準地說，AI 協作真正省下的不是單純的寫程式時間，而是三件事：
① 重工成本 ② 上下文理解成本 ③ 決策腦力
其中最關鍵的是第三個，我真正感受到的變化是我不需要每幾分鐘就讀一堆程式碼或內容並做一次決策，我可以把大量的小判斷，透過流程、規則、任務邊界和交接摘要提前設計好。
這樣做可以讓我只需要在真正重要的節點做決策，其他的時間，Claude Code 可以按照規則往前跑，這才是我覺得最省腦力的地方。
我們一天要做的大小決策非常非常的多，從早上起床要穿哪件衣服到午餐要吃什麼，這些都在消耗腦力，但腦力應該放在更有價值的事情上，例如：開發方向與深度，要怎麼判斷與整合，而不是這裡要不要同意 echo？那邊要不要 make this edit？
■ 用 AI 開發，最耗的不是寫程式，而是不斷的判斷下一步
很多人以為 AI 開發最花時間的是寫 code，但實際做過一個稍微長一點的產品後會發現，真正耗人的不是寫 code，而是一直判斷：下一步要做什麼？這個錯誤要不要修？這個功能是不是現在要做？這裡要不要改 schema？這個檔案能不能動？這個結果能不能算完成？要不要 commit？要不要 push？要不要 deploy？要不要開新 task？要不要換新 session？
每一個問題都不大，但如果一天要判斷幾十次，就會很累。像之前用 Claude Chat 搭配 Claude Code，我算過，一天五小時的話，大概要決策 80-120 次。
這就是我說的「決策使用次數」，你的腦不是被一個大決策耗乾的，而是被很多小決策慢慢消耗掉，尤其跟 AI 協作時，AI 很常會把很多事情丟回來讓你決定：要不要繼續？要不要修改？要不要建立檔案？要不要新增欄位？要不要 commit？要不要 deploy？
如果每一步都要人重新判斷，AI 雖然在幫你做事，但你其實一直被打斷，這樣不一定省腦力，只是把寫程式的疲勞，換成決策的疲勞。
■ 所以我後來的目標不是讓 AI 更自由，而是讓它少問我
這是我在這個專案嘗試的一個很重要的轉變！一開始，我會覺得 AI 問我，是安全的，讓 AI 每做一步都確認，好像比較不會出錯。
但久了以後，我發現如果所有事情都問我，效率會很差，因為很多問題其實不值得問，例如能不能 git status？能不能讀 package.json？能不能 grep 某個函式？能不能看 schema？能不能讀 README？能不能跑型別檢查？
這些都是低風險操作，如果讓 AI 每次都停下來問，我就要一直做微小決策，這非常的耗腦！我中風過，腦子能少用就少用啊啊啊啊啊～～～～😅
所以我開始嘗試把任務一開始就寫清楚：哪些操作可以直接做，不需要問我。哪些操作必須先問我。
例如：唯讀檢查可以直接做，讀檔可以，搜尋程式碼可以，跑 build 可以，但修改資料庫不行！push main 不行！deploy production 不行！改 schema 不行！刪資料不行！
這樣一來，AI 不需要一直問我低風險問題，我也不用一直被打斷，身為顧客是上帝的我，只需要在高風險節點做判斷。
這就是省腦力的核心關鍵，不讓 AI 完全自動，而是改成讓 AI 知道什麼事情不用問，什麼事情一定要問。
■ 我把決策分成三種：自動、回報、確認
我把 AI 協作裡的事情分成三個層級。
① 可以自動執行的事
例如讀檔、搜尋、檢查 branch、看 log、跑型別檢查。這些事情風險很低，AI 可以直接做，做完回報就好。
② 可以先做但要回報的事
例如做技術分析、提出檔案修改計畫、列出風險、設計資料流、規劃 UI flow，這些不會直接改變系統，但會影響下一步決策，AI 可以先產出方案，我再判斷。
③ 必須先確認的事
例如修改 schema、建立 migration、push main、deploy、改正式環境、刪資料、批次修改會員資料、改權限模型，這些一旦做錯，重工返工成本比較高，所以一定要停下來問。
這三層分清楚之後，協作就變得很絲滑，因為我不用一直判斷每件小事，低風險操作自動跑，中風險操作先規劃，高風險操作才需要我拍板，這樣我的決策次數就會大幅下降。
■ 我不是每次都在決策，而是在前面設計決策規則
這是我覺得很多人可以學習的地方，靠意志力一直做決策很無腦，但如果在任務開始之前，就先設計決策規則會省事很多。
例如我會寫：本次只做技術實作計畫，不要寫程式，不要修改檔案，不要建立文件，不要 commit / push / deploy / 修改 Prisma Schema / 建立 migration。
這段看起來很囉嗦，但它其實幫我省下很多後續的判斷，因為我就不用在 AI 每次動工時重新想這一步可不可以？
規則已經寫好了，這一輪就是不能動工，所以 AI 只能分析、規劃、列出方案，它不會突然開始改檔案，我也不用一直盯著它有沒有過度設計做過頭。
這是把「即時決策」變成「預先規則」。即時決策很耗腦，預先規則很省腦。
■ 為什麼我的任務指令會寫得很細
很多人第一次看到我給 AI 的任務指令，可能會覺得太長。明明只是要 AI 幫忙規劃一個功能，為什麼要寫這麼多？
但我現在覺得，指令寫得細，不是為了控制 AI，而是為了降低我自己的決策負擔。而且寫得長，其實也只是複製貼上，甚至一起協作幾輪之後，AI 就會自己加上這些規則了。
一份好的任務指令，至少要包含六件事。
① 背景：AI 要知道前面已經完成什麼，不要重新發明一次。
② 已確認的產品決策：哪些方向已經拍板，不要再討論。
③ 本次 Scope：這一輪要做什麼。
④ Non-scope：這一輪明確不做什麼。
⑤ 安全限制：哪些可以直接做，哪些不能做。
⑥ 輸出格式：最後要用什麼結構回報。
這樣 AI 的回答會穩很多，它不會一邊分析、一邊實作、一邊自作主張擴充功能。它會照著任務邊界，產出我真正需要的東西。
所以我現在覺得，AI 協作最重要的不是 prompt 技巧，而是任務設計能力。
你不能只是跟 AI 許願，而是要設計一段又一段的工作流程。
■ 每個 Task 都切小，是為了減少「大腦切換成本」
我現在很習慣把任務切得很小，不是「把 CRM 做完」，而是確認某個欄位為什麼沒有回填，修正某個同步流程，驗證正式站是否已部署到最新版，只改善某個頁面的圖片預覽與送出確認。
這樣做不是因為我喜歡拆 task，而是因為小 task 可以降低大腦切換成本。
大 task 裡面包含了太多決策，資料要不要改？UI 要不要改？API 要不要改？測試怎麼做？部署要不要做？風險在哪裡？
如果一次把這些全部丟進來，人就要一直切換思考模式。
但小 task 很清楚，這一輪只查問題，這一輪只修 UI，這一輪只驗證部署，這一輪只寫計畫。
AI 比較不會亂做，我也比較不需要一直介入，每個小任務只需要少量決策，這就是為什麼看起來任務很多，但整體反而不累。
■ 先 Discovery，再 Coding，是為了避免做錯方向
很多人用 AI 開發是想到、開始寫、出錯、修、再出錯、再修，最後推翻。（我上上週就是這樣，每天 12 小時雷打不動的專案，被我砍掉重練，然後這次花三個工作天做得更好更完整）
我現在比較像是先Discovery，然後思考產品決策，作 Blueprint，讓Claude Code Coding，最後驗收。
我不會一有想法就叫 AI 實作，我會先讓 AI 幫我研究這個問題的根因是什麼？是 UI 問題，還是資料問題？是 API 沒接，還是資料本來就沒同步完整？是使用者流程不清楚，還是功能真的不存在？需不需要改資料庫？會不會影響權限？會不會影響正式環境？是不是應該先做唯讀分析，而不是直接改程式？
這個步驟看起來好像變複雜了，但實際上非常省時間，特別是在 Coding 過程中，我幾乎只要無腦按 enter 就好😂