Builder.io Visual Edit 把真實網頁搬進設計畫布：畫面改好了，程式也跟著改了嗎？
Builder.io 開源 Visual Edit，讓本機網頁以真實路由進入設計畫布。本文解析視覺修改如何交回程式代理，以及手機版、跨頁流程與原始碼驗收的重點。
設計師說按鈕太擠，工程師改了間距，手機畫面卻出現另一個問題。這種來回並不一定是誰沒聽懂，而是兩邊正在看不同的東西：一邊看設計稿，另一邊看正在執行的網站。Builder.io 推出的 Visual Edit，試圖讓這段溝通直接發生在真實網頁上。它把本機執行的應用程式放進設計畫布，讓人比較頁面、調整視覺，再把修改交給程式代理寫回專案。
這項工具最值得理解的地方，是畫布和程式之間的交接。官方檔案明確說明，畫布不會自動把視覺調整寫入原始碼。使用者看好修改後，仍要請代理讀取待處理變更，產生可以檢查的程式修改。因此，它比較適合縮短介面討論與實作的距離，而不能省略程式審查與實際功能驗收。
畫布裡的頁面，來自正在執行的應用程式
Visual Edit 使用由網址承載的內嵌頁面，顯示本機應用程式的真實路由。路由就是網站用來決定顯示哪一頁、哪個狀態的位址，例如設定頁、結帳頁，或附有步驟引數的表單。官方強調，它不是把頁面複製成一份靜態網頁，再讓人在複製品上操作。
這個差異會影響討論品質。靜態截圖可以指出顏色與位置，卻很難呈現文字長度變化、資料載入、錯誤訊息和不同登入狀態。真實頁面則能讓設計討論靠近使用者實際遇到的情況。不過，頁面能呈現多少狀態，仍取決於應用程式本身是否提供可重現的網址與測試資料。
若一個流程必須先填完前三頁，第四頁才會出現，直接把第四頁網址丟進畫布可能不足以重建狀態。團隊應先準備穩定的測試帳號、範例資料或可重設的流程，再開始比較畫面。工具提供共同觀看的位置，應用程式仍要提供共同觀看的內容。
同一張畫布，適合比較跨頁流程
官方示例包含把歡迎頁、註冊步驟與完成頁並排，也可以把首頁、價格頁與設定頁放在一起。這對設計審查有實際用途：同一個主要按鈕在不同頁面是否保持一致，返回操作會不會改變位置，完成頁是否延續前面的語氣，都比較容易一次看清楚。
跨頁流程不能只挑漂亮的正常狀態。以購物結帳為例，收件資料未填完整、付款被拒絕、優惠碼失效與訂單完成，會產生不同的文字與操作。若畫布只列出順利付款的三張畫面，介面審查仍然可能漏掉使用者最需要協助的地方。
比較流程時，可以先把每張畫面的任務寫清楚。收件頁的目標是讓人完成必要資訊，付款頁的目標是確認金額與付款方式，完成頁的目標是交代後續。視覺修改應服務這些任務。把三頁都改成相同配色，並不會自動讓流程更好用。
手機與桌機，需要同時看內容變化
Visual Edit 支援指定不同視窗尺寸，將同一路由以桌機、平板或手機寬度並排。響應式設計就是網站依可用空間重新安排內容。能把這些尺寸放在同一畫布，有助於發現某個桌機修改在手機上造成的連鎖影響。
例如把主要按鈕左右留白加大，桌機看起來更舒服，手機卻可能擠掉價格資訊。把卡片標題放大，短英文名稱仍然正常，較長的中文名稱就多出一行，造成整排卡片高度不一致。這些問題通常需要同時看尺寸與真實內容，才能找出原因。
指定幾個視窗尺寸也不是完整的裝置驗證。觸控操作、螢幕鍵盤、瀏覽器工具列與字型渲染，都可能影響實際使用。畫布適合做視覺判斷，重要流程仍應在目標裝置或接近目標裝置的瀏覽環境中走一次，尤其是輸入表單與固定在底部的操作區。
Builder Visual Edit 官方發布與示範影片。此為官方展示，並非本文實測結果。 影片來源：Steve (Builder.io) 官方發布素材。
視覺修改如何交回程式代理
官方流程是先在畫布上選擇元件，例如按鈕，再調整填色或內距。內距指元件內容與邊框之間的空間。看好結果後，使用者要求程式代理取得這批視覺修改，代理才會更新應用程式原始碼，讓人檢查。
這段交接需要保留修改意圖。單純記錄某個按鈕增加了幾個畫素，可能無法說明是要改善觸控範圍、對齊其他元件，還是只改這一個頁面。若代理把區域性調整寫入共用按鈕元件，整個網站都可能改變。若它只寫入單頁，其他相同場景又可能保持舊樣式。
因此，交接時應補上範圍：這項修改適用哪些頁面、哪些尺寸、哪些狀態，是否要改共用設計值。讓代理在提交前列出受影響檔案與預期畫面，再用差異檢查確認改動，通常比只說「照畫布改」更容易驗收。
用一個註冊流程建立小規模試用
以下是流程設計範例，並非本文實測結果。假設一個服務有歡迎頁、帳號資料頁、方案選擇頁與完成頁，團隊想改善手機上主要操作不明顯的問題。試用範圍可以先限定這四頁，採用同一組測試帳號與同一個方案，避免資料差異幹擾比較。
第一輪只看問題，不急著調整。記錄使用者在哪裡需要捲動畫面、哪個按鈕與次要連結競爭、錯誤訊息是否靠近輸入欄位。接著選出一個最影響完成流程的問題，例如手機帳號頁的下一步按鈕被說明文字推到畫面底部。
第二輪才在畫布調整間距、文字層級與按鈕位置。桌機與手機一起看，確認改善沒有把另一個尺寸弄壞。這時可以同時準備長姓名、長電子郵件與錯誤提示，檢查調整是否只對短範例資料有效。
第三輪要求代理讀取修改，明確限制程式範圍。若目標只涉及帳號頁，就不應順帶重做整套元件或改動驗證邏輯。完成後重跑帳號頁與後續頁面，確認表單能提交、返回仍保留合理資料、完成頁顯示正確。畫面與功能都成立，才算這一輪結束。
審查程式時，留意共用元件與樣式來源
視覺調整背後可能有多種寫法。顏色可能來自設計變數，也可能寫死在某個元件。間距可能受父容器控制，也可能由按鈕本身決定。代理若只根據結果外觀修改，容易把原本一致的樣式系統拆散，留下幾個很難維護的特殊值。
檢查時不必要求所有人讀懂整個專案，可以先看三件事。修改是否沿用既有的樣式慣例，是否在正確的元件層級發生，是否新增了只為某張畫面服務的例外。必要時請代理解釋為何選擇這個檔案，而不是另一個共用元件。
如果一個改動會影響全站，驗收範圍也要跟著擴大。例如共用輸入欄位改了高度，登入、註冊與搜尋可能一起受影響。單頁插圖換位置，則未必需要檢查所有頁面。把檢查規模和真正的影響範圍連在一起，才能避免只看一張畫面，也避免每次小改都變成全面重測。
協作與存取，也有自己的條件
官方檔案提到，帳號支援的設計聯結器負責開啟畫布、放置畫面與交回原始碼修改。部分公開或唯讀設計可以直接檢視，但建立、儲存與分享仍需要登入。不同聊天環境對內嵌畫布與操作交接的支援可能不同，使用時應依實際介面確認。
普通瀏覽器中的畫布和支援互動元件的聊天環境，交接方式也可能不同。團隊不應假設看到同一個設計畫面，就一定能把操作直接送回同一個程式代理。若需要複製修改指示，應保留頁面位址、視窗尺寸、元件名稱與變更原因，避免只傳一張截圖。
本機頁面也可能帶有真實客戶資料。用工具做介面審查時，最好先使用必要的範例資料，確認分享物件能看哪些畫面。這不是設計工具特有的問題，而是真實應用程式被帶進協作環境後，團隊需要一起處理的存取邊界。
什麼情況下，這個工具最有幫助
對已有可執行網站、經常討論跨頁介面、又使用程式代理協助修改的團隊，Visual Edit 有機會減少描述畫面與找元件的時間。對尚未決定產品流程、只有概念草圖的團隊，先把使用者任務與資訊架構定好，往往更有價值。
判斷試用是否成功，可以記錄從指出問題到取得可驗收修改的時間、同一問題需要來回解釋的次數，以及程式修改後是否出現其他頁面的視覺回歸。這些比「畫布看起來像某個設計工具」更能反映實際效益。測量時也要把審查與返工時間算進去。
這項發布讓介面協作更接近真實應用程式，但最後的品質仍來自一條完整的交接鏈：看到真實狀態、講清修改意圖、寫入合適的位置，再確認功能與不同尺寸。團隊若能把這條鏈做短而清楚，視覺編輯才會成為可持續使用的工作方式。
把修改描述寫成可以重現的問題
一份好的畫面問題紀錄，應讓沒有參加討論的人也能重現。可以寫成：在手機寬度、帳號頁出現兩行錯誤訊息時，下一步按鈕會離開第一個畫面，使用者必須捲動才能繼續。這比「手機版不太好看」多交代了頁面、條件與影響，也讓修改後有明確的比較方式。
若有多個人同時審查，應先確定哪一份程式版本是基準。設計師看到上午的畫面，工程師使用下午更新過的元件，兩邊可能會對同一項間距得出相反結論。可以在紀錄附上版本識別與測試資料名稱，讓畫布討論和程式差異指向同一份內容。
修改完成後也要保留前後證據。重要的不是截圖數量，而是證據能否回答原來的問題。前圖顯示按鈕被推到下方，後圖顯示同樣長度的錯誤訊息下仍可操作，再搭配一次實際提交測試，就比十張不同資料的漂亮截圖更容易判斷。
遇到代理一次改了太多地方，可以要求分拆成幾個有獨立目的的變更。按鈕間距與表單驗證不必綁在同一輪，品牌色調整與導覽重排也可以分開。每一輪都能說清楚原因與回復方法，團隊才有辦法知道改善來自哪一項修改。
這種紀錄方式也有助於日後維護。如果兩個月後另一位工程師想把間距改回來，可以先看到當時要解決的錯誤狀態，判斷問題是否仍存在。工具把操作變快，留下修改理由則讓速度不至於換成下一次返工。
