2024年，GitHub Copilot用戶寫的代碼里，有41%是AI生成的。但一個(gè)更隱蔽的數(shù)字是：這些代碼被修改或回滾的比例，沒人敢公開統(tǒng)計(jì)。

問題不在于AI寫得快，而在于它改得盲。你把一個(gè)復(fù)雜系統(tǒng)丟給AI agent，它像拿到一份沒有注釋的電路圖——知道哪根線連到哪，但不知道當(dāng)初為什么非要這么繞。DLD框架的作者Fredrik Widlund發(fā)現(xiàn)，這才是AI編程的「阿喀琉斯之踵」。

從「氛圍編程」到系統(tǒng)性崩潰

Widlund在瑞典有聲書平臺(tái)Storytel做Staff Engineer，過去一年他試了幾乎所有AI編程流派。最極端的叫「vibe coding」——描述需求，讓AI隨便寫，寫完能跑就行。聽起來像產(chǎn)品經(jīng)理的終極夢想，直到他發(fā)現(xiàn)一個(gè)規(guī)律：項(xiàng)目前兩周速度起飛，第三周開始修bug，第四周想重寫。

「AI生成代碼的速度和人類理解它的速度，差距在指數(shù)級(jí)擴(kuò)大。」

這不是LLM（大語言模型）變笨了，是它的工作方式?jīng)Q定的。AI agent讀代碼時(shí)，看到的是靜態(tài)文本；但代碼背后是一連串決策——為什么用這個(gè)架構(gòu)、為什么放棄那個(gè)方案、為什么這里必須妥協(xié)。這些信息原本存在工程師腦子里，隨著人員流動(dòng)或時(shí)間推移，變成「孤兒知識(shí)」。

Widlund舉了個(gè)例子：一個(gè)微服務(wù)用了某種奇怪的數(shù)據(jù)庫分片策略。新接手的AI agent看到這段代碼，邏輯上推斷可以優(yōu)化，改完后導(dǎo)致生產(chǎn)環(huán)境雪崩。真正的原因是三年前某個(gè)凌晨，團(tuán)隊(duì)為了應(yīng)對一次突發(fā)流量，臨時(shí)做的應(yīng)急方案，后來沒人敢動(dòng)。

給代碼配一本「決策日記」

DLD的全稱是Decision-Linked Development，決策關(guān)聯(lián)開發(fā)。核心想法粗暴但有效：每次代碼變更，必須同時(shí)記錄「為什么改」。不是那種敷衍的commit message，而是結(jié)構(gòu)化的決策上下文——考慮了哪些方案、排除了哪些、受什么約束條件限制。

技術(shù)上，DLD用了一個(gè)叫ADR（Architecture Decision Records，架構(gòu)決策記錄）的概念，但做了關(guān)鍵改造。傳統(tǒng)ADR是寫給人看的文檔，容易過時(shí)；DLD把決策數(shù)據(jù)嵌入代碼倉庫的元數(shù)據(jù)層，讓AI agent能直接讀取。換句話說，AI改代碼前，先讀「病歷本」。

這個(gè)設(shè)計(jì)擊中了AI編程的一個(gè)悖論：LLM的上下文窗口越來越長，但有效利用率并沒有同比提升。Claude 3.5能處理20萬token，可如果你把十年項(xiàng)目的全部歷史丟給它，噪音會(huì)淹沒信號(hào)。DLD做的是預(yù)篩選——只把「和當(dāng)前修改相關(guān)的決策」推給AI。

Widlund在Storytel內(nèi)部測試時(shí)，一個(gè)典型場景是遺留系統(tǒng)的API改造。以前，工程師需要花2-3天梳理歷史文檔和口頭傳說；用DLD后，AI agent能在幾分鐘內(nèi)定位到關(guān)鍵決策點(diǎn)，比如「2021年Q3為了兼容iOS 12客戶端，這里必須保持REST而非GraphQL」。

開源之后，爭議來了

DLD今年早些時(shí)候開源，GitHub星標(biāo)增長曲線很典型：前兩周平緩，被某個(gè)技術(shù)KOL轉(zhuǎn)發(fā)后垂直拉升，然后進(jìn)入平臺(tái)期。真正有趣的是issue區(qū)的爭論。

一派工程師認(rèn)為這解決了AI編程的「可解釋性」危機(jī)。另一派則質(zhì)疑：如果AI需要人類寫的決策記錄才能安全工作，那是不是說明AI還不夠格？Widlund的回應(yīng)很直接：「人類工程師接手新項(xiàng)目時(shí)也需要文檔，憑什么要求AI更高？」

更實(shí)際的批評是關(guān)于維護(hù)成本。DLD要求團(tuán)隊(duì)在寫代碼的同時(shí)維護(hù)決策鏈，這對已經(jīng)疲于交付的團(tuán)隊(duì)是額外負(fù)擔(dān)。Widlund的折中方案是「漸進(jìn)式采納」——只在關(guān)鍵模塊啟用，比如核心業(yè)務(wù)邏輯、容易出事故的邊界條件。

他在博客中透露了一個(gè)數(shù)據(jù)：Storytel內(nèi)部采用DLD的模塊，AI生成代碼的首次通過率（無需人工返工）從34%提升到61%。但這個(gè)數(shù)字也有水分——首批試點(diǎn)團(tuán)隊(duì)本身就是對代碼質(zhì)量要求更高的組，可能存在選擇偏差。

更大的圖景：AI需要「組織記憶」

DLD的野心不止于代碼。Widlund在幾篇技術(shù)演講中暗示，同樣的思路可以擴(kuò)展到產(chǎn)品設(shè)計(jì)、運(yùn)營策略——任何需要「繼承歷史決策」的領(lǐng)域。

這觸及了企業(yè)AI應(yīng)用的一個(gè)深層焦慮。過去兩年，公司們瘋狂采購AI工具，卻發(fā)現(xiàn)效率提升有天花板。瓶頸往往不是工具本身，而是組織知識(shí)的碎片化。Salesforce一份內(nèi)部研究顯示，銷售團(tuán)隊(duì)用AI生成客戶郵件，前三個(gè)月響應(yīng)率提升，半年后回落到基線——因?yàn)锳I學(xué)不到「這個(gè)客戶去年為什么差點(diǎn)解約」這類非結(jié)構(gòu)化信息。

DLD試圖建立的是一種機(jī)器可讀的「組織記憶」。它不是要替代人類判斷，而是讓AI在做判斷前，先站在和人類同樣的信息起跑線上。

當(dāng)然，理想很豐滿。Widlund自己也承認(rèn)，DLD目前的實(shí)現(xiàn)還偏技術(shù)化，需要工程師手動(dòng)維護(hù)決策記錄。他正在實(shí)驗(yàn)讓AI輔助生成ADR——用另一個(gè)AI來監(jiān)督寫代碼的AI，聽起來像套娃，但可能是必經(jīng)之路。

Storytel的一位產(chǎn)品經(jīng)理在內(nèi)部反饋會(huì)上說了句實(shí)話：「以前怕AI不懂業(yè)務(wù)，現(xiàn)在怕AI太懂代碼但不懂我們?yōu)槭裁催x這條路�！笵LD能不能填上這個(gè)缺口，可能決定了AI編程工具是停留在「高級(jí)自動(dòng)補(bǔ)全」，還是真正成為可托付的協(xié)作伙伴。

如果AI agent能讀完你三年前寫的決策筆記，它會(huì)同意你當(dāng)時(shí)的判斷，還是覺得你是個(gè)傻子？