整理 | 褚杏娟

在上世紀(jì)六十年代末，隨著系統(tǒng)規(guī)模增長(zhǎng)到開發(fā)者已無(wú)法有效掌控的程度，“軟件危機(jī)”（Software Crisis）這一說(shuō)法首次出現(xiàn)。此后，每一代人似乎都用更強(qiáng)大的工具“解決”了這場(chǎng)危機(jī)，但結(jié)果往往只是制造出了更大的問(wèn)題。

Netflix 工程主管 Jake Nations 表示，如今，AI 正在把這一循環(huán)加速到一個(gè)新的階段：無(wú)限軟件危機(jī)（Infinite Software Crisis）。由 AI 生成的代碼庫(kù)，本質(zhì)上是生成它們的那一連串曲折對(duì)話的映射。每一次澄清、每一次方向調(diào)整，都會(huì)被直接固化進(jìn)系統(tǒng)架構(gòu)中。我們正在用 vibe coding 的方式，一步步走向?yàn)?zāi)難。

Jake?Nations 至今在軟件工程和大規(guī)模 AI/ML 系統(tǒng)設(shè)計(jì)領(lǐng)域擁有 13 年以上經(jīng)驗(yàn)，專注于管理復(fù)雜代碼庫(kù)與推動(dòng)高質(zhì)量工程實(shí)踐。在 Netflix，他負(fù)責(zé)推動(dòng)技術(shù)架構(gòu)與嚴(yán)謹(jǐn)開發(fā)流程，強(qiáng)調(diào)要理解系統(tǒng)本質(zhì)、控制復(fù)雜性以及在 AI 時(shí)代保持代碼和設(shè)計(jì)的可維護(hù)性。

針對(duì)上述問(wèn)題，Jake 認(rèn)為解決之道只有一個(gè)：選擇“簡(jiǎn)單”，而不是“容易”。一次冗長(zhǎng)的對(duì)話很容易；而劃分清晰、邊界明確的獨(dú)立階段，才是真正的簡(jiǎn)單。他提出了一種三階段方法論，并指出，當(dāng)所有人都在以機(jī)器的速度競(jìng)相生成代碼時(shí)，真正能夠脫穎而出的工程師，是那些能夠判斷系統(tǒng)何時(shí)開始變得糾纏、復(fù)雜的人。在無(wú)限代碼生成的時(shí)代，人類在最關(guān)鍵的節(jié)點(diǎn)上進(jìn)行判斷，將成為核心競(jìng)爭(zhēng)優(yōu)勢(shì)。

下面是 Jake 的演講分享，我們對(duì)此進(jìn)行了翻譯，并在不改變?cè)饣A(chǔ)上進(jìn)行了刪減，以饗讀者。

1 我們正在交付自己并不真正理解的代碼

我交付過(guò)一些自己其實(shí)并不完全理解的代碼。這些代碼是 AI 生成出來(lái)的，測(cè)試也跑過(guò)，上線也沒(méi)出問(wèn)題，但如果你讓我解釋它到底是怎么工作的，我說(shuō)不清楚。說(shuō)實(shí)話，我敢打賭，在座的每一個(gè)人都做過(guò)同樣的事。

所以，不如我們干脆承認(rèn)一個(gè)事實(shí)：我們現(xiàn)在都在交付自己并不完全理解的代碼。

我想帶大家回顧一下，這種情況是如何發(fā)生的。首先，回顧歷史，你會(huì)發(fā)現(xiàn)歷史總是在重復(fù)。其次，我們其實(shí)掉進(jìn)了一個(gè)陷阱：把“容易”和“簡(jiǎn)單”混為一談。最后，我認(rèn)為是有解法的，但前提是，我們不能把“思考”這件事外包出去。

過(guò)去幾年，我在 Netflix 推動(dòng) AI 工具的落地應(yīng)用，可以非常負(fù)責(zé)任地說(shuō)，這種加速是真實(shí)存在的。以前需要好幾天才能完成的待辦事項(xiàng)，現(xiàn)在幾個(gè)小時(shí)就能搞定；那些在計(jì)劃里躺了好幾年的大型重構(gòu)，終于開始被真正推進(jìn)。

但問(wèn)題在于，大型生產(chǎn)系統(tǒng)總是會(huì)以意想不到的方式出現(xiàn)故障?？纯醋罱?Cloudflare 發(fā)生的事情就知道了。一旦真的出問(wèn)題，你必須非常清楚自己正在調(diào)試的代碼是怎么運(yùn)作的。而現(xiàn)實(shí)是，我們現(xiàn)在生成代碼的速度和規(guī)模實(shí)在太快了，理解能力已經(jīng)明顯跟不上了。

說(shuō)實(shí)話，我自己就干過(guò)這種事：生成了一大段代碼，看了一眼，心里很清楚自己完全不知道它在干嘛。但測(cè)試過(guò)了，也能跑，那就先上線再說(shuō)吧。這其實(shí)并不是什么新鮮事。每一代軟件工程師最終都會(huì)遇到一個(gè)瓶頸：軟件復(fù)雜度超出了他們的管理能力。

我們并不是第一批面臨“軟件危機(jī)”的人，但我們是第一批面臨這種無(wú)限生成規(guī)模情況的人。

2 軟件危機(jī)，一直在循環(huán)

如果我們把時(shí)間往前撥，你會(huì)看到類似的故事一再發(fā)生。

在上世紀(jì)六十年代末到七十年代初，一群當(dāng)時(shí)最聰明的計(jì)算機(jī)科學(xué)家聚在一起，提出了一個(gè)判斷：我們正身處一場(chǎng)軟件危機(jī)之中。社會(huì)對(duì)軟件的需求急劇增長(zhǎng)，但我們的開發(fā)能力卻嚴(yán)重跟不上，項(xiàng)目周期過(guò)長(zhǎng)、效率低下，整體表現(xiàn)并不理想。

Edsger Dijkstra 曾有一句非常經(jīng)典的話，大意是：當(dāng)我們只有少量、性能很弱的計(jì)算機(jī)時(shí)，編程只是一個(gè)小問(wèn)題；而當(dāng)我們擁有了性能極其強(qiáng)大的計(jì)算機(jī)之后，編程反而變成了一個(gè)巨大的問(wèn)題。他解釋道，隨著硬件性能提升了幾個(gè)數(shù)量級(jí)，社會(huì)對(duì)軟件的需求也成比例增長(zhǎng)，最終壓力就全部落在了程序員身上：我們必須在“手段”和“目標(biāo)”之間找到支撐如此龐大軟件體系的方法。

這種循環(huán)不斷上演。七十年代，我們有了 C 語(yǔ)言，可以構(gòu)建更大的系統(tǒng)；八十年代，個(gè)人計(jì)算機(jī)普及，每個(gè)人都能寫軟件；九十年代，對(duì)象化編程盛行，繼承層級(jí)復(fù)雜到失控，某種程度上“感謝”Java；進(jìn)入新世紀(jì)，敏捷開發(fā)、沖刺、敏捷教練登場(chǎng)，瀑布模型被宣判“過(guò)時(shí)”；再后來(lái)是云計(jì)算、移動(dòng)開發(fā)、DevOps，軟件真正“吞噬了世界”。

而今天，我們迎來(lái)了 AI。Copilot、Cursor、Claude、Codex、Gemini，只要你能描述清楚需求，代碼幾乎可以瞬間生成。模式?jīng)]有變，但規(guī)模徹底變了：它已經(jīng)是無(wú)限的了。

3 難點(diǎn)從來(lái)不在“寫代碼”

Fred Brooks 除《人月神話》作者之外，還寫過(guò)一篇非常重要的論文，叫《沒(méi)有銀彈》（No Silver Bullet）。他在文中明確指出：不存在任何一種單一的技術(shù)創(chuàng)新，能夠在軟件生產(chǎn)率上帶來(lái)數(shù)量級(jí)的提升。

原因很簡(jiǎn)單：真正困難的部分，從來(lái)不是代碼的機(jī)械層面，比如、輸入、樣板代碼這些，而是理解問(wèn)題本身，并設(shè)計(jì)出正確的解決方案。這一點(diǎn)，是任何工具都無(wú)法替代的。

我們過(guò)去發(fā)明的所有工具和方法，幾乎都在讓“機(jī)械部分”變得更容易，但核心挑戰(zhàn)始終沒(méi)有改變：我們?nèi)匀恍枰宄降自摌?gòu)建什么，以及它應(yīng)該如何運(yùn)作。

既然問(wèn)題不在寫代碼本身，那為什么我們總是在優(yōu)化這些“機(jī)械層面”的東西？為什么經(jīng)驗(yàn)豐富的工程師，也會(huì)寫出自己看不懂的代碼？

我認(rèn)為，答案就在兩個(gè)我們經(jīng)?；煊玫脑~上：簡(jiǎn)單和容易。

Rich Hickey，也就是 Clojure 語(yǔ)言的創(chuàng)造者，在他的演講《Simple Made Easy》中，對(duì)這兩個(gè)概念做過(guò)非常清晰的區(qū)分。他認(rèn)為，“簡(jiǎn)單”指的是結(jié)構(gòu)上的單一、無(wú)糾纏，每個(gè)部分只做一件事，彼此之間不互相纏繞；而“容易”指的則是距離上的接近，是不是順手、是不是不用費(fèi)力就能拿到，比如復(fù)制、粘貼、直接上線。

簡(jiǎn)單關(guān)乎結(jié)構(gòu)，容易關(guān)乎便利。

問(wèn)題在于，簡(jiǎn)單是無(wú)法靠“許愿”得到的，需要思考、設(shè)計(jì)和拆解。而容易卻隨處可得：裝個(gè)包、讓 AI 生成、從 Stack Overflow 抄一段代碼。人類天生就會(huì)選擇容易的那條路。但容易并不等于簡(jiǎn)單。容易意味著你可以很快往系統(tǒng)里加?xùn)|西；簡(jiǎn)單意味著你能真正理解自己已經(jīng)做過(guò)的事情。每一次我們選擇容易，其實(shí)都是在用當(dāng)下的速度，換未來(lái)的復(fù)雜度。

說(shuō)實(shí)話，這種權(quán)衡在過(guò)去確實(shí)是有效的。復(fù)雜度積累得足夠慢，我們還有機(jī)會(huì)通過(guò)重構(gòu)、反思和重建來(lái)解決。但 AI 打破了這個(gè)平衡。它把“容易”推向了極致，極致到我們甚至不再考慮“簡(jiǎn)單”這條路。

4 對(duì)話式 AI，正在放大復(fù)雜度

當(dāng)代碼能瞬間生成時(shí)，為什么還要思考架構(gòu)呢？通過(guò)對(duì)話一步步生成代碼，看起來(lái)很自然，也很舒服，但它非常容易把一個(gè)本來(lái)簡(jiǎn)單的任務(wù)，演變成一團(tuán)復(fù)雜的混亂。

比如，我們有一個(gè)應(yīng)用，想為它引入一套身份認(rèn)證機(jī)制。我們對(duì) AI 說(shuō)：“加一個(gè) OAuth 認(rèn)證流程”，于是生成了一個(gè)看起來(lái)很干凈的 oauth.js 文件。隨著不斷迭代，又多出來(lái)一些配套的處理文件，看起來(lái)一切似乎還算合理。接著，我們又提出新的需求：“還要支持另一種 OAuth 認(rèn)證流程?！庇谑谴a庫(kù)里同時(shí)出現(xiàn)了 oauth.js 和 oauth2.js 兩套實(shí)現(xiàn)。我們繼續(xù)通過(guò)對(duì)話不斷迭代，很快就發(fā)現(xiàn)會(huì)話管理開始出問(wèn)題，各種沖突接踵而至。

到了第二十次迭代時(shí)，你已經(jīng)不再是在“討論設(shè)計(jì)”，而是在被迫管理一個(gè)極其復(fù)雜的上下文，甚至已經(jīng)記不清自己到底引入過(guò)多少約束條件。代碼庫(kù)里開始出現(xiàn)來(lái)自廢棄方案的死代碼，有為了“先跑起來(lái)”而被強(qiáng)行修復(fù)的測(cè)試，還有來(lái)自三種不同解決思路的殘留片段，因?yàn)槊恳淮涡碌闹噶睿紩?huì)在不知不覺(jué)中覆蓋之前的架構(gòu)決策。

我們說(shuō)“讓認(rèn)證邏輯在這里生效”，它照做了；我們說(shuō)“修復(fù)這個(gè)錯(cuò)誤”，它同樣完成了。但它對(duì)糟糕的架構(gòu)決策本身沒(méi)有任何約束或抵抗力，代碼只會(huì)不斷變形，以滿足你最新提出的需求。

每一次對(duì)話，其實(shí)都在選擇“容易”而不是“簡(jiǎn)單”。而“容易”的必然結(jié)果，就是復(fù)雜度不斷疊加。AI 會(huì)機(jī)械地滿足你的每一次最新指令，卻不會(huì)對(duì)糟糕的架構(gòu)決策產(chǎn)生任何阻力。

AI 真的把“容易”推向了邏輯極致：你想要什么，代碼就能瞬間得到。但這里的危險(xiǎn)在于，生成的代碼會(huì)平等對(duì)待你代碼庫(kù)中的每一個(gè)模式。當(dāng)智能體分析你的代碼庫(kù)時(shí)，每一行代碼都會(huì)變成一個(gè)需要保留的模式：第 47 行的身份驗(yàn)證檢查是一個(gè)模式，我 2019 年寫的那段奇怪的、像 GraphQL 一樣工作的 gRPC 代碼也是一個(gè)模式。

技術(shù)債在 AI 眼里并不是“債”，只是更多的代碼而已。

真正的問(wèn)題在于復(fù)雜度。我知道我在演講中反復(fù)提到這個(gè)詞，卻沒(méi)有真正定義它，但最好的理解方式是：它是簡(jiǎn)單的對(duì)立面，本質(zhì)就是“糾纏”。當(dāng)系統(tǒng)變得復(fù)雜時(shí)，一切都會(huì)相互影響，你幾乎無(wú)法只改一個(gè)地方而不波及其他部分。每一次交互都是在選擇容易而非簡(jiǎn)單，而容易總是意味著更多的復(fù)雜度。我們其實(shí)知道更好的做法，但當(dāng)容易的路這么容易走時(shí)，我們還是會(huì)選擇它。復(fù)雜度會(huì)不斷累積，直到為時(shí)已晚。

回到 Fred Brooks 的理論，他將系統(tǒng)中的復(fù)雜度分為兩類：

• 第一類是本質(zhì)復(fù)雜度（Essential Complexity），也就是問(wèn)題本身的難度：用戶要支付、訂單要履約，這些決定了系統(tǒng)為什么存在。

• 第二類是偶然復(fù)雜度（Accidental Complexity），這是我們?cè)趯?shí)現(xiàn)過(guò)程中不斷疊加上去的東西：臨時(shí)方案、防御性代碼、曾經(jīng)合理但現(xiàn)在過(guò)時(shí)的框架和抽象。

在真實(shí)的代碼庫(kù)里，這兩種復(fù)雜度往往糾纏在一起，想要分離它們，需要對(duì)歷史、上下文和經(jīng)驗(yàn)的深刻理解。而 AI 并不會(huì)區(qū)分這些，它只會(huì)把所有模式一并保留下來(lái)。

5 AI 真正需要的不是“更好的提示詞”

有一個(gè)來(lái)自 Netflix 實(shí)際工作的例子。

我們有一個(gè)系統(tǒng)，在大約五年前寫的舊授權(quán)代碼和新的集中式 OAuth 系統(tǒng)之間建有一個(gè)抽象層。我們當(dāng)時(shí)沒(méi)有時(shí)間重建整個(gè)應(yīng)用，所以就在兩者之間加了一個(gè)適配層?，F(xiàn)在有了 AI，這似乎是一個(gè)直接重構(gòu)代碼以使用新系統(tǒng)的好機(jī)會(huì)，對(duì)吧？但事實(shí)并非如此。

舊代碼與它的授權(quán)模式耦合得太緊了：權(quán)限檢查穿插在業(yè)務(wù)邏輯中，角色假設(shè)嵌入在數(shù)據(jù)模型里，OAuth 調(diào)用分散在數(shù)百個(gè)文件中。智能體會(huì)開始重構(gòu)并處理了幾個(gè)文件后，就會(huì)遇到無(wú)法梳理的依賴，然后要么失控放棄，要么更糟。它會(huì)試圖保留舊系統(tǒng)中的一些現(xiàn)有邏輯，并使用新系統(tǒng)重新實(shí)現(xiàn)，我覺(jué)得這也很糟糕。

問(wèn)題在于，它無(wú)法看到表象之下的東西，無(wú)法區(qū)分業(yè)務(wù)邏輯在哪里結(jié)束、授權(quán)邏輯在哪里開始。所有東西都糾纏在一起，即使有完整的信息，AI 也找不到一條清晰的路徑。當(dāng)你的偶然復(fù)雜度到這種程度時(shí)，AI 不僅幫不上忙，反而只會(huì)在上面添加更多的層。

但我們?nèi)祟惪梢詤^(qū)分，至少當(dāng)我們放慢速度思考時(shí)可以。我們知道哪些模式是本質(zhì)的，哪些只是幾年前某人的解決方案。我們掌握著 AI 可以推斷但需要我們提前花時(shí)間區(qū)分的上下文。

那么具體該怎么做呢？當(dāng)你面對(duì)一個(gè)龐大的代碼庫(kù)時(shí)，如何區(qū)分本質(zhì)復(fù)雜度和偶然復(fù)雜度？

我在 Netflix 工作的代碼庫(kù)有大約一百萬(wàn)行 Java 代碼，上次檢查時(shí)大約有五百萬(wàn)個(gè) tokens，我能訪問(wèn)的任何上下文窗口都裝不下它。因此，在著手處理這個(gè)問(wèn)題時(shí)，我最初的設(shè)想是，將代碼庫(kù)的大量?jī)?nèi)容直接復(fù)制到上下文中，看看模型能否自行識(shí)別出關(guān)鍵模式并理解系統(tǒng)結(jié)構(gòu)。但結(jié)果就和之前的授權(quán)重構(gòu)并無(wú)二致，生成的結(jié)果很快陷入了自身復(fù)雜度之中。

這迫使我不得不嘗試另一種方法：我必須選擇要包含的內(nèi)容，如設(shè)計(jì)文檔、架構(gòu)圖、關(guān)鍵接口等等，然后花時(shí)間寫下組件應(yīng)該如何交互以及要遵循的模式。

我其實(shí)是在寫一個(gè)規(guī)格說(shuō)明。五百萬(wàn)個(gè) tokens 最終變成了兩千字的規(guī)格說(shuō)明。更進(jìn)一步，我把這個(gè)規(guī)格說(shuō)明轉(zhuǎn)化為了一套精確的代碼執(zhí)行步驟，沒(méi)有模糊的指令，只有精確的操作序列。我發(fā)現(xiàn)這樣生成的代碼更干凈、更聚焦，因?yàn)槲蚁榷x了需求，再規(guī)劃了執(zhí)行過(guò)程。

我把這種方法稱為“上下文壓縮”，你也可以叫它“上下文工程”或“規(guī)格驅(qū)動(dòng)開發(fā)”，名字并不重要。重要的是，思考和規(guī)劃成為了工作的主體。讓我給你們?cè)敿?xì)介紹一下這個(gè)方法在實(shí)踐中是如何運(yùn)作的。

6 三階段方法論

第一階段：研究。我會(huì)把所有相關(guān)的東西都提供給 AI，包括架構(gòu)圖、文檔、Slack 對(duì)話記錄。

這一點(diǎn)我其實(shí)已經(jīng)反復(fù)強(qiáng)調(diào)過(guò)很多次了，但核心只有一句話：盡可能把所有與你即將做出的修改相關(guān)的上下文一次性帶進(jìn)來(lái)，然后再使用智能代理去分析整個(gè)代碼庫(kù)，梳理系統(tǒng)的組成部分以及它們之間的依賴關(guān)系。

這絕對(duì)不是一次性完成的過(guò)程。我通常會(huì)不斷追問(wèn)，比如緩存是怎么處理的？失敗場(chǎng)景是如何應(yīng)對(duì)的？如果它的分析有誤，我會(huì)直接糾正；如果它缺少關(guān)鍵信息，我就補(bǔ)充上下文。每一輪交互，都會(huì)讓它的分析更加精細(xì)。

這一階段的產(chǎn)出是一份完整的研究文檔：系統(tǒng)里目前都有哪些東西、它們之間是如何相互連接的、你即將做出的改動(dòng)會(huì)影響到哪些部分。原本需要花上好幾個(gè)小時(shí)甚至更久的探索過(guò)程，被壓縮成了幾分鐘的閱讀時(shí)間。

我知道 Dex 之前也提到過(guò)這一點(diǎn)，但我還是要強(qiáng)調(diào)：這里的人工檢查點(diǎn)（human checkpoint）至關(guān)重要。這是整個(gè)流程中投入產(chǎn)出比最高的時(shí)刻，你需要把分析結(jié)果與現(xiàn)實(shí)系統(tǒng)進(jìn)行對(duì)照，在這里發(fā)現(xiàn)錯(cuò)誤的話就能避免之后發(fā)生的災(zāi)難性后果。

第二階段：制定可以“照著做”的實(shí)現(xiàn)計(jì)劃。已經(jīng)有了可靠研究結(jié)論的前提下，我們開始制定一份極其詳細(xì)的實(shí)現(xiàn)計(jì)劃，包括真實(shí)的代碼結(jié)構(gòu)、函數(shù)簽名、類型定義、數(shù)據(jù)流等。

這份計(jì)劃的目標(biāo)，是做到任何一名開發(fā)者都可以直接照著執(zhí)行。我常把它比作“數(shù)字填色”：你可以把它交給團(tuán)隊(duì)里最初級(jí)的工程師，對(duì)他說(shuō)“照著這個(gè)來(lái)做”。只要他逐行照抄，最終結(jié)果就應(yīng)該是正確可用的。

大量關(guān)鍵的架構(gòu)決策，正是在這一階段完成的。我們會(huì)在這里確保復(fù)雜邏輯是正確的，業(yè)務(wù)需求遵循良好實(shí)踐，服務(wù)邊界清晰，職責(zé)劃分干凈，同時(shí)避免任何不必要的耦合。之所以能在問(wèn)題發(fā)生之前就識(shí)別它們，是因?yàn)槲覀冊(cè)?jīng)親身踩過(guò)這些坑。而 AI 并沒(méi)有這種經(jīng)驗(yàn)，它會(huì)把代碼中看到的每一種模式，都當(dāng)作“必須遵守的約束”。

這一階段真正的“魔法”，在于評(píng)審速度。我們可以在幾分鐘之內(nèi)完成對(duì)整個(gè)方案的驗(yàn)證，并且清楚地知道接下來(lái)到底會(huì)構(gòu)建出什么。而如果我們想跟上代碼生成的速度，就必須以同樣快的速度理解自己正在做的事情。

第三階段：實(shí)現(xiàn)。最后才是實(shí)現(xiàn)，一旦我們有了清晰的研究結(jié)論和明確的實(shí)現(xiàn)計(jì)劃，這一步反而應(yīng)該是最簡(jiǎn)單的，而這正是我們希望看到的結(jié)果。

當(dāng) AI 有一份清楚、具體的規(guī)格說(shuō)明可以遵循時(shí)，上下文就會(huì)保持干凈且聚焦。我們避免了冗長(zhǎng)對(duì)話導(dǎo)致的復(fù)雜度螺旋。相比五十輪不斷“進(jìn)化”的代碼修改，現(xiàn)在只需要三次高度聚焦的輸出，而且每一步都會(huì)在進(jìn)入下一階段前完成驗(yàn)證。沒(méi)有被放棄的方案，沒(méi)有相互沖突的模式，也不會(huì)再出現(xiàn)那種“等等，其實(shí)應(yīng)該這樣”的瞬間，沒(méi)有留下遍地的死代碼。

在我看來(lái)，這種方法真正的好處是：你可以把大量工作交給后臺(tái)運(yùn)行的智能體來(lái)完成。因?yàn)?strong>所有真正困難、需要?jiǎng)幽X子的事情，已經(jīng)提前由你完成了。智能體只需要按照計(jì)劃開始實(shí)現(xiàn)。你可以去處理別的事情，回來(lái)時(shí)只需要快速評(píng)審結(jié)果，因?yàn)槟銠z查的只是“它是否遵循了計(jì)劃”，而不是試圖弄清楚它是不是憑空“發(fā)明”了什么。

我們不是用 AI 來(lái)替我們思考，而是用它來(lái)加速機(jī)械性的工作，同時(shí)保持我們對(duì)代碼的理解能力。研究更快了，規(guī)劃更全面了，實(shí)施也更干凈了。但思考、綜合和判斷，仍然是我們的責(zé)任。

還記得我之前說(shuō)的那個(gè) AI 無(wú)法處理的授權(quán)系統(tǒng)重構(gòu)嗎？現(xiàn)在我們實(shí)際上已經(jīng)開始推進(jìn)它，并且取得了一些實(shí)質(zhì)性的進(jìn)展。但這并不是因?yàn)槲覀冋业搅烁玫奶崾驹~，恰恰相反，我們發(fā)現(xiàn)，連研究、規(guī)劃、實(shí)現(xiàn)這些階段都無(wú)法一開始就交給 AI。最終，我們不得不親自下場(chǎng)，手工完成這次修改：不借助 AI，只是閱讀代碼、理解依賴關(guān)系，然后一步步改動(dòng)，看哪里會(huì)出問(wèn)題。

說(shuō)實(shí)話，這次人工遷移過(guò)程非常痛苦，但至關(guān)重要。它揭示了所有隱藏的約束條件、必須遵守的不變式，以及一旦授權(quán)邏輯發(fā)生變化，哪些服務(wù)會(huì)直接崩潰。這些信息，是任何自動(dòng)化代碼分析都不可能替我們挖掘出來(lái)的。

然后，我們把這個(gè)手動(dòng)遷移的拉取請(qǐng)求納入了研究過(guò)程，讓它作為后續(xù)所有研究工作的基礎(chǔ)。即便如此，由于不同實(shí)體之間仍然存在差異，我們還是需要不斷追問(wèn)：這個(gè)該怎么處理、哪些數(shù)據(jù)是加密的哪些不是，每一次都要補(bǔ)充額外的上下文，并經(jīng)過(guò)多輪迭代。

直到這時(shí)，我們才有可能生成一份“或許能一次成功”的計(jì)劃。注意，這里的關(guān)鍵詞是“或許”。我們?nèi)匀辉诔掷m(xù)驗(yàn)證、不斷調(diào)整，并持續(xù)發(fā)現(xiàn)新的邊界情況。

這套三階段方法并不是什么魔法。它之所以能奏效，只是因?yàn)槲覀冊(cè)?jīng)親手完成過(guò)一次遷移。在把理解寫進(jìn)流程之前，我們必須先贏得這種理解。

我依然認(rèn)為，并不存在所謂的銀彈。沒(méi)有更好的提示詞，沒(méi)有萬(wàn)能的模型，甚至也不是寫得更漂亮的規(guī)格文檔。真正重要的，始終是那件最樸素、也最困難的事情：足夠深入地理解你的系統(tǒng)，理解到你可以安全地對(duì)它做出修改為止。

那為什么還要折騰這一整套流程呢？為什么不干脆一直和 AI 反復(fù)迭代，直到“能用”為止？反正模型遲早會(huì)變得足夠強(qiáng)，最后不就都能跑起來(lái)了嗎？

在我看來(lái)，“能跑”本身并不夠。通過(guò)測(cè)試的代碼和能在生產(chǎn)環(huán)境長(zhǎng)期穩(wěn)定運(yùn)行的代碼之間，是有本質(zhì)區(qū)別的；今天還能工作的系統(tǒng)，和未來(lái)還能被別人安全修改的系統(tǒng)，也是兩回事。

這中間存在一個(gè)認(rèn)知鴻溝。當(dāng) AI 可以在幾秒鐘內(nèi)生成成千上萬(wàn)行代碼時(shí)，理解這些代碼卻可能要花你幾個(gè)小時(shí)；如果系統(tǒng)足夠復(fù)雜，可能需要幾天；甚至在極端情況下，你可能永遠(yuǎn)都無(wú)法真正理解它。

7 軟件，終究是一項(xiàng)人類的事業(yè)

還有一個(gè)我覺(jué)得幾乎沒(méi)人認(rèn)真討論過(guò)的問(wèn)題：每一次為了跟上生成速度而跳過(guò)思考，我們失去的并不只是對(duì)代碼的理解。我們正在逐漸喪失一種能力：識(shí)別問(wèn)題的能力，那種會(huì)提醒你“等等，這里開始變復(fù)雜了”的直覺(jué)，如果你長(zhǎng)期不真正理解自己的系統(tǒng)，是會(huì)慢慢退化的。

模式識(shí)別（pattern recognition）來(lái)源于經(jīng)驗(yàn)。我一眼就能看出某種架構(gòu)是危險(xiǎn)的，那是因?yàn)槲揖湍莻€(gè)曾經(jīng)凌晨三點(diǎn)還在被它折磨的人；當(dāng)我堅(jiān)持推動(dòng)更簡(jiǎn)單的方案時(shí)，是因?yàn)槲以?jīng)接手并維護(hù)過(guò)別人留下的復(fù)雜系統(tǒng)。

AI 只會(huì)生成你讓它生成的東西，它并不會(huì)內(nèi)化那些來(lái)自失敗的教訓(xùn)。

三階段方法，正是用來(lái)彌合這道鴻溝的。它把“理解”壓縮成一系列可以在生成速度下被快速審查的產(chǎn)出物。如果沒(méi)有這一層，我們只是在用一種自己無(wú)法理解的速度，不斷累積復(fù)雜度。

AI 確實(shí)徹底改變了我們寫代碼的方式，但坦率地說(shuō)，我并不認(rèn)為但它并沒(méi)有改變軟件失敗的根本原因。每一代人都會(huì)遭遇屬于自己的軟件危機(jī)。Dijkstra 那一代，通過(guò)建立軟件工程這門學(xué)科來(lái)應(yīng)對(duì)；而我們這一代，面對(duì)的是無(wú)限規(guī)模的代碼生成。

答案并在于下一個(gè)工具或新的方法論，而在于重新記起一個(gè)我們?cè)缇椭赖氖聦?shí)：軟件始終是一項(xiàng)人類的事業(yè)。困難的從來(lái)不是敲代碼，而是在一開始就知道該敲什么。

最終能夠走得更遠(yuǎn)的開發(fā)者，并不只是那些生成代碼最多的人，而是那些仍然理解自己在構(gòu)建什么、能夠看清系統(tǒng)接縫、敢于質(zhì)疑問(wèn)題本身是否正確的人。

我想用一個(gè)問(wèn)題來(lái)結(jié)束今天的分享，這個(gè)問(wèn)題并不是“我們會(huì)不會(huì)使用 AI”，那早已是既定事實(shí)。真正的問(wèn)題是：當(dāng) AI 寫下大部分代碼的時(shí)候，我們是否仍然理解自己的系統(tǒng)？

https://www.youtube.com/watch?v=eIoohUmYpGI

技術(shù)人的年度儀式感！ 年度盤點(diǎn)與趨勢(shì)洞察 啟動(dòng)！

《2025 年度盤點(diǎn)與趨勢(shì)洞察》由 InfoQ 技術(shù)編輯組策劃。覆蓋大模型、Agent、具身智能、AI Native 開發(fā)范式、AI 工具鏈與開發(fā)、AI+ 傳統(tǒng)行業(yè)等方向，通過(guò)長(zhǎng)期跟蹤、與業(yè)內(nèi)專家深度訪談等方式，對(duì)重點(diǎn)領(lǐng)域進(jìn)行關(guān)鍵技術(shù)進(jìn)展、核心事件和產(chǎn)業(yè)趨勢(shì)的洞察盤點(diǎn)。

力求以體系化視角幫助讀者理解年度技術(shù)演化的底層邏輯、創(chuàng)新方向與落地價(jià)值，并為新一年決策提供參考。內(nèi)容將在 InfoQ 媒體矩陣陸續(xù)放出，歡迎大家持續(xù)關(guān)注。