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

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

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

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

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

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

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

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

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

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

具體場景很常見。假設(shè)你三年前寫了一個函數(shù)，注釋里寫著"此處用輪詢而非事件驅(qū)動，是因為當時第三方API不支持webhook"?，F(xiàn)在的AI agent看到這個函數(shù)，只會看到"輪詢"這個結(jié)果，看不到"第三方API不支持webhook"這個約束條件。它可能會自信地"優(yōu)化"成事件驅(qū)動，然后生產(chǎn)環(huán)境爆炸。

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

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

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

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

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

但在組織層面，圖景更復(fù)雜。AI驅(qū)動的開發(fā)被綁定了激進的 productivity gain（生產(chǎn)力提升）目標，而團隊規(guī)模卻在收縮或凍結(jié)。新增的系統(tǒng)復(fù)雜度需要維護，但 headcount（人頭數(shù)）沒有同比增加。這不是技術(shù)問題，是組織設(shè)計問題。

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

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

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

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

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

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

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

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

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