訂單還沒來先問斷線

假設你是 5 人小公司的老闆，最近想把 AI 小幫手接到官網商店、社群商店和市集平台。你想像的是，它可以幫你看訂單、整理訊息、提醒庫存，最好還能把客服常見問題先擋一輪。 可是你一開始問廠商或工程師，對方沒有先問 AI 要怎麼回話，反而先問你：平台登入誰管？API 斷了誰收通知？同步失敗要重送幾次？你本來只是想省人力，結果第一天就被系統問題拉回地面。 這篇的核心判斷很直接：多平台 AI 專案先卡住，常常不是 AI 不夠聰明，而是 AI底座還撐不起多個銷售平台同時進出資料。AI底座（AI infrastructure），用白話文講，就是讓 AI 能安全連系統、拿資料、記錄動作、處理失敗的那層基礎工程。

先講結論

你先被 AI底座絆倒，因為多個平台不是多接幾條線，而是多出權限、同步、失敗重送與查帳問題。

阿葵接上商城：「AI幫我接單」
派派盯錯誤：「怎麼全線紅燈！」
博士指水管：「底座還沒補」
阿葵加備援：「先別全自動」
補充視角

先替你做判斷

這題的重點不是 AI 小幫手會不會聊天，而是它接到多個銷售平台後，誰能登入、資料何時同步、失敗怎麼補、紀錄去哪查。AI底座沒先做穩，模型越勤快，錯誤越容易被放大。

哪些場景會先爆

你會先撞到這個坑，通常是在 AI 從單一工具變成跨平台幫手的時候。單一平台時，AI 只要看一份資料；多個銷售平台時，它要判斷哪個平台是最新狀態，還要知道哪些動作可以做，哪些只可以提醒人。 外部訊號也在講類似處境。有一個開源專案的討論串在整理小企業自動化工具，重點放在實用比較；另一個開源專案討論把工作小幫手做給老闆和營運者用；還有一個開源專案提到要把產品整理成可接多個 marketplace 的公司方案。marketplace，簡單講就是你上架和成交的外部銷售平台。 Virtualization Review 也報導過一份企業 AI 挑戰調查，主題指向 AI infrastructure 是企業導入 AI 的主要壓力之一。這不代表小公司要照大企業規格建機房。對你來說，它的提醒是：當 AI 開始連訂單和營運資料，底層穩不穩會比介面漂不漂亮更早出問題。 這幾種情境最容易先露出破口：

  • 你要讓 AI 同時讀官網商店、社群私訊和市集訂單。
  • 你希望 AI 自動提醒庫存，但庫存其實散在不同後台。
  • 你想把客訴、退貨、出貨進度集中成一個工作台。
  • 你打算讓 AI 對訂單狀態做建議，甚至觸發後續動作。

失控點不在聊天

真正讓事情失控的原因，是多平台會把同一筆生意拆成好幾份資料。訂單在 A 平台顯示已付款，在 B 系統還沒更新；庫存在倉庫系統扣掉了，前台頁面晚幾分鐘才變；客人已經取消，AI 卻看到舊紀錄，還在建議出貨。 這不是語言模型多問幾句就能補起來的問題。模型擅長整理文字，但它不會天生知道哪個平台的資料比較新，也不會自動理解每個 API 的限制。API，用白話文講，就是不同系統之間交換資料的接口；接口慢、斷、改版，AI 看到的世界就會變形。 AI底座在這個 case 裡代表三件事。第一，它要處理連線和權限，確認 AI 能看什麼、不能動什麼。第二，它要處理資料同步，讓訂單、庫存、會員狀態有可追蹤的更新時間。第三，它要處理失敗後的補救，像是重試、排隊、警示與紀錄。 這也是為什麼有些開源討論會提到 fallback services。fallback service，簡單講就是主要服務失敗時的備援做法。它在這裡不是工程師炫技，而是當某個平台暫時讀不到資料時，AI 要先停手、改成提醒人工確認，或改用上一個可信狀態。 如果接下來 30 天內你把 AI 小幫手接進多個通路，卻沒有失敗通知和查帳紀錄，第一次平台維護時，你要靠誰判斷哪些訂單被漏看？這個問題最好在上線前回答，不要在客人催貨時才補。

先做小而穩的底座

現在先做的不是把所有平台一次接滿，而是挑一個最會影響現金流的流程來驗證。對多數小店來說，通常是訂單狀態、庫存扣減或出貨提醒。你先把這條流程跑穩，再把第二個平台接進來，風險會小很多。 第一個可查證做法，是看平台文件裡的 webhook、rate limit 和 OAuth scopes。webhook，用白話文講，就是平台有新事件時主動通知你；rate limit，就是平台限制你在一段時間內能查幾次；OAuth scopes，就是你授權某個工具能看哪些資料、能做哪些動作。這三個詞不迷人，但它們會決定 AI 小幫手會不會半夜突然拿不到資料。 第二個做法，是把每次關鍵動作都留下 event log。event log，簡單講就是事件紀錄。你不需要一開始就做很複雜，但至少要能查到：AI 何時讀到哪個平台、拿到哪個訂單狀態、做了什麼建議、最後是誰按下確認。 第三個做法，是把失敗分成可重試和不可重試。平台暫時逾時，可以排隊稍後再試；授權過期，就不要一直重送，應該通知管理者重新登入；資料欄位缺少，就先標成待確認。這比讓 AI 猜答案安全得多。 你可以先要求廠商或內部負責人交出這幾項，不需要一次做成大型系統：

  • 每個平台的授權帳號、權限範圍和到期處理方式。
  • 每筆訂單或庫存資料的最後同步時間。
  • 平台讀取失敗時的重試規則與通知對象。
  • AI 做過的建議、觸發動作和人工確認紀錄。

如果你用的是現成自動化工具，也可以照這個方向檢查。Zapier、Make、n8n 這類工具通常有任務執行紀錄與錯誤重跑機制；Shopify 等電商平台也有 webhook 和 API 文件可查。你不一定要自己寫底層程式，但你要知道錯誤會在哪裡被看見。

  1. 1 / 4 · HOOK

    不是 AI 笨，是底座先漏水。

    • 平台一斷線，訂單就漏看
    • 庫存晚同步，AI 還叫你出貨
    • 展示很順，上線才開始查帳
  2. 2 / 4 · WHY

    多平台會把同一筆生意拆碎。

    • 權限沒劃清，誰都像能動手
    • 同步沒時間戳，新舊資料打架
    • 失敗沒紀錄，只剩客人催貨
  3. 3 / 4 · HOW

    先把底座補到會停手。

    • 先挑一條現金流流程
    • 記下每筆資料同步時間
    • 斷線時，先停手通知人
  4. 4 / 4 · TAKEAWAY

    接平台前，先問它怎麼失敗。

    • 能回查，老闆才知道漏哪單
    • 會停手，比會聊天更值錢

別把強模型當備援

最容易白忙的誤區，是以為換一個更強的模型，就能補掉底層串接的洞。模型可以把客服文字整理得更順，也可以幫你把訂單摘要變清楚，但它不能憑空知道平台剛剛回傳失敗，或某個授權已經過期。 另一個誤區，是把所有平台資料先丟進同一張表，再讓 AI 自己判斷。這看起來很快，短期也可能能跑，但只要平台欄位意思不同，後面就會出現同名不同義的問題。例如「已完成」在某平台代表付款完成，在另一個平台可能代表出貨完成。 上線前特別避開這幾種做法：

  • 只測正常訂單，不測平台斷線、授權過期和資料延遲。
  • 只看 AI 回覆是否自然，不看它引用的資料時間。
  • 把不同平台的狀態欄位硬合併，卻沒有對照表。
  • 讓 AI 直接做高影響動作，卻沒有人工確認或撤回紀錄。
注意點

送出前看這四題

如果你今天要核准一個多平台 AI 小幫手專案，不要只看展示畫面。展示通常會挑資料完整、平台順暢、流程最漂亮的情境。你要看的，是它遇到不漂亮的情況時怎麼收場。 送出前，先問這四題：

  • 某個銷售平台暫時讀不到資料時，AI 會停手、重試，還是照舊回答？
  • 同一筆訂單在兩個系統狀態不同時，哪個來源優先？
  • AI 做過哪些判斷和動作，老闆事後能不能查？
  • 權限過期、API 限流、資料欄位改版時，誰會收到通知？
實作提醒

下次拿這篇對表

下次你要評估 AI 小幫手，不要先問它能不能同時接很多平台。先拿這篇當對照表，問廠商或團隊：AI底座怎麼處理權限、同步、失敗和紀錄。 如果你的狀況只是單一平台、低風險提醒，可以先小規模試。若你要讓 AI 影響訂單、庫存或出貨，就先把底座補到可追蹤、可停手、可回查。這條路比較慢，但比較像真的要上線。

讀者最常問的幾個問題

小公司一定要先請工程團隊做完整 AI底座嗎？

不一定。你可以先用現成平台的內建串接、Zapier、Make、n8n 這類自動化工具，或電商平台原生通知功能起步。重點不是一開始做很大，而是先確認登入權限、資料更新時間、錯誤重試、操作紀錄這四件事有地方可查。

如果我只接 2 個銷售平台，也會遇到這些問題嗎？

會，只是規模比較小。只要有 2 個平台，就可能出現同一筆訂單在兩邊狀態不同、庫存更新先後不一致、折扣規則不同步的情況。這時 AI 小幫手如果只看其中一邊，就會給出看似合理但不完整的判斷。

AI底座和一般網站主機有什麼不同？

網站主機主要讓頁面跑得起來。AI底座要處理的是 AI 連到外部系統後的穩定性，例如權限、資料同步、訊息排隊、失敗補送、紀錄查詢與備援。對你來說，就是讓 AI 不只會回答，還能在系統出狀況時留下線索。

什麼時候才適合把 AI 小幫手接到多個銷售平台？

當你已經能清楚回答三件事，就比較適合推進：平台斷線時怎麼知道、資料不同步時誰判斷、AI 做過哪些動作去哪裡查。如果這三題目前都沒有答案，先做單一平台試點會比較穩。