不用逐条点开、不用来回切页面。对着对话框说"看看我有哪些要审的",再说一句"帮我审批那几条",剩下的交给 AI 和流程引擎。
一、从"逐条点"到"一句话"
审批的决策成本其实很低------绝大多数单据看一眼就知道该不该过。真正耗时的是操作路径:
打开待办 → 找到那条 → 点进去 → 看表单 → 滚到底 → 点通过 → 写意见 → 确认 → 返回 → 下一条
一条 30 秒,47 条就是 23 分钟。
aiBPM 把这条路径压成两句话。AI 负责听懂人话,流程引擎负责把事情办成。
二、三步交互
① 用户:看看我有哪些要审的
AI:调流程引擎的待办接口,把结果整理成清单
② 用户:帮我审批那几条
AI:从上下文里取出具体条目,逐条调用审批接口
③ AI:已通过 3 条,2 条需要打开处理(附原因和链接)
三个细节让体验成立:
-
清单先行。"那几条"要有指代对象,用户先看到一份可核对的列表
-
能办的直接办,不能办的说明白。哪些可一步通过、哪些需打开处理,一目了然
-
执行前二次确认。将要操作的条目列清楚,用户点"确认"才执行
三、AI 如何调用流程引擎
3.1 四个接口
对话审批建立在流程引擎对外开放的标准接口上,分属两个基路径:
| 场景动作 | 接口 | 基路径 |
|---|---|---|
| 列待办 | /listTodo |
/api/sys-lbpmservice/lbpmAiTodo |
| 查可执行操作 | /getOperationList |
/api/sys-lbpmservice/lbpmAiTodo |
| 按待办执行 | /approveTodo |
/api/sys-lbpmservice/lbpmAiTodo |
| 按单据审批 | /approveProcess |
/api/km-review/kmReviewRestServiceNew |
AI 不接触流程引擎内部。它只看到:待办条目、这条上我能做什么、一个能打开单据的链接。流程怎么流转、节点怎么走,由引擎决定。
3.2 列待办
POST /api/sys-lbpmservice/lbpmAiTodo/listTodo
{
"handler": "{\"LoginName\":\"zhangsan\"}",
"pageSize": 5
}
返回:
{
"total": 2,
"items": [{
"processId": "9f8e...",
"todoId": "1a2b...",
"docSubject": "张三 8 月差旅报销",
"fdCreator": "张三",
"arrivalTime": "2026-09-15 10:23:02",
"operations": [
{"operationType": "handler_pass", "operationName": "通过"},
{"operationType": "handler_refuse", "operationName": "驳回"}
],
"isSimple": true,
"simpleBlockReason": "",
"formUrl": "/km/review/.../kmReviewMain.do?method=view&fdId=9f8e..."
}]
}
一个接口就把三件事说清楚了:是什么单、能不能一句话办、不能办的原因是什么。
3.3 查可执行操作
POST /api/sys-lbpmservice/lbpmAiTodo/getOperationList
{
"processId": "9f8e...",
"handler": "{\"LoginName\":\"zhangsan\"}"
}
返回当前节点、当前这个人可执行的操作及各操作需要的参数。
3.4 执行
POST /api/sys-lbpmservice/lbpmAiTodo/approveTodo
{
"todoId": "1a2b...",
"handler": "{\"LoginName\":\"zhangsan\"}",
"operationType": "handler_pass",
"auditNote": "同意,票据齐全"
}
返回:
{"processId": "9f8e...", "todoId": "1a2b...", "msg": "操作已执行"}
审批完成,流程按引擎既定规则流转到下一节点。
3.5 完整链路
用户:"帮我审批那几条"
↓
AI 解析指代 → 取出上一轮清单中的具体条目
↓
判断可执行性(isSimple)
├─ 可一步通过 ──→ approveTodo ──→ 引擎流转 ──→ 回执
└─ 需打开处理 ──→ 不调用,回传原因 + 链接
↓
汇总结果,一句话答复用户
AI 只产出结构化指令,引擎只接受合法指令。 中间的边界清晰,两边各司其职。
四、四个设计要点
4.1 能力分层:能一步办的和需要人工办的,自动分开
不是所有待办都能一句话批。流程设计时给审批节点开启「快速审批」后,接口返回的 isSimple 才为 true------意味着这条可以一步办结。
没开启的节点,isSimple 恒为 false,并给出具体原因:
| 原因 | 用户看到的 |
|---|---|
| 节点未开启快速审批 | 请打开单据处理 |
| 下节点是人工决策 | 需要选择流程走向 |
| 必须修改下节点处理人 | 需要指定处理人 |
能力边界由流程设计决定,接口如实反映。 这让"哪些能自动、哪些必须人工"变成一条清晰的线,而不是模糊的猜测。
4.2 安全设计:以会话身份调用
所有操作都以当前登录人的身份执行,身份由网关从会话注入:
-
AI 不参与身份传递
-
引擎侧校验:非该待办处理人一律拒绝
-
越权返回明确提示:
no permission to operate this todo
一句话概括:AI 可以替人操作,不能替人成为别人。
4.3 逐条执行、逐条留痕
批量审批不是包一个大事务,而是逐条独立执行:
成功 3 条 / 失败 1 条 / 跳过 2 条 ← 逐条回传,如实告知
每条操作的原始请求、响应、审批意见全部落库。审计问"这笔为什么这么走",答案是完整的链路记录,不是一句"AI 说的"。
4.4 人工决策:AI 给选项,人做选择
遇到需要选择流程走向的节点,AI 不做判断:
这笔需要选择走向:A. 转财务复核 还是 B. 直接通过?
用户选,AI 执行。机器负责效率,人负责判断。 这条边界一旦模糊,审批的严肃性就没了。
五、带来的变化
| 之前 | 现在 | |
|---|---|---|
| 看有哪些要审 | 打开列表页 | 问一句 |
| 审批单条 | 点开、滚动、点通过、写意见 | 一句话批量 |
| 知道哪些批不了 | 点进去才发现 | 清单里直接标明 |
| 操作记录 | 分散在页面 | 逐条留痕可追溯 |
对普通员工,省的是每天 20 分钟的机械操作;对企业,省的是这部分操作标准化之后带来的流程效率。
六、结语
对话式审批的价值不在于"AI 有多聪明",而在于它把流程操作变成了可编程的动作:
-
待办列表不再是页面,是结构化的数据
-
审批不再是点击,是带参数的调用
-
"那几条"这种模糊表达,能准确对上具体单据
沿着这条线,后面自然是:"把上周的报销都查一下进度""这三条转给李四""这两条驳回,理由是发票抬头不对"。
而每往前一步,边界都要重新画一次:AI 可以替人操作,不能替人判断。