既然我們已經知道什麼工作很貴，AI 產生的 UI 會不會讓這些工作變得更多？

前面幾天，我們一直在追 大量 UI Rendering 到底貴在哪裡？

Day 18 建立 Vue 3.5.40 Baseline，Day 19 換成 Vue 3.6.0-rc.2，Day 20 再把成本拆到 Framework Runtime 與 Browser，一路追下來，有一個結果很重要：

看到 Rendering Cost 變化時，不能直接把它歸因給 Vue。

一次 UI Update，至少會經過幾個不同層次：

State Change
     │
     ▼
Vue Runtime
Render / Diff / Patch
     │
     ▼
UI Architecture
Update Scope / Component Tree
     │
     ▼
Browser
Layout / Paint / Composite

這也解釋了為什麼 Framework 升級之後，Scenario 的總時間沒有明顯下降，並不代表整個問題沒有改善空間，因為還有一個更基本的問題：

我們到底讓系統做了多少工作？

Rendering Cost 不只跟 Component 數量有關

前面的 Component Storm 已經看過一個很容易產生誤解的情境：假設一次要渲染 500 Components，很容易直覺認為頁面一定很慢。

但真正值得觀察的是：

State Change
     │
     ▼
Update Scope
     │
 ┌───┴────────────┐
 ▼                ▼
1 Component    500 Components
 Update          Update

如果頁面有 500 個 Component，但一次 State Change 只影響其中一個，實際需要處理的工作可能很有限。

反過來，如果只有 100 個 Component，卻因為 Parent State 改變，讓大量 Children 一起進入 Update，成本反而可能更值得調查。

所以 Component Count 可以描述 Tree Size，卻不能直接代表一次 Update 的成本。

真正值得量測的是 Update Scope。

資料很多，也不代表畫面需要全部 Render

假設現在有 5,000 筆使用者資料：

const users = ref(/* 5,000 users */)

最直接的寫法可能是：

<UserCard
  v-for="user in users"
  :key="user.id"
  :user="user"
/>

但使用者的螢幕一次可能只看得到 20 張 Card，這時候真正需要問的問題就變成：這 5,000 筆資料，有多少真的需要進入目前這次 Rendering？

Virtual Scrolling、Pagination、分頁載入等策略，本質上都在處理這個問題，它們改變的是 需要進入畫面更新的資料與 DOM 範圍，這和單純把 Vue Runtime 再優化幾個百分點，是不同層次的問題。

然後問題來到 AI Coding

過去建立 UI，大致是：

需求
  ↓
工程師設計
  ↓
Component / State / UI Architecture
  ↓
Code

現在的開發流程多了一個很重要的變化：

需求
  ↓
Prompt
  ↓
 AI
  ↓
Component
State
Composable
UI Architecture
  ↓
Code

AI 已經不只是產生幾行 template，當我們要求：

• 把頁面拆成 Component
• 抽出共用 Component
• 整理 State
• 重構 Composable
• 建立可重用的 List
• 優化整個頁面結構

AI 實際上已經參與了 UI Architecture 的形成。

於是前面幾天研究的 Rendering Cost，會出現一個新的問題：如果 Architecture 會影響 Rendering Work，那 AI 產生的 Architecture 也可能影響 Rendering Work 嗎？

這裡先停一下。

目前沒有足夠的實驗結果，可以直接下結論說 AI 會產生 Rendering Anti-pattern，所以 Day 21 要驗證的不是「AI 寫得好不好」。

真正值得驗證的是：

AI 產生的 UI 結構，是否可能讓一次 State Change 觸發超出需求的 Rendering Work？

最麻煩的情況，是 Code 完全沒有錯

例如 AI 產生了一個 List：

<UserList
  :users="users"
  :selected-id="selectedId"
/>

Code 可能同時滿足：

✓ TypeScript 通過
✓ Build 通過
✓ Test 通過
✓ UI 正常
✓ Component 結構清楚

但如果：

Click one item
      ↓
Parent State Change
      ↓
Large Component Tree Update
      ↓
Only one DOM node actually changes

那問題就出現了，程式的功能結果正確，Runtime 執行的工作量卻可能高於需求。

這種問題很難靠 Compiler Error、Type Check 或一般 Unit Test 發現，因為它測的是：

Code Correctness
        ↓
Runtime Behavior
        ↓
Rendering Work

而這三件事情並不完全相同。

所以 Code Review 還需要多看一層

傳統 Code Review 常見的問題：

這段 Code 對不對？
這個 Component 好不好維護？
有沒有重複？
State 放的位置合理嗎？

面對 AI 產生的 UI，還可以增加幾個 Runtime 問題：

例如：

一次 State Change 會觸發哪些 Component？

Update Scope 有多大？

這次 Render 實際產生多少工作？

最後真的改了多少 DOM？

例如看到：

const selectedId = ref(null)

function select(id) {
  selectedId.value = id
}

Code 本身沒有什麼問題，真正值得追的是 Runtime-aware Code Review，因為它關心的不只是 Code 長什麼樣子，也關心這段 Code 會要求 Runtime 做什麼。

selectedId 改變
      ↓
誰依賴它？
      ↓
哪些 Component 重新 Update？
      ↓
哪些 Render Work 真的有必要？
      ↓
最後哪些 DOM 發生變化？

回頭看 VDOM Stress Test

這幾天其實可以把問題濃縮成一條線：

Framework
    ↓
Architecture
    ↓
Rendering Work
    ↓
哪些工作真的需要做？

Day 18~20，我們花時間確認：

• Rendering Cost 分布在哪裡
• Framework Runtime 是否真的改善
• Browser Cost 剩下多少
• Component Tree 與 Update Scope 如何影響工作量

到了 Day 21，問題再往前推一步：

如果我們可以決定 Architecture
        ↓
就可以決定 Update Scope
        ↓
也就可能決定 Runtime 需要做多少工作

而 AI 開始參與 Architecture 之後，這個決策來源也發生了變化，因此接下來值得驗證的問題就很具體：

AI 產生的 Component、State 與 Composable 結構，會不會在功能正確的情況下，產生可以避免的 Runtime Work？

這一次，問題就不能只看 UI 長什麼樣子，得開始追它 實際跑了多少東西。