停止編碼的那天，就是失去架構判斷力的開始：一位 30 年架構師的 AI 生存指南

編譯｜宇琪

策劃 | Tina

在 AI Coding 飛速發展的當下，工程師的價值正從“如何實現”轉向“解決什么問題”，那么，手敲代碼還有意義嗎？作為一名堅持編碼近 30 年的架構師，微軟最有價值專家 (MVP)、開源項目創作者、現任 Aviva Solutions 的代碼架構師 Dennis Doomen 的觀點直截了當：如果你不深入代碼，就無法做出優秀的架構決策。

最近，Dennis 在播客節目中，與主持人 Patrick Akil 對話，他以大量一線經驗為基礎，探討了一個更現實的問題：在 AI 可以生成代碼的時代，我們究竟該如何保持對代碼質量的掌控？基于該播客視頻，InfoQ 對內容進行了整理與部分刪改。

核心觀點如下：

• 作為架構負責人，同時仍保持動手實踐，這是團隊中唯一有效的軟件開發方式。

• 軟件工程的核心，無論過去還是未來，都是在已有系統與不斷增長的復雜性之間維持平衡。如果對過去的決策缺乏理解，卻仍機械遵循，就會不斷累積復雜性，而時間會放大這一問題，甚至決定系統成敗。

• 即便未來我們可能不再需要編寫代碼，現階段仍然需要對 AI 生成的結果進行接管和維護。

• 無論是提交記錄還是代碼評審說明，都應盡量記錄決策意圖，而不僅是技術細節。

成為高效軟件架構師的唯一方式

Patrick：你曾說自己不愿意全職做會議演講，因為你太熱愛現在的工作了。

Dennis：我也不認為有必要全職從事演講，我仍然希望親自參與實踐。我更愿意稱自己為“動手型架構師”或“編碼型架構師”，幾乎所有分享內容都源于我的一線經驗。如果停止編寫代碼，不再親自構建并上線生產系統，就會逐漸失去這些經驗。

我現在 52 歲，從事這一領域已近 30 年，幾乎無法想象自己停止編碼。幸運的是，我的工作通常兼具架構設計與團隊協作，我既是架構師，也是團隊成員，會與開發者一起編寫生產代碼，從中能夠獲得大量實踐經驗。同時，我也能向開發者展示：只要稍微調整方法，代碼的可維護性就能顯著提升，這一點非常有價值。此外，在實踐中還會不斷遇到框架限制，學習新技術、新范式，這些都極具價值。因此，我通常只分享自身經驗，而不是單純介紹新技術，因為后者已有很多人可以勝任。我更愿意講述日常工作中的真實經歷，包括遇到的困難與取得的成功。

Patrick：作為架構負責人，同時仍保持動手實踐，這是否是團隊中最有效的軟件開發方式？

Dennis：我認為這是唯一有效的方式。我接觸過許多企業架構師，他們通常關注高層設計，例如策略或信息架構，但往往缺乏一線經驗，難以判斷某種方案是否可行，或某種技術路徑對長期可維護性與可持續性的影響。對我來說，軟件架構師若想真正發揮作用，必須清楚自己在做什么，并通過實踐不斷驗證設想，需要親自觀察方案在實際中的表現。即使只是修復現有代碼庫中的缺陷，也極具價值，因為可以從中學到大量經驗。我曾多次以顧問身份加入團隊，發現他們在維護代碼時面臨困難，例如高耦合、結構混亂等問題。

當從更高視角審視時，往往會發現其架構本質上類似某種成熟模式。但問題在于，當前團隊已經完全失去了對原始架構理念的理解，甚至不知道其底層設計思想。他們只是機械地復制項目結構與文件夾，而不理解其背后的原因，這種教條化做法反而削弱了優化和簡化代碼的能力。如果不深入代碼庫，很難發現這些問題。

在從零開始設計系統時，架構師通常會基于功能與非功能需求做出合理假設，但將這些設計真正落地，并非僅靠文檔即可完成，開發團隊仍會在實現過程中犯錯。架構本身也包含假設，例如是否需要某種抽象，或是否采用特定模式，最終可能發現方案過于復雜或性能不足，需要調整。有時團隊經驗不足，也難以判斷某種模式是否適用。因此，這一過程本質上是持續迭代的：設計、實現、反思、再調整，這與敏捷開發非常相似，也是工作的重要組成部分。

Patrick：我認為軟件工程的核心，無論過去還是未來，都是在已有系統與不斷增長的復雜性之間維持平衡。如果對過去的決策缺乏理解，卻仍機械遵循，就會不斷累積復雜性，而時間會放大這一問題，甚至決定系統成敗。

Dennis：如果你意識到系統中存在不必要的復雜性，就需要持續投入精力去消除它。但實踐中常會面臨權衡，例如某個模塊過于復雜，卻遵循統一模式，是否應打破模式以簡化該模塊。如果這樣做，系統的一致性會受到影響，部分開發者更傾向于保持一致性，即使代價是更高復雜度。我的觀點是，應將模塊視為邊界，在該邊界內保持一致性即可，而優先簡化模塊本身，因為這將顯著提升可維護性。許多開發者在抽象、單元測試范圍等問題上感到困惑，本質上也是復雜性帶來的問題。

關于避免重復（DRY）原則，我持相對務實的態度：在某些情況下，我會有意識地復制代碼，以降低耦合，但這必須是經過權衡的決策，而非盲目復制或完全避免復制。我觀察到，許多有 10 至 15 年經驗的開發者，在掌握設計模式后，往往會過度依賴這些模式。當你提出當前并不需要某種抽象時，他們常常會引用開閉原則或單一職責原則進行辯護，但這些抽象往往只是為未來的可能性做準備，而非現實需求。例如，有人會為了未來可能支持多種數據庫而設計復雜抽象，即使當前并無此需求。但不同數據庫在語義上的差異，使這種抽象往往難以真正成立。

Patrick：如果存在一套固定規則，嚴格遵循是否會更簡單？

Dennis：理論上可以想象這樣的情況，例如一種完全統一的標準，但現實并非如此。

Patrick：我更感興趣的是“規范與務實”的平衡，以及當下與未來的取舍。隨著 AI 輔助開發不斷加速，我們或許會逐漸不再關注實現方式本身，只要系統最終是可維護的即可。

Dennis：我認為在未來的某個階段，人們可能真的不再關心代碼本身，就像科幻作品中那樣，只需表達需求，系統便能自動完成。去年，我開發了一個 .NET 的開源 HTTP Mock 庫，起因是現有工具無法滿足需求，于是我開始自行構建，并整理需求與 API 設計。

出于好奇，我將 GitHub issue 分配給 Copilot。令人驚訝的是，它生成了一個高質量的開源項目，基本實現了所有需求，并遵循了我的編碼規范。隨后我通過評論不斷補充需求，例如增加斷言方法、支持不同版本等，它也能夠很好地完成這些任務，甚至可以自動拆分項目、生成文檔示例。在此基礎上，我繼續手動優化，并將其視為自己的代碼進行迭代。現在，我采用人機協作的方式開發：部分功能由 AI 生成，部分由我完成。目前代碼中存在一些不完全符合我標準的部分，例如方法較長，但我選擇接受這一現實，并在后續逐步重構。

Patrick：只要功能正確、測試通過，就可以接受，而不必立即優化。

Dennis：確實如此。代碼本身并不差，也遵循一定規范。我仍在不斷嘗試新的工具與方法，同時會重點審查測試，確保其能夠準確反映預期行為。測試不僅用于驗證功能，也幫助我理解系統行為與 API 設計。在實踐中持續迭代，而對于重復性任務，我通常會優先交由 AI 處理，以提高效率。

即使是在日常項目中，我也會讓 AI 生成額外的測試用例，以確保覆蓋率足夠全面。但隨后我一定會逐一審查這些測試，確認它們確實達到了預期目的，同時也符合我偏好的編碼模式。在此基礎上，我會要求 AI 進行調整，并同步更新指令文件，使其在下一次生成時更貼近我的規范。雖然這并不能完全保證結果，但這已經成為當前較為有效的工作流程。

測試在 AI 時代成為“安全網”

Patrick：我曾在一些團隊中經歷過這樣的流程：在需求細化階段，就將解決方案寫得非常具體，包括要修改的內容、代碼位置、采用的規范和模式等。在沒有 AI 輔助工具的情況下，我并不喜歡這種方式，但它的優點是開發者只需讀取任務并執行。如今，執行本身正在顯著加速，我們不再需要親自完成所有實現。這讓我開始思考：當構建能力不斷提升、各種工具層出不窮時，研究與規劃、識別問題本身的重要性是否會進一步提升？與此同時，分發與用戶獲取也將變得更加關鍵，因為如果用戶可以輕易自行構建工具，那么產品真正解決的問題才是核心。

Dennis：這也讓我思考，開發開源項目是否仍然值得。不過，從現實來看，并非所有人都具備自行構建工具的能力。我們往往容易忽視自己身處一個“技術圈層”之中：以我為例，我有機會參加各種會議，并活躍于開源社區，接觸到大量持續學習、追求技術前沿的開發者。在會議交流中，可以從許多經驗豐富的人身上學到東西。但事實上，還有大量開發者并沒有這樣的條件，他們只能在日常工作中獲取知識，甚至可能因為缺乏引導而長期停滯。因此，我們所做的事情不僅是為自己或這個小圈子，也是為更廣泛的開發者群體服務。

以我的開源項目為例，很多團隊在實際項目中會使用它，并結合 AI 來重寫測試、替換舊的 mock 方案，或為特定場景自動生成測試代碼。我始終堅持的目標，是讓代碼盡可能具備良好的可讀性。同時，我一直推崇測試驅動開發，并努力讓測試本身具備自解釋性，避免噪音，使其可以作為文檔使用。因此，我傾向于使用更清晰的測試方式，而不是依賴復雜、難以理解的 mock 結構。本質上，這些工具最初是為我自己服務的，在此基礎上再開放出來，觀察是否能被更多人接受。

Patrick：我過去非常重視測試的結構與組織，不僅是為當前的自己，也是為未來的自己和團隊成員。我會在提交信息和代碼評審中盡量提供上下文，使每次變更清晰且可理解。如今，我越來越覺得測試質量就是系統的“安全網”。如果我們將實現過程視為黑箱，那么只要測試足夠可靠，就可以信任系統的行為，無論代碼是由人還是 AI 生成。因此，如何設計測試、測試什么內容，正變得愈發重要。有些團隊甚至會先編寫測試和規范，再基于此生成實現。

Dennis：即便未來我們可能不再需要編寫代碼，現階段仍然需要對 AI 生成的結果進行接管和維護。回顧過去兩三年，從 AI 工具開始普及到現在的發展速度是非常驚人的。盡管底層技術仍在優化，但真正顯著的進步更多體現在工具層面，使其更快、更強大。坦率地說，我并不真正理解 AI 的內部原理，但這并不妨礙我高頻使用它。

Patrick：我也嘗試深入理解 AI，但后來意識到這更多是出于好奇，而非解決實際問題。我更傾向于直接使用工具進行實驗，尤其是在個人項目或生產環境中。我曾嘗試完全依賴 AI 進行開發，但很快遇到問題，例如上下文被壓縮，導致理解丟失，最終甚至在主分支上直接提交了實驗性代碼。這是一次教訓，但也是通過實踐獲得的經驗。與此同時，這種快速變化也帶來了一定的焦慮，如果沒有實驗環境，很容易落后。

Dennis：我也有類似經歷。比如我曾使用 AI 工具修改代碼，并頻繁提交以便隨時回滾。但后來發現某些修改被意外覆蓋，甚至開始懷疑是自己操作失誤。通過查看 Git 記錄，才發現是 AI 在某次修改中撤銷了我之前的更改。這說明在使用 AI 時必須格外謹慎，良好的分支管理和代碼審查尤為重要。

至于“實驗”，我更傾向于在已有項目中逐步嘗試，而不是隨意構建后再丟棄。我曾被問到團隊是否應統一使用某種 AI 工具，我的建議是不要這樣做。因為工具變化極快，強制統一反而限制探索空間。更合理的方式是允許團隊自由選擇工具，同時跟蹤使用情況并定期評估。

至于成本問題，其實很容易被誤解。我曾遇到一些團隊在討論是否引入 Copilot，他們會擔心成本問題，例如為幾位開發者支付每月訂閱費用。但如果從效率角度看，這類投入通常可以在極短時間內收回，甚至帶來數倍收益。

不過，另一面的問題在于，一些經驗尚淺的開發者在使用 AI 時可能面臨挑戰。一部分人擔心使用 AI 會削弱自身學習能力，因此刻意避免使用；他們更愿意通過查閱資料、閱讀文檔、反復試錯來積累經驗。另一部分人則過度依賴 AI，卻缺乏判斷能力，無法驗證生成代碼是否正確。我確實見過有人提交代碼時并不理解其實現邏輯，只是確認“測試通過”。在這種情況下，我會強調：可以使用 AI，但必須確保代碼質量達到團隊標準，即使你不完全遵循某種方法論，也應具備相應的設計質量。

在 AI 時代保持好奇心與批判性思維

Patrick：回顧我的學習經歷，從最初的獨立探索，到進入職場后學會主動提問、與團隊協作，再到如今使用 AI 進行“自我問答”，我認為關鍵在于保持好奇心與批判性思維。你可以選擇簡單復制答案，也可以利用 AI 深入理解原理，并與團隊討論驗證。只要持續提問與反思，就能快速成長。

Dennis：確實如此。在過去，我也經常與不同水平的開發者合作。有些人頻繁提問，有些人則因顧慮而不敢發問。如今，這些人可能會轉向 AI 獲取答案，這未必是壞事。我自己也經常使用 AI 來快速獲取信息，例如對比不同技術方案、查詢行業實踐等。AI 的優勢在于能夠整合多種觀點，提供結構化總結，這在很多場景下非常高效。因此，我幾乎每天都會使用它，無論是工作問題，還是生活決策，都會借助 AI 獲取參考意見。

Patrick：如果讓你從零培養一名軟件工程師，基于你現在的經驗，你會重點關注哪些方面？

Dennis：實際上，這種情況在我的團隊中經常出現，因為團隊里有不少剛入行的開發者。從根本上來說，我認為方法與過去并沒有本質變化：讓他們從真實代碼庫中入手，例如修復缺陷、完成小規模改進，在逐步接觸較大范圍代碼的過程中理解系統。同時，鼓勵他們不斷提問。

在代碼評審中，我有一個長期使用的做法：通過表情符號來傳達反饋的語氣和意圖。這并不是為了表達情緒，而是幫助開發者理解評論的重要程度。例如，我會用“鎬子??”表示這是細節層面的改進建議，尤其是在面對初級開發者時，這種方式可以更清晰地傳達“可以優化但不是錯誤”的信息。我還會用“思考”的表情表示這是一種可討論的實現方式，從而引導他們主動思考不同方案的優缺點，并通過交流進一步加深理解。有時我還會使用“營地??”的表情，表達“讓代碼比來時更干凈”的理念，即當前實現是可接受的，但仍有優化空間。

這些評審本身就是一種學習過程，如果開發者在某個問題上卡住，即使我知道答案，也可能會建議他們先借助 AI 工具進行探索，然后將結果作為討論基礎。這樣不僅能提高效率，也能促進更深入的理解。不過，在架構層面，例如抽象設計或依賴反轉原則的應用，仍然需要整體視角的判斷，這類問題目前 AI 還難以完全勝任。只要系統仍需維護，我們就必須持續關注耦合、內聚等核心設計問題。

Patrick：有時我會因為不懂某些問題而感到尷尬，不敢直接問同事，而是先借助工具理解背景，再進行討論。我認為 AI 可以幫助我們快速獲取上下文信息，尤其是在復雜系統中，但最終決策仍然需要人來承擔。

Dennis：確實如此，AI 在理解復雜代碼庫方面非常有幫助。例如，在微服務架構中，它可以幫助你梳理服務之間的數據流，快速定位調用路徑。但對于“為什么這樣設計”的歷史原因，仍需要依賴版本控制系統或文檔記錄。因此，我始終強調：在提交代碼時，不僅要說明“做了什么”，更要說明“為什么這么做”。

代碼本身往往無法體現決策背后的動機，而這些信息極易丟失。因此，無論是提交記錄還是代碼評審說明，都應盡量記錄決策意圖，而不僅是技術細節。我自己也會借助 AI 自動生成提交說明，并對結果進行適當調整。這些工具往往能夠準確抓住變更的本質，而不僅僅是文件層面的修改。這也進一步說明，高質量的歷史記錄對于后續理解系統至關重要。

Patrick：有些公司會記錄業務決策，如成本優化或增長策略，而不僅是技術決策。如果能夠通過提交記錄、任務系統和文檔持續積累上下文，那么在未來借助 AI 工具進行分析時，這些信息將極具價值。

Dennis：在實踐中，我通常會推動團隊使用文檔工具來記錄關鍵決策，包括背景、備選方案及其優缺點，以及參與決策的人。尤其對于非簡單決策，這些記錄在長期來看極為重要。當新成員加入團隊或有人質疑既有方案時，這些文檔可以清晰還原當時的決策背景，避免重復討論或錯誤推翻原有設計。

Patrick：記錄決策是否可能導致“路徑依賴”，即團隊過于堅持過去的選擇，而忽視當前環境的變化？

Dennis：這種情況確實存在，但我也經歷過相反的情境：當管理層變動或新成員加入時，可能會基于不完整的信息質疑既有架構。如果缺乏記錄，很容易做出錯誤決策。而有了清晰的決策依據，就可以解釋當時選擇的合理性，從而避免不必要的推翻。關鍵在于：如果環境發生變化，應重新評估；如果沒有變化，就不應輕易否定過去的決定。

Patrick：隨著 AI 可以快速復現開源項目的部分功能，一些依賴“開源 + 付費擴展”的商業模式正面臨挑戰，這是否會影響開發者參與開源的動力？

Dennis：使用開源并不意味著可以獲得長期維護的保證，很多用戶會默認項目會持續更新，但實際上并非如此。在架構實踐中，我通常會制定開源使用規范。例如，在選擇開源庫時，需要評估其質量、維護情況以及社區活躍度。如果未來該項目停止維護，團隊是否有能力接手？這意味著，開源代碼在某種程度上也可能成為你的“自有代碼”。

因此，需要考慮多個因素，例如維護者規模、代碼質量、測試覆蓋、文檔完善程度以及發布流程等。關鍵不是簡單判斷“能不能用”，而是充分理解其風險與成本。如果采用這種思路，即使項目停止維護，也可以通過分叉繼續維護。

很多人低估了構建高質量庫的復雜度，即使借助 AI，開發成熟工具仍需要大量時間與經驗。因此，在大多數情況下，使用開源依然是更高效的選擇。

Patrick：如果有人在考慮是否將自己的項目開源，你會如何建議？

Dennis：首先它本身是有趣的過程，同時也是展示能力的一種方式。當看到他人使用你的項目并從中受益，會帶來很大的成就感。如果項目被廣泛采用，甚至有人主動提交修復或改進，這種協作體驗非常寶貴。

更重要的是，開源是一個“付出與回報并存”的過程。你不僅分享成果，也能從社區中獲得大量反饋、經驗以及新的技術視角。很多改進建議、工具推薦甚至全新的思路，都是通過社區互動獲得的。這些知識與經驗的積累，是開源最具價值的部分。

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

聲明：本文為 InfoQ 整理，不代表平臺觀點，未經許可禁止轉載。

會議推薦

世界模型的下一個突破在哪？Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過？研發體系不重構，還能撐多久？

AICon 上海站 2026，4 大核心專題等你來：世界模型與多模態智能突破、Agent 架構與工程化實踐、Agent 安全與可信治理、企業級研發體系重構。14 個專題全面開放征稿。

誠摯邀請你登臺分享實戰經驗。AICon 2026，期待與你同行。