[讀者回函]當 AI 可以原子級逆向拆解整個 APP UI，UI/UX 設計師的定位將如何變革？
When AI Can Atomize the UI, What’s Left for UI/UX Designers?
最近有讀者問我：
「現在 AI 可以在 IDE 裡直接生出畫面、改版面、甚至重建整個 App 介面，設計師以後是不是只要看 AI 畫完的稿就好？」
這個問題我剛好卡在第一線同時在用 Pencil（長在 IDE 裡的設計檔）和 Paper.design（讓 AI 幫你操作視窗的 UI 工具）。 這篇就用實際體驗來談：當 AI 可以原子級地拆解、重組 UI，Pencil 和 Paper 代表了兩條很不一樣的路，也剛好說明了「人類還要做什麼」。
AI Agent 住在哪裡，決定了用戶體驗的深度。 下圖把 AI 代理的駐留形式分成四種：從「嵌入式」（如 Word 裡的 Copilot）到「對話式」（如 Claude App）、再到「代理式」（獲系統授權、可寫檔案與執行程式，如 Claude Code、OpenClaw），最後是「環境感知」（整合於硬體、無所不在如 Apple Intelligence）。
Pencil 和 Paper 所處的，正是代理式 AI（Agentic UX）這一帶—AI 不再只是被動回應，而是能主動操作畫布與檔案；隨之而來的挑戰，就是如何保持可解釋性與可中斷性。
Pencil：在 IDE 裡長出來的設計檔，Git‑friendly 的 code‑first UX
在 Pencil 的世界裡，設計檔跟程式碼是同一等級的公民。
.pen 檔：可以 diff 的設計
Pencil 的 .pen 檔本質上是 JSON，可以在 IDE 裡直接建立 something.pen，存放在跟 .tsx、.css 同一個專案資料夾。 這代表你可以用 Git 管理設計：branch、PR、code review，全部都適用在設計稿上，連 diff 都是可讀的 JSON 變更。
在官方的設計↔程式說明裡，他們直接把 Pencil 定位成「讓設計和 code 雙向同步的橋樑」，可以從 .pen 匯出 React/Tailwind，也可以從現有 code 反推回設計檔。
用 MCP / Skill 把 AI 變成「設計編譯器」
真正好玩的地方，是 Pencil 把這個 .pen 檔變成 AI 的寫入目標。
你可以在 Cursor 或其他支援 MCP 的 IDE 裡開一個空白 @designer.pen，呼叫像 ui‑ux‑pro‑max 這種 Skill，直接下指令：
「/ui‑ux‑pro‑max 幫我產一個 SaaS 儀表板，寫進 @designer.pen」
AI 會一次把整個畫面結構寫成 JSON 丟進 .pen，畫布同步長出完整 UI。 再配合 Ralph Loop 這種 loop agent，可以把現成的 Web App 逐頁爬過、解析 DOM，然後一頁一頁重建成 .pen 設計稿，這在 Pencil 社群已經是標準 workflow：
「既有 UI → Ralph Loop → .pen 設計檔 → 再設計／重構」。
Ralph Loop 最能發揮價值的場景是遺留系統現代化（Legacy Modernization）—例如把 10 年前的舊版網頁快速轉化為現代 React 組件的結構圖，而不是從零產出新產品。
設計資產如何流轉？ 下圖描繪的是以 UX Dataset Repository（GitHub repo） 為核心的 DesignOps 工作流：Gen-AI 生成概念原型並可試整合到 Figma；設計師在 Figma 協作，設計透過「Extract JSON / Import via MCP」進入 repo，與 UX 文案、設計規範、設計系統一起被版控；工程師從 repo clone，在整合了 Pencil.dev 的 Cursor IDE 裡直接「HTML to design」、把程式碼轉回可視設計。
也就是說，.pen 與 MCP 的角色，正是讓設計以程式碼／結構化數據的形式，在 Figma、GitHub、Cursor 之間雙向流動。
實際體感：像在 Figma 裡畫，但 commit 的是 JSON
從使用者角度，Pencil 的畫面長得很接近 Figma：
左邊是圖層、右邊是屬性條、支援自動 layout、component 等等，學習成本幾乎是零。 差別在於：
你不需要在瀏覽器和 IDE 之間來回切換，所有設計都長在同一個 repo 裡。
每一次改動都是一次 Git 變更，可以走完整的 code review 流程，設計決策被納進 CI/CD 管線。
.pen 讓設計師終於能參與原子級的復盤：可以追蹤某個按鈕的顏色變更到底是哪一個 Sprint、由誰（或哪個 AI Skill）決定修改的。
對我這類「會寫 code 的設計師」來說，這種「在 IDE 裡畫圖」的感覺非常快樂—就像終於可以用同一套工具管理 UI、邏輯和狀態。
Pencil 社群的辯論：解放還是技術債？
「JSON 膨脹（JSON Bloat）」的擔憂：當 AI 用 Ralph Loop 快速重建既有 UI 並產出數萬行的 .pen JSON 時，人類設計師真的有能力進行 Code Review 嗎？有人自嘲：「以前是改圖改到死，現在是看 AI 產的 JSON 看到眼瞎。」
另一個陷阱是設計系統的硬編碼危機：如果 AI 產出 .pen 時沒有對齊團隊內部的 Design System Tokens，這些自動生成的畫面會變成難以重用的「原子垃圾」。
此外，UX 社群中仍有大量專業者認為 IDE 環境（Cursor、VS Code）限制了視覺感官的直覺—這種「工程師治國」的工具鏈，是否會扼殺 UI 的藝術性？對「會寫 code 的設計師」是天堂，對純視覺導向的設計師可能是排斥感。
Paper.design：AI 變成會用工具的「UI 操作員」
如果說 Pencil 把設計變成 JSON 檔案，Paper.design 做的是相反的一件事：它把 AI 丟進你正在用的 UI 工具裡。
不是寫檔案，而是操作視窗
Paper.design 的定位，是讓 AI 能夠操作你當前的視窗：
包括 Paper 自己的畫布、瀏覽器裡的頁面，甚至是像 Figma 那樣的介面。 AI 不再只是吐出一段 code，而是用 MCP APIs 去建立 frame、拉出元件、改 CSS、截圖，再把結果回傳給你。
介面本身長得很像 Figma：中間是畫布，左邊是圖層、右邊是屬性，只是底層跑的是真實 HTML/CSS。 paper 官方說明很直接：flexbox、gap、border‑radius 這些行為，就是跟瀏覽器一致—因為根本就是在跑瀏覽器。
檔案不在你的 repo 裡，而是在 Paper 雲端
關鍵差異在檔案管理：
Paper 的設計稿不是 .pen 那種純文字檔，而是存放在 Paper 自己的專案／雲端系統，不會自動出現在你的 Git repo 裡，也不能用 Git 直接 diff 設計變化。 你要把結果帶回專案時，通常是匯出 code、資產或截圖，再手動整合。
定價上，Paper 的 Free 方案每週有 100 次 MCP tool calls，Pro 方案則是每月 20 美元，給你每週 100 萬次呼叫，對於頻繁透過 AI 操作畫面的工作流來說，免費額度很容易用完。
Paper 的反思：高擬真的「幻覺陷阱」
UX 專家提出了「功能性斷層」的警告：Paper 生成的 UI 看起來 100% 像成品，甚至有 CSS 動畫，但底層的狀態管理（State Management）往往是空的。這會導致 stakeholder 在 demo 時產生錯覺，認為產品已經快做完了，實際上後端邏輯與資料流完全沒接上—金玉其外。
成本與效率的拉鋸也值得算一算：與其花 20 美金買百萬次 tool calls 讓 AI 慢慢「拉」UI，對於熟練的前端來說，直接寫 Tailwind 可能還更快且更精確。
實際體感：Pencil vs. Paper，我怎麼選？
把抽象的 feature 拿掉，回到操作感受，大致可以這樣整理：
1. 寫入速度：Paper 通常更快一點
在 Pencil 裡，AI 需要理解 .pen 的 JSON schema，知道怎麼組成 frame、layout、component 再寫入檔案。
在 Paper 裡，AI 直接用 HTML/CSS 操作真實畫面—這是 LLM 天然熟悉的語言，不需要額外學一套 schema，所以「第一次就生出可用畫面」的成功率通常更高。
2. 佈局精準度：Paper 靠瀏覽器吃香
因為 Paper 本質上就是 Web 渲染，你看到的 flex 行為、gap、padding、border‑radius 就是瀏覽器會發生的事，對 pixel‑perfect 或「我要看實際跑版」的情境非常可靠。 Pencil 的畫面也很接近實際產品，但終究是一層抽象，最後還是要轉成特定技術棧（React、Tailwind…）。
3. 視覺與截圖：Paper 更接近「成品 demo」
在 Paper 裡截圖，本質上是 Web App 的截圖，顏色、排版、動態效果都跟上線後差不多，所以很適合拿去做 usability test 或 stakeholder demo。 Pencil 的視覺也不差，但更偏向「設計工具的畫布」，強項在結構和設計↔code 同步，不在於高擬真的動態展示。
4. 檔案與版本控管：這是 Pencil 的主場
Pencil 可以在 IDE 裡直接 new *.pen，指定完整路徑、放進 monorepo、配 CI pipeline，整個流程都跟一般程式碼一樣自然。
Paper 則是「你先在 Paper 建專案，再讓 AI 進來」，中間多了一層 SaaS 的隔離，改版紀錄掌握在 Paper 平台，而不是你的 Git 歷史。
如果你的目標是「讓 AI 參與產品 UI 的日常開發，並且留下可審查的變更記錄」，Pencil 的模型會比較符合 code‑first 團隊的期待；如果你要的是「快速做出非常接近成品的畫面，用來討論或測試」，Paper 的體驗會更順手。
上週我用 Paper 快速產出 3 個 layout 給 stakeholder 選，確定方向後再用 Pencil 固化成 .pen 納入 repo。過程中 Paper 的免費額度用完，得在「手動匯出」和「付費升級」之間做選擇—這類取捨，就是設計師要提前想清楚的。
放回更大的脈絡：這兩種路線，跟其他 Gen‑AI UX 工具有何不同？
Pencil 和 Paper 其實代表的是「開發者導向」和「畫布導向」兩種極端。
如果把現在常見的 Gen‑AI UX tools 放在一張圖上，大概會長這樣：
工具定位與優勢一覽
So What：solo 設計師、要快速出 demo → Paper；code‑first 團隊、要納入 CI → Pencil；已經在 Figma 生態 → Figma Make 優先。若用輸入方式來分：Prompt to UI（一句需求生多螢幕）有 UX Pilot；Screenshot to UI（草圖／截圖→原型）有 Uizard、Paper；Reference to UI（既有 code／repo 為本）有 Pencil、Ralph Loop—三類大概就齊了。
從這張表來看：
Pencil 靠近「開發者」那一端：跟 Cursor、Claude Code 等開發工具整合，把 UI 視為可 refactor 的程式碼資產。
Paper 比較像是「高擬真 prototyping / 前端沙盒」，和 Framer AI、V0 在「實際 DOM 渲染」這點上有一點重疊，但它特別強調 AI 操作畫布而不是只生成 code。
Figma Make、Galileo、Uizard 則都待在「設計畫布」這一側，差別在是否綁定 design system（Figma Make）、產出保真度（Galileo）與速度／易用性（Uizard）。
UX Pilot：一句需求 → 多螢幕 flow → Figma／交付前端
UX Pilot 最典型的實戰場景，就是「一句需求 → 多螢幕 user flow → 匯出到 Figma／交付前端」，剛好補齊 Prompt to UI 這一塊。
實戰一：10 分鐘做完新創 Landing + App Flow。 在 UX Pilot 輸入一句需求（例如「AI SaaS dashboard for a startup」），AI 會自動生出登入、列表、商品頁、結帳等一整條 user flow 的多個畫面（autoflow）；選 Web 或 Mobile，生成對應版型與元件，設計師用側邊欄微調排版與 copy。UX Pilot 會同時建立互動（按鈕連到對應畫面、hover、過場），最後一鍵匯出到 Figma，保留 frame、autolayout、元件階層。
這很適合「Gen‑AI → UX Repo → Figma → Engineer」早期 conceptual prototype 節點：先用 UX Pilot 把大方向 user flow 長出來，再落回 repo／設計系統。
實戰二：Figma 內用 Plugin 做 wireframe → high‑fi → review。 在 Figma 開 frame，啟動「UX Pilot AI: UI Design & Wireframes」plugin，輸入簡短 prompt（例如「SaaS billing settings page」），AI 直接在該 frame 生成 wireframe；再下第二個 prompt 把 wireframe 提升成高保真 UI。
若有自己的 design system，可先匯入元件，UX Pilot 會以你的元件為 building blocks 生成畫面。接著用「Design Review」依 Nielsen 十大啟發式或自訂規則請 AI 做可用性檢查，變成自動 heuristic review。
這條路線的 single source of truth 還是 Figma file 本身，UX Pilot 當 design‑time 加速器。
實戰三：Idea → Design System → Prototype → Code 一條龍。 在 UX Pilot Web App 輸入產品簡介（例如 B2B SaaS、健康管理 App），AI 先產出 IA／sitemap 與 user flow 圖；用「Generate App Flow」建出整個 App 關鍵畫面（登入、列表、詳情、設定），每頁可編輯。
用 Global Edit 調整品牌色、角圓、typography，會自動更新整個 flow，等於快速生成一套 mini design system；再生成互動 prototype、一鍵匯出 Figma 或前端 code（HTML/CSS/React）。
這種整合式工作流已經觸碰到「設計 → production‑ready code」的 handoff，接近第二張圖裡「對話式／代理式 AI」那一段——AI 不只畫畫面，而是在幫你設計 flow、生成設計系統、出 code。
放回「AI Agent 住在哪裡」的光譜：UX Pilot 今天多半還是嵌入式／對話式 AI，作為 Figma plugin 和 Web App 住在應用層，屬於 Gen‑AI + Figma 區塊，靠匯出接上工程。但 autoflow、design‑review、code export 這些功能，已經讓它長出輕量代理的味道——可以自動生成 user flow、做啟發式檢查、產生可交付 code，對應工作流裡「Gen‑AI / UX Repo / Figma」區到 Cursor IDE 前的那一塊。
Pencil .pen vs. Uizard 輸出：核心差異一覽
若要比得更細，Pencil 和 Uizard 的差異不只在「哪個生成比較漂亮」，而在設計成果在開發流程裡扮演什麼角色。下表對齊兩者在檔案本質、版控與 AI 寫入方式上的差別。
在 Pencil 裡，一個 @login.pen 檔其實就是一段 JSON。官方把它描述成「類似 HTML 或 SVG 的物件樹」，每個節點都有 id、type 和 layout、padding、fills 等屬性，還配好完整的 TypeScript schema。這個檔案可以直接跟 .tsx、.css 放在同一個 repo 裡，用 Git diff 出每一個像素的變動，走 branch、PR、code review——對開發者來說它就是 source code 的一種。
這讓 AI 很容易「以程式的方式」介入設計：用 MCP / Skill 寫 JSON 到 .pen，或透過 pencil‑to‑code 把 .pen 一鍵轉成 React + Tailwind component；甚至用 loop agent 掃過整個 App，把既有畫面逆向成一批 .pen 檔，變成可 refactor 的設計資產。
Uizard 走的路線完全不同。它是雲端 AI 設計工具，主打「從 prompt、草圖或截圖，一口氣生出多個畫面流」，用 Screenshot Scanner、Autodesigner、Theme builder 幫你快速調整，最後在 handoff 模式裡提供每個元件對應的 React 和 CSS 片段，讓前端 copy‑paste 實作。
但這些輸出大多是圖檔（PNG、PDF）或「元素級的 code snippet」，而不是一個可以直接進 repo 的結構化檔案。你可以把產出的 React 拿去版控，但那已經是「實作層」，而不是 UI 工具自己的原始格式；整個 Uizard 專案的版本歷程，綁在 Uizard 平台的資料庫裡，而不是你的 Git。
兩條路反映的是不同的設計哲學：對 Pencil 來說，設計檔就是程式碼，.pen 放進 repo 成為 AI 代理可以安全操作的「介面契約」，適合在 HITL 流程裡當「UX Repo ↔ Cursor IDE ↔ Engineer」的高風險節點——人可以用 PR gatekeeper 決定哪些設計變更可以進 production。
對 Uizard 來說，設計結果主要是畫面和互動體驗本身，AI 幫你從 0 生出多個版本、轉成原型，再交給人類挑與微調，用 React/CSS handoff 給工程師；在早期探索和非工程背景的團隊裡非常好用，但設計檔本身較難納入 infra 和自動化治理。
一句話區分：Pencil 的 .pen 是可被 AI 與人類共同維護的源碼，可以放進 UX Repo、走完整 Git 工作流；Uizard 的輸出則是高效率的「AI 生成稿與 code 規格」，適合把產品帶到可 demo、可開發的狀態，但不會自然變成你長期維護的設計 single source of truth。
如果你的角色是「介於設計與工程之間」，Pencil + Paper 其實可以疊在一起用：
用 Paper 快速試 layout、看真實瀏覽器行為與截圖；
確定方向後，用 Pencil 把決定好的畫面固化成 .pen 檔、納入 repo 與 Ralph Loop 工作流，變成可維護的設計資產。
原子級拆解背後的版權與倫理
當 AI 可以一鍵把對手的 Web App 拆解成 .pen 檔供你「再設計」時，「克隆」與「借鑑」的界線在法律與倫理上變得模糊。UX 社群正在討論這是否會導致全球網頁趨同化（UI Homogenization），讓網路世界變得越來越無聊。
另一個容易被忽略的是無障礙（A11y）的缺失：AI 拆解 UI 往往只拆解了「視覺原子」，卻經常丟失了「語義原子」。目前 Pencil 或 Paper 的 AI 生成結果在螢幕閱讀器兼容性上仍不穩定，這需要設計師進行二次人工審核。
{合作廣告}
🧑🎓 UX 訂閱制學習計劃：把 human-in-the-loop 變成你的日常。這也是我會特別推薦 #UX訂閱制學習計劃 的原因：它不是一次性的 bootcamp，而是把借位、補位、入位拆開來，串成 3 月到 12 月的一條學習軸線。透過每月 Podcast 和專欄，先向不同領域的 UX / 產品 / AI / 服務設計講師「借位」
透過直播與 Circle 社群討論，在你的真實案子與問題上進行「補位」
