AI 時代的軟體進化論

在今天的許多企業中，大部分決策、執行、驗證和改進都在軟體系統上進行。客戶觸點、定價和合同變更、供應和庫存調整、日誌收集和分析，以及內部運營工作流——所有這些都深度依賴軟體。這不再是IT僅僅被引入的階段；業務本身的運作與軟體狀態緊密相連，更新軟體的能力已等同於更新業務的能力。

這種情況不限於特定行業。跨越各個行業和企業規模，以一定速度和複雜度運營的企業已無法在沒有軟體作為核心的情況下運作。隨著外部條件變化越來越快，決策—執行週期的頻率不斷增加，變化的能力本身成為了競爭因素。當客戶價值、服務條件、運營約束、監管要求和成本結構的變化疊加時，無法更新軟體的企業就無法將決策轉化為行動，無法進行修正，最終陷入停滯。

在這種環境下，可以觀察到許多軟體更新成為業務決策和政策變更瓶頸的案例。決策可能已經做出，但執行所需的結構性變更無法及時完成，縮小了可以實際測試的舉措範圍。

軟體更新所需時間越長，決策與執行之間的距離就越大。在這段延遲期間，環境條件持續變化。結果，越來越多的決策未被執行，業務的運營範圍逐漸收縮。

當我們審視長期使用的軟體時，很少發現系統仍保持其原始狀態。功能被新增，配置被更改，運營被調整，軟體演變為與初始設計截然不同的形態。早期規範或設計文件在數年後仍能完全匹配實現和運營現實的情況並不常見。這並不意味著原始設計毫無意義；相反，它反映了一個觀察——初始時假定的條件在長期運營中難以保持。

隨著軟體持續使用，最初未預料到的任務和決策成為日常運營的一部分。使用者行為發生變化，資料的數量和含義不斷演變，與周圍系統的關係也在轉變。額外的處理、重組、替換和變通方案不斷積累。最初看起來像是小例外的東西最終成為常態，這些常態向內部結構施加外推力。隨著時間推移，曾經簡單明瞭的設計在吸收現實世界需求後變得更加複雜。

同一批人在系統整個生命週期中始終保持負責也並不常見。開發者和運維人員更替，組織結構演變，角色重新分配。即使文件仍在，過去決策背後的上下文假設也未被完全共享。丟失的不是資訊量，而是早期決策成立的一組條件。當這些假設消退時，相同的文字不再導向相同的結論。變更變得更加謹慎，區域性變通方案增多，整體一致性逐漸惡化。

這些變化並非源於特定故障或異常情況。類似的模式在不同組織、行業和技術領域中反覆出現。它們共同的特點是，軟體在長期使用的同時，周圍條件持續變化。儘管這些變化的性質因環境而異，但變化持續存在這一事實是共通的。

假設中的微小差異隨時間累積。曾經可以透過常規運營吸收的調整最終需要結構性重新考慮。在那個節點，變化的權重和範圍增加。隨著影響範圍擴大，驗證成本上升，回滾變得更加困難，決策制定放緩。當決策放緩時，企業無法再測試他們想嘗試的東西。這種狀態不是質量低下，而是學習受阻——環境變化越快，這種損害就越大。

許多開發工作傳統上遵循這樣一種模式：在實施開始之前儘可能地確定設計。這種方法對於建立共識、實現分工和大規模專案管理是有效的。在實施成本高、實驗昂貴的環境中，儘早固化設計是務實的選擇，設計起到了預先降低複雜性的作用。

然而，這種方法有固有的時間結構約束。從設計完成的那一刻起，它所假設的條件就開始變化。設計完成和實施之間的間隔越長，假設與現實之間的偏差就越大。當條件快速變化時，到系統完成時這種偏差可能變得很大。發生變化的往往不是次要的規格細節，而是基本優先事項、運營約束或資料的含義。

這並不意味著設計是錯誤的。在很多情況下，它是當時最好的決策。問題在於沒有考慮到假設會隨時間推移而變化這一事實。如果完成後的調整沒有被內建在內，系統在完成的那一刻就變得難以更新。當完成被視為終點時，後續變更被作為例外處理，作為事後補充而累積。隨著時間推移，更新以區域性修復的形式堆積，結構硬化，業務的學習速度下降。

這種開發方法的出現有明確的原因。高實施成本和沉重的實驗負擔使得早期規劃至關重要。評估條件、組織依賴關係和預先定義完整系統的能力在此類環境中發揮了關鍵作用。建立共識、風險前置和結構化分工是實際的必要條件。

隨著條件變化，價值的位置也隨之變化。過去的判斷、失敗和調整不會變得無效。相反，它們被以不同方式引用和應用。從設計評審中獲得的經驗不再用於完美預測未來，而是用於識別系統在變化下可能在哪裡斷裂。運營教訓告知哪些基礎應保持固定，哪些領域應保持靈活。過去的經驗不是被丟棄的；它是被重新使用的。

隨著這種重用變得可能，經驗的價值往往增加而非減少。在快速變化的環境中，錯誤的判斷會迅速放大。更低的實驗成本意味著更多的嘗試——包括錯誤的嘗試。因此，優先排序和方向判斷的質量對結果的影響更大。

近年來，開發條件出現了明顯變化。實施和實驗的成本已經下降，將假設轉化為可測試形式所需的時間已經縮短。這種轉變部分由直接支援程式碼生成和修改的AI軟體的廣泛採用所驅動。這些工具降低了驗證實現的初始成本，使得嘗試、廢棄和重構設計變得可行。

這裡重要的不是AI是否被採用，而是條件已經改變。當條件改變時，在其下有效運作的結構也會改變。

重要的是，這不是將AI驅動的開發與人類驅動的開發對立起來的問題。正在發生的是人類判斷——如優先排序、結構決策和上下文理解——與AI輔助程式碼生成和修改的融合。人類決定嘗試什麼和在哪裡改變；AI降低實施這些決策的成本。透過這種協作，以前不切實際的速度進行實驗和學習已成為可能。

因此，持續更新軟體以配合業務變化的開發方式首次成為現實選擇。

在這些條件下，允許事後調整的結構比試圖預先固定一切的結構更易管理。隨著規模增長和需求演變，重新審視和修改結構的能力成為先決條件。這並不意味著放棄設計。它意味著縮小固定基礎，清晰定義什麼應該保持靈活，並在明確優先順序的情況下保持漸進重組結構的能力。基礎設計變得更加重要，而非更不重要。

隨著系統擴充套件，基礎設施不可避免地被替換。曾經足夠的配置需要冗餘、分割槽、分佈、可觀測性和恢復機制。持續運營帶來重組和功能擴充套件的需求。在實際環境中，升級、降級、回滾、分階段遷移、並行執行和部分替換是常規活動——而非異常事件。無法前後移動的結構在每次變更時增加風險和成本，最終完全停止更新。

因此，軟體結構必須支援可逆性和可替換性。當邊界不清晰且系統向單一方向增長時，變更廣泛傳播，驗證變得粗糙，回滾變得困難。清晰定義的邊界和模組化的替換單元允許學習透過變化繼續進行。

這些決策不能僅靠個人才智。確定什麼保持固定、什麼保持靈活以及哪些變更是可接受的，必須被作為共享假設來對待。這需要的不僅僅是工具選擇或編碼標準；它需要共同的戰術理解。在缺乏此類共享判斷的地方，更新變得依賴個人，速度下降，學習停止。

每次條件變化時，新的約束被新增到軟體和業務中。雖然過去的設計和實現可能不再直接適用，但這並不否定它們背後的經驗。

透過之前的變化形成的判斷——理解系統在哪裡會斷裂、瓶頸在哪裡出現、變化傳播多遠——在條件再次變化時繼續被使用。即使形式變化，這些判斷在決定下一步嘗試什麼和在哪裡介入時重新浮現。

在現代開發環境中，人類情境判斷和AI輔助實現的結合使得此類經驗可以在更短的間隔內被應用。積累的知識仍然嵌入在判斷質量中，並直接流入後續的實現和驗證。

因此，系統不是在每次變化時從頭重建，也不是僵化地保留過去的形式。相反，經驗隨著條件變化被重用，軟體據此進化。

變化將繼續。新技術和約束將出現。但積累的經驗不會丟失。隨著經驗可以被重用的速度和頻率增加，其價值更直接、更一致地反映在結果中。