AI 時代的軟體遺產重構經濟學：從序列執行拓撲到多核、多 Actor 與多 AI 原生架構

The Economics of Legacy Software Reconstruction in the AI Era: From Serial Execution Topologies to Multicore, Multi-Actor, and Multi-Agent-Native Architectures

作者：Neo.K（許筌崴）
機構：一言諾科技有限公司（EveMissLab）
版本：v0.1
日期：2026-08-20
性質：理論論文／軟體工程與 AI 系統架構研究

摘要

大量經典遊戲、企業系統與桌面軟體形成於與今日截然不同的計算條件之下。受限於當時的 CPU 核心數、記憶體容量、圖形與 I/O 架構、工具鏈成熟度、人力成本與單一人類操作者假設，許多系統自然採取高度序列化、共享狀態密集、單一主迴圈、單一焦點、單一權威寫入者或單機邊界明確的軟體拓撲。本文將此類約束統稱為「舊軟體序列時空拓撲」，並強調其不等同於字面上的「所有程式只能使用一顆 CPU 核心」。

本文提出一個核心命題：隨著 AI 程式理解、程式生成、代理式工具使用、多 Agent 協作、自動測試與計算資源持續進步，舊軟體從既有序列拓撲重構為多核、多 Actor、多 AI 原生架構的邊際成本將長期下降。其機制並非 AI 消滅軟體工程，而是 AI 同時壓縮理解、規格抽取、依賴分析、程式重寫、測試生成、差異驗證與修復迭代等多個成本項目。

本文進一步提出 Legacy Reconstruction Cost Model、Parallelizable Topology Model、Irreducible Semantic Lower Bound 與 Reconstruction Crossover Condition。核心判據為：當「繼續維護既有拓撲」的預期總成本高於「解構、重建、驗證與遷移」的成本時，重構會由高風險特例逐步轉化為經濟上合理的常規選項。此轉折對遊戲尤其重要，因為遊戲同時包含長期狀態、即時互動、模擬、AI、圖形、資產、事件、任務、腳本與大量邊界條件，是高複雜度軟體重構的壓力測試場。

本文不主張任意 legacy software 均可完全平行化，也不主張 AI 能消滅因果依賴、規格缺失與驗證成本。相反地，本文提出不可約下界：真正的序列依賴、語義不確定性、行為保真度、安全需求與驗證責任仍會限制重構收益。本文最後討論 HDUS 類計算世界架構作為此種多 Actor、多 AI 與資源圖式軟體的可能承載層，但不將其視為本命題成立的必要條件。

關鍵詞： Legacy Software、Software Modernization、AI-assisted Refactoring、Multicore、Multi-Agent、Multi-Actor、Game Reconstruction、Software Archaeology、Task Graph、HDUS

1. 問題不是「舊軟體能不能跑」，而是它仍活在舊計算時代

一套二十年前的遊戲今天通常可以藉由相容層、模擬器、舊 API、虛擬機或平台移植繼續執行。

但「可以執行」與「其計算拓撲仍然合理」是兩個不同問題。

舊軟體的架構通常同時受到以下條件塑形：

可用 CPU 核心數有限；
thread 與同步工具的工程成本較高；
記憶體與儲存較昂貴；
GPU 與 CPU 工作分配模式不同；
網路延遲高且遠端計算不普及；
CI、fuzzing、property-based testing 與大規模 telemetry 尚未普及；
軟體由有限人類團隊手工維護；
使用者通常被假設為單一人類；
AI 不被視為持續存在的 Actor；
App、Window、Process、Machine 之間高度綁定。

因此，歷史架構可以粗略表示為：

\mathcal{L}_{old} = ( S_g, M, P, F_h, A_h, B_m ),

其中：

$S_g$ ：大量共享或全域狀態；
$M$ ：主要控制迴圈；
$P$ ：以 process/thread 為核心的執行單位；
$F_h$ ：單一 host focus；
$A_h$ ：主要人類操作者；
$B_m$ ：單機邊界。

此模型在當時未必落後，甚至可能是最佳工程解。

真正的問題是：

當計算條件改變後，歷史最優解是否仍然是今日最優解？

本文答案是：未必。

2. 「單核」應被重新定義為序列拓撲問題

本文使用「單核時空困境」時，不將其嚴格定義為：

CPU\ cores=1.

很多經典軟體實際上早已使用多執行緒、音訊執行緒、I/O thread、render thread 或背景工作。

更準確的問題是：

\boxed{ \text{Architectural Serial Fraction} }

即整個系統有多少工作因為歷史架構，而不是因為真正不可約的因果關係，被綁在同一個序列控制流、共享狀態域、單一主迴圈或單一權威節點中。

令軟體工作圖為：

G=(V,E),

其中 $V$ 為工作單位， $E$ 為依賴關係。

若舊架構實際執行序近似：

v_1 \rightarrow v_2 \rightarrow v_3 \rightarrow \cdots \rightarrow v_n,

不代表所有邊：

(v_i,v_{i+1})\in E

都是必要依賴。

其中部分可能只是：

原始程式方便；
global state 難拆；
當年多核收益不足；
工具鏈不適合；
測試成本過高；
團隊沒有足夠時間重構。

因此第一個重要工作不是「平行化」，而是重新估計：

E_{true} \subseteq E_{legacy}.

其中 $E_{true}$ 是真正不可消滅的因果依賴，而 $E_{legacy}$ 包含歷史實作造成的額外耦合。

AI 解構的價值之一，就是協助尋找兩者之差：

E_{accidental} = E_{legacy} - E_{true}.

3. 從軟體考古到可執行規格

傳統 legacy modernization 最困難的階段之一，不是寫新 code，而是理解舊系統到底在做什麼。

一套成熟軟體的真實規格往往分散於：

原始碼；
scripts；
config；
asset metadata；
database schema；
build system；
UI behavior；
bug workaround；
save format；
hidden constants；
undocumented assumptions；
玩家／使用者長期依賴的 emergent behavior。

因此舊系統可表示為：

\mathcal{S}_{legacy} = C + D + A + R + H,

其中：

$C$ ：code；
$D$ ：data；
$A$ ：assets；
$R$ ：runtime behavior；
$H$ ：historical assumptions。

真正的解構不是單純反編譯，而是產生一個中間表示：

\mathcal{M} = ( State, Rule, Event, Dependency, Interface, Invariant, Trace, Artifact ).

只要 $\mathcal{M}$ 足夠完整，後續問題就從：

重新理解整個舊系統。

轉化成：

根據已知 dependency 與 invariant，重新映射到新執行拓撲。

這是問題難度的結構性下降。

4. AI 正在改變 legacy modernization 的成本結構

到 2026 年，AI-assisted modernization 已不只是研究想法。

Microsoft 的 GitHub Copilot modernization 已提供 legacy application assessment、migration planning、framework upgrade、re-architecture 與 agentic transformation；其文件明確描述可由 modernization agents 分析既有專案、產生目標架構並處理重寫。Google Cloud 的 mainframe modernization 工具亦使用生成式 AI 進行 codebase assessment、依賴映射、business rule 抽取與程式轉換。AWS Transform 則把 specialized AI agents、agentic workflows 與 application decomposition 納入 legacy modernization。

同時，多 Agent 軟體工程工具開始產品化。OpenAI Codex、GitHub Copilot Fleet 與 Anthropic 多 Agent 系統都已將任務分解、隔離執行與平行工作視為主要能力。

因此本文不需要提出：

\text{AI can assist modernization}

作為新命題。

更進一步的新問題是：

\boxed{ \text{AI-assisted modernization} \rightarrow \text{topological reconstruction} }

也就是：

當 AI 已能理解、規格化與重寫舊系統後，我們是否仍應只把它遷移成「同一種舊軟體的新語言版本」？

答案未必。

5. Legacy Reconstruction Cost Model

定義舊軟體完整重構成本：

C_R = C_U + C_S + C_D + C_W + C_I + C_V + C_M,

其中：

$C_U$ ：理解與軟體考古成本；
$C_S$ ：規格抽取成本；
$C_D$ ：依賴與拓撲分解成本；
$C_W$ ：重寫成本；
$C_I$ ：整合成本；
$C_V$ ：驗證成本；
$C_M$ ：遷移與相容成本。

在傳統人力模式中：

C_R^{human}

可能極高。

AI 介入後，不應粗暴假定：

C_R^{AI}\rightarrow0.

較合理的模型是：

C_R(t) = \sum_i \alpha_i(t)C_i^{human} + C_{compute}(t) + C_{coord}(t),

其中：

0\le\alpha_i(t)\le1

表示某一成本項目仍需多少人類等價工作量。

若 AI 能力、agent tooling、test generation 與 compute 持續進步，則多個 $\alpha_i(t)$ 具有下降可能：

\frac{d\alpha_U}{dt}<0,

\frac{d\alpha_S}{dt}<0,

\frac{d\alpha_D}{dt}<0,

\frac{d\alpha_W}{dt}<0,

\frac{d\alpha_V}{dt}<0.

因此核心猜想為：

\boxed{ \frac{dC_R}{dt}<0 }

這不是數學必然定理，而是需要長期工程資料驗證的技術經濟假說。

6. 重構的真正目標：重新求一次計算拓撲

舊軟體現代化常見目標包括：

語言升級；
framework 升級；
containerization；
cloud migration；
API 化；
database migration。

本文提出另一個維度：

\boxed{ \text{Execution Topology Modernization} }

也就是不只問：

用什麼語言重新寫？

而要問：

哪些計算單位今天根本不必再被綁在一起？

令舊執行時間為：

T_{old} = \sum_{i=1}^{n}T_i.

若解構後得到平行集合：

\mathcal{P} = \{P_1,P_2,\ldots,P_k\},

理想新時間近似：

T_{new} \approx \max_j T(P_j) + T_{sync} + T_{coord}.

因此收益：

S = \frac{T_{old}}{T_{new}}.

但此式只在工作真正獨立時成立。

若錯誤拆分依賴，系統會付出：

C_{race} + C_{rollback} + C_{consistency}.

所以重構的真正價值不在「使用更多核心」，而在：

\boxed{ \text{識別正確的並行邊界} }

7. Amdahl 上界仍然存在

任意系統都存在不可平行部分。

令 $p$ 為可平行化比例， $N$ 為有效工作單位數，並加入協調成本 $\omega(N)$ ：

S(N) \le \frac{1}{ (1-p) + \frac{p}{N} + \omega(N) }.

即使：

N\rightarrow\infty,

也不代表：

S(N)\rightarrow\infty.

因為：

1-p>0

以及：

\omega(N)>0.

例如：

\text{Damage} \rightarrow \text{Death Check} \rightarrow \text{Drop Resolution}

具有真實因果順序。

AI 不能因為會寫程式，就把因果律消滅。

因此「AI 多核化」真正能消除的是：

E_{accidental},

而不是：

E_{true}.

8. 遊戲是此命題的高難度測試場

遊戲之所以重要，不只是因為市場價值。

它是一種高度混合軟體：

Game = Simulation + Rendering + Input + AI + Physics + Audio + UI + Scripting + Persistence + Narrative.

其中同時存在：

frame-sensitive work；
長期世界狀態；
大量資料與資產；
玩家可見的行為保真度；
不可完全形式化的「手感」；
emergent interactions；
大量 rare-state combinations。

因此若 AI 可以可靠地將一套經典遊戲從舊拓撲重構成現代多核、多 Actor、多 AI 版本，代表其能力不只是「會生成 CRUD application」。

遊戲可以被視為：

\boxed{ \text{Legacy Reconstruction Stress Test} }

9. 從「NPC AI」到多層智能計算

傳統遊戲 AI 常表示為：

FSM, \quad BT, \quad Utility, \quad Planner.

未來重構不應簡化成：

每個 NPC 都掛一個大型語言模型。

這在成本、延遲與一致性上通常不合理。

更可行的是分層：

\text{World AI} \rightarrow \text{Faction AI} \rightarrow \text{Group AI} \rightarrow \text{Character AI}.

而每層可以使用不同計算模型：

M_i \in \{ FSM, BT, Utility, SmallModel, LargeModel, RuleEngine \}.

因此 AI-native game architecture 的重點不是：

LLM\ everywhere,

而是：

\boxed{ \text{Dynamic Intelligence Allocation} }

即依據：

角色重要性；
事件風險；
玩家距離；
世界狀態；
budget；
latency；
narrative demand；

動態決定智慧層級。

10. Multi-Actor 比 Multi-Agent 更一般

未來軟體不只要支援多 AI。

它還可能同時存在：

A = \{ Human, AI_1, AI_2, Service, RemoteHuman, Automation \}.

因此真正的軟體現代化方向之一是：

\boxed{ \text{Single-Operator Software} \rightarrow \text{Multi-Actor Software} }

它要求重新思考：

input ownership；
focus；
authority；
transaction；
conflict；
resource identity；
observation；
provenance。

傳統：

1\ Human + 1\ Cursor + 1\ Focus

不再是唯一合理的操作模型。

這使 legacy reconstruction 不只是一個 performance problem，也是一個 interaction ontology problem。

11. Multi-Agent Reconstruction 本身也需要拓撲

若重構系統由多 AI 執行，可以表示為：

\mathcal{A} = \{A_0,A_1,\ldots,A_n\}.

但：

|\mathcal{A}|\uparrow

不保證：

Productivity\uparrow.

多 Agent 本身存在：

C_{coord} = C_{communication} + C_{merge} + C_{conflict} + C_{duplicate} + C_{verification}.

因此最佳 Agent 數量應與當前可獨立工作的前沿相關：

N^* \approx |\mathcal{F}_{independent}|.

其中：

\mathcal{F}_{independent}

是 task graph 上目前可在不等待彼此的情況下執行的工作集合。

這與 GitHub Fleet、OpenAI multi-agent coding 與 Anthropic orchestrator-worker 系統觀察到的工程事實一致：平行 Agent 對獨立子任務最有效，而依賴密集工作會受到協調成本限制。

12. 經典遊戲「重製」可能被重新定義

傳統 remake 常聚焦：

Graphics + Resolution + Assets + EnginePort.

但 AI 時代可能出現第二類：

\boxed{ \text{Computational Remake} }

其核心不是換貼圖，而是：

\text{Old Behavior} \rightarrow \text{New Computational Topology}.

例如：

main-loop-bound NPC simulation 被拆成 task graph；
faction simulation 可獨立運行；
pathfinding 分散到 worker pool；
narrative AI 成為可選智慧層；
save state 被提升為可版本化 world state；
single-focus interaction 改為 multi-actor transaction；
legacy modules 被逐步包裝為 Resources；
AI agents 可在隔離 scope 中讀、改、驗證世界。

所以：

\text{Remake} \neq \text{Visual Upgrade}.

它可能變成：

\boxed{ \text{Temporal-Spatial Computational Reconstruction} }

13. 維護與重構的交叉點

令未來一段時間內持續維護 legacy system 的成本為：

C_L(H),

其中 $H$ 是時間 horizon。

令完整現代化重構成本為：

C_R(t).

則存在可能的 crossover：

\boxed{ C_R(t^*) < C_L(H) }

一旦成立：

重構比繼續維護古董更便宜。

此時軟體遺產的經濟性會改變。

過去某套軟體可能因為：

code 太亂；
文件缺失；
原作者離開；
regression test 不足；
rewrite 風險太高；

而永遠留在 legacy state。

AI 若持續降低：

C_U+C_S+C_D+C_W+C_V,

就可能將部分「不可重寫」系統推入可重構區域。

這是本文最重要的經濟命題。

14. 不可約語義下界

本文反對一個過度樂觀結論：

C_R\rightarrow0.

即使 AI 極強，仍存在：

\boxed{ C_{min} = C_{semantic} + C_{serial} + C_{verification} + C_{migration} + C_{risk}. }

14.1 語義下界

若原軟體某些規則從未被文件化，也無可觀察行為足以反推，AI 無法憑空知道唯一正確答案。

14.2 序列下界

真正具有因果順序的 state transition 不能任意平行化。

14.3 驗證下界

「能生成」不等於「已證明等價」。

14.4 遷移下界

玩家存檔、企業資料、插件、生態系與外部 API 都可能形成現實約束。

14.5 風險下界

安全關鍵、金融、醫療或大型線上服務的錯誤成本可能遠高於程式生成成本。

因此本文真正主張的是：

C_R(t)\downarrow,

而不是：

C_R(t)\rightarrow0.

15. Behavioral Oracle 與差異驗證

若原系統仍可執行，它本身可以部分充當 behavioral oracle。

對狀態：

s_i

輸入動作：

a_i,

舊系統得到：

o_i^{old}.

新系統得到：

o_i^{new}.

可以建立：

d( o_i^{old}, o_i^{new} ) < \epsilon.

更完整地：

\mathcal{T} = \{ (s_i,a_i,o_i) \}_{i=1}^{N}.

透過：

replay；
fuzzing；
generated states；
save-state mutation；
differential testing；
property checking；

大量產生行為對照。

AI 與算力上升的另一個重要作用，就是讓：

N\uparrow

的成本下降。

因此，重構能力的提高不只來自更會寫 code，也來自：

\boxed{ \text{More Affordable Verification} }

16. 但 Behavioral Oracle 不是完整真理

舊系統輸出：

o_i^{old}

不代表：

o_i^{old} = \text{Intended Behavior}.

因為原版可能包含：

bug；
undefined behavior；
accidental exploit；
platform-specific artifact；
frame-rate dependency；
race condition。

因此 reconstruction 必須區分：

\text{Observed}

\text{Intended}

\text{Preserved}

三種語義。

對經典遊戲尤其如此：

某個 bug 可能已成為 speedrun 技巧。

此時：

Bug_{historical}

是否應被修掉，不是單純技術問題，而是產品與保存策略問題。

17. 三種重構目標

因此本文提出三種 reconstruction mode。

Mode A：Behavior-Preserving Reconstruction

目標：

\mathcal{B}_{new} \approx \mathcal{B}_{old}.

主要重構底層拓撲，不改變使用者可觀察行為。

Mode B：Semantics-Preserving Modernization

保留核心規則，但允許修復：

performance bottleneck；
known bug；
unsafe behavior；
obsolete interface。

Mode C：Generative Expansion

以原系統為基底：

\mathcal{S}_{old} \subset \mathcal{S}_{new}.

直接加入：

multi-AI；
richer simulation；
persistent world；
dynamic content；
multi-actor interaction；
new resource graph。

第三種才是真正可能把「經典軟體」變成 AI 時代新系統的模式。

18. 從 legacy executable 到 computational world

傳統遊戲或軟體經常被理解為：

Application = Executable.

但重構後可以改為：

\boxed{ Application = Persistent\ Computational\ World. }

例如：

\mathcal{W} = ( Actors, Resources, Fields, State, Capabilities, Transactions ).

此時：

rendering 只是 projection；
process 只是 execution backend；
AI 是 Actor；
NPC simulation 是 Field；
save 是 world-state serialization；
remote compute 是 Resource；
human input 是 Actor action；
legacy executable 可以退化成 compatibility Resource。

這正是 HDUS 類架構可能介入的地方。

19. HDUS 的角色：承載層，而非必要前提

本文命題不依賴 HDUS 才成立。

任何可以提供：

multi-actor identity；
task/field abstraction；
resource graph；
capability；
transaction；
provenance；
heterogeneous execution；

的 runtime 都可以支援此方向。

但 HDUS 的 World / Field / Actor / Resource 模型天然適合描述：

\text{Legacy Software} \rightarrow \text{Multi-Actor Computational World}.

因此可以想像漸進遷移：

LegacyExecutable \rightarrow LegacyResource \rightarrow ExtractedResources \rightarrow NativeFields \rightarrow MultiActorWorld.

這比一次性 rewrite 更安全。

舊系統可以在重構期間繼續執行，新模組逐步取代舊模組。

20. 漸進式拓撲替換

理想重構不必是：

Old \rightarrow Delete \rightarrow New.

而可以是：

\mathcal{S}_0 \rightarrow \mathcal{S}_1 \rightarrow \mathcal{S}_2 \rightarrow \cdots \rightarrow \mathcal{S}_n.

每一步只替換一個 topology boundary。

例如：

MainLoop \rightarrow MainLoop+WorkerPool,

再：

NPCSystem \rightarrow NPCField,

再：

QuestState \rightarrow VersionedResource,

再：

SingleHumanInput \rightarrow MultiActorBroker.

若每一步都具有 differential test 與 rollback，重構風險可顯著下降。

21. 一個可測量的 Modernization Index

為避免把「AI 原生化」寫成宣傳詞，本文提出初步指標：

MI = w_1P + w_2D + w_3A + w_4V + w_5R,

其中：

$P$ ：可安全平行化比例；
$D$ ：依賴顯式化程度；
$A$ ：multi-actor readiness；
$V$ ：verification coverage；
$R$ ：resource decoupling。

並滿足：

\sum_iw_i=1.

此指標不主張為通用標準，只作為比較 legacy 與 reconstructed architecture 的研究工具。

更重要的量則是：

\Delta MI = MI_{new} - MI_{old}.

如果：

\Delta MI>0

但：

Cost_{runtime}

或：

RegressionRate

大幅惡化，仍不能稱為成功。

22. 真正的成功函數

因此重構成功不等於：

MoreThreads + MoreAgents.

本文提出：

Q_R = f( Fidelity, Performance, Maintainability, Parallelism, Verifiability, Cost, Risk ).

成功重構至少要同時提高部分指標，而不能以嚴重犧牲其他指標換取表面上的「多核」。

尤其：

Parallelism\uparrow

若導致：

Consistency\downarrow\downarrow,

就是失敗。

同理：

AI\ Actors\uparrow

若：

CoordinationCost\uparrow\uparrow,

也不是進步。

23. 核心命題

本文最終提出五個命題。

命題一：AI 重構成本下降命題

在模型能力、工具使用、自動驗證與算力持續進步的條件下，部分 legacy software 的有效重構成本具有長期下降趨勢：

\boxed{ \frac{dC_R}{dt}<0. }

命題二：歷史序列耦合可分離命題

舊軟體的序列依賴可以分解為：

\boxed{ E_{legacy} = E_{true} \cup E_{accidental}. }

現代化主要作用於：

E_{accidental}.

命題三：重構交叉點命題

對部分長期維護系統，存在：

\boxed{ t^*: C_R(t^*) < C_L(H). }

此後重構可能比維護 legacy architecture 更具經濟性。

命題四：多 AI 非單調收益命題

多 Agent 數量增加不保證效能單調上升：

\boxed{ N_{AI}\uparrow \not\Rightarrow Performance\uparrow. }

存在由 task graph、communication 與 shared-state constraints 決定的有效區間。

命題五：軟體遺產拓撲可再生成命題

當舊系統的狀態、規則、依賴、介面與行為被充分解構後，其實作拓撲不必被視為不可變歷史事實：

\boxed{ \text{Preserve Semantics} \not\Rightarrow \text{Preserve Execution Topology}. }

這是本文最核心的一句。

24. 可證偽條件

本文不是以不可證偽的未來預測收尾。

若未來實驗普遍顯示：

AI 對 large legacy systems 的理解成本沒有隨能力提升下降；
AI 產生的 reconstruction specification 長期無法達到可驗證完整度；
multi-agent coordination cost 抵消大多數重構收益；
differential testing 無法有效控制 semantic drift；
legacy maintenance cost 長期仍顯著低於 AI reconstruction cost；

則本文的強形式：

\frac{dC_R}{dt}<0

至少需要被限制於更小的軟體類別。

相反地，若 longitudinal benchmarks 顯示：

C_R^{2028} < C_R^{2026}

並且：

Q_R^{2028} \ge Q_R^{2026},

則可以逐步累積支持。

25. 建議實驗

Experiment A：經典小型遊戲

選擇具有：

可取得 source 或合法分析版本；
deterministic replay；
中等規模；
清楚 game state；

的舊遊戲。

比較：

HumanOnly

與：

Human+AI

重構成本。

Experiment B：拓撲抽取

要求 AI 從 legacy code 建立：

G_{legacy}.

再由獨立 verifier 檢查：

E_{true}

與：

E_{accidental}.

Experiment C：Behavioral Oracle

產生：

10^3, 10^4, 10^5

級狀態與 replay，觀察 reconstruction divergence。

Experiment D：多 Agent 重構

比較：

N=1,2,4,8,16

時：

completion time；
token/compute；
merge conflicts；
regression count；
repair cycles。

用實驗估計：

N^*.

Experiment E：Legacy vs Native Topology

比較：

\mathcal{S}_{legacy}

與：

\mathcal{S}_{reconstructed}

在：

throughput；
latency；
CPU utilization；
scalability；
maintainability；
observability；

上的差異。

26. 對未來軟體產業的含義

如果本文命題成立，AI 可能不只提高「新軟體生成速度」。

更深層的變化是：

\boxed{ \text{Software Heritage Becomes Recomputable}. }

也就是軟體遺產從：

固定的 historical implementation

逐漸變成：

可被重新理解、重新規格化、重新驗證與重新生成的 semantic artifact。

這會改變：

remake；
remaster；
emulator；
enterprise modernization；
operating-system migration；
game preservation；
abandoned software；
scientific code；
infrastructure software；

的成本曲線。

歷史 code 不再必然等於歷史 architecture。

27. 結論

本文提出的不是：

AI 未來可以把所有舊遊戲自動多核化。

而是一個更一般、也更可驗證的命題。

舊軟體的執行拓撲受到其誕生時代的硬體、工具與人力條件塑形。當 AI、agent tooling、自動驗證與計算資源發生質變時，維持舊拓撲的理由也可能失效。

因此：

\boxed{ \text{Legacy Semantics} \neq \text{Legacy Topology}. }

只要能將：

State, Rule, Dependency, Invariant, Behavior

從歷史 implementation 中抽離，新的實作就可以重新尋找：

\text{Parallelism}, \text{Multi-Actor}, \text{Multi-Agent}, \text{Distributed Resources}.

真正不能被 AI 消滅的，是：

\text{Irreducible Causality} + \text{Semantic Uncertainty} + \text{Verification Responsibility}.

但除此之外，大量過去因成本過高而被視為「只能這樣維護」的歷史耦合，可能逐步變成可重新計算的工程選擇。

若此趨勢延續，AI 對軟體史最深的影響之一，或許不只是生成更多新程式，而是讓人類第一次有能力以較低成本重新計算舊軟體的整體架構。

參考資料

OpenAI. Introducing the Codex App. 2026.
OpenAI. Codex: AI Coding Agents for Software Engineering. 2026.
GitHub. Running Tasks in Parallel with the Fleet Command. GitHub Docs, 2026.
GitHub. Custom Agents and Sub-Agent Orchestration. GitHub Docs, 2026.
Anthropic. How We Built Our Multi-Agent Research System. 2025.
Microsoft Learn. GitHub Copilot Modernization Overview. 2026.
Microsoft Learn. Re-architect Projects by Using GitHub Copilot Modernization. 2026.
Google Cloud. Mainframe Assessment Tool Overview. 2026.
Google Cloud. Mainframe Migration and Modernization with AI. 2026.
AWS. AWS Transform Migration Launch Guide. 2026.
AWS Prescriptive Guidance. Understanding Application Decomposition. 2026.
Amdahl, G. M. Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities. AFIPS, 1967.

理論地位聲明

本文提出之成本函數、重構交叉點、Modernization Index 與長期下降關係均屬理論模型與可驗證命題，不代表已被產業資料普遍證實。文中對未來多核、多 Actor、多 AI 軟體架構的推論應透過 longitudinal benchmark、legacy reconstruction experiment、behavioral differential testing 與實際維護成本資料持續檢驗。