用 QClaw 做了一个工程合同风险审计技能说说我的完整实践过程本文参与腾讯云 OpenClaw 玩虾大赛分享一次真实的技能开发与使用经历。前言为什么我想做这个最近公司承接了不少工程项目合同量大法务人手有限。每次拿到一份采购合同或者施工合同审起来都很花时间——条款多则几十页光是把关键风险点逐条找出来就要两三个小时。更头疼的是有些条款藏在很不起眼的地方一不小心就漏掉了。后来我开始用QClaw它是基于OpenClaw打造的本地 AI 助手绑定微信、QQ、企微、飞书、钉钉等 IM 平台用自然语言就能驱动各种自动化任务。在使用过程中我接触到Skill技能这个机制——你可以把它理解为给 AI 装上一个专用的能力模块让它能处理特定领域的任务。我开始琢磨能不能用这个机制做一个专门审计工程合同风险的技能这个想法就这样落地了。以下是我完整做下来的过程有思路、有设计、也有踩坑供有兴趣做类似事情的朋友参考。一、QClaw 是什么——不只是对话 AI1.1 从「通用对话」到「专业助手」市面上的 AI 对话工具已经很多了但大多数本质上是「通用问答器」——你问它答答完就结束。它不知道你是谁不知道你的工作场景更无法替你完成实际任务。QClaw是腾讯云推出的本地 AI 助手它的设计目标就不是通用对话而是承接具体的、专业的工作流。它和普通 AI 对话工具最大的区别在于两点第一它能调用 Skill技能。Skill 是 OpenClaw 的核心扩展机制。简单说就是你可以把某个专业领域的知识、规则、甚至脚本文件打包成一个「技能包」当 AI 判断到适合的场景时会自动激活对应的技能来响应你。就像给 AI 装上了一个插件让它突然具备某个专业能力。第二多平台消息通道。你可以在微信、QQ、企业微信、飞书或钉钉任意一个平台发一条语音或文字指令QClaw 收到后理解你的意图调用相关 Skill完成任务后把结果推送回来。整个过程不需要打开电脑在现场、工地、出差路上都能用。1.2 OpenClaw 的技术架构OpenClaw是一款开源个人 AI 智能助理专为在个人设备或云服务器上自建部署设计。它是 QClaw 的底层框架核心设计思想是**「本地化 技能化」**本地化运行所有 AI 推理和文件处理都在本地设备上完成数据不经过云端。对于工程公司来说这意味着合同内容这种商业机密数据不会外泄。技能化扩展通过 Skill 机制OpenClaw 可以不断扩展自己的能力边界。每个 Skill 都是一个独立的能力包可以单独开发、测试和分发。多平台消息通道支持微信、QQ、企业微信、飞书、钉钉等多个 IM 平台的消息收发。QClaw 则特指通过腾讯电脑管家入口、绑定微信使用的 OpenClaw 形态。1.3 Skill 的文件结构OpenClaw 的 Skill 本质上是一个配置文件 可选的工具代码目录结构如下contract-risk-audit/ ├── SKILL.md # 或 skill.yaml技能的核心定义文件 ├── package.json # TypeScript 技能需要定义依赖 ├── src/ │ └── index.ts # TypeScript 技能入口定义具体工具 ├── references/ # 知识库文件 │ ├── standard_template.md │ └── risk_rules.md └── scripts/ # 可执行的辅助脚本 └── extract_contract.py对于采用 Natural 方式的简单 Skill甚至只需要一个SKILL.md文件就够了——这就是为什么 ClawHub 上的技能本质上都是一个 Markdown 文件。Skill 文件SKILL.md或skill.yaml定义了name / version / author技能身份信息description技能用途描述permissions需要的权限如 network、notificationsconfig用户需要填写的配置项如 API KeyentryPoint实现方式natural / typescript / shell和具体逻辑开发一个 Skill 的核心工作就是编写这个配置文件并准备好references/里的规则和数据文件。如果涉及文件处理再写几个 Python 脚本。这些都不算复杂一个有基础编程经验的人花一两天就能做出来。二、为什么我选择做工程合同风险审计这个方向2.1 工程合同审查的三大痛点工程行业的合同有它的特殊性我总结为三个字多、专、烦。多——条款数量多。一份设备采购合同少说也有十几个章节赔偿上限、验收标准、违约责任、质保期限、管辖权约定……每个环节都可能藏着风险。人工审的时候精力一分散漏掉一两条很正常。专——专业门槛高。「赔偿上限是不是太低」需要结合合同金额和行业惯例来判断「验收标准是否模糊」需要有工程经验才能识别「违约责任是否对等」还要做财务测算。传统法务人员很难在所有维度上都做到位。烦——重复劳动多。公司的合同来来去去其实就那几类模板相对固定每次审查做的事情其实差不多但每次都要从头做一遍效率很低。2.2 Skill 能解决什么问题我想如果能做一个 Skill把公司的标准合同模板和风险识别规则内置进去让 AI 每次拿到新合同就能自动比对、自动识别风险、自动量化财务影响——那法务的工作就从「逐条审」变成了「审核 AI 的审查结果」效率会高很多而且不会遗漏。这个 Skill 的核心目标有三个不漏项每一条差异条款都被发现量化风险告诉决策者每条风险可能造成多少损失给出建议不只是指出问题还要给出修改方向的建议三、技能的设计思路3.1 核心原则AI 执行规则而非做判断在动手之前我想清楚了一件事这个 Skill 并不是要替代法务做判断而是把公司积累的审查经验固化成可复用的规则让 AI 来执行这些规则确保每次审查都不遗漏。这很重要。AI 的强项是执行规则、处理大量文本、发现异常点人的强项是在边界情况下做综合判断。把规则执行的事情交给 AI人聚焦在判断和决策上——这是最高效的人机协作方式。3.2 四阶段执行流程整个技能的运行流程分为四个阶段┌─────────────────────────────────────────────────────────────┐ │ 阶段一合同文本抽取 │ │ PDF/Word → 文字提取 → 结构化文本 │ │ 扫描件自动触发 OCR │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 阶段二模板逐条比对 │ │ 读取标准模板 28 条核心条款 → 语义相似度匹配 → 标记差异条款 │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 阶段三风险识别与量化 │ │ 差异条款 × 风险规则 → 风险评级 财务影响估算 │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 阶段四生成审计报告 │ │ 结构化输出风险清单、评级、量化数据、修改建议 │ └─────────────────────────────────────────────────────────────┘阶段一合同文本抽取。用户把 PDF 或 Word 发给 QClaw技能调用脚本把文件里的文字内容提取出来。工程合同大多是 PDF 格式有些是扫描件没有文字层这种情况会先走一遍 OCR 识别。阶段二模板逐条比对。技能读取公司标准合同模板里的每一条条款用语义相似度算法和待审合同的对应条款逐一对比。相似度低于阈值的条款会被标记为「差异条款」进入下一阶段分析。这里有个细节——纯文本匹配不够用因为合同里经常有「甲方应」和「乙方应」的权责转换字面相似但含义完全相反所以后期我加入了语义层面的判断让 AI 理解条款的实际含义而不仅仅是比对文字。阶段三风险识别与量化。这是最核心的部分。技能基于预定义的风险规则对每条差异条款进行判断。比如赔偿上限低于合同金额 30% 的会被标记为高风险违约金比例双方差距超过 50% 的会被标记为中风险。量化财务影响是这一步最有价值的地方——技能会根据合同金额和风险类型自动估算潜在损失范围让决策者有清晰的量化依据。阶段四生成审计报告。技能按照预置的报告模板输出结构化的审计结果包含差异条款清单、风险评级、财务影响估算值和修改建议措辞。3.3 风险规则的定义方式Skill 的知识库核心是references/risk_rules.md采用 Markdown 格式定义规则不需要写代码。公司可以完全自主维护这套规则。以下是规则定义的示例结构## 赔偿上限规则 ### 规则ID RISK-001 ### 规则名称 赔偿上限过低 ### 判定条件 当赔偿上限 合同金额 × 30% 时触发高风险 当赔偿上限 合同金额 × 50% 时触发中风险 ### 量化方式 潜在最大损失 合同金额 - 赔偿上限 ### 行业背景 工程行业通常认为 30% 是赔偿上限的基准线 ### 修改建议措辞 建议将赔偿上限调整为合同金额的 30% 至 50%这种方式的好处是规则即文档文档即规则。法务人员可以直接阅读和修改规则不需要懂代码。四、用 QClaw 完成 Skill 开发——完整步骤这一节详细介绍在 QClaw 中开发合同审计 Skill 的每一步操作。4.1 环境准备第一步安装 QClaw从腾讯云官网下载 QClaw 客户端Windows 版安装在本地电脑上。第二步配置消息通道QClaw 支持同时接入多个 IM 平台。这里以最常用的微信为例打开 QClaw 设置界面进入「通道配置」选择「微信」通道扫码完成认证。完成上述步骤后你就可以在微信里和 QClaw 对话了。第三步准备开发环境Skill 的文本处理脚本使用 Python 编写建议预装以下依赖# 安装 Python 依赖pipinstallpdfminer.six python-docx# 可选OCR 识别处理扫描件pipinstallpytesseract pillow4.2 告诉 QClaw「我要做一个合同审计技能」这是最有意思的部分——你不需要手动创建任何文件直接用自然语言和 QClaw 对话它就能帮你把技能从头到尾做出来。打开 QClaw直接发送我想做一个工程合同风险审计技能能帮我自动审查采购合同里的风险条款识别赔偿上限过低、违约金不对等、验收标准模糊这些问题最后输出一份结构化的审计报告。4.3 QClaw 根据你的需求自动生成技能框架QClaw 消化了你的需求开始生成技能内容。这个过程你不需要参与只需要等待它告诉你「技能已创建完成」。大约几分钟后QClaw 会返回「搜索一下相关的技术实现参考和最佳实践现在我已经了解了技能创建的最佳实践。让我为你设计这个工程合同风险审计技能1. 技能配置文件SKILL.md技能名称contract-risk-audit触发关键词审查合同、审计合同、检查合同风险、合同风险 等2. 知识库文件references/standard_template.md— 已根据你发来的合同模板整理好核心条款references/risk_rules.md— 内置了以下风险识别规则RISK-001赔偿上限过低 30% 合同金额为高风险RISK-002违约金权责不对等甲乙差距 200% 为高风险RISK-003验收标准模糊出现合理标准等表述触发RISK-004管辖权不利约定异地管辖触发3. 文本处理脚本scripts/extract_contract.py— PDF/Word 文本提取scripts/compare_template.py— 条款拆分、相似度比对、风险量化4. 工作流程用户上传合同 → 提取文本 → 识别条款类型 → 与标准模板比对 → 应用风险规则 → 生成审计报告然后我们可以根据内容确认或提出修改比如我这里还想调整一下赔偿上线阈值「基本没问题但赔偿上限的阈值我想调高一点我们公司要求至少 35% 才算达标低于这个值就要标高风险。另外增加一条规则付款条件里如果只写’验收后付款’没有具体天数也作为风险标记。」之后可以看到其成功更新技能4.4 调试技能——用真实合同跑一遍技能框架生成之后需要测试一下效果。QClaw 支持直接在对话中模拟运行。发送阅读测试合同文本_设备采购合同,合同金额 500 万重点关注赔偿上限和违约责任。QClaw 启动技能执行等待片刻后其会输出完整的审计报告每条风险包含条款位置、原文摘录、风险描述、量化数据潜在损失金额、修改建议措辞。技能不是一次性做完就结束了而是在实际使用中不断打磨。**使用过程中又发现了一些可以优化的地方规则不够用「上次审一份设备租赁合同里面有条’提前解约需赔偿6个月租金’这个条款挺苛刻的但技能没识别出来。能否增加一条关于解约赔偿的规则」QClaw「新增规则提前解约赔偿过高风险等级中风险触发阈值赔偿 ≥ 3个月租金/费用」4.6 查看和管理你的技能技能开发完成后可以通过 QClaw 随时查看技能状态和管理技能查看已创建的技能「列出我目前安装的所有技能」更新技能如果之后想调整技能直接告诉 QClaw「contract-risk-audit 的风险阈值帮我改一下高风险从35%调整为40%」QClaw 会直接更新对应的规则文件不需要你手动去改代码。导出和分享「把这个技能导出来分享给同事」QClaw 将技能打包通过邮件或链接分享同事收到后可以直接安装到自己的 QClaw 中使用。五、一次真实的使用过程我用一个实际场景来展示整个流程。某项目需要审核一份供应商发来的设备采购合同合同金额 500 万元法务需要在下班前给出审查意见。以前这至少要花两个小时这次我试着让 QClaw 来做。第一步上传合同我把 PDF 发给 QClaw说明了审查要求帮我审查这份合同的风险重点看赔偿上限、违约责任和验收标准技能自动激活。第二步文本抽取技能识别到是 PDF 文件调用extract_contract.py进行文本提取。因为是原生 PDF不是扫描件文字直接被提取出来耗时约 30 秒。第三步模板比对技能读取了公司标准采购模板的 28 条核心条款开始逐条比对。比对结果出来了几条差异较大的条款条款类型标准模板内容合同实际内容相似度赔偿上限赔偿上限不低于合同金额的30%赔偿上限为50万元35%违约金甲方甲方的违约金为合同金额的10%甲方违约金为5%60%违约金乙方乙方的违约金为合同金额的10%乙方违约金为15%55%验收标准符合GB/T 28288-2012国家标准以双方认定的合理标准为准42%第四步风险识别与量化技能对每条差异条款应用风险规则生成量化结果赔偿上限条款——合同约定的赔偿上限是 50 万元仅为合同金额的 10%远低于行业普遍认可的 30% 下限。技能自动计算了潜在最大损失450 万元。这条被标为高风险。违约责任条款——甲方的违约金是合同金额的 5%乙方是 15%差距比例达到 300%属于明显的权责不对等。这条被标为中风险技能同时指出此类条款在诉讼中可能被法院依职权酌减但会增加纠纷处理成本。验收标准条款——合同使用了「以双方认定的合理标准为准」这样的表述缺少量化指标。技能识别出这类模糊表述容易在履约阶段引发争议建议改为具体的性能参数或检测方法。第五步审计报告生成整个过程从上传文件到拿到完整的审计报告大约用了十五分钟。结果以结构化报告的形式输出═══════════════════════════════════════════════════════════ 工程合同风险审计报告 ═══════════════════════════════════════════════════════════ 合同名称设备采购合同供应商XXX机械有限公司 合同金额500万元 审阅时间2024-XX-XX XX:XX 审阅耗时15分钟 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 风险摘要 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 高风险1项 中风险2项 低风险0项 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 风险详情 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【高风险】RISK-001赔偿上限过低 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 条款位置第12.2条 合同原文供方应承担的最高赔偿额不超过合同总价的10% ⚠️ 风险描述赔偿上限50万仅为合同金额的10% 远低于行业通行的30%基准线 量化数据潜在最大损失 450万元 ✅ 修改建议将赔偿上限调整为合同金额的30% 即150万元 【中风险】RISK-002违约金权责不对等 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 条款位置第13.1条 合同原文甲方违约按合同金额的5%支付违约金 乙方违约按合同金额的15%支付违约金 ⚠️ 风险描述甲乙双方违约金比例差距达300% 存在明显不公平条款 量化数据潜在纠纷成本 ≈ 50万元按诉讼成本估算 ✅ 修改建议将甲方违约金调整为10%与乙方对等 【中风险】RISK-003验收标准模糊 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 条款位置第8.3条 合同原文设备验收以双方认定的合理标准为准 ⚠️ 风险描述缺少可量化、可检测的具体标准 容易引发履约争议 量化数据潜在履约争议损失 ≈ 25万~75万元 ✅ 修改建议改为「设备性能须符合GB/T 28288-2012 国家标准要求具体指标见附件」 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 审阅结论 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 本份合同存在一项高风险条款和两项中风险条款 建议在签署前与供应商就上述条款进行协商修订。 ═══════════════════════════════════════════════════════════ 本报告由 QClaw 合同风险审计技能自动生成 ═══════════════════════════════════════════════════════════法务的工作从「从头审」变成了「看报告确认结论」时间从两三个小时压缩到了十几分钟。结语这次用 QClaw 做合同审计技能的经历是我第一次认真地把一个工作中的痛点用 Skill 的方式解决掉。做之前觉得可能很复杂做下来发现思路理清楚之后实现并不困难。更重要的是这个过程让我对 Skill 这个机制有了更具体的理解——它本质上解决的是「AI 在垂直领域的知识怎么注入」的问题。不管是合同审查还是其他有明确规则和流程的工作其实都可以用类似的思路去做。回顾整个开发过程OpenClaw/QClaw 的生态其实已经相当完善了本地化的数据安全保证、多平台消息通道的便捷性、ClawHub 技能市场的丰富度以及 Skill 开发本身对非专业程序员也友好的设计——这些都是能让你快速跑通一个想法的有利条件。如果你也在工程行业工作日常工作里有不少重复性的审查、比对、核对工作不妨想想这里面有没有可以用 Skill 自动化掉的部分。这次玩虾大赛就是一个很好的契机不妨动手试试。