AI 预填业务页面时，怎样保留员工核对和提交

「AI 预填业务页面」指的是 AI 在原业务页面里把能拿到的字段先填好，员工核对无误后自己点提交。这个做法省掉的是录入和来回查数据的时间，最后那一下决定仍然留在人手里。把预填和自动提交放在一起讨论，结果往往是要么迟迟不敢用，要么本该清楚的责任边界被弄模糊。这篇说明预填适合做到哪一步、哪些字段值得交给 AI、为什么页面回执才算结果，以及怎样用授权、确认点和调用审计把这条链路收紧。

预填和提交经常被当成一件事

业务部门提出的需求往往就是一句话：「这张单子能不能让 AI 自己填好、自己交掉」。IT 听到的是两件事，填好是准备，交掉是承诺。这两件事放在一起谈，问题就来了。

只做了自动提交、没有留下核对环节时，单据一旦带错价格或选错往来单位，从系统上翻记录只能看到一次成功写入，看不出当时是 AI 的判断还是人的判断。反过来，只做了预填、员工还得从零核对每个字段，省下来的时间有限，业务部门会觉得这东西没帮上忙。

分歧点在于哪一步算作决定。企业的做法通常是把这一步定得很明确：AI 负责把单子准备到员工只需要看一眼就能确认的程度，员工按下的那一下才算决定。这个边界定下来之后，预填的范围、确认点的位置、审计要记什么，都能顺着推下去。

一次预填里，系统实际做了哪几步

以一张 ERP 的销售订单为例，预填跑下来通常经过四步。

1. 提取：从员工的自然语言、上一张单据或者跨系统查询结果里，拿到客户、商品、数量、价格这些候选值。数据可能来自 ERP 本身，也可能来自 OA 里的审批记录或 WMS 的库存。
2. 校验：检查候选值在目标系统里是否成立，例如客户编码是否存在、商品是否已停售、库存是否够、价格是否落在这个客户的价目范围内。校验不通过应停下来，把不确定的值留给员工核对。
3. 填充：把值写进原业务页面的对应字段。员工看到的还是平时那个界面，系统不在旁边另造一个表单。
4. 停在提交前：字段填好后停住，把页面留给员工，提交按钮由员工自己按。

这四步里，前三步可按目标系统能力与授权范围配置为自动完成，第四步是这类预填方案的分界线。是否另行配置自动提交，需要单独评估业务风险与确认要求，不能把预填当成提交。

哪些字段适合交给 AI 预填

字段能不能预填，看的是出错以后好不好发现、好不好改。大致可以按下面几类来分。

表格里的分法不是硬规则。同一家企业里，一张内部领用单和一张对外销售合同的容忍度完全不同，具体填到哪一层要看业务能接受的返工成本。

分工怎么落到授权和确认配置上

预填能用的前提，是这次调用身份明确、权限范围清楚。连接器先判断当前员工能不能调用这项能力，目标系统再对功能权限和数据权限作最终判断，决定这次调用能看到哪些行、哪些字段。AI 拿到的是员工本来就有权看到的数据，预填出来的值也就落在员工职责范围内。

落到配置上，通常有这几个动作。

• 按员工或用户组授权，不把「全员可用」当初值，先用最小范围跑通再放宽。
• 把新增、修改、删除和审批设成必须确认，查询、校验和预填保持自动。
• 让预填走原业务页面。绕开页面直接写库，界面、校验规则和留痕就都不是原来那一套了。
• 审计记录员工与 AI 身份、调用入口、业务能力、目标系统、时间、耗时、结果和输入输出摘要，并支持查询与导出。审计保存期限由企业自己配置。

这一整套做下来，其实就回到那条常被提起的口径：不换系统、沿用员工权限、关键操作人确认、调用审计。四件事里少一件，预填这条链路都会在某个环节松掉。

几条容易被含糊过去的边界

页面预填不等于提交成功。 字段填进页面只是准备好了待提交的内容，是否真正生效，以页面回执或目标系统的结果为准。

不是所有外部页面都能填。 能不能预填、能填哪些字段，取决于目标系统的页面结构、接口能力和权限模型，具体范围以项目评估为准。

预填和自动化脚本走的不是一条路。 固定脚本与页面预填的实现方式不同。预填应沿用原页面的字段和校验规则；权限范围、异常字段与实际写入结果，仍须结合目标系统逐项验收。

确认点少了没意义，多了没效率。 每个字段都要确认，等于没做预填；只在最后一个高度概括的按钮上要求确认，又等于把责任押在一次点击上。确认点应当落在业务真正在意的那个字段或那个动作上。

上线前核对什么

下面几个动作都可以在实际产品能力演示中核对，演示使用演示或脱敏数据，不代表任何客户的上线成果。

• 用两个不同岗位的员工账号对同一张单据发起预填，确认可填字段与可查数据范围不同，差异来自目标系统的权限判断。
• 让 AI 预填一张单据，确认字段填好后没有自动提交，提交动作仍需员工本人触发。
• 故意让某个字段取到不存在的客户编码，核对系统是否提示并留空；如未拦截，应先修正配置或校验链路。
• 预填完成后由员工改掉两个字段再提交，确认改动被记录，页面回执与目标系统的结果一致。
• 从审计里检索这次调用，确认能定位到员工、入口、能力、目标和结果。
• 撤掉某名员工的授权，不刷新客户端直接发起一次预填，确认请求被服务端拒绝。

前两项在首个场景联调时就能查清，后几项偏配置与流程核查，要连着授权管理和审计一起看。

结语

预填把准备工作的成本压下来，决定权仍然留在员工手上。企业推进这类场景时，把提交这一步明确留给员工，反而更容易通过内部评审，也更容易在出问题时说清楚发生了什么。星云 PLUS AI 系统连接器做的事，是把已有数据、接口、业务页面、Skill 和 Agent 发布成可授权、可确认、可审计的业务能力，让 AI 沿用员工身份与权限工作。

下一步不必铺开。先选一张字段不多、结果容易核查的单据，把预填、确认点和审计跑通，再决定要不要扩到多系统联查或批量办理。具体接入范围、部署形态与实施周期，以项目评估为准。

常见问题

预填和 RPA 录单有什么区别？

部分 RPA 流程按页面坐标或固定规则录入，页面变化时需要维护。这里讨论的预填沿用原业务页面的字段与校验，并在调用时核对连接器授权和目标系统权限；具体差异取决于目标系统与实施方式。

员工核对太麻烦，能不能只对金额类字段确认？

确认点放在哪里由业务定，可按能力配置。一种可评估的做法是主数据和数量自动填，金额与结算条件强制确认，结论性文本留空由员工写。具体怎么分，要看这类单据出错以后的返工成本。

预填用了 AI，责任算谁的？

提交由员工触发；具体业务责任仍应按企业内部制度明确。系统这一侧要做的，是把这次调用的身份、权限范围和过程留成可查的记录。这也是为什么撤权、审计要和预填一起上线，等到出问题再补就晚了。

了解产品能力，可参阅AI 系统连接器与安全与治理。相关阅读：AI 超级账号风险、人机协作办公。