從 Vibe Coding 到商業上線：走完 doudou EOR 落地
January 6, 2026
從 Vibe Coding 為起點，實際走完一條被客戶與商業檢驗的 ERP 產品上線旅程。
Employment of record
2026 年 01 月 06 日 · 閱讀時間約 12 分鐘
這不是一個 side project，也不是一個 demo。這是一個被賣、被用、被罵，也被期待的產品。
本文以工程師的視角進行回顧與產品實戰紀錄。
它不是技術教學文，也不是工具比較，而是記錄我在 2025 年 4 月到 11 月之間，如何從 AI Vibe Coding，一路走到商業交付、被市場與客戶檢驗的系統。
站在 2026 年初回頭看，對於我而言是一段值得留下文字的旅程。
一切的起點：三人小隊
這段旅程的起點，如果要用一個比喻來形容，這次的合作像是一趟臨時成團、卻必須走完全程的遠征。
強尼 是這趟旅程的領航員。他站在前線，替我們與業主對話，判讀方向、校正路線，把抽象的商業語言，轉譯成我們能實際前進的步伐與節奏。對我而言，他不只是 PM，更像是在關鍵時刻提醒「這條路走得通嗎」的人。
沐恩 則像是地圖繪製者。她深入需求訪談的現場，把零散、衝突、甚至彼此拉扯的想法，整理成清楚的路徑與節點，讓使用者的每一步都有跡可循，也讓工程能在不迷路的情況下前進。
而我，負責的是把這張地圖真正鋪成道路的人。從地基、結構到細節收尾，確保這條路不只是看起來存在，而是真的能被走、被反覆使用，並承受現實世界的重量。
我們只有三個人，沒有多餘的資源與緩衝空間。但也正因如此，每個決定都很直接、每一次信任都很關鍵。回頭看，正是這個小又彼此互補的組合，讓這趟旅程能夠一路走到真正上線的那一刻。
四月：幾次談談，MVP 的誕生
四月的幾次訪談，為整個產品定下了基調。
當時，我們對這個專案的想像，其實相對保守，它比較像是一個企業內部外包的 Proof-of-Concept (PoC)，用來驗證一個 EOR 系統在上雲後的流程與商業上的可行性。
不追求「什麼都做」，而是非常克制地定義了 Minimal Viable Product (MVP)：
- 哪些流程一定要有
- 哪些國家一定要被支援
- 哪些功能現在不做，反而是對產品負責
這些刻意的取捨，在當下看起來很保守，但後來證明，它們替整個專案撐住了第一層結構。
五月：真正的程式動工，Vibe Coding 的開始
五月，真正動工，從 Figma 白板與文件，走向實際的程式碼，這個階段也是我第一次深刻感受到 AI Vibe Coding 的力量。
對很多人而言，Vibe Coding 是一種「求有就好」的過程；但對我們來說，這一次的挑戰是唯有借助 AI 力量，我們才有機會走到終點。
雖然許多系統設計與架構概念，過去多少都有所耳聞，但在過去的經驗裡，往往因為角色與責任邊界的關係，沒有真正派上用場的空間。懂一點卻很少輪到自己做決定。
這次是我第一次站在「必須做選擇的人」的位置上。從技術選型、系統走向，到每一個看似微小、但影響著長期維運的決策，都必須自己承擔後果。
一方面是邊走邊學，另一方面，也被迫開始思考那些在過去視野裡，根本沒有機會面對的問題。
回過頭來看，當因為 AI 開發功能變得更快時，壓力其實沒有減少，而是整體往上移了一層。
我開始反覆問自己：
這個設計真的撐得住嗎？還是只是「現在看起來能跑」？
選用的第三方服務，會不會其實是殺雞用牛刀？
這樣的解法，真的適合在這個時間點導入嗎？所謂的 Best Practice，是不是放錯了場景？
資料在量起來之後，讀取會不會出問題？
流程設計有沒有足夠防呆，還是只是在賭使用者不會走歪？
還有更多更瑣碎、卻同樣重要的問題：
當錯誤發生時，錯誤訊息使用者看得懂發生了什麼嗎？
這些問題，大多不會出現在功能完成的那一刻，而是在系統開始被「認真使用」之後，才一個一個浮現。
我也意識到，很多當下覺得模糊、甚至說不出來的不安，其實正是工程師成長的足跡。
甜蜜時程 vs 現實世界
一開始，我們心中都有一個「甜蜜時程」：8 月底。
它不是 hard deadline，而是一個團隊內部對交付的期許，在商業酬勞與開發時程之間，一個看起來合理、也讓人有動力前進的時間點。
在專案初期，這個時間點並沒有太多衝突。因為在大家的認知裡，這仍然是一個 PoC 性質的合作：重點在於驗證流程、測試可行性，而不是馬上承擔完整的營運風險。
但隨著前端畫面、後端系統逐漸成形，事情開始變得微妙。
我們內部開始感受到交付壓力，希望能在這個時間點拿出一個「完整、可展示、可使用」的結案版本；而業主端開始頻繁地提到另一件事：穩定性。
於是，出現了一種當下說不出口、但實際存在的矛盾：我們承受著時間帶來的推進壓力，對方想慢一點，不希望系統帶著風險交付。
真正的辛苦談，也正是從這個張力開始浮現。
需求不再只是「補功能」，而是開始牽動整體流程；功能複雜度快速攀升；而穩定性、資料正確性、使用者防呆設計、資訊安全，也逐漸從配角，走到系統設計的正中央。
從 PoC 到 Spin-out：專案性質的劇烈轉變
後來我們真正意識到，這些變化並不是偶然。
隨著市場動態與商業可行性的浮現，原本被視為企業內部 PoC 的專案，在短短幾個月內，轉變成一間 spin-out 的獨立公司。
這個轉折點，徹底改變了專案的性質。
與我們對口的業主同仁，也不再只是「需求窗口」，而是在這趟旅程中，逐步成為子公司的經理與夥伴。
角色的改變，帶來的是期待與標準的全面升級。系統不再只是「可以用就好」，而是必須面對一個更現實的要求，不能出錯。
這也解釋了，為什麼在那個時間點之後，測試變得更嚴格、討論變得更細碎，而每一個看似小的決定，都開始被反覆檢視。
因為這已經不只是一個專案，而是一個準備走向市場的產品。
工程師視角：我一個人包辦了什麼
在這段旅程中，我一個人包辦了大部分功能開發的事情 (感謝學長強尼給了很多我指導)。
技術棧選擇為 Next.js、Vercel、MongoDB、Supabase、Mailgun。
圍繞 EOR 的核心邏輯，是大量交互的表單填寫更新刪除、進度追蹤、檔案上傳、搜尋系統、站內通知、Email 通知、多角色的權限登入管理系統。
當這些模組開始彼此交織時，我才真正體會到， ERP 系統沒有「小功能」。
80 項需求變更：需求地獄與產品現實
初版交付後，真正的戰爭才開始。數十次的來回溝通、超過 80 項的需求溝通與修正來回，背後其實來自三種原因：
- 我們的疏忽
- 業主一開始沒想到
- 真正隨著商業推進而出現的追加需求
有些往往都不是單純的 bug，而是產品走進真實世界後，必然會遇到的現實摩擦。
系統設計被迫進化
為了有效解決這些問題，系統設計做了多次調整。
我學到一件很重要的事：「撐一下」通常是錯的選擇。
真正的產品級軟體，要求的是可預期、可修復、可擴充，而不是勉強能動。
回頭看：這趟旅程值不值得？
回想這些日子，很難用一句話概括，但數字會留下痕跡。
3 個人，1 個專案，210 天，29 個不重複使用者頁面，53 個 API 結點，439 個檔案，54,429 行程式。
這些數字本身並不代表成功，也不保證品質，卻誠實記錄了我們曾經走過的痕跡，那些反覆推翻、重寫、調整與修補的日子。
它們背後是一次又一次在「能不能撐住」、「該不該再改」之間做出的選擇。
如果要我回答這趟旅程值不值得，答案很簡單。
值得。
因為跟著強尼和沐恩，我們不只是寫完了一個系統，而是完整經歷了一次，從想像走到現實、從 Vibe Coding 走到商業上線的過程。
後記
沐恩說因為這次合作經驗，讓她在紐約找到一份很好的工作，一起恭喜她！