AI 审批助手不该只给问题清单：审批环节的 AI 要走到给结论这一步

审批人真正卡住的地方，不是不签字

e签宝是国内智能合同签管平台，AI 审批助手是这套底座嵌进审批流的一个节点，位置在审批单内部。一份三十页的销售合同走到总监那一步，审批单上只有金额、相对方和合同类型三个字段。付款条款在第三轮协商里被对方改过，附件里有比价单和补充协议。审批人想判断这份合同能不能签，只能把附件从头翻一遍。翻完之后他做两个动作之一：扫一眼金额点通过，或者打回让业务补充说明。前一个把风险留到履约阶段，后一个把时间还给了往来沟通。

这两种做法都不算失职，是审批单上呈现的信息不支持判断。合同审批的瓶颈从来不在授权，在于授权之前那一次没有工具支撑的阅读。

e签宝把 AI 审批助手做成了审批流里的一个节点。管理员在审批流设计里插入节点、勾选能力，合同流到该节点时系统自动执行，结论显示在审批单右侧的「AI 审批意见」。2026 年 9 月上线时它提供四项能力：主体一致性校验、合同摘要、合同比对、合同审查。到了 11 月 12 日，这四项之上加了四件事：核验关键信息、总结审批建议、问题原文定位、驳回意见一键插入。

这四件事的共同指向，是让审批人少做判断以外的动作。

从列问题到给结论，是一次产品成熟度分界

第一代 AI 审批助手的输出形态是问题清单。审查跑完给风险数量，比对跑完给差异条数，摘要给一段关键信息。审批人拿到的是原始判断材料，还需要自己把这些材料读成一个结论。

11 月 12 日的更新里，官方给出的背景写得很直白：原 AI 审批助手只展示问题项，审批人无法快速判断是否通过。这句话点出了第一代产品的天花板。AI 把该看的都看了，但把最费脑的那一步留给了人。

「总结 AI 审批建议」要解决的就是这一步。系统不再只报问题项，而是把问题读完给一段结论，审批人对着结论判断通过还是驳回。

这段变化值得单独拎出来看。AI 在合同场景里被期待的从来不是「审得更多」，是「审得动」。风险条目标红三十条，和给出「这份合同有三处需要修改，其余可签」，是两件完全不同的事。后者才对应审批人真实的决策动作。

三个能力的问题，收敛成一套阅读体验

第一代产品有一处结构性的别扭。审查、比对、核验各自输出结论，审批人要在三处之间来回切。同一条款在审查里标为高风险，在比对里标为已修改，在核验里标为金额不一致，三条信息分散在三个页签，人要自己拼。

11 月 12 日之后，三处的全部问题整合成卡片，标注对应原文，在合同原文上一一定位。官方对这个设计的解释同样直接：对用户来说不关心是什么能力带来的问题，只要是问题，他们都关心。

这句话背后是一个常被忽略的产品判断。能力是按技术模块划分的，问题不是。审批人面对的是一份合同和一堆要改的地方，他不会先想「这条是审查发现的还是比对发现的」。把输出按能力分栏，等于把系统的组织方式强加给使用者。

收敛成卡片还有一层效果：问题可以逐条处理。定位到原文、看清上下文、决定改还是不改，这条动作链完整之后，AI 的输出才会被真正用掉。再准的结论，只要需要人去别的页面找原文，使用率就会掉。

驳回意见空着，问题不在审批人

驳回是审批里最常见也最没有信息量的动作。审批人点驳回，系统弹一个输入框，很多人直接提交，或者写一句「请修改后再提交」。发起人收到一条没有内容的驳回，不知道该改哪一条，只能把合同重发一遍，或者打电话问。

11 月 12 日的更新里，官方对这个痛点的描述是：审批驳回时，用户基本不会输入驳回意见，或者随意输入文案；对发起人来说，无法通过驳回原因修改合同中的问题。

这不是审批人的态度问题。写一条准确的驳回意见，前提是他刚把三十页合同的问题在脑子里整理过一遍，还要组织成对方能照着改的语言。这个成本很高，高到多数人选择跳过。

现在的做法是按 AI 识别的问题自动生成审批意见，一键填入驳回框。审批人可以在生成的基础上修改，也可以直接提交。这一条改动小，但它把「驳回」从一个流程动作变成了信息传递。

主体校验升级成基础核验，管的是多文件一致性

第一代的主体一致性校验只核对签约主体。合同里除了当前企业之外还有哪些主体，这些主体是否与预期一致，解析失败时跳过。它回答的是「跟谁签」。

11 月 12 日这一项升级成「基础核验」。核验范围从主体扩展到当前合同流程中所有文件的签署方、日期、金额等关键信息，按合同类型区分核验项。官方给出的背景是企业希望对多文件下的这些信息做核验，看是否存在遗漏或不一致。

这个扩展对应的是真实业务形态。一份采购合同带上订单、比价单、技术协议三份附件，签署方名称在四份文件里出现四次，日期出现四次，金额出现三次。人工核对要逐份比对，任何一处不一致都会成为后续纠纷的起点。

核验的处理方式保留了原有的两档。选「仅提示」时，不一致或解析失败写入 AI 审批意见，审批继续由人工处理。选「拒绝」时优先执行核验，发现不一致或解析失败即拒绝本次审批，同一节点的其他 AI 能力不再执行。

选「拒绝」要清楚代价：一个刚性判断换来确定性，同时放弃了同一节点上其他能力的风险识别结果。这个取舍在合同类型差异大的企业里未必划算。

四项能力的执行边界，配置前必须知道

AI 节点跑在审批流上，它的工程约束决定了能承诺什么。几条边界在配置前值得先明确。

审查、比对、摘要失败或超时时，系统展示对应状态并继续流转，不阻断审批。只有基础核验配置为「拒绝」且结论异常时才会拦下流程。这个设计说明 AI 节点不能成为流程的单点故障——一份合同不该因为一次分析超时卡在审批里。

AI 节点之后的普通审批节点和抄送节点不会再次执行 AI，而是复用距离当前节点最近的前序结果。需要新的审查或比对结论，只能新增 AI 节点，这意味着同一份合同会被执行两次。

合同版本变化后，旧版本的 AI 结果作废。审批实例再次到达 AI 节点时，系统按最新合同版本和最新配置重新执行。这一条挡住了「改过的合同沿用改之前结论」的错位。

同一条审批流上，一项能力只能由一个 AI 审批助手执行。配置时如果某项能力无法勾选，先检查是否已被前序节点选用。

版本门槛是高级版及以上。2026 年 9 月上线时这项能力处于灰度，企业需要开通 AI 大数据协议，审查能力还需要提前维护好审查方案或使用系统自带方案。

生态不通，AI 的结论就没有落点

审批环节的 AI 能力有一个容易被忽略的前提：合同得先走到这个节点上。

企业的审批大多不在合同系统里发生。合同在钉钉、飞书或企业微信的审批单里流转，附件才是要签的文件。如果 AI 审批助手只存在于合同系统的网页端，业务的实际路径就变成在审批单里下载、去另一个系统上传、等结论、再回来补充说明。多出来的这几步，决定了 AI 会被用起来，还是被绕开。

e签宝把这一段做在审批单内部。2026 年 10 月 15 日的更新支持审批单「明细/表格」里的合同直接作为签署文件，模板关联审批表单后，「签署文件」可以直接选择明细里的附件，审批通过后自动带入签署，发起时可以勾选这次要签哪几份。

10 月 29 日的更新解决了附件直接签署的老问题。来源于审批单附件的纯流程模板此前打不开自动发起签署，原因是每份附件的盖章位置不一样，系统不知道该在哪盖。现在的做法是在签署方的签署设置里填写签署位置关键词，例如「甲方（盖章）」，系统在附件里找到这个词并自动放好签署区。

关键词的配置有一条明确边界：这个词要出现在附件里，并且只出现在盖章的位置。合同其他地方也有这个词时，那里也会被放上签署区。盖章处没有合适文字时，可以在那里填一段文字当关键词再把字体改成白色，合同上看不出来。

同一个日期还开放了审批单里直接点链接发起签署。模板里打开「发起签署链接回传」开关后，审批到签署环节时评论区自动出现「点击链接发起签署」，只有发起人能通过链接发起，发起后只有发起人、签署方和抄送人能查看。合同撤回或拒签后，同一个链接可以重新发起。

11 月 5 日的更新把飞书多维表接进发起环节。记录满足设定条件，系统就用对应合同模板自动发起，不需要人再点一次。配置分两步，先在合同模板的流程设置里打开自动发起签署开关，再在飞书多维表里创建自动化流程。自动发起时没有人填写签署方，所以签署方要在模板里提前设好。

接口这一侧同样有动作。10 月 22 日的更新支持把审批节点配置为外部系统，企业可以在开放平台注册应用并配置接收审批回调的服务，此后通过接口调用完成该节点的审批。有些合同的内部审批必须先在自有系统走完，这条能力省掉的是两个系统之间的状态搬运。

11 月 12 日的更新把钉钉、企业微信、飞书的签署发起人从单人放开到多人，最多十人。

这些能力串起来说明一件事：AI 审批助手的价值不在算法多强，在于它是否站在合同真正经过的那个节点上。一份合同如果从来没进过这个节点，再准的结论也用不上。

装在哪一格，决定它服务谁

同一套能力装在审批流的不同位置，服务的角色完全不同。

装在业务负责人审批之前，业务先看到摘要和差异，自查一遍再提交，问题在到达法务之前被处理掉。装在法务审批之前，法务拿到的是已经标注过的合同，注意力直接落在高风险项上。装在用印审批之前，比对的是审批通过版与对方签回版，防的是签回时被改条款。

位置选错不能靠多加节点弥补。AI 节点之后的节点复用前序结果，想在同一流程里对不同阶段做不同审查，只能增加 AI 节点，代价是同一份合同被执行两次。

一家企业如果法务只有两个人、业务线有八条，把节点放在业务负责人之前，等于用一次自动分析替代八条线各自的人工初筛。

上线前先定四件事

先定哪个流程先接。合同审批面向业务与法务的判断，用印审批面向最后一道核对，两者需要的 AI 能力不同，同时上会分散配置精力。

再定节点放在哪一格。答案取决于企业当前最缺的是业务初筛、法务判断效率，还是用印前的版本一致性。

然后定基础核验的处理方式。选「拒绝」意味着把主体与关键信息错误设成硬红线，选「仅提示」意味着保留人工判断空间。这一项的影响面比看起来大，因为它决定了流程会不会被系统拦下。

最后定展示范围。AI 节点保存之后，后续审批节点和抄送节点默认勾选 AI 审批意见及各能力的展示开关，可以逐节点调整。关闭展示只影响审批人是否看到结果，不影响任务执行。哪些角色该看到 AI 结论，是一个管理判断，不是一个配置细节。

四件事定完，AI 审批助手才成为流程里的一个稳定环节。判断它有没有用的标准很简单：审批人打开审批单之后，还需要翻多少页附件。e签宝把这四项能力放在审批流节点里，配置在管理员手里，结论在审批人眼前，前提是合同本来就从这个节点经过，这也是生态打通比能力清单更值得先确认的原因。