從 Framework、Architecture 到 AI Coding 的工程閉環

前面 29 天，我們一直在追 Vue 3.6 到底改善了什麼？

一路從 Vue 3.5.40 Baseline 跑到 Vue 3.6 RC，再把成本拆成 Framework Runtime、JavaScript、Rendering、Layout 等不同層級，最後得到的結果也很明確：

• Reactive Chain：Reactive Graph 沒有因版本升級而改變。
• Component Storm：Update Cost 有改善證據，但 Runtime Attribution 仍不足以直接歸因給 Vue Runtime。
• Composable Chaos：Depth 20 的 JavaScript-level Cost 下降，但 Runtime Attribution 仍不足。
• VDOM Stress：Vapor 改變了 Runtime Cost Structure，Framework Cost 明顯下降後，Browser Rendering 成為剩餘成本的重要部分。

這些結果最後指向同一件事：

Framework
    │
    │ Vue 3.5 → 3.6
    ↓
Runtime Evidence
    │
    ↓
Architecture

Framework 可以改變單次 Work 的成本，但系統到底產生多少 Work，還要回到 Architecture。

Architecture 會落在 Boundary 上

前面的 Component Storm 與 Composable Chaos，剛好對應兩種不同的 Boundary。

Component Boundary

Component Storm 測試大量 Component 存在時的 Runtime Cost。

因此真正的 Architecture 問題是：

這個 UI 需要幾個 Component？

哪些差異值得建立新的 Render Boundary？

哪些 Component 只是把原本的 UI 切得更細？

Component 越多，不代表架構越好。

Component 越少，也不代表架構越好。

需要確認的是：這個 Boundary 是否承擔明確責任。

Reactive Boundary

Composable Chaos 則把 Boundary 往 Reactive Logic 移動。

useLayer20()
    ↓
useLayer19()
    ↓
   ...
    ↓
useLayer1()
    ↓
Reactive Graph

這裡需要驗證：

這層 Composable 解決了什麼責任？

增加這層後，Reactive Dependency 有沒有變複雜？

抽象帶來的維護價值，是否值得增加的 Runtime Work？

因此 Component 與 Composable 雖然都是抽象工具，控制的是不同 Boundary。

AI Coding 把 Boundary 問題放大

當 AI 可以快速產生 Component、Composable 與各種封裝，問題會從「怎麼寫」變成：

應該建立什麼？
應該放在哪裡？
需要增加這個 Boundary 嗎？

例如建立 Dialog，AI 可能依照需求直接產生：

UserDialog.vue
ConfirmDialog.vue
DeleteDialog.vue
WarningDialog.vue

程式都能運作，但工程師需要先檢查：

差異來自 UI？
差異來自行為？
差異是否足以形成新的 Component Boundary？

這就是 AI Coding 與 Architecture 開始接上的地方。

Architecture 規則需要進入 AI Coding 流程

前面的 D27、D28 已經把這件事拆成三個控制點：

Prompt

把專案既有的 Architecture 規則告訴 AI，例如：

建立新的 Component 前：
1. 說明新增 Boundary 的責任
2. 確認既有 Component 是否可以重用
3. 說明為什麼現有 Boundary 無法滿足需求

Design System

提供已經存在的 UI Boundary 與 API，AI 有可重用的選項，就不需要每次從零建立新的 UI Component。

Code Review

最後檢查 AI 產生的 Code：

• 是否重複建立 Component？
• 是否增加不必要的 Composable？
• Boundary 是否有明確責任？
• 是否破壞既有 Architecture？

這三個環節分別處理規則、選項、驗證。

Cost 也要進入同一個 Loop

Architecture 決定 Boundary，Boundary 又會影響 Framework 需要處理的 Work，所以效能問題不能只停在這版 Vue 變快了。

需要繼續追：

Cost
 ↓
哪個 Layer？
 ↓
Framework Runtime？
JavaScript？
DOM？
Layout？
Paint？
 ↓
哪個 Boundary 造成？
 ↓
這個 Boundary 是否必要？

前面的 Vapor 實驗就是一個實際例子，當 Framework Runtime Cost 大幅下降，剩餘的 Browser Rendering、Layout、Paint 就更容易被看見。

成本下降之後，下一個問題通常是：還有多少 Work 根本不需要存在？

30 天最後收斂成 Engineering Loop

把前面的實驗與 AI Coding 放在一起，可以得到完整流程：

這個 Loop 中，每一層都有明確問題：

所以 AI Coding 時代的工程流程可以簡化成：

Generate
   ↓
Review
   ↓
Measure
   ↓
Validate
   ↓
Decide
   ↓
Evolve

AI 負責提高 Code Production 的速度，工程師則需要持續驗證：

Architecture 放得對不對、Boundary 是否必要、Cost 落在哪裡，以及改動後的 Evidence 是否成立。

這就是這 30 天從 Framework 一路走到 Architecture，再進入 AI Coding 後，最後留下來的 Engineering Loop。