Harbor：設計稿免工程投入，直接編譯成互動原型
Stripe Dev Blog · 2026-09-14
Stripe 內部原型工具 Harbor，把「只能看的靜態設計稿」和「要工程師另外投入的完整原型」合併成一條新路：設計師直接在瀏覽器裡用 AI 把設計稿變成能點擊、能分享的互動原型，不必等工程資源。打造它的是 Stripe Web Presence and Platform 團隊的工程師 Cristian Rivera，他花約 40 天做出第一版，起初只是想驗證 AI 能不能省下等工程原型的時間。
原本的問題
stripe.com 團隊改版時，經常需要更多資訊才能判斷一個新設計構想是否可行，但不是每個構想都值得投入開發一個完整的工程原型去驗證。靜態設計稿說明不了互動細節、動畫效果，或使用者點擊後會發生什麼；工程原型的成本又高到只有少數重要構想才排得上工程資源。這個落差留下一大段沒人做的空白地帶——很多構想因此卡在簡報裡，沒被真正操作過就被擱置或否決。
採用的方法
Harbor 的介面是一個瀏覽器分頁，左邊是原型，右邊是聊天面板。作者先選一套設計系統（決定套件與起始檔案），再描述想要什麼。流程分成四步：
- agent 寫出一份多檔案的原始碼樹（multi-file source tree）
- Harbor 的渲染引擎 Drydock 直接在瀏覽器裡編譯這份原始碼並回傳一個正在執行的頁面，連同一份記錄編譯與執行期間失敗的報告
- agent 讀取渲染後的頁面、列出並檢查元素、點擊、輸入、捲動、把畫面切成 mobile／tablet／desktop 三種尺寸，還能截圖
- 準備好後，作者把原型發布到一個可分享的網址；同一時間只有一個已發布版本，每個瀏覽者打開時都是自己的瀏覽器重新編譯一次
使用的人變多之後，大家開始想在原型上留言，但頁面會被 agent 一直重寫，留言要怎麼知道自己還釘在原本討論的東西上。Harbor 的做法是同時記錄好幾種訊號：語意標籤、穩定識別碼、留言當下的文字內容、結構路徑、清單裡的 key，以及要不要先打開對話框或折疊區塊才能看到這個元素，還記下每種訊號在留言當下是不是唯一的。agent 重寫過原型後，Harbor 不會把留言偷偷挪到「看起來很像」的新元素上，而是回報這則留言是「仍連結著（attached）」「需要人確認（needs review）」，還是「已找不到對應元素（orphaned）」。留言也綁定發布當下的版本，換版後舊留言會被標成過期，提醒審閱者這是對應哪一版的意見。
Harbor 後來接上了 Stripe 內部其他的 AI 工具，靠的是兩個架構決定。第一，把 Harbor 的功能透過內部 Model Context Protocol（MCP）伺服器開放出去，其他 agent 不必請人手動複製上下文到新對話，就能建立、讀取、更新、發布一個原型；跑在 devbox 上的 coding agent 也用同一組工具，把 Harbor 原型的檔案樹拉進正式程式碼庫。第二，把 Drydock 獨立成一個介面很小的服務：輸入一份 React 加 TypeScript 的多檔案原始碼樹，回傳一個在瀏覽器裡執行的頁面，加上失敗報告。因為介面不依賴 Harbor 其他部分，內部其他工具也能直接拿去用——例如知識工作 AI 平台 Kai，就用它讓使用者把分析結果變成可點擊的原型。
實際效果
Harbor 自 2026 年 5 月開始使用至今，已有 3,000+ 位 Stripe 員工做出超過 12,000 個原型，佔全公司 25% 的員工至少做過一個原型。在最早使用 Harbor 的專案之一裡，一位設計師做出了一個新的產品頁面，包含一段動畫化的主視覺；工程師、產品經理和主管都能即時操作這個原型，很快就對設計達成共識。等頁面真正上線時，那段動畫幾乎一比一從原型搬進了正式頁面。
| 原本 | 現在（Harbor） |
|---|---|
| 評估新設計構想，只有靜態設計稿可看，看不出互動與動畫細節 | 設計師在瀏覽器裡用 AI 直接生成可點擊、可操作的原型 |
| 要看到真正動起來的效果，得另外找工程師投入開發一個完整原型 | agent 寫出多檔案原始碼，Drydock 直接在瀏覽器編譯執行，不必架服務端 |
| 對原型的意見多半留在會議或簡報裡，原型改版後很難對應回原本討論的東西 | 留言錨定在畫面元素上，原型被重寫後仍回報「連結中／需確認／已遺失」 |
| 原型做完之後，動畫等效果要重新手刻進正式頁面 | 案例中的主視覺動畫，幾乎一比一從原型搬進了正式上線頁面 |
採用範圍後來超出了設計團隊原本設定的邊界：財務團隊把每月實際數字和業務檢討做成可點擊的原型，取代投影片；一位風控分析師把處理時間分析做成團隊能自行檢視的儀表板；業務團隊替特定客戶做出報價方案、battlecard 和 ROI 試算工具，這些都不是 Harbor 原本設定的場景。
對想做類似工具鏈的團隊來說，Stripe 這次踩到的重點不是 AI 生成程式碼本身，而是留言怎麼在畫面不斷被重寫的情況下，還講得出「這則意見現在對應到哪裡」——只把留言挪到最相似的新元素上，審閱者會在不知情下看錯版本。另一個重點是把渲染引擎獨立成一個介面很小的服務，不綁死在 Harbor 內部，這也是它後來能被其他 AI 工具直接複用的原因。
原始來源：Stripe Dev Blog：Harbor: Stripe's AI-assisted prototyping tool