背景

隨著 AI 輔助編程工具如 Claude Code 的普及，開發者合併由 AI 生成或修改的代碼已成為常態。然而，傳統的 Git 提交紀錄僅保留了最終的代碼差異（diff），卻遺失了產生這些代碼的對話過程與決策脈絡。開源工具 git-memento 試圖解決此問題，透過 Git notes 功能將 AI 對話紀錄與特定提交關聯，引發了開發社群對於「AI 對話紀錄是否應成為代碼資產一部分」的深度辯論。

社群觀點

支持者認為，AI 對話紀錄具備極高的「意圖溯源」價值。在軟體維護的長週期中，開發者往往在數月後難以理解某段代碼的設計初衷，而對話紀錄能揭示當時的假設、嘗試過的錯誤路徑以及最終選擇特定方案的原因。這類資訊被視為一種「決策審計軌跡」，其功能類似於飛機的黑盒子或飛行記錄器。部分觀點甚至大膽預測，未來「對話紀錄」本身將取代代碼成為原始碼（Source of Truth），而代碼僅是該紀錄編譯後的產物。對於企業管理而言，這也能幫助公司理解員工如何與 AI 協作，並評估提示詞工程的效率。

然而，反對聲音同樣強烈且具備實務考量。許多資深開發者指出，AI 對話過程往往充斥著大量無意義的嘗試、錯誤的推論與冗長的廢話，將其併入 Git 紀錄無異於將偵錯日誌或 Google 搜尋紀錄提交到倉庫中，會造成嚴重的資訊噪音。此外，AI 的非確定性特質使得對話紀錄難以像傳統編譯器那樣被重複驗證，即便輸入相同的提示詞，也未必能得到相同的代碼。更嚴重的隱憂在於隱私與安全，開發者在與 AI 對話時可能無意間洩漏敏感資料或客戶資訊，若自動將這些紀錄存入 Git notes 並推送到遠端倉庫，將造成難以挽回的資安漏洞。

在支持與反對之間，社群也激盪出更具建設性的折衷方案。不少留言者建議，與其保存原始的對話紀錄，不如要求 AI 總結對話精華，產出高品質的提交訊息（Commit Message）或設計文件。這種「精煉後的意圖」比原始日誌更具可讀性。也有人提出「計畫導向」的流程，先由 AI 產出架構計畫書並納入版本控制，再進行代碼實作，如此既能保留決策脈絡，又能過濾掉對話中的雜訊。

最後，這場討論也觸及了開發文化的轉變。部分評論憂心地指出，如果開發者因為依賴 AI 而不再閱讀與理解自己提交的代碼，那麼保存再多的對話紀錄也無法解決代碼品質下降的問題。這反映出技術社群對於「猿猴式編程」（Ape Coding）現象的集體焦慮：當開發門檻降低、代碼產量激增時，人類開發者是否還能維持對系統的掌控力，而不僅僅是 AI 產出的搬運工。

延伸閱讀

在討論中，多位參與者提到了與此議題相關的工具與概念：

• Entire：由前 GitHub 執行長創立的公司，旨在重新定義 AI 時代的版本控制與協作。
• Ape Coding：一篇探討 AI 輔助下開發者逐漸喪失深度理解能力的虛構短文，引發廣泛共鳴。
• Boris Tane 的開發方法：一種將研究與計畫文件（plan.md）納入版本控制的實務流程，用以管理 AI 協作的架構決策。
• y (eqtylab)：在 Codex 黑客松中開發的雛型工具，專注於記錄決策意圖的溯源。