合同审查助手 2.0：实用为王，不再“迷信”大模型

👋大家好，我是 Sword
最近我对合同审查助手进行了全面升级，搞定了合同审查助手2.0版本。相比1.0版本，它减少了对LLM节点的滥用。并且以结构化配置 + 精准调用为原则，将实用性摆在了第一位。

本篇文章就给大家详细解读合同审查助手2.0的核心内容，共同探讨如何让AI工具成为真正实用，稳定可靠的智能助手。

一、 为什么要升级？

下图是1.0版本的工作流，可以看到整个流程有非常多的节点，看起来有一种“炫酷吊炸天”的感觉。

然而实际使用过程中，1.0的体验远低于预期，我总结了以下几个核心问题：

1. 文件处理复杂且不稳定： 不同类型的文件支持效果很差，调试成本高。
2. 过度设计的规则调用流程： 使用了模版、变量聚合、Agent节点、MCP服务，搞了一大堆，实际上只是为了取一个文件切片规则并且做切片操作而已。
3. Agent 节点“高开低走”： 提示词极长，实际作用却很少，远不如预期灵活。
4. 审查流程难以维护： 多个并行节点看起来“高大上”，实际上依赖大量碎片化知识库，维护成本极高。
5. 不必要的输出设计： 聚合后支持无数种输出格式，从实用性上来看确实有用，但是我将其作为教学范例，完完全全就是过度设计。

真正的实用，不是看起来复杂高深，而是简单、易用、可复制、能落地。华而不实的设计，只会让人踩坑不断。

二、核心优化内容

请欣赏 2.0 版本的审查流程图，接下来我简单介绍一下本次版本的核心优化：

1. 文件处理更高效： 通过一个多功能节点即可完成 PDF、图片等多格式的文档解析，去掉了冗余流程配置。

2. 规则体系更精准： 只需一个 HTTP 节点，即可实现动态加载审查规则，按合同类型快速匹配适用审查要点，扩展能力也大大提升。

3. 审查流程更简洁： 利用一个迭代节点，自动调度所有审查点，无需堆叠多个 LLM 节点，执行效率提升的同时还使用BadCases大大提高准确率。

4. 动态提示词设计： 将每个审查要点的核心规则写入配置文件，实现迭代中LLM节点动态提示词效果，大幅度提高扩展性

三、核心流程拆解

1.多格式文档支持

关于这个点其实在之前文章就有提到过，通过将工作流封装成工具，实现了多种文档一个节点完成解析的功能。封装为工具的工作流如下：

从流程图中我们可以看到，该工具集成了PaddleOCR + Dify自带的文档提取器。实现了图片、扫描型PDF、各种文档类型的内容提取。而在实际使用时，只需要将其作为一个节点使用即可。

2.更强大的规则体系
该体系通过两个配置文件和一个接口实现，实现了真正的简单好用。

inspection_points.json文件存储审查要点，该文件存储各种合同的审查要点，并维护了索引。

checklists.json文件则用于配置各种合同的审查要点索引，通过该索引取inspection_points.json中的实际审查要点。

rule.py脚本则是为了实现根据合同类型动态获取审查列表的功能。
在实际的审查流程中，通过该接口获取审查点，然后作为迭代节点的参数，控制整个审查流程。

3.更高效，强大的审查流程

开始节点配置了三个参数：
合同文件：需要审查的文件
合同类型：根据合同类型选择
审查偏好/重点：除了配置的审查规则外，审查节点还将根据该参数进行重点审查，使得审查结果更贴近用户需求。

在迭代流程中，先根据审查条例获取审查依据条款，同时根据合同内容获取BadCases内容。然后合同审查节点将依据用户的审查偏好、审查依据条款、BadCases内容对当前审查点进行审查，并输出结果。

四、运行效果

1.以下是正在运行过程中的总览效果，可以看到步骤非常少，但是麻雀虽小五脏俱全。

2.以下是几个迭代中的参数，可以看到每个迭代审查的是不同的内容。可以看到每个迭代都实现了精准的规则调用，并行执行还提升了效率。

3.以下是执行结果，

我们可以看到，对于每一个审查点，智能体都给予了审查结论、问题说明和修改建议。相信随着知识库的不断填充，这个智能体也会越来越强大。

五、总结

在合同审查助手1.0的探索中，我走了不少弯路：一边追求“炫技”的堆叠组合，一边迷失在复杂流程的维护和调试中。而 2.0 的升级，是一次真正意义上的回归——回归审查本质，回归开发效率，回归用户体验。

这次 2.0 版本升级的核心理念只有一句话：用最合适的技术解决问题，而不是“啥都交给大模型”。

**🎁 关注我的公众号【AI转型之路】，获取完整部署包 **