AAIPROS

AIPROS · Static Essay Page

AI加审批流,不是让AI替你点同意

审批与权限 公众号文章 2026-05-17 7 min

昨晚直播里,大家问得最多的,不是“AI 能不能审批”。

昨晚直播里,大家问得最多的,不是“AI 能不能审批”。

更真实的问题是:审批流都已经线上化了,为什么还是慢?

人还在反复补材料。

审批人还在翻制度。

流程管理员还在解释:为什么这个单子又卡住了。

直播时信号不太稳定,有几段关键内容没有讲透。这个作业我欠大家,所以今天补上。

这篇文章完整讲一件事: AI 加审批流,到底有哪六种可落地的做法。

先说结论。

AI 进入审批流,不是让模型替老板、财务、法务、人事直接点“同意”。

审批的本质,仍然是责任链。

AI 真正能改变的,是审批前的信息准备、审批中的规则比对、审批后的意见沉淀,以及流程本身的持续优化。

先把“自动审批”讲清楚

很多企业以前也做过自动审批。

比如报销金额小于 300 元,自动通过。某个岗位发起的常规申请,自动通过。某个字段满足某个条件,直接走下一节点。

这当然有价值。

但它不是 AI 逻辑,而是工程逻辑。

工程逻辑的特点很清楚:条件被提前写死,系统只负责判断。

当金额大于多少,小于多少,发起人是谁,部门是什么,字段有没有填写,系统按规则执行。

它适合非常标准的 yes or no。

问题是,企业里很多审批,根本不是 yes or no。

老板审批也许只看一个结果。

但职能部门不是这样。

财务要看预算、发票、合同、付款计划。

法务要看主体、条款、责任边界。

采购要看供应商、价格、历史合作、异常风险。

这些判断不是一个字段能解决的。

第一种:规则内置在审批引擎里

1 这是最基础的一种。

规则直接写进审批引擎。

表单提交以后,系统读取表单字段,再根据金额、部门、岗位、类别、发起人等条件判断走向。

它的优点是稳定、可控、成本低。

它的缺点也明显:只能处理结构化字段,无法理解附件,无法理解自然语言制度,也无法处理复杂例外。

所以这类自动审批最好用在低风险、高频、规则非常明确的事项里。

比如小额费用报销、固定额度内的办公用品申请、标准化权限开通。

不要轻易把复杂合同、供应商准入、关键人事事项放进去。

因为它看起来自动了,实际上只是把简单规则写死了。

第二种:接口补数据,再做规则判断

2 很多审批只看表单是不够的。

比如采购申请要看供应商历史履约。

合同审批要看客户信用。

付款审批要看预算余额和发票状态。

这时系统会先通过接口获取外部数据,再把这些数据拿回来和表单数据一起判断。

这比第一种复杂了一步。

它不只是看“你填了什么”,还会看“别的系统里已经发生了什么”。

但本质上,它仍然是工程规则。

数据来源变多了,判断方式没有变。

它适合企业已经有较好系统集成基础的场景。

如果预算系统、合同系统、ERP、CRM 都能稳定打通,这种方式很有效。

但一旦接口谈不下来,数据口径不一致,或者不同系统字段不规范,推进就会变慢。

第三种:多模态解析材料,再进入规则和模型判断

3 审批真正变难,通常从附件开始。

表单里只有几行字段。

但真实判断藏在合同、报价单、发票、营业执照、方案文件、聊天记录截图里。

过去大家会用 OCR 识别。

OCR 能解决一部分问题,但准确率、版式理解、语义理解都有限。

今天更可行的方式,是用多模态模型或专门微调过的模型,先把非结构化材料变成可计算的信息。

一般会分几步。

A 先获得数据:表单、附件、页面信息、第三方系统数据。

B 再识别类型:这是合同、发票、报价单,还是资质文件。

C 继续解析内容:主体、金额、日期、条款、风险点、异常项。

D 最后把解析后的内容送入规则匹配和模型判断。

这里最容易犯的错,是为了 AI 而 AI。

供应商名称能不能和表单匹配,这种事情不应该交给大模型瞎猜。

能用工程规则稳定匹配的,就先用工程规则。

比如供应商 A 是否等于表单里的供应商 A,合同金额是否等于付款申请金额,发票抬头是否等于合同主体。

这些判断要确定、要可追溯。

大模型更适合做什么?

适合处理自然语言规则、复杂条款理解、风险说明、审批意见组织。

比如合同里某个责任条款是否偏离模板,某个付款条件是否明显前置,某段话是否和制度精神冲突。

真正的难点,是评测

做到第三种形态,很多企业会遇到一个坎。

不是模型不会说话。

而是系统到底准不准。

审批不是写文章。

一个金额提错,一个主体看错,一个条款误判,都会带来真实风险。

所以这里必须做评测。

要素提取要评测。

附件解析要评测。

规则匹配要评测。

审批意见也要评测。

而且不能只看一个总分。

你要拆到字段级、规则级、场景级。

比如合同主体、金额、期限、付款条件、违约责任、发票信息,每一类字段的准确率都要单独看。

很多企业不是不想用 AI 审批。

而是不知道怎么证明它可用。

这件事非常专业。

没有评测体系,AI 审批就只能停在演示阶段。

第四种:审批插件,不依赖接口也能先跑起来

4 到这里,有些流程管理团队会说:道理我懂,但接口太难谈了。

信息部门排期很满。

业务系统不愿开放数据。

平台厂商也不一定配合。

那有没有更轻的办法?

有。

就是审批插件。

它不先改造原系统,也不强依赖标准接口。

当你打开审批页面时,插件读取页面上的表单信息和附件信息,再调用已经封装好的审批 Skill,给出扫描结果和审批意见草稿。

这个插件不是等你点按钮才开始干活。

更好的设计,是有预热机制。

你打开页面那一刻,它已经开始捕捉页面、解析附件、匹配规则。

等你点开侧边栏时,它把结果快速回放给你。

审批人看完,可以一键把意见插入到审批框里。

这种方式特别适合先做样板。

它能绕开一开始就大规模集成的难题,让流程团队先证明价值。

但它也有边界。

页面结构变化会影响读取。

附件权限要处理好。

日志、留痕、权限隔离,也要提前设计。

所以它适合做快速增强,不适合长期替代正式平台能力。

第五种:通过转换器做审批辅助平台

5 插件再往前走一步,就可以变成平台。

有些审批系统、协同平台、OA 平台,本身能通过连接器或转换器把任务数据同步出来。

那我们就可以做一个审批辅助平台。

任务一产生,平台就接收数据。

你还没打开表单时,它已经完成材料解析、规则比对、风险扫描和意见草稿。

等审批人进入页面,只看到一个边栏。

边栏里有摘要,有风险,有建议,有依据。

但它不一定直接写回审批系统。

这点很关键。

很多企业第一阶段不敢让 AI 自动操作。

那就先让 AI 做“辅助判断层”。

它把该看的内容提前看完,把该提示的风险提前提示,把该写的意见提前组织好。

人仍然做最终决定。

这个形态比插件更适合规模化。

因为它能统一管理 Skill、规则、评测集、权限和日志。

企业如果想把 AI 审批从单点工具变成组织能力,最终会走到这一层。

第六种:让智能体通过协议和命令行接入审批

6 最后一种更有想象力。

如果一个桌面智能体,能在你的身份授权下读到 OA、BPM、协同平台里的审批任务,会发生什么?

它可以定时监听你的待审批列表。

它可以读取单据和附件。

它可以调用审批 Skill 做判断。

它可以把低风险事项自动处理掉。

也可以把中高风险事项整理成邮件、即时消息或待办提醒,让你只处理真正需要你看的部分。

这件事不是空想。

现在很多企业平台已经开始提供 OpenAPI、SDK、MCP、CLI 这类面向自动化和智能体的入口。

以飞书/Lark 为例,官方开源 CLI 已经面向 AI Agent 和开发者提供命令行能力;审批开放接口也提供审批任务同意、拒绝等动作。

这意味着,智能体不一定非要通过页面点击才能工作。

它可以通过授权、接口、命令行和企业身份体系,成为一个受控的流程执行者。

当然,这一层风险也最高。

不是所有审批都适合全自动。

我的建议是分级处理。

低风险、强规则、可撤回的事项,可以尝试自动执行。

中风险事项,自动生成意见,但保留人工确认。

高风险事项,只做摘要、比对和预警,不自动提交。

这不是保守。

这是把 AI 放进组织流程时,必须有的责任边界。

不要按“代际”理解,要按“能力层”理解

我不太想把它讲成一代、二代、三代。

因为企业真实落地时,不会按代际整齐演进。

很多企业会同时存在几种形态。

小额报销还在用工程规则。

合同审批已经开始做文档解析。

流程团队先用插件做轻量试点。

信息部门在评估是否搭一个统一的审批辅助平台。

高级一点的团队,已经开始尝试让智能体监听任务、生成意见、回写结果。

这才是现实。

AI 加审批流不是一个产品按钮。

它是一组能力。

数据接入能力。

材料解析能力。

规则建模能力。

模型判断能力。

评测验证能力。

权限和审计能力。

这些能力叠起来,才叫 AI 审批。

企业应该怎么开始

如果你正在企业里推动这件事,不要一上来就说“我要做 AI 自动审批”。

这个表述会让管理层紧张。

也会让法务、财务、人事本能防御。

更好的说法是:先做 AI 审批辅助。

第一步,选一个高频、低风险、材料相对标准的流程。

比如费用报销、合同初审、供应商资料补齐、采购比价、权限申请。

第二步,把审批判断拆成四类。

1 哪些规则能工程化。

2 哪些信息需要从附件里提取。

3 哪些判断需要模型理解自然语言。

4 哪些动作必须保留人工确认。

第三步,做一套小评测集。

不要贪大。

先拿几十个真实历史单据,把正确答案标出来。

看模型能不能提对字段,看规则能不能匹配对,看意见能不能说清依据。

第四步,再决定用什么形态落地。

接口好拿,就走平台化。

接口不好拿,就先做插件。

规则简单,就先工程化。

附件复杂,就先做材料解析。

已经有开放 API 或 CLI,就可以试智能体自动化。

最后一步,是把每一次审批结果沉淀回来。

哪些意见被采纳了。

哪些风险被忽略了。

哪些规则经常误报。

哪些节点总是退回。

这些数据沉淀下来,才会反过来优化制度、表单、流程和 Skill。

我真正想提醒大家的

审批流的数字化,解决的是“单子能不能在线流转”。

AI 进入审批流,解决的是“人在判断前,能不能少做无效劳动”。

这两个问题不一样。

很多企业的审批系统已经上线很多年,但审批体验仍然不好。

原因不是流程图画得不够漂亮。

而是判断所需的信息,没有被提前准备好。

规则没有被结构化。

材料没有被解析。

历史经验没有被复用。

流程问题没有被复盘。

AI 的价值,不是把责任从人身上拿走。

它的价值,是把重复、低效、可验证的部分先处理掉,让真正承担责任的人,把注意力放在判断本身。

这也是流程管理团队接下来最值得迁移的能力。

不要只会画流程图。

要能把一个流程拆成数据、规则、判断、动作、反馈。

不要只会写制度。

要能把制度变成可执行、可评测、可迭代的 Skill。

不要只会说 AI 很厉害。

要能回答:哪些地方该用工程,哪些地方该用模型,哪些地方必须留给人。

从这个角度看,AI 加审批流不是一个小功能。

它会逼着企业重新理解流程管理。

流程不再只是“谁先审、谁后审”。

流程会变成一套可以被智能体理解、执行、评测和优化的组织操作系统。

这件事,值得大讲特讲。

给昨晚直播同学的福利

昨晚信号不好,确实影响了体验。

所以这篇文章也算是补作业。

课里提到的流程规划 Skill、泳道图/流程图绘制 Skill、流程课件,我会整理成资料包。

你可以在评论区留一个你最想改造的审批场景。

你不用先想得很复杂。

就写一句话也行。

比如:合同审批、费用报销、采购申请、供应商准入、用章审批、权限开通。

场景越具体,我越容易给你对应的资料和建议。

参考依据

这篇文章里关于审批动作、文档信息提取、流程挖掘、智能体工作流和飞书/Lark 命令行能力的判断,参考了公开资料:Microsoft Power Automate Approvals、AI Builder Document Processing、Power Automate Process Mining、ServiceNow Now Assist Agentic Workflows、Lark/Feishu CLI 与飞书审批开放接口。