AI 進企業系統的正確切入口：設計態與執行態應該分開

「一個視窗通吃」聽起來省事，出事時沒人簽字

專案彙報常有一句：「我們要一個助手，既能用自然語言配流程，又能隨口問經營數。」演示很炫：改個不合格品處置流、再問上月不良最高的三家供應商，同一個對話方塊搞定。IT 事後才發現權限矩陣攤不開——誰確認了配置變更？答案對應哪些原始單據？看見的工廠資料有沒有越權？責任一扯，「是 AI 建議的」成了誰都不想接的灰盒子。

企業裡 AI 專案翻車，很少是因為模型不夠聰明，而是把它放在了錯誤的位置：同時承擔「構建系統」和「判斷經營」。模型建錯了，改一下再發布；決策判斷錯了，貨已發、款已付、投訴已上門。錯誤代價不對稱，就不能共用同一套入口、權限與審計設計。把「方便」當成「正確」時，審計與回滾會最先崩。這不是產品包裝話術，而是平臺能力頁寫明的結構——配置與權限仍在設計側完成；執行態問數與辦理只使用已發布的頁面權限，不直寫庫；兩者不是同一個聊天視窗。切入點選錯，後面換模型也救不回來。先把職責邊界立住，再談模型能力清單——邊界先於引數，也先於任何演示話術。

兩類職責：一個改配置，一個在授權內問數與辦理

按「雙智慧體」分工來理解，比按大模型能力清單更穩。

設計側（落地）：服務實施、業務與二開。用自然語言建/改應用、模型、表單、報表、流程與頁面；產出的是可進入設計器繼續調整的真實物件，不是一段無法落地的說明文字。例如描述「不合格品處置：發現—評審—返工/報廢/讓步—審批—關閉」，系統給出結構化草案，人確認後進設計器微調再發布。

問數側（問數與辦理）服務管理層與業務負責人。在已上線系統裡問數、看異常、給建議；建立單據與辦理稽核走業務介面，不超過本人頁面權限，不改配置、不直寫庫。例如「上月來料不良率最高的三家供應商及主要不良項」，答案必須能下鑽到原始記錄。

只會吐文字、還要實施人員在設計器裡重做一遍的「助手」，只是聊天，不是設計側。合格鏈路是：自然語言描述意圖與約束 → 生成可開啟的物件草稿 → 人在設計器核對邊界（並行、回退、加簽等）→ 確認釋出並寫入變更審計。當場驗證很具體：用你們最複雜的變更或不合格品流程描述一遍，看生成物能否直接進設計器繼續改，而不是複製貼上到別處。

問數的價值也不在「答得像諮詢顧問」，而在答案與業務單據可互證：關鍵數字能點到明細；時間、組織、口徑版本可見；不足以支撐決策時明說，而不是編一個完整結論。管理層真正怕的不是答不上來，而是答錯了還顯得很有把握。口徑字典未凍結時，「專業口吻」只會把互相矛盾的指標縫成看似統一的故事——這比答不上來更傷信任。

掛在引擎上，而不是懸空聊天

智慧體是加速層，不替代組織、權限、表單、流程、報表與整合任一引擎。設計側可輔助生成表單與流程物件，但釋出前必須在設計器複核；執行態對已上線業務庫問數，答案應能落到具體表與行，不私自改指標定義，也不繞過行級權限；建立單據與辦理稽核只經業務介面，不超過本人在頁面上能做的事，不直寫資料庫，不自動代他人審批，不改主資料。組織與權限變更後，可見範圍須隨任職生效，避免「人已調崗、助手仍按舊組織取數」。任取一次「自然語言生成的流程」和一次「問數或辦理」，若分別答不清「誰確認發布」「答案對應哪些記錄」「稽核是否仍是本人權限」，就不應進生產。

三條底線是治理要求，不是模型引數：

1. 不直接改生產資料——寫操作只經業務介面，且不超過本人頁面權限，禁止模型自由裁量或直寫資料庫。
2. 不繞過權限——可見範圍與使用者本人一致；自然語言若能問出越權資料，就是洩露通道。
3. 不脫離審計——每次生成與確認留痕，能回答「誰確認的改動」「數字根據哪些記錄」。

這三條寫進位制度與系統門禁之前，試點範圍寧可偏小。常見失敗模式一眼可辨：職責混用導致權限無法收斂；無確認直接生效讓錯誤放大；答案不可溯源最終棄用；權限放大成洩露；口徑未統一就上問數，答案專業但錯誤；借問數通道「順便改審批人」繞過變更閘門。把失敗模式貼在專案章程裡，比事後追責便宜。

先人在環，後問數：順序比模型版本重要

建議大致按九十天排：前三十天選一兩個表單/流程場景，強制「生成 → 人確認 → 設計器調整 → 釋出」，用交付週期對比與變更可審計作完成標誌；中三十天補口徑字典、主資料唯一性與權限矩陣，關掉「萬能聊天」入口；後三十天僅對已上線報表域開放問數，強制下鑽與權限繼承，且未發生越權事件。試點場景也有講究：設計側優先選流程複雜但規則相對穩定的單據（變更、不合格品處置、讓步接收），不要一上來啃主資料重構；問數優先選口徑已凍結的質量或交付指標，不要讓模型去「統一」每週還在改定義的 KPI。擴大組織範圍前，先完成權限抽檢與指標臺賬基線——模型幻覺式答案一旦進經營會，後面再糾偏成本極高。

賬號分冊比共用高權限令牌做問數更安全；長期共用令牌，權限繼承與審計都會失真。設計側草稿與釋出必須分離，禁止聊天草稿直接覆蓋生產版本。問數側只能消費已釋出指標，不能私自改指標定義——改定義仍走設計器與釋出閘門。

還不到視窗時，寧可晚一個月

主資料未統一（同一物料多個編碼）、權限體系說不清、沒有留痕機制、業務規則每週在變、報表口徑尚未凍結、或把 AI 當驗收替代品指望它「猜對需求」——這些情況下引入智慧體，只會更快放大混亂。連人都管不清可見範圍時，助手只會把越權問得更順口。一句話自檢：離開助手，你們是否仍說不清「誰能改配置、誰能看哪些數、數字從哪張單來」？答不清就還不到上線視窗。寧可晚一個月開放問數，也不要用一次答錯毀掉管理層信任。

人機分工要寫進位制度：助手給草案與線索，人做判斷與擔責。權限矩陣寫不清，雙智慧體很快會退化成「誰都能聊、誰都難追責」的灰盒子。JEDP數字化平臺把雙智慧體寫成設計態負責落地、執行態負責問數與辦理——配置與權限仍在設計態完成——選型時可直接對照：兩個入口、兩套權限、兩套審計，而不是一個炫酷對話方塊。

下一場演示只問三句話

採購與資訊化選型時，別被「對話式全能助手」帶跑。讓對方演示你們最複雜的一條變更或不合格品流程：產物能否進設計器繼續改？再問一條已上線指標：答案能否下鑽到原始單據？最後問一次越權請求：是否被拒絕且可審計？三句過不去，模型再新也不進生產。若對方堅持一個聊天視窗同時改配置又問經營數，直接要求看兩套權限矩陣與兩套審計日誌——答不清就說明職責邊界還沒設計完。邊界清楚了，能力才有地方用力；邊界糊塗時，能力只會加速翻車。職責分離不是口號，是上線門檻。兩個入口、兩套權限、兩套審計——少一條都別急著全廠推廣。

• JEDP 平臺能力：雙智慧體
• 雙智慧體詳情：設計態與執行態
• 平臺與雙智慧體沙箱試用
• 資訊化選型打分表（免留資）