整理 | 褚杏娟

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

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

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

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

下面是 Jake 的演講分享，我們對此進(jìn)行了翻譯，并在不改變原意基礎(chǔ)上進(jìn)行了刪減，以饗讀者。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

有一個來自 Netflix 實(shí)際工作的例子。

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

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

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

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

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

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

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

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

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

6 三階段方法論

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

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

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

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

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

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

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

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

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

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

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

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

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

還記得我之前說的那個 AI 無法處理的授權(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)這些階段都無法一開始就交給 AI。最終，我們不得不親自下場，手工完成這次修改：不借助 AI，只是閱讀代碼、理解依賴關(guān)系，然后一步步改動，看哪里會出問題。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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