# 軟體時代鑲嵌假說：時代拓撲論視角下的企業、工程師、工具鏈、教育與 AI 採用非同步

**Software Epoch Mosaic Hypothesis: Asynchronous Epoch Topologies of Firms, Engineers, Toolchains, Education, and AI Adoption**

**作者：** Neo.K  
**機構：** EveMissLab / 無界智庫研究體系  
**日期：** 2026-09-17  
**版本：** v0.1  
**文件類型：** 時代拓撲論應用研究 / 命題假說論文  
**前置理論：** 《時代拓撲論 v2.0》；《時代拓撲論：通用週期、超前距離與跨層普及》  
**研究狀態：** $C_0$ 理論建模；具備外部產業與教育資料之初步實證錨點  

**公司：** 一言諾科技有限公司  

---

## 摘要

同一個 2026 年，一家軟體公司的不同團隊可能同時使用數十年前形成的語言與工具、近十年的雲端與自動化架構，以及剛出現一兩年的 AI Agent 工作流。某些資深工程師持續更新技術棧，某些年輕工程師則可能工作於高度 legacy 的組織；某些教授研究前沿主題，實際授課內容卻仍受教材、課綱、實驗環境與制度約束而停留在更早的工程狀態。

本文以《時代拓撲論》為母框架，提出 **Software Epoch Mosaic Hypothesis，軟體時代鑲嵌假說**：

> 軟體公司、工程團隊、教育機構與個體工程師並不共同存在於一條單調的新舊技術時間線上，而是同時佔據多個互相耦合但不同步的技術、工程流程、組織與認知狀態。現代軟體世界更接近一個由不同技術時代局部區塊拼接而成的動態鑲嵌拓撲。

因此：

$$
\boxed{
t_i=t_j
\not\Rightarrow
\Sigma_i^{\mathrm{software}}
=
\Sigma_j^{\mathrm{software}}.
}
$$

本文進一步反對：

$$
\boxed{
\text{Newer}
\Rightarrow
\text{Better}
\Rightarrow
\text{Market Winner}.
}
$$

市場並不直接選擇「最新技術」，而是在特定約束條件下選擇具有局部適應度的技術組合。某些舊技術可能是長期穩定基底，某些是特定 domain 的高適應度工具，某些則只是高遷移成本造成的歷史延續；只有其中一部分應被稱為真正的 **Epoch Lag，時代滯後**。

本文因此提出四類技術狀態：

$$
\boxed{
\mathcal L
\in
\{
\text{StableSubstrate},
\text{DomainOptimalLegacy},
\text{TransitionalCoexistence},
\text{EpochLag}
\}.
}
$$

本文亦提出企業軟體時代狀態束：

$$
\boxed{
\mathfrak S_x(t)
=
\{
\Sigma_x^K,
\Sigma_x^L,
\Sigma_x^A,
\Sigma_x^V,
\Sigma_x^Q,
\Sigma_x^C,
\Sigma_x^D,
\Sigma_x^{AI},
\Sigma_x^O
\}_t,
}
$$

分別表示知識、語言／Runtime、架構、版本控制、品質工程、CI/CD、自動化部署／基礎設施、AI 工程與組織治理狀態。

現有資料提供若干明顯的「鑲嵌」實例。JetBrains 2025 遊戲開發調查中，AAA studio 的版本控制同時大量使用 Perforce P4、GitHub、GitLab、Azure DevOps Server 與 Subversion；其中 Perforce P4 在 AAA studio 的使用率達 45%，而 GitHub 在 Mid-size / Indie 與 Hobbyist 的使用率分別達 61% 與 79%。同一產業內，不同規模與資產工作流形成完全不同的工具拓撲。

JetBrains 2025 CI/CD 調查也顯示，32% 的組織同時使用兩套 CI 工具，9% 使用至少三套；報告並直接描述 legacy pipelines、新工具遷移、合規、成本與既有基礎設施共同造成的 adoption lag。這表示企業中的「新舊共存」並非單純管理失敗，而常是 path dependence 與 migration distance 的結果。

AI 時代又使此差距放大。Stack Overflow 2025 調查中，84% 的受訪者已使用或計畫使用 AI 開發工具，51% 的 professional developers 每天使用；然而 AI Agent 並未同步普及，52% 的開發者仍不使用 Agent 或停留在較簡單 AI 工具，38% 沒有 Agent 採用計畫。這顯示「有使用 AI」本身不足以描述工程時代狀態。

教育層同樣如此。ACM/IEEE-CS/AAAI 的 CS2023 已明確將 version control、testing、code review、tooling、CI、dependency management、reproducible builds、modern IDE 與 ML-powered code assistants 納入 software engineering 教學內容；但既有研究早已指出 academia–industry skill gap，尤其在 configuration management、software process、architecture 與 testing 等領域。這使「教授知道什麼」與「學生實際被教授什麼」必須分離：

$$
\boxed{
\text{Professor Knowledge}
\neq
\text{Delivered Curriculum}.
}
$$

本文最終主張，軟體工程是時代拓撲論中特別適合量化的實證領域，因為 repository、dependency、toolchain、CI pipeline、language version、deployment architecture 與 AI usage 都留下可觀測的「技術化石層」。未來可以建立 software epoch distance、organization epoch fracture 與 curriculum epoch lag 等可計算指標。

**關鍵詞：** 時代拓撲論、軟體時代鑲嵌、技術債、legacy system、CI/CD、GitHub、Perforce、AI Agent、軟體教育、academia-industry gap、migration cost、path dependence

---

# 1. 從「2026 年軟體公司」的錯覺開始

日曆時間提供：

$$
\boxed{
t=2026.
}
$$

但這只能表示：

> 組織存在於 2026 年。

不能推出：

$$
\boxed{
\Sigma_{\mathrm{organization}}
=
\Sigma_{\mathrm{frontier},2026}.
}
$$

一家公司完全可能同時包含：

```text
C++ legacy core
Java 8 backend
TypeScript frontend
Python data stack
Perforce asset pipeline
GitHub repositories
Jenkins CI
GitHub Actions experiments
VM deployment
container deployment
no-AI teams
Copilot teams
agentic-development experiments
```

因此「公司所處時代」不是單一 scalar。

---

# 2. 與《時代拓撲論 v2.0》的關係

《時代拓撲論 v2.0》的核心命題是：

$$
\boxed{
\text{時代不是物理時間的函數，
而是多維拓撲結構。}
}
$$

物理時間只是演化參數與投影軸。

本文將此原理特化到軟體工程：

$$
\boxed{
\text{Software Epoch}
\neq
\text{Calendar Year}.
}
$$

同樣位於 2026 年的公司、團隊、教授、學生與程式碼庫可以位於完全不同的 software epoch neighborhood。

---

# 3. Software Epoch State Bundle

本文定義軟體時代狀態束：

$$
\boxed{
\mathfrak S_x(t)
=
\{
\Sigma_x^K,
\Sigma_x^L,
\Sigma_x^A,
\Sigma_x^V,
\Sigma_x^Q,
\Sigma_x^C,
\Sigma_x^D,
\Sigma_x^{AI},
\Sigma_x^O
\}_t.
}
$$

---

## 3.1 $\Sigma^K$ ｜Knowledge State

包括：

- 基礎 CS 知識；
- 現代軟體工程知識；
- security；
- distributed systems；
- concurrency；
- formal methods；
- AI-assisted development。

---

## 3.2 $\Sigma^L$ ｜Language / Runtime State

包括：

- language generation；
- runtime；
- compiler；
- type system；
- package ecosystem；
- dependency management。

---

## 3.3 $\Sigma^A$ ｜Architecture State

包括：

- monolith；
- modular monolith；
- service architecture；
- event-driven；
- data-oriented；
- cloud-native；
- heterogeneous computing。

---

## 3.4 $\Sigma^V$ ｜Version / Configuration State

包括：

- no VCS；
- centralized VCS；
- Git；
- Perforce；
- repository governance；
- branching；
- review；
- reproducible configuration。

---

## 3.5 $\Sigma^Q$ ｜Quality Engineering State

包括：

- manual testing；
- unit testing；
- integration testing；
- static analysis；
- dynamic analysis；
- fuzzing；
- formal verification；
- automated regression。

---

## 3.6 $\Sigma^C$ ｜CI/CD State

包括：

- manual build；
- build scripts；
- CI；
- CD；
- deployment automation；
- policy gates；
- supply-chain scanning。

---

## 3.7 $\Sigma^D$ ｜Deployment / Infrastructure State

包括：

- local-only；
- bare metal；
- VM；
- container；
- orchestration；
- edge；
- serverless；
- reproducible infrastructure。

---

## 3.8 $\Sigma^{AI}$ ｜AI Engineering State

包括：

```text
AI_NONE
AI_CHAT
AI_AUTOCOMPLETE
AI_CODE_GENERATION
AI_REVIEW
AI_AGENT
MULTI_AGENT
AUTONOMOUS_WORKFLOW
```

---

## 3.9 $\Sigma^O$ ｜Organizational State

包括：

- collaboration；
- governance；
- release discipline；
- documentation；
- migration capability；
- learning rate；
- technical debt governance；
- architecture ownership。

---

# 4. Software Epoch Mosaic Hypothesis

本文提出：

$$
\boxed{
\Sigma_{\mathrm{software\ org}}(t)
=
\bigcup_{i=1}^{n}
\Sigma_i(t).
}
$$

其中每個 $\Sigma_i$ 可以是：

- team；
- repository；
- product；
- service；
- infrastructure；
- engineering subgroup。

因此一家公司不是位於「某一個軟體時代」，而是由多個不同 software epochs 拼成的：

$$
\boxed{
\text{Software Epoch Mosaic}.
}
$$

---

# 5. Mosaic 不是例外，而可能是大型組織的正常狀態

大型企業通常具有：

- 不同產品年齡；
- 不同客戶要求；
- 不同 compliance；
- 不同團隊 autonomy；
- 不同 acquisition history；
- 不同技術債；
- 不同人才結構。

因此：

$$
\boxed{
\text{Organizational Uniformity}
}
$$

反而可能比：

$$
\boxed{
\text{Heterogeneous Coexistence}
}
$$

更少見。

---

# 6. 市場不會自動讓最新技術勝出

最簡單的錯誤模型是：

$$
\boxed{
\text{NewTechnology}
>
\text{OldTechnology}
}
$$

所以：

$$
\boxed{
\text{New}
\rightarrow
\text{MarketWinner}.
}
$$

這不成立。

---

# 7. Local Fitness

企業實際決策更接近：

$$
\boxed{
F(T|E)
=
V(T,E)
-
C(T,E)
-
R(T,E)
}
$$

其中：

- $V$：value；
- $C$：migration / operation cost；
- $R$：risk；
- $E$：environment。

---

# 8. Migration Decision

若：

$$
\boxed{
\Delta V_{\mathrm{new}}
<
C_{\mathrm{migration}}
+
R_{\mathrm{migration}},
}
$$

則：

$$
\boxed{
\text{Remain on old technology}
}
$$

可以是理性決策。

---

# 9. 新不等於高適應度

$$
\boxed{
\text{Newest}
\not\Rightarrow
\text{Highest Local Fitness}.
}
$$

這是本文最重要的反單線命題之一。

---

# 10. 四類「舊」

不能把所有舊技術都叫 legacy problem。

本文提出：

$$
\boxed{
\mathcal L
\in
\{
S_0,S_1,S_2,S_3
\}.
}
$$

---

## $S_0$ ｜Stable Substrate

年代很久，但仍是基礎性或 canonical。

例如：

- graph；
- relational model；
- compiler fundamentals；
- operating-system principles；
- C language in appropriate systems domains。

其「舊」不是缺陷。

---

## $S_1$ ｜Domain-Optimal Legacy

技術較舊，但仍高度符合特定 workflow。

例如大型遊戲資產管線中的 Perforce P4。

---

## $S_2$ ｜Transitional Coexistence

新舊系統同時存在於遷移期：

```text
Jenkins
+
GitHub Actions
```

這不一定是治理失敗。

---

## $S_3$ ｜Epoch Lag

既有方案已明顯造成：

- 無法維護；
- 重大安全風險；
- 明顯效率損失；
- 人才供應困難；
- 失去競爭能力；

且合理替代路徑存在，但系統仍因 inertia 長期停滯。

這才是本文真正稱為：

$$
\boxed{
\text{Epoch Lag}.
}
$$

---

# 11. Tool Age ≠ Epoch Position

某工具首次出現於很早的年代，不表示今天使用它的人「活在那個年代」。

因此：

$$
\boxed{
\text{Age}(Tool)
\neq
\text{EpochPosition}(User).
}
$$

判斷必須看：

- current fitness；
- workflow role；
- alternatives；
- switching cost；
- capability gap。

---

# 12. GitHub 不是現代性的充分條件

一個公司可以有：

```text
GitHub
+ no code review
+ no CI
+ no tests
+ manual deployment
```

因此：

$$
\boxed{
\text{GitHubUsage}
\not\Rightarrow
\text{ModernEngineeringState}.
}
$$

反過來：

$$
\boxed{
\text{NoGitHub}
\not\Rightarrow
\text{Backwardness}.
}
$$

它可能使用：

- GitLab；
- Azure DevOps；
- Bitbucket；
- Perforce；
- Gerrit；
- self-hosted Git。

---

# 13. 遊戲業的工具鑲嵌

JetBrains 2025 Game Development Survey 顯示 AAA studio 的版本控制工具並不集中於單一現代平台。

其調查結果包括：

- Perforce P4：45%；
- GitHub：38%；
- GitLab：38%；
- Azure DevOps Server：32%；
- Subversion：25%。

而 Mid-size / Indie 的 GitHub 為 61%，Hobbyist 為 79%。

因此：

$$
\boxed{
\text{Same Industry}
\neq
\text{Same Tool Epoch}.
}
$$

---

# 14. AAA 與 Indie 的時代向量可以不同而都合理

AAA studio 可能更重：

- 巨量 binary assets；
- locking；
- centralized pipelines；
- build farms；
- enterprise governance。

Indie 可能更重：

- open ecosystem；
- distributed collaboration；
- low setup cost；
- GitHub-native automation。

因此兩者不能簡單排序為：

$$
\text{AAA}>\text{Indie}
$$

或：

$$
\text{GitHub}>\text{Perforce}.
$$

應比較指定操作：

$$
D_{A\rightarrow B}^{(\ell,q)}.
$$

---

# 15. CI/CD 的 Mosaic

JetBrains 2025 CI/CD survey 顯示：

- 32% 組織同時使用兩套 CI 工具；
- 9% 使用至少三套。

這是一個直接的「鑲嵌」案例。

---

# 16. Multi-Tool Reality

企業可能同時有：

```text
legacy Jenkins
new GitHub Actions
client-required Azure DevOps
team-specific GitLab CI
```

這不是單一線性 progression。

---

# 17. Adoption Lag

JetBrains 將企業中的 adoption lag 歸因於：

- legacy systems；
- compliance；
- migration cost；
- existing investment；
- customer requirement；
- cost / performance trade-off。

這正好對應時代拓撲論中的：

$$
\boxed{
\text{Non-symmetric Transition Cost}.
}
$$

---

# 18. Migration Distance

本文定義：

$$
\boxed{
D_{A\rightarrow B}^{soft}
=
\inf_{\gamma\in\Gamma_{A\rightarrow B}}
\text{Cost}(\gamma).
}
$$

其中 transition path $\gamma$ 可以包含：

- code migration；
- retraining；
- data conversion；
- build migration；
- infrastructure migration；
- compliance review；
- customer transition；
- rollback preparation。

---

# 19. Migration Distance 不對稱

通常：

$$
\boxed{
D_{A\rightarrow B}
\neq
D_{B\rightarrow A}.
}
$$

例如：

> Jenkins → GitHub Actions

與：

> GitHub Actions → Jenkins

具有不同 path、investment 與 operational risk。

---

# 20. Path Dependence

企業現在使用什麼，不只由當下最佳方案決定。

還由：

$$
\boxed{
\text{History}
}
$$

決定。

包括：

- previous acquisitions；
- past champions；
- old contracts；
- plugin ecosystems；
- internal expertise；
- sunk infrastructure。

因此：

$$
\boxed{
\text{PresentState}
=
f(\text{CurrentFitness},\text{History}).
}
$$

---

# 21. Organizational Epoch Fracture

本文提出：

$$
\boxed{
\mathfrak F_{org}(t)
=
\text{Mismatch}(
\Sigma^K,
\Sigma^L,
\Sigma^A,
\Sigma^V,
\Sigma^Q,
\Sigma^C,
\Sigma^D,
\Sigma^{AI},
\Sigma^O
).
}
$$

---

# 22. 裂縫案例

例如：

```text
modern language
+ modern cloud
+ no tests
+ manual releases
```

或：

```text
agentic coding
+ legacy deployment
+ no dependency governance
```

都是高 fracture state。

---

# 23. Fracture 不等於低能力

一家公司可能產品仍然很賺錢。

所以：

$$
\boxed{
\text{EpochFracture}
\neq
\text{BusinessFailure}.
}
$$

它描述的是：

> 各層同步程度。

---

# 24. 新舊工程師共存

工程師年齡不能直接映射技術 epoch。

因此：

$$
\boxed{
\text{Age}
\neq
\text{ExperienceTopology}
\neq
\text{TechnologyEpoch}.
}
$$

---

# 25. Experience Years 也不是單一尺度

可以有：

$$
Engineer_A
=
20\text{ years continuous evolution}
$$

與：

$$
Engineer_B
=
2\text{ years pattern repeated ten times}.
$$

總年資相同，學習 topology 不同。

---

# 26. 個體 Software Epoch Vector

可定義：

$$
\boxed{
\mathbf e_i^{soft}
=
(
K_i,
L_i,
A_i,
V_i,
Q_i,
C_i,
D_i,
AI_i
).
}
$$

---

# 27. 個體和組織可能不同步

例如 frontier engineer 進入 legacy company：

$$
\boxed{
\mathbf e_{engineer}
\not\sim
\mathbf e_{organization}.
}
$$

可能產生：

- modernization；
- frustration；
- local tool adoption；
- exit。

---

# 28. 組織也可能比個體先進

相反地，先進公司可能有：

- automated governance；
- CI；
- testing；
- platform engineering；

但個別工程師仍停留舊 workflow。

---

# 29. AI 時代把非同步放大

Stack Overflow 2025 顯示：

- 84% respondents 使用或計畫使用 AI tools；
- professional developers 中 51% 每天使用；
- 52% 不使用 AI Agent 或停留較簡單 AI 工具；
- 38% 沒有採用 AI Agent 的計畫。

因此：

$$
\boxed{
\text{AIUsage}
}
$$

不是 binary variable。

---

# 30. AI Adoption Ladder

本文提出：

$$
\boxed{
A_{AI}
\in
\{
A_0,\ldots,A_7
\}.
}
$$

例如：

```text
A0 none
A1 chat
A2 autocomplete
A3 generation
A4 review/test
A5 agent
A6 multi-agent
A7 integrated autonomous workflow
```

---

# 31. 「我們公司有 AI」資訊量很低

兩家公司都說：

> 有 AI。

其實可能：

$$
A_2
\quad\text{vs}\quad
A_6.
$$

因此 AI adoption survey 若只問 yes/no，會嚴重壓縮 epoch structure。

---

# 32. AI Epoch Distance

可定義：

$$
\boxed{
D_{i\rightarrow j}^{AI}
}
$$

表示一個團隊從目前 AI engineering state 到另一狀態所需 transition cost。

---

# 33. AI 可以壓縮週期

AI 亦可以降低：

- learning cost；
- migration research；
- code conversion；
- documentation cost；
- testing cost。

因此：

$$
\boxed{
AI
\rightarrow
\text{Cycle Compression}.
}
$$

但不能推出：

$$
\boxed{
AI
\rightarrow
\text{Zero Migration Cost}.
}
$$

---

# 34. Software Epoch Leap

某個人可以透過 AI 在一年內快速補入：

- 新語言；
- 新 framework；
- deployment；
- formal methods；
- AI tooling。

因此個體可能出現高速度 transition。

但：

$$
\boxed{
\text{Knowledge Leap}
\neq
\text{Organizational Leap}.
}
$$

---

# 35. 教育層的問題

「教授是不是懂現代軟體？」不是單一問題。

需要分解成：

$$
\boxed{
\text{ProfessorKnowledge}
}
$$

與：

$$
\boxed{
\text{DeliveredCurriculum}.
}
$$

---

# 36. Professor Knowledge ≠ Delivered Curriculum

本文提出：

$$
\boxed{
\text{Professor Knowledge}
\neq
\text{Delivered Curriculum}.
}
$$

因為實際課程還受：

- syllabus；
- textbook；
- lab environment；
- assessment；
- department；
- accreditation；
- teaching load；
- course duration；

影響。

---

# 37. Curriculum State Function

可表示：

$$
\boxed{
\Sigma_{\mathrm{course}}
=
F(
\Sigma_{\mathrm{professor}},
\Sigma_{\mathrm{curriculum}},
\Sigma_{\mathrm{textbook}},
\Sigma_{\mathrm{lab}},
\Sigma_{\mathrm{assessment}},
\Sigma_{\mathrm{institution}}
).
}
$$

---

# 38. 教授年齡不是主要判準

因此：

$$
\boxed{
\text{ProfessorAge}
\neq
\text{ProfessorEpoch}.
}
$$

年輕教授可以使用舊課綱。

年長教授也可以持續研究最新 compiler、systems、AI 或 formal methods。

---

# 39. 舊知識與過時教學必須分開

本文提出三類教育內容：

### E0｜Stable Foundation

例如：

- algorithms；
- data structures；
- memory；
- operating systems；
- networking；
- logic；
- complexity。

老，但仍是基礎。

### E1｜Domain-Relevant Established Practice

例如：

- C/C++；
- relational databases；
- Git fundamentals；
- build systems。

不是最新，但仍大量使用。

### E2｜Epoch-Lagged Practice

若課程宣稱自己教授「現代軟體工程」，卻系統性缺少：

- version control；
- testing；
- code review；
- CI；
- dependency management；
- collaborative workflow；

則較接近真正的 curriculum epoch lag。

---

# 40. CS2023 的證據

ACM/IEEE-CS/AAAI 的 CS2023 Software Engineering 知識領域已明確把：

- version control；
- branching / merging / rebasing；
- reproducible builds；
- static / dynamic analysis；
- CI；
- dependency management；
- package management；
- modern IDE；
- ML-powered code assistants；

列入 SE tools / environments。

因此到了此 curriculum state：

$$
\boxed{
\text{Modern Software Engineering Education}
}
$$

已不再等於：

> 會寫程式 + 會編譯。

---

# 41. Programming ≠ Software Engineering

CS2023 特別強調：

$$
\boxed{
\text{Programming}
\neq
\text{SoftwareEngineering}.
}
$$

Software engineering 還包含：

- people；
- time；
- maintenance；
- evolution；
- teamwork；
- testing；
- tools；
- process。

這也說明某些「看起來會教程式」的課程，並不等於完成 modern SE education。

---

# 42. Academia–Industry Gap

Garousi 等人在 2019 的 meta-analysis：

- 整合 35 個研究；
- 涵蓋 13 國；
- 超過 4,000 data points。

結果指出重要 skill gaps 包括：

- configuration management；
- software process；
- design / architecture；
- testing。

因此：

$$
\boxed{
\text{Curriculum Epoch Lag}
}
$$

不是純粹個人抱怨，而具有長期可觀測研究背景。

---

# 43. Curriculum Epoch Distance

本文提出：

$$
\boxed{
D_{\mathrm{curriculum}\rightarrow\mathrm{practice}}
}
$$

表示：

> 某課程到指定產業實務狀態之間，學生還需要跨越多少 knowledge / tooling / workflow transformation。

---

# 44. 教授「懂」與「能教」再次分離

教授可能知道：

- Git；
- CI；
- cloud；
- AI。

但課程仍無法實際提供。

因此：

$$
\boxed{
\text{KnowledgeAvailability}
\neq
\text{InstructionalRealization}.
}
$$

這是典型跨層耦合損失。

---

# 45. Capitalism Does Not Synchronize Epochs

本文提出：

$$
\boxed{
\text{Market Competition}
\not\Rightarrow
\text{Epoch Synchronization}.
}
$$

市場可以淘汰某些低適應度方案，

但也可以長期保留：

- profitable legacy；
- switching-cost moat；
- compatibility ecosystems；
- regulated systems；
- customer lock-in；
- niche tools。

---

# 46. Competition Produces Selection, Not Uniform Modernity

因此更準確的是：

$$
\boxed{
\text{Competition}
\rightarrow
\text{Selection under Constraints}.
}
$$

不是：

$$
\boxed{
\text{Competition}
\rightarrow
\text{Everyone Uses Frontier Technology}.
}
$$

---

# 47. Innovation Diffusion Is Uneven

新技術通常先進入：

- greenfield projects；
- startups；
- side projects；
- frontier teams。

再逐步進入：

- large organizations；
- critical infrastructure；
- regulated domains。

這是一種：

$$
\boxed{
\text{Asymmetric Diffusion}.
}
$$

---

# 48. Software Geological Layers

本文提出一個可觀測類比：

$$
\boxed{
\text{Repository}
=
\text{Software Geological Layer}.
}
$$

Repository 可保留：

- language versions；
- dependency versions；
- build systems；
- architecture；
- test maturity；
- CI configuration；
- migration history；
- contributor history。

---

# 49. Toolchain Fossils

例如：

```text
pom.xml
Makefile
Jenkinsfile
Dockerfile
Cargo.toml
package-lock.json
.github/workflows
```

都可以被視為：

$$
\boxed{
\text{Epoch Fossils}.
}
$$

---

# 50. 可實證性

軟體領域之所以適合時代拓撲研究，是因為大量狀態能被機器讀取。

例如：

$$
\boxed{
\text{Observable Software Epoch Features}
}
$$

包括：

- primary languages；
- language age/version；
- dependency freshness；
- VCS；
- CI；
- testing；
- static analysis；
- deployment；
- containerization；
- infrastructure automation；
- AI tooling；
- release cadence。

---

# 51. Software Epoch Signature

本文提出：

$$
\boxed{
\chi_x
=
(
l,
v,
q,
c,
d,
a,
r
).
}
$$

作為簡化 signature。

例如：

- $l$：language/runtime；
- $v$：version/configuration；
- $q$：quality；
- $c$：CI/CD；
- $d$：deployment；
- $a$：AI adoption；
- $r$：release process。

---

# 52. 不應建立單一總分

本文反對：

$$
\boxed{
\text{SoftwareModernityScore}=87/100.
}
$$

因為這會重演時代拓撲論反對的單軸投影。

---

# 53. 局部可比較，全局不可粗暴排序

可以問：

> 在 CI maturity 上誰更接近某目標？

不能因此推出：

> 公司 A 比公司 B 全面更先進。

因此：

$$
\boxed{
\text{Local Comparability}
\neq
\text{Global Ranking}.
}
$$

---

# 54. Software Epoch Distance

對指定操作 $q$：

$$
\boxed{
D_{j\rightarrow i}^{(\ell,q)}
=
\inf_{\gamma\in\Gamma}
\text{Cost}(\gamma).
}
$$

例如：

> 從 manual deployment 轉為 reproducible CI/CD。

或：

> 從 AI chat 轉為 agentic workflow。

---

# 55. Epoch Cycle Count

可以進一步定義：

$$
\boxed{
N_{j\rightarrow i}^{(\ell,q)}
=
\min
\{
n:
\Sigma_j^\ell
\xrightarrow{n}
\Sigma_i^\ell
\}.
}
$$

---

# 56. 週期不是固定年份

一個週期可以是：

- 補知識；
- 改 architecture；
- 遷移 VCS；
- 建 CI；
- 建 testing；
- 改 release process；
- 建 AI governance。

因此：

$$
\boxed{
\text{Cycle}
\neq
\text{CalendarYear}.
}
$$

---

# 57. 軟體時代裂縫與事故

高 fracture 可能增加：

- deployment errors；
- security exposure；
- migration friction；
- onboarding cost；
- hidden operational knowledge；
- key-person dependency。

但這些仍需實證驗證。

---

# 58. Legacy 也可能形成競爭護城河

某些企業因長期累積：

- proprietary tooling；
- internal automation；
- domain expertise；

使舊技術形成：

$$
\boxed{
\text{Legacy Capability Moat}.
}
$$

這再次說明舊不等於低能力。

---

# 59. 真正的落後應以 Reachability 判斷

本文提出：

> 一個系統是否「落後」，不應只看它用了多舊的工具，而要看它是否仍能以合理成本完成現代需求，並是否保有可達的演化路徑。

形式上：

$$
\boxed{
\text{Lag}(x,q)
=
f(
\text{CapabilityGap},
\text{TransitionCost},
\text{Risk},
\text{Reachability}
).
}
$$

---

# 60. 若功能足夠且可持續，就不必強迫更新

因此：

$$
\boxed{
\text{NoNeedToMigrate}
}
$$

本身可以是合理結論。

時代拓撲不是：

> 技術更新排行榜。

而是：

> 狀態與轉換結構分析。

---

# 61. AI 時代的新問題

AI 工具使局部 transition cost 快速下降：

$$
C_{\mathrm{learning}}
\downarrow
$$

$$
C_{\mathrm{migration}}
\downarrow
$$

$$
C_{\mathrm{prototype}}
\downarrow.
$$

因此原本合理的 legacy equilibrium 可能突然失去穩定性。

---

# 62. AI 重新定義「太貴所以不改」

如果過去：

$$
C_{\mathrm{migration}}=100,
$$

AI 使其降為：

$$
C_{\mathrm{migration}}=20,
$$

則原本 rational legacy state 可能變成 epoch lag。

---

# 63. Dynamic Lag

因此：

$$
\boxed{
\text{Lag}
}
$$

不是永久標籤。

它隨：

- AI；
- tooling；
- labor；
- hardware；
- regulation；

改變。

---

# 64. Software Epoch Topology Is Time-Varying

$$
\boxed{
\mathfrak S_x
=
\mathfrak S_x(t).
}
$$

同一家公司去年合理的工具組合，今年可能已不再合理。

---

# 65. Claim Boundary

## $K$ ｜Established / Observed

已有公開資料支持：

- software organizations commonly use heterogeneous toolchains；
- large organizations often use multiple CI systems；
- migration cost、legacy investment、compliance 與 project requirements affect tool adoption；
- AI adoption is uneven；
- software engineering education has documented industry-alignment gaps；
- current CS curriculum recommendations include modern workflow / tooling topics。

---

## $E$ ｜Reasoned Extrapolation

本文提出：

- Software Epoch Mosaic；
- Organizational Epoch Fracture；
- Software Epoch Signature；
- Curriculum Epoch Distance；
- Legacy Fitness；
- four-state legacy classification；
- repository geological-layer model。

---

## $S$ ｜Simulation / Data Analysis Required

需要大型 repo / company dataset 檢驗：

- epoch clustering；
- migration graph；
- tool coexistence；
- fracture correlation；
- modernization paths。

---

## $X$ ｜Experiment / Field Study Required

需要企業或教育研究：

- AI 是否實際壓縮 migration cycle；
- curriculum lag 對職涯的影響；
- professor knowledge / delivered curriculum gap；
- high epoch fracture 是否增加 failure rate。

---

## $F$ ｜Future Extension

包括：

- AI autonomous software-epoch auditor；
- repository archaeology；
- organization transition simulator；
- curriculum epoch monitoring；
- industry-scale epoch maps。

---

# 66. 核心命題集

## P1｜Calendar Synchronization Is Not Software Epoch Synchronization

$$
\boxed{
t_i=t_j
\not\Rightarrow
\Sigma_i^{\mathrm{software}}
=
\Sigma_j^{\mathrm{software}}.
}
$$

## P2｜Software Organizations Are Mosaics

$$
\boxed{
\Sigma_{\mathrm{org}}
=
\bigcup_i
\Sigma_i.
}
$$

## P3｜Newest Does Not Imply Highest Fitness

$$
\boxed{
\text{Newest}
\not\Rightarrow
\text{HighestFitness}.
}
$$

## P4｜Old Technology Has Multiple Ontological Classes

$$
\boxed{
\text{Old}
\in
\{
\text{StableSubstrate},
\text{DomainOptimalLegacy},
\text{TransitionalCoexistence},
\text{EpochLag}
\}.
}
$$

## P5｜Market Competition Does Not Synchronize Epochs

$$
\boxed{
\text{Competition}
\not\Rightarrow
\text{EpochSynchronization}.
}
$$

## P6｜Migration Distance Is Asymmetric

$$
\boxed{
D_{A\rightarrow B}
\neq
D_{B\rightarrow A}.
}
$$

## P7｜Engineer Age Is Not Technology Epoch

$$
\boxed{
\text{Age}
\neq
\text{ExperienceTopology}
\neq
\text{TechnologyEpoch}.
}
$$

## P8｜AI Adoption Is a State Space, Not a Boolean

$$
\boxed{
\text{AIUsage}
\neq
\{0,1\}.
}
$$

## P9｜Professor Knowledge Is Not Delivered Curriculum

$$
\boxed{
\text{ProfessorKnowledge}
\neq
\text{DeliveredCurriculum}.
}
$$

## P10｜Software Epoch Can Be Empirically Reconstructed

$$
\boxed{
\text{Repo}
+
\text{Toolchain}
+
\text{Pipeline}
+
\text{Dependencies}
+
\text{Process}
\rightarrow
\text{EpochEvidence}.
}
$$

---

# 67. 對《時代拓撲論》的新增價值

軟體工程提供一個特殊優勢：

> 時代狀態留下大量結構化數位痕跡。

因此它可能成為時代拓撲論第一批最適合進入：

$$
\boxed{
\text{Computational Empirical Validation}
}
$$

的 domain。

---

# 68. 後續可做的 MVP

未來如果要實作，可以建立：

$$
\boxed{
\text{Software Epoch Auditor}.
}
$$

輸入：

```text
Git repository
dependency files
CI configs
build files
deployment files
```

輸出：

```text
epoch state bundle
fracture map
migration candidates
unknowns
```

但本文不主張立即開發。

---

# 69. 結論

軟體世界表面上是一個極度追求創新的資本主義市場。

因此人們容易形成直覺：

> 新技術會淘汰舊技術。

但真實軟體世界更接近：

$$
\boxed{
\text{many local technological epochs coexisting at once}.
}
$$

一家公司可以同時擁有：

- 很新的語言；
- 很舊的 CI；
- 很成熟的 testing；
- 很新的 AI Agent；
- 很舊的 deployment；
- 很強的 business capability。

這不是矛盾。

它正是：

$$
\boxed{
\text{Software Epoch Mosaic}.
}
$$

市場競爭也不會自動消除這種鑲嵌。

因為市場選擇的是：

$$
\boxed{
\text{fitness under constraints},
}
$$

而不是：

$$
\boxed{
\text{novelty}.
}
$$

因此「舊」必須被拆成：

- 穩定基底；
- 領域最適 legacy；
- 遷移共存；
- 真正的 epoch lag。

教育亦同樣如此。

一位教授本人的知識狀態、系所課綱、教材、教學環境與學生最後收到的 curriculum 並不是同一個變量。

所以：

$$
\boxed{
\text{Professor Knowledge}
\neq
\text{Delivered Curriculum}.
}
$$

AI 時代會使整個現象更加劇烈。

因為 AI 一方面快速降低個體跨越技術狀態的成本，另一方面大型組織仍受到 legacy、compliance、migration、capital investment 與 governance 的限制。

結果可能是：

$$
\boxed{
\text{Individual Epoch Acceleration}
+
\text{Organizational Epoch Inertia}.
}
$$

兩者共同增大：

$$
\boxed{
\mathfrak F_{\mathrm{software}}.
}
$$

最終，本文主張：

> 判斷一家公司、一個工程師、一個教授或一門課是否「與時俱進」，不能只看年份、年齡或某個流行工具是否存在；應觀察其在特定軟體工程狀態空間中的位置、可達性、轉換成本與跨層同步程度。

軟體產業因此不是單一技術時間線。

它是一張：

$$
\boxed{
\text{Software Epoch Topology}.
}
$$

而每一個 repository、toolchain、pipeline 與 curriculum，都可能是這張拓撲留下的一層技術化石。

---

# 參考文獻與資料來源

1. Neo.K / EveMissLab. 《時代拓撲論 v2.0：相對絕對時空間框架下的時代向量結構與分形動態因果展開》, 2026.
2. Neo.K / EveMissLab. 《時代拓撲論：通用週期、超前距離與跨層普及》v1.0, 2026.
3. JetBrains. *The State of Game Development 2025*.
4. JetBrains TeamCity / JetBrains Research. *The State of CI/CD in 2025*, 2025.
5. Stack Overflow. *2025 Developer Survey — AI*, 2025.
6. ACM / IEEE Computer Society / AAAI. *Computer Science Curricula 2023 (CS2023)*, endorsed 2024.
7. CS2023 Software Engineering Knowledge Area. *Tools and Environments; Changes since CS2013*.
8. Garousi, V., Giray, G., Tüzün, E., Catal, C., & Felderer, M. “Aligning software engineering education with industrial needs: A meta-analysis.” *Journal of Systems and Software*, 156 (2019), 65–83. DOI: 10.1016/j.jss.2019.06.044.

---

## 作者聲明

本文不主張任何特定工具、語言、公司、教授或教育機構應被簡化標記為「先進」或「落後」。

時代拓撲分析的目的不是建立技術流行排行榜，而是描述：

- 狀態；
- 差異；
- 局部適應度；
- 可達性；
- 轉換成本；
- 跨層耦合。

尤其：

$$
\boxed{
\text{Old}
\neq
\text{Bad}
}
$$

以及：

$$
\boxed{
\text{New}
\neq
\text{Good}.
}
$$

真正應分析的是：

$$
\boxed{
\text{Fit}
+
\text{Reachability}
+
\text{Transition Cost}
+
\text{Current Requirements}.
}
$$

---

*Software Epoch Mosaic Hypothesis / v0.1 / 2026-09-17*  
*EveMissLab — Boundless Knowledge. One Promise Forward.*