企業級 AI 應用建設的 4 大難題：試點很成功，推廣卻熄火

難題一：資料散，巧婦難為無米之炊

一次月度質量評審，質量經理報上月的來料不良率是 2.3%，採購經理當場反駁說他的口徑下是 4.1%。兩個人吵了十分鐘才發現都對：一個按批次算，一個按採購金額算；一個取 QMS 的檢驗結論，一個取 ERP 的退貨記錄。資料都在系統裡，只是從來沒有被對齊過。

這類爭論在人的會議上是十分鐘，在 AI 面前會被放大成一種更麻煩的形態：它不會說「你們口徑不一致」，而是會把兩個數字縫成一個看起來完整、讀起來順口的結論——比如取了一個中間值，再配上一段關於「整體質量穩中向好」的表述。管理人員看到的是一個自信的答案，而不是一場沒吵完的架。一個自信但錯誤的答案，比一句「我不知道」傷害大得多，因為它會被當成依據繼續用下去，一直用到某個客戶投訴把它翻出來。

所以對 AI 來說，「資料散」不是可以邊用邊補的小毛病，而是一道准入題。製造業的資料通常散在 ERP、MES、QMS、WMS、Excel 和紙質單據之間：同一物料多個編碼，同一客戶多個簡稱，同一指標多套演算法，同一份單據在不同系統裡狀態不同步。模型能力再強，也無法從矛盾輸入裡推出可信輸出——它沒有額外的資訊源，只能在你給的素材裡打磨出一個最像答案的東西。

當場自檢：不看系統、不問人，能不能說清「上月來料不良率」這個數字來自哪張單、按哪個口徑、覆蓋哪些組織？如果回答這個問題需要三個人湊在一起對口徑，那 AI 上線只是把這場爭論加速了——它會把三個答案同時呈現出來，還都帶著確信的語氣。

務實的做法是先做兩件不出彩的事：主資料的唯一來源，以及指標口徑字典（誰定義、何時生效、變更留痕）。然後讓 AI 只消費已經凍結的口徑。這一步沒有捷徑，也不存在哪個模型能替你跳過。跳過它的專案，通常會在半年後繞回來補，只是那時預算和耐心都已經消耗掉一部分了。

難題二：不懂行，通用模型答非所問

把一起客訴的經過貼給通用大模型，讓它「幫我分析原因」，得到的通常是一份漂亮的通用模板：先確認問題描述、再分析可能原因、最後制定糾正措施並跟蹤驗證。流程沒錯，用不上——因為你們真正需要知道的是：這是本月同一工序的第二起，上一起的糾正措施還在驗證期沒關閉，而客戶在三個月前剛提過同類特殊要求。這三條都在你們的系統裡，模型一條也不知道。

模型掌握的是語言規律，不是你的業務約束。它不知道你們廠的工序代號代表什麼，不知道 8D 裡的根本原因追到哪個顆粒度才算過去，不知道客戶特殊要求（CSR）臺賬裡寫著什麼，也不知道 IATF16949 對整改閉環在時間與證據上的稽核預期。這些知識不在公開語料裡，只能從企業自己的資料中來：制度檔案、SOP、歷史單據、不良代碼字典、客戶特殊要求臺賬、以往稽核的整改記錄。

關鍵在於注入的方式。把這些資料一股腦塞進上下文，得到的往往是更危險的東西——一個能引用專業術語、卻指不出出處的回答。它比通用模板更像是內行說的，因此更難被當場質疑，也更難事後糾錯。合格的產業知識注入必須可檢索、可引用：回答能說出這句話依據的是哪份檔案的哪一版、哪一批單據，讓人可以順著線索自己去核。

這裡正好用得上一個判斷原則：錯誤代價不對稱。AI 生成一份生產資料清單，錯了改一次；AI 給出一個質量判斷，錯了可能已經放行了一批貨。所以產業場景裡更穩的分工是——AI 負責把三小時的翻檔案壓縮到三分鐘，給出候選與線索；判斷與簽字仍然留給人。它不替你做結論，只讓你在做結論前少翻幾箱紙。

當場自檢：拿你們內部一個真實的術語或不良代碼去問它，看它是答對了，還是編了一個聽起來很合理的解釋。這一問能很快分出「懂行」和「像懂行」。連這一步都答不準的話，它在評審會上幫不上忙，只會給會議多貢獻一段需要被糾正的內容。

難題三：不落地，智慧體停在對話框

試點階段做了問答機器人和文件總結，反饋還不錯。演示了兩個月，後臺訪問記錄掉到個位數。原因通常不是不好用，而是它不在任何人的工作路徑上——要用它，得先想起來有個對話框，再切過去，再組織好怎麼問。這三步中的任何一步，都足夠讓人回到原來那套辦法去。

企業軟體的使用從來是被流程推著走的：待辦不辦會超期，單據不稽核就流不下去，報工不填月結過不去。掛在流程上的功能，不用人記得它；只在對話框裡等著的功能，永遠排在「等等再說」那一欄。

檢驗標準可以非常簡單：這個 AI 功能停掉一週，會不會有人來找你恢復？沒人來，就說明它還沒進流程。這個問題比任何使用率報表都準，因為它問的是依賴，不是興趣。

能真正落地的形態，是嵌進既有節點，而不是另開一個入口。製造業裡幾個具體的例子：不合格品評審單開啟時，自動帶出同類歷史 NCR 以及當時採用的處置方式和最終結果；來料檢驗錄入前，帶出該供應商近 90 天的不良走勢與尚未關閉的 8D 單；生產報工提交時，對超出歷史波動範圍的數值給出提示與可能原因；變更單提交時，列出與本次變更相關聯的在途變更，避免改一處漏三處。這些形態有個共同點——使用者不需要「去問 AI」，AI 出現在他本來就要操作的那一步；它給出的是可核對的候選與線索，不是替他拍板的結論。

順帶劃清邊界：智慧體是加速層，不替代組織、權限、表單、流程、報表與整合裡的任何一環。它可以推待辦、給提示，也可在本人權限內經業務介面建立單據、辦理稽核；不自動代他人審批，不改主資料，不越過行級權限，不直寫資料庫。把它當成第 N 個業務模組會更清楚——它有明確的輸入、明確的邊界、明確的責任人，而不是一個什麼都能問的視窗。

當場自檢：列出你最常用的三個業務動作，問自己 AI 有沒有出現在其中任何一步上。如果只在第四個「不知道找誰的時候」才想起來用它，那它還沒落地，只是多了一個可選的聊天入口。

難題四：算不清，三筆賬過不了立項

前兩道坎過了，第三道也做了，最後往往卡在會議室裡。不是技術問題，是三筆賬沒人能當場算清。

安全賬——資料能不能出企業。哪些欄位允許走外部模型、哪些必須留在內網、呼叫外部能力時留了什麼樣的記錄。這道題最容易拖到最後才想，而它一旦結論是「不能出」，前面按外部模型做的方案就要推翻重做。早問一個月，省下的往往是整個工期。

責任賬——AI 給的建議導致一次錯判，誰擔責。如果回答是「AI 建議的」，這個專案就不該上線，因為那等於沒人負責。可接受的設計是：AI 只在人做決定之前提供線索，決定與簽字仍由人完成，並且每次生成與採納都留痕，能夠回答「誰在什麼時候、依據哪份知識、做了什麼決定」。留痕不是為了追責，而是為了讓所有人敢用。

ROI 賬——這筆賬最容易算糊。把收益寫成「效率提升 30%」是無法取證的，驗收會上必然吵起來，而且吵到最後通常不是輸在收益不夠，是輸在說不清。能過關的寫法是把收益落到可取證的四類上：人力工時、報廢與返工、稽核與合規成本、交付與現金週期，每一類都說清改進前後各自的取證方式。取不到證的收益，再動人也不要寫進立項材料。

三筆賬裡只要有一筆算不清，專案就過不了立項；勉強上了，也過不了驗收。這三筆賬還有個共同特點：它們都不在演示裡，所以最容易被跳過，也最容易在結項時一次性找回來。

當場自檢（安全賬）：列出你們最敏感的五個欄位，看現在的方案有沒有明確它們能不能出境、由誰批准、記錄留在哪裡。

當場自檢（責任賬）：假設 AI 的一次錯誤建議導致了一批誤判，你們能不能在兩小時內定位到是哪個版本的知識、哪一批資料導致的？答不出來，說明留痕還沒設計。

當場自檢（ROI 賬）：把預期收益逐條問「這條怎麼取證」。凡是答不出取證方式的那幾條，直接從收益表裡劃掉——早劃掉，比在驗收會上被人替你劃掉要好。

順序錯了白花錢：四道坎有先後

這四道坎不是四個可以隨便挑的選題，它們之間是有依賴的順序：資料與口徑不統一，餵進去的就是矛盾輸入；知識不可溯源，越懂行的回答越危險；沒進流程，再準也沒人用；三筆賬算不清，前面三條做得再好也過不了立項。任何一環跳過，後面都要回頭補。

最常見的翻車姿勢恰好是把順序倒過來：先買了模型和平台，再回頭補資料與口徑。預算是花在看得見的部分，卡住的是看不見的部分，半年後專案被打上「AI 不成熟」的標籤擱置。真實原因往往不是 AI 不成熟，而是順序錯了——而且這個錯誤的成本，最後會算在 AI 頭上，讓下一次立項更難。

還有一句務實的話值得放在專案章程裡：四道坎沒過第二道時，寧可晚半年上經營問數，也不要用一次答錯消耗掉管理層的信任。信任是一次性資源，用一次錯答案換來的教訓，比多等三個月貴得多——而且它消耗的不只是這個專案，還有下一次申請預算時的信用額度。

順序對了，也不用等到全部準備完畢才動。更可行的做法是讓 AI 先在低代價場景裡跑起來（輔助錄單、相似案例檢索、欄位校驗），用真實使用記錄去暴露資料最亂的環節，反過來推動口徑治理。兩條線互相推著走，比等一個完美起點更接近落地。

JEDP 數字化平臺把這件事寫在產品結構裡，而不是留到方案彙報裡再解釋：AI 作為加速層掛在既有引擎之上，設計側的生成必須經人確認才生效，執行態問數只消費已經凍結的口徑；建立單據與辦理稽核只經業務介面，不超過本人權限，全程留痕，權限繼承使用者本人範圍而不額外放大可見資料。選型時可以直接拿這四條去對照——如果對方講不清楚一個提問者能看到哪些資料、答錯了怎麼定位，那說明這四道坎他們還沒走過。

• JEDP 平臺能力：雙智慧體
• AI 進企業系統的正確切入口：設計態與執行態應該分開
• 資訊化選型打分表（免留資自測）
• 平臺與雙智慧體沙箱試用