結對編程原本是極限編程（Extreme Programming, XP）中的協作做法。兩位開發者一起處理同一份工作，一位負責操作鍵盤與輸入程式，另一位負責觀察方向、提醒風險、補充背景。這組分工常被稱為駕駛者（Driver）與導航者（Navigator）。
AI 代理人（AI Agent）是一種控制 AI 執行任務的方式。它會先理解開發者交付的目標，再依照指令讀取檔案、修改程式、執行測試，或根據錯誤訊息提出修正建議。它能回答問題，也能在受限制的範圍內協助完成一段開發工作。
和一般問答式 AI 相比，AI 代理人差異在於它可以依照目標連續執行多個步驟。開發者給出任務後，它可以先分析現況，再提出計畫，接著修改檔案並回報結果。這讓 AI 不只提供建議，也能參與部分開發流程。
AI 進入開發流程後，結對的形式開始延伸。開發者可以和 AI 代理人一起工作，由開發者提出需求、補充系統背景、限制修改範圍，再讓 AI 協助產生程式碼、測試草稿、重構建議或替代方案。
這種工作方式讓結對從兩位開發者之間的協作，延伸到單一開發者與 AI 工具之間的協作。
在這個型態裡，AI 代理人像是一個反應很快的草稿產生者。它能快速寫出第一版內容，也能依照錯誤訊息調整程式。
開發者的工作則更接近導航者，需要判斷 AI 是否理解需求、是否遵守架構邊界、是否改到正確區域，以及產出的測試是否驗證到重要行為。
這也是結對編程再次被討論的起點。AI 已經提高輸入程式的速度，團隊需要重新看待結對的價值。
AI 可以快速產生看起來完整的程式碼。它可能包含方法、錯誤處理、測試案例與說明文字。對開發者來說，這會帶來新的壓力，在產出速度提高後，閱讀、理解與判斷也需要一併跟上。
單人與 AI 代理人結對時，開發者可能在短時間內得到大量修改內容。
若每一段修改都沒有被拆開檢查，錯誤假設就有機會快速進入程式碼、測試與文件。需求理解一開始偏掉，AI 生成的內容也會沿著錯誤方向擴大。後續審查才發現問題時，團隊需要花更多力氣還原當時的判斷。
因此，AI 時代的結對需要把注意力放在理解與判斷。開發者要能看懂 AI 產出的設計理由，確認它是否符合目前系統的責任切分、資料流向與業務規則。
程式能執行只是基本條件，團隊還需要知道它能否被維護、能否被測試，以及能否被其他成員接手。
這也讓傳統導航者的角色被重新放大。導航者需要檢查語法、提醒下一步工作，也要協助團隊停下來看清楚 AI 的假設。當 AI 產出速度很快，導航者需要幫助工作維持在可理解的範圍內，讓生成、檢查與修正形成可追蹤的節奏。
人與 AI 結對可以先分成兩個層次來看。
第一個層次是單一開發者與 AI 代理人結對。這種型態適合用來探索需求、產生初版程式、補測試、查找錯誤原因，或快速比較幾種修改方向。它能降低開始工作的門檻，也能讓開發者更快取得候選方案。
第二個層次是兩位開發者一同使用 AI 工具。這時 AI 產出的內容會離開個人工作區，變成兩個人都能檢查的草稿。兩位開發者可以一起調整提示詞（Prompt）、閱讀生成結果、比較替代方案，並把需求理解、架構限制與測試考量說出來。
這兩個層次處理的問題不同。單一開發者與 AI 代理人結對，重點在於提高個人探索與生成速度。兩位開發者一同使用 AI 工具，重點在於讓需求理解、能力傳遞與風險判斷在工作過程中被說清楚。
若團隊只停在單一開發者與 AI 代理人的互動，提示詞、假設與修正理由仍可能留在個人環境裡。
加入兩位開發者共同使用 AI 的場景後，團隊可以在生成過程中看見彼此如何拆解問題、如何檢查風險，以及如何決定保留或放棄某個解法。
單人與 AI 代理人結對時，開發者不需要從空白檔案開始輸入每一段程式。開發者可以先把需求、限制條件、相關檔案與預期行為說清楚，再讓 AI 代理人產生第一版程式碼、測試草稿、重構建議或錯誤修正方向。
這會改變開發者的工作內容。過去開發者主要負責把想法轉成程式碼，現在有一部分輸入工作會交給 AI 代理人。
開發者同時具備駕駛與導航角色，除了撰寫程式，會把更多注意力放在任務切分、上下文提供與輸出檢查上。指令越清楚，AI 代理人越有機會產生接近需求的候選內容。
AI 代理人承接生成工作後，個人開發的起手式也會改變。開發者可以先要求它閱讀相關程式碼，整理目前模組責任，再提出修改計畫。
確認方向後，再要求它進行小範圍修改。這種做法能讓生成工作保留可檢查的節奏。
需要留意的是，AI 代理人產出的內容仍只是候選變更。它能快速補出實作細節，也可能補進團隊尚未確認的假設。
開發者不能只因為程式能執行、能編譯，或測試看起來通過，就直接把結果視為完成。生成速度提高後，判斷責任仍然留在人身上。
當 AI 代理人承接部分生成工作，開發者就需要更像導航者一樣控管方向。這個角色需要在每一步確認 AI 是否理解任務、是否掌握限制，以及是否把修改放在合適的位置。
導航者要先確認需求意圖。開發者可以要求 AI 代理人先重述需求、列出它理解到的業務規則、標示不確定的地方，再開始修改。
這一步能提早看出 AI 是否自行補上未確認的內容。若需求原本就不清楚，開發者也能趁早向產品負責人（Product Owner）或利害關係人確認。
開發者也要控管修改範圍。AI 代理人有時會為了讓結果看起來完整，順手改動相鄰模組、調整測試、改寫命名，甚至加入新的抽象層。
開發者還需要檢查測試是否真的有效。AI 代理人能產生測試，也能依照測試失敗訊息修正程式。測試通過只代表目前測試條件被滿足，仍需要確認測試是否真有偵錯能力，能抓到錯誤行為。
導航者的職責會成為先控管 AI 代理人的理解方向，再控管它能修改的範圍，最後控管驗證訊號是否可信。AI 代理人可以加快生成與修正，工程師仍要確保每一步都有清楚的邊界與檢查依據。
單人與 AI 代理人結對最容易出現的風險，是修改速度超過理解速度。
AI 代理人可以在很短時間內產生多個檔案的變更。開發者若一次接收太多內容，就很難看清楚每個修改背後的原因。這時，錯誤假設會被包進完整的程式結構裡，後續也更難拆解。
把任務拆成小步驟。先讓 AI 代理人分析現況，再產生修改計畫。接著修改一個明確範圍，並執行對應測試。確認行為正確後，再進行整理或重構才是穩妥的做法。
每一個步驟都需要保留檢查時間，讓開發者判斷是否繼續往下走。
檢查點可以放在幾個位置。開始修改前，檢查 AI 代理人對需求與系統背景的理解。產生程式後，檢查變更範圍與架構邊界。測試完成後，檢查測試是否對應需求行為。準備提交前，檢查拉取請求（Pull Request）說明是否交代 AI 協助內容、人工調整內容與主要風險。
這種小步驟工作法能讓單人與 AI 代理人的結對更可控。AI 代理人負責加快探索與生成，人負責設定邊界、判斷結果與保留脈絡。
每一步都有清楚檢查點，後續審查、測試與維護才不會被大量候選變更拖住。
兩位開發者一同使用 AI 工具時，可以先讓 AI 產生一段程式、測試案例、重構建議或錯誤分析，再一起閱讀、檢查與修正。
討論有了具體草稿，成員就能直接指出哪裡需要補充背景、哪裡需要收斂範圍。
單人使用 AI 時，提示詞、生成結果與修正理由常留在個人工作環境裡。其他人到了程式碼審查（Code Review）才看到最後結果，很難知道中間經過哪些假設與取捨（Trade-off）。
兩位開發者一起操作時，AI 為什麼這樣產生、哪裡需要調整、哪個假設需要確認，都可以直接拿出來討論。
這樣的協作可以採用三方工作節奏。
駕駛者負責輸入提示詞與操作整合開發環境（Integrated Development Environment, IDE），把需求、限制與檢查條件轉成 AI 可以執行的指令。
導航者負責審查提示詞與 AI 生成的程式碼或內容差異比較，隨時提醒需求語意、架構邊界、測試缺口與風險。
AI 代理人則作為第三位虛擬成員，快速提供多種演算法、設計草稿或修正方向。
這個流程能讓 AI 的輸出留在共同視野中。駕駛者不會只是自己和 AI 對話，導航者也不會等到程式完成後才開始審查。
兩個人會在提示詞形成、AI 回應、程式修改與測試結果出現的過程中同步參與。知識也會在這些小段落裡被說出來，不會留到最後才補充。
角色也需要定期輪替。建議每 30 到 45 分鐘讓駕駛者與導航者交換位置。原本操作 IDE 與輸入提示詞的人，改成從旁邊審查方向。原本負責口頭審查的人，改成實際操作與下指令。
這種輪替能避免知識只從單一方向流動，也能讓兩個人都擁有輸入上下文、檢查輸出與說明判斷的實務經驗。
兩位開發者一起使用 AI 工具時，可以要求 AI 針對同一個需求產生幾種替代方案。例如一種方案採取小範圍修改，一種方案先補測試保護，一種方案調整模組邊界，一種方案把重複邏輯抽出來。
這些方案不需要全部採用，主要價值在於提供討論材料。
替代方案會促使工程判斷被說清楚。若只看最後選定的作法，新成員很難知道團隊放棄了哪些選項。當兩位開發者一起比較方案，就能討論每個選項的變更範圍、測試難度、維護成本、架構影響與上線風險。
這些內容平常藏在資深開發者的經驗裡，透過比較才會被具體說出來。
這種比較也能幫助團隊避免直接接受 AI 的第一個答案。AI 第一版產出常會選擇看起來最直覺的寫法，直覺寫法未必貼合系統現況。
兩位開發者可以要求 AI 說明不同方案的取捨，再用團隊已知的需求、測試、架構決策紀錄（Architecture Decision Records, ADR）與既有程式碼來檢查。
這些討論會把資深成員的判斷方式攤開。資深成員可以說明為什麼某個方案會增加耦合、為什麼某個設計會讓測試變難、為什麼某次修改應該先縮小範圍。新成員之後遇到相近問題時，也才能自己做出合理選擇。
提示詞討論很適合放進結對工作。兩位開發者一起寫提示詞時，會需要把需求、背景、限制、輸出格式與檢查方式講清楚。這個過程其實是在整理團隊對問題的理解。
例如要請 AI 修改一段訂單狀態邏輯，提示詞不能只寫「修正狀態錯誤」。開發者需要補充哪些狀態可以被轉換、哪些角色有權限操作、失敗時要回傳什麼錯誤、哪些資料不能被更新、需要補哪些測試。這些資訊一旦被寫出來，新成員就能看見系統規則如何影響程式修改。
提示詞討論也能讓團隊提早發現理解落差。兩位開發者在撰寫提示詞時，如果對需求條件、模組責任或測試範圍有不同理解，就會在生成前先被看見。等 AI 產生程式後才發現方向不同，便會多出一輪刪改與重寫。
當提示詞被拿來共同討論，它會成為需求與系統理解的練習材料。
資深開發者可以示範如何把模糊需求轉成可執行條件，測試角色可以補充失敗情境，熟悉系統的人可以加入架構限制。AI 工具因此也能承載團隊練習表達、檢查與判斷的過程。
能力擴散若只依賴課程、分享會或文件，容易和日常開發脫節。
兩位開發者一同使用 AI 工具，就可以把學習放進實際工作中。調整提示詞、閱讀 AI 產出、比較替代方案、確認測試結果，都會讓判斷方式在任務中被看見。
這種做法適合放在風險較高或知識集中度較高的工作上。
例如修改關鍵模組、處理跨系統流程、整理遺留程式、補重要測試，或接手只有少數人熟悉的領域。
兩位開發者一起使用 AI 工具，可以讓熟悉系統的人把判斷說出來，也讓接手的人在真實任務中理解脈絡。
團隊不需要把所有工作都改成兩人一起使用 AI。低風險、範圍明確、已有足夠測試保護的任務，可以由單人與 AI 代理人結對完成。
牽涉需求理解、架構邊界、資料正確性或關鍵流程的任務，適合安排兩位開發者一起處理，讓風險檢查與經驗傳遞放在同一段工作裡。
當這種做法進入日常節奏，團隊會開始累積共同語言。大家會更熟悉如何描述需求、如何限制 AI 修改範圍、如何閱讀 AI 產出，以及如何把判斷寫進拉取請求。
AI 進入開發流程後，提示詞可能變成新的個人資產。某位工程師知道要怎麼描述需求，知道要補哪些上下文，也知道某個模組有哪些限制。
這些內容如果只留在個人的聊天紀錄、筆記或工具設定裡，團隊看起來使用了同一套 AI 工具，實際上仍然依賴少數人的提問技巧與系統記憶。
提示詞會直接影響 AI 的輸出方向。需求描述、系統背景、限制條件、測試要求、命名規則、架構邊界，都可能藏在提示詞裡。
當提示詞沒有被保存，其他成員就很難知道某段 AI 產出是根據哪些條件生成，也很難判斷後續是否能沿用同樣做法。
版本控制不代表把所有一次性對話的提示詞都需要提交。若每一次臨時提問、探索性對話、錯誤排查過程都被提交到儲存庫（Repository），專案很快會充滿雜訊（Noise）。這些內容數量多、脈絡短、重用價值有限，反而會讓團隊規範與模板變得難找。
團隊需要明確區分哪些提示詞值得保存。需要進入版本控制的，多半是系統級指令（System Prompt / Rules）與通用模板。
例如 Claude.md、Agents.md 這類專案 AI 使用規則、測試生成模板、重構檢查模板、拉取請求說明模板。這些內容會長期影響 AI 在專案中的行為，也會影響不同成員使用 AI 時是否遵守同一套規範。
一次性對話提示詞則可以用較輕量的方式留下脈絡。若某次提示詞對正式變更有明顯影響，可以在 拉取請求中簡短說明 AI 協助範圍、主要輸入方向、人工調整內容與驗證結果。這樣審查者能理解 AI 參與了哪些部分，不需要把完整對話紀錄全部放進儲存庫。
提示詞可以依照用途放在合適的位置。測試生成提示詞可以放在測試文件附近，重構提示詞可以和拉取請求說明、測試結果與架構限制放在一起，專案級 AI 規則可以放在儲存庫根目錄或 AI 代理人使用的目錄中。
後續成員接手時，除了最後的程式碼，也能看到團隊希望 AI 依照哪些共同規則工作。
提示詞被保存後，還需要能被審查。AI 開發流程中的審查需要看最後產出的程式碼，也要看輸入給 AI 的條件是否清楚。
提示詞寫得模糊，AI 就會自行補上許多細節。這些內容可能符合常見做法，卻未必符合團隊的業務規則與系統邊界。
提示詞審查可以先從需求清楚度開始看。提示詞是否說明使用者情境、業務規則、成功條件、失敗情境與資料限制，會影響 AI 是否能生成貼近目標的內容。
接著要看限制條件是否足夠。團隊可以檢查提示詞是否標示不可修改的檔案、不可新增的外部套件、需要遵守的架構規則，以及需要補上的測試類型。
對高風險功能來說，也可以要求提示詞明確限制 AI 先提出修改計畫，經過人工確認後再進行程式變更。
提示詞審查也能成為能力擴散的場景。資深開發者可以指出哪些系統背景需要補充，測試人員可以提醒哪些情境沒有被描述，產品角色可以修正業務語意。
團隊一起審查提示詞時，也是在檢查彼此對需求、系統與風險的理解是否一致。
團隊重複使用 AI 一段時間後，會自然長出一些提示詞模板。
這些模板可能用來產生單元測試（Unit Test）、整理需求、分析錯誤、協助重構、撰寫拉取請求說明，或產生文件草稿。模板可以降低使用門檻，也能讓團隊用較一致的方式提供上下文。
模板固定下來後，仍需要定期調整。系統架構會改變，測試策略會更新，團隊規範也會修正。舊模板如果沒有跟著更新，就可能把過期規則繼續帶進新的 AI 產出。
提示詞模板的演化可以連回日常工作。當程式碼審查發現 AI 常漏掉某類錯誤情境，就把這項要求補進測試生成模板。當事故分析發現日誌（Logging）不足，就把可觀測性（Observability）要求補進開發模板。當架構決策紀錄新增了模組邊界限制，也要回頭檢查相關提示詞是否需要更新。
模板需要有清楚的維護入口。團隊可以把常用提示詞模板放在專案儲存庫、工程手冊或內部知識庫中，讓成員在日常工作中透過拉取請求或文件審查提出修改。
人機結對也會出現一些反模式。
第一種是盲目接受（Blind Accept）。開發者看到程式能編譯、測試通過，就直接按下接受全部，或是啟用旁路模式（Bypass Mode），讓 AI 不經確認就修改程式碼。
這時若沒有檢查需求假設、修改範圍與測試內容，AI 產出的錯誤設計就可能被包進正式程式碼裡。
第二種是提示詞通膨（Prompt Inflation）。開發者花了很長時間撰寫超長提示詞，加入大量背景、規則與輸出要求，最後得到的結果卻只是幾行簡單修改。
若同一段工作由人直接完成需要更少時間，團隊就要重新判斷 AI 是否真的降低成本。提示詞應該協助釐清問題，不應讓提示詞撰寫取代工程判斷。
第三種是盲目信任測試結果。AI 可能產生很多測試案例，測試覆蓋率（Test Coverage）看起來很高，內容卻只檢查成功路徑（Happy Path），或使用沒有驗證價值的啞斷言（Dummy Assertions）。
這類測試會讓團隊誤以為功能已經受到保護。開發者仍需要確認測試是否對應真實業務規則、失敗情境、邊界條件與資料限制。
提示詞要避免變成知識孤島，還需要回到團隊流程中。若提示詞只存在於 AI 工具的個人對話紀錄，團隊就很難追蹤它如何影響變更。
即使最後程式碼通過審查，其他人仍然看不到生成過程中的需求假設、限制條件與修正理由。
重要提示詞要和工作項目連在一起。當提示詞用於產生正式程式碼或測試時，可以在拉取請求中簡短說明 AI 協助的範圍、主要提示詞方向、人工調整內容與驗證結果。
這不需要貼出完整對話紀錄，重點是讓審查者知道哪些內容由 AI 協助產生，以及人在哪些地方做了判斷。
團隊也可以建立提示詞知識庫，收斂常用情境的寫法。例如需求澄清、測試生成、錯誤分析、重構計畫、文件整理，都可以有範例提示詞與使用說明。
當提示詞使用脈絡能回到工作項目、拉取請求、文件與知識庫中，AI 使用就不會停留在個人操作層次。
團隊能看見哪些提示詞有效、哪些提示詞容易造成偏差，後續也能依照這些紀錄調整模板。這樣人與 AI 結對才能支援能力擴散，避免新的知識集中藏在每個人的 AI 對話裡。
iThome鐵人賽
看影片追技術