AI 进企业系统的正确切入口：设计态与运行态应该分开
让一个 AI 既帮你建业务模型、又替你判断经营数据，听起来很强大。但它一旦出错，代价完全不对称——建模错了可以改，决策错了钱已经花出去了。
读这一篇能得到什么
- 企业 AI 落地的关键不是模型能力，而是职责边界与错误代价的匹配
- 设计侧负责生成配置、由人确认后发布；运行态在本人权限内问数、导出，并经接口办理
- 两者必须分离，因为它们对权限、审计与可回溯性的要求完全不同
- 落地建议先做人在环的配置加速，数据治理到位后再推进经营问数
- 三条不可触碰的底线——写操作只经业务接口且不越权、不绕过权限、不脱离审计留痕
「一个窗口通吃」听起来省事，出事时没人签字
项目汇报常有一句：「我们要一个助手，既能用自然语言配流程，又能随口问经营数。」演示很炫：改个不合格品处置流、再问上月不良最高的三家供应商，同一个对话框搞定。IT 事后才发现权限矩阵摊不开——谁确认了配置变更？答案对应哪些原始单据？看见的工厂数据有没有越权？责任一扯，「是 AI 建议的」成了谁都不想接的灰盒子。
企业里 AI 项目翻车，很少是因为模型不够聪明，而是把它放在了错误的位置：同时承担「构建系统」和「判断经营」。模型建错了，改一下再发布；决策判断错了，货已发、款已付、投诉已上门。错误代价不对称，就不能共用同一套入口、权限与审计设计。把「方便」当成「正确」时，审计与回滚会最先崩。这不是产品包装话术，而是平台能力页写明的结构——配置与权限仍在设计侧完成；运行态问数与办理只使用已发布的页面权限，不直写库；两者不是同一个聊天窗口。切入点选错，后面换模型也救不回来。先把职责边界立住，再谈模型能力清单——边界先于参数，也先于任何演示话术。
两类职责：一个改配置，一个在授权内问数与办理
按「双智能体」分工来理解，比按大模型能力清单更稳。
设计侧（落地）：服务实施、业务与二开。用自然语言建/改应用、模型、表单、报表、流程与页面；产出的是可进入设计器继续调整的真实对象，不是一段无法落地的说明文字。例如描述「不合格品处置：发现—评审—返工/报废/让步—审批—关闭」，系统给出结构化草案，人确认后进设计器微调再发布。
问数侧（问数与办理）服务管理层与业务负责人。在已上线系统里问数、看异常、给建议；创建单据与办理审核走业务接口，不超过本人页面权限，不改配置、不直写库。例如「上月来料不良率最高的三家供应商及主要不良项」，答案必须能下钻到原始记录。
| 维度 | 设计侧 | 问数侧 |
|---|---|---|
| 谁用 | 实施、业务、二开 | 管理层、业务负责人 |
| 输出 | 可进设计器的对象草案 | 问数导出，以及经接口写入的单据或审核结果 |
| 人确认 | 必须，发布才生效 | 问数须可溯源；办理即本人的一次操作 |
| 权限 | 设计与配置权 | 继承本人页面权限；问数不越权，办理不越过节点 |
| 审计 | 谁确认了哪次变更 | 问了什么、办了什么、数据范围 |
| 错误代价 | 相对低，可改后重发 | 相对高，可能影响资金与承诺 |
只会吐文字、还要实施人员在设计器里重做一遍的「助手」，只是聊天，不是设计侧。合格链路是：自然语言描述意图与约束 → 生成可打开的对象草稿 → 人在设计器核对边界（并行、回退、加签等）→ 确认发布并写入变更审计。当场验证很具体：用你们最复杂的变更或不合格品流程描述一遍，看生成物能否直接进设计器继续改，而不是复制粘贴到别处。
问数的价值也不在「答得像咨询顾问」，而在答案与业务单据可互证：关键数字能点到明细；时间、组织、口径版本可见；不足以支撑决策时明说，而不是编一个完整结论。管理层真正怕的不是答不上来，而是答错了还显得很有把握。口径字典未冻结时，「专业口吻」只会把互相矛盾的指标缝成看似统一的故事——这比答不上来更伤信任。
挂在引擎上，而不是悬空聊天
智能体是加速层，不替代组织、权限、表单、流程、报表与集成任一引擎。设计侧可辅助生成表单与流程对象，但发布前必须在设计器复核。运行态对已上线业务库问数，答案应能落到具体表与行，不私自改指标定义，也不绕过行级权限；创建单据与办理审核只经业务接口，不超过本人在页面上能做的事，不直写数据库，不自动代他人审批，不改主数据。组织与权限变更后，可见范围须随任职生效，避免「人已调岗、助手仍按旧组织取数」。任取一次「自然语言生成的流程」和一次「问数或办理」，若分别答不清「谁确认发布」「答案对应哪些记录」「审核是否仍是本人权限」，就不应进生产。
三条底线是治理要求，不是模型参数：
- 不直接改生产数据——写操作只经业务接口，且不超过本人页面权限，禁止模型自由裁量或直写数据库。
- 不绕过权限——可见范围与使用者本人一致；自然语言若能问出越权数据，就是泄露通道。
- 不脱离审计——每次生成与确认留痕，能回答「谁确认的改动」「数字根据哪些记录」。
这三条写进制度与系统门禁之前，试点范围宁可偏小。常见失败模式一眼可辨：职责混用导致权限无法收敛；无确认直接生效让错误放大；答案不可溯源最终弃用；权限放大成泄露；口径未统一就上问数，答案专业但错误；借问数通道「顺便改审批人」绕过变更闸门。把失败模式贴在项目章程里，比事后追责便宜。
先人在环，后问数：顺序比模型版本重要
建议大致按九十天排：前三十天选一两个表单/流程场景，强制「生成 → 人确认 → 设计器调整 → 发布」，用交付周期对比与变更可审计作完成标志；中三十天补口径字典、主数据唯一性与权限矩阵，关掉「万能聊天」入口；后三十天仅对已上线报表域开放问数，强制下钻与权限继承，且未发生越权事件。试点场景也有讲究：设计侧优先选流程复杂但规则相对稳定的单据（变更、不合格品处置、让步接收），不要一上来啃主数据重构；问数优先选口径已冻结的质量或交付指标，不要让模型去「统一」每周还在改定义的 KPI。扩大组织范围前，先完成权限抽检与指标台账基线——模型幻觉式答案一旦进经营会，后面再纠偏成本极高。
| 角色 | 建议开通 | 明确禁止 |
|---|---|---|
| 实施 / 二开 | 生成与草稿编辑 | 跳过确认直接发布生产 |
| 业务关键用户 | 有限范围的草稿确认 | 扩大到全租户配置权 |
| 管理层 | 继承本人范围的问数 | 借问数通道改配置 |
| 审计 / IT | 只读审计与发布记录 | 用管理员账号代问业务数 |
账号分册比共用高权限令牌做问数更安全；长期共用令牌，权限继承与审计都会失真。设计侧草稿与发布必须分离，禁止聊天草稿直接覆盖生产版本。问数侧只能消费已发布指标，不能私自改指标定义——改定义仍走设计器与发布闸门。
还不到窗口时，宁可晚一个月
主数据未统一（同一物料多个编码）、权限体系说不清、没有留痕机制、业务规则每周在变、报表口径尚未冻结、或把 AI 当验收替代品指望它「猜对需求」——这些情况下引入智能体，只会更快放大混乱。连人都管不清可见范围时，助手只会把越权问得更顺口。一句话自检：离开助手，你们是否仍说不清「谁能改配置、谁能看哪些数、数字从哪张单来」？答不清就还不到上线窗口。宁可晚一个月开放问数，也不要用一次答错毁掉管理层信任。
人机分工要写进制度：助手给草案与线索，人做判断与担责。权限矩阵写不清，双智能体很快会退化成「谁都能聊、谁都难追责」的灰盒子。JEDP数字化平台把双智能体写成设计态负责落地、运行态负责问数与办理——配置与权限仍在设计态完成——选型时可直接对照：两个入口、两套权限、两套审计，而不是一个炫酷对话框。
下一场演示只问三句话
采购与信息化选型时，别被「对话式全能助手」带跑。让对方演示你们最复杂的一条变更或不合格品流程：产物能否进设计器继续改？再问一条已上线指标：答案能否下钻到原始单据？最后问一次越权请求：是否被拒绝且可审计？三句过不去，模型再新也不进生产。若对方坚持一个聊天窗口同时改配置又问经营数，直接要求看两套权限矩阵与两套审计日志——答不清就说明职责边界还没设计完。边界清楚了，能力才有地方用力；边界糊涂时，能力只会加速翻车。职责分离不是口号，是上线门槛。两个入口、两套权限、两套审计——少一条都别急着全厂推广。
想把这篇里的做法落到自己的厂里？资源中心有对应场景的在线自测与资料模板，也可以直接约一次真实环境演示。
常见问题
围绕本篇主题的追问，先看这里；仍有疑问可联系我们
设计侧会不会生成错误的模型？
会，所以流程必须是「生成建议 + 人工确认后生效」。它降低的是建模的起步成本与遗漏风险，不替代人的判断。所有生成的变更都要留痕，可追溯到是谁确认的。
问数答错了怎么办？
两条措施——一是回答必须能下钻到原始记录，让使用者可以自行核对；二是权限继承使用者的数据范围，不额外扩大可见数据。回答若无法溯源，就不应作为决策依据。
先上配置加速还是先上问数？
建议先做人在环的配置辅助。风险低，收益直接体现为交付周期缩短。问数对数据质量与口径统一依赖更强，前置条件不足时容易答错。
智能体会不会取代配置人员？
短期内不会。它更像一个熟练的助手，能快速给出草案、指出遗漏、减少重复劳动，但业务判断、边界确认与责任承担仍在人身上。
一个聊天窗口能不能同时做建模和问数？
不建议。表面省事，实际会把配置权限与经营数据可见范围搅在一起，审计与回滚都做不清。平台侧应坚持分入口。