合同审核助手

要解决什么问题

法务或业务同事拿到的合同往往是 Word .docx，需要逐条看付款、违约、知识产权、争议管辖等条款，还要留意正文里的金额、账号、税号、联系方式等敏感信息。人工通读成本高，且批注要落在原文对应段落上，不能只给一份纯文字清单。

本技能把这条链路做成可重复流程：从可编辑的 .docx 抽正文 → 用大模型生成「原文片段 → 风险批注」的 JSON → 脚本校验与补全 → 写回 Word 原生批注。

工作方式

1. 文本提取：用 extract_docx_text.py 从段落、表格、页眉页脚抽取合同全文，替代类似 Dify 文档抽取节点的能力。
2. 风险标注 JSON：按 references/llm_prompt.md 的 system prompt，将 {{DOC_TEXT}} 替换为正文；输出键为合同中 8～80 字且逐字存在 的片段，值为 【风险等级】风险点：…；风险后果：…；修改建议：… 格式。关注领域包括付款、验收、责任与赔偿、解除、争议解决、保密、知识产权、交付、通知与期限等。
3. 清洗与校验：clean_annotations.py 检查文档长度、校验键是否在原文中出现、用正则 自动标敏感信息（金额、银行账号、税号、电话、邮箱、地址、合同编号等），在模型输出不足时用关键词规则兜底，并将总批注数限制在 20 条以内。
4. 写入批注：can_generate 为 true 时，add_word_comments.py 直接操作 OOXML：先精确匹配再按阈值（默认 0.55）模糊匹配，插入 commentRange 并生成 comments.xml，得到带批注的 .docx。

默认批注作者为「法务审核助手」，可通过 --author 修改。

适用边界

• 输入必须是 标准 .docx，正文可选中编辑；扫描件、图片版 Word、.doc 或纯图片段落需要先 OCR 或另存为可读文本。
• 若键无法在原文中匹配（含页眉页脚、文本框、受保护区域），can_generate 可能为 false，应查看 debug 输出并确认文件格式。
• 模糊阈值过低（如 0.40）可能产生误匹配；1.0 则仅精确匹配，对 OCR 或排版差异更苛刻。