82 lines
3.7 KiB
Markdown
82 lines
3.7 KiB
Markdown
# 已交付合同批量质检方法 (2026-07-13)
|
|
|
|
## 触发条件
|
|
Doro要求"逐一审查已交付合同的修订有哪些问题"
|
|
|
|
## 方法
|
|
|
|
### 准备
|
|
1. 读通用 review-rules.md + 对应顾问单位特殊规则——**每次都tool call读取，不凭记忆**
|
|
2. 确认哪些是今天交付的（按任务交付目录文件的mtime筛选）
|
|
3. 一份一份做，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条逐条对照）
|
|
1. 主体条款：名称是否正确、是否直接改了不批注
|
|
2. 违约责任：是否有维权费用（律师费、诉讼费、保全费）
|
|
3. 争议解决：是否甲方所在地法院
|
|
4. 保密/数据：数据归属+保密存续+泄露责任
|
|
5. 知识产权：成果归甲方+终止后继续使用
|
|
6. 第三方侵权：乙方全责+全额赔偿甲方
|
|
7. 转包/分包：限制条款
|
|
8. 价款条款：金额不一致是否批注
|
|
9. 服务成果持续使用权
|
|
10. 条款逻辑
|
|
|
|
#### C. 批注合规检查
|
|
- 每个WB批注逐条对照规则：
|
|
- 是否涉及商业条款？（日期/期限/金额/支付方式/频率/天数 → 不应有）
|
|
- 是否能直接修订？（能改就改不批注）
|
|
- 是否有【】标签或理由解释？（禁止）
|
|
- 是否有"建议考虑""请考虑是否"等模糊措辞？（禁止）
|
|
|
|
#### D. 格式检查
|
|
- INS run的rPr与同段原文run逐属性对比（sz/rFonts/bold）
|
|
- 新增章节标题格式是否与原文章节标题一致
|
|
- 新增正文段落pPr（ind/spacing/numPr）是否与原文同类型段落一致
|
|
- 单段正文不加numPr（"有2才有1"规则）
|
|
|
|
#### E. 交叉引用/编号
|
|
- 新增条款后原文编号是否顺延
|
|
- 接受修订后无重复编号/无跳号
|
|
|
|
### 报告格式
|
|
每份合同列出：
|
|
- 问题1/2/3...（严重/中等/轻微）
|
|
- 格式是否OK
|
|
- 是否需要修复
|
|
|
|
### 铁律
|
|
- 先查文件再说话（不凭印象判断）
|
|
- 一份做完确认后再做下一份
|
|
- 修复时从待审查原文出发，不在被污染的交付版上修
|