AI Capability
AI 不是加在系統外面的一個功能，
是資料流本身
多數「導入 AI」的失敗，不是模型不夠好，是資料根本沒串起來。點餐一套、廚房一套、庫存一套、設備又一套， 每一套都只看得到自己那一段，AI 拿到片面資料，給出的建議自然比店長的直覺還糟。
這頁講的是我們怎麼處理這件事，以及為什麼這樣選。功能清單誰都列得出來， 講清楚取捨與代價才是技術能量。
四層能力，缺一層前面都白做
由下而上，每一層都依賴前一層的品質。
先讓事件流進來，AI 才有東西可想
門市的資料散在點餐、廚房、庫存與設備四個地方，格式與更新頻率都不一樣。我們做的是事件驅動的匯流層：訂單成立、出餐完成、庫存異動、設備開關門與溫度回報，全部標準化成同一種事件送進同一條流。
沒有這一層，後面的預測與問答都只能拿到某一個系統的片面資料，講出來的答案會比人工判斷還糟。
把營運資料變成可以用問的
店長要的是「上週哪個時段最容易缺貨」，不是一張報表。這一層把自然語言的問題對應到實際的資料結構，再把查詢結果組回人話。難的不是產生查詢語句，是欄位命名跟真實語意常常對不上——這需要一份維護中的語意映射，不是接上模型就會通。
設計上，模型看得到資料的結構，看不到原始資料本身。
異常要即時抓，需求要提前算
兩種推論的節奏完全不同。異常偵測是連續的：溫度飄移、訂單量突然斷掉、設備回報停止，發生當下就要有人知道。需求預測是週期的：把歷史銷售與外部變數一起算，給出下一段時間的備貨方向。
預測給的是方向與區間，不是保證值。把預測講成承諾，是這類系統最常見的失信來源。
會用的人不一定會打字
第一線是中高齡員工與外籍同仁，介面越複雜，實際使用率越低。這一層做的是語音問答與多語言介面，把 SOP 與作業知識整理成可檢索的形式，讓人用問的就能拿到答案，而不是翻紙本手冊。
知識要先被萃取出來才有得檢索——這件事的瓶頸從來不是技術，是有沒有人願意把老師傅的做法講出來。
三個設計上的取捨
每一個選擇都有代價，寫出來才叫負責。
推論集中在雲端，門市端不放 AI 硬體
門市端放推論硬體，就要面對數百個點位的維護、故障與版本不一致。集中在雲端只需要維護一套。
代價：代價是對網路的依賴變高，所以斷線行為必須先設計好（見 03）。
模型看資料結構，不看原始資料
要回答營運問題，模型需要知道有哪些欄位、彼此怎麼關聯，不需要知道每一筆交易的內容。把原始資料送進模型，是把風險換成一點方便。
代價：代價是語意映射要人工維護，欄位改名就要跟著改，不能全自動。
斷線的時候，門市要能繼續做生意
網路斷掉不能變成不能出餐。核心交易流程在本地完成，AI 提供的是建議與洞察，屬於可降級的部分。
代價：代價是要明確切分「什麼是必要功能、什麼是加值功能」，並在斷線時誠實告訴使用者哪些暫時不可用。
這些能力怎麼落到設備上
我們同時做設備與系統，所以設備不只是終端，它本身就是資料來源。
取餐與販售設備
開關門、取貨完成、庫存扣減與溫度回報，都是事件來源，也是異常偵測的觸發點。
溫控與效期
溫度與效期資料進到同一條流，超出設定範圍時可即時告警，紀錄也可作為稽核依據。
補貨節奏
銷售資料回推補貨頻率與品項結構，讓補貨從固定班表變成依實際消耗調整。
常被問到的四件事
這套能力需要換掉現有的 POS 或 ERP 嗎？
不需要，而且我們的設計前提就是不換。匯流層走事件與 API，對接既有系統；能不能接、接到什麼程度，要看對方系統開放哪些介面，這是導入前要先確認的第一件事。
資料會被送到模型供應商去訓練嗎？
不會。設計上模型取得的是資料結構而非原始資料，且不作為訓練用途。實際的資料流向、保存位置與保存期限，會在導入前以書面確認。
多久看得到效果？
這要看資料的完整度，不是看系統本身。若既有系統的資料是斷的、欄位命名混亂，前期會花在把資料整理成可用狀態。我們不承諾時程數字，會在盤點完你的系統現況後給實際的評估。
加盟體系怎麼處理資料權限？
總部與加盟主看到的範圍必須切開：總部看得到跨店的彙總與趨勢，單店看得到自己的營運資料。這個切分要在導入前就談定，事後再切通常會變成爭議。