這個11歲寫代碼的工程師，用3個文件解決了AI改代碼的"失憶癥"

AI coding agents（AI編程智能體）能在一秒內生成200行代碼，卻對你三年前寫的注釋視而不見。Storytel的一位staff engineer花了12個月驗證：當代碼量超過10萬行，這種"自信而盲目"的修改方式，正在讓技術債以指數級增長。

他最終交出的答案只有3個文件，卻試圖重新定義AI與代碼的協作關系。

從"氛圍編程"到系統性崩潰

作者的自述帶著一種典型的工程師式坦誠：11歲入門，嵌入式系統學位，但大部分技能靠自學。這種人通常對"黑箱"有本能的警惕——而LLM（大語言模型，Large Language Model）正是黑箱中的黑箱。

過去一年，他在Storytel嘗試了從"vibe coding（氛圍編程，指憑直覺讓AI生成代碼）"到嚴格規格驅動開發的完整光譜。前者像開快車：初期爽感明顯，團隊生產力數字漂亮；后者像修路： upfront成本高昂，但承諾長期可維護。

問題出在中間地帶。當團隊用AI加速開發復雜系統時，一個悖論浮現：機械優勢（mechanical advantage）確實讓構建速度變快，但沒人能保證這種優勢在18個月后不會變成技術債炸彈。LLM性能會持續提升——但這不能成為流程設計的唯一保險。

「我不斷回到一個核心問題：如何在利用AI的機械優勢快速構建復雜系統的同時，不只依賴LLM未來性能的持續提升來保證長期有效的流程？」

這個問句的潛臺詞是：當前的行業共識（用更聰明的模型解決一切）可能是一種偷懶。

DLD的解剖：把"為什么"寫進代碼旁邊

他的解決方案叫DLD，一個開源框架。名字本身沒有營銷野心，結構也極簡：三個核心文件，解決一個被忽視的問題——AI agents修改代碼時，無法訪問代碼背后的決策歷史。

具體場景很常見。假設你三年前寫了一個函數，注釋里寫著"此處用輪詢而非事件驅動，是因為當時第三方API不支持webhook"。現在的AI agent看到這個函數，只會看到"輪詢"這個結果，看不到"第三方API不支持webhook"這個約束條件。它可能會自信地"優化"成事件驅動，然后生產環境爆炸。

DLD的做法是把決策（Decision）與代碼解耦存儲，但保持強鏈接。不是寫在注釋里（注釋會被忽略），不是寫在Wiki里（Wiki會過時），而是用一種結構化的、機器可讀的方式，讓AI agent在修改前必須"閱讀"當時的決策上下文。

這相當于給代碼配了一份"病歷"——不是給人類看的，是給下一個AI醫生看的。

技術實現上，DLD用了一個聰明的類比：把代碼決策當作依賴管理。就像npm（Node Package Manager，Node.js包管理器）記錄"為什么用這個版本"，DLD記錄"為什么寫成這樣"。區別在于，依賴版本是客觀事實，代碼決策是主觀判斷——而主觀判斷恰恰是AI最容易誤判的地帶。

Storytel的試驗場：個人興奮 vs 組織焦慮

作者的觀察值得細品。在個人層面，LLM讓30歲以上的工程師重新燃起 side project 的希望——"那些從未見光的項目"突然有了可行性。他甚至提到自己沒有孩子，但時間已被生活切割得支離破碎。這種表述精準擊中了目標讀者：不是剛畢業的極客，而是有房貸、有體檢報告、有"曾經想做的項目"文件夾的中年技術人。

但在組織層面，圖景更復雜。AI驅動的開發被綁定了激進的 productivity gain（生產力提升）目標，而團隊規模卻在收縮或凍結。新增的系統復雜度需要維護，但 headcount（人頭數）沒有同比增加。這不是技術問題，是組織設計問題。

他刻意回避了道德討論（"我還沒提到任何道德層面"），但留下了鉤子。當AI生成的代碼比例超過某個閾值，代碼庫的所有權歸屬會變得模糊。這不是法律意義上的版權模糊，是運維意義上的責任模糊：當生產事故發生時，誰擁有足夠的上下文來修復？

DLD試圖在技術層面 preempt（預先應對）這個問題，通過強制保留決策鏈條來維持"可追責性"（accountability）。

開源的賭注：一個小工具能否改變協作協議

DLD目前的狀態是"我已學到的東西"，而非"已驗證的解決方案"。作者沒有聲稱這是銀彈，反而強調了實驗性質。這種克制在AI工具泛濫的當下，反而構成了可信度。

真正的賭注在于：如果DLD的假設成立（即AI agents需要結構化決策歷史才能安全地修改復雜代碼），那么它可能成為新一代開發工具鏈的基礎設施。就像Git（分布式版本控制系統）解決了"誰改了什么"，DLD試圖解決"為什么這樣改"。

但協議層面的改變比工具層面難得多。Git花了十年才成為默認選項，而AI開發工具的迭代周期是以月計算的。DLD需要回答的終極問題是：當LLM本身的能力提升到可以"理解"代碼意圖時，顯式的決策記錄是否還有必要？

作者的回應藏在開頭的那段話里：「不只依賴LLM未來性能的持續提升」。這是一種對技術決定論的溫和反抗——即使模型變聰明了，人類決策的透明度仍然有價值。

Storytel的工程師們現在有了一個選擇：繼續用"vibe coding"賭模型的未來，或者用DLD為當下的決策付費，換取長期的可維護性。這個選擇本身，可能比DLD的技術細節更能預測AI開發工具的未來走向。

如果DLD最終被廣泛采用，我們會怎么稱呼這種開發模式？當"決策即代碼"成為基礎設施，下一個被重新定義的會是什么——代碼審查，還是工程師的職業身份本身？