前言：這一部（Day8-16 到 Day17-23）都在講怎麼「管住」AI，今天談怎麼「跟」AI 一起工作

前面幾天講了很多「防止 AI 犯錯」的具體技巧——分階段委派、要求執行證據、逐輪追問邊界情境。這些方法有效，但也意味著每一輪都要停下來檢查，節奏被切得很細。今天要談一種更接近即時協作的模式：傳統 Pair Programming 裡「Driver 負責打字、Navigator 負責思考方向」這個分工，套用到 AI 協作情境時該怎麼運作。

今日目標

• 理解傳統 Pair Programming 的 Driver/Navigator 分工邏輯
• 認識這個分工套用到人機協作時，角色該怎麼對應
• 學會判斷什麼時候該讓 AI 當 Driver、什麼時候該人自己動手
• 掌握這種即時協作模式跟前面幾天講的「分階段委派」的差異與互補關係

傳統 Pair Programming 的分工邏輯

Pair Programming 的核心分工是：Driver 專注在「把這一行程式碼打出來」的戰術層次，Navigator 專注在「這個方向對不對、接下來該往哪走」的策略層次。兩個角色定期互換，確保沒有人一直悶頭打字而忽略了整體方向，也沒有人一直在旁邊發號施令卻沒有動手實作的手感。

套用到人機協作：人當 Navigator，AI 當 Driver

在 AI coding agent 協作情境下，比較自然的對應是人保留 Navigator 角色，AI 擔任 Driver——人不逐行寫程式碼，但持續判斷「現在這個方向對不對」「這一步是不是該先寫測試」「剛才那個實作是不是走偏了」；AI 負責把具體的程式碼、測試打出來，執行、回報結果。

這個分工跟這系列前面幾天講的「分階段委派」不是互斥的，是同一個精神在不同顆粒度下的展現：分階段委派是把 Navigator 的判斷切成一個個明確的檢查點（先寫測試、貼出失敗證據、再寫實作），Pair Programming 模式則是更即時、更連續的來回——Navigator 不是每輪任務結束才介入，是在 AI 打字的過程中，看到方向不對就隨時喊停,而不是等一大段程式碼生成完才回頭審查。

對照範例

❌ 純粹的「丟需求、等結果」模式：
「幫我實作訂單驗證邏輯。」
[等待 AI 產出一大段完整程式碼]
→ 人在這段時間完全沒有介入，只能在最後一次性審查，
  如果方向從一開始就偏了（例如驗證邏輯放錯了層級），
  要等到最後才發現，重寫成本很高

✅ Navigator 持續介入的模式：
「先寫一個測試，驗證『金額低於門檻該回傳什麼』這個規則。」
[AI 開始寫，人看著它推進]
「等等，這個驗證邏輯你打算寫在 Order 類別裡，
  但我們的規則是驗證邏輯要放在 Service 層，先停一下，
  改成寫在 OrderValidationService。」
[AI 依照方向調整]
→ 方向錯誤在剛冒出苗頭時就被喊停，
  不用等一大段程式碼寫完才發現要整段重來

Navigator 角色的價值，不在於「懂不懂寫程式碼」，在於持續保持對「這個方向符不符合已知規則、業務脈絡」的判斷——這正是 AI 缺乏的東西：AI 沒有這個專案半年後要往哪個方向演進的直覺，人有。

什麼時候該用這種模式、什麼時候不用

即時的 Navigator/Driver 模式，適合用在需要持續判斷方向、規則還沒完全講清楚的情境——例如探索性的功能開發、需求本身還在釐清的階段。如果任務本身很明確、規則已經講得很清楚（像是修一個定義清楚的 bug），分階段委派（Day11 講的方式）反而更有效率，因為不需要每一步都盯著看，可以讓 AI 獨立跑完一輪再回來檢查證據。

今日思考題

回想你上一次跟 AI 協作寫一段複雜邏輯：你是全程盯著它逐步推進、隨時喊停調整方向，還是丟出需求後等它一次產出完整結果再審查？如果是後者，那次協作有沒有出現「方向早就偏了，但到最後才發現」的情況？

今日重點回顧

• 傳統 Pair Programming 的核心分工是 Driver 專注戰術執行、Navigator 專注策略方向
• AI 協作情境下，人適合保留 Navigator 角色，AI 擔任 Driver，持續執行具體程式碼
• 這跟分階段委派是同一種精神在不同顆粒度的展現：即時介入 vs 明確檢查點
• 這種模式適合規則還沒完全講清楚、需要持續判斷方向的情境，明確定義的任務用分階段委派更有效率

明日預告

明天進入第四部：實戰案例。用一次真實的除錯過程，看 AI 寫的測試怎麼掩蓋掉了一個真正存在的 bug。