双语合同完善 / 模板残留清理（中英对照法律服务协议等）

适用场景

莎莎 / Maggie / 客户直接交办一份"在现有草稿基础上完善"的中英对照合同（法律服务协议、委托代理协议等），不走 Doro 的 uwf workflow。草稿往往是从所内旧模板 / 旧案改来的，残留前案痕迹。

铁律1：模板残留是常态，必须逐条中英对照

律所复用双语模板时，中文侧和英文侧可能各自残留不同旧案的内容，且核心商业条款中英文互相矛盾。普力克 Procore 案（2026-06-25）实例：

中文侧整体是"社保调查"案，英文侧整体是"喆航买卖合同纠纷"案——两个不同旧案混在一份草稿里
客户名残留旧客户（艾达 / AMOS），分布在抬头、正文、付款条款第三方代付人、签署页多处
费率：中文 2,500 元/小时·2-3 小时一次性；英文 2,000 元/小时·每月 5-6 小时——三项数据互相打架
付款：中文付全额；英文付 50% 即 72,500 元 + AMOS 新加坡公司代付

做法：python-docx 提全文（含 doc.tables），把每个条款的中文段和紧邻的英文段配对，逐条比对。重点盯：服务内容、服务范围、主要联系人、费率、工时、付款方式/金额、第三方付款人、签署日期。

铁律2：商业条款绝不替客户猜，先确认后动手

费率、金额、工时、付款分期、第三方代付——这些是商业条款。草稿里中英文打架时不能自己挑一个填进去。把所有矛盾点列成清单，让委托律师给准数，确认后再出稿。本案先问了 7 点（真实业务事由 / 非诉 or 诉讼 / 联系人 / 费率 / 工时 / 收款方式 / 签署日），拿到 3 点核心确认（服务内容=王晓玲社保调查、费率 2,500×2-3 小时一次性全额、签署日 6/25）才动手。

铁律3：以中文为准 → 先定中文，再对齐英文

协议若含"如有出入以中文为准"条款（多数中英对照协议都有），完善顺序必须是：先把中文条款定稿，再逐条把英文改成与中文一致。用户本案也明确指示此顺序。这样既符合协议约定，也符合用户预期。该兜底条款审完保留——对己方有利，不要删。

技术：段落级 run 合并替换（保格式整段替换）

python-docx 里一个段落常被切成几十个碎 run（中文逐字符切、英文逐词切，bold/size 各异）。整段替换文本又要保留段落样式，用这个函数：

def set_para_text(p, text):
    """整段文本写入第一个 run，清空其余 run，保留首 run 格式。"""
    if not p.runs:
        p.add_run(text); return
    p.runs[0].text = text
    for r in p.runs[1:]:
        r.text = ""

表格单元格同理：set_para_text(cell.paragraphs[idx], text)
删除整个空段落（如清掉被替空的旧英文残段，避免留空行）：el = p._element; el.getparent().remove(el)
替换后务必复查：遍历全文（段落 + 表格 cell）拼成大字符串，断言旧内容（艾达/AMOS/旧金额/旧费率等）not in full，再断言新数据出现次数正确。

验收：多页 OnlyOffice 渲染 → 逐页 vision 核对

单页固定版面用 print-ready-pdf/scripts/oo_render_check.sh。多页双语合同用以下管线（Maggie/Doro/莎莎都用 OnlyOffice 看文件，必须用 x2t 不用 LibreOffice）：

docker cp file.docx nextcloud-onlyoffice-1:/tmp/_chk.docx
# 容器内写 TaskQueueDataConvert xml，m_nFormatTo=513，跑 x2t（见 print-ready-pdf）
docker cp nextcloud-onlyoffice-1:/tmp/_chk.pdf /tmp/out.pdf
pdftoppm -png -r 110 /tmp/out.pdf /tmp/pg     # 每页一张 PNG

然后 vision_analyze 逐页核对：客户名、服务内容、费率、付款方式金额、签署日期、签署页主体、中英一致性。

铁律4：vision 报"截断/截字/多空格"先回源核实，别急着改

justified（两端对齐）渲染图里，vision 模型会把以下正常排版现象误报为"文字截断/排版错误"——本案一次任务里就误报了 4 次：

跨页连字符断词（第1页底 accor- → 第2页头 ding）
跨页句子接续（第4页底 Negotiations shall → 第5页头 commence...）
两端对齐的字距假象（with 被读成 wit h）
两端对齐的自动换行断词（aforemen / tioned，且无连字符）

判断方法（任一即可证伪 vision 的"截断"）：

从源 docx 读该段 p.text，确认是完整单词 / 完整句子；
查 word/settings.xml 是否含 autoHyphenation（没开就不会真断字）；
查文本不含软连字符 \u00ad。

渲染层表象 ≠ 文档缺陷，Word / OnlyOffice 编辑视图会正常回流。

铁律5：关键数据（账号/金额/信用代码）逐字符回源核对，不信 vision 读数

vision 把收款账号 121955296610001（15 位）读成 12195296610001（漏 1 位）。账号、金额、统一社会信用代码这类关键数字，必须从源 docx 逐字符提取核对，绝不采信 vision 对渲染图的读数。本案账号与原稿逐位一致，确认后未改。

顺手订正范围（"条款明确得当"要求）

完善双语合同时，除主体/商业条款外，一并修掉：

中文病句（"在上述法律服务作为客户的代理人" → "就上述法律服务事项作为客户的代理人"）、错别字（"疑异"→"疑义"）、异体字（"⻓"→"长"）
英文逗号粘连句（comma splice，逗号改分号或加 and）、口语化用词（"really" → "truthfully"，与同条 "faithfully" 体系一致）

交付

命名规则：当事人名称+文件名称+版本+修改人+日期（本案：普力克贸易（上海）有限公司-法律服务协议-v1-20260625.docx）
本类任务默认交"用印前清稿"（直接定稿、非修订模式）。若需带修订痕迹版本供对方/同事看改了哪些，另出一版 tracked changes（用 ContractEditor 库，不裸写 XML）。交付时主动告知用户这两种版本的区别，问要哪种。

6.0 KiB Raw Blame History