3.7 KiB
3.7 KiB
已交付合同批量质检方法 (2026-07-13)
触发条件
Doro要求"逐一审查已交付合同的修订有哪些问题"
方法
准备
- 读通用 review-rules.md + 对应顾问单位特殊规则——每次都tool call读取，不凭记忆
- 确认哪些是今天交付的（按任务交付目录文件的mtime筛选）
- 一份一份做，pass一份再做下一份
numPr断裂检查（2026-07-13 消防设施检测案教训，最易遗漏）
新增WB INS段落如果插在auto-numbered序列（原文段落有numPr）中，必须有相同numPr：
- 检查原文被插入位置前后段落是否有numPr
- 如果有（如numId=4, ilvl=0），新增段落也必须有同一numPr
add_clause默认strip numPr（A类设计），在B类自动编号段落中会导致编号断裂- 修法：手动用zipfile+lxml克隆邻近段落的pPr（含numPr）给新增段落
独立段落 vs 合并到现有条款的判断
当新增内容插在有手动编号（1、2、3、）的章节中时：
- 新内容与前一条主题紧密相关（如数据归属+保密）→ 合并到前一条末尾，不独立编号
- 新内容是独立主题→ 编号为下一个序号
- 这是审查者应当自行判断的专业决定，不问Doro
字体修复的per-paragraph策略
同一合同中不同段落可能有不同的字体继承模式：
- 段落A:
ascii=宋体, hAnsi=宋体, cs=宋体, sz=24（显式设置） - 段落B: 完全无rFonts（靠docDefaults继承） 不能全局统一处理——必须逐段对比orig run属性，INS run匹配同段orig run
每份合同检查项
A0. 完整性检查（先于内容审查）
- 必须同时检查 tracked changes + comments.xml + footers/headers
- 用
zipfile读word/comments.xml提取所有批注数量和内容 - 段落文本100%相同 ≠ 文件完全相同（可能有批注但无修订）
- 2026-07-13教训：v2被误判为"与原文完全相同"，实际有6条WB批注。python-docx的
.text不反映批注内容
A. 检测重复处理
待审查文件是否已有WB修订？如果有，交付版是否产生了重复文字/重复INS。
B. 修订内容 vs 审查清单（10条逐条对照）
- 主体条款：名称是否正确、是否直接改了不批注
- 违约责任：是否有维权费用（律师费、诉讼费、保全费）
- 争议解决：是否甲方所在地法院
- 保密/数据：数据归属+保密存续+泄露责任
- 知识产权：成果归甲方+终止后继续使用
- 第三方侵权：乙方全责+全额赔偿甲方
- 转包/分包：限制条款
- 价款条款：金额不一致是否批注
- 服务成果持续使用权
- 条款逻辑
C. 批注合规检查
- 每个WB批注逐条对照规则：
- 是否涉及商业条款？（日期/期限/金额/支付方式/频率/天数 → 不应有）
- 是否能直接修订？（能改就改不批注）
- 是否有【】标签或理由解释？（禁止）
- 是否有"建议考虑""请考虑是否"等模糊措辞？（禁止）
D. 格式检查
- INS run的rPr与同段原文run逐属性对比（sz/rFonts/bold）
- 新增章节标题格式是否与原文章节标题一致
- 新增正文段落pPr（ind/spacing/numPr）是否与原文同类型段落一致
- 单段正文不加numPr（"有2才有1"规则）
E. 交叉引用/编号
- 新增条款后原文编号是否顺延
- 接受修订后无重复编号/无跳号
报告格式
每份合同列出：
- 问题1/2/3...（严重/中等/轻微）
- 格式是否OK
- 是否需要修复
铁律
- 先查文件再说话（不凭印象判断）
- 一份做完确认后再做下一份
- 修复时从待审查原文出发，不在被污染的交付版上修