這篇文章從 2016 年的 Pair Programming 導讀延伸，重新整理團隊如何一起理解問題、實作與審查。原導讀介紹的是他方的工作方式，不是創科已量測的生產力成果。
AI 能協助產生或解釋程式，但不會自動承擔業務判斷與交付責任。團隊仍需要決定：哪些問題值得即時共同處理，哪些工作適合獨立進行，以及哪些變更需要另一個人的確認。
依任務選擇合作方式
- 人與人結對
- 適合需求仍有歧義、設計取捨多，或需要交接重要知識的任務。一人實作，另一人觀察與提問，並定期交換角色；遠端協作也可採用相同原則。
- 獨立實作與非同步審查
- 適合範圍清楚、可用測試與變更說明表達的工作。要控制變更大小，說明目的與驗證方式，並避免審查排隊成為新的延誤。
- AI 輔助實作
- 適合協助探索、草擬或處理容易驗證的重複工作。使用者仍需理解輸出；涉及權限、資料或關鍵業務規則時，不能只由同一工具自我檢查就算完成。
讓結對真正產生共同理解
開始前先約定問題、時間範圍與期望產出。觀察者不只是等待輪到自己打字，而是檢查假設、提出替代方案並留意驗證缺口。如果一方一直主導，另一方只負責輸入，知識傳遞的效果就值得重新檢視。
高強度協作也需要休息與獨立思考。可以把較難的設計或除錯安排為短段共同工作，其他明確任務各自完成。On Pair Programming討論了遠端結對、角色輪替與協作挑戰，可作為團隊試行時的背景。
為 AI 生成的變更留下可審查的脈絡
審查者需要知道這次變更解決什麼問題、有哪些限制，以及作者實際驗證過什麼。是否用了 AI 可以是工作紀錄的一部分，但不能代替變更說明。特別要留意看似合理但不存在的 API、不必要的新依賴，以及未經確認的邊界行為。
- 先寫明預期行為與不允許的結果，再評估實作。
- 把權限、資料遺失、錯誤處理與回復方式列為重要檢查項。
- 用能讓錯誤實作失敗的測試驗證，而不只確認程式會執行。
- 讓接手者能解釋關鍵設計；若無法說明，就不應只因測試綠燈而合併。
用小範圍試行衡量合作成本
選一類容易反覆出現的工作，試行固定期間。觀察解決問題的總時間、審查來回、返工、交接與參與者的負荷。不能只比較「兩個人同時投入」與「一個人寫完」的當下工時，也不能假定結對必然適合所有任務。
若試行後關鍵知識仍只在同一人身上，可以調整輪替與文件；若協作造成持續中斷，則重新安排任務與共同工作的時段。改善應回到團隊實際遇到的問題。
把責任留在人與流程之間
可先明確約定三件事：什麼變更需要兩人共同判斷、誰可以批准合併，以及什麼情況必須停下來補驗證。工具可以更換，這些責任仍需有人承擔。
延伸閱讀：研發效能與交付品質、持續交付能力。原導讀來源為 Why Every Startup Should Pair Program；本文的 AI 協作討論是本次新增的分析，不歸因於原導讀。