一位前端工程師對 AI 時代新產品工程工作流程的觀察
一個看似不合理的數字
12 天。兩個人：一位產品設計師和一位前端工程師。一次完整的平台重建。
不是原型，不是 MVP，而是一個生產環境應用程式的全面替換——最終以一個刪除了 26,000 行舊程式碼的 PR 作結。每一個頁面、每一條路由、每一個互動，全部從零開始重建，並交付給真實用戶。
在任何傳統的產品開發流程中，這樣的時程都是荒謬的。這種規模的專案通常需要數個月：在 Figma 中進行數週的設計探索、多輪利害關係人審查、交接儀式、Sprint 規劃，然後才是緩慢而費力的像素級實作。這次發生的事情從根本上就不同——不是因為我們更努力，而是因為我們的協作方式改變了。
這是我們如何在 VM0 交付 Zero 平台的故事，以及它讓我對產品工程協作未來的思考。
舊有的瓶頸
每位前端工程師都熟悉傳統的流程：
- 設計師在 Figma 中建立設計稿
- 設計審查、反覆修改、確認定稿
- 附有間距、顏色、斷點的標注規格
- 工程師將視覺規格轉譯為程式碼
- 來回溝通：「可以把這個往左移 4px 嗎？」
- 最後，接上 API 層
- 整合測試，更多來回溝通
瓶頸從來不在任何單一步驟。它存在於步驟之間的空隙：等待、資訊在轉譯過程中的流失、情境切換。設計師對互動的心智模型，一旦被壓平成靜態的 Figma 畫格並加上標注，送到工程師手上時已經失真了。工程師重建的是設計師所想像的某個版本，但這不可避免地是一份有損耗的複製品。
我們已經習慣了這種摩擦，以至於不再察覺它的存在。這就是「事情本來的運作方式」。
實驗：如果設計師直接交付程式碼呢？
2026 年 3 月 5 日，我們的產品設計師 Ming 開了 PR #3685：feat(platform): add zero app with shell, pages and polish。這個 PR 新增了 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 行）。活動頁面接上了真實的日誌。最重要的是：聊天頁面連接到了實際的代理執行管線，用一個可運作的 AI 對話介面取代了約 1,200 行的示範程式碼。同一天，我引入了 FeatureSwitchKey.Zero，一個讓我們能夠同時運行新舊平台的功能旗標。
第 4-5 天（3 月 12-13 日）： 檔案附件、工作階段管理、多代理聊天、設定持久化。Ming 建立的每一個頁面現在都在做真實的工作了。
這個節奏幾乎像音樂一樣。每天早上，我從 Ming 的骨架中挑選一個頁面，研究其元件結構，確認它需要哪些資料，建立 API 整合，處理錯誤狀態，然後推送。到了下午，又一個頁面活了過來。
功能旗標：平行世界
FeatureSwitchKey.Zero 功能旗標值得單獨一提，因為它讓這次遷移是安全的，而非魯莽的。
從 3 月 11 日起，我們的生產環境應用程式同時運行兩套完整的 UI。使用舊系統的用戶看到舊路由。使用新系統的內部測試人員看到 Zero。我接線完成的每一個頁面都可以在生產環境的情境下進行測試，而不會影響任何一位用戶的工作流程。
這並不是什麼革命性的做法。功能旗標是標準實踐。但功能旗標與設計即程式碼工作流程的結合創造了一些特別的東西：我們可以驗證新平台的完整使用者體驗（因為 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 指令，以及最終將整個概念從「防火牆」重新命名為「權限」，遍及整個程式碼庫。
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 即時更新和端對端測試。隔天，它就向所有用戶開放了。
AI 在其中扮演的角色
我想精確說明 AI 在這裡的角色，因為很容易對它過度高估或低估。
AI 讓設計師能夠寫程式碼。 Ming 是一位產品設計師，不是軟體工程師。她的思維方式是版面、層次和互動，而不是 React hooks 和 TypeScript 泛型。AI 工具（Cursor，後來是 Claude Code）透過處理從設計意圖到可運行程式碼的機械性轉譯，彌合了這個差距。Ming 負責指揮，AI 負責打字。結果是由設計師撰寫、但工程師可以在其上繼續建構的程式碼。
AI 加速了審查循環。 在協作 PR 上，我的 AI 代理會審查 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 的平台——一個 AI 代理作業系統。他刪除的舊程式碼數量之多，多到他自己都不太好意思承認。
