← Archive
lm-003974 · 2026-09

Feature 越多，作品反而越差？AI 時代的 Integration Debt

zh-Hant · md Raw source ↗ Metadata ↗
下載 MD 檔 ⬇

Feature 越多，作品反而越差？AI 時代的 Integration Debt

系列： AI 時代的創作、選擇與人類復古系列
篇次： 第 5 篇
版本： v0.1
性質： 理論論文／系統整合理論／公開版

摘要

現代數位創作經常把「功能增加」誤認為「價值增加」。遊戲增加更多系統、軟體增加更多模組、網站增加更多功能、AI 產品增加更多 Agent、工作流與模型，看起來都像產品能力在持續成長。然而，若新功能並沒有被既有系統真正需要，也沒有形成新的因果鏈、選擇結構與使用者價值，那麼功能數量的增加不但未必提高產品品質，甚至可能降低整體一致性、可理解性、可維護性與體驗密度。

本篇提出：

FeatureCount↑⇏ProductCoherence↑\boxed{ \text{FeatureCount}\uparrow \not\Rightarrow \text{ProductCoherence}\uparrow }

並正式定義 Integration Debt（整合債務）：

當一個系統持續增加局部功能、資料、模組、規則與內容，但這些新增部分未能同步建立足夠的跨系統依賴、回饋、驗證、因果關係與使用者可感知價值時，系統所累積的未完成整合成本。

本篇進一步提出 Integration Throughput、Feature Orphan Rate、Causal Coupling Density、Cross-System Dependency Ratio、Integration Coverage 與 Marginal Feature Value 等概念，並分析 AI 時代特有的風險：生成式 AI、Agent 與自動化讓新增功能的成本快速下降，但如果「新增速度」比「理解、整合、驗證速度」下降得更快，產品將進入高產量、低整合的結構性陷阱。

因此，AI 時代真正稀缺的能力可能不再是「做出更多功能」，而是：

讓更多功能彼此需要。\boxed{ \text{讓更多功能彼此需要。} }

關鍵詞

Integration Debt、Feature Growth、系統整合、AI 開發、遊戲設計、因果密度、Feature Orphan、Agentic Development、產品一致性、系統架構

1. 功能數量不是產品價值

創作者很容易把：

NF=Feature CountN_F = \text{Feature Count}

當成產品進度。

例如：

  • 多一套經濟系統；
  • 多一種貨幣；
  • 多一個角色；
  • 多一條任務線；
  • 多一組技能；
  • 多一個派系；
  • 多一個 AI Agent；
  • 多一個插件；
  • 多一個儀表板。

於是：

NF↑N_F\uparrow

在開發者眼中很容易被感受到：

產品變豐富了。

但使用者真正得到的不是：

NFN_F

而是：

Connected Experience\boxed{ \text{Connected Experience} }

因此：

Feature Count≠Experience Value\boxed{ \text{Feature Count} \neq \text{Experience Value} }

2. 功能可以存在，但不必有意義

假設系統中有功能：

FiF_i

如果它：

  • 不影響其他系統；
  • 不改變使用者決策；
  • 不改變未來狀態；
  • 不創造新的策略；
  • 不被其他功能讀取；
  • 不被劇情、AI、經濟或世界回饋使用；

那麼：

FiF_i

雖然存在，

但它可能只是：

Feature-shaped Content\boxed{ \text{Feature-shaped Content} }

而不是：

Integrated System Component\boxed{ \text{Integrated System Component} }

3. 「有功能」與「功能被需要」是兩個層級

定義：

Exist(Fi)=1Exist(F_i)=1

只表示：

這個功能在產品裡。

但真正高階的是：

Need(Fi,Fj)>0Need(F_i,F_j)>0

即：

系統 FjF_j 會因為 FiF_i 的存在而改變。

因此成熟產品不是單純：

{F1,F2,…,Fn}\{F_1,F_2,\dots,F_n\}

而是：

GF=(VF,EF)\boxed{ G_F=(V_F,E_F) }

其中：

  • VFV_F：功能節點；
  • EFE_F：功能之間的依賴、回饋與因果邊。

產品真正的深度更接近：

∣EF∣|E_F|

而不是：

∣VF∣|V_F|

4. 系統價值來自關係，而不只是節點

假設兩款遊戲都有十個系統。

A：

∣V∣=10,∣E∣=8|V|=10,\quad |E|=8

B：

∣V∣=10,∣E∣=35|V|=10,\quad |E|=35

若 B 的耦合是有意義且可理解的，則 B 通常能形成更多：

  • 策略；
  • 回饋；
  • 取捨；
  • 意外組合；
  • 世界反應。

因此：

System Depth≈f(Meaningful Relations)\boxed{ \text{System Depth} \approx f( \text{Meaningful Relations} ) }

而不是：

f(Feature Names)f( \text{Feature Names} )

5. Integration Debt 的正式定義

本篇定義：

DI=Integration DebtD_I = \text{Integration Debt}

表示：

已經存在但尚未被充分整合的系統複雜度。

可以粗略表示為：

DI=Cimplemented−Cintegrated\boxed{ D_I = C_{implemented} - C_{integrated} }

其中：

  • CimplementedC_{implemented}：已實作複雜度；
  • CintegratedC_{integrated}：已形成跨系統有效關係的複雜度。

當：

Cimplemented↑C_{implemented}\uparrow

但：

CintegratedC_{integrated}

成長較慢，

則：

DI↑\boxed{ D_I\uparrow }

6. Integration Debt 和 Technical Debt 不一樣

Technical Debt 通常指：

  • 程式結構；
  • 可維護性；
  • workaround；
  • 重複程式；
  • 低品質架構。

而 Integration Debt 更接近：

產品層與系統層的未完成關係。\boxed{ \text{產品層與系統層的未完成關係。} }

例如：

  • 經濟系統存在，但錢無處可花；
  • 城市數值存在，但玩家決策不讀它；
  • NPC 有名字，但沒有持續狀態；
  • 結局存在，但不記得前面的選擇；
  • AI 有戰鬥能力，但不理解遊戲公式；
  • 自訂系統存在，但 bonus 被另一個 cap 吃掉；
  • 有 faction 系統，但與玩家角色成長幾乎分離。

這些可能：

CodeCorrect=1CodeCorrect=1

但：

ProductIntegration<1\boxed{ ProductIntegration<1 }

7. 功能導向開發的陷阱

可以把一種常見流程寫成：

F1→F2→F3→⋯→Fn\boxed{ F_1 \rightarrow F_2 \rightarrow F_3 \rightarrow \dots \rightarrow F_n }

每完成一個功能就往下一個走。

這叫：

Feature-Oriented Development\boxed{ \text{Feature-Oriented Development} }

它本身不是錯。

問題在於如果缺少：

Integration Pass\boxed{ \text{Integration Pass} }

則：

FiF_i

會被當成：

完成。

但真正狀態可能只是：

Locally Complete\boxed{ \text{Locally Complete} }

而不是：

Globally Integrated\boxed{ \text{Globally Integrated} }

8. Local Completion 與 Global Completion

定義：

L(Fi)=Local CompletionL(F_i) = \text{Local Completion}

表示：

  • 能運作；
  • UI 能顯示；
  • 資料能保存；
  • 基本邏輯正確。

而：

G(Fi)=Global CompletionG(F_i) = \text{Global Completion}

則要求：

  • 被其他系統讀取；
  • 形成玩家取捨；
  • 有長期後果；
  • 有反饋；
  • 有測試；
  • 有敘事／經濟／AI／世界耦合。

因此：

L(Fi)=1⇏G(Fi)=1\boxed{ L(F_i)=1 \not\Rightarrow G(F_i)=1 }

9. 「功能完成」是最危險的錯覺之一

因為：

L(Fi)=1L(F_i)=1

會給開發者強烈的完成感。

畫面能跑。

按鈕能按。

數值會變。

資料會存。

於是：

好，下一個。

但使用者真正感受到的可能是：

這東西有什麼用？

因此：

Implementation Success≠Product Success\boxed{ \text{Implementation Success} \neq \text{Product Success} }

10. Feature Orphan

本篇定義：

Feature Orphan\boxed{ \text{Feature Orphan} }

為：

已存在但缺乏足夠跨系統依賴的功能節點。

可定義 Orphan 指標：

Oi=11+diO_i = \frac{1}{1+d_i}

其中：

did_i

是功能 FiF_i 的有效跨系統連結數。

若：

di→0d_i\rightarrow0

則：

Oi→1O_i\rightarrow1

代表：

高孤兒化。

11. Feature Orphan Rate

整體可定義：

FOR=NorphanNfeature\boxed{ FOR = \frac{ N_{\text{orphan}} }{ N_{\text{feature}} } }

如果：

FOR↑FOR\uparrow

代表產品裡：

有很多東西，但彼此不太需要。

這種產品會產生一種非常特殊的體驗：

看起來很豐富，玩起來很薄。\boxed{ \text{看起來很豐富，玩起來很薄。} }

12. Causal Coupling Density

可以進一步定義：

CCD=∣Ecausal∣∣VF∣\boxed{ CCD = \frac{ |E_{causal}| }{ |V_F| } }

其中：

∣Ecausal∣|E_{causal}|

只計算真正會造成：

Wt→Wt+1W_t \rightarrow W_{t+1}

變化的有效關係。

因此：

CCD↑CCD\uparrow

表示：

每一個系統平均和更多有意義後果連結。

這比：

FeatureCountFeatureCount

更接近玩家感受到的系統密度。

13. Cross-System Dependency Ratio

再定義：

CSDR=Ncross-system reads/writesNsystem operations\boxed{ CSDR = \frac{ N_{\text{cross-system reads/writes}} }{ N_{\text{system operations}} } }

例如：

  • 城市經濟是否影響商店；
  • 關係是否影響任務；
  • 任務是否影響 ending；
  • 機體狀態是否影響角色；
  • 角色關係是否影響 AI；
  • 世界戰爭是否改變資源；
  • 玩家選擇是否改變 NPC 行為。

如果：

CSDRCSDR

很低，

表示系統多數時間只在：

Self-Contained Loops\boxed{ \text{Self-Contained Loops} }

裡運作。

14. Integration Coverage

設：

RpossibleR_{possible}

為設計上合理的關係集合，

RimplementedR_{implemented}

為已實作的有效關係。

則：

IC=∣Rimplemented∣∣Rpossible∣\boxed{ IC = \frac{ |R_{implemented}| }{ |R_{possible}| } }

這不是要求：

所有系統都互相連。

那會造成過度耦合。

真正目標是：

Important Relations Are Implemented\boxed{ \text{Important Relations Are Implemented} }

也就是：

關鍵因果關係不能缺席。

15. 整合不是把所有東西硬接在一起

Integration Debt 理論不主張：

∀i,j,Fi↔Fj\forall i,j,\quad F_i\leftrightarrow F_j

那會產生：

Spaghetti System\boxed{ \text{Spaghetti System} }

成熟整合應該是：

Selective Coupling\boxed{ \text{Selective Coupling} }

即：

只建立真正能創造決策與意義的關係。

所以整合的核心仍然是：

Selection\boxed{ \text{Selection} }

而不是：

Maximum Connectivity\text{Maximum Connectivity}

16. Integration Debt 的累積公式

可以粗略表示：

DI(t+1)=DI(t)+ΔFt−ΔItD_I(t+1) = D_I(t) + \Delta F_t - \Delta I_t

其中：

  • ΔFt\Delta F_t：新增功能複雜度；
  • ΔIt\Delta I_t：新增整合能力。

若長期：

ΔFt>ΔIt\Delta F_t > \Delta I_t

則：

DI↑\boxed{ D_I\uparrow }

17. Integration Throughput

定義：

TI=Integration Throughput\boxed{ T_I = \text{Integration Throughput} }

即單位時間能完成多少：

  • 跨系統連結；
  • 全域驗證；
  • 玩法整合；
  • 邊界案例；
  • 回歸測試；
  • 玩家回饋修正；
  • 因果一致性檢查。

那麼穩定條件可以寫：

TI≥TF\boxed{ T_I \ge T_F }

其中：

TF=Feature Production ThroughputT_F = \text{Feature Production Throughput}

18. AI 時代最危險的地方出現了

生成式 AI、Agent、Copilot、程式生成、素材生成會讓：

TF↑↑T_F\uparrow\uparrow

但如果：

TIT_I

沒有同步提升，

則：

TFTI↑\boxed{ \frac{T_F}{T_I} \uparrow }

Integration Debt 會加速累積。

這意味著：

AI 可能讓產品更快地變得更亂。\boxed{ \text{AI 可能讓產品更快地變得更亂。} }

19. 「AI 讓我一天做十個功能」不一定是好消息

以前：

TF=1T_F=1

所以一週增加七個功能。

未來：

TF=10T_F=10

一天就增加十個。

若整合能力仍：

TI=1T_I=1

那麼：

DI\boxed{ D_I }

將快速爆炸。

所以：

AI 提高產能。

只是上半句。

下半句是：

整合能力有沒有同比提升？\boxed{ \text{整合能力有沒有同比提升？} }

20. AI 讓 Feature Inflation 更容易

當新增功能成本下降：

Cost(Fi)↓Cost(F_i)\downarrow

開發者更容易說：

順便加一個。

於是：

NF↑N_F\uparrow

這叫：

Feature Inflation\boxed{ \text{Feature Inflation} }

它和貨幣通膨很像：

單個功能變便宜了，但整個產品被更多功能稀釋。

21. 功能通膨會降低每個功能的注意力

創作者注意力：

AA

有限。

若：

NF↑N_F\uparrow

則每個功能平均可獲得：

ANF\frac{A}{N_F}

因此：

NF↑⇒ANF↓N_F\uparrow \Rightarrow \frac{A}{N_F}\downarrow

結果：

  • 測試變少；
  • 文件變少；
  • 平衡變少；
  • 互相連結變少；
  • 邊界案例變少。

這會反過來：

DI↑D_I\uparrow

22. AI 生成內容尤其容易產生「表面完成」

AI 很擅長產出：

  • 程式碼；
  • UI；
  • 角色；
  • 任務；
  • 文案；
  • 資料；
  • 圖片；
  • 設定。

這些東西很容易讓：

Visible Completion\boxed{ \text{Visible Completion} }

快速增加。

但：

Invisible Integration\boxed{ \text{Invisible Integration} }

通常更難。

例如：

任務寫好了。

和：

任務真的影響世界、角色、經濟與 ending。

是完全不同的工作量。

23. AI 時代的瓶頸從生成轉向整合

過去：

Bottleneck=Production\boxed{ \text{Bottleneck} = \text{Production} }

未來越來越可能：

Bottleneck=Integration+Evaluation+Selection\boxed{ \text{Bottleneck} = \text{Integration} + \text{Evaluation} + \text{Selection} }

也就是：

做出東西越來越容易。

但：

知道哪些東西該存在、如何彼此作用、哪些該刪掉，反而更難。

24. Marginal Feature Value

定義新增功能：

Fn+1F_{n+1}

的邊際價值：

MFV=ΔVproduct(Fn+1)\boxed{ MFV = \Delta V_{product}(F_{n+1}) }

很多開發者假設：

MFV>0MFV>0

但實際上可能：

MFV=0MFV=0

甚至：

MFV<0\boxed{ MFV<0 }

25. Feature 真的可以讓產品變差

新增功能可能增加：

  • UI 複雜度；
  • 教學成本；
  • 平衡成本；
  • Bug 面積；
  • 認知負擔；
  • 維護成本；
  • 測試矩陣；
  • 玩家誤解。

所以：

Benefit(Fi)<IntegrationCost(Fi)Benefit(F_i) < IntegrationCost(F_i)

時：

MFV<0\boxed{ MFV<0 }

26. 「刪功能」可以是正向開發

如果某功能：

FiF_i

造成：

MFV(Fi)<0MFV(F_i)<0

則移除：

−Fi-F_i

可能：

Vproduct↑\boxed{ V_{product}\uparrow }

因此成熟開發不是：

一直加。

而是：

Add+Integrate+Merge+Delete\boxed{ \text{Add} + \text{Integrate} + \text{Merge} + \text{Delete} }

27. Integration Debt 會產生「系統名詞幻覺」

產品可能有：

  • 經濟；
  • 外交；
  • 政治；
  • 勢力；
  • 城市；
  • 忠誠；
  • 聲望；
  • 科技；
  • 角色；
  • 關係；
  • 世界狀態。

看起來：

NFN_F

很高。

但玩家真正需要理解的決策：

NDN_D

可能很少。

因此：

System Vocabulary≫Decision Vocabulary\boxed{ \text{System Vocabulary} \gg \text{Decision Vocabulary} }

這就是：

System-Name Illusion\boxed{ \text{System-Name Illusion} }

28. 玩家真正感受到的是 Decision Density

定義：

DD=Nmeaningful decisionsTplay\boxed{ DD = \frac{ N_{\text{meaningful decisions}} }{ T_{\text{play}} } }

如果系統很多，但：

DDDD

很低，

玩家會覺得：

東西很多，但我其實一直做同樣的事。

因此：

Decision Density\boxed{ \text{Decision Density} }

比功能數量更接近遊戲深度。

29. Integration Debt 也會傷害敘事

如果：

  • 任務不記得前面；
  • NPC 不記得互動；
  • ending 不讀 mission history；
  • 世界不讀角色行為；

那麼：

Narrative State Persistence\boxed{ \text{Narrative State Persistence} }

很低。

結果：

劇情很多，但人生很薄。

所以：

Narrative Quantity≠Narrative Continuity\boxed{ \text{Narrative Quantity} \neq \text{Narrative Continuity} }

30. Integration Debt 也會傷害經濟

經濟不是：

有錢。

而是：

資源約束選擇。\boxed{ \text{資源約束選擇。} }

若：

Income≫UsefulSinksIncome\gg UsefulSinks

則：

MarginalUtility(Money)→0MarginalUtility(Money)\rightarrow0

所以：

貨幣存在。

不代表：

經濟存在。

真正經濟要求：

Resource→Trade-off→Future State\boxed{ \text{Resource} \rightarrow \text{Trade-off} \rightarrow \text{Future State} }

31. Integration Debt 也會傷害角色系統

角色有：

  • 名字；
  • 立繪；
  • 數值；
  • 技能；

但如果沒有：

  • 記憶；
  • 關係；
  • 持續狀態；
  • 專屬選擇；
  • 世界反應；

那角色可能只是：

Decorated Data Objects\boxed{ \text{Decorated Data Objects} }

而不是：

Persistent Actors\boxed{ \text{Persistent Actors} }

32. Integration Debt 也會傷害 AI

遊戲有複雜戰鬥公式：

CombatDepth↑CombatDepth\uparrow

但 AI 只使用：

  • 距離；
  • 最近敵人；
  • 簡單 priority。

那：

AIModelDepth<GameSystemDepth\boxed{ AIModelDepth < GameSystemDepth }

結果遊戲自己都沒有真正「理解」自己的系統。

這也是一種：

Model Integration Debt\boxed{ \text{Model Integration Debt} }

33. AI Agent 可以成為 Integration Auditor

這也是 AI 真正有價值的地方。

不是只：

幫忙加功能。

而是讓 Agent 問：

  • 這個變量被誰讀？
  • 這個資源何時有約束？
  • 這個任務改變哪些持久狀態？
  • 這個角色被哪些系統記住？
  • 這個 ending 讀了哪些歷史？
  • 這個 buff 在最終公式中真的有效嗎？
  • 這個城市 stat 是否改變玩家決策？

這就是：

Integration Audit\boxed{ \text{Integration Audit} }

34. AI 最值得做的是「全域差分」

每次加入：

Fn+1F_{n+1}

Agent 不只測：

它能不能跑。

而是問：

ΔG=Gafter−Gbefore\boxed{ \Delta G = G_{after} - G_{before} }

即：

整個產品因為它變了什麼？

如果：

ΔG≈0\Delta G\approx0

那麼：

Fn+1F_{n+1}

可能只是：

Decorative Complexity\boxed{ \text{Decorative Complexity} }

35. Integration Gate

本篇提出：

Integration Gate\boxed{ \text{Integration Gate} }

每個重大功能完成前至少問：

1.

它改變哪些玩家決策？

2.

哪些其他系統會讀它？

3.

哪些狀態會因它改變？

4.

玩家如何知道它重要？

5.

它有哪些長期後果？

6.

它如何被 AI／NPC／世界使用？

7.

它的失敗模式是否有回歸測試？

如果多數答案是：

沒有。

那麼功能可能還沒有：

Global Completion\boxed{ \text{Global Completion} }

36. Feature Dependency Ledger

可以建立：

Feature Reads Writes Player Decision Long-term State AI Use Regression
FiF_i ... ... ... ... ... ...

如果一列大量空白：

Potential Integration Debt\boxed{ \text{Potential Integration Debt} }

這種東西非常適合由 AI 自動生成與維護。

37. AI 時代應該有 Integration Agent

未來一個小團隊甚至可以配置：

Feature Agent\boxed{ \text{Feature Agent} }

負責生產。

再配置：

Integration Agent\boxed{ \text{Integration Agent} }

專門反問：

為什麼要有這個？

以及：

Regression Agent\boxed{ \text{Regression Agent} }

確認：

加了它之後，舊系統有沒有壞？

因此：

Generate→Integrate→Verify\boxed{ \text{Generate} \rightarrow \text{Integrate} \rightarrow \text{Verify} }

應該成為新的開發基本循環。

38. Integration Debt 和 Context Debt

系統越大：

NF↑N_F\uparrow

人類越難同時記住全部。

所以：

Context Debt\boxed{ \text{Context Debt} }

也會增加。

也就是：

沒有人真的記得整個產品。

此時每個新功能都更容易局部合理、全域錯誤。

AI 長上下文、程式索引、圖資料庫、狀態摘要正好可以用來降低這種問題。

39. 「看完整個專案」會變成新能力

未來真正強的 AI 開發能力，不只是：

寫一個函數。

而是：

Read Whole System→Model Dependencies→Find Missing Relations\boxed{ \text{Read Whole System} \rightarrow \text{Model Dependencies} \rightarrow \text{Find Missing Relations} }

這等於把：

Architectural Attention\boxed{ \text{Architectural Attention} }

變成一種可以外掛的能力。

40. Integration Debt 與一人團隊

Solo developer 特別容易出現：

Creator Blind Spot\boxed{ \text{Creator Blind Spot} }

因為：

  • 同一個人設計；
  • 同一個人實作；
  • 同一個人測試；
  • 同一個人知道所有隱含規則。

所以他會自動補完：

Missing Connections in Mind\boxed{ \text{Missing Connections in Mind} }

但玩家不會。

因此產品實際存在的連結：

EproductE_{product}

和創作者腦中的：

EmentalE_{mental}

可能不同。

41. Mental Integration Illusion

若：

Emental>EproductE_{mental} > E_{product}

創作者會覺得：

當然有關係啊。

因為他知道：

  • 設定；
  • 背景；
  • 隱含邏輯；
  • 設計意圖。

但玩家只能看到：

EproductE_{product}

所以：

Design Intention≠Implemented Causality\boxed{ \text{Design Intention} \neq \text{Implemented Causality} }

42. AI 可以充當「不知道的第二腦」

這就是 AI 作為第二設計師的前置理由。

讓 AI：

  • 不給隱藏背景；
  • 只看遊戲；
  • 只看 UI；
  • 只看程式；
  • 只看資料；

然後問：

我能不能自己推導這個系統？

可以暴露：

Knowledge Leakage\boxed{ \text{Knowledge Leakage} }

即：

只有作者知道，產品本身沒有說。

43. Integration Debt 的經濟成本

每一筆 Integration Debt 都會增加未來：

CchangeC_{change}

因為新功能需要處理：

  • 更多例外；
  • 更多相互作用；
  • 更多 bug；
  • 更多測試；
  • 更多資料遷移。

所以：

DI↑⇒Cchange↑D_I\uparrow \Rightarrow C_{change}\uparrow

並可能：

Velocity↓Velocity\downarrow

44. Integration Debt 的玩家成本

玩家則承受：

Cognitive Load\boxed{ \text{Cognitive Load} }

他必須理解大量：

SiS_i

但不知道哪些真正重要。

因此：

Displayed Complexity>Useful Complexity\boxed{ \text{Displayed Complexity} > \text{Useful Complexity} }

時，

遊戲會顯得：

複雜但不深。

45. Complexity 與 Depth 必須分開

定義：

C=ComplexityC = \text{Complexity} D=DepthD = \text{Depth}

功能增加通常：

C↑C\uparrow

但只有在形成新的：

  • 策略；
  • 取捨；
  • 路徑；
  • 因果；
  • 選擇；

時：

D↑D\uparrow

所以：

C↑⇏D↑\boxed{ C\uparrow \not\Rightarrow D\uparrow }

甚至：

C↑,D≈constantC\uparrow,\quad D\approx \text{constant}

就是典型 Integration Debt。

46. 最危險的是「深度幻覺」

當：

NFN_F

很大，

創作者與宣傳都容易說：

很深。

但真正深度應該接近：

Meaningful Choice Paths\boxed{ \text{Meaningful Choice Paths} }

而不是：

Menu Count\text{Menu Count}

因此：

Depth≈Reachable Meaningful State Diversity\boxed{ \text{Depth} \approx \text{Reachable Meaningful State Diversity} }

47. Integration Debt 的真正對偶：Integration Capital

既然有債務，也有資本。

定義：

CI=Integration Capital\boxed{ C_I = \text{Integration Capital} }

包括：

  • 明確 dependency graph；
  • 回歸測試；
  • 系統狀態模型；
  • AI audit；
  • 設計規範；
  • 可重用耦合介面；
  • 玩家行為 telemetry；
  • release checklist；
  • simulation harness。

這些都能讓：

TI↑T_I\uparrow

48. Integration Capital 可以跨作品累積

成熟工作室第四款遊戲不應只是：

CodeCapital4>CodeCapital1CodeCapital_4 > CodeCapital_1

而應該：

IntegrationCapital4>IntegrationCapital1\boxed{ IntegrationCapital_4 > IntegrationCapital_1 }

也就是：

不只是做得更多。

而是：

更知道如何讓東西互相需要。

49. AI 時代真正應該累積的是整合資本

AI 可以讓：

CodeCapitalCodeCapital

與：

AssetCapitalAssetCapital

更便宜。

所以真正稀缺的會逐步轉向：

IntegrationCapital\boxed{ IntegrationCapital }

包括：

  • 系統圖；
  • 測試圖；
  • 關係圖；
  • design grammar；
  • state model；
  • error memory；
  • review history。

這些東西會成為：

AI-Native Production Moat\boxed{ \text{AI-Native Production Moat} }

50. 最小可行 Integration Loop

一個 AI 時代的基本循環可以是：

Design→Implement→Integrate→Simulate→Audit→Revise\boxed{ \text{Design} \rightarrow \text{Implement} \rightarrow \text{Integrate} \rightarrow \text{Simulate} \rightarrow \text{Audit} \rightarrow \text{Revise} }

而不是：

Design→Implement→Next Feature\boxed{ \text{Design} \rightarrow \text{Implement} \rightarrow \text{Next Feature} }

51. 「完成」的重新定義

未來：

Done(Fi)\boxed{ Done(F_i) }

不應只等於：

Implemented(Fi)Implemented(F_i)

而應該至少：

Done(Fi)=Implemented+Connected+Tested+Explained+Observed\boxed{ Done(F_i) = Implemented + Connected + Tested + Explained + Observed }

這才接近真正產品完成。

52. 系列中的位置

前四篇已經建立：

Human-Made⇏Value\text{Human-Made} \not\Rightarrow \text{Value}

以及：

Production Method⇏Consumer Utility\text{Production Method} \not\Rightarrow \text{Consumer Utility}

第五篇進一步說：

Content / Feature Production⇏Integrated Experience\boxed{ \text{Content / Feature Production} \not\Rightarrow \text{Integrated Experience} }

這使整個系列從：

AI vs Human\text{AI vs Human}

正式轉向：

Production Architecture\boxed{ \text{Production Architecture} }

53. 下一篇：AI 作為第二設計師

如果 Integration Debt 的核心是：

沒有人持續從全域重新看整個產品。

那麼 AI 的最佳角色之一就自然出現：

AI as Permanent Second Designer\boxed{ \text{AI as Permanent Second Designer} }

下一篇將處理：

  • AI 如何做系統審核；
  • 如何當 red team；
  • 如何問「這東西有什麼用」；
  • 如何找全域不一致；
  • 如何把創作者腦內的隱含關係轉成可驗證關係；
  • 為什麼 AI 的價值可能不是生成，而是反對與審查。

54. 結論

AI 時代最容易被誤判的進步是：

做東西變快了。\boxed{ \text{做東西變快了。} }

但真正重要的是：

把東西變成一個整體，有沒有同步變快？\boxed{ \text{把東西變成一個整體，有沒有同步變快？} }

如果：

Feature Growth>Integration Growth\text{Feature Growth} > \text{Integration Growth}

那麼：

AI 越強，Integration Debt 可能累積得越快。\boxed{ \text{AI 越強，Integration Debt 可能累積得越快。} }

因此未來的高品質創作，不應以：

做了多少功能\boxed{ \text{做了多少功能} }

為核心指標。

而應更接近：

有多少功能彼此真正需要。\boxed{ \text{有多少功能彼此真正需要。} }

更進一步：

產品深度不是節點數，而是有意義的關係數。\boxed{ \text{產品深度不是節點數，而是有意義的關係數。} }

所以 AI 時代真正稀缺的能力，可能不再是生成更多：

  • 圖；
  • 程式；
  • 角色；
  • 系統；
  • 任務。

而是：

知道哪些不該做，哪些該留下，以及留下的東西應該如何互相改變彼此。\boxed{ \text{知道哪些不該做，哪些該留下，以及留下的東西應該如何互相改變彼此。} }

這就是 Integration Debt 理論真正要指出的核心。

AI 可以讓功能生產接近無限。

但如果整合能力沒有跟上，

那麼：

無限生產能力\boxed{ \text{無限生產能力} }

最後只會得到：

無限未完成的整合。\boxed{ \text{無限未完成的整合。} }