# AI 組織吸收與耦合拓撲 03
# 重構權限與相容性債務：AI 的局部最優、全域最優與既有系統約束

**English Title:**  
**Reconstruction Authority and Compatibility Debt: Local Optima, Global Optima, and Legacy Constraints in AI-Assisted Software Engineering**

**系列：** AI Organizational Absorption & Coupling Topology  
**系列編號：** 03 / 06  
**版本：** v0.1  
**日期：** 2026-09-18  
**作者：** Neo.K  
**協作：** Aletheia（GPT-5.6 Sol）  
**機構：** EveMissLab / 一言諾科技有限公司  
**文件性質：** AI 軟體工程理論／企業重構治理／時代拓撲論應用  
**前置母文：**
- Paper 00《軟體時代鑲嵌與 AI 組織拓撲》
- Paper 01《有效問題覆蓋論》
- Paper 02《企業 AI 吸收論》

**主要前置方法論：**
- 《形式系統的補丁化累積：載體超載、局部擬合與結構債務》
- 《理論補丁算子學》
- 《全域完成論：AI 時代從局部完成到全域實例化的方法論》
- Maximum Local Precision + Minimum Global Disturbance
- Global-First Completion

---

## 摘要

前沿 AI Coding Agent 已開始具備跨檔案理解、依賴追蹤、測試生成、架構分析與大範圍程式碼修改能力，因此一個新的工程矛盾正在形成：

> **AI 可能已經能看出全域更好的解法，但現實組織只允許它修改局部。**

因此，AI 軟體工程中的主要瓶頸不再只是：

$$
\boxed{
\text{Can the AI find a better solution?}
}
$$

而是：

$$
\boxed{
\text{Is the better solution inside the authorized,
compatible, verifiable, reversible change space?}
}
$$

本文提出最核心的區分：

$$
\boxed{
\Omega_{\mathrm{optimal}}
\neq
\Omega_{\mathrm{authorized}}
\neq
\Omega_{\mathrm{deployable}}.
}
$$

其中：

- $\Omega_{\mathrm{optimal}}$：AI 在充分資訊下可探索的理論最佳化空間；
- $\Omega_{\mathrm{authorized}}$：組織允許 Agent 修改的空間；
- $\Omega_{\mathrm{deployable}}$：考慮相容性、驗證、回滾、責任與風險後真正可部署的空間。

一般而言：

$$
\boxed{
\Omega_{\mathrm{deployable}}
\subseteq
\Omega_{\mathrm{authorized}}
\subseteq
\Omega_{\mathrm{optimal}}.
}
$$

這使「AI 只做局部 patch」不應被簡化理解成 Agent 能力不足。局部修復可能是：

- 權限限制；
- 相容性約束；
- contract preservation；
- migration risk；
- unknown dependency；
- rollback requirement；

下的合理策略。

但當局部補丁長期累積時，又可能形成本文所稱：

$$
\boxed{
D_{\mathrm{compat}}
=
\text{Compatibility Debt}
}
$$

與既有「結構債務」相連。Compatibility Debt 表示：為維持舊接口、舊資料、舊客戶、舊工作流與舊責任邊界，而持續加入 adapter、exception、bridge、special case 與 local patch 所累積的未來整合成本。

延續先前補丁化理論，本文提出：

$$
\boxed{
D_{t+1}
=
\rho D_t
+
\alpha C_t^{\mathrm{patch}}
+
\beta L_t^{\mathrm{interface}}
+
\gamma H_t^{\mathrm{legacy}}
+
\eta X_t^{\mathrm{exception}}
-
\delta R_t,
}
$$

其中 $R_t$ 表示真正的重構、刪除、統一與空間重寫。

然而，本文同時反對另一個極端：

> **既然 AI 可以全域理解，就應讓 AI 直接全面重寫。**

全域重構會擴大：

- change surface；
- blast radius；
- verification surface；
- migration surface；
- organizational liability。

因此本文引入：

$$
\boxed{
L_{\mathrm{reconstruction}}
=
\text{Reconstruction Liability}
}
$$

以及：

$$
\boxed{
B_{\mathrm{change}}
=
\text{Change Blast Radius}.
}
$$

AI 的全域方案若超過組織可驗證與可回滾能力，即使架構上更優，也可能不是當前 deployable optimum。

因此，本研究不在「局部修復」與「全域完成」之間選邊，而是建立一個 **Authorized Reconstruction Topology**。其核心是：

$$
\boxed{
\text{Choose the largest change surface
that remains observable, authorized,
verifiable, compatible, and reversible.}
}
$$

這使先前兩個方法論得到統一：

$$
\boxed{
\text{Maximum Local Precision}
+
\text{Minimum Global Disturbance}
}
$$

適合高不確定、高耦合、低授權、低可回滾環境；而：

$$
\boxed{
\text{Global-First Completion}
}
$$

適合範圍明確、依賴可見、授權充分、sandbox 完整且全域驗證成本可承擔的環境。

本文因此提出 **Reconstruction Eligibility Condition**：

$$
\boxed{
\text{GlobalReconstruction}(q)
\Rightarrow
\text{Auth}
\land
\text{Obs}
\land
\text{Dep}
\land
\text{Ver}
\land
\text{Rollback}
\land
\text{Owner}.
}
$$

只有當修改權、觀測、依賴圖、驗證、回滾與責任擁有者都足夠時，全域重構才是合理候選。

外部研究與此框架相容。METR 2026 發現，約一半通過 SWE-bench Verified automated grader 的 AI patch 仍不會被 maintainer 接受，拒絕原因包含 code quality、破壞其他程式與核心功能失敗；2025 的 Agentic Refactoring 大型研究顯示，AI Agent 的實際 refactoring 明顯偏向低階、一致性導向的局部修改，而不是高階設計變更；2026 年針對 30 萬級 AI-authored commits 的預印本研究則報告 AI-generated code 在真實 repository 中可引入長期存續的 code smells、bugs 與 security issues；DORA 2026 也指出 AI 加速 creation 後，時間常被重新分配到 auditing 與 verification。

本文最終主張：

$$
\boxed{
\text{Best Technical Architecture}
\neq
\text{Best Deployable Change}.
}
$$

真正的企業 AI 重構問題是一個：

$$
\boxed{
\text{Constrained Global Optimization Problem}.
}
$$

---

# 0. 問題定義

AI Coding Agent 的能力正在從：

```text
complete line
→ write function
→ edit file
→ edit repository
→ plan migration
→ propose architecture
```

快速擴張。

因此一個新的情況出現：

> Agent 看得到更好的全域結構，但無法合法採取對應行動。

這不是單純技術能力問題。

---

# 1. 三個空間

本文首先區分三個空間。

## 1.1 理論最佳化空間

$$
\boxed{
\Omega_{\mathrm{optimal}}
}
$$

表示：

> 若忽略組織權限與遷移限制，AI 可以搜索的候選解空間。

---

## 1.2 授權修改空間

$$
\boxed{
\Omega_{\mathrm{authorized}}
}
$$

表示：

> AI 實際被允許修改的物件、接口與狀態集合。

---

## 1.3 可部署修改空間

$$
\boxed{
\Omega_{\mathrm{deployable}}
}
$$

表示同時滿足：

- compatibility；
- verification；
- rollback；
- security；
- governance；
- business continuity；

的可實際部署區域。

---

# 2. 基本包含關係

典型情況：

$$
\boxed{
\Omega_{\mathrm{deployable}}
\subseteq
\Omega_{\mathrm{authorized}}
\subseteq
\Omega_{\mathrm{optimal}}.
}
$$

但這是一般結構，不宣稱所有組織都嚴格包含。

---

# 3. Optimization Space ≠ Authorized Modification Space

核心命題：

$$
\boxed{
\text{Optimization Space}
\neq
\text{Authorized Modification Space}.
}
$$

AI 可以知道：

> 整個 dependency architecture 應該重寫。

但公司只允許：

> 改這三個檔案。

因此 AI 的實際問題變成：

$$
\boxed{
\max_{x\in\Omega_{\mathrm{authorized}}}
U(x)
}
$$

而不是：

$$
\boxed{
\max_{x\in\Omega_{\mathrm{optimal}}}
U(x).
}
$$

---

# 4. 這是一個受限最佳化問題

令：

$$
U(x)
$$

為方案 $x$ 的全域工程效用。

約束：

$$
g_i(x)\le0
$$

可包括：

- backward compatibility；
- budget；
- downtime；
- security；
- customer contract；
- legal；
- ownership。

則企業 Agent 真正解的是：

$$
\boxed{
x^\*
=
\arg\max_x U(x)
\quad
\text{s.t. }
g_i(x)\le0.
}
$$

---

# 5. Technical Optimum ≠ Deployable Optimum

因此：

$$
\boxed{
x_{\mathrm{technical}}^\*
\neq
x_{\mathrm{deployable}}^\*.
}
$$

一個架構師眼中的最好方案，

不一定是：

> 現在最值得部署的方案。

---

# 6. 為什麼企業會限制全域修改

限制來源可能包括：

- unknown dependencies；
- undocumented consumers；
- old customer contracts；
- regulatory obligations；
- operational risk；
- missing tests；
- unclear ownership；
- migration cost；
- retraining；
- rollback difficulty。

這些都屬於真實 constraint。

---

# 7. Legacy Constraint Graph

可把既有系統表示為：

$$
\boxed{
G_L=(V,E,\lambda).
}
$$

節點 $V$：

- service；
- database；
- API；
- team；
- customer；
- contract；
- deployment；
- policy。

邊 $E$：

- dependency；
- ownership；
- data flow；
- authorization；
- compatibility；
- contractual relation。

---

# 8. 一個修改不是只碰 code

若修改節點：

$$
v_i,
$$

實際影響：

$$
\boxed{
\text{Impact}(v_i)
=
\text{Reach}_{G_L}(v_i).
}
$$

所以：

> 改一個 API

可能同時是：

- code change；
- customer change；
- documentation change；
- contract change；
- billing change。

---

# 9. Change Surface

本文定義：

$$
\boxed{
S(\Delta)
=
\text{set of affected nodes and interfaces}.
}
$$

局部 patch：

$$
|S(\Delta)|\ll|G_L|.
$$

全域 reconstruction：

$$
S(\Delta)\approx G_L.
$$

---

# 10. Change Blast Radius

再定義：

$$
\boxed{
B_{\mathrm{change}}(\Delta)
=
f(
|S|,
\text{Centrality},
\text{Irreversibility},
\text{Externality},
\text{Uncertainty}
).
}
$$

這是一個診斷形式，不宣稱固定函數。

---

# 11. Blast Radius 與 Agent 能力

Agent 越能大範圍修改：

$$
\text{Capability}\uparrow,
$$

可觸及：

$$
|S|\uparrow.
$$

但同時：

$$
\boxed{
B_{\mathrm{change}}\uparrow.
}
$$

所以高能力 Agent 不必然獲得高授權。

---

# 12. Reconstruction Liability

本文提出：

$$
\boxed{
L_{\mathrm{reconstruction}}
}
$$

表示重構失敗後由組織承擔的：

- operational；
- financial；
- legal；
- security；
- reputational；
- maintenance；

責任。

---

# 13. 成功與失敗不對稱

全域重構成功：

> 得到較乾淨架構。

全域重構失敗：

> 可能造成 production-level damage。

因此決策不能只比較期望性能：

$$
U_{\mathrm{new}}>U_{\mathrm{old}}.
$$

還要看：

$$
\boxed{
EU
=
P_sV_s
-
P_fC_f.
}
$$

---

# 14. 大失敗成本使組織偏向局部

若：

$$
C_f\gg V_s,
$$

即使：

$$
P_s>P_f,
$$

組織仍可能合理選擇：

$$
\boxed{
\text{Minimal Change}.
}
$$

這不是必然保守，而是風險函數不同。

---

# 15. Compatibility Debt

本文定義：

$$
\boxed{
D_{\mathrm{compat}}
=
\text{deferred cost accumulated by preserving old interfaces,
states, conventions, and consumers}.
}
$$

來源包括：

- adapter；
- compatibility layer；
- legacy branch；
- special case；
- duplicated schema；
- translation layer；
- deprecated API support。

---

# 16. Compatibility Debt 與一般 Technical Debt 的差別

Technical Debt 很廣。

Compatibility Debt 特別指：

> 為了讓新結構繼續和舊世界共同存在而付出的債務。

所以：

$$
\boxed{
D_{\mathrm{compat}}
\subseteq
D_{\mathrm{technical}}
}
$$

可作為一個實用子類。

---

# 17. Dynamic Compatibility Debt

延續既有結構債務模型：

$$
\boxed{
D_{t+1}
=
\rho D_t
+
\alpha C_t^{\mathrm{patch}}
+
\beta L_t^{\mathrm{interface}}
+
\gamma H_t^{\mathrm{legacy}}
+
\eta X_t^{\mathrm{exception}}
-
\delta R_t.
}
$$

其中：

- $C_t^{patch}$：補丁耦合；
- $L_t^{interface}$：接口損失；
- $H_t^{legacy}$：legacy preservation load；
- $X_t^{exception}$：特殊例外；
- $R_t$：重構／刪除／統一。

---

# 18. Local Success Can Increase Global Debt

因此：

$$
\boxed{
Q_{\mathrm{local}}\uparrow
}
$$

可能同時：

$$
\boxed{
D_{\mathrm{compat}}\uparrow.
}
$$

例如：

> Bug 修好了。

但又多一層：

```text
if legacy_customer:
    ...
```

---

# 19. Patch Accumulation

每次：

$$
\Sigma_{t+1}
=
\Sigma_t\oplus P_t.
$$

局部誤差可能下降。

但 patch 彼此開始依賴後：

$$
\boxed{
C_{\mathrm{patch-coupling}}\uparrow.
}
$$

這會使未來重構更困難。

---

# 20. 舊理論的重構門檻

既有補丁化研究已提出：

若：

$$
\left|
\frac{dE_{\mathrm{local}}}{dn}
\right|
<
\lambda
\frac{dD}{dn},
$$

則新增補丁的邊際收益小於結構債務邊際成本。

這是一個非常適合 AI 工程的重構判斷形式。

---

# 21. AI 讓 Patch 更便宜

AI 使：

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

這是好事。

但也可能造成：

$$
PatchFrequency\uparrow.
$$

因此：

$$
\boxed{
\text{Cheaper Patch}
\not\Rightarrow
\text{Lower Long-Term Debt}.
}
$$

---

# 22. Patch Elasticity

本文提出：

$$
\boxed{
\epsilon_P
=
\frac{
\%\Delta PatchCount
}{
\%\Delta PatchCost^{-1}
}.
}
$$

如果 AI 讓 patch 太便宜，組織可能用更多 patch 延後 reconstruction。

此為候選度量。

---

# 23. AI Patch Trap

當：

$$
\text{PatchCost}\downarrow
$$

造成：

$$
PatchCount\uparrow\uparrow,
$$

並使：

$$
D_{\mathrm{compat}}\uparrow,
$$

本文稱：

$$
\boxed{
\text{AI Patch Trap}.
}
$$

---

# 24. 但「全部重寫」不是解答

另一個錯誤是：

> 有 AI 了，重寫整個系統就好。

這忽略：

- hidden requirements；
- production behavior；
- migration data；
- tacit knowledge；
- old customers；
- external integration。

---

# 25. Greenfield Illusion

本文稱：

$$
\boxed{
\text{Greenfield Illusion}
}
$$

即：

> 把 brownfield system 當作可以重新從零建構的 clean specification。

但：

$$
\boxed{
\text{ObservedLegacyBehavior}
}
$$

常本身已成為隱含 specification。

---

# 26. Legacy Behavior as Contract

如果客戶長期依賴某行為：

$$
b,
$$

即使：

> 沒寫在文件。

也可能形成：

$$
\boxed{
\text{De Facto Contract}.
}
$$

所以全域重寫不能只讀正式 spec。

---

# 27. Specification Incompleteness

對 mature system：

$$
\boxed{
Spec_{\mathrm{written}}
\subset
Spec_{\mathrm{effective}}.
}
$$

其中：

$$
Spec_{\mathrm{effective}}
=
Spec_{\mathrm{written}}
+
Behavior_{\mathrm{production}}
+
\text{TacitKnowledge}
+
\text{ExternalDependency}.
$$

---

# 28. AI 全域理解的真正需求

因此真正的 repository-scale intelligence 不只是：

> 看完所有 code。

還需要理解：

- runtime traces；
- production metrics；
- user behavior；
- issue history；
- review norms；
- contract；
- external API consumers。

---

# 29. METR：Test Pass 不等於 Mergeable

METR 2026 發現：

> 約一半通過 SWE-bench Verified automated grader 的 AI-generated PR，仍不會被 maintainer merge。

主要拒絕類型包含：

- code quality；
- breaks other code；
- core functionality failure。

因此：

$$
\boxed{
\text{Test Closure}
\neq
\text{Repository Closure}.
}
$$

---

# 30. Repository Acceptance Surface

本文定義：

$$
\boxed{
\Omega_{\mathrm{mergeable}}
}
$$

為：

> 不只通過 tests，還符合 repository 的 architecture、quality、maintainership 與 compatibility expectations 的 change space。

所以：

$$
\boxed{
\Omega_{\mathrm{test-pass}}
\not\subseteq
\Omega_{\mathrm{mergeable}}
}
$$

不能被假定為完全重合。

---

# 31. Maintainer Judgment 是一個重要層

Maintainer review 可能判斷：

- style；
- future maintainability；
- architecture；
- hidden coupling；
- scope appropriateness。

這些往往不是 unit test 能完全捕捉。

---

# 32. Agentic Refactoring 的實證訊號

2025 的大型 Agentic Refactoring 預印本分析：

- 15,451 個 refactoring instances；
- 12,256 PRs；
- 14,988 commits；

並報告 Agent 的 refactoring 明顯偏向：

- Change Variable Type；
- Rename Parameter；
- Rename Variable；

等低階、一致性導向修改。

研究者將此與人類更常進行高階 design refactoring 的情況對比。

這不是能力上限證明。

但顯示：

$$
\boxed{
\text{Observed Agent Refactoring}
}
$$

目前仍高度局部化。

---

# 33. 為什麼 Agent 偏局部

可能原因包括：

- task framing；
- limited authority；
- benchmark structure；
- risk；
- context；
- verification cost。

所以不能直接說：

> AI 不會高階重構。

---

# 34. 真正問題是 Reconstruction Eligibility

本文因此提出：

$$
\boxed{
\operatorname{Eligible}_{global}(q)
}
$$

而不是只問：

$$
\boxed{
\operatorname{Capable}_{global}(A,q).
}
$$

---

# 35. Reconstruction Eligibility Condition

若要允許全域 reconstruction，至少需要：

$$
\boxed{
\text{Auth}
\land
\text{Obs}
\land
\text{Dep}
\land
\text{Ver}
\land
\text{Rollback}
\land
\text{Owner}.
}
$$

其中：

- $Auth$：足夠修改權；
- $Obs$：足夠觀測；
- $Dep$：依賴可見；
- $Ver$：可驗證；
- $Rollback$：可回復；
- $Owner$：責任與決策擁有者明確。

---

# 36. 缺一項會怎樣

如果：

$$
\neg \text{Dep},
$$

可能漏掉 hidden consumers。

如果：

$$
\neg \text{Ver},
$$

無法確認重構沒有破壞行為。

如果：

$$
\neg \text{Rollback},
$$

失敗成本急升。

如果：

$$
\neg Owner,
$$

沒有誰能合法批准。

---

# 37. Authorized Reconstruction Radius

本文定義：

$$
\boxed{
r_A
=
\text{Authorized Reconstruction Radius}.
}
$$

表示 Agent 在指定 task 中被允許改動的依賴半徑。

---

# 38. $r_A$ 不是檔案數

它可以依：

- dependency hops；
- service boundary；
- ownership boundary；
- API boundary；
- blast radius；

定義。

所以：

$$
\boxed{
r_A
}
$$

是拓撲量，不是單純 LOC。

---

# 39. Observation Radius

同時定義：

$$
\boxed{
r_O
=
\text{Observation Radius}.
}
$$

若：

$$
r_A>r_O,
$$

Agent 被允許修改它無法完整觀察的範圍。

這非常危險。

因此提出：

$$
\boxed{
r_A
\le
r_O
}
$$

作為一個保守治理原則。

---

# 40. Verification Radius

另有：

$$
\boxed{
r_V
=
\text{Verification Radius}.
}
$$

更嚴格地：

$$
\boxed{
r_A
\le
\min(r_O,r_V)
}
$$

才適合自動 commit。

---

# 41. Rollback Radius

若：

$$
r_R
$$

表示可安全回滾範圍，

則 autonomous modification 應考慮：

$$
\boxed{
r_A
\le
r_R.
}
$$

---

# 42. Reconstruction Envelope

綜合得到：

$$
\boxed{
r_{\mathrm{deploy}}
=
\min(
r_{\mathrm{auth}},
r_O,
r_V,
r_R
).
}
$$

此為概念 envelope，不代表所有維度都可直接量化為相同距離。

---

# 43. Local Repair 的合理區域

當：

- dependency unknown；
- authority narrow；
- risk high；
- rollback weak；

最合理策略是：

$$
\boxed{
\text{Maximum Local Precision}
+
\text{Minimum Global Disturbance}.
}
$$

---

# 44. Maximum Local Precision

要求：

- 找到真正責任層；
- 不把 symptom 當 root cause；
- 建立最小 dependency cone；
- 用反例定位 defect；
- 只改必要結構。

---

# 45. Minimum Global Disturbance

要求：

- 不碰無關節點；
- preservation of contract；
- 明確 boundary test；
- 明確 side effects；
- 可回滾。

所以：

$$
\boxed{
\text{Local}
\neq
\text{Blind Patch.}
}
$$

---

# 46. Boundary Closure

局部修復至少要：

$$
\boxed{
\text{LocalClosure}
+
\text{BoundaryClosure}.
}
$$

即：

> 本地修好了。

還要：

> 與外界接點沒破。

---

# 47. Global-First Completion 的合理區域

相反地，若：

- scope 已明確；
- dependency graph 可見；
- sandbox 完整；
- task domain bounded；
- tests / verification 足夠；
- full authority 已取得；

則逐檔案施工可能產生不必要局部最優。

這時：

$$
\boxed{
\text{Global-First Completion}
}
$$

可能更合理。

---

# 48. Global-First ≠ Reckless Rewrite

Global-First 的核心不是：

> 一次亂改全部。

而是：

$$
\boxed{
\text{Bounded Domain}
\rightarrow
\text{Global Instantiation}
\rightarrow
\text{Global Validation}
\rightarrow
\text{Targeted Repair}.
}
$$

---

# 49. Local vs Global 不是二元哲學

本文拒絕：

$$
\boxed{
\text{LocalGood}
\quad \text{vs}\quad
\text{GlobalGood}.
}
$$

真正判準是：

$$
\boxed{
\text{Change Strategy}
=
f(
\text{Scope},
\text{DependencyVisibility},
\text{Authority},
\text{Verification},
\text{Rollback},
\text{Risk}
).
}
$$

---

# 50. Reconstruction Strategy Matrix

可概念化：

| 依賴可見度 | 驗證能力 | 授權 | 建議策略 |
|---|---|---|---|
| 低 | 低 | 低 | 最小局部修復 |
| 高 | 低 | 高 | 建模／補驗證，暫不全域改 |
| 高 | 高 | 低 | 全域分析，局部提交 |
| 高 | 高 | 高 | 可考慮 bounded global reconstruction |

這不是固定 policy，而是判斷模板。

---

# 51. Analysis Authority ≠ Modification Authority

AI 可以被允許：

$$
\boxed{
\text{Global Read / Analyze}
}
$$

但只具有：

$$
\boxed{
\text{Local Write}.
}
$$

這是一種非常有價值的中間狀態。

---

# 52. Global Observer, Local Actor

本文提出：

$$
\boxed{
\text{Global Observer}
+
\text{Local Actor}.
}
$$

AI 可以：

- 全 repo 建圖；
- 找 dependency；
- 找 architectural debt；

但：

- 只提交有限 patch。

這比：

> 既不讓 AI 看全域，也不讓它改全域

更有效。

---

# 53. Reconstruction Proposal Mode

對高 blast-radius 變更：

AI 不應直接 commit。

而先產生：

```yaml
reconstruction_proposal:
  target:
  rationale:
  affected_nodes:
  dependencies:
  preserved_contracts:
  migration_steps:
  compatibility_risks:
  verification_plan:
  rollback_plan:
  estimated_blast_radius:
  approval_required:
```

---

# 54. 這與舊補丁證書一致

既有補丁算子學已要求：

- scope；
- dependencies；
- side effects；
- verification；
- reversibility。

本文把它擴張成 software reconstruction certificate。

---

# 55. Reconstruction Certificate

定義：

$$
\boxed{
Cert_R(\Delta)
}
$$

至少包含：

- change identity；
- scope；
- dependency graph；
- affected interfaces；
- preserved invariants；
- migration；
- tests；
- rollback；
- owner；
- authority；
- uncertainty。

---

# 56. Cert 沒有完成，不應直接全域施工

對高風險 change：

$$
\boxed{
Cert_R(\Delta)=\text{Incomplete}
\Rightarrow
\text{NoAutonomousGlobalCommit}.
}
$$

---

# 57. Human Review 的角色

Human review 不應只是：

> 幫 AI 找 syntax error。

而是處理 AI 難以內生擁有的：

- business contract；
- future roadmap；
- social responsibility；
- organizational ownership；
- risk appetite。

---

# 58. Code Ownership

2026 IEEE TSE 的一項實驗發現，使用 AI 的參與者在 task completeness 上有明顯提升，但對自己實作程式碼的技術問題回答能力下降，研究者將其作為 code ownership 下降的 proxy。

這提示：

$$
\boxed{
\text{More Generated Code}
\neq
\text{More Organizational Understanding}.
}
$$

---

# 59. Ownership Debt

本文提出：

$$
\boxed{
D_{\mathrm{ownership}}
}
$$

表示：

> 程式碼變動速度超過團隊理解、責任歸屬與維護能力時累積的債務。

---

# 60. Ownership Debt 與 Compatibility Debt 可耦合

如果：

$$
D_{\mathrm{ownership}}\uparrow,
$$

團隊更難判斷哪些 legacy behavior 可以刪。

因此：

$$
D_{\mathrm{compat}}\uparrow
$$

也可能更容易發生。

---

# 61. AI-Generated Debt 的實證訊號

2026 年一篇大規模預印本分析：

- 304,362 verified AI-authored commits；
- 6,275 GitHub repositories；

報告 AI-authored commits 可引入：

- code smells；
- bugs；
- security issues；

且部分問題長期保留。

其中研究者報告：

> 24.2% 被追蹤的 AI-introduced issues 在其觀察終點仍存在。

此為預印本結果，需要後續重現與審查。

---

# 62. 這不代表 AI 寫 code 必然更差

該研究只能支持：

$$
\boxed{
\text{AI-generated code can create persistent maintenance debt}.
}
$$

不能推出：

$$
\boxed{
\text{AI code}
<
\text{Human code}
}
$$

作為普遍排序。

---

# 63. 關鍵是 Debt Governance

如果生成成本下降：

$$
\text{GenerationCost}\downarrow,
$$

企業必須同步提升：

$$
\boxed{
\text{DebtDetection}
+
\text{Refactoring}
+
\text{Verification}
+
\text{Ownership}.
}
$$

否則：

$$
\boxed{
\text{CodeProductionRate}
>
\text{MaintenanceAbsorptionRate}.
}
$$

---

# 64. Continuous Autonomous Refactoring

2026 年的 Continuous Autonomous Refactoring roadmap 將未來 AI refactoring 指向：

- multi-objective optimization；
- quality definition；
- multi-timescale heterogeneous signals；
- architecture / design patterns；
- trust；
- continuous delivery integration。

這與本文：

$$
\boxed{
\text{Refactoring}
\neq
\text{Local Code Rewrite}.
}
$$

高度一致。

---

# 65. 多目標最佳化

真正的架構重構至少同時最佳化：

$$
\boxed{
\{
\text{Correctness},
\text{Maintainability},
\text{Compatibility},
\text{Performance},
\text{Security},
\text{Cost},
\text{MigrationRisk}
\}.
}
$$

因此不存在單一：

$$
\text{best code}.
$$

---

# 66. Pareto Reconstruction Frontier

本文提出：

$$
\boxed{
\mathcal F_R
=
\text{Pareto Frontier of Reconstruction Candidates}.
}
$$

AI 不應只輸出：

> 最漂亮的方案。

而應輸出多個 trade-off：

```text
minimal patch
compatibility-preserving refactor
medium migration
clean rewrite
```

---

# 67. Decision Is Organizational

AI 可以計算：

$$
\mathcal F_R.
$$

但企業仍需決定：

$$
\boxed{
x^\*\in\mathcal F_R
}
$$

依：

- risk appetite；
- budget；
- roadmap；
- ownership。

---

# 68. Reconstruction Window

舊補丁理論已提出：

> 技術、工具、資料代際變化可能使重構成本暫時下降。

本文將其引入軟體工程：

$$
\boxed{
W_R(t)
=
\text{Reconstruction Window}.
}
$$

---

# 69. AI 可能打開新的 Reconstruction Window

如果 AI 讓：

- code migration；
- test generation；
- dependency analysis；
- documentation；

成本下降，

則：

$$
\boxed{
C_R(t)\downarrow.
}
$$

原本不值得重構的系統可能進入重構窗口。

---

# 70. 但窗口不是自動指令

仍需：

$$
\boxed{
C_R
+
L_{\mathrm{reconstruction}}
<
D_{\mathrm{future\ debt}}.
}
$$

才可能值得。

---

# 71. Reconstruction Necessity

延續舊 RNI 思路，可定義：

$$
\boxed{
\text{RNI}
=
f(
\text{StructuralMismatch},
\text{PatchCoupling},
\text{InterfaceLoss},
\text{FailureRisk},
\text{Recoverability}
).
}
$$

不建立未校準的硬公式。

---

# 72. Refactor / Rewrite / Preserve 三分

未來 AI 不應只給：

> rewrite / don't rewrite。

而至少分類：

$$
\boxed{
\{
\text{Preserve},
\text{Refactor},
\text{Reconstruct}
\}.
}
$$

---

# 73. Preserve

當：

- local fitness 高；
- debt controllable；
- migration risk 高；

保持現狀可能最合理。

---

# 74. Refactor

當：

- core semantics 要保持；
- architecture 可逐步改善；
- compatibility important；

適合 incremental refactoring。

---

# 75. Reconstruct

當：

- base structure mismatch；
- patch coupling high；
- interface debt high；
- migration tools mature；

才進入 reconstruction 候選。

---

# 76. Architecture Is Historical State

企業架構不是只有技術原因。

它沉積：

- past decisions；
- customers；
- acquisitions；
- failures；
- staffing；
- regulation。

所以：

$$
\boxed{
\text{Architecture}
=
\text{TechnicalStructure}
+
\text{HistoricalSedimentation}.
}
$$

---

# 77. 時代拓撲連接

這正是：

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

舊架構可能屬於不同技術時代，

但仍和現在：

- 資本；
- customer；
- governance；

形成有效耦合。

---

# 78. AI Refactoring 是跨時代轉換

當 AI 把：

$$
\Sigma_{\mathrm{legacy}}
\rightarrow
\Sigma_{\mathrm{new}},
$$

不是只轉 code。

而是：

$$
\boxed{
\text{Cross-Epoch Migration}.
}
$$

---

# 79. Migration Identity Preservation

重構後還必須回答：

> 它還是不是同一個產品／服務？

可定義核心不變量：

$$
\boxed{
K_{\mathrm{product}}.
}
$$

---

# 80. Kernel Preservation

對 change $\Delta$：

$$
\boxed{
\text{KP}(\Delta)
=
\frac{
|K_t\cap K_{t+1}|
}{
|K_t|
}.
}
$$

這是候選度量。

不假設所有 product identity 都能直接集合化。

---

# 81. 全域完成與局部修復的統一

本文最重要的方法論統一：

$$
\boxed{
\text{Global Understanding}
\neq
\text{Global Modification}.
}
$$

AI 應盡可能：

$$
\boxed{
\text{Understand Globally}.
}
$$

但施工半徑取決於：

$$
\boxed{
\text{Authorized Reconstruction Envelope}.
}
$$

---

# 82. Unified Principle

因此：

$$
\boxed{
\text{Global Analysis}
+
\text{Constraint-Aware Change Radius}
+
\text{Local/Global Closure}.
}
$$

這比固定：

> always local

或：

> always global

更合理。

---

# 83. Reconstruction Control Law

概念上：

$$
\boxed{
r_{\mathrm{change}}^\*
=
\max r
}
$$

subject to：

$$
\boxed{
\text{Auth}(r)
\land
\text{Obs}(r)
\land
\text{Ver}(r)
\land
\text{Rollback}(r)
\land
\text{Risk}(r)\le\tau.
}
$$

即：

> 在所有安全可閉包條件成立下，選擇最大的有效修改半徑。

---

# 84. 為什麼這對 AI 特別重要

人類工程師通常受：

- attention；
- coding speed；
- context capacity；

限制。

AI 正在放寬這些限制。

所以：

$$
\boxed{
\text{Implementation Radius}
}
$$

突然擴大。

但企業的：

$$
\boxed{
\text{Governance Radius}
}
$$

未必同步擴大。

---

# 85. Radius Mismatch

若：

$$
r_{\mathrm{AI-capability}}
\gg
r_{\mathrm{governance}},
$$

就產生：

$$
\boxed{
\text{Reconstruction Radius Mismatch}.
}
$$

---

# 86. 這也是企業 AI 吸收瓶頸

Paper 02 的：

$$
\mathfrak F_{\mathrm{AI}}
$$

在軟體架構層的一個具體形式就是：

$$
\boxed{
r_{\mathrm{AI-capability}}
-
r_{\mathrm{deployable}}.
}
$$

---

# 87. 可反駁假說 H1

在控制 task complexity 後：

> dependency visibility 越高，Agent 可安全使用的 change radius 越大。

---

# 88. 可反駁假說 H2

如果：

$$
\text{PatchCost}\downarrow
$$

但 reconstruction governance 不變，

AI adoption 可能先增加 patch frequency 與 compatibility debt。

---

# 89. 可反駁假說 H3

提供 global repository dependency context 的 Agent，即使只允許 local write，也應比 local-context-only Agent 產生更少 boundary regressions。

---

# 90. 可反駁假說 H4

高 blast-radius AI changes 若要求 Reconstruction Certificate，應降低：

- unexpected regressions；
- rollback failures；
- ownership ambiguity。

---

# 91. 可反駁假說 H5

存在某個 debt / risk 區域，使：

$$
\text{incremental patching}
$$

的長期總成本高於：

$$
\text{bounded reconstruction}.
$$

---

# 92. 可反駁假說 H6

AI 能力提升越快，若 authority / verification radius 不同步增加，Reconstruction Radius Mismatch 會暫時擴大。

---

# 93. 最小實證資料模型

```yaml
change_id:
agent:
task:
change_type:
  - patch
  - refactor
  - reconstruction
authorized_scope:
observed_scope:
verified_scope:
rollback_scope:
affected_nodes:
dependency_hops:
blast_radius:
compatibility_constraints:
preserved_invariants:
tests:
maintainer_review:
production_result:
rollback_required:
new_debt:
removed_debt:
owner:
approval:
```

---

# 94. Reconstruction Benchmark

未來可以建立：

$$
\boxed{
\text{RBench}
}
$$

不是只測：

> Agent 能不能重寫。

而測：

- global dependency understanding；
- contract preservation；
- blast-radius estimation；
- migration planning；
- rollback planning；
- architectural quality；
- maintainer acceptance。

---

# 95. Brownfield Benchmark

特別需要：

$$
\boxed{
\text{Brownfield AI Benchmark}.
}
$$

因為現實企業不是 clean repository。

需要：

- old versions；
- hidden tests；
- compatibility consumers；
- historical exceptions；
- incomplete docs。

---

# 96. 與 Paper 04 的接口

Paper 03 已處理：

$$
\boxed{
\text{AI}
\leftrightarrow
\text{Existing System}.
}
$$

但企業不是一個 AI 加一個 codebase。

下一篇要加入：

- multiple humans；
- multiple Agents；
- heterogeneous models；
- hidden AI usage；
- shared / divergent state。

因此 Paper 04 進入：

$$
\boxed{
\text{Multi-Actor Coupling Topology}.
}
$$

---

# 97. Claim Boundary

## $K$ ｜已有支持

已有外部資料支持：

- automated benchmark pass 不等於 maintainer acceptance；
- Agent refactoring 在現實資料中大量呈現局部、低階修改；
- AI-generated code 可產生持續存在的 maintenance issues；
- AI coding speed 提升會增加 auditing / verification 壓力；
- large-scale autonomous refactoring 仍面臨 architecture、quality、trust、continuous-delivery integration 問題。

## $E$ ｜本文推導

本文提出：

- Optimal / Authorized / Deployable Space；
- Compatibility Debt；
- Reconstruction Liability；
- Change Blast Radius；
- Authorized Reconstruction Radius；
- Observation / Verification / Rollback Radius；
- Reconstruction Envelope；
- AI Patch Trap；
- Greenfield Illusion；
- Ownership Debt；
- Reconstruction Window；
- Reconstruction Radius Mismatch；
- Reconstruction Certificate。

## $S$ ｜需要 simulation / repo study

- patch elasticity；
- change-radius vs regression；
- compatibility-debt dynamics；
- global observer / local actor strategy；
- reconstruction certificate effectiveness。

## $X$ ｜需要企業 field study

- true cost of global AI refactor；
- liability perception；
- authority boundary design；
- brownfield migration success；
- ownership debt。

## $F$ ｜工程化

- AI Reconstruction Auditor；
- Compatibility Debt Scanner；
- Blast Radius Estimator；
- Reconstruction Certificate Generator；
- Brownfield Agent Benchmark；
- Global Observer / Local Actor Runtime。

---

# 98. 結論

AI Coding Agent 正在越來越能：

> 看全域。

但企業並不因此自動應該讓它：

> 改全域。

這兩件事必須分開：

$$
\boxed{
\text{Global Understanding}
\neq
\text{Global Modification Authority}.
}
$$

現實工程中的最優解不是：

$$
\boxed{
\arg\max_{\Omega_{\mathrm{optimal}}}U.
}
$$

而是：

$$
\boxed{
\arg\max_{\Omega_{\mathrm{deployable}}}U.
}
$$

因此，AI 的局部 patch 並不總是低級方案。

在：

- 高不確定；
- 低 observability；
- 低 rollback；
- 高 liability；

的環境中：

$$
\boxed{
\text{Maximum Local Precision}
+
\text{Minimum Global Disturbance}
}
$$

可能是正確施工策略。

但當：

- domain bounded；
- dependency graph 可見；
- authority 充分；
- sandbox 完整；
- verification 完整；

時，只做局部 patch 反而可能累積：

$$
\boxed{
D_{\mathrm{compat}}
}
$$

並錯失：

$$
\boxed{
\text{Reconstruction Window}.
}
$$

此時：

$$
\boxed{
\text{Global-First Completion}
}
$$

成為更合理的方法。

所以這兩個看似衝突的方法其實可以統一為：

$$
\boxed{
\text{Global Analysis}
+
\text{Maximum Safe Change Radius}.
}
$$

其中 change radius 受：

$$
\boxed{
\text{Auth},
\text{Obs},
\text{Ver},
\text{Rollback},
\text{Risk}
}
$$

共同約束。

最終，企業真正需要的不是：

> 更敢讓 AI 改全部。

也不是：

> 永遠只讓 AI 補小洞。

而是建立一個能回答：

> **這一次，到底應該讓 AI 改多大？**

的治理與工程系統。

這就是：

$$
\boxed{
\text{Authorized Reconstruction Topology}.
}
$$

---

# 參考文獻與研究錨點

### 內部前置研究

[INT-01] Neo.K. 《AI 組織吸收與耦合拓撲 00：軟體時代鑲嵌與 AI 組織拓撲》v0.2. EveMissLab, 2026.

[INT-02] Neo.K. 《AI 組織吸收與耦合拓撲 01：有效問題覆蓋論》v0.1. EveMissLab, 2026.

[INT-03] Neo.K. 《AI 組織吸收與耦合拓撲 02：企業 AI 吸收論》v0.1. EveMissLab, 2026.

[INT-04] Neo.K. 《形式系統的補丁化累積：載體超載、局部擬合與結構債務》v1.0. EveMissLab, 2026.

[INT-05] Neo.K. 《理論補丁算子學》v0.1. EveMissLab, 2026.

[INT-06] Neo.K. 《全域完成論：AI 時代從局部完成到全域實例化的方法論》v1.0. EveMissLab, 2026.

### 外部研究

[R1] Whitfill, P., Wu, C., Becker, J., & Rush, N. **Many SWE-bench-Passing PRs Would Not Be Merged into Main.** METR, 2026-03-10.

[R2] Horikawa, K., Li, H., Kashiwa, Y., Adams, B., Iida, H., & Hassan, A. E. **Agentic Refactoring: An Empirical Study of AI Coding Agents.** arXiv:2511.04824, 2025.

[R3] Liu, Y., Widyasari, R., Zhao, Y., Irsan, I. C., & Lo, D. **Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild.** arXiv:2603.28592, 2026. Preprint.

[R4] DORA. **Balancing AI tensions: Moving from AI adoption to effective SDLC use.** 2026-03-10.

[R5] Marcilio, W. E., et al. **Evaluating the Effectiveness of LLMs in Fixing Maintainability Issues in Real-World Projects.** SANER 2025. IEEE.

[R6] IEEE Transactions on Software Engineering. **More Code, Less Understanding? On the Impact of AI Assistants on Developers’ Productivity and Code Ownership.** 2026.

[R7] Sun, X., Ståhl, D., Sandahl, K., & Kessler, C. **Continuous Autonomous Refactoring: A Research Roadmap for AI-Driven Code Quality Maintenance.** arXiv:2609.01236, 2026. Preprint.

[R8] IEEE. **Examining Software Engineering Practices in the Pre-AI and Post-AI ERA.** ICAIIC 2026.

---

*AI Organizational Absorption & Coupling Topology — Paper 03 v0.1*  
*EveMissLab — Boundless Knowledge. One Promise Forward.*