【AI 會寫 API 還不夠：Vibe Coding 下一個機會，是把台灣產業經驗做成 Skill】
- AI 開始會寫 API，真正的差異化可能是讓它理解台灣產業的工作方式 -
最近看到一個很有意思的開源專案：ecommerce-cia。
它不是另一套電商系統，也不是幫你做購物車，而是一套專門給 AI Coding Agent 使用的「台灣電商 Skill」。
看到這個專案，我第一個想到的是：Vibe Coding 發展到現在，真正的瓶頸可能已經慢慢從「AI 會不會寫程式」，轉移到「AI 懂不懂這個產業」。
因為現在要 AI 幫你寫一個購物車，其實已經不難。商品頁、購物車、會員、訂單後台，甚至串 API，AI 都可以很快幫你生出來。
真正痛苦的是後面。
「我要接綠界。」
「我要用藍新。」
「LINE Pay 怎麼串？」
「7-11 取貨付款怎麼做？」
「ATM 付款超過三天沒付，訂單怎麼辦？」
然後你會發現一個很有趣的狀況：Coding Review 沒有 Error，API 文件也看了，每一段程式碼單獨看，好像都沒有問題。
但真的把整間商店跑起來，就是不順。😂
最麻煩的 Bug，可能發生在兩個正確的 Function 之間
一般我們叫 AI Review 金流，很容易只檢查幾個局部問題：
- API 呼叫對不對？
- 簽章對不對？
- Callback Route 有沒有建立？
- 資料庫有沒有寫入？
- 庫存 Function 有沒有執行？
每一個地方都可能是對的，但問題可能發生在兩個「正確的 Function」中間。
以一筆交易為例，流程可能像這樣：
- 客人建立訂單。
- 系統保留庫存。
- 客人前往金流服務付款。
- 金流通知商店付款結果。
- 系統驗證通知並更新訂單狀態。
- 庫存、顧客通知與出貨流程依照訂單狀態接續處理。
如果 Callback 重送兩次呢？客人付款成功，但瀏覽器沒有跳回網站呢？ATM 建立虛擬帳號後幾天都沒有付款，庫存要什麼時候釋出？如果付款成功但庫存更新失敗，或訂單取消時付款通知剛好進來，系統又該怎麼辦？
這些才是真正把電商系統跑起來後，會遇到的問題。
所以 Review 金流不該只逐個看 Function，而要沿著「錢」和「貨」走過完整流程：下單、訂單、庫存、金流、Callback 驗證、狀態更新、出貨，到交易完成，逐段找可能的斷點。
ecommerce-cia 示範了另一種 AI 稽核方式
ecommerce-cia 不是另一套購物車或電商平台，而是給 AI Coding Agent 使用的台灣電商 Skill。它有意思的地方，在於把注意力放到金流、庫存、訂單等環節如何互相影響。
依照專案 README 的說明，它有檢查既有交易流程的 Audit Mode，也有引導新手準備與串接金流的 Setup Mode；文件提到藍新、綠界、PAYUNi、TapPay 與 LINE Pay 等台灣常見情境。這些內容呈現了一個值得參考的方向：除了問 AI「這段程式碼有沒有寫錯」，也可以要求它沿著整條交易生命週期檢查系統行為。
這已經不只是一般的 Coding Skill，而是把產業流程和判斷方式整理成可重複使用的 Domain Engineering Skill。
AI 會看 API 文件，稀缺的是踩過坑的經驗
這件事讓我想到我之前一直在談的「把專業知識軟體化」。
假設一個台灣電商工程師做了十年。他真正值錢的可能不是「我知道怎麼呼叫綠界 API」，因為這件事情 AI 看文件就能協助。
真正值錢的，是這些踩過坑才知道的事：
- 綠界或藍新的 Callback 曾經出過什麼狀況。
- ATM 訂單逾期後，何時釋放庫存才符合商業規則。
- 超商取貨付款訂單的狀態該怎麼轉換。
- 使用者付款成功但沒有跳回網站，不能因此就判定付款失敗。
- Webhook 重送不能重複扣庫存或重複通知。
- 退款、取消與付款通知同時發生時，訂單狀態要如何處理。
這些東西通常不會完整寫在 API 文件裡。它們存在工程師的腦袋裡，來自踩坑、Debug、客訴、事故，以及凌晨三點修 Production 的經驗。😂
API 文件能說明端點、欄位和簽章方式；把這些技術細節放進真實商業情境後，流程上的例外與判斷往往還要靠產業經驗補足。
專業知識除了軟體化，也可以 Skill 化
以前我們會想：我做了十年房仲，可不可以把我的判斷方法做成一套房仲 SaaS？我做了十年行銷，可不可以把我的 SOP 做成一套行銷系統？
我之前也寫過把專業知識變成軟體，讓產業專家成為下一代產品經理。現在可能又多了一條路：不一定要先做 SaaS，也可以先把專業知識整理成 Skill。
從產業經驗到 AI 可執行 Skill 的概念示意。
一個資深電商工程師的經驗，如果要整理成 AI 能使用的 Skill，可以從常見情境開始，逐步寫清楚：
- 什麼情況下要啟動檢查。
- 要沿著哪些訂單、金流和庫存流程追蹤。
- 哪些例外狀況需要特別確認。
- 要用什麼證據判斷流程真的完成，而不是只看單一測試顯示綠燈。
如此一來，AI 就不只是「會寫程式」，還能重複參照一套做過許多台灣電商專案的人累積的判斷方式。
下一波 Vibe Coding 機會，可能是台灣產業 Domain Skills
未來 Skill 最有價值的地方，不一定是 React Skill、Next.js Skill 或 Python Skill。這些通用技術知識，模型本身會越來越強。
更可能形成差異化的，是懂得台灣產業實際怎麼運作的 Domain Skills，例如：
- 台灣電商金流與物流。
- 台灣電子發票、統編與發票規則。
- LINE 官方帳號與會員流程。
- 政府 Open Data 與台灣個資保護情境。
- 房仲成交流程、補教招生、餐飲訂位、美容預約與傳統產業報價。
這些領域的共同點是：模型可能知道技術，但不一定知道台灣的商業流程、例外情境與在地作法。而真正掌握這些 Know-how 的人，往往是已經在產業裡工作十年、二十年的實務工作者。
Skill 不只是提示詞，而是可以交給 Agent 使用的 SOP
我現在看 Skill，已經不只把它當成「提示詞」，而是可以被 AI Agent 使用的產業 SOP。
以前經驗存在腦袋裡，後來我們把它寫成 SOP，再把 SOP 做成軟體。現在又多了一種形式：把 SOP 整理成 AI Agent 能參照與執行的 Skill。
Vibe Coding 的競爭，可能不只是誰比較會下 Prompt、誰比較會用 Claude Code 或 Codex，而是誰能把自己十年、二十年的產業經驗，整理成 AI 可以重複使用的能力。
模型會越來越強，寫程式會越來越便宜，API 串接也會越來越簡單。但有一件事情不會因此自動出現：你踩過的那些坑。
而那些坑，可能才是 AI 時代真正值得被「程式化」的專業知識。
這也是我看到 ecommerce-cia 之後，覺得最值得研究的地方。它表面上是在處理台灣電商金流、物流與流程稽核，背後示範的也許是一個更大的方向：下一波 Vibe Coding，不只是讓 AI 幫我們寫軟體，而是開始把一個產業真正的 Know-how，寫進 AI 裡。
常見問答 (FAQ)
Q1：什麼是台灣產業 Domain Skill？
台灣產業 Domain Skill 是把在地產業常見的情境、判斷方式、執行流程與例外處理整理成 AI Agent 可重複參照的規範。它能補足通用技術知識與實際商業流程之間的落差。
Q2：Domain Skill 和一般 Code Review 有什麼不同？
一般 Code Review 多半檢查程式碼或單一 Function 的正確性；Domain Skill 可以引導 AI 沿著跨系統流程檢查狀態如何傳遞，例如金流通知、訂單更新、庫存處理與出貨。兩者處理的問題不同，實務上可以搭配使用。
Q3：如何把產業經驗整理成 AI Agent Skill？
先整理常見情境與踩坑案例，再把觸發條件、判斷方式、處理步驟、例外狀況與驗證證據寫清楚，最後交由熟悉該產業的人用真實案例檢查。這樣的 Skill 才能承載可重複使用的專業判斷，而不只是一段泛用提示詞。
