AI 审批助手怎么用：把合同审查装进审批流的四件事

审查结论只有一个消费场景，就是审批

企业上 AI 合同审查，第一年常做的事是给法务部配一套审查系统。用下来会看到一个落差：法务审得快了，合同该卡的地方还是卡不住。

原因在于审查结论真正被消费的地方不在审查系统里，在审批单上。审批人点同意或退回，才是这份合同第一次因为审查而改变走向。审查系统里躺着的高风险提示，如果审批人看不到，它对这笔交易没有产生任何作用。

这个视角一换，产品形态的判断也跟着变。真正要解决的问题从「怎么审得更准」，挪到了「审查怎么在审批发生的那个界面上起作用」。

e签宝 AI 审批助手的定位落在这一步：装在合同审批流程里的 AI 节点。合同流转到指定审批节点时，自动执行主体一致性校验、条款风险审查、合同比对与内容摘要，结论回填到审批单字段或审批意见。

把 AI 放进审批节点，改的是审查什么时候开始

审查系统的工作方式是等人来用。法务收到合同、打开系统、选方案、跑审查。这条路径的隐含前提是有人先判断这份合同需要审。

实际业务里这个前提经常不成立。业务方觉得是标准文本，直接就走了审批，等法务看见，合同已经在最后一个节点。审查能力再强，没被触发就等于不存在。

AI 节点换掉了触发条件。合同进审批流，到那个节点就跑，不需要谁记得去点。审查从「一个需要被发起的动作」变成「审批流程的固定一环」。

这个改动看起来只是位置挪了一下，实际改的是覆盖率。发起式审查的覆盖率取决于人的判断，节点式审查的覆盖率等于走这条审批流的合同量。

代价同样明确：节点式审查不能做太重的判断。审批有时效，一个节点卡住整条流程，业务会绕开它。能力因此被切成四块，主体校验、条款审查、比对、摘要，按审批流的需要勾选，不全量跑。

主体一致性校验不占审批字段，这件事本身有信息量

四项能力里，主体一致性校验的处理方式和其他三项不一样：它不占审批字段，结论直接展示在审批意见中。

这个细节透露的是判断依据的性质。合同审查、比对、摘要的结论需要人二次判断，所以要变成字段供审批人填写和流转。主体一致性校验的结论是硬事实，比对的是工商登记的企业名称、统一社会信用代码、法定代表人与经营状态，对得上或者对不上，中间没有解释空间。

硬事实不需要进表单，它需要的是拦得住。这也是四项能力里唯一可以配置成「拒绝」的一项：配成拒绝时，主体校验不通过会直接拒绝本次审批；也可以配成仅提示。

条款审查拿不到这个权限，原因也在同一个地方。拦截的前提是判断无争议。条款风险有争议，同一处措辞在不同交易背景下轻重不同，机器给硬结论会误伤；主体信息不一致没有争议，对不上就是改名没同步，或者签错了对象。

结论要能收敛，否则第二轮就没人看

一份合同改两轮之后，审查意见会开始打架：同一处条款被标了两次，第一轮的意见还挂在那里，审批人分不清哪条还成立。

这个问题的技术名字叫结果收敛，落到体验上就是一件事：审批人打开这一版，看到的意见是不是只针对这一版。

做法有几层。AI 深度审查与规则审查的结果统一在「条款审查」里展示，重复意见自动合并；风险点分待处理、已处理、已忽略三种状态，支持一键批量修订；方案没有变动时，重审只跑待处理项，并标记出新增、修正、移除。

「只跑待处理项」这一条比看上去重要。全量重审的麻烦不在耗时，在输出：每次重审都产出一份完整意见，审批人要在两份几乎一样的清单里找差异。增量重审把差异本身变成输出。

每一轮重审生成新的版本记录，当前结果不被覆盖，原始合同、修订版与审查报告都能下载。这条设计是为半年后的举证留的。

一个审批单里多份合同，难在版本而不是审查

单份合同的审批链路是线性的，多份合同不是。一张审批单里挂三份合同，每份分别起草、分别签署，还要保证用的都是已审批的最新模板。

武汉顶好能源的场景就是这样：一张审批单涉及多份合同，需要在明细里分别协商起草、从明细读取文件发起电子签，还要把对方盖章返回的扫描件与确认版本做比对。这条链路上每个环节都能拿错版本，用印环节拿到旧版模板，签署环节签了未经审批的那一稿。

这类场景里，AI 审查能解决的问题有限，真正要解决的是版本链路：哪个版本被审过、哪个版本被批过、哪个版本被盖章。多合同、多明细的审批流，验证顺序该是先跑通版本链路，再谈审查深度。

用印审批要核的是那一版文件，条款已经在上一环审过

用印审批常被当成合同审批的重复动作，它查的其实是另一件事。

合同审批看的是文本内容对不对；用印审批看的是准备盖章的这份文件，和当初审批通过的那份，是不是同一份。这个差别在多轮往返里会被放大：审批通过之后，业务和对方又改了两处措辞，文件重新上传，用印环节看到的是新文件。

处理方式是把审批版本与签回版本做比对，差异按新增、替换、删除列出，被调整过的位置直接定位到条款。附件核验是同一思路的另一面，比对正文与附件，单次最多 3 份。报价单、技术附件、补充协议与主合同条款冲突这类问题，靠人翻文件很难不漏。

四条导入路径，决定老法务的经验能不能搬进系统

规则库这件事，卖点从来不是预置了多少条，是企业自己那套能不能搬进来。

AI 审批助手依据《民法典》19 种典型合同类型分别预置规则分组，企业在这套分组上改写为自己的方案。现有审查要求有四条路径搬进来：手动录入、粘贴文本清单、上传范本或制度、Excel 模板导入。一条规则由关注角色、风险等级、审查要点、修改意见、关联法条构成。

这条设计的实际意义在迁移成本。审查标准散在老法务的笔记和聊天记录里，形式是一段话，不是一张表。把它变成结构化规则，中间那一步的手工量最大。四条路径对应四种现状：有清单的、有制度的、有范本的、什么都没有只能一条条写的。

京源环保的情况能说明这一步的优先级。这家环保企业有一套自己的审查规则，数量约四五十条，此前的版本大约只支持二十条，装不下，标准就只能继续留在各人手里。落地顺序是审批流程先不动，规则先在独立页面上跑起来，过程中客户关心的是规则格式怎么组织、版本之间怎么对比、以后进审批怎么用。规则验证通过后再往前推。

一条审批流最多可路由 10 个方案，发布前可以用实测合同试跑。这两条把「新规则不敢压到真实审批上」拆开了：先试跑，再按合同类型分方案路由。

接入方式决定这件事推不推得下去

审批流跑在飞书、钉钉或企业自建 OA 里，这是既成事实。AI 能力以什么形态进去，决定推广成本。

三种形态的差别在入口。飞书审批流已接入，加一个 AI 执行节点、勾选需要执行的能力即可；钉钉是端内发起与待办；用印审批通知走飞书通道；企业自有系统通过 OpenAPI 对接协商起草全流程，创建任务、邀请协商、在线编辑、定稿、文件下载。

配置动作在 e签宝侧做一次：开通与授权、勾选能力、配置回传，之后照常发起，审批到达节点时自动执行分析。发起人和审批人的操作入口不变，这一点决定推开时的阻力大小。需要重新培训一遍流程的系统，落地率都不高。

接入范围按实际情况说明：未点名的系统即尚未接入，以实际开通情况为准。

边界要写进流程配置，不能写在说明书里

AI 进审批最容易出的问题是权责说不清：结论错了谁负责，跑失败了流程卡不卡。

AI 审批助手的边界写死在配置里三条。AI 分析结果作为审批参考，审批决定仍由审批人结合业务情况完成；四项能力中只有主体一致性校验配置为拒绝时会拒绝本次审批，其余三项没有拒绝权限；合同审查、合同比对与审批意见摘要失败或超时，不阻断审批，只展示对应状态。

第二条和第三条是关键。审查、比对、摘要失败不阻断，意味着这三项的定位是辅助信息，流程连续性优先于分析完整性。主体校验可以拒绝，意味着它被当作合规卡点，不再是参考意见。

这个划分对配置的人有要求：哪些能力配成拦截、哪些配成提示，上线前要想清楚。全部配成提示，系统等于没装；把条款审查也配成拒绝，误报会直接卡住业务。

一条审批流里加一个 AI 节点，技术上是几天的事。难的是节点勾了哪几项、每项的输出进了哪个字段、哪一项有拦截权。这三个问题在上线前答清楚，审批里的 AI 才是流程的一环；答不清楚，它就是一个偶尔被点开的功能。