從 Vibe Coding 到商業上線：走完 doudou EOR 落地
January 6, 2026
從 Vibe Coding 為起點，實際走完一條被客戶與商業檢驗的 ERP 產品上線旅程。
Employment of record
這件事不是為了漂亮的 demo，而是要能被賣出去、被日常使用、也被挑剔。當產品開始承擔責任，所有小細節都變成大問題。
這是一份工程師視角的戰地筆記。
它不是技術教學文，也不是工具比較，而是記錄我在 2025 年 4 月到 11 月之間，如何從 AI Vibe Coding，一路走到商業交付、被市場與客戶檢驗的系統。換句話說，這是一條從「可以跑」走向「能被挑剔」的路。
站在 2026 年初回頭看，這是一段值得留下文字的旅程。
一切的起點：三人小隊
想像一下，三個人要在七個月內，從零打造一套能上線營運的 EOR 系統。
沒有現成框架可以套、沒有前人經驗可以抄、沒有多餘的人力緩衝。
這就是我們的起點。
如果要用一個比喻來形容，這次的合作像是一趟臨時成團、卻必須走完全程的遠征。
強尼是這趟旅程的領航員。他站在前線，替我們與業主對話，判讀方向、校正路線，把抽象的商業語言轉譯成我們能實際前進的步伐。對我而言，他不只是 PM，更像是在關鍵時刻提醒「這條路走得通嗎」的人。
沐恩是地圖繪製者。她深入需求訪談的現場，把零散、衝突、甚至彼此拉扯的想法，整理成清楚的路徑與節點，讓使用者的每一步都有跡可循，也讓工程能在不迷路的情況下前進。
而我，負責把這張地圖真正鋪成道路。從地基、結構到細節收尾，確保這條路不只是看起來存在，而是真的能被走、被反覆使用，並承受現實世界的重量。
三個人，沒有多餘的資源與緩衝空間。但也正因如此，每個決定都很直接、每一次信任都很關鍵。
小團隊的優勢不是資源少，是每個人都無處可躲。
四月：幾次訪談，MVP 的誕生
四月的幾次訪談，為整個產品定下了基調。
當時，我們對這個專案的想像其實相對保守——它比較像是一個企業內部外包的 PoC（Proof of Concept），用來驗證 EOR 系統上雲後的流程與商業可行性。
不追求「什麼都做」，而是非常克制地定義了 MVP：
- 哪些流程一定要有
- 哪些國家一定要被支援
- 哪些功能現在不做，反而是對產品負責
這些刻意的取捨，在當下看起來很保守，但後來證明，它們替整個專案撐住了第一層結構。
MVP 的價值不在於它有多少功能，在於它讓團隊知道什麼不該做。
五月：真正的程式動工，Vibe Coding 的開始
五月，真正動工。從 Figma 白板與文件，走向實際的程式碼。
這個階段是我第一次深刻感受到 AI Vibe Coding 的力量。
對很多人而言，Vibe Coding 是一種「求有就好」的過程；但對我們來說，這一次的挑戰是——唯有借助 AI 力量，我們才有機會走到終點。
過去的經驗裡，很多系統設計與架構概念我多少都有耳聞，但往往因為角色與責任邊界的關係，沒有真正派上用場的空間。懂一點，卻很少輪到自己做決定。
這次不一樣。
這是我第一次站在「必須做選擇的人」的位置上。從技術選型、系統走向，到每一個看似微小、但影響長期維運的決策，都必須自己承擔後果。
一方面是邊走邊學，另一方面，也被迫開始思考那些在過去視野裡根本沒機會面對的問題。
回過頭來看，當 AI 讓開發功能變得更快時，壓力其實沒有減少，而是整體往上移了一層。
我開始反覆問自己：
這個設計真的撐得住嗎？還是只是「現在看起來能跑」？
選用的第三方服務，會不會其實是殺雞用牛刀？
這樣的解法，真的適合在這個時間點導入嗎？所謂的 Best Practice，是不是放錯了場景？
資料在量起來之後，讀取會不會出問題？
流程設計有沒有足夠防呆，還是只是在賭使用者不會走歪？
還有更瑣碎、卻同樣重要的問題：
當錯誤發生時，錯誤訊息使用者看得懂嗎？
這些問題，大多不會出現在功能完成的那一刻，而是在系統開始被「認真使用」之後，才一個一個浮現。
AI 讓你寫得更快，但不會讓你想得更清楚。速度提升之後，思考的壓力只會更大。
甜蜜時程 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 走到商業上線的過程。
真正的成長不是學會了什麼技術，是經歷過一次完整的失敗、修正、再交付的循環。
後記
沐恩說因為這次合作經驗，讓她在紐約找到一份很好的工作。
一起恭喜她！