你的AI需要“傷疤組織”

最昂貴的AI錯誤不是編碼助手第一次搞錯了什麼，而是明天它又犯了同樣的錯誤。正是這一點逐漸消磨你的耐心——不是因為模型失敗了一次，這很正常。令人沮喪的是你已經糾正過它：你解釋了倉庫的模式，告訴了它那次遷移失敗的原因，指出了奇怪的CI問題，展示了之前失敗的依賴。AI修復了任務，會話結束。然而兩天後，一個新會話又提出了同樣糟糕的想法，彷彿一切從未發生過。這就是我最近一直在思考的問題：AI編碼助手需要的不僅僅是更大的上下文窗口，它們需要“傷疤組織”。

我所説的“傷疤組織”是指被記住的失敗。它不是泛泛的文檔，不是龐大的聊天記錄，也不是另一個臃腫的AGENTS.md文件——無論是否相關都被塞進每次提示中。傷疤組織是關於什麼出了問題、為什麼出問題以及不應重複的持久記憶。例如：不要在這個倉庫中使用這個遷移模式，它在本地通過但會因為X原因破壞預發佈環境；不要替換這個中間件，它看起來冗餘但實際上保護了管理路由；不要再使用這個包，我們試過它，由於原生依賴在Vercel上失敗了；Stripe的webhook處理器必須保留原始請求體，正常的JSON解析會破壞簽名驗證；這個測試失敗通常意味着模擬用户缺少某個角色，不要先重寫認證流程。這類知識非常寶貴，但大多數時候它消失了——存在於某人的頭腦中，淹沒在Slack裏，困在昨天的AI會話中，或藏在再也沒人閲讀的PR評論裏。

很多AI編碼工作流仍然把上下文當作萬能藥：添加更多文件、更多指令、更多文檔、更多示例、更多項目歷史。最終提示變成了一個雜物抽屜，AI有了更多文本，但不一定有更好的判斷力。這正是我關心的區別：上下文告訴AI附近有什麼，而傷疤組織告訴AI它從慘痛教訓中學到了什麼。兩者不是一回事。

舊模式是這樣的：會話1中AI提出錯誤方法，開發者糾正，AI修復問題，會話結束；會話2中AI對糾正毫無記憶，再次提出同樣錯誤方法，開發者失去信任。模型並非真的“忘記”了——它從一開始就沒有持久記憶，只有臨時工作空間。一旦會話結束，教訓就消失了。

更好的模式應該是：會話1中AI提出錯誤方法，開發者糾正，教訓作為持久項目記憶被存儲；會話2中AI開始類似任務，相關傷疤被檢索，AI避免重蹈覆轍。這是一種不同的AI編碼工作流——不僅更快、更便宜、消耗更少token，而且更有經驗。

編碼助手越強大，這一點就越重要。當AI只寫小片段時，遺忘只是煩人；現在它們可以觸及真實架構：重構文件、生成遷移、編寫測試、修改接近生產環境的代碼。這讓重複錯誤代價更高。如果AI要在真實代碼庫中操作，它需要的不僅僅是指令，而是對後果的記憶——記住那些帶來傷害的事情。

這正是我通過Empirical探索的用例之一。Empirical是AI工具的記憶層。它不是把每個教訓、決策、偏好和警告都塞進一個巨大的提示，而是讓AI在需要時檢索特定的記憶。對於編碼助手，記憶層可以存儲：項目決策、倉庫約定、失敗方法、bug歷史、CI/CD怪癖、安全陷阱、依賴警告、“再也不要這樣做”的教訓。這些通常會在會話之間丟失，也正是讓開發者隨時間變得更有效的東西。為什麼AI編碼助手應該有所不同呢？

我不認為編碼助手的下一次飛躍僅僅來自更智能的模型。部分進步將來自更好的記憶——不是轉錄轉儲，不是“把整個倉庫加載到上下文中”，而是作為累積判斷力、操作歷史、傷疤組織的記憶。因為真正的勝利不僅僅是能夠編寫代碼的AI，而是能記住上次修復為什麼失敗的AI。