AI 時代的軟體演進論

在今日的許多企業中，大部分決策、執行、驗證與改進都透過軟體系統完成。客戶接觸點、定價與合約變更、供應和庫存調整、紀錄蒐集與分析，以及內部營運工作流程，全都深度依賴軟體。這早已不只是「導入 IT」的階段；企業本身的運作與軟體狀態緊密相連，更新軟體的能力已等同於更新企業營運的能力。

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

在這種環境下，軟體更新成為企業決策和政策調整瓶頸的情況屢見不鮮。決策已經做出，但執行所需的結構性變更來不及完成，實際可驗證的措施範圍因而縮小。

軟體更新所需時間越長，決策與執行之間的距離就越大。在這段延遲期間，環境條件仍持續變化。結果，越來越多決策無法落實，企業可採取行動的範圍逐漸縮小。

當我們審視長期使用的軟體時，很少有系統仍保持原始狀態。功能持續增加、設定不斷調整、營運方式也隨之改變，軟體最後往往演變成與初始設計截然不同的樣貌。早期規範或設計文件在數年後仍能完全符合實作與營運現況的情況並不常見。這並不代表原始設計毫無意義；相反，它反映出最初假定的條件很難在長期營運中維持不變。

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

系統在整個生命週期中很少由同一批人負責到底。開發者和維運人員更替，組織結構演變，角色重新分配。即使文件仍在，過去決策背後的脈絡與前提也未被完全共享。遺失的不是資訊量，而是早期決策成立的一組條件。當這些假設逐漸淡去，相同的文字便不再導向相同結論。變更因而更加謹慎，局部變通方案增多，整體一致性逐步惡化。

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

假設中的微小差異隨時間累積。曾經可以透過常規營運消化的調整，最終需要從結構上重新審視。屆時，變更的分量和範圍都會增大。隨著影響範圍擴大，驗證成本上升，回滾更困難，決策也隨之放緩。決策一旦放緩，企業就無法再驗證原本想嘗試的方案。這種狀態不是品質低下，而是學習受阻——環境變化越快，這種損害就越大。

許多開發工作傳統上遵循一種模式：在實作開始前儘可能確定設計。這種方法有助於建立共識、落實分工並管理大型專案。在實作成本高、實驗昂貴的環境中，儘早固定設計是務實選擇，設計也能預先降低複雜度。

然而，這種方法有其固有的時間結構限制。從設計完成的那一刻起，它所假設的條件就開始變化。設計完成與實作之間的間隔越長，假設和現實的偏差就越大。當條件快速變化時，系統完成之際，偏差可能已相當可觀。改變的往往不是次要設定細節，而是基本優先事項、營運限制或資料本身的意義。

這並不代表設計錯誤。在很多情況下，它是當時最好的決策。問題在於未考量假設會隨時間變化。如果系統沒有為完成後的調整預留機制，完成的那一刻也會成為難以更新的起點。當「完成」被視為終點，後續變更便會被當成例外和事後補充而持續累積。隨著時間推移，更新以局部修補的形式堆疊，結構逐漸僵化，企業的學習速度也隨之下降。

這種開發方法之所以出現，有其明確原因。高實作成本和沉重的實驗負擔，使早期規劃至關重要。在此類環境中，評估條件、整理相依關係並預先定義完整系統的能力，確實發揮關鍵作用。建立共識、預先處理風險和結構化分工，都是實務上的必要條件。

隨著條件變化，價值的著力點也會改變。過去的判斷、失敗和調整不會變得無效。這些經驗反而會以不同方式被引用和運用。從設計審查中獲得的經驗，不再用於完美預測未來，而是用來辨識系統面對變化時可能在哪裡失效。營運教訓告知哪些基礎應保持固定，哪些領域應保持靈活。過去的經驗不會被丟棄，而會以新的方式繼續發揮作用。

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

近年來，開發條件已明顯改變。實作與實驗成本下降，將假設轉化為可測試形式所需的時間也已縮短。這項轉變部分來自可直接協助產生與修改程式碼的 AI 工具廣泛普及。這些工具降低驗證實作的初始成本，讓嘗試、捨棄與重構設計成為可行選項。

這裡重要的不是是否採用 AI，而是條件已經改變。條件一旦改變，能夠有效運作的結構也會隨之改變。

重要的是，這不是要把 AI 驅動開發與人類驅動開發對立起來。真正發生的是，人類在優先順序、結構決策和脈絡理解上的判斷，正與 AI 輔助產生和修改程式碼的能力結合。人類決定要嘗試什麼、改動哪裡；AI 則降低落實這些決策的成本。透過這種協作，實驗與學習如今能以過去難以想像的速度進行。

因此，持續更新軟體以配合企業營運變化的開發方式，首次成為現實可行的選項。

在這些條件下，允許後續調整的結構比試圖預先固定一切的結構更易管理。隨著規模增長和需求演變，重新審視和修改結構的能力成為先決條件。這並不意味著放棄設計。這代表應縮小必須固定的基礎範圍，明確界定哪些部分應保持彈性，並在優先順序清楚的前提下，保留逐步重組結構的能力。基礎設計變得更加重要，而非更不重要。

隨著系統擴大，基礎設施勢必會被替換。過去足夠的架構，後來會需要備援、分割、分散、可觀測性和復原機制。持續營運也會帶來重組與擴充功能的需求。在實際環境中，升級、降級、回滾、分階段遷移、平行執行和局部替換都是例行活動，而非異常事件。不支援前進、後退與回滾的結構，會在每次變更時增加風險和成本，最後甚至完全停止更新。

因此，軟體結構必須支援可逆性和可替換性。當邊界不清晰且系統向單一方向增長時，變更廣泛傳播，驗證粒度變粗，回滾變得困難。邊界清晰、可模組化替換，才能讓學習在持續變化中延續。

這些決策不能僅靠個人才智。哪些部分保持固定、哪些保持彈性，以及哪些變更可以接受，都必須成為團隊共同的前提。這不只關乎工具選擇或程式碼規範，也需要團隊共享同一套實務判斷。在缺乏此類共享判斷的地方，更新變得依賴個人，速度下降，學習停止。

每當條件變化，軟體和企業營運都會面臨新的限制。雖然過去的設計與實作可能不再直接適用，但這並不否定它們背後的經驗。

以往變更中形成的判斷——理解系統會在哪裡斷裂、瓶頸會在哪裡出現、變化會傳播多遠——在條件再次變化時仍會發揮作用。即使系統形態改變，這些判斷也會在決定下一步嘗試什麼、從哪裡介入時再次派上用場。

在現代開發環境中，人類對情境的判斷與 AI 輔助實作相結合，使這些經驗能以更短週期得到運用。累積的知識仍然體現在判斷品質中，並直接用於後續實作與驗證。

因此，系統不必在每次變化時從頭重建，也不需僵化地保留過去形式。相反，經驗會隨條件變化而重新運用，軟體也據此演進。

變化仍會持續，新技術與限制也會出現。但累積的經驗不會遺失。隨著經驗能被重新運用的速度和頻率提高，其價值會更直接、更一致地反映在結果上。