AI 寫的 code,context 要不要進 git?
討論一個我覺得很實際的問題:如果這段 code 是 AI 寫的,那 AI 的 session context 要不要一起進版本控制?
有個工具叫 memento,做法是把 AI coding session 轉成 markdown,然後掛在 git notes 上。commit 本身不變,但 notes 裡面有完整的「當時跟 AI 說了什麼、AI 怎麼回應」的紀錄。
我想了一下,這件事分幾個層面。
可追溯性的價值是真的
fintech 環境裡待久了,對「為什麼這段 code 這樣寫」這種問題有很深的感受。六個月後出了 bug,原本寫這段的人早就離職了,你只能從 git blame 反推意圖,通常反推不出來什麼有用的東西。如果當時的 AI session 還在,你起碼知道「當時考慮過 X 方案,因為 Y 原因選了 Z」,這對除錯是有幫助的。
審計的需求也是真的。有些產業對「為什麼做這個決定」是有法規要求的,不只是工程習慣問題。
但反對派說的也沒錯
HN 上有人說:code 本身就是 truth,能看懂 code 才是正道,session context 只是過程中的噪音。這個論點我部分同意。
問題是 AI 產出的 code 有一個特性:它「看起來正確」的機率比人手寫的更高,但背後可能有完全錯誤的前提。你 review 完覺得沒問題,merged 了,結果三個月後才發現那段邏輯是基於一個錯誤的假設,而那個假設在 session 裡面其實有提到,只是 AI 沒有 flag 出來。
這種情況下,session 紀錄是有 debug 價值的。
實務問題
Session size。一個長一點的 coding session 可能是幾十 KB 甚至更大的 markdown,整個 repo history 會變得很肥。git notes 不在 default fetch 裡面,要另外處理。
機密資訊。Session 裡面可能會夾帶你當時貼進去的 code snippet、API key、架構設計,這些東西你未必想讓所有有 repo 存取權的人看到。
Signal-to-noise ratio 很低。AI session 裡面大量的來回通常不是什麼有意義的決策,是你在反覆叫它修 lint error 或解釋它自己寫的東西。這些進 git notes 的意義不大。
我自己的結論
全量 session 我覺得不太 practical,但「關鍵決策點」的紀錄是有意義的。比如你用 AI 討論出某個架構選擇,或是 AI 提供了一個你本來沒想到的 trade-off 分析,那段對話值得留下來,可以用 commit message 或 PR description 的方式記,不一定要整個 session dump 進去。
工具本身的思路是對的,只是粒度和篩選的問題還需要解。
我現在傾向先把「重要決策摘要」納入 PR 模板,等流程穩了再決定要不要導入完整 session trace。
作者:鍵盤工人