Vibe Coding：用 AI 取代價值 2 萬美元的企業級物流平台

對於許多新創公司而言，「自建」還是「購買」是一個根本性的戰略抉擇。傳統上，「購買」選項——即選擇企業級 SaaS 平台——是避免撰寫 API 整合與管理複雜物流邏輯等艱鉅工作的安全做法。然而，隨著大型語言模型 (LLMs) 導致軟體開發成本大幅下降，這個數學邏輯正在改變。

TRMNL 最近在物流供應商 ShipHero 服務中斷後，發現自己正處於這個抉擇點。隨之而來的是一場「Vibe Coding」實驗：在短短幾週內，利用 Claude 驅動的自定義解決方案，取代了每年 20,000 美元的企業平台。

瓶頸期：當 SaaS 變成負擔

TRMNL 使用 ShipHero 主要執行兩項功能：管理訂單暫扣/備註以及執行出貨流程。雖然該系統曾一度運作尚可，但隨後出現了幾個摩擦點：

• 使用者體驗不佳： 完全沒有行動裝置版面，且網頁入口網站被拆分到兩個不同的網域，且缺乏良好的 SSO。
• 缺乏支援： 客戶服務單被忽視，且客戶經理缺乏回應能力。
• 關鍵故障： 他們在柏林倉庫發生了完全的服務中斷，同時伴隨著不穩定的郵資定價（同一件貨件的郵資從 12 美元跳漲至 140 美元）。

當供應商停止回覆訊息時，TRMNL 決定停止支付服務費用，並使用 AI 重建平台。

「Vibe Coding」工作流程

重建平台的過程並非要親手撰寫每一行程式碼，而是透過編排 AI 來處理設計與整合等繁重工作。

從截圖到高保真原型圖

透過使用 Claude Design，團隊將現有 ShipHero 入口網站的截圖餵給 AI。目標並非為了創新而創新，而是為了維持「慣性友好性」。因為倉庫團隊已經對舊的 UI 建立了肌肉記憶，新系統需要感覺起來很熟悉，以確保能無縫地在同一天完成切換。

值得注意的是，AI 能夠在沒有明確的「前後狀態」描述的情況下，推斷出複雜的 UX 模式——例如「點擊左側項目，移動到右側」的出貨入口網站邏輯。

解決整合的噩夢

任何物流平台的挑戰之處在於電商物流業者 (UPS, FedEx, DHL, USPS) 的 API 整合。這些整合通常涉及超過 1,000 行程式碼的 JSON 載荷，特別是在處理危險品與國際運輸時。

這正是 LLMs 提供最強大槓桿的地方。透過將這些物流業者的技術文件餵給 AI，TRMNL 避免了閱讀 FedEx 文件所帶來的繁重勞動，將原本可能耗時數月的專案轉化為快速部署。

架構與測試

為了管理實際的建置過程，團隊使用了 Claude CLI 與一個名為「Superpowers」的工具，該工具採用蘇格拉底式教學法來處理架構。該工具並非只是生成程式碼，而是透過提出澄清性問題來確定精確的需求，這對於處理多倉庫支援與外鍵管理等複雜邏輯至關重要。

為了確保穩定性，團隊高度依賴自動化測試。正如作者所提到的，「slop 是與測試程度相當的安全程度」，強調了 AI 生成的程式碼需要嚴格的測試框架來達到生產環境就緒狀態。

最終產品：自定義物流引擎

最終產出的平台不僅僅是一個複製品，它是一個針對 TRMNL 特定需求優化的量身定制工具：

• 硬體整合： 一個用於網路印表機的自定義 Swift 工具，只需點擊一下即可列印 4x6 標籤與裝箱單。

• 並行控制： 使用 WebSockets 將訂單鎖定給特定的倉庫團隊成員，以防止重複出貨。

• 訂單優化： 一個「合併訂單」介面，用於合併來自同一客戶的多筆訂單，以降低郵資成本。

• 自動化規則： 一種無伺服器風格的基礎設施，允許團隊使用 Python, Ruby, 或 Node 撰寫規則，以便根據 SKU, location, 與 Incoterms 自動分配出貨方式。

底線：SaaS 的新現實

該專案耗時約 80-100 小時的開發時間，隨後進行了一週的現場除錯。結果是一個載入速度更快、列印速度更快，且維護成本遠低於每年 2 萬美元合約的系統。

這種轉變凸顯了軟體產業中日益增長的趨勢。正如一位 Hacker News 社群成員所言：

「擁有為自己的業務建立自定義軟體的能力，是一項了不起的超能力。我認為這也會對 SaaS 公司整體造成巨大的價格壓力。」

對於企業級軟體供應商而言，教訓很明顯：當價值主張從「我們幫你省去寫程式碼的麻煩」轉轉變為「我們提供更優質的服務」時，任何依賴法律合約與高流失門檻來留住客戶的供應商，都會發現自己面臨著「一個擁有訂閱制自動補完 CLI 的聰明人」的威脅。