一個台南小團隊用 Claude Code 三週交付百萬專案:當傳統外包商還在開會，他們已經上線收錢了

四個人、三週、一個價值百萬的電商後台系統。台南一間五人工作室靠 Claude Code 的 agentic workflow 完成了傳統外包商報價三個月的案子。這不是矽谷的故事，是台灣南部真實發生的事。

上週跟一個台南的朋友吃飯，他丟了一句話讓我筷子差點掉下來:「我們上個月用 Claude Code 三週結案一個百萬的案子，甲方到現在還搞不清楚我們怎麼做到的。」

他的工作室叫「海風數位」（化名），就在台南市東區一棟老公寓的三樓。團隊五個人，一個做設計，兩個前端，一個後端，加上他自己什麼都碰一點。這種規模在台灣的接案生態裡，坦白講，就是那種大案子吃不到、小案子嫌太碎的尷尬位置。

但這次不一樣。

案子是什麼

一家中部的傳統製造商想做 B2B 電商後台——經銷商下單、庫存管理、報價單自動生成、對接既有的 ERP 系統。甲方先找了兩家傳統外包商報價，一家報 180 萬工期四個月，另一家報 150 萬工期三個月。他們最後把案子給了海風，報價 95 萬，工期三週。

「人家一定覺得我們在唬爛，」他笑著說，「但我心裡有底，因為我已經用 Claude Code 做過幾個小案子了，我知道它能幹嘛。」

他們怎麼用 Claude Code

這裡是我最感興趣的部分，所以我追問了很多細節。

他們的工作流程大概是這樣的:第一天開完需求會議之後，他直接把需求文件餵進 Claude Code，讓它幫忙產出整個專案的架構骨架——API schema、資料庫 ERD、前端元件樹。「以前這個動作我們至少要花一週來回討論，現在半天搞定，而且產出的品質比我自己畫的好。」

接下來的關鍵操作是，他們把 CLAUDE.md 寫得非常詳細。這件事我要特別強調，因為大多數人用 AI coding tool 的方式是錯的——他們直接開口問問題，然後抱怨答案不好。海風的做法是花了整整一個下午寫了一份將近 2000 字的 CLAUDE.md，裡面定義了 coding convention、tech stack 的版本、每個模組的命名規則、甚至連 error handling 的模式都寫死了。

「你可以把 CLAUDE.md 想成一個超級詳細的 onboarding 文件，只是你 onboard 的對象不是人，是 AI，」他這樣形容。

後端的同事用 Claude Code 的 agentic mode 來處理最痛苦的部分——ERP 對接。那套 ERP 是十幾年前的系統，API 文件殘缺不全（做過台灣傳統產業整合的人都懂那個痛）。他們把僅有的文件和幾個 sample response 丟給 Claude Code，讓它自己去推斷 API 的行為模式，然後生成 adapter layer。

「最猛的是它寫測試，」他特別提到這點，「我們叫它幫每個 adapter 寫 integration test，它不只寫了 happy path，連那些 ERP 回傳亂碼的 edge case 都 cover 到了。」

前端兩個人則是一人負責一半的頁面，每個人都開自己的 Claude Code session。他們的 prompt 策略是先讓 Claude Code 讀完設計稿的標註（用截圖丟進去），然後直接生成 React 元件。「大概七成可以直接用，三成要手動調。但以前那七成是我們要自己一行一行刻的。」

跟競品比起來呢

我問他為什麼不用 GitHub Copilot 或 Cursor。

「Copilot 我用過兩年，它的 inline suggestion 很好，但它不懂我的整個 codebase。我需要的不是幫我補完下一行，我需要的是一個能理解整個專案然後幫我生整塊功能的東西。」

這個觀察其實很精準。Copilot 的甜蜜點是 line-level 和 function-level 的補完；Cursor 的 Composer 開始往 multi-file editing 走，但在 agentic 程度上還是比 Claude Code 差一截。Claude Code 真正的殺手鐧是它的 CLI-native 設計加上對整個 project context 的掌握——它不只是一個編輯器外掛，它是一個跑在你終端機裡、能自己讀檔改檔跑測試的 agent。

不過說實話，這裡有個 caveat:Claude Code 的學習曲線比 Copilot 陡很多。你不能裝好就用，你得學會怎麼寫 CLAUDE.md、怎麼設定 permission mode、怎麼用 /plan 跟它對齊思路。海風的團隊花了大概兩三個月才摸出一套有效的使用方法。

那些沒講的部分

我也追問了踩過的坑，因為只講成功的故事是不誠實的。

第二週他們遇到一個大問題:Claude Code 生成的庫存計算邏輯有一個 off-by-one error，在特定的併發場景下會導致庫存數字對不上。這個 bug 藏了三天才被發現，因為它只在兩個經銷商「幾乎同時」下單同一個品項時才會觸發。

「AI 寫的 code 你還是得 review，這點沒有任何捷徑，」他很認真地說，「它幫你省的是打字的時間和架構設計的時間，但 code review 的責任永遠在人身上。」

另一個問題是 context window 的限制。當他們的 codebase 長到一定程度之後，Claude Code 開始「忘記」早期定義的一些 convention，生成的新 code 風格會漂移。他們的解法是把最重要的規則都寫在 CLAUDE.md 裡（因為這個檔案永遠會被載入），而不是靠對話歷史。

結果

三週後系統上線。甲方的經銷商第一天就下了 47 筆訂單。到現在運行兩個月了，除了一次因為甲方自己的 ERP 掛掉導致同步中斷之外，零事故。

95 萬，三週，四個人。

同樣的案子，傳統外包商的報價是 150 到 180 萬，三到四個月，團隊至少八到十人——而且你我都知道，台灣外包業的「三個月」通常意味著五個月。

我不是要說 AI 工具會取代工程師。海風的四個人每一個都是有五年以上經驗的開發者，他們知道什麼該讓 AI 做、什麼不該。但我確實認為一件事正在發生:會用這些工具的小團隊，正在吃掉那些靠人力規模撐場面的中型外包商的市場。

這個趨勢不可逆。

你如果現在還在觀望 Claude Code 或類似的 agentic coding tool——不是該不該學的問題，是你還剩多少時間學的問題。

Prompt Engineering 備註:海風團隊最有效的 prompt 策略不是單次的神奇 prompt，而是 CLAUDE.md 的系統性設定。把你的 coding standard、tech stack constraint、甚至 anti-pattern 都寫進去。這比任何 prompt trick 都有效十倍。