[{"data":1,"prerenderedAt":44},["ShallowReactive",2],{"article-zh-ai-needs-customer-insight-not-just-code":3},{"article":4,"related":17,"prevArticle":37,"nextArticle":41,"availableLocales":42},{"id":5,"slug":5,"title":6,"excerpt":7,"content":8,"image":9,"date":10,"published":11,"status":12,"category":13,"keywords":14,"meta_description":15,"og_image":16,"custom_css":16,"created_at":10,"updated_at":10},"ai-needs-customer-insight-not-just-code","我們從北美電商專案學到的兩件事","去年做北美雙倉跨洋補貨與履約風險決策平台時，我們再次確認：真正困難的不是把 AI 接進系統，而是能不能理解每一次決策所處的時間、限制與後果。","\u003Cp>去年，我們做了一個北美雙倉、跨洋補貨與履約風險決策平台。\u003C/p>\n\n\u003Cp>表面上看，這是一個供應鏈系統：中國供應端、LA 與 Houston 兩個倉、多通路銷量、零售商叫貨 PO、訂艙、通關、運價、跨區履約與調撥。\u003C/p>\n\n\u003Cp>但真的開始拆之後才發現，它其實不是在解一個「預測」問題，也不是在做一個「有 AI 的 dashboard」。它在處理的是：當資訊不完整、風險一直變、每個動作都會影響下一個動作時，今天到底該怎麼決定。\u003C/p>\n\n\u003Cp>這段經驗也讓我們更確定一件事：現在用 AI 寫出一個系統，已經不是最難的部分。真正困難的是，團隊有沒有能力把一個產業裡那些還沒被講清楚的情境、限制與後果，一起看進去。\u003C/p>\n\n\u003Cp>我想把這次專案裡，最有感的兩件事整理下來。\u003C/p>\n\n\u003Ch2>第一件事：模型不能活在事後，它必須活在當時\u003C/h2>\n\n\u003Cp>供應鏈裡有很多數字看起來都很直覺。\u003C/p>\n\n\u003Cp>貨什麼時候到。  \n還有多少庫存。  \n報價是多少。  \n某一票貨有沒有被查驗。\u003C/p>\n\n\u003Cp>但真的做決策時，最重要的往往不是最後的答案，而是：\u003Cstrong>在那一天、那一刻，我們到底看得到什麼？\u003C/strong>\u003C/p>\n\n\u003Cp>例如，後來更新過的 ETA 不能回頭當成當時已知的資訊；最終帳單不能拿來假裝當初就知道成本；查驗結果也不能在回測時提前出現。這些看起來像資料工程的小細節，實際上會直接決定模型是不是在自欺欺人。\u003C/p>\n\n\u003Cp>如果模型用了未來才知道的資訊，它當然會看起來很準。  \n但那不是預測能力，只是事後諸葛。\u003C/p>\n\n\u003Cp>所以我們在這個系統裡很在意事件發生時間、資料第一次可見的時間、規則版本，以及每一次 decision timestamp 下的狀態快照。不是因為這些東西很技術，而是因為真實世界不會讓你帶著答案回去做決策。\u003C/p>\n\n\u003Cp>這也是我們認為 AI 真正開始有價值的一個分水嶺：它不只是能把資料算得更快，而是能不能在當下資訊不完整的情況下，把不確定性也一起說清楚。\u003C/p>\n\n\u003Cp>不是只給一個 ETA，而是給一個到貨區間與風險。  \n不是只說要不要調貨，而是告訴你各種情境下可能發生什麼，還有發生的機率。  \n不是只說哪個方案成本最低，而是把缺貨、服務承諾、客戶關係與後續機會成本一起攤開來看。\u003C/p>\n\n\u003Cp>這種能力不只是模型能力。它背後需要的是對問題本身的理解。\u003C/p>\n\n\u003Ch2>第二件事：人不是 AI 上線前的簽核，而是系統學習的一部分\u003C/h2>\n\n\u003Cp>這次有一個很典型的問題：Houston 的庫存，到底要不要拿去救美西的單？\u003C/p>\n\n\u003Cp>如果只看單一訂單，答案可能很簡單。美西缺貨，Houston 還有貨，就跨區寄。\u003C/p>\n\n\u003Cp>但只要往下多看一層，事情就不一樣了。\u003C/p>\n\n\u003Cp>這批貨送去美西，可能保住一張高毛利訂單；但同時也可能讓 Houston 自己的區域在下一個需求高峰缺貨。中間還有跨區運費、承諾日、零售商罰則、倉庫作業能力，以及客戶長期價值。\u003C/p>\n\n\u003Cp>一個成熟的系統，不應該只丟出「建議調撥」四個字。\u003C/p>\n\n\u003Cp>它至少要講清楚：\u003C/p>\n\n\u003Cul>\n\u003Cli>這個動作在什麼情境下值得做。\u003C/li>\n\u003Cli>不做會失去什麼；做了又會把哪些風險帶到下一站。\u003C/li>\n\u003Cli>它有沒有碰到不能被成本抵銷的硬限制。\u003C/li>\n\u003Cli>如果人決定修改建議，修改的是什麼，又為什麼。\u003C/li>\n\u003C/ul>\n\n\u003Cp>這也是我們對 human-in-the-loop 的理解。\u003C/p>\n\n\u003Cp>人不是模型上線前按一下「同意」的人。人工的批准、修改、拒絕與延後，本身都是很重要的訊號。它可能反映客戶關係、合規條件、現場狀況，或某些還沒有被寫進規則的商業判斷。\u003C/p>\n\n\u003Cp>但人工判斷也不能只停在聊天紀錄裡。\u003C/p>\n\n\u003Cp>模型當時提出了哪些候選方案、人工最後選了什麼、實際執行的是什麼，以及幾週或幾個月後真正發生了什麼，都必須能被保留下來。這樣系統才有機會形成一條可以回放的決策閉環，而不是每次都從零開始猜。\u003C/p>\n\n\u003Cp>我們越來越確定：AI 若要走進複雜營運，它必須學的不是「人有沒有按同意」，而是人為什麼在那個情境下做了那個選擇，以及那個選擇最後帶來什麼結果。\u003C/p>\n\n\u003Ch2>複雜場景，難的從來不是把模型接起來\u003C/h2>\n\n\u003Cp>現在很多事情都可以很快做出 demo。\u003C/p>\n\n\u003Cp>拉資料、接模型、做介面、讓它產生建議，這些事情的門檻確實正在下降。這是好事。\u003C/p>\n\n\u003Cp>但真正走進產業之後，困難不會因此消失，它只是從「能不能做」變成「知不知道該怎麼做」。\u003C/p>\n\n\u003Cp>哪些資料是事後才知道的，不能拿來訓練。  \n哪些規則是硬限制，不能讓模型用更高收益交換。  \n哪些平均數會掩蓋掉關鍵客戶、特定路線或特定倉的失敗。  \n哪些動作表面上救了一個區域，實際上只是把風險搬到另一個地方。\u003C/p>\n\n\u003Cp>這些問題沒有一個只靠模型名稱可以回答。\u003C/p>\n\n\u003Cp>它需要 customer insight，也需要 problem insight。更直接地說，它需要團隊願意陪著業務走到細節裡，把原本分散在不同角色經驗中的判斷，一點一點拆出來、定義出來、留下來。\u003C/p>\n\n\u003Cp>這也是我們這一年很常在做的事。\u003C/p>\n\n\u003Cp>我們不是先拿一套 AI 解法，再去找能套進去的問題；而是先把不同產業真正卡住的地方看清楚，再判斷模型、規則、資料與人的角色應該怎麼組合。\u003C/p>\n\n\u003Cp>有些情況適合自動化。  \n有些情況應該只做建議。  \n有些情況最重要的反而是讓系統知道：現在資料不夠，應該停下來交給人判斷。\u003C/p>\n\n\u003Ch2>當決策開始同時看見一百多個資料源\u003C/h2>\n\n\u003Cp>這個專案最後串接了\u003Cstrong>超過百個資料源、幾千個欄位，以及上千個關鍵因素\u003C/strong>。需求、庫存、零售商 PO、訂艙、跨洋節點、通關、運價、外部氣象訊號，以及人工覆核後真正執行的結果，都必須在 SKU、倉別、通路與時間上對得起來。\u003C/p>\n\n\u003Cp>聽起來像資料整合，但困難從來不只在接進來。每一筆資訊都會改變下一個動作的判斷：是先補貨、改分倉、跨區直寄，還是乾脆不動。系統必須即時把庫存週轉、缺貨風險、服務承諾、物流成本與貢獻毛利放到同一張決策帳上，讓團隊不必靠一連串人工轉述與試算，才知道這一票貨該怎麼走。\u003C/p>\n\n\u003Cp>結果是，庫存周轉率與毛利率都出現顯著提升；專案回本週期低於一年，截至撰稿時換算的 ROI 已超過 300%。\u003C/p>\n\n\u003Cp>不過，這份成果從來不是我們自己完成的。它來自企業主願意為長期價值投入的遠見，也來自內部團隊全力配合，讓資料、流程與現場判斷真正被攤開來一起處理。更難得的是，面對導入初期難免出現的小錯誤，團隊選擇一起修正、一起校準，而不是在第一次不完美時就放棄。這些看似不在系統裡的條件，才讓專案最後走出了亮眼的成績。\u003C/p>\n\n\u003Ch2>結語\u003C/h2>\n\n\u003Cp>回頭看這個雙倉供應鏈專案，我們完成的不只是模型與規則的設計基線。\u003C/p>\n\n\u003Cp>更重要的是，我們重新驗證了一件一直相信的事：AI 的成熟，不在於它看起來多聰明，而在於它能不能理解自己正在面對什麼樣的不確定性；能不能把限制與後果說清楚；又能不能和人的經驗一起，把複雜的決策走得更穩。\u003C/p>\n\n\u003Cp>真正能在產業裡創造價值的，不是把 AI 放進系統裡而已。  \n而是把那些原本沒有被系統看見的情境與判斷，也一起放進去。\u003C/p>","https://cdn.sqa.tw/articles/ai-decision-complexity-supply-chain-2026-08-17.png","2026-08-17T02:30:00+00:00",true,"published","industry","AI 決策系統, 供應鏈 AI, 情境洞察, scenario insight, human-in-the-loop, point-in-time data","從北美雙倉跨洋補貨與履約風險決策平台回看，談複雜商業場景中 AI 真正需要的 scenario insight、point-in-time 資料紀律，以及 human-in-the-loop 的決策閉環。",null,[18,25,31],{"id":19,"slug":19,"title":20,"excerpt":21,"image":22,"date":23,"category":24},"sme-guide-to-choosing-ai-agent","滿街都是AI Agent，中小企業應該怎麼選？","我們最近被委託做 AI Agent 導入後的全盤檢查，才發現 Agent 在客服收單環節默默多採購了五倍原料，還差點在財務面造成流動性風險。Agent 的問題，往往不是不夠聰明，而是沒有人問對問題。","https://cdn.sqa.tw/articles/sme-agent-black-box-inspection.jpg","2026-09-01T15:00:00+00:00","perspective",{"id":26,"slug":26,"title":27,"excerpt":28,"image":29,"date":30,"category":24},"ai-coding-team-collaboration-three-patterns","AI coding 進到團隊之後，我們開始看到的三個現象","這半年接觸十多個開發團隊後，我們反覆看到同一件事：個人因 AI 變快，不代表團隊已經準備好一起變快。","/images/blog/ai-coding-teams-editorial.jpg","2026-08-20T08:00:00+00:00",{"id":32,"slug":32,"title":33,"excerpt":34,"image":35,"date":36,"category":24},"why-we-are-reintroducing-dbam-ai","為什麼我們重新整理 SQA.TW","這次 SQA.TW 改版，不是離開 SQA，而是讓網站更完整地呈現我們一直在做的事：理解企業營運、找出數位化與 AI 能真正發揮作用的位置。","https://cdn.sqa.tw/articles/1787077891011-ga9zk8zxnf.jpg","2026-08-17T16:00:00+00:00",{"slug":38,"title":39,"date":40},"qaptly-v0175-codex-support","Qaptly Desktop 開始支持 Codex","2026-05-16T13:01:00+00:00",{"slug":32,"title":33,"date":36},[43],"zh",1788492750379]