政策訊號：AI正在從展示型專案轉向生產系統能力
上海市經濟和資訊化委員會於2026年7月釋出進一步推動“AI+製造”的相關措施，重點覆蓋工業垂類大模型、工業智慧體、物理AI、工業軟體、工業網際網路等方向。國家層面的“人工智慧+製造”專項行動也明確提出，以場景牽引、安全可信和產業智慧化為原則，推動人工智慧進入研發、中試、生產、質檢、運維、供應鏈和經營管理。
這意味著製造企業的AI專案不能只以“完成一個問答助手”作為目標。更有價值的建設方式，是把AI嵌入生產經營閉環，讓它能夠讀取可信資料、理解業務約束、提出建議、觸發受控動作，並透過結果反饋持續最佳化。
- 研發環節：知識檢索、設計輔助、文件與規範檢查
- 生產環節：排產輔助、工藝分析、異常診斷與質量預測
- 裝置環節：智慧巡檢、故障識別、預測性維護與工單協同
- 經營環節：訂單分析、庫存預警、供應鏈協同與經營預測
不要從“模型能力”出發，要從生產瓶頸出發
製造現場的高價值問題通常隱藏在交付週期、良率、停機時間、庫存、能耗和人工經驗中。企業應先找出影響經營結果的瓶頸，再判斷AI能否透過識別、預測、檢索、生成或任務編排改善這個瓶頸。
適合首批試點的場景通常具備四個條件：業務頻率高、歷史資料可獲得、人工判斷規則能夠被描述、結果可以量化。對於資料稀少、責任風險高或工藝仍頻繁變化的場景，應先做數字化補課或採用輔助決策模式。
- 把“建設工業智慧體”改寫成明確的業務指標
- 記錄當前基線，例如平均停機時長、質檢耗時和異常閉環週期
- 區分建議型、審批型和自動執行型場景
- 優先選擇90天內能夠完成閉環驗證的切入點
工業智慧體的底座是資料、知識與IT/OT連線
工業智慧體需要同時理解裝置狀態、工藝引數、產品標準、歷史故障、生產計劃和人員許可權。這些資訊往往分散在PLC、SCADA、MES、ERP、QMS、WMS、文件系統和個人經驗中。如果沒有統一的資料語義與介面，智慧體只能停留在孤立問答。
建設時應明確資料權威來源、採集頻率、質量規則和訪問許可權，並透過API、訊息、邊緣閘道器或資料平臺連線系統。知識庫需要保留文件版本、適用產線和審批狀態，實時資料則要考慮時序、延遲、缺失和異常值。
- 統一裝置、物料、工單、工藝和質量問題的關鍵編碼
- 為實時資料、業務資料和文件知識設計不同接入方式
- 將許可權從原系統繼承到AI應用，避免跨角色越權
- 建立資料血緣、更新時間和回答依據展示機制
把智慧體設計成受控協作者，而不是黑箱自動化
生產現場容錯空間有限。智慧體可以分析告警、檢索規程、生成處置建議或建立工單，但涉及修改工藝引數、停止裝置、調整排產和釋放質量結果時，需要明確授權等級與人工確認點。
建議把能力劃分為只讀查詢、輔助建議、受控執行和高風險禁止四級。每次工具呼叫都記錄發起人、輸入、依據、動作、結果和人工確認，失敗時能夠回退到人工流程。這樣才能讓效率提升與生產責任保持一致。
用小閉環試點驗證價值，再複製到產線和工廠
試點不應只做功能演示，而要使用真實班次、真實工單和真實異常進行驗證。上線前建立離線測試集，上線後觀察準確率、建議採納率、誤報漏報、人工節省時間、業務指標變化和單次任務成本。
當一個場景達到預設門檻後，再沉澱資料接入、許可權、評測、監控和釋出模板，擴充套件到相鄰裝置、產品或工廠。平臺化應該發生在可複製模式被驗證之後，而不是在第一個場景前先搭建大而全的平臺。
- 第1-2周：現場訪談、流程觀察與基線測量
- 第3-6周：資料接入、原型開發和離線評測
- 第7-10周：小範圍上線、人機協同與風險觀察
- 第11-12周：業務覆盤、驗收和複製決策
專案驗收要同時看業務、技術、安全與運營
工業AI專案的驗收不能只看頁面和功能清單。業務側要確認指標是否改善，技術側要確認效能、穩定性和介面質量，安全側要確認許可權、審計和應急機制，運營側要確認知識更新、模型評測和問題責任人。
對於外部實施或FDE合作專案，還應交付場景說明、資料字典、介面文件、評測集、測試報告、許可權矩陣、部署手冊、監控規則、培訓材料和迭代清單，避免系統上線後無人維護。
把上海AI+製造從閱讀結論變成專案輸入
閱讀方法文章之後，最容易出現的問題是認同原則，卻沒有把原則轉成下一步行動。建議由業務負責人組織一次60至90分鐘的小型工作會，只選擇一條真實流程，不急著討論完整平臺。參會人應包括實際執行者、結果使用者、系統或資料介面人，以及最終驗收負責人。
第一步：建立現狀與樣本基線
圍繞“政策訊號：AI正在從展示型專案轉向生產系統能力”抽取近期正常、異常和邊界任務，記錄每月處理量、等待時間、實際處理時間、返工率、人工觸點、錯誤後果和當前工具。資料不足時可以連續記錄一至兩週，但要註明樣本週期和業務波動。不要先設定一個好看的節省比例，再倒推資料。
第二步：明確首期閉環與不做事項
結合“不要從“模型能力”出發，要從生產瓶頸出發”寫出首期輸入、處理、輸出、使用角色和完成條件。把必須接入的系統、需要客戶提供的資料、不能自動處理的高風險事項和依賴第三方的條件分開列出。首期目標是讓一條鏈路連續執行並可複測，而不是把工業智慧體、製造業AI落地、FDE全部堆進同一版本。
第三步：把技術結果對應到工程證據
圍繞“工業智慧體的底座是資料、知識與IT/OT連線”建立需求編號、樣本編號、測試結果和版本之間的追蹤關係。AI專案還要儲存版本化評測集、提示或流程配置、模型與知識來源、人工修正記錄，以及低置信度、越權和失敗回退測試。不要只以一次演示是否生成正確答案作為上線依據。供應商演示應使用雙方確認的樣本；無法公開的生產資料可以脫敏，但不能完全用理想化測試資料代替真實條件。
第四步：用相同口徑完成驗收和覆盤
結合“把智慧體設計成受控協作者，而不是黑箱自動化”預先約定觀察週期和質量底線。假設原流程每月處理600項任務，平均每項耗時20分鐘、返工率10%，目標可以按示例寫為“上線六週後，在任務複雜度相近的前提下，平均耗時降低25%，返工率不高於原基線”。這組數字僅演示測量方法，不代表任何客戶成果；正式指標必須由企業依據自身樣本確認。
- 業務材料：流程圖、角色、任務樣本、當前問題和基線資料
- 技術材料：系統清單、介面、資料許可權、部署環境和安全要求
- 專案材料：首期範圍、排除項、責任矩陣、里程碑和變更機制
- 驗收材料：測試集、執行記錄、缺陷清單、指標查詢和交接文件
當這些材料能夠被業務和技術雙方共同確認時，文章中的方法才真正進入專案。若關鍵資料、介面授權或負責人尚未到位，合理的下一步通常是限定範圍的診斷或PoC，而不是立即承諾完整工期和固定總價。
官方參考資料
- 上海市進一步推動“AI+製造”發展的若干措施上海市經濟和資訊化委員會 · 2026-07-17
- “人工智慧+製造”專項行動實施意見工業和資訊化部等八部門 · 2026-01-09
- 2026年“資料要素×”大賽賽題指南國家資料局等部門 · 2026-04-27
把方法落實到專案行動
- 從可量化的生產瓶頸出發，而不是從模型功能出發
- 資料、知識、IT/OT連線和許可權是工業智慧體的共同底座
- 先用受控小閉環驗證，再沉澱模板向更多產線複製
- 以業務、技術、安全和運營四組指標共同驗收
繼續核對專案決策中的常見問題
FDE外包與普通AI軟體開發有什麼區別？
FDE外包強調工程師深入業務任務，與使用者、資料、模型和現有系統共同推進落地。普通AI開發通常從較明確的功能需求開始，重點完成應用與介面。FDE更適合場景尚需發現、反饋頻繁或必須跨部門推動的專案。兩種方式並不衝突，FDE可以負責現場診斷和閉環，研發團隊負責平臺與工程實施。
檢視完整回答 →AI外包採購、報價與驗收企業AI應用開發應該先做PoC還是直接實施正式系統？
當模型效果、資料質量或系統條件尚未驗證時，應先做限定範圍的PoC；如果同類能力已在真實樣本上驗證，範圍、介面和驗收標準比較穩定，可以直接進入生產實施。PoC不是低配正式系統，而是回答關鍵不確定性。是否需要PoC，應根據未知項和錯誤成本決定，而不是所有專案機械增加一個階段。
檢視完整回答 →企業AI效果、安全與持續運營AI專案應該怎樣制定驗收指標？
AI專案不能只用“回答看起來不錯”驗收，也不宜承諾脫離資料範圍的百分之百準確。指標應同時覆蓋業務結果、模型效果、系統效能、安全許可權和人工兜底。測試集必須來自真實業務並按難度與風險分層。上線條件、觀察期和不達標處理方式應在開發前確認。
檢視完整回答 →企業AI轉型組織與實施企業AI轉型應該由業務部門還是IT部門負責？
企業AI轉型需要業務和IT共同負責，但責任不同。業務部門定義問題、知識口徑、真實樣本和最終結果，IT或技術團隊負責資料介面、身份許可權、架構、安全、釋出與運維。管理層負責場景優先順序、預算和跨部門決策。只由技術部門推進，容易做出沒人使用的工具；只由業務部門採購，又可能忽略系統和安全風險。
檢視完整回答 →需要結合企業現狀進一步分析？
我們提供 IT 技術諮詢、企業資訊化建設、軟體專案外包、產品設計、研發交付與系統運維服務。