北京
你有沒有遇到過這種情況：你跟代碼代理聊得火熱，它根據你給的上下文改了幾行代碼，一切看起來完美。但兩周后，另一位同事的代理不小心又把那個重要的架構邊界改回去了，因為那個決策只存在于你的聊天記錄里。倉庫自己，偏偏沒記住。
這事不是假設。我是在真實倉庫里使用代碼代理時撞上的。一開始，我們以為問題出在上下文不夠——文件不夠、指令不清、錯誤日志沒喂進去。于是拼命往會話里塞東西：項目說明、歷史記錄、測試日志，甚至把整段計劃貼進去。代理確實更聰明了，能搞定當前任務。可真正的麻煩很快浮出水面：一些技術決策天生就不該只活在聊天窗口里。
比如，某個改動重新劃定了服務邊界，明確了“誰才是數據真相的來源”。又或者，團隊定下一條規矩：“絕不允許靜默回退”。這類決策一旦做出，會直接影響未來幾個月甚至幾年的代碼走向。如果它們只靠代理的短期記憶——哪怕工具提供了跨會話的私有記憶——就會成為地雷。因為那種記憶往往團隊其他人看不到，無法在合并請求里審查，沒有版本控制，換個工具就可能丟失，更別提清晰標注哪些規則已經“板上釘釘”、哪些還在討論中。
你瞧，這已經不是一個“上下文夠不夠”的問題了。這是個記憶的問題，而且是倉庫級的、耐久的記憶。更具體點說：下一次有人（或代理）碰這塊代碼時，他得能立刻知道，這里有過一個深思熟慮的決定，不能隨便推翻。
那么，怎么讓倉庫“記住”這種決策呢？一種簡單得出奇的辦法，是用架構決策記錄，也就是常說的ADR。別被這名字唬住，它不是什么厚重的設計文檔。最好的ADR其實短得只有幾段話，但能極其精確地回答三件事：做了什么決定、為什么非做不可、這個決定會給未來的工作帶來哪些必須遵守的約束。當然，還得標明狀態——是已接受、提議中、待定，還是已經被后來的決策替換掉了。
我這里有個很實用的判斷標準：如果兩個月后，另一個開發者或者另一個代碼代理碰了這塊區域，他是不是必須得知道當初這個決策，才不會把架構搞崩？如果答案是“是”，那么它就該以ADR（或者ADR的更新、待定候選）的形式，被寫進倉庫里。反過來，如果答案是否定的，那么寫段清晰的代碼、配上測試或者實現文檔，通常就足夠了。
千萬別誤會，我可沒主張把什么都記錄成ADR。像按鈕上改個文案、重構一個本地函數、調一個視覺細節——這些當然對產品很重要，但幾乎不會牽動未來的架構決策。可一旦涉及到“真相源應該放在哪個服務里”“代理工具的唯一合法接口是什么”“本地環境必須用顯式 profile 激活”這類規則時，就值得認真對待了。
歸根結底，這其實是一種工作習慣的轉換：不再把代碼代理當成一個帶著上下文來處理一次性任務的幫手，而是真正參與架構演進的協作者。既然要協作，就得有共享的、可追溯的、耐久的記憶。不然你每次打開聊天窗，都像是第一次給代理介紹項目。而倉庫呢，還是什么都沒記住。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
