1. 合同审查的痛点以及我为什么选 Coze TextIn我先从最实际的一个场景说起某公司法务部每周要审几十份合同包括采购协议、销售合同、保密协议、技术服务合同。这些合同来源五花八门有对方邮件发来的 PDF有扫描盖章件有改过七八版的 Word。审阅的人要把付款条款、违约责任、知识产权归属、争议解决条款逐条核对还要检查合同编号、金额大小写、日期是否对得上。这套流程极其机械但又出不得错。很多团队想过用 AI 来提效结果一打听市面上的合同审查产品要么按坐席收费、年费动辄几十万要么需要私有化部署、IT 资源跟不上。实际上对于“每周几十份合同”这个体量用 Coze 低代码搭建一套智能体再配合 TextIn 做文档解析就能把“条款审阅 规范审阅”两条线跑起来。这套方案的特点是轻不需要开发团队不需要算法工程师不需要租 GPU一个懂业务流程的人几天内就能搭起来成本几乎可以忽略。我在这里先说明一下这套方案的定位它不是要替代律师做法律判断而是把“读文档、抽信息、查一致性、出报告”这些体力活交给 AI让人去做最终判断。这个定位决定了后面所有的设计——包括选型、工作流编排、提示词怎么写、报告怎么输出。2. 方案设计为什么“条款审阅”和“规范审阅”必须拆开很多人一开始会犯一个错误让大模型直接把整本合同读一遍然后输出一段“审阅意见”。我试过效果非常差。原因很简单合同审阅其实是两类完全不同的任务。2.1 条款审阅本质上是一道语义理解题条款审阅关注的是这份合同里到底写了什么关键条款是否齐全权利义务是否对等有没有明显风险。比如一份采购合同我要知道甲方乙方是谁、合同总价、交付时间、验收标准、付款节点、违约责任、保密期限、争议解决方式。模型需要从长文中抽取这些要素再判断有没有缺失缺失的条款通常需要标注为“建议补充”。这类任务高度依赖大模型的语义理解能力。它要求模型能区分“甲方应于收到乙方开具的增值税专用发票后 10 个工作日内支付”和“甲方应在收到货物后 30 日内一次性付清”的区别并且能判断这种差异带来的资金压力风险。这不是关键词匹配能解决的。2.2 规范审阅本质上是一道规则匹配题规范审阅关注的是合同的表达形式是否符合模板要求。比如合同编号是否连续、金额大写和小写是否一致、页码是否齐全、条款序号有没有跳号、时间是否自洽、有没有错别字、有没有出现模板残留的占位符。这类任务更接近“规则引擎”但它又比单纯的正则表达式灵活得多因为“金额大小写是否一致”“日期格式是否统一”这类问题散落在半结构化文本里用关键词匹配很容易漏。大模型在这里的优势是能把解析出来的文本按句子、按条款拆开逐条做规则判断。2.3 拆开设计的三个好处把这两类审阅拆成两个独立的 LLM 节点或两个提示词模板有三个实际好处第一提示词可以各自优化。条款审阅的提示词专注于“要素抽取 缺失判断 风险提示”规范审阅的提示词专注于“一致性 格式 错别字”。混在一起写两边的效果都会崩。第二输出维度更清晰。我可以在工作流里让条款审阅输出一个 JSON 结构规范审阅输出另一个 JSON 结构最后由汇总节点合并成一份报告。这样后续不管是导出 Excel、接入企业微信还是存数据库都很方便。第三出错时容易定位。如果条款审阅没问题、规范审阅老翻车我只需要单独调规范审阅的提示词不用动整个流程。2.4 选 Coze 和 TextIn 的理由Coze 在这里承担的是“编排大脑”的角色。它把大模型调用、提示词、知识库、API 接口这些能力都串起来还支持把做好的智能体发布成在线服务或 Bot让业务人员通过网页、API 直接使用。对中小企业来说这是最现实的 AI 落地路径不用自己维护一套微服务架构不用做前后端数据和配置都在云上维护。TextIn 则是解决“输入端”的问题。合同大多是 PDF 或扫描件大模型拿到的原始文件没法直接处理必须先转成结构化的文本。TextIn 的文档解析服务能把 PDF、图片里的文字、表格、段落完整地提取出来效果比普通 OCR 好不少特别是对带印章、带复杂表格的合同页还原度很高。没有这一步后面所有审阅都无从谈起。3. 实操在 Coze 里配置“解析 → 条款审阅 → 规范审阅”工作流下面这部分是完整的操作记录我尽量按步骤来写。你不需要完全照抄我的配置但核心链路可以复用。3.1 第一步接入 TextIn 文档解析插件在 Coze 的“插件”里找到文本解析类插件或者直接通过自定义插件的方式接入 TextIn 的 API。官方提供的是两种接入路径一种是市场已有的封装插件直接点击添加另一种是在插件管理里填 API 地址、鉴权方式、入参出参。如果走自定义接口一般是下面这样POST https://api.example.com/document/parse Header: Authorization: Bearer YOUR_API_TOKEN Body: { file_url: https://.../contract.pdf, parse_mode: auto }响应里会包含结构化文本、表格识别结果和每页的版式信息。我在 Coze 插件节点里只需要保留两个字段text_content全文文本和table_content表格内容。这两个字段会作为后续 LLM 节点的输入。注意有些合同是图片型 PDF也就是扫描件普通 PDF 解析插件会直接罢工。TextIn 的优势就在于它的 OCR 能力可以识别扫描件。但识别出来的文本偶尔会有错字这会影响规范审阅的准确性后面我会专门讲怎么处理。3.2 第二步搭工作流主链路在 Coze 的“工作流”里我设计了四个节点按顺序连接开始节点接收用户上传的文件路径或 URL。插件节点调用 TextIn输出解析后的文本。LLM 节点一条款审阅输入text_content 合同类型输出条款审阅 JSON。LLM 节点二规范审阅输入text_content 模板规则输出规范审阅 JSON。结束节点把两个 JSON 合成一份 Markdown 报告。这里有个关键操作LLM 节点一和 LLM 节点二一定要并联两路同时跑不要串联。因为条款审阅和规范审阅是独立任务串联会让整个流程多等一轮大模型调用时间翻倍费用也翻倍。3.3 第三步写条款审阅的提示词这是整套方案的核心。我用了比较清晰的“角色 任务清单 输出格式”结构你是一位具有 10 年经验的合同审阅专家。 请对用户提供的合同文本进行条款审阅。 审阅任务逐条执行 1. 抽取合同基础要素合同名称、合同编号、甲方全称、乙方全称、合同总金额大写与阿拉伯数字、签署日期、有效期。 2. 核对关键条款是否缺失付款条款、交付/验收条款、违约责任条款、保密条款、知识产权归属条款、争议解决条款、解除与终止条款。 3. 对每项要素给出状态OK存在且表述清晰、MISSING完全缺失、AMBIGUOUS存在但表述模糊。 4. 在 MIssING 和 AMBIGUOUS 的情况下补充具体说明和建议补充位置。 输出格式严格输出 JSON不要输出任何额外说明。 { elements: [{name: ..., value: ..., status: OK/MISSING/AMBIGUOUS, risk_note: ...}], risk_summary: [风险点1, 风险点2] }我没有在提示词里写死每个公司的具体合同模板而是让模型先做要素抽取再做判断。这样做的好处是通用性好不同部门的采购合同、销售合同都能直接审。如果你有固定的合同模板可以在知识库里放一份标准模板然后在提示词里加一句“与知识库中的 XX 模板对比指出偏离项”效果会更好。3.4 第四步写规范审阅的提示词规范审阅的提示词更偏“找茬”我让它输出一个 Markdown 表格而不是 JSON。因为规范审阅的结果大多是“哪一页哪一段有问题”表格形式更便于阅读和复核。请基于用户提供的合同文本进行规范审阅重点检查以下内容 1. 合同编号是否符合常见格式要求是否缺失或重复。 2. 金额的大写与阿拉伯数字是否一致。 3. 日期逻辑是否自洽签署日期是否早于生效日期合同有效期是否覆盖履行期。 4. 条款序号是否连续是否有跳号或重号。 5. 正文中是否存在明显错别字、漏字、占位符残留如“XX”“【】”“请填写”。 6. 页码和页眉页脚中的合同编号、版本号是否一致。 要求只输出问题项没有问题的维度不输出。 输出格式Markdown 表格 | 检查维度 | 问题描述 | 出现位置可按原文片段定位 | 修改建议 |这里我想强调一个细节规范审阅不需要判断“这句话合不合法”它只管“格式和表达是否规范”。很多模型天然有“我要给出法律意见”的冲动你必须在提示词里明确禁止它展开法律评价否则它会输出一堆正确的废话反而把真正的格式问题淹没了。3.5 第五步设计报告合并逻辑LLM 节点一输出 JSONLLM 节点二输出 Markdown我再用一个“报告生成”节点把它们汇总成一份最终报告。这一节点本质上是一个低难度的 LLM 调用提示词就一句请把用户提供的条款审阅结果 JSON 和规范审阅结果表格合并为一份带标题的合同审查报告 报告开头写明合同名称与总体评价随后依次展示“关键条款”“规范性检查”“风险摘要”三个板块。注意这一步不需要让模型重新判断它只是排版工具模型参数量小一点都没有关系。如果你想让报告更美观也可以跳过这个节点直接在 Coze 的输出配置里写多行文本模板。3.6 配置过程中的几个里程碑我建议不要一口气搭建完整流程而是分层验收第一步先用文本解析插件直接跑一份 PDF确认解析结果是不是完整、有没有乱码 第二步单独测条款审阅节点——用一段知名合同的公开文本做输入检查抽取要素是否准确 第三步单独测规范审阅节点找一份有错别字、序号错乱的测试合同确认能抓出问题 第四步再把整条链路串起来跑。每层的验收时间和修改成本不一样插件出问题可能要换接口LLM 出问题只要改提示词。从费用角度考虑逐层测试也比整链路反复试错省得多。4. 落地部署从“能用”到“好用”的关键调整4.1 发布方式的选择Coze 支持把智能体发布为多种形态我在实际落地中试过三种网页版在线体验适合内部试用期。业务人员把合同上传到一个 URL等几十秒拿到报告。优点是零门槛缺点是文件上传大小有限制。API 服务适合集成到法务现有的合同管理系统里。Coze 会给你一个 API 地址你的后端系统上传文件后调用这个 API 拿到审查报告。这条路径最正式也是我认为最终应该走的路线。飞书/企微机器人适合“群里直接甩合同”这种高频场景。我们在企业微信机器人里发一个文件机器人在群里回复审阅报告摘要。优点是交互非常顺缺点是长报告容易被聊天工具截断。我不建议一上来就追求全自动集成。先把机器人或网页版跑两周让业务人员用真实合同测反馈问题后再迭代。很多流程问题只有在真实业务场景里才会暴露。4.2 准确性如何把控让模型说出“我不确定”合同审阅最怕的就是模型一本正经地胡说。解决这个问题我在提示词里加了一个技巧允许“不知道”。具体做法是在条款审阅的 JSON 输出里增加一个字段uncertainty当模型无法从原文中找到某个要素时它的状态可以是UNCERTAIN而不是硬凑一个答案。比如合同里没有明确的“保密期限”模型可以如实输出 MISSING并附一句“原文未找到保密期限条款”。但如果原文里写的是“保密期限为商业合理期限”这种模糊表述就标成 AMBIGUOUS要提示人工判断。我这里建议两条硬性规则第一条所有标记为 MISSING 或 AMBIGUOUS 的条款必须给出原文中没有对应内容的依据禁止模型自行脑补标准条款内容。第二条风险摘要里只允许引用合同原文里出现过的信息禁止泛泛而谈“建议咨询法律顾问”之类的话。4.3 长合同怎么办超过 20 页的合同对上下文窗口是个考验。我在实践中发现30 页以内的合同把全文塞进去问题不大超过 30 页容易出现两个问题一是调用成本急剧上升二是模型开始漏看后半部分的信息。我目前的处理方式是先用 TextIn 的解析结果把合同按章节或按条款块切分再分段审阅。Coze 工作流里可以加一个“文本分割器”把全文按“第 X 条”或“第 X 章”切成若干块每块分别调用条款审阅最后再合并结果。这样稳定性和成本都可控。4.4 成本估算很多人担心大模型调用成本太高实际上合同审查这种场景的 token 消耗是可控的。以一份 10 页、约 1.5 万字的中文合同为例TextIn 解析一次成本在几厘到几分钱之间条款审阅一次输入约 1.5 万 token输出约 1500 token规范审阅一次输入约 1.5 万 token输出约 800 token报告合并一次输入约 2000 token输出约 1200 token。按主流大模型 API 的中等价格粗算一份合同的 AI 审查成本大约在三到五毛钱。如果每天审 20 份合同一个月下来不到 300 块钱。这个成本相比人工审查是断崖式的下降。但请别忘了模型结论需要人工复核复核的时间成本才是这套系统真正的“人工开销”。5. 常见问题与排查我从测试和试用中踩过的坑5.1 问题一扫描件识别后错别字太多某份扫描合同上盖了大红章TextIn 解析之后正文里有几个字被识别错了最典型的是把“贰拾万元”识别成“贰拾五天”这种情况下规范审阅会误报“金额大小写不一致”。我的处理办法是在规范审阅的提示词里加一条——“如果疑似 OCR 识别错误导致的个别字符异常请在报告中标注‘疑似识别错误’不要直接断言合同有问题”。同时我会在前置流程里轻量使用图像增强让扫描件更清晰。提示要求再高的 AI 也无法做到扫描件 100% 准确。凡是大写中文数字和日期建议人工对着原文复核一次这是底线。5.2 问题二条款审阅把“没有的条款”脑补成“有”有一次测试合同时模型把一条“保密条款”状态标成了 OK但我翻遍原文都没找到关于保密的任何表述。后来发现问题出在知识库里。我在知识库中放入了一份参考模板而参考模板里有保密条款模型把两部分信息混合了。解决办法把 LLM 节点的“知识库引用”和“上下文”严格分隔开。知识库内容只用于回答“模板中是否包含保密条款”这类参照性问题不能混入对当前合同的判断。简单做法是在提示词里明确写知识库内容仅用于对比参考判断当前合同要素时只能依据用户当前提供的合同文本。5.3 问题三长合同后半段被“遗忘”某团队审一份 60 页的融资协议后半段的付款里程碑全部漏了。我排查后确认不是提示词问题而是大模型在处理超长上下文时对中间和尾部内容的注意力下降。应对措施就是我在 4.3 提到的分段审阅。把文本按条款块切分后每个块单独调用模型最后统一合并。合并时再加上“信息去重”指令避免同一条款被重复报告。5.4 问题四输出格式不稳定有些大模型在输出 JSON 时偶尔会带一句“好的以下是结果”这种前缀这在 Coze 的“结构化输出”里会导致解析失败。解决办法有三个在提示词末尾强调“只输出 JSON不要有任何前缀和后缀”开启 Coze 节点里的“JSON 模式”或者用结果解析节点做清洗。我一般在提示词里加一句“如果无法满足输出要求请输出空 JSON”保证流程不中断。5.5 问题速查表现象可能原因排查步骤解决方案解析后全文乱码合同是图片型 PDF插件未启用 OCR用通用 PDF 工具打开确认是否为扫描件更换为支持 OCR 的解析插件条款审阅缺关键条款文本过长导致注意力丢失拆段再测试确认是否部分段落未参与审阅增加文本分割节点规范审阅误报错别字OCR 识别误差被当成原文对比原始 PDF 片段定位错误来源提示词增加“疑似识别错误”标注机制报告中出现模板痕迹知识库与当前合同混用删除知识库引用再测试提示词明确知识库仅作参照接口返回超时合同页数过多检查日志定位耗时环节限制单次审阅页数超长合同自动拆分子任务输出 JSON 解析失败模型输出带了多余文字查看原始输出内容开启 JSON 模式提示词要求空 JSON 兜底6. 这套方案还能延伸到哪里合同审阅只是第一个场景同样是“解析文档 → 抽取要素 → 规则检查 → 生成报告”这条链路换成其他输入和提示词就能跑向完全不同的应用。我可以举几个实际验证过的方向第一供应商资质审查。把供应商的营业执照、资质证书、审计报告传到 TextIn用 Coze 工作流抽取证件有效期、经营范围、注册资本再和企业内部的准入标准比对自动判断资质是否过期、经营范围是否匹配。第二招投标文件核查。标书里的废标条款极其严格有的要求盖章、有的要求签字、有的要求法人授权。用规范审阅的思路做一个“标书形式审查”智能体能把形式审查的初筛工作量减掉大半。第三内部制度文件一致性审查。公司制度更新频繁不同版本之间经常出现前后矛盾。把新旧两版制度文件同时解析让模型逐条对比差异输出一份变更对照表。这比人工逐行比对效率高很多。这些都是“轻量落地”这个思路的延伸。核心方法论是一致的先拆任务再选工具用工作流把拆开的任务串起来让人工复核留到最后一道关。最后分享一点实战体会我做这套东西最大的心得是不要指望 AI 一次到位。第一版跑通时条款审阅的风险摘要里还会出现“本合同存在一定法律风险”这种空话我在提示词里加了一条“禁止输出无法被原文引用的结论”这类问题就绝迹了。AI 合同的落地本质上是在调试“输出边界”——让模型知道它该判断什么、不该判断什么、拿不准的时候怎么表达。如果你正准备给自己团队搭一套合同审查方案我建议不要急着对标几十万的商业产品。先从 20 份真实合同开始测把准确率、漏报率、误报率记下来自己心里有数再逐步扩大范围。轻量方案的价值不在于一张嘴吹得天花乱坠而在于用最低的成本把流程验证清楚让人工从“读全文”变成“只看异常”这是我在实际测试中感受到的最大的效率变化。