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

喺 AI Coding 發展咁快嘅而家，工程師嘅價值正由「點樣實現」轉向「解決乜嘢問題」，咁手寫 code 仲有意義咩？作為一個堅持寫 code 差唔多 30 年嘅架構師、微軟最有價值專家（MVP）、開源項目創作者、而家係 Aviva Solutions 嘅代碼架構師 Dennis Doomen，佢嘅觀點好直接：如果你唔深入理解 code，就唔會有出色嘅架構決策。

最近，Dennis 喺播客節目裏面同主持人 Patrick Akil 傾偈，佢用咗大量一線經驗做基礎，探討咗一個更現實嘅問題：喺 AI 可以生成 code 嘅時代，我哋究竟要點樣 keep 住對 code 質素嘅掌控？基於呢個播客影片，InfoQ 整理咗內容，亦刪改咗一部分。

核心觀點如下：

• 作為架構負責人，同時保持落手實踐，呢個係團隊入面唯一有效嘅軟件開發方式。

• 軟件工程嘅核心，無論以前定未來，都係喺現有系統同不斷增加嘅複雜性之間保持平衡。如果對過去嘅決策唔理解，但係仍然死跟，就會不停累積複雜性，而時間會放大呢個問題，甚至決定系統成敗。

• 就算將來我哋可能唔需要再寫 code，現階段仍然要接手同維護 AI 生成嘅結果。

• 無論係提交記錄定 code review 說明，都應該盡量記錄決策嘅意圖，而唔係得技術細節。

Patrick：你曾經話自己唔想做全職演講，因為你太鍾意而家份工。

Dennis： 我都唔覺得有必要全職做演講，我仍然想親身參與實踐。我更願意叫自己做「動手型架構師」或者「編碼型架構師」，幾乎所有分享嘅內容都係嚟自一線經驗。如果停咗寫 code，唔再自己整同 deploy 生產系統，就會慢慢冇咗呢啲經驗。

我而家 52 歲，做咗呢行差唔多 30 年，幾乎想像唔到自己唔寫 code。好彩，我嘅工通常兼顧架構設計同團隊協作，我同時係架構師同團隊成員，會同開發者一齊寫生產 code，從中可以得到好多實踐經驗。同時，我都可以向開發者展示：只要稍微調整方法，code 嘅可維護性就會明顯提升，呢樣好有價值。另外，喺實踐入面仲會不斷遇到框架限制，學新技術、新範式，呢啲都好有價值。所以，我通常只會分享自身經驗，而唔係單純介紹新技術，因為後者已經好多人做得嚟。我更願意講返日常工作中嘅真實經歷，包括遇到嘅困難同成功。

Patrick：作為架構負責人，同時保持落手實踐，呢個係咪團隊入面最有效嘅軟件開發方式？

Dennis： 我認為呢個係唯一有效嘅方式。我接觸過好多企業架構師，佢哋通常關注高層設計，例如策略或者資訊架構，但係往往缺乏一線經驗，好難判斷某個方案得唔得，或者某條技術路線對長期可維護性同可持續性有咩影響。對我嚟講，軟件架構師如果想真正發揮作用，一定要知道自己做緊乜，同埋透過實踐不斷驗證諗法，要親身睇住方案喺實際入面嘅表現。就算只係 fix 現有 code base 嘅缺陷，都好有價值，因為可以從中學到好多嘢。我曾經多次以顧問身份加入團隊，發現佢哋喺維護 code 嘅時候遇到困難，例如高耦合、結構混亂等問題。

當用更高嘅角度睇嘅時候，往往會發現佢哋嘅架構本質上有啲似某啲成熟模式。但問題係，而家嘅團隊已經完全唔明原本嘅架構理念，甚至唔知底層嘅設計思想。佢哋只係機械式咁複製項目結構同文件夾，唔理解背後嘅原因，呢種教條化做法反而削弱咗優化同簡化 code 嘅能力。如果唔深入 code base，好難發現呢啲問題。

由零開始設計系統嘅時候，架構師通常會根據功能同非功能需求做合理假設，但要將呢啲設計真正落地，唔係淨係靠文件就得，開發團隊仍然會喺實現過程中犯錯。架構本身都包含假設，例如需唔需要某種抽象，或者用唔用特定模式，最後可能發現方案太複雜或者效能唔夠，需要調整。有時團隊經驗唔夠，都好難判斷某個模式啱唔啱用。所以，呢個過程本質上係持續疊代：設計、實現、反思、再調整，同敏捷開發好相似，都係工作嘅重要部分。

Patrick：我認為軟件工程嘅核心，無論以前定未來，都係喺現有系統同不斷增加嘅複雜性之間保持平衡。如果對過去嘅決策唔理解，但係仍然死跟，就會不停累積複雜性，而時間會放大呢個問題，甚至決定系統成敗。

Dennis： 如果你發現系統入面有冇必要嘅複雜性，就需要持續投入精力去消除佢。但係實踐入面成日要取捨，例如某個 module 太複雜，但係跟咗統一模式，應唔應該打破模式去簡化個 module？如果咁做，系統嘅一致性會受影響，部分開發者寧願 keep 一致性，就算代價係更高複雜度。我嘅觀點係，應該將 module 當成邊界，喺嗰個邊界入面 keep 一致性就得，優先簡化 module 本身，因為咁會明顯提升可維護性。好多開發者喺抽象、單元測試範圍等問題上覺得混淆，本質上都係複雜性帶嚟嘅問題。

關於避免重複（DRY）原則，我係比較務實嘅：某啲情況下，我會特登複製 code，去降低耦合，但呢個一定要經過深思熟慮嘅決策，而唔係盲抄或者完全唔抄。我見到好多有 10 到 15 年經驗嘅開發者，學咗 design pattern 之後，成日會過度依賴呢啲 pattern。當你話而家唔需要某種抽象嘅時候，佢哋成日會引用開閉原則或者單一職責原則去辯護，但呢啲抽象往往只係為咗將來嘅可能性而準備，而唔係現實需要。例如，有人會為咗將來可能支援多種 database 而設計複雜抽象，就算而家冇呢個需求。但唔同 database 喺語義上嘅差異，令到呢種抽象好難真係成立。

Patrick：如果有一套固定規則，嚴格跟住會唔會簡單啲？

Dennis： 理論上可以想像呢種情況，例如一套完全統一嘅標準，但現實唔係咁。

Patrick： 我更感興趣嘅係「規範同務實」之間嘅平衡，同埋而家同將來嘅取捨。隨住 AI 輔助開發越嚟越快，我哋可能會慢慢唔再關注實現方式本身，只要個系統最後係可維護就得。

Dennis： 我認為將來某個階段，啲人可能真係唔再關心 code 本身，好似科幻作品嗰樣，只要表達需求，系統就會自動搞掂。舊年，我開發咗一個 .NET 嘅開源 HTTP Mock 庫，因為現有工具滿足唔到需求，所以我自己開始整，同埋整理需求同 API 設計。

出於好奇，我將 GitHub issue 交俾 Copilot。令人驚訝嘅係，佢生成咗一個高質素嘅開源項目，基本上滿足曬所有需求，仲跟足我嘅編碼規範。然後我透過 comment 不斷補充需求，例如加斷言方法、支援唔同版本等，佢都可以好好完成，甚至自動拆項目、生成文件範例。喺呢個基礎上，我繼續手動優化，並當成自己嘅 code 去疊代。而家我用人機協作嘅方式開發：部分功能由 AI 生成，部分由我完成。而家 code 入面有啲唔係完全符合我標準嘅地方，例如方法比較長，但我選擇接受現狀，然後慢慢重構。

Patrick： 只要功能正確、test 過到，就可以接受，唔使即刻優化。

Dennis： 的確係咁。code 本身唔差，亦有跟規範。我仍然不斷試新工具同方法，同時會重點 review test，確保佢哋準確反映預期行為。Test 唔只用嚟驗證功能，亦幫我理解系統行為同 API 設計。喺實踐入面不斷疊代，而重複性嘅任務，我通常會優先叫 AI 做，提高效率。

就算係日常項目，我都會叫 AI 生成額外嘅 test case，確保 coverage 夠全面。但之後我一定會逐個 review 呢啲 test，確認佢哋真係達到預期目的，同時亦符合我鍾意嘅編碼模式。跟住我會叫 AI 調整，並同步 update instruction file，等佢下次生成嘅時候更貼近我嘅規範。雖然呢個唔係完全保證，但已經成為而家比較有效嘅 workflow。

Patrick： 我曾經喺某啲團隊經歷過呢個流程：喺需求細化階段，就將解決方案寫得好具體，包括要改嘅內容、code 位置、用嘅規範同 pattern 等。冇 AI 輔助工具嘅時候，我唔鍾意呢種方式，但優點係開發者只要睇任務就做。而家，執行嘅速度明顯加快，我哋唔再需要親自完成所有實現。呢樣令我開始諗：當構建能力越來越強、各種工具層出不窮嘅時候，研究同規劃、識別問題本身嘅重要性會唔會更加提高？同時間，分發同用戶獲取都會變得更關鍵，因為如果用戶可以輕易自己構建工具，咁產品真正解決嘅問題先係核心。

Dennis： 呢個都令我諗，開發開源項目係咪仍然值得。不過，現實嚟睇，唔係個個都有能力自己構建工具。我哋成日容易忽略自己身處一個「技術圈層」入面：以我為例，我有機會參加各種會議，活躍喺開源社區，接觸到大量持續學習、追求技術前沿嘅開發者。喺會議交流入面，可以從好多經驗豐富嘅人身上學到嘢。但事實上，仲有大量開發者冇呢啲條件，佢哋只係喺日常工作中獲取知識，甚至可能因為冇引導而長期停滯。所以，我哋做嘅嘢唔單止係為自己或者呢個小圈子，亦係為更廣泛嘅開發者羣體服務。

以我嘅開源項目為例，好多團隊喺實際項目入面會用佢，再結合 AI 去 rewrite test、取代舊嘅 mock 方案，或者為特定場景自動生成 test code。我一直堅持嘅目標，係令 code 盡可能容易閲讀。同時，我一直推崇 test-driven development，並努力令 test 本身有自解釋性，避免噪音，令佢可以當文件用。所以，我傾向用更清晰嘅測試方式，而唔係依賴複雜、難明嘅 mock 結構。本質上，呢啲工具最初係為我自己服務，然後再開放出嚟，觀察嚇其他人接唔接受。

Patrick： 我以前好重視 test 嘅結構同組織，唔單止為咗而家嘅自己，亦為咗將來嘅自己同團隊成員。我會喺 commit message 同 code review 入面盡量提供 context，令每次變更清晰同可理解。而家，我越嚟越覺得 test 質素就係系統嘅「安全網」。如果我哋將實現過程當成黑箱，只要 test 夠可靠，就可以信賴系統嘅行為，無論 code 係人定 AI 生成。所以，點樣設計 test、test 啲乜嘢，變得更加重要。有啲團隊甚至會先寫 test 同規範，再根據呢啲去生成實現。

Dennis： 就算將來我哋可能唔需要再寫 code，現階段仍然要接手同維護 AI 生成嘅結果。回顧過去兩三年，由 AI 工具開始普及到而家嘅發展速度係好驚人。雖然底層技術仍然喺度優化，但真正顯著嘅進步更多係喺工具層面，令佢哋更快、更強大。老實講，我唔係好明 AI 嘅內部原理，但呢個唔阻礙我高頻使用佢。

Patrick： 我都嘗試深入瞭解 AI，但後來發現呢個更多係出於好奇，而唔係解決實際問題。我更傾向直接使用工具做實驗，特別係個人項目或者生產環境。我曾經完全依賴 AI 做開發，但好快遇到問題，例如 context 被壓縮，導致理解丟失，最後甚至喺主 branch 直接 commit 咗實驗性 code。呢個係一個教訓，但都係透過實踐得到嘅經驗。同時間，呢種快速變化亦帶嚟咗啲焦慮，如果冇實驗環境，好容易落後。

Dennis： 我都有類似經歷。例如我用 AI 工具改 code，並頻密 commit 以便隨時 revert。但後來發現某啲修改俾人意外覆蓋，甚至開始懷疑係自己操作失誤。睇返 Git 記錄，先發現係 AI 喺某次修改入面撤銷咗我之前嘅更改。呢個說明用 AI 嘅時候要格外小心，良好嘅分支管理同 code review 特別重要。

至於「實驗」，我更傾向喺現有項目入面逐步嘗試，而唔係隨便整完就掉。曾經有人問我團隊應唔應該統一用某種 AI 工具，我嘅建議係唔好咁做。因為工具變化好快，強制統一反而限制探索空間。更合理嘅做法係俾團隊自由選擇工具，同時 tracking 使用情況並定期評估。

至於成本問題，其實好容易被誤解。我曾經遇過一啲團隊討論係咪引入 Copilot，佢哋會擔心成本問題，例如為幾個開發者俾月費。但如果從效率角度睇，呢類投入通常好短時間內就 return，甚至帶來幾倍收益。

不過，另一面嘅問題係，一啲經驗尚淺嘅開發者用 AI 嘅時候可能會遇到挑戰。一部分人擔心用 AI 會削弱自身學習能力，所以刻意唔用；佢哋更願意通過查資料、睇文件、反覆試錯嚟累積經驗。另一部分人就過度依賴 AI，但缺乏判斷能力，冇辦法驗證生成嘅 code 啱唔啱。我確實見過有人 commit code 嘅時候唔理解其實現邏輯，只係確認「test 過到」。喺呢種情況下，我會強調：可以用 AI，但一定要確保 code 質素達到團隊標準，就算你唔完全跟某種方法論，都要有相應嘅設計質素。

Dennis： 的確係咁。以前，我都成日同唔同水平嘅開發者合作。有人成日問嘢，有人就因為顧慮而唔敢問。而家，呢啲人可能會轉向 AI 攞答案，呢個未必係壞事。我自己都成日用 AI 嚟快速獲取資訊，例如對比唔同技術方案、查行業實踐等。AI 嘅優勢係能夠整合多種觀點，提供結構化總結，呢個喺好多場景下好有效率。所以，我幾乎每日都用佢，無論係工事，定生活決策，都會藉助 AI 攞參考意見。

Patrick：如果你由零開始培養一個軟件工程師，根據你而家嘅經驗，你會重點關注邊啲方面？

Dennis： 實際上，呢種情況喺我團隊成日出現，因為團隊入面有唔少啱啱入行嘅開發者。從根本嚟講，我認為方法同以前冇本質變化：叫佢哋由真實 code base 開始，例如 fix 缺陷、完成細小改進，慢慢接觸較大範圍 code 嘅過程中理解系統。 同時，鼓勵佢哋不斷問問題。

喺 code review 入面，我有一個長期用嘅做法：透過表情符號傳達 feedback 嘅語氣同意圖。呢個唔係為咗表達情緒，而係幫開發者理解 comment 嘅重要程度。例如，我會用「鎬子⛏️」表示呢個係細節層面嘅改進建議，尤其面對初級開發者嘅時候，呢種方式可以更清晰傳達「可以優化但唔係錯」嘅訊息。我仲會用「思考🤔」嘅表情表示呢個係可以討論嘅實現方式，從而引導佢哋主動諗嚇唔同方案嘅優缺點，再透過交流進一步加深理解。有時我仲會用「營地⛺️」嘅表情，表達「令 code 比嚟嘅時候更乾淨」嘅理念，即係當前實現可以接受，但仍有優化空間。

呢啲 review 本身就係一個學習過程，如果開發者喺某個問題卡住，就算我知道答案，都可能建議佢哋先用 AI 工具探索，然後將結果作為討論基礎。咁樣唔單止提高效率，亦促進更深入嘅理解。不過，喺架構層面，例如抽象設計或者依賴反轉原則嘅應用，仍然需要整體視角嘅判斷，呢類問題而家 AI 仲未完全搞得掂。只要系統仍需維護，我哋就要持續關注耦合、內聚等核心設計問題。

Patrick： 有時我會因為唔識某啲問題而覺得尷尬，唔敢直接問同事，而係先用工具理解背景，再討論。我認為 AI 可以幫我哋快速獲取 context 資訊，尤其係複雜系統入面，但最終決策仍然要人嚟負責。

Dennis： 的確係咁，AI 喺理解複雜 code base 方面好有幫助。例如，喺 microservices 架構入面，佢可以幫你梳理服務之間嘅數據流，快速定位 call 嘅路徑。但對於「點解咁設計」嘅歷史原因，仍然要依賴版本控制系統或者文件記錄。所以，我一直強調：喺 commit code 嘅時候，唔單止要講「做咗啲乜」，更加要講「點解咁做」。

Code 本身往往冇辦法體現決策背後嘅動機，而呢啲資訊好容易丟失。所以，無論係 commit message 定 code review 說明，都應該盡量記錄決策意圖，而唔係得技術細節。我自己都會藉助 AI 自動生成 commit 說明，然後適當調整。呢啲工具往往可以準確捉到變更嘅本質，而唔係淨係文件層面嘅改動。呢個進一步說明，高質素嘅歷史記錄對於之後理解系統好重要。

Patrick： 有啲公司會記錄業務決策，例如成本優化或者增長策略，而唔只係技術決策。如果能夠透過 commit 記錄、任務系統同文件持續積累 context，咁將來藉助 AI 工具做分析嘅時候，呢啲資訊會好有價值。

Dennis： 喺實踐入面，我通常會推動團隊用文件工具記錄關鍵決策，包括背景、備選方案同佢哋嘅優缺點，仲有參與決策嘅人。尤其對於唔係簡單決策，呢啲記錄喺長遠嚟講好重要。當新成員加入團隊或者有人質疑現有方案嘅時候，呢啲文件可以清晰還原當時嘅決策背景，避免重複討論或者錯誤推翻原有設計。

Patrick：記錄決策會唔會導致「路徑依賴」，即係團隊太過堅持過去嘅選擇，而忽略咗當前環境嘅變化？

Dennis： 呢種情況的確存在，但我都經歷過相反嘅情境：當管理層變動或者新成員加入嘅時候，可能會基於唔完整嘅資訊質疑現有架構。如果冇記錄，好容易做錯決策。而有咗清晰嘅決策依據，就可以解釋當時選擇嘅合理性，從而避免不必要嘅推翻。關鍵係：如果環境有變化，就應該重新評估；如果冇變化，就唔應該輕易否定過去嘅決定。

Patrick：隨住 AI 可以快速復現開源項目嘅部分功能，一啲依賴「開源 + 付費擴展」嘅商業模式正面臨挑戰，呢個會唔會影響開發者參與開源嘅動力？

Dennis： 用開源唔代表可以得到長期維護嘅保證，好多用戶會默認項目會持續更新，但實際上唔係咁。喺架構實踐入面，我通常會制定開源使用規範。例如，揀開源 library 嘅時候，要評估佢嘅質素、維護情況同社區活躍度。如果將來個項目停止維護，團隊有冇能力接手？呢個意味住，開源 code 某程度上都可能成為你嘅「自有 code」。

所以，需要考慮多個因素，例如維護者規模、code 質素、test coverage、文件完善程度同發佈流程等。關鍵唔係簡單判斷「用唔用得」，而係要充分理解其風險同成本。如果採用呢種思路，就算項目停止維護，都可以透過 fork 繼續維護。

好多人低估咗開發高質素 library 嘅複雜度，就算藉助 AI，開發成熟工具仍然需要大量時間同經驗。所以，大多數情況下，用開源仍然係更有效率嘅選擇。

Patrick：如果有人諗緊係咪將自己嘅項目開源，你會點建議？

Dennis： 首先，呢個過程本身就幾有趣，同時亦係展示能力嘅一種方式。當見到其他人用你嘅項目，仲從中受益，會帶嚟好大嘅成就感。如果項目被廣泛採用，甚至有人主動提交 fix 或者改進，呢種協作體驗好寶貴。

更加重要嘅係，開源係一個「付出同回報並存」嘅過程。你唔單止分享成果，都可以從社區入面得到大量 feedback、經驗同新嘅技術視角。好多改進建議、工具推薦甚至全新嘅思路，都係透過社區互動得到嘅。呢啲知識同經驗嘅累積，係開源最有價值嘅部分。

參考連結：

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

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

會議推薦

世界模型嘅下一個突破喺邊？Agent 從 Demo 到工程化仲差啲乜？安全與可信呢道坎點過？研發體系唔重構，仲可以撐幾耐？

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

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

在 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 進行調整，並同步更新指令文件，使其在下一次生成時更貼近我的規範。雖然這並不能完全保證結果，但這已經成為當前較為有效的工作流程。

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，但必須確保代碼質量達到團隊標準，即使你不完全遵循某種方法論，也應具備相應的設計質量。

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，期待與你同行。