去年Q3，Storytel的工程師團(tuán)隊做了個實驗：讓AI接手一個中等復(fù)雜度的微服務(wù)重構(gòu)。結(jié)果代碼交付速度提升40%，但3個月后維護(hù)工單暴漲217%。

負(fù)責(zé)AI落地的Staff Engineer Tobias Sandelius在復(fù)盤時發(fā)現(xiàn)，AI生成的代碼像一份沒有配料表的預(yù)制菜——你知道它能吃，但不知道里面放了什么，更不敢隨意加熱。

這個發(fā)現(xiàn)直接催生了DLD（Decision-Linked Development），一個試圖把「決策痕跡」焊進(jìn)代碼里的開源框架。

從「氛圍編程」到?jīng)Q策考古

Sandelius的實驗路徑很有代表性。2024年初，他和多數(shù)開發(fā)者一樣，從「vibe coding」（氛圍編程）入手——描述需求，讓AI自由發(fā)揮，人類負(fù)責(zé)鼓掌。

這種模式在原型階段確實爽快。他內(nèi)部記錄的一個案例：用Claude 3.5 Sonnet花4小時搭完一個推薦系統(tǒng)的MVP，同等工作量過去需要3天。

但快感在代碼交接時戛然而止。

接手項目的后端工程師在Slack里吐槽：「這坨代碼能跑，但我不知道它為什么這樣跑。改一行可能崩，不改又滿足不了新需求?！筍andelius把這類反饋歸類為「決策真空」——AI寫代碼時做了無數(shù)微觀選擇，但這些選擇的上下文在提交（commit）瞬間就被抹掉了。

他試過強(qiáng)制要求團(tuán)隊寫詳細(xì)注釋，但很快發(fā)現(xiàn)這是和人類本性作對。另一個極端是spec-driven開發(fā)：先寫冗長規(guī)格文檔，再讓AI按圖施工。結(jié)果文檔撰寫時間吞噬了AI節(jié)省的工時，「像為了用洗碗機(jī)先手洗一遍碗」。

DLD的核心設(shè)計：把「為什么」寫進(jìn)語法樹

DLD的解法不是讓AI多說話，而是讓代碼結(jié)構(gòu)本身攜帶決策信息。

框架要求每個代碼變更必須綁定三類元數(shù)據(jù)：決策動機(jī)（為什么改）、約束條件（當(dāng)時不能做什么）、替代方案（考慮過但放棄的路徑）。這些信息以結(jié)構(gòu)化格式嵌入代碼倉庫，而非游離在外的文檔。

Sandelius打了個比方：傳統(tǒng)注釋是便利貼，可能掉、可能過時；DLD是把決策刻進(jìn)代碼的「分子結(jié)構(gòu)」里，改代碼必須先讀到之前的「分子式」。

技術(shù)實現(xiàn)上，DLD用Git的notes機(jī)制和自定義的AST（抽象語法樹）標(biāo)注層。AI agent在修改代碼前，框架強(qiáng)制它先解析關(guān)聯(lián)的決策鏈。如果某段代碼的決策依據(jù)是「當(dāng)時Redis集群不穩(wěn)定，所以用本地緩存兜底」，agent讀到這條就不會在沒有確認(rèn)基礎(chǔ)設(shè)施變化的情況下貿(mào)然回退方案。

關(guān)鍵約束：DLD不試圖記錄所有信息，只捕捉「如果缺失會導(dǎo)致誤操作」的決策點(diǎn)。

Sandelius在文檔里強(qiáng)調(diào)，過度記錄會重蹈spec-driven的覆轍。框架內(nèi)置了一套啟發(fā)式規(guī)則，自動標(biāo)記高風(fēng)險變更區(qū)域——比如涉及并發(fā)控制、數(shù)據(jù)一致性、或依賴外部服務(wù)的代碼塊。

3個月實測：速度換可維護(hù)性的賬怎么算

2024年Q4，Storytel的一個8人后端團(tuán)隊在真實項目中試點(diǎn)DLD。

數(shù)據(jù)呈現(xiàn)有趣的 trade-off：首次開發(fā)周期比純AI模式慢15-20%，但代碼審查時間縮短35%，后續(xù)迭代的速度在第二、第三次修改時反超對照組。更關(guān)鍵的是，因「誤改歷史決策」導(dǎo)致的生產(chǎn)事故歸零。

Sandelius在內(nèi)部匯報中引用了團(tuán)隊的原話：「現(xiàn)在改代碼像看聊天記錄，知道對面（之前的開發(fā)者或AI）當(dāng)時在想什么，而不是對著一堵墻猜。」

但他也坦承局限。DLD對「探索性編碼」——即連人類都還沒想清楚的混沌階段——幫助有限?？蚣艿膬r值在代碼進(jìn)入「需要長期維護(hù)」?fàn)顟B(tài)時釋放，這恰好是多數(shù)AI生成代碼的薄弱環(huán)節(jié)。

另一個意外發(fā)現(xiàn)：DLD讓人類開發(fā)者的角色發(fā)生了微妙位移。他們花更多時間定義決策邊界和約束，而非直接編寫實現(xiàn)代碼。一位參與試點(diǎn)的工程師形容：「以前我是寫手，現(xiàn)在我是編輯兼事實核查員?！?/p>

開源后的反饋與未解問題

DLD在2025年1月開源后，GitHub兩周內(nèi)收獲1,200星。Sandelius梳理的issue和討論里，有兩類聲音最集中。

一類是工具鏈整合訴求：希望DLD能嵌入Cursor、Windsurf等主流AI IDE的agent工作流，而非作為獨(dú)立框架存在。另一類是質(zhì)疑決策記錄的權(quán)威性——如果最初的決策就是錯的，DLD會不會讓錯誤傳承得更牢固？

Sandelius的回應(yīng)很直接：「DLD不負(fù)責(zé)判斷決策質(zhì)量，只負(fù)責(zé)防止無意識覆蓋。錯誤的決策至少應(yīng)該被有意識地修改，而不是在無知中撞毀?！?/p>

他目前正在探索的下一步，是讓AI agent在讀取決策鏈時，能主動標(biāo)記「此決策的前提條件可能已變化」的預(yù)警。這需要框架與運(yùn)行時監(jiān)控、基礎(chǔ)設(shè)施狀態(tài)打通，復(fù)雜度躍升一個量級。

Storytel內(nèi)部還有一個未公開的實驗：把DLD的決策記錄喂給專門訓(xùn)練的模型，試圖讓AI不僅能讀取歷史決策，還能評估其當(dāng)前有效性。早期結(jié)果參差——模型對技術(shù)約束的判斷準(zhǔn)確率約70%，但對業(yè)務(wù)邏輯的時效性判斷經(jīng)常翻車。

如果AI coding agent的終極形態(tài)是「能獨(dú)立維護(hù)長期項目」，那么決策鏈的可解析性可能是比代碼生成能力更基礎(chǔ)的瓶頸。DLD的實驗至少證明了一點(diǎn)：在讓AI寫更多代碼之前，我們可能需要先教會它閱讀代碼的「記憶」。