在 AI 時代，最有效減少衝突的方法，是避免一次性產生大量且廣泛的變更。

• Small & Frequent Commits / PRs：將任務拆解為極小的單元，AI 幫你寫完一個小 Function 就立刻測試、送出 PR。要求每個 PR 只做一件事（例如：單一功能實作、單一 Bug 修正）。

  限制 AI 的變更範圍（Scope Control）：在給 AI 的 Prompt 中明確限制修改的邊界（例如：「只針對 X function 進行修改，不要動其他程式碼與格式」）。這能有效避免 AI「順手」重構不相關的程式碼，減少無意義的 Line Conflicts。

• 格式化與邏輯分集 Commit：如果 AI 重構了程式碼格式或變數命名，這些純排版類的變更應獨立為一個 Commit (e.g., "refactor: apply formatting")，邏輯變更則為另一個 Commit (e.g., "feat: implement user auth logic")。這樣在 Code Review 或 Git Compare 時，可以利用 git blame -w（忽略空白變更）快速對比核心邏輯差異。

AI 生成的程式碼，其責任歸屬不能模糊不清。提交者必須視同程式碼為自己親手所寫。

• 「誰 Submit，誰負責」原則：用 AI 工具提交 Code 的人，必須負責該程式碼的品質、解釋其運作邏輯，並處理後續可能發生的 Bug 或衝突。不能以「這是 AI 寫的」作為推卸責任的藉口。
• PR 描述聚焦意圖與變更影響：與其在 Commit Message 中標註 AI 工具與冗長 Prompt，更重要的是在 PR 描述中清晰說明「為什麼這樣改」、「解決了什麼問題」、「影響了哪些模組」以及「主要變更了哪些邏輯」。這有助於 Reviewer 快速理解變更的商業意圖與架構影響，而非逐行檢查語法。

feat: 實作使用者驗證 API

Co-authored-by: Claude 3.5 Sonnet <ai-assistant>
Prompt/Context: 依據 Issue #102 要求實作 JWT 驗證邏輯

因為人類不一定能 100% 讀懂 AI 寫出的每一行程式碼，測試（Tests）就是最終的真理，但前提是測試本身是可靠且經過人類審查的。

• 真人把關核心測試：核心商業邏輯的單元測試與整合測試，最好由人類設計，或至少經過人類仔細審查。這能避免 AI 在寫實作的同時也寫出「只會驗證自己錯誤實作」的測試。真人在意的迴歸測試（Regression Tests） 是最高標準。
• 嚴格的 CI/CD 防線：所有程式碼變更，無論來源是 AI 或真人，都必須在合併前由 CI 自動執行完整的測試套件。這是確保商業邏輯不會被破壞的關鍵。如果測試覆蓋率不足，再頻繁的測試也形同虛設。
• 測試作為衝突裁決者：當衝突發生，無論是真人或 AI 解決合併後，只要能通過真人的測試案例，就能確保程式碼在商業邏輯上是正確且可接受的。

傳統 Git 以「文字行數（Line-based）」判斷衝突，面對 AI 生成的大量程式碼容易無所適從。此時，AI 的價值在於「解釋」而非「自動解決一切」。

• 利用 AI 擔任「衝突翻譯官」：當衝突發生時，開發者可以將 Git 衝突區塊直接丟給 AI 助手（如 IDE 內建的 Copilot 或 Claude 等），請 AI 讀取兩邊分支的內容與 Git Log，解釋衝突雙方的意圖與差異。

「這一段衝突中，A 分支試圖做什麼？B 分支試圖做什麼？請用三句話說明兩者的差異與意圖。」

• 由真人判斷並下合併指令：在 AI 協助解釋後，真人開發者根據對商業邏輯的理解，明確指示 AI 如何合併：「保留 A 分支的 XX 邏輯，並融入 B 分支的 YY 效能優化，幫我寫出合併後的程式碼。」AI 專門的語意化合併工具（如 SemanticMerge）在生態支援上已較為過時，實務上直接透過 AI 助手理解與輔助修改更為可行。

「縮短 Branch 壽命、小步快跑（Short-lived Branches / Trunk-Based Development）」是應對 AI 程式碼衝擊最有效的一招。然而，這招並非萬靈丹，它有幾個重要的前提：

• 成熟的 CI/CD 流程：必須有完整且穩定的 CI/CD 流水線，確保每次合併都能自動跑完所有測試，並能快速部署。否則，頻繁合併反而可能導致主幹（Main/Master）分支頻繁處於不穩定狀態。
• Feature Flags (功能開關)：透過功能開關，即使將尚未完成或有風險的功能合併到主幹，也能透過配置來控制其開啟與關閉，避免影響線上用戶。這是讓 Trunk-Based Development 更安全的關鍵。
• 任務拆解能力：雖然 AI 擅長一次性生成大量程式碼，但要實踐小步快跑，開發者仍需具備將大任務拆解成細小、可獨立完成單元的能力，並刻意限制 AI 的每次變更範圍。

為甚麼這招最管用？

• 降低影響範圍：AI 一次能改 500 行，但如果你每改 20 行就 Merge 一次，衝突頂多就是 2 行；如果放了三天改了 10 萬行才 Merge，衝突就是災難。
• 減少「黑盒子」記憶負擔：AI 改完立刻測、立刻上，大家都還記得這段 Code 的意圖；放太久，連丟 Prompt 的那個人都會忘記 AI 當初為什麼這樣寫。

• PR 審查重質不重量：Review 程式碼時，重點不再是逐字看語法（這些可以交給 Linter 和 AI 輔助），而是確認「架構設計是否合理」、「功能是否符合需求」、「效能與安全性考量是否周全」。人類的戰略性思考與領域知識變得更為重要。
• 團隊需權衡 Code Ownership 與跨模組重構：儘管有 AI 輔助，模組權責劃分（Code Ownership）仍能減少兩個 AI 同時大改同一個檔案的機率。但過度切割可能導致跨模組的重構變得困難。團隊需找到平衡點，或許透過介面導向開發（Interface-First），先定義好介面/API，再由不同成員或 AI 負責其內部實作，以隔離影響。