一名前端工程師對 AI 時代新產品工程工作流程的看法
一個不合理的數字
12天。兩個人：一位產品設計師與一名前端工程師。一個完整的平台重建。
不是原型。不是 MVP。是生產環境應用的完整替換，最終以一個 PR 刪除了26,000行舊有程式碼。每個頁面、每條路由、每個互動，全都從零開始重建並交付給真實用戶。
在任何傳統產品開發工作流程中，這個時程都荒謬至極。這樣規模的專案通常需要數月：在 Figma 進行數週的設計探索、多輪利害關係人審查、交接儀式、衝刺規劃，然後是像磨坊一樣緩慢的像素級實作。而這次發生的事，根本不同。不是因為我們更努力，而是我們合作的方式徹底改變了。
這就是我們如何在 VM0 推出 Zero 平台的故事，以及它讓我對產品工程協作未來的啟發。
舊有瓶頸
每位前端工程師都熟悉傳統流程：
- 設計師在 Figma 製作模型
- 設計審查、反覆修正、最終確認
- 標註規格，包括間距、顏色、斷點
- 工程師將視覺規格轉換為程式碼
- 來回溝通：「這個可以往左移 4px 嗎？」
- 最後串接 API 層
- 整合測試，再來回修正
瓶頸從來不在單一環節，而是在每個步驟之間的縫隙：等待、資訊流失、情境切換。設計師對互動的心智模型，一旦被壓平成靜態 Figma 畫面並加上紅線標註，送到工程師手上時已經失真。工程師重建出設計師想像的版本，但終究是有損的拷貝。
我們早已習慣這種摩擦，甚至不再察覺。這只是「事情的運作方式」。
實驗：如果設計師直接交付程式碼？
在 2026 年 3 月 5 日，Ming，我們的產品設計師，開了 PR #3685：feat(platform): add zero app with shell, pages and polish。它新增了4,146行可運作的 React 程式碼。
不是 Figma 檔案。不是設計 token 匯出。而是一個可執行的應用程式。
這個 PR 包含完整的應用殼：側邊欄導覽、路由結構、聊天、排程、活動、團隊管理與設定等頁面骨架，全都用我們的設計系統設計，並能在瀏覽器中渲染。資料雖然是模擬的，但 UI 是實際可用的。你可以npm run dev，點擊瀏覽每個頁面。
Ming 並不是用傳統方式從零寫這些程式碼。她運用 AI 編碼工具（先是 Cursor，後來是 Claude Code）將她的設計理念直接轉譯為 React 元件。AI 處理機械式的轉換（JSX 結構、CSS 屬性、元件組合），而 Ming 則主導那些 AI 無法決定的視覺與互動細節：版面節奏、資訊層級、轉場感受。
接下來四天，又有三個 PR 合併：
| 日期 | PR | Ming 交付內容 |
|---|---|---|
| 3 月 5 | #3685 | 應用殼、側邊欄、所有頁面骨架（+4,146 行） |
| 3 月 6 | #3825 | 排程頁面、UI 微調（+2,650 行） |
| 3 月 9 | #3993 | 新手引導流程、Slack 設定對話框（+1,146 行） |
| 3 月 9 | #4050 | 關於頁面、浮動導覽卡 |
到 3 月9日，我們新平台的整個前端界面都已經是可執行的程式碼。你日後在生產環境看到的每個頁面，都已能在開發環境中點擊瀏覽。只是還沒連接真實資料。
這時輪到我登場。
我的新工作：注入靈魂
當我在 3 月9日打開程式碼庫時，面對的不是將平面設計轉成程式碼的老問題。程式碼已經在那裡了。我的工作是將每個模擬資料換成真實資料，把每個精心設計的界面連接到活生生的後端。
這徹底改變了我的工作方式。我不再思考像素，而是思考資料流。不再問「這有沒有跟設計稿一樣？」，而是問「這頁需要呼叫什麼 API？失敗時該怎麼處理？」
這是我第一週的工作內容：
第1天（3 月9日）： 認證與組織切換。我將 Ming 的殼接上 Clerk 認證，新增跨網域導向，讓組織切換器真的能切換組織。兩個 PR，當天合併。
第2天（3 月10日）： 連接器與排程。我用真實 API 資料取代模擬連接器網格，把排程分頁串接到實際的 cron 任務，並將指令編輯器連到後端。四個 PR。
第3天（3 月11日）： 大串接日。團隊頁面接上真實子智能體資料（+3,271 行）。活動頁面接上真實日誌。重頭戲：聊天頁面串接到實際智能體執行管線，將約1,200行展示程式碼換成可用的 AI 對話介面。同一天，我引入了FeatureSwitchKey.Zero，一個讓新舊平台可並行運作的功能旗標。
第4-5天（3 月12-13日）： 檔案附件、工作階段管理、多智能體聊天、設定持久化。Ming 建好的每個頁面，現在都能做實事了。
這節奏幾乎像音樂。每天早上我挑一個 Ming 的骨架頁，研究元件結構，找出所需資料，建 API 串接，處理錯誤狀態，然後推送。到下午，又有一頁活了過來。
功能切換：平行世界
FeatureSwitchKey.Zero功能旗標值得特別一提，因為它讓這次遷移安全而非魯莽。
從 3 月11日開始，我們的生產應用同時運行兩套完整 UI。舊系統用戶看到舊路由，內部測試者則看到 Zero。我串接的每個頁面都能在生產情境下測試，不會影響任何用戶的工作流程。
這並不革命性。功能旗標是業界標準。但功能旗標結合設計即程式碼的工作流程，產生了特別的效果：我們能驗證新平台的完整 UX（因為 Ming 已經建好可瀏覽的 UI），同時逐頁讓功能上線（因為我逐一串接）。任何時刻，只要出問題，都能隨時切回。
結果什麼問題都沒發生。
第12天：大切換
3 月17日，我開了 PR #5095：refactor: remove all non-zero platform pages and feature flag。
差異：+456 行，-26,041 行。
之前：舊 VM0 平台。表格、執行 ID、原始工作階段資料。
之後：全新 Zero。對話式 AI 工作區，支援釘選智能體與用例卡片。
一次合併，所有舊路由全數刪除。功能旗標移除。Zero 不再是選項，而是唯一模式。後續 PR（#5155）更直接移除了/zero URL 前綴：原本的/zero/chat，現在只剩/chat。
我為什麼敢這麼果斷？因為：
- 每個頁面都已在功能旗標下運行至少5天
- 每個 API 串接都用生產資料測試過
- 新舊系統共用同一後端。這只是前端切換，不是資料遷移
- 新系統已有真實用戶持續回饋
那26,000行程式碼不是帶著焦慮刪除，而是帶著如釋重負。
模式重複出現
最讓我驚訝的不是這次遷移本身，而是我們發現的這種工作流程，成了後續每個新功能的預設模式。Ming 用 AI 協助建 UI 殼，我負責串接邏輯、擴展架構。同樣的設計即程式碼模式，應用在功能層級：
權限系統（3 月19日 → 4 月7日）
Ming 交付了 PR #5467，一個帶有 Sheet 元件與切換控制的權限抽屜 UI。三次提交，UI 乾淨俐落。
我在同一 PR 上加了13次提交：firewall_access_requests的資料庫遷移、API 端點、整合測試、lint 修正。接下來兩週，10+個後續 PR 完善了整個權限層：審核卡片重設計、存取請求的 Slack 通知、權限診斷 CLI doctor 指令，最後還將整個概念從「firewall」全面改名為「permission」。
Ming 的抽屜是種子，權限系統是大樹。
排程系統（3 月23日 → 4 月13日）
Ming 設計了排程詳情路由與行事曆 UX（#6155）。三次提交，UI 乾淨。
我加了14次提交：描述編輯與自動產生、Slack 頻道通知選擇、未儲存變更確認對話框、行事曆/清單檢視統一、完整測試。然後15+個後續 PR，擴展成完整的定期任務系統，支援執行歷史、時區處理、cron 表達式。
Telegram 整合（4 月27日 → 4 月28日）
到這時，這個模式已經如此純熟，我們在48小時內交付了整個平台整合。Ming 建好設定 UI（#11196）與新手引導流程（#11399）。我負責多機器人 API、訊息收發、檔案上傳/下載、豐富訊息上下文、Ably 即時更新、E2E 測試。隔天，所有用戶都能用。
AI 的角色
我想精確說明 AI 的角色，因為很容易被高估或低估。
AI 讓設計師能寫程式碼。 Ming 是產品設計師，不是軟體工程師。她思考的是版面、層級、互動，而不是 React hooks 或 TypeScript 泛型。AI 工具（Cursor、Claude Code）彌補了設計意圖到可運作程式碼的機械轉譯。Ming 主導，AI 輸入。結果是設計師寫的程式碼，工程師能直接擴展。
AI 加速了審查迴圈。 在協作 PR 上，我的智能體會審查 Ming 的程式碼，依優先級（P0/P1/P2）分類問題，並直接推送修正。PR #5060 五輪審查僅38分鐘完成。PR #5467三輪審查僅20分鐘。這不是「AI 取代程式碼審查」。我仍親自檢查每個變更。但 lint、型別、測試缺漏等機械工作都自動化了。
AI 並未做設計決策。 每頁的資訊架構、互動模式、視覺層級，來自 Ming 的產品直覺、用戶研究與領域專業。AI 能產生設定頁，但無法決定該用切換還是下拉選單，或該用確認對話框還是簡化流程。
AI 並未做架構決策。 是否用功能旗標平行部署、API 層分離策略、逐頁串接而非一次到位，這些都是工程判斷。AI 幫我寫程式碼更快，但流程安排與風險控管還是人來決定。
誠實的總結：AI 消除了設計與工程間的轉譯層。它沒取代任何一方，而是移除了兩者之間的鴻溝。
我的角色有何改變
經過三個月這樣的工作流程，我對前端工程師的角色有了新看法。
我不再是視覺轉譯者。 收到 Figma 檔、花數小時對齊間距的日子結束了。不是因為我變快，而是這已不是我的工作。設計師的意圖直接以程式碼呈現，而不是程式碼的圖片。
我是架構擴展者。 我的主要價值在於將可運作的 UI 表面，建構其下看不見的基礎設施：API 串接、資料驗證、錯誤處理、權限檢查、即時更新、測試。大多數協作 PR 的提交比例說明了一切。Ming 貢獻3次 UI 提交，我則貢獻13次其他內容。
我是品質守門人。 有 AI 協助的審查迴圈，我能維持更大範圍的程式碼品質。自動審查抓出機械問題；我專注於架構、邊界情境，以及確保功能端到端可用。
我是交付策略師。 功能旗標、漸進串接、平行部署：如何讓功能從程式碼到生產環境，現在是我工作的核心，而非事後補救。
數字
三個月。兩個人。全程有 AI 協助。
- 914 個合併 PR（我679個，Ming 235個）
- 12天，從第一個骨架到整個平台替換
- 48小時，完成 Telegram 整合（我們最快的功能）
- 26,000行，一次合併自信刪除
- 88% 我的 PR 與 66% Ming 的 PR 有 AI 共同作者
這些不是拼命指標。我們沒加班、沒熬夜。速度來自於消除無效時間：交接會議、規格誤解、「這個能不能再移 4px」的來回。當設計意圖直接進入程式碼，工程師在原地擴展，浪費自然減少。
這對團隊意味著什麼
我不認為每個團隊都該這樣工作。這種流程來自我們的特殊情境：小團隊、綠地重建機會、以及早期取得強大 AI 編碼工具。你的情況可能不同。
但我相信底層的轉變是普遍的：設計與工程的界線正在消融，而 AI 是溶劑。 隨著 AI 工具越來越能將意圖轉成程式碼，更多設計師會直接交付程式碼。屆時，工程師花在轉譯的時間會減少，更多精力投入架構、品質與交付。
前端工程師的工作不會消失，只是型態改變。說真的？新型態更有趣。
Yuma 是 VM0 的前端工程師，負責打造支援 Zero 的平台——一套智能體作業系統。他刪除過的舊程式碼比他願意承認的還多。
