用藍盒子馴服天空

今年上半年工會的購書活動我買了一套名字看起來很奇怪的書：《以紙鳶征服加農炮》和《用藍盒子馴服天空》。因爲我有時喜歡在會議間隙看幾頁書，所以這兩本書一直襬在我的桌面上。因爲名字確實很奇怪，所以經常有同事路過的時候會問我這兩本書是講什麼的，我就會簡單地回答：這是一本講工程的書。 爲什麼我想買這套書呢？因爲我一直在思考一個問題：軟件工程的主要載體是代碼，當AI可能生成代碼之後，軟件工程還存在嗎? 或者說在AI能產生代碼的時代，軟件工程師的作用是什麼？這個問題自從生成式AI出現並廣泛應用於軟件工程之後就在困擾我，尤其是最近一兩年AI 編程agent的能力越來越強，從以前只能簡單地給你推薦一下你應該引用哪個類庫變成可以獨立地完成一部分代碼，比如寫一個類或是一個HTML頁面。 我無意中在微信讀書上讀到了微軟中國首席技術官給這套書寫的序，然後我就覺得這本書能夠幫助我回答“AI編程時代，軟件工程和軟件工程師的價值”這個問題，然後我就推薦公司買了這套書。這套書比較容易讀，因爲 它用了很多故事來講述核心的觀點，這些故事涵蓋了航空工程，機械工程和環保工程等不同的領域。 如果大家對這些故事好奇的話，我建議大家可以自己讀一下書，這些故事告訴我們對於一個工程問題來說，最重要的是什麼。我們平時經常把科學和技術連在一起使用，好像科學和技術是無法區分的，其實並不然。區分科學和技術有一個最簡單的標準，科學是要建立一個模型來描述世界上的現象，技術或是工程則是要用模型來解決各種複雜的問題。 科學中最常用的方法是還原論，也就是把現象中的各種因素拆開，獨立研究每一種因素。技術和工程的方法則不然，技術和工程需要一種系統性的視角，也就是說不僅要搞清楚一個組件是如何工作的，還要搞清楚這個組件是如何和整個系統中的其他組件互動並相互影響的。這種系統性視角分析出來的結果就是一個工程問題的結構。 比如說在我們日常的軟件工程中，我們不僅要搞清楚一個組件比如數據庫或消息中間件的工作原理，我們還需要搞清楚當這個組件和我們系統中的其他組件一起工作時會發生什麼，什麼情況這些組件被應用到了合適的場景下，什麼時候我們應該考慮別的組件。我們需要一個全局性視角來理解各個組件是如何組成一個系統的。 工程問題中除了要了解結構之外還需要了解約束。什麼是約束呢？我們在軟件工程中出現的業務需求和非功能性需求就是一種強制性的約束，比如用戶能否接受異步刷新，API的平均返回時間是多少等等都是對我們工程問題的約束。 作爲一個軟件工程的參與者，我們每天的任務就是根據各種約束來設計我們的系統和系統中的各種組件，然後通過編碼或配置來實現這個系統。在這個過程中我們每天面對的主要問題是什麼呢？是編寫代碼？配置各種環境中的參數和連接字符串？還是監控日誌系統中記錄的錯誤? 作者的回答是我們每天需要面對的主要任務是判斷問題的類別並做出權衡。 是的，沒錯，根據系統結構和各種約束條件做出權衡纔是各種工程問題和工程實踐的核心任務。這個答案在很大程度上回答了我最初的問題，有了AI能產生代碼之後，軟件工程師還需要做什麼？答案很簡單：軟件工程師需要專注於核心任務：權衡。AI可能幫你寫出一個類，但是AI很難告訴你根據你的場景你到底是該用一個接口還是一個抽象類。AI可以快速寫出每個軟件設計模式的代碼實現，但是它沒法告訴你當前的情況是應該用簡單工廠模式還是抽象工廠模式。 即使AI能夠根據你的描述給你建議，這個建議最終是否採納也只能依賴你自己的權衡，並且只有你自己才能對權衡的結果負責。整個權衡的過程不僅依賴於AI可以快速回答的靜態知識，還依賴於我們從長期實踐經驗中獲得的動態知識，也就是知道什麼時候應該運用什麼知識的能力。所以權衡是一個困難的任務，需要團隊的集體智慧和協調一致，權衡的結果永遠沒有最優解，只有次優解。 爲什麼權衡是一個困難的任務呢？因爲它需要考慮的方面太多了，根據作者在這套書中給出的建議，任何權衡都需要考慮六個方面：效率，模糊性，脆弱性，安全性，可維護性，韌性。也就是說任何工程問題的權衡需要面對的不是非此即彼，非黑即白的簡單問題，而是一個棘手的六面體。 我們在軟件開發的日常工程中被重視最多的就是效率：在一個sprint裏完成了多少task，case是否能夠在SLA規定的時間範圍內解決等等。效率當然是工程中一個重要的考量目標，所以很多的KPI都是圍繞如何提高效率設計的。用AI編程助手來寫代碼當然能提高效率，所以AI編程助手是任何軟件工程都無法抗拒的誘惑。 我們需要注意的一點是效率不是我們工程問題權衡的唯一指標，我們使用AI產生了更多的代碼是否會帶來可維護性上的困擾，我們能不能理解這些AI產生的代碼對系統結構造成的影響，這是我們需要考慮的問題。當然還有更重要的安全問題，AI產生的代碼是否有安全隱患，也是我們在代碼靜態掃描時需要關注的。 我們日常遇到的工程難題一般都是如何在這六個維度上做到平衡，因爲如果我們只看一個指標的話，就沒有所謂的工程難題。所有的難題都是因爲要兼顧多個因素。曾經牛頓力學解決了兩個物體之間的作用是什麼樣的，有人就想了是不是能夠計算三個物體在牛頓力學中的相互作用，這就是著名的“三體問題”，後來龐加萊發現這個問題用微積分根本算不出，後來也證明了三體問題沒有解析解。現在我們那本耳熟能詳的科幻小說的名字就是這麼來的。 沒有一種工程模式可以解決所有六個維度的問題，明白了這點大家就不用在讓人眼花繚亂的技術討論中迷茫了。有人說他要取消微服務架構改用單體，是不是微服務架構就不能用了？不是，只是在某些場景下微服務架構不是權衡之後的次優解。有人說MCP引發AI應用的上下文爆炸，是不是MCP就不能用了？不是，也是因爲在某些場景下這個技術會引發某些維度的混亂，所以只能在權衡之後被捨棄。 解決工程問題最忌諱的就是拿着錘子找釘子。解決工程問題的人最要不得的態度就是一知半解，聽說了一種新技術和新概念之後就把這個新技術和新概念當成神藥，忘記了工程的本質是權衡，恨不得把這個新技術和新概念應用到一切的工程實踐中去。我曾經就見過那種無論多簡單的場景都要套用設計模式的人，設計模式就是這麼被這些人玩兒壞的。 無論是設計模式還是現在各種AI相關的新概念，它們都是一種技術方案，都有它們適合的場景，同樣也有它們不適合的場景。真的要採用哪種技術和模式都需要在團隊內部經過討論之後做出謹慎的權衡。工程問題需要考慮的所有因素是一個六面體，這就意味着在這六個因素之間的權衡沒有放諸四海皆準的標準答案和全局最優解，這對於任何從事工程的人來說即是一個魔咒，也是一個福音。 說它是魔咒因爲我們沒法用一個標準方法和模板來解決所有技術問題，作爲一個軟件從業者，這些年強行套用微服務架構引起的水土不服我們還見得少嗎？說它是福音是因爲工程問題沒有全局最優解和標準答案，AI就無法替代人類做權衡（主要是因爲AI無法替代人來承擔權衡失敗的結果）。除非Open AI這種大模型廠商宣佈對AI做出的決策後果負責，否則根據多個因素做出一個次優解的權衡永遠是人類不可逃避的責任和專屬領地。 我們明白了工程難題的本質之後我們要明白自己會犯錯是正常的，要接受自己的歷史侷限性並在別人指出之後及時改正。同時我們也要避免拿着錘子找釘子和追求完美的陷阱，我們唯一需要做的是像《周易》中說的一樣：“君子終日乾乾，夕惕若，厲無咎。” 只有我們每天都記得自己所做的是沒有最優解的權衡，並時刻準備修正自己的錯誤，我們才能在工程活動中避免更大的災難。此話與大家共勉。

用藍盒子馴服天空：承認“不可知”不是無能，而是基於數學邏輯的理性誠實 評分7分 1. 核心主張 * 應對棘手問題，不是僅憑直覺或簡單分割問題的方式，進行有效干預並帶來深刻改進，而取決於更好地對棘手問題進行工程設計（better engineering of wickedness）。這需要一種系統工程學的方法，以及培養一種將工程學概念融入文化和公民參與的公民意識 2. 主要價值 * 提供一種系統工程學的思維模式和方法論——即“運行概念”（Concept of Operations, ConOps），幫助人們負責任地評估和處理生活中最難纏的、具有多面性和矛盾性的“棘手問題”（Wicked Problems） 3. 要點 * 哲學家卡爾·波普爾（Karl Popper）的“時鐘與雲朵”（Clocks and Clouds）隱喻來分類問題，論證棘手問題的不可預測性 * 棘手問題不是兩面性問題，是六面性問題，效率（Efficiency）、模糊性（Vagueness）、脆弱性（Vulnerability）、安全（Safety）、維護（Maintenance）、韌性（Resilience），處理棘手問題必須應用多準則方法 * 問題層次：“硬性問題”（Hard）、“軟性問題”（Soft）和“混亂問題”（Messy），相互作用 * 硬性（Hard）：有明確邊界，可優化（Optimize）/解決（Solution）。軟性（Soft）：涉及人類行爲，結果不明確，可滿意夠用（Satisfice）/化解（Resolution）。混亂（Messy）：由價值觀衝突產生，需理想化（Idealize）/消融（Dissolution） * 拉塞爾·阿考夫（Russell Ackoff）的觀點，區分了“解決”（Solution，針對硬性問題，目標是優化）、“化解”（Resolution，針對軟性問題，目標是滿意夠用，即 satisficing）和“消融”（Dissolution，針對混亂問題，目標是理想化）三種不同的問題應對策略 * “怪物方程”（the monster equation） I=2^n*(n−1) 來量化系統的潛在狀態，以直觀展示覆雜系統的爆炸性複雜程度 * 書中列舉了飛行模擬機、波士頓糖蜜災難、卡特莉娜颶風、冰島火山危機、福島核事故、美國海軍命中率提升的案例，道路修建時候從單純的物理效率（技術參數）轉向經濟和社會效率（公共福利）也是不錯的案例，從投入大於產出、到機會成本、到支付意願，效率不僅僅是數學計算，還涉及人類的慾望、選擇和行爲（軟問題） 4. 洞見 * 識別問題（時鐘 or 雲朵）→問題結構分類（軟、硬、混？）→硬性要素（Hard）：可優化（Optimize），通過技術解決（Solution）；軟性要素（Soft）：涉及人類行爲和偏好，可滿意夠用（Satisfice），通過化解（Resolution）；混亂要素（Messy）：涉及價值觀衝突，可理想化（Idealize），通過消融（Dissolution）→嘗試從多角度（as many angles as possible）進行問題分解→運行概念用六大屬性過濾器，確保解決方案考慮了所有方面→多準則行動與整合，擁抱矛盾，尋找“協同作用”（synergies） 5. 啓示 * 應該從優化的思維（如，平衡效率和安全），到多準則評估的方向進行轉向，確保結論在其他維度不會造成災難性後果，更加不要不要把雲當成時鐘來修。 * 人類的認知帶寬是有限的，而系統的複雜性是無限的。承認“不可知”不是無能，而是基於數學邏輯的理性誠實 * 對安全的錯誤感知或對系統能力的誇大承諾更加可怕，The promise or perception of a system when it does not exist is perhaps more dangerous than no system at all. * 一些解決方案要從技術解決到文化消融、從“創新”（Innovation）轉向“維護”（Maintenance）轉向，因爲維護是現代性的基礎，對現有系統的長期投入比盲目追求新技術更爲重要，能夠避免“緩慢災難” Source：用藍盒子馴服天空 《Wicked Problems: How to Engineer a Better World》 Guru Madhavan