feat: export core Hermes skills
This commit is contained in:
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,996 @@
|
||||
---
|
||||
name: contract-portfolio-analysis
|
||||
description: 合同组合分析——批量OCR、独立法律审查、模版对比、三角色校对、Excel汇总表制作与台账维护。适用于多校区/多合同的批量梳理与持续维护项目。
|
||||
version: 1.12.0
|
||||
tags: [合同, 批量分析, 模版对比, Excel, OCR, 租赁, 法律审查, 三角色校对, 台账维护]
|
||||
triggers:
|
||||
- 批量合同梳理/分析
|
||||
- 多校区合同汇总
|
||||
- 合同与标准模版对比
|
||||
- 合同组合风险分析
|
||||
- 租赁合同汇总表制作
|
||||
- 汇总表更新/维护
|
||||
- 租赁台账维护
|
||||
- 新增租赁合同
|
||||
- 合同到期更新
|
||||
- 提前解除/退租更新
|
||||
---
|
||||
|
||||
# 合同组合分析（Contract Portfolio Analysis）
|
||||
|
||||
## 适用场景
|
||||
客户有大量已签署合同需要梳理（如多个校区的租赁+物业合同），要求：
|
||||
- 逐份提取关键信息
|
||||
- 与标准模版对比差异
|
||||
- 提取变更/解除条款
|
||||
- 汇总为结构化Excel表格
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 元规则：workflow 是必经清单，必须逐项严格执行；不得擅自改动（Maggie 2026-06-22 确立）
|
||||
|
||||
**这条管的是「怎么对待 workflow 本身」，优先级排在所有内容铁律之前。**
|
||||
|
||||
- **每个校区都必须按本 skill 完整逐项执行**——Step 0→7（单校区闭环 Step 0→6 + 全局收尾 Step 7）+ 三角色校对 + H列三件套 + **末尾整体风险分析与建议段** + 需核实标红，**一步都不能跳、不能简化、不能凭「上个校区做过的印象」代替**。Maggie 原话：「以后每个校区都需要按照 workflow 来做。」
|
||||
- **不得擅自改动 workflow**：流程的任何增删改（跳过校对、省掉整体分析段、改列结构、改 Step 顺序、改交付方式等）都必须**经 Maggie 明确授权**；授权的调整**固化进本 skill 后才算数**，未固化的一律按原 workflow。我不能自行决定「这步这次不用做」。Maggie 原话：「不能擅自改动 workflow。」
|
||||
- **悦拾光教训（2026-06-22）**：被要求「做好汇总表」后，凭「世茂做过」的印象裸做，擅自跳过了三角色校对、末尾整体风险分析段、H列付款安排标红、需客户核实标红——被 Maggie **连续四次**追问「你有按 workflow 操作么 / 在做了么」。根因：把 workflow 当参考而非必经清单，把「做表」误判成机械画格子活、绕过 skill 直接 openpyxl 裸写。（详见 Pitfall 16）
|
||||
- **落地**：每个校区开工前，**先把 workflow 步骤列成 todo 逐项打勾**；交付前对照清单确认每一步都做了，**缺一项不交付**。Maggie 验收必查两件事：(a) 标准板块齐全（尤其整体风险分析与建议段）；(b) 是否真走了 workflow——两者缺一即返工。
|
||||
|
||||
---
|
||||
|
||||
## 🔴🔴 开工铁律：每个校区跑「单校区开工闸门」脚本，从头独立做（Maggie 2026-06-23 立，最高优先级之一）
|
||||
|
||||
**这条专治「开新校区时凭上个校区的印象乱跑/跳步」。是物理闸门，不是靠记性。**
|
||||
|
||||
### ① 开工第一个动作 = 跑闸门脚本（不跑不准动手）
|
||||
开始任何一个校区（新建/续做/重做）的**第一件事**，先在终端跑：
|
||||
```bash
|
||||
python3 ~/.hermes/skills/legal/contract-portfolio-analysis/scripts/campus-workflow-gate.py <校区名>
|
||||
```
|
||||
它会打印：单校区独立闭环纪律 + 完整 Step 0→7 workflow + 该校区源文件夹定位 + 汇总表存放路径 + 待打勾 todo。**把它吐出的 todo 贴进 todo 工具逐项打勾**。没跑这个脚本、没建这份 todo，就不算开工，不准开始填表。
|
||||
|
||||
### ② 单校区独立闭环纪律（核心）
|
||||
**每个校区都是「第一次」，从 Step 0 从头到 Step 6 独立完整跑一遍（Step 7 总览是全部校区定稿后的全局收尾），不受任何其他校区影响：**
|
||||
- **不拿别校区的印象代替本校区的实做**——「世茂/悦拾光是这样做的」「上个校区这么定级」这类印象，**一律不假设适用于本校区**。本校区的逐字通读、八维审查、回 07 原件比对，每一项都要在本校区原文上从头做。
|
||||
- **别校区的结论/定级/措辞，统统不迁移**。一切回本校区合同原文重新判断。这是「全新合同全面审」，不是「套上一份的模子」。
|
||||
- **为什么立这条**：批量做时，注意力被格式/效率分散，最容易「这份大概和上一份一样」地跳读跳审——人不会觉得自己跳了，但判断地基已经空了（与「第一铁律·逐字通读」的批量失效模式同源）。开工闸门脚本就是强制把「每个校区从头来」顶在最前面。
|
||||
|
||||
### ③ 汇总表存放纪律（Maggie 2026-06-23 立）
|
||||
**每个校区做完，汇总表存到该校区自己的文件夹下**，与该校区合同放一起，便于客户对照查阅：
|
||||
- 存放路径：`小Maggie协作区/南通新东方/履约期内非集采合同-综办/房租物业合同/<校区名>/`
|
||||
- 命名：`<校区名/项目名>-梳理-MJ-YYYYMMDD.xlsx`（当事人/项目名+文件名+修改人+日期）
|
||||
- **不放公共目录、不放别的校区文件夹、不只留本地 /tmp**。17 个校区各自的汇总表归各自文件夹。
|
||||
- 总览 sheet 是所有校区定稿后最后整合的产物（见 Step 7），与「各校区表存各校区文件夹」不冲突——单校区表归位在前，总览整合在后。
|
||||
|
||||
### ④ 与既有规则的关系
|
||||
本节是「元规则·workflow 必经清单」的开工落地抓手，与「Pitfall 18·禁止 openpyxl 裸做」「第一铁律·逐字通读」三位一体：元规则定「必须走流程」，本节定「每校区从头独立走 + 开工先跑闸门 + 表归各自文件夹」，Pitfall 18 定「别绕过 skill 裸写」。三条一起堵死「开新校区自己乱跑」。
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 第一铁律：每份合同每份文件，亲自逐字逐句通读理解后再判断（Maggie 2026-06-22 确立，刻进骨子的律师基本严谨）
|
||||
|
||||
**这是本 skill 所有规则的地基，排在最前面。** Maggie 原话：「你要把每一份合同每一份文件都逐字逐句自己阅读理解并审查，刻在骨子里，这是做一个律师工作最基本的严谨。」
|
||||
|
||||
- **铁律本身**：法律审查/填表/下任何结论前，必须**亲自 `read_file` 把该合同整篇 OCR 原文（含全部附件）从头读到尾、读懂每条的语境与语义**。`禁止`用以下任何一种代替通读：① subagent 的提取报告 ② `grep`/`search_files` 命中单行 ③「这套合同我见过、大概是这样」的印象式推断。源头（读原文）必须在自己手里——这与「三角色分工·法律审查动作A不外包」「第0步·审查第一性原则」是同一条骨架，本条把它提到全局第一位。
|
||||
|
||||
- **🔴 批量场景是这条铁律最容易失守的地方（必须正视的失效模式）**：一次做 4+ 份合同时，注意力被「填表格式、行高、防 subagent 超时、跨表联动」分散，逐字通读这一步会**悄悄退化**成「提取报告说啥我核个大概」——人不会觉得自己跳读了，但判断的地基已经空了。**越是批量、越要顶住，每一份都亲自从头读完，不因为是第 3 份第 4 份就打折。**
|
||||
|
||||
- **自检信号（出现即说明我没真读）**：用户就某条款问一个具体问题（如「这里能不能推算」「这个填空是什么意思」「依据是什么」），我**一回原文、30 秒就核出答案**——这恰好证明答案一直在原文里明摆着，**之前没去逐字读**。凡是「用户一问、回原文秒答」的，根因都是当初没通读，不是题目难。
|
||||
|
||||
- **没真读的两类典型产物（2026-06-22 世茂高中物业实证，均在 ⑤b 详述）**：① 因果方向写反（9.1/10.1「物业违约连带触发租赁解除」——原文是单向「租赁终止则物业终止」）；② 选填留空 `/` 当真实备选项论证（「填空额取高」）。两个都是「没读懂原文就下笔」的直接产物，逐字读过绝不会发生。
|
||||
|
||||
- **逐字通读会主动捞出选择性审查漏掉的真问题（同日世茂物业实证）**：亲自通读两份物业全文后，发现 K列漏审了 ① 高中物业 8.3/8.4/8.5 甲方违约责任（双倍保证金赔偿等，**对乙方有利**）② 6.2/6.3 甲方可转让+「乙方15日内不配合签转让协议视为同意+甲方可解约」（沉默视同意，**对乙方不利**）③ 3.1.3 乙方违约全部保证金作违约金——挑审/靠提取报告时全漏了。**逐字读不是慢，是把本该发现的风险真的发现。**
|
||||
|
||||
- **落地**：续做/校对/交付前，凡涉及对某合同下法律结论，先确认「这份我本人逐字读过整篇原文了吗」；没有就先读，OCR 没有就先 OCR（扫描件无文字层走 tesseract，见 Pitfall 4）。读完再走「整合质询三对撞」「⑤b 法律结论核证」收口。
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 铁律：模版差异 ≠ 法律风险（Maggie 2026-06-16 确立）
|
||||
|
||||
**法律审查 和 模版比对 是两件性质完全不同的事，绝不能混为一谈：**
|
||||
|
||||
| | 法律审查（动作A） | 模版比对（动作B） |
|
||||
|---|------------------|------------------|
|
||||
| 回答的问题 | 合同**本身**有没有法律风险 | 现实情况 vs **内部合规要求**差多少 |
|
||||
| 参照系 | 法律 + 司法实践 | 客户的标准范本 |
|
||||
| 做法 | 当作**一份新合同全面审** | 中性陈述差异 |
|
||||
| 性质 | 法律风险判断 | 合规差距说明 |
|
||||
|
||||
- **不能用"和模版有无差距"代替"有无法律风险"**。模版比对的目的是让客户了解现状与内控标准的差距，**不能作为合同本身法律风险的判断依据**。
|
||||
- 一份合同可能**完全符合模版却仍有法律风险**（条款歧义、引用失效法规、约定履行不能的义务——模版覆盖不到）；也可能**大幅偏离模版却无实质法律风险**（纯商业安排或措辞不同）。
|
||||
- ❌ 旧做法里隐含的等号"模版有、本合同没有 = 风险"是**错的**，已废止。
|
||||
- 汇总表中"法律风险"信息（动作A产出）与"模版差异"信息（动作B产出）**分列**，并注明两者性质区别，避免下游把合规差距误读为法律风险。
|
||||
|
||||
→ 完整审查框架见 `references/independent-legal-review-framework.md`（八维框架），模版比对方法论见本文「模版对比方法论」节。
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 核心工序：填表前的「整合质询」（Maggie 2026-06-17 世茂提成教训确立，对治"信息在手却没整合"）
|
||||
|
||||
**这是我主审的必经工序，不是可选项。** 病灶诊断（必须正视）：提成漏判、违约金摘单句，根因都**不是信息没拿到**——提取报告早标了"提成比例%空缺"、合同里违约金兜底句白纸黑字写着。错在**读到了分散的信息，却没把它们对撞成完整判断**就直接填表了。光靠"记得仔细点"防不住，状态一松就漏。所以把"整合"从脑内一闪念，固化成填表前的强制动作。
|
||||
|
||||
### 做法：每个关键字段进表前，先过「三对撞」
|
||||
|
||||
对**金额、面积、期限、违约金、解除权、优先权、续租、保证金**等每个要进表的关键字段，填之前必须主动问三句、并在脑中（或主审清单里）确认一遍才能落笔：
|
||||
|
||||
1. **空缺对撞**——这个数额/比例/期限，原文对应的**填空位真的填了数额吗**？还是 `/`、空白、"待定"、"另行约定"？
|
||||
- 空缺 → 该机制实践中不适用，按"实际如何"写，不照搬字面（提成栽点：比例空缺=提成不适用=实际按保底）。
|
||||
- ⚠️ **反向陷阱：下"留白/未约定"结论前，必须穷尽 正文条款 + 全部附件 + 补充协议 三处出处，别拿"我提取的那一处没写"当"全合同没约定"（2026-06-18 世茂高中租赁2028租金教训）**。世茂栽点：高中租赁（3023双签版）附件三只约定了 2026/1–2027/12 保底租金，提取只读了附件三 → 表里记"2028年度第3年留白"；实际**正文第3.1条**已明确约定 2028 年度：不含税 **6,689.17 元/月**、含税 **7,291.2 元/月**（税率9%）、或营业额2%提成两者取高。是 Maggie 截图正文第3.1条才捞回来的。错因：商业Mall合同金额信息**正文与附件双向分布**——附件三按年列租金却漏了第3年，正文3.1条反而把全程（含第3年）写全了。这与本 skill "金额数字常在附件，正文条款只定规则"的经验**互为补充、不可偏废**：附件可能有**时间/范围缺口**由正文补全，正文也可能只定规则把数额甩给附件——两个方向都要查。
|
||||
- 做法：任何"留白/空白/未约定/第X年缺"落笔前，回 OCR 原文把**正文对应条款 + 每个附件 + 补充协议**都 `grep` 一遍（搜该费用/金额关键词与年度），三处都确认没有，才能记"留白"；一处有就照实补，并按 4d 把数字来源标到**真实出处条款号**（如"正文3.1"而非"附件三"）。补回的数额仍走金额数学交叉验证锁真值（不含税×(1+税率)=含税、单价×面积=不含税、税金/不含税=税率、对比相邻年度递增率是否合常理）。
|
||||
2. **跨条款对撞**——这个字段在**别的条款**有没有被限定、修改、加例外、设前提、做衔接？
|
||||
- 违约金：有没有"守约方/违约方"对等表述？有没有"不足赔偿的赔全部损失"兜底？（万达栽点：摘"2个月"漏了兜底全赔+对等适用）
|
||||
- 期限：物业期限 vs 租赁期限对不对得上？（世茂青少物业2024/3 vs 新租赁2025/12）
|
||||
- 解除权/优先权：正文说有，附件/补充协议有没有改掉、放弃掉？
|
||||
3. **字面 vs 实际对撞**——合同这么"写"，**实践中实际怎么执行**？字面机制会不会因某个空缺/前提不成立而落空？
|
||||
- "两者取高"但提成比例空白→取高落空，实际只有保底。
|
||||
- "可续租"但通知期已过/条件未成就→续租权实际已丧失。
|
||||
4a. **跨副本对撞**——同一项目里若有**多份同一套标准格式合同**（如世茂青少+高中都是世茂52+格式、万达各校区同范本），**同一条款号的文本必须逐字相同**。提取后若发现**同一条款在两份副本里数值/表述不一致**，这**几乎必然是 OCR 错误**，不是真实差异——**立即回原图核，绝不把伪差异写进表**。（2026-06-18 世茂6.4装修违约金教训：青少 OCR 读"十倍"、高中 OCR 读"1倍"，我把"青少10倍/高中1倍"当真实差异写进 K列还标"青少畸高"——其实两份同款合同6.4逐字相同，青少那行 OCR 是整行乱码，"十"是"1"的误识。同一范本同条款不一致＝红灯，不是发现。）"十↔1""〇↔0""日↔目"等也是 OCR 高混淆对，和 ‰↔% 同等警惕。处置同费率符号：双跑交叉→不一致即裁图放大、`MEDIA:` 发 Maggie 肉眼终判，不在两个机器结果里挑一个。
|
||||
- **🟢 反向建设性用法：同范本逐字相同特性可「补回」某份 OCR 丢失的字段，不止「揪错」（2026-06-22 悦拾光实证）**：当一份合同某关键字段被**页间断裂/污渍/整行乱码**吃掉、双跑裁图都拿不到时，回它的同范本兄弟合同核同一条款号——既逐字相同，兄弟份的值即这份的真值。实证：悦拾光一期租赁30.3逾期付款违约金率正好卡在第12页末「每逾期一日甲方有权按拖」断行处、费率数字消失在页间，各 psm 裁图都补不到；扩租合同（同星展模板）30.3 OCR 完整「按拖欠金额【3】%…逾期超【7】日停水电」——同范本同条款号，一期那缺口即【3】%。**比裁图发 Maggie 更省一步**（自动闭环，不必劳烦用户看像素）。前提同 4a：必须是**确认的同一套范本**（条款号体系、措辞结构逐条对应），补回数额仍走金额数学交叉验证/兄弟份二次确认。「跨副本对撞」完整双向用法：**不一致→揪 OCR 错；一份缺→拿兄弟份补**。
|
||||
4b. **倍数/比例先换算绝对值再定级（别被大数字唬住）**——违约金"X倍日租金""X%"等，**必须乘出每天/每月的绝对金额，放进合同语境判断高低**，不凭倍数大小拍脑袋。世茂6.4：装修期是免租期，按营业期日租金折算——1倍≈1,100元/天=督促按期开业的常规违约金（**不构成风险点**）；若真10倍≈11,000元/天=一天顶三分之一月租金，才叫畸高。**定级看绝对值与语境，不看倍数数字本身大不大。**
|
||||
4c. **租赁违约金/保证金一律换算成"几个月月租金"进表（Maggie 2026-06-18 世茂确立）**——租赁合同的**保证金、违约金**等金额，进 H列/K列时**必须同时给出"=X个月月租金"**，让违约金是否过高一目了然、便于横向比对。物业合同同理换算成"X个月管理费"。
|
||||
- 换算基数：租赁用**月（保底）租金**（14.2"平均月租金"则按租期加权平均月租算）；物业用**月管理费**。
|
||||
- 🔴 **分母陷阱：月租金 = 年租÷12（或半年租÷6），别误把半年租/全年租当分母（2026-06-22 人民中路实证，格式校对揪出）**。栽点：押金39,730元，月租金=119,190.75÷6=19,865元，正确换算≈**2个月月租**；我误用半年租金当分母算成"0.33个月月租"（39,730÷119,190.75=0.33，实为"0.33个半年期租金"）。做除法前先把分母统一成**月**租金，再除。
|
||||
- 实例（世茂）：青少租赁保证金66,230元≈**1.95个月**月租；14.2违约金(平均月租3倍或等额取高)=101,685元=**3个月**月租。高中租赁保证金13,888元=**2个月**月租；14.2违约金=20,832元=**3个月**月租。青少物业履约保证金12,432.72元≈**3个月**管理费；高中物业6,944元=**2个月**管理费。
|
||||
- 写法：金额后加括号注换算，如"租赁保证金：66,230元（≈1.95个月平均月租）""根本违约金(14.2)：平均月租3倍或等额保证金取高=101,685元（3个月月租）"。这是金额提取的**标准动作**，不是可选。
|
||||
4d. **金额条款号标"数字真实出处"，不标正文"请见附件X"的指引条（Maggie 2026-06-18 世茂物业逐条纠正确立）**——给金额加条款号方便核对时，必须标**数字实际写在合同哪一条**，而不是正文里那句"具体金额请见附件一"的指引条。
|
||||
- 世茂栽点（被 Maggie 逐条纠正4次）：履约保证金我标"3.1.1"（正文指引条）实际数字在**附件一1.1**；管理费标"3.3"实际在**附件一第2条**；装修押金标"3.4.1"实际在**附件一3.1**；水电费标"3.6"实际在**附件一4.1**；租赁保证金标"5.1"实际在**附件三2.1**。世茂这类商业合同的金额数字几乎全在附件（附件一费用表/附件三租金表），正文条款只写"详见附件X"。
|
||||
- 做法：标条款号前，回原文确认**数字落地在哪一条**——搜到正文"请见附件X"就继续往附件里翻，找到真正写着数字的那一条（如"附件一第2条""附件三2.1"）再标。一翻就到，才是方便核对。
|
||||
- 条款号格式忠于原文编号体系：世茂用阿拉伯数字（附件一1.1、附件三2.1），万达用中文章节（四、五、第四条一款）——不把万达的"四"硬改成"4.1"，各合同标各自的原生编号。
|
||||
4e. **分档条款先判"本租户属哪一档"，都不属=该条不适用，不照搬档位数字（Maggie 2026-06-18 世茂质量保证金确立）**——合同按业态/类型分档约定金额时（如质量保证金分"充值类≥8万/零售1万/餐饮留空"），**必须先判断本租户（新东方=教育培训）属于哪一档**。
|
||||
- 世茂栽点：质量保证金附件一1.2分三档（充值业务为主≥8万、零售商品`/`留空、美容美发餐饮`/`留空），新东方是**教育培训**机构——三档**都不属于**。我却把"≥8万（充值类）/1万（零售）"照搬进 H列，既误导（像是本合同要交8万/1万），其中"1万"还是 OCR 把零售档留空`/`误识成"1"。
|
||||
- 正解：本租户不属任何档→**该条对本租户不适用，整条不列**（与"提成比例空白→不适用""装修违约金属常规→不列"同理）。绝不照搬不对应的档位数字。
|
||||
- ⚠️ **业态推理优先于 OCR 字符核对**：当"本租户不属任何档"已能凭业态推理判定时，不必纠结某档的留空符号到底是`/`还是"1万"——那是"零售档"的填值，新东方本就不在零售档，符号是几都不影响"不适用"的结论。先用语境（业态归类）判适用性，再决定要不要核字符。这是"字面 vs 实际对撞"在分档条款上的落地。
|
||||
4. **单位/量级对撞**——费率、金额、面积的**单位和量级**是否合理？OCR 文本的符号高度不可信，必须做常识量级核验。
|
||||
- **‰ vs % 是 OCR 重灾区**（2026-06-17 世茂租赁14.1教训）：扫描件 OCR 常把千分号 `‰` 误识为百分号 `%`。世茂4份合同 OCR 全部把"千分之2"识别成"2%"，被 Maggie 当场抓出。
|
||||
- **量级常识闸门**：日费率写进表前先口算年化——每日 X% × 365。**年化超过约 100% 就该警觉**（每日2%=年化730%，荒谬；每日千分之2=年化73%，合理）。逾期违约金/滞纳金日费率，正常落在 万分之几～千分之几（年化 18%～73%），**见到"每日1%、每日2%"先疑 OCR 误识，回 PDF 原件核符号**。
|
||||
- 同理核：折年化标注别算错（0.5%/日=年化182.5%，不是18.25%；万分之5/日才是年化18.25%）。
|
||||
- **OCR 符号判不准时的处理**：扫描件低质量 OCR 对 ‰/% 这种小符号经常判不清，机器反复试无解→**标注"OCR数值，单位以PDF原件为准"，不武断定值**；能看清原件就看（局部裁剪放大），看不清就请 Maggie 核（她看过原件）。绝不拿可疑的 OCR 符号当确定结论填进交付物。
|
||||
- **主动双跑核符号，不止"怀疑"（2026-06-18 世茂物业9.2实证）**：对存疑费率符号别停在"先疑 OCR"——主动跑**两种方法**交叉验证：①整页 OCR；②把该费率行**裁出来放大 3–4 倍单独重 OCR**（tesseract chi_sim+eng 多 psm）。**两次结果不一致 = 已证明机器判不准，立即升级人工**，绝不在两个机器结果里挑一个填表。世茂实证：青少物业9.2 整页读 `0.5%`、裁图重读 `0.5‰`；高中物业9.2 两次分别读 `1%` 和 `1‰`——三跑三种组合，铁证 OCR 不可信。常见误识：`%` 被读成"吃"，`‰` 与 `%` 在不同 psm 间反复横跳。
|
||||
- **升级人工要带"放大裁图"，不甩空问题（2026-06-18 确立）**：机器判不准时，把那一行费率裁出、放大、存 PNG，用 `MEDIA:` 发 Maggie 做肉眼终判（符号就在数字后那一个字符），而不是空口问"是%还是‰"。这是"不把校验责任推给用户"在符号核对上的落地——能做的双跑交叉先做尽，剩下唯一机器解不了的一个像素符号才交人。✅ **vision_analyze 已配好可用（魏玮 2026-06-22 配置，实测能准确读出渲染图的红色标记/文字截断/版面）**：现在符号判不准时**先自己 `vision_analyze` 看裁图终判**，能自核就不必裁图发 Maggie；自核仍拿不准的像素级符号才交人。这是从前"vision provider 未配、只能裁图发人"的升级——主路径变为自核，发人是兜底。命令级配方见 `references/ocr-rate-symbol-verification.md`。
|
||||
- **金额用数学交叉验证，构成自洽 = 不必看图、不必问人（2026-06-18 世茂高中物业管理费实证）**：当 OCR 的**合计/总额不稳**（同一"合计"两跑读成 1347、8472）但**构成项稳定**（不含税 3275.42 + 税金 196.53、单价 9.43×面积 347.2、税率 6%），用**算术关系反推**就是最硬的裁判——比看像素更可靠，且**全自动无需人工**。三条恒等式当探针：①`不含税 + 税金 = 含税合计`（3275.42+196.53=3471.95，自证"合计1347"是误读）②`单价 × 面积 = 不含税`（9.43×347.2≈3274，与 OCR 不含税吻合）③`税金 / 不含税 = 税率`（196.53/3275.42=6.00%，精确命中）。三式互相咬合且与多数稳定 OCR 值一致 → 锁定真值，OCR 那个不稳的总额直接弃用。**适用面**：凡"分项 + 合计"结构（管理费、租金保底=不含税+税金、押金=N月租金）都先做构成自洽核验，再决定信不信 OCR 的总额。比量级闸门更进一步：量级闸门排除荒谬值，数学交叉验证直接算出真值。
|
||||
|
||||
### 铁律
|
||||
- **三对撞过不了，不填表**。任一对撞发现问题，回原文核实清楚再落笔。
|
||||
- **优先用提取报告里 subagent 已标的"空缺/待核"信号**——它标了"提成%空缺"我却没用，是整合失职，不是它没干活。subagent 标的每个"待核/空缺/乱码"都必须在三对撞里被显式处理掉，不能晾着。
|
||||
- **判断过程不写进交付物**（Maggie 2026-06-17）：三对撞是我审查时走的内部工序，汇总表/结论里**只写整合后的最终结论**（如"营业期保底租金"），不写"因提成空缺所以不适用"这类推理过程。过程留给主审清单，交付物只留结论。
|
||||
- **核实痕迹不写进交付物**（Maggie 2026-06-18 世茂确立）：我**自己的核实过程**——"经PDF原件核实""经数学交叉核实""关键数字均经PDF原件+数学交叉核实""（目录XX系扫描漏识L）"等——一律**不进交付物**，删除。客户只需看结论，不需要知道我怎么核的。核实是我的内部责任，留痕在工作记录/主审清单即可。这与"判断过程不进交付物"同源。世茂栽点：青少/高中物业K列写"（9.2，经PDF原件核实）"、高中物业末尾整段"〔关键数字均经PDF原件+数学交叉核实…〕"注脚，被 Maggie 要求全删。
|
||||
- ⚠️ **清理核实痕迹（及任何统一性清理/修正）必须全表扫描，配对合同往往漏一处（2026-06-22 世茂确立）**：青少↔高中、租赁↔物业的同款条款常含同一句痕迹，删一处极易漏掉配对那份。实例：Maggie 手删青少物业 I8 的"经原件核实"，却漏了高中物业 I14 的同款痕迹（"逾期缴费违约金1‰/日(9.2,经原件核实)"），由小Maggie 补扫全表清掉。续做接手/交付前**用脚本全表 grep 痕迹关键词**（经原件核实/经原件/经PDF/经数学/均经…核实/核实〕）确认 0 残留再发——别只清用户点名的那一处。这是「同口径修正必须扫全表对齐」在清理动作上的同一抓手。
|
||||
- **需客户核实的内容整条标红**（Maggie 2026-06-18 世茂确立）：风险点/备注中**需要客户去核实或确认某个事实**的内容，**整条标红**（红色 FFFF0000），方便客户一眼识别待办。
|
||||
- **判据（标红 vs 不标红）**：①只标"**需客户去核实/确认事实**"的——如"服务期衔接需核实""2028年度计租标准建议签约时补明或确认"；②**提示类不标红**——"提示按时缴费""提示知悉""提示自行投保"等是提醒乙方履约注意，不是要客户核实事实；③**我已核实的不标红**（且核实痕迹要删，见上条）。
|
||||
- **范围：整条标红**（从该条编号到句末整条，不是只标"需核实"那半句）。Maggie 先要"只标需核实那句"、后改为"整条标红"——以**整条**为准。实例：青少物业第1条（服务期衔接需核实）、高中租赁第9条（2028租金留白需确认）、整体分析第6点（衔接需核实）三条整条红色。
|
||||
- ✅ **标准做法（2026-06-18 世茂最终验证成功）：openpyxl 写富文本红色 → WPS 打开另存为 xlsx → Excel 不报错且红色保留**。这是"单元格内某条标红、其余黑、且 Excel 兼容"目前**唯一跑通**的路径，Maggie 已亲验 Excel 正常打开+红色在。两步缺一不可。
|
||||
- **技术实现**：openpyxl `CellRichText` + `TextBlock(InlineFont(rFont="微软雅黑", sz=10, color="FFFF0000"), 整条文本)`，黑色段 `color="FF000000"`，按 `\n` 切分逐行判断、整行染色保留换行。务必带 rFont/sz 与全表一致（微软雅黑10），否则富文本丢字体。
|
||||
- ⚠️ **为什么必须 WPS 另存这一步**：openpyxl 把单元格写成 `inlineStr`+`CellRichText`（`<is><r><rPr>…`），不合 Excel 严格 OOXML 校验 → Excel 报"部分内容有问题/需要修复"，点"修复"会**丢弃富文本→红色一并丢失**。试过手改 XML（修 rPr 子元素顺序 rFont→charset→family→sz→color、补 `charset=134`/`family=2`）**都没用**。WPS 容错宽松能正常打开，**且 WPS 另存会把整个文件重写成规范格式（inlineStr→sharedStrings），消除所有不合规处**——这才是 Excel 不再报错的真正原因。验证规范化成功的标志：另存版 xlsx 里 `xl/sharedStrings.xml` 存在（openpyxl 原版没有）。
|
||||
- 🔴🔴 **富文本红必须是 openpyxl 写入的「最后一步」，中间任何 load_workbook→save 都会把红打回纯文本（2026-06-22 悦拾光实证，多次返工教训）**：openpyxl 的 `CellRichText` 在「`load_workbook` 重新加载→`save`」一个来回后**退化成纯字符串**——哪怕这一轮只改了别的格、甚至只改了行高没碰富文本格，红色照样全丢。悦拾光栽点：H5/H6 写好富文本红(9处)后，又去 `load_workbook` 改 K列定性错误、改行高，每改一轮存一次，红色就被打回纯文本一次（红run 9→0），反复三次。**正解：把所有文本编辑（改错别字、补条款、改措辞、改行高 row_dimensions）全部做完定稿后，在同一个脚本的最后一段一次性写富文本红 + `save`，之后绝不再 `load_workbook`**。写完立即用 `zipfile` 读 `xl/worksheets/sheet1.xml` 数 `FFFF0000` 验证（不要用 openpyxl 读回验证——读回这个动作本身无害，但养成「写完只用 zipfile 验、不 load」的肌肉记忆更稳）。顺序铁律：①所有纯文本编辑→②设行高→③最后写富文本红→④save→⑤zipfile验红run→⑥WPS另存/x2t渲染。
|
||||
- 🔴🔴 **二次编辑已标红（WPS规范化）的 xlsx：绝不用 openpyxl 重存——它会把红色全毁掉（2026-06-18 世茂实证）**。WPS 另存后的好文件存储用 `sharedStrings.xml` + 富文本红 `<r>` run；一旦 `openpyxl.load_workbook → 改 → save`，openpyxl 把整表打回 `inlineStr`、**3 处红色 run 直接归零、`sharedStrings.xml` 消失**，Excel 又报"需要修复"——等于把 WPS 救回的成果一键作废。**改一个字都不能用 openpyxl 存。**（本 session 实测：openpyxl 改完 H11 后红色 3→0，结构 sharedStrings→inlineStr，幸亏有 WPS 好基线备份才回得来。所以**改前先把 WPS 好版本另存 `_bak_` 备份**。）
|
||||
- 🔴🔴 **建造阶段（WPS 规范化之前）同样会丢红：每一次 `load_workbook → save` 循环都把 CellRichText 悄悄打回纯字符串，哪怕这次只改了别的格 / 只设了行高、根本没碰富文本格（2026-06-22 悦拾光实证，连丢两次才定位）**。机制：openpyxl 一旦重新加载含富文本的工作簿再 save，所有 CellRichText 一律退化成 str、红 run 归零。所以**富文本红必须是整个建表流程的最后一步**：① 先在同一个脚本里把所有行高设好、所有黑字内容写完；② **最后**才写 CellRichText 红 run；③ `save`；④ 此后**绝不再 `load_workbook`**——要渲染 / 上传直接拿这个文件，要改内容就回到①把整段脚本重跑（含最后写红），不在已写红的文件上二次 load。**验证红色只用「只读 zip 数 `FFFF0000`」**（`zipfile` 读 `xl/worksheets/sheet1.xml` 或 `sharedStrings.xml`），**绝不用 `load_workbook` 复核**——一 load 一 save 红就又归零。典型错序（先写红 → 再 load 设行高 → save）= 红照样没，本 session 正是这样连丢两次。
|
||||
- ✅ **正解：在 `sharedStrings.xml` 的 XML 层做外科手术，红 run 一个字不碰**。流程：①`zipfile` 解压 WPS 好文件到临时目录；②`sheet1.xml` 里每个格子 `<c r="H11" t="s"><v>45</v></c>` 的 `<v>` 就是 **sharedString 索引**——据此把"要改哪个格"翻成"要改第几条 `<si>`"；③lxml 打开 `xl/sharedStrings.xml`，**只替换目标 `<si>` 里的 `<t>` 文字节点**（纯文本格直接重写单个 `<t xml:space="preserve">`；含红 run 的格**只改黑色 `<r>` 的 `<t>`**，红色 `<r>`（带 `<rPr>…<color rgb="FFFF0000"/>`）原样保留）；④重新打包。
|
||||
- ⚠️ **重新打包必须把 `[Content_Types].xml` 放 zip 第一项**（其次 `_rels/`），否则 LibreOffice 等严格解析器报 `source file could not be loaded`（Excel/WPS 宽容，但别赌）。用 `zipfile.ZIP_DEFLATED`，逐文件 `zf.write(full, arc)`。
|
||||
- **删一条红色风险项 + 顺移编号**（如已核实的"留白"风险撤销 → 整条删）：lxml 里定位目标 `<r>`（按 `<t>` 文字开头如 `"9. "` 且含关键词）→ `si.remove(目标<r>)` → 遍历后续 `<r>` 的 `<t>` 把 `"10. "→"9. " "11. "→"10. "` 前缀顺移，保持 1–N 连续。删红 run 时红色计数会随之 −1（删的就是那条红）。
|
||||
- **改完五查**（本地验不了 Excel，这五项是能自动做的最强保证，过了再发 Maggie）：①`xl/sharedStrings.xml` 仍在；②红色 run 数 = 改前预期（删 1 条红就 3→2，没删就不变）——用 `re.findall(r'rgb="FFFF0000"', ss)` 数；③`zipfile.testzip()` 通过 + 所有 `.xml/.rels` 部件 lxml 能 `fromstring` 解析；④目标格文字已更新、编号 1–N 连续、旧表述（"留白/未约定"等）全表 `grep` 0 残留；⑤与 WPS 好基线**部件清单同构**（`set(namelist)` 差异仅空目录条目可接受）。一键跑：`scripts/edit-redmarked-xlsx.py --verify <文件> --baseline <WPS好基线>`。
|
||||
- **最终仍交 Maggie 用 Excel 肉眼终判**（同"本地验不了 Excel"铁律），但上述五查全过再发，不裸交。完整可复用实现（解压→按 si 索引改 `<t>`→删 run 顺移→规范重打包→五查）见 `scripts/edit-redmarked-xlsx.py`。
|
||||
- 🔴 **「红色run数」五查②不是「标红条数」，别拿它当颜色没动坏的护身符（2026-06-22 世茂确立）**：`red_run_count()` 数的是 `rgb=FFFF0000` 串的出现次数，**等于带红 rPr 的 `<r>` 个数**，不等于「有几条风险被标红」。隐藏陷阱：某些长单元格（世茂 K8 青少物业、K11 高中租赁、A16 整体评价）在 WPS 规范化时被整格染红——**该格每个 `<r>`（标题/每条/空行）都带红 rPr**，K8=8 红run、K11=15、A16=20，全表实际红run≈47，而非交付物语义上的「6 处标红提示」。我连续几次编辑都看「红色保持6 ✅」就放心，那个 6 只是凑巧（H5/H8/H11/H14 四个单纯提示格各1 + 别处）——它**根本不反映三个长红格的真实状态**。教训：① 改前先 `--show-si <idx>` 看目标格的 run 结构，确认它是「纯文本格 / 单红run / 整格全红」哪一种，再决定怎么动；② 含红 run 的格做编辑/插入新条时，新增 `<r>` 会**继承所在格的染色基调**（整格全红的格里插的新条也会是红的），不想红就显式给新 run 的 rPr 设黑 `<color rgb=FF000000/>`；③「整格泛红」是否要修属格式返工、范围大，**先渲染发 Maggie 确认她 Excel/OnlyOffice 里看到的是黑字还是红字再决定**，不自作主张大改已验收过的格。④ 自己看不了图时用**像素分析绕过 vision**：`PIL`+`numpy` 读 x2t 渲染的 PNG，按 `(R>120)&(G<90)&(B<90)` 数红字像素、`(R<90)&(G<90)&(B<90)` 数黑字像素，逐水平带判主色，能量化「整格红 vs 黑字为主」——比纯靠 XML 推断更接近用户实际所见（本次实证 K8 区域红字带6 vs 黑字带13，红黑混杂而非纯红）。
|
||||
- ⚠️ **本地无法自验 Excel 行为，别反复甩"修好了"让用户当测试员**：x2t/LibreOffice 在本环境都不能可靠复现 Excel 的严格校验（LibreOffice 连干净版都报 "source file could not be loaded"，是环境问题非文件问题，不可用它验证）。本 session 连续 4+ 次"还是不行"就是反面典型。**没有能复现失败的工具时，先说清"我这边验不了 Excel"，把带富文本红色的版本发给用户、请其 WPS 另存，不要断言成功。**
|
||||
- **给用户的话术**：标好红后——"文件红色已标，但 openpyxl 生成的格式 Excel 会报'需要修复'。请你把这个文件用 WPS 打开 → 另存为 xlsx，Excel 就正常了、红色也在。另存后发我，我替换到 Nextcloud。" ⚠️ 被另存的必须是**带富文本红色那一版**（别拿中途"去富文本"的版本去另存，那样没红色）。
|
||||
- **更省事的退路（嫌 WPS 那步麻烦/纯自动化场景）**：纯文本前缀 `【需客户核实】`/`❗待核实：`，整条黑字零格式，Excel 绝不报错——但没有红色高亮。Maggie 要红色就走 WPS 另存法。
|
||||
- 完整排查全过程见 `references/openpyxl-excel-richtext-pitfall.md`。
|
||||
- 这道工序对治的是"上下文整合"，与「整款通读不摘单句」「合同间整体审查」是同一方法的三个抓手：整款通读=条款内不漏要件，整体审查=条款间不漏关联，整合质询=填表前强制对撞收口。
|
||||
|
||||
### ⚠️ 法律风险须标注对应合同条款（Maggie 2026-06-17 万达打样确立）
|
||||
|
||||
每一条法律风险**尽量标注其对应的合同条款号**，方便 Maggie 或客户在需要时回原文核对，使风险结论可溯源。
|
||||
|
||||
- **明确条款型**（合同里确有该条款）→ 直接标号，嵌在描述里：如「装修期满须恢复原状（第五条3款）」「违约金仅2个月租金（第九条1款）」「续租通知期 第八条3款"三个月" vs 第十条1款"一个月"」。
|
||||
- **缺失型风险**（合同里压根没有某约定，如无办证退出通道、无任意解除权、无查封拍卖衔接条款）→ **不硬凑条款号**，写清"第X条仅有…，无…"或"合同无…条款"，点出"在哪个条款本该有却没有"。如「第八条仅有协商解除/期满终止，无任意解除权」。
|
||||
- 标注方式：**在风险描述里嵌入条款号（括号或行文）**，不另起统一后缀（Maggie 已确认此方式）。提前解除路径等结论也同样补出处（如「协商解除（第八条1款）」「押金不退（第五条2款）」）。
|
||||
- **铁律：条款号必须核对合同原文逐条确认，绝不臆造**。标注前先读 OCR 原文 `.md`，把每条风险 → 原文条款匹配一遍；写入后用脚本验证关键条款号是否到位。
|
||||
- 法条（民法典X条）仍按〔待核实〕处理，与合同条款号是两回事：合同条款号是本合同内部定位，法条编号是外部法律引用。
|
||||
|
||||
### ⚠️ 金额/费用栏（H列）也标注对应条款号（Maggie 2026-06-18 世茂+万达确立）
|
||||
|
||||
K列法律风险标条款号的同理，**H列每个金额/费用项也标注其在合同中的对应条款号**，方便 Maggie/客户回原文核对。这是 H列金额提取的**标准动作**，与「4c 换算月租金」一起做。
|
||||
|
||||
- **格式按世茂来，简单明了**：金额后加括号注条款号，如「租赁保证金：66,230元（5.1，附件三；≈1.95个月平均月租）」「管理费：含税4,144.24/月（3.3，附件一）」「根本违约金(14.2)：…」。
|
||||
- **⚠️ 条款号忠于各合同原文的编号体系，绝不统一臆造**：
|
||||
- 世茂租赁/物业用**阿拉伯数字**：保证金5.1、保底租金5.2、结算周期5.2.2、违约金14.2；物业履约保证金3.1.1、质量保证金3.1.2。
|
||||
- 万达租赁用**中文章节**：租金「四」、押金「五」——原文就是「四、租金及支付方式」「五、租赁押金」，**不能硬改成「4.1」造成与原文不符**。
|
||||
- 万达物业用「**第四条**」：物业费/能耗第四条一款、垃圾清运/装修保证金第四条二款。
|
||||
- 「格式按世茂来」指的是**括号注法简洁**，不是把所有合同的编号都改成阿拉伯数字——编号本身必须能在该合同原文里查得到。
|
||||
- **金额数字常在附件，正文条款只定规则 → 双层定位**：世茂保底租金正文5.2只写「标准见附件三」，具体数额在附件三 → 标「（5.2，附件三）」。同理保证金「（5.1，附件三）」、管理费「（3.3，附件一）」。
|
||||
- **同范本不同份，条款号可能不同，必须各自核**：青少物业管理费在 **3.3**、高中物业管理费在 **3.2**；青少物业装修押金 **3.4.1**、高中物业 **3.3.1**——别因为是同一套世茂物业格式就套用同一条款号。逐份回原文 `grep` 核条款标题。
|
||||
- **铁律：条款号必须回 OCR 原文逐项核实，绝不臆造**（同 K列法律风险条款号铁律）。
|
||||
|
||||
### ⚠️ 金额/费用栏（H列）推算每期支付截止日；推不出则总结+红色提示（Maggie 2026-06-18 世茂确立，确认为**通用规则**）
|
||||
|
||||
> 🔵 **通用规则（Maggie 2026-06-18 明确）**：「付款安排 + 无法推算时红色提示」是**所有租赁/物业类合同梳理的标准动作**，不是世茂个案——以后**每一份**租赁/物业合同进 H列都要做。与「H列标条款号」「4c 换算月租金」一并，构成 H列三件套。
|
||||
|
||||
H列不只列金额，还要处理合同约定的**付款时间**，让 Maggie/客户一眼知道下一笔哪天该付。**分两条路径，按"起算日能否确定"分流**：
|
||||
|
||||
- **路径A（起算日确定）→ 推算具体支付截止日**：把抽象付款规则（"预付制""结算周期六个月""上个结算周期最后一个月15日前支付"）逐期算成**每一期的具体支付截止日**。**尚未到支付时点的（付款截止日 ≥ 审查当日）整条标红提示**（红色 FFFF0000，标红技术走前述「openpyxl 写富文本红 → WPS 另存规范化」/「sharedStrings XML 层加红 run」法）。
|
||||
- **路径B（起算日不明/推不出）→ 总结合同写了什么 + 红色提示约定不清**：见下方"🔴🔴 推算不出来就别硬推"条。**绝不硬凑确定日期。**
|
||||
|
||||
- **推算前先定起算日**：营业期/计租起算日决定全部结算周期的划分。**装修期是否计租、营业期从哪天起算，必须回原文+向 Maggie 确认，不擅自假设**（世茂高中：Maggie 确认起租日=2026/1/1，含装修期也计租）。起算日错→整串付款日全错→误导付款。
|
||||
- ⚠️ **"租赁期限X年，自A至B"——A到B的日历跨度可能 > X年，免租装修期常不计入约定的X年租期（2026-06-22 人民中路 Maggie 确立）**。人民中路合同写"租赁期限5年，自2025/3/1至2030/4/30"，但该区间日历跨度实为5年2个月：前2个月（2025/3/1–4/30）是免租装修期、**不计入5年**，真正5年计租期是2025/5/1–2030/4/30。识别三个别混的概念：①日历区间(A至B) ②约定租期年限(X年) ③计租期(起租日起算)。G列分行写清三者，免租期单列并注"不计入X年租期、物业费由乙方承担"。Maggie 原话："免租期没有算到租期里"。注：商业租赁的"租赁期限"措辞常与免租期叠加导致 OCR/字面易误读，是否计入须回原文+问 Maggie。
|
||||
- **日期是硬事实，用代码算不手算**：按结算周期逐期划区间，套合同付款条款算每期截止日（如"上个结算周期最后一个月的15日前"）。算完**先把每期推算结果列给 Maggie 核对合同解释**（起算日含义、各期付款节点解读），确认后再写进表。
|
||||
- **标红范围**：只标"付款截止日 ≥ 审查当日"的**未到期期次**；已付/已到期的黑字。基准日取审查当日（如 2026/6/18）。这与「需客户核实内容标红」用同一套红色技术，但语义不同——这里红的是"未来待付款提示"。
|
||||
- 🔴🔴 **推算不出来就别硬推——退到"总结+提示"路线（Maggie 2026-06-18 世茂反转确立）**：起算日合同没写死、各期具体付款日**确实推算不出来**时，**绝不硬凑一个确定日期**（错的确定日期比"不确定"更危险，会误导付款）。Maggie 原话："算了，世茂的我也推算不出来。这种推算不出来的，就总结下合同里写的结算周期，以及支付时间。无法推算的，就提示合同约定不清楚，请注意实际支付时间之类的。" 改走两段式：
|
||||
- **第一段（黑字·照实总结合同写了什么）**：`【付款安排】结算周期X个自然月/一个自然年，预付制(条款号)：首期于营业期起租日/交付日支付；其后每期于上一结算周期最后一个月15日前提前支付(遇法定节假日顺延)。`
|
||||
- ⚠️ **已过期的确定节点不列（Maggie 2026-06-18 世茂青少确立）**：合同明确写了的确定付款节点，**只有付款截止日 ≥ 审查当日（未来/待付）才列**；**截止日 < 审查当日（已过期）的一律不列**——付款安排聚焦"尚未发生、需提醒注意"的，过去的节点占篇幅无意义。世茂青少租赁"第二期保底租金余额335,133.92元应于2026/4/15前支付"——2026/4/15 早于审查日 2026/6/18，**已过期 → 删除不列**（Maggie 原话"这个时间点已经过了，没必要列出"）。红色提示里同步去掉对该过期节点的引用（如"及第二期付款日(2026/4/15)"删掉）。判据与"标红范围只标未到期期次"同源：**已发生的不提，待发生的才提（未到期还标红）**。
|
||||
- **第二段（整句标红·提示约定不清）**：`🔴合同未明确约定营业期起租日/交付日，各期具体付款日无法推算，请按实际营业期起算日/交付日及甲方账单核对支付时间。` 整句红色 FFFF0000，走「openpyxl 写富文本红 → WPS 另存规范化」/「sharedStrings XML 层加红 run」标红法。
|
||||
- **判据：能确定起算日→推算具体日期（前几条）；起算日不明/推不出→总结+红色提示（本条）。** 律师式严谨：宁可标"约定不清、请核实实际支付时间"，不给一个算错的确定日期。这与"事实问题不靠文本提取下结论""OCR 缺失数字标〔待核〕不编造"同源——**不确定的事项如实提示，不假装确定**。
|
||||
- **🔑 客户问"能否推算具体付款日"时，回 OCR 原文核条款原话，不靠汇总表摘要判断（2026-06-22 世茂青少物业确立）**：表里的付款节点是压缩摘要，本身可能语义不全，不足以支撑"能否推算"的判断。Maggie 问青少物业"上一个自然年15日前，是不是12月15日前"——回 OCR 原文核 3.3.3/3.3.4，发现原文**真的只写"上一个自然年15日前"、没有月份限定词**（两处独立一致出现 → 非 OCR 丢字，是合同本身缺月份）。结论：即使起算日确定，光凭"15日前"也定不出哪天 → 约定不清。**calculability 是事实问题，回原文条款原话核，不在表摘要上推。**
|
||||
- **同范本不同份，付款条款表述可能真实不同（不止条款号不同）**：青少物业(3.3.x，结算周期一个自然年，"上一个自然年15日前"**缺月份**) vs 高中物业(3.2.x，结算周期6个自然月，"上一个结算周期**最后一个月**的15日前"**月份完整**)——同套世茂物业格式，付款节点表述却**真实不同**，青少那份更彻底地约定不清。已比对 OCR 原文确认非 OCR 错。"跨副本对撞"既要防 OCR 伪差异、也要识别真差异，**不能因"同范本"就假设两份逐字相同**。校准一份时回兄弟份核原文：相同才一并改，不同则只改该份（本次只改青少 H8，高中 H14 月份完整、归因正确，原样不动）。
|
||||
- **"约定不清"的红色提示精准归因到具体条款缺陷，不泛泛说"起算日未定"**：旧提示"合同未明确约定交付日/起算日…"归因不全；青少物业真正的双重缺陷是 ①交付日未写死 ②"15日前"连哪个月都没写。改为点明"合同3.3.3/3.3.4仅约定'上一个自然年15日前'，未明确具体月份（如是否为12月15日），且交付日/起算日未写定…"——客户拿表即可对照条款知道是合同本身漏洞。**精准归因 = 客户可操作。**
|
||||
- 🔴 **"推不出"的第二类成因：付款条款文本本身缺关键限定词（月份/日期锚点），不止起算日缺失（2026-06-22 世茂青少物业确立）**：除"起算日未写死"外，**条款字面缺月份/日期锚点**同样导致推不出确定日，且更隐蔽——表里摘要常把它"脑补补全"掩盖掉。世茂实证：青少物业 3.3.3/3.3.4 原文是"乙方应于**上一个自然年 15 日前**支付下个自然年的管理费"——**"自然年"前缺了月份**（不像租赁合同写全的"上一**结算周期最后一个月**15日前"）。字面"上一自然年15日前"语义不完整，存在两解：①脱漏"最后一个月"→应为12月15日；②约定不清。**Maggie 直觉问"是不是12月15日"方向多半对，但合同文本本身没写"12月"这三个字，按律师严谨不能替合同补全**。
|
||||
- 必查动作：用户问"能不能推算出具体日期"时，**绝不拿汇总表里被压缩过的摘要回答**（摘要可能已把缺失的限定词脑补掉）——必须回 OCR/PDF 原文核该付款条款的**逐字表述**，确认月份/日、起算日是否都写全。表摘要"上一个自然年15日前支付下一自然年"看似完整，原文实则缺月份。
|
||||
- 处置：缺锚点→仍走"总结+红色提示"，且**红提示里如实点明是合同文本缺了什么**（如"合同3.3.4仅约定'上一自然年15日前'未明确月份，请按甲方账单核对"），让客户知道是合同本身没写清、不是我们漏算。是否按解读①直接认定确定日期，属法律判断取舍，**提请 Maggie 定，不自作主张补全**。
|
||||
- 标红语义：这里红的是"**合同约定不清的待核提示**"，落在"需客户核实/确认事实"那一类（见「需客户核实内容标红」判据①），整句标红，与"未来待付款提示"标红并行不悖。
|
||||
- **整批同套格式合同付款条款逐字相同时，四份文案可成套复用**：世茂青少+高中、租赁+物业四份均"首期于起租日/交付日付、其后每期上个结算周期最后一月15日前预付"，只结算周期不同（高中租赁6月、高中物业6月、青少租赁12月、青少物业一自然年）——文案套同一模板改结算周期即可，不必每份从头写。
|
||||
- **世茂四份付款条款实例**（同套世茂52+格式，付款节点逐字相同）：租赁/物业均"首期于营业期起租日/交付日支付，之后每个结算周期的保底租金/管理费于**上个结算周期最后一个月的15日前**提前支付（遇法定节假日顺延）"。结算周期：**高中租赁6个月、高中物业6个月、青少租赁12个自然月、青少物业一个自然年**。
|
||||
- 这与 4c（换算月租金）、H列标条款号同属 H列标准动作——都是"交付物信息完整、可核对、待办凸显"的 Maggie 偏好。
|
||||
|
||||
#### 零散情形 → 提炼专业法律概念（Maggie 2026-06-17 万达打样确立）
|
||||
- 审查中遇到**零散列举的具体情形**，识别其背后的**专业法律概念**，用概念统领、具体情形作括注，比堆砌情形更专业简洁。
|
||||
- 租赁场景三类常见（背后是不同制度，**别张冠李戴挂法条**）：
|
||||
- 出租方变更/过户 → **所有权变动**（买卖不破租赁，民法典725条）
|
||||
- 查封、拍卖（执行/第三人处置）→ **第三人主张权利**（民法典729条）—— 注意：查封≠所有权变动，不能挂725
|
||||
- 征收、拆迁 → **征收征用**（民法典243条）
|
||||
- 格式：`专业概念（具体情形举例）`。实例：原写"合同无查封拍卖、出租方变更、征收拆迁的衔接条款（援引725条买卖不破租赁）"（情形零散+725挂错），改为"所有权变动（出租方变更）、第三人主张权利（查封、拍卖）、征收征用等情形未作安排，实操中求偿困难"。
|
||||
- **法条号默认不写进表格正文**（Maggie偏简洁）——概念用准即可，法条留作内部依据；正文落点回到"实操求偿困难"等实际后果。
|
||||
|
||||
### ⚠️ 风险定级纪律：克制，按"实际影响"分级（Maggie 2026-06-17 万达打样确立）
|
||||
|
||||
站乙方立场审查不等于把每处瑕疵都往高风险写。Maggie 反复纠正"评高了"。三条定级铁律：
|
||||
|
||||
**① 形式瑕疵按"是否实际影响成立/生效/履行"定级，不夸大**
|
||||
- 形式瑕疵 = 签署日期空白、印章不全、填空未填、落款不完整等。
|
||||
- 判据：若**关键履行要素已明确约定**（租期起止、金额、付款时间，标条款号）**且合同已实际履行**（《民法典》第490/502条：一方履行主要义务对方接受即成立生效），则纯形式瑕疵评 🟢**低风险**，不评高风险、不写"合同效力存疑"。
|
||||
- 建议落点：**不渲染风险，落到"建议补正以规范合同管理"**。
|
||||
- 表述模板："X空白/未填。鉴于〔关键要素已明确（第X条）+合同已实际履行〕，X缺失不影响合同成立与生效，风险较低，但仍建议明确X，以规范合同管理。"
|
||||
- 实例：万达"签署日期空白"原评🔴"合同是否有效成立存疑"→ 降🟢低风险。
|
||||
|
||||
**② 尽调/核验类事项用操作性"请确认…"提示，不写成"未核验→风险"**
|
||||
- 适用：权属核验、资质核验、证照查验等"应做、通常已做、只是需确认"的事项。
|
||||
- 写法：操作性核验提示，**假定通常已做**，措辞平和。如"核验出租权：请确认已核验过甲方的不动产权证明原件，并有复印件存档"。
|
||||
- 等级：归 🟢 低风险（建议规范类），**不放高风险/须核实区**，不写"无从核验→效力风险"。
|
||||
- 实例：万达"出租权属未核验（风险）"→ 改"核验出租权：请确认已核验…并存档"，归🟢低风险。
|
||||
|
||||
**③ 一条风险只讲一件事**——别把一个真问题和一个伪问题捆在一条（会一起被拔高）。万达原把"签署日期空白"+"出租权属未核验"捆成一条评🔴；拆开后各自降级。
|
||||
|
||||
**⑤ 责任/违约条款必须整款通读，不摘单句（确认偏误警示，2026-06-17 万达违约救济教训）**
|
||||
> ⚠️ **前置主规则（合同级第一性原则，非仅违约条款）**：整款通读的前提是**完整通读全文 + 准确把握每个条款的上下文语境与语义**。这不是违约条款的特殊要求，而是审查地基——**整个合同、每一条款**都要先通读、读懂语境再下结论。法律审查第一步必须 `read_file` 把整篇合同 OCR 文本（.md，通常仅20–60KB）一次性读完，**禁止用 grep 命中单行代替阅读**。详见 `references/independent-legal-review-framework.md` 第0步·审查第一性原则（2026-06-18 世茂14.2教训：错误归因"PDF太大不能通读"，实测 OCR 文本仅58KB完全可整篇读；根因是"命中即停"+只扫字没读懂语义）。
|
||||
- 违约/责任条款通常含多要件：**结算方式 + 违约金 + 兜底赔偿 + 适用主体 + 情形列举**。全部识别再下结论，看到"违约金X个月"就停 = 断章取义。
|
||||
- 实例：万达第九条1款，只摘"2个月违约金"判"救济偏薄、对乙方不利"，漏看了 ①"甲乙双方…守约方有权解除"=**双方对等适用** ②"按实际使用天数结算租金"=年付未用部分照退 ③"违约金不足以赔偿的赔全部损失"=**兜底全赔**。整款实为均衡条款，结论被推翻、该条移除。
|
||||
- **先判"对谁适用"再判利弊**：中国合同违约责任多为"守约方/违约方"对等表述。下"对X方不利"前先确认是单方还是双方对等条款；对等条款不存在偏向谁。
|
||||
- **"偏薄/不足"类结论必须先排除兜底**：全条款搜"不足以赔偿的赔全部损失"类兜底句，有兜底就不能说"无法覆盖损失"。
|
||||
- **警惕标签预设 = 确认偏误**：自然人房东、格式不规范等标签会诱导预判风险，带预设找证据只看见印证预设的部分。正解：用条款本身说话，问这条实际给了X方什么、拿走了什么。
|
||||
- **违约金/赔偿/费率必须连「计算基数」一起提取，只写比例=没说清（2026-06-18 世茂青少租赁14.1教训）**：写「千分之二」「3倍」「30%」而不写**乘什么**，等于没提取——读者不知道基数。基数（如「逾期**应付费用总额**的千分之二」「**平均月租金**的3倍」「**合同总价**的30%」）必须与比例同时进 I列/K列。世茂栽点：14.1 原文「按前述**逾期应付费用总额**的千分之二」，我只写「逾期付款违约金千分之2/日」漏了基数，被 Maggie 纠正。提取费率/违约金时强制自问：这个百分比/倍数**乘的是哪个金额**？基数没提到=回原文补。
|
||||
- **⚠️ 同一合同里多处「同数值」违约金，基数可能完全不同，必须逐条认基数防张冠李戴（2026-06-22 悦拾光实证）**：一份合同常有数个违约金/赔偿率，数字碰巧相同极易混填。悦拾光实证：6.1 **开业违约金** = 首期租金的 **3%**（基数=首期租金，督促按期开业的一次性违约金）vs 30.3 **逾期付款违约金** = **拖欠金额** 的 **3%**/日（基数=拖欠金额，逐日累计）——两个都是「3%」但**基数、性质、计息方式三不同**，旧版 K列把两者混为一谈、基数张冠李戴。铁律：见到同合同多处违约金，**一律按条款号逐条独立认「率×基数×计息单位（一次性/按日/按月）」**，绝不因数字相同就假设是同一个机制。年化/绝对值核高低时（4b）也要带对基数：拖欠金额3%/日=年化1095%畸高（但若是合同真实条款则照实记，疑 OCR 先核——本例双份核过3%属真值非误识），与开业违约金3%（一次性、基数=首期租金）完全两码事。
|
||||
- ⚠️ **只标你核过的区分维度，别为「解释清楚」凭空添一个没核的维度——会自造新错（2026-06-22 悦拾光 6.1 二次教训，由独立法律校对 subagent 揪出）**：区分两个同数值违约金时，我为了「讲清楚」给 6.1 加注「属一次性」与 30.3「按日累计」对比——**但 6.1 原文是「每逾期一日按首期租金3%」，本身就是按日累计、不是一次性**。真正且唯一核过的区分维度只有**基数不同**（30.3=拖欠金额浮动 / 6.1=首期租金固定），计息单位我没核就脑补了个「一次性」，既错又对乙方低估风险（开业晚60天≈首期租金180%）。教训：写区分注**只写已回原文坐实的那个维度**（这里=基数），没核的维度（计息单位、绝对额、适用主体）一律不写——「为了表述完整而补一个想当然的对比项」是确认偏误的变体，宁可只点准一个维度，不画蛇添足凑三要素。这与「⑤b rule 2 标了条款号≠读懂条款」同源：别拿模糊印象填充你没真读的部分。
|
||||
- **「除……外，……还应……」句式 = 责任叠加，必须逐层拆全（2026-06-18 世茂14.2教训，整款通读的句法级抓手）**：中文违约后果常是「**除[A]外**，[乙方]**还应**[B]；若不足赔偿的**还应[C]补足**」的多层叠加。看到「除…外」就警觉——**「除…外」前面那一层（A）极易被整段漏掉**。世茂栽点：14.2 原文「**除乙方交纳的租赁保证金不予退还用以冲抵违约金赔偿给甲方外**，乙方**还应**按平均月租金3倍或等额保证金（两者取高）支付违约金；不足赔偿的**还应负责补足**」——我只摘了中间「3倍/等额取高」，把「①保证金没收冲抵」整层漏掉、「③不足补足」也丢了，三层只取一层。正确提取必须三层齐全：①保证金没收冲抵 + ②另付主违约金 + ③不足补足。这是「整款通读不摘单句」落到**句法层面**——「除…外」「另…」「还应…」「并…」都是叠加信号词，逐个信号词对应一层后果，一个都不能丢。
|
||||
- **同口径修正必须扫全表对齐（规则一致性）**：同一套格式合同（如世茂青少+高中租赁，14.1/14.2逐字相同）改了一处条款表述，必须回各校区/各份原文核对是否同款，同款的一并改，否则同表内「青少改了高中没改」自相矛盾。改完用脚本全表扫旧表述残留（`bad=[旧串...]` 遍历所有单元格）确认0残留。
|
||||
|
||||
**⑤b 法律结论核证三铁律（2026-06-22 世茂高中物业 9.1/10.1 教训）**
|
||||
|
||||
教训：高中物业 K列第2条出现两个错误——①把「2个月 或 _/_元（两者取高）」里的选填留空 `/` 当成「填空额」备选项写进交付物论证（"或填空额，取高；填空为空故按2个月计"）；②写「物业违约可能连带触发租赁解除」，因果方向与原文相反——10.1 实为「租赁终止则物业终止」的**单向**联动，9.1 前提是「乙方过错致出租方解除租赁」在先、物业方才追责，合同**无**「物业违约→租赁解除」链条；且该句与同格第5条「10.1 租赁终止则物业终止」自相矛盾未自检。三条对治：
|
||||
|
||||
1. **选填留空 `/` = 不适用，是跨条款通用判别，不只用于提成/分档**：任何「或___元 / 或__%（两者取高）」类条款，填空为 `/` / 空白 / 未填 → 该选项不存在，**直接写确定项的结论**（如「2个月平均月管理费」），**不在交付物里论证那个空选项**（「填空为空故按2个月计」这类推理过程不进交付物）。这是 ⑨（提成空白=不适用）、4e（分档留空=不适用）的**泛化**——「选填留空=不适用」适用于违约金、保证金、费率等一切选填条款，不限于提成/分档。栽点根因：已有规则只绑定在它首次出现的场景，未泛化到新条款。
|
||||
|
||||
2. **法律因果链必须核方向，标了条款号 ≠ 读懂条款**：写「A导致B」「A连带触发B」「A可能触发C」这类因果结论前，回原文确认**箭头方向**（是 A→B 还是 B→A），尤其「联动 / 连带 / 触发 / 导致」这类词。合同联动多为**单向**（「租赁终止则物业终止」≠「物业终止则租赁终止」）。标条款号是定位、不是免检牌——标了 (9.1) 仍须真读懂 9.1 的**前提与后果**分别是什么，不能凭「两者有联动」的模糊印象脑补反向因果。栽点根因：印象式推断代替条款核对。
|
||||
|
||||
3. **同一单元格内多条结论写完互相对撞一遍**：同一格里引同一条款（如 10.1）的多处表述，方向 / 口径必须一致。填表「整合质询」应含**单元格内一致性自查**——高中物业 K14 第2条与第5条都涉 10.1 却方向写反、自相矛盾而未自检，正因写时凭印象一气呵成、没回头与同格其他条对撞。
|
||||
|
||||
4. **引某条款作依据前，先确认该条「正文非空」——空标题条款不能当依据，回原文找真正承载该规则的条款（2026-06-22 悦拾光 23条空壳教训）**：合同里**有标题、正文却是空白**的条款是真实存在的坑（OCR 与原件都如此，非 OCR 丢字）。悦拾光实证：「第二十三条 租赁房屋的转租」**只有这行标题、正文整条空**（OCR 里直接从该标题跳到第二十四条续租）——我一度在 I列写「禁止转租(23/28.9)」，把空壳的23条当依据引了。真正承载「禁止转租」的是 **28.9**（乙方擅自转租=根本违约）。处置铁律：① 任何条款号写进交付物前，回 OCR 原文确认**该条款号下确有承载目标规则的正文**，不是只看到标题就引；② 发现标题在、正文空 → **绝不引这个空号**，全文 `grep` 该规则的关键词（如「转租」）定位到真正写着它的条款（可能在「根本违约」列举、违约责任等别处）再引；③ 判断「正文是否真空」要看相邻条款是否紧接——若「第二十三条」标题下一行就是「第二十四条」，即空壳。这是 rule 2「标了条款号≠读懂条款」的同族延伸：rule 2 防因果方向错，本条防「引了个根本没内容的条款号」——都是「条款号是定位、不是免检牌」。④ **🔴 同范本两份副本，同一条款可能「一份正文空、另一份有正文」——这是真实差异，不是 OCR 错，「镜像印象」是漏读元凶（2026-06-22 悦拾光二次教训，由独立法律校对 subagent 揪出）**：悦拾光一期 23条「租赁房屋的转租」确为空壳（标题直接跳 24条），但**扩租 23条有禁止性正文**「未经甲方书面同意，乙方不得将该房屋转租，亦不得将该房屋进行其他非法或违约处置」。我逐字通读时太想确认「两份是同模板镜像」，反而把扩租这行有正文的 23条整行跳过、一口咬定「两份都空、都用 28.9」——连带写出「两份逐条对应、条款高度一致」的夸大表述。后果：①扩租禁止转租其实有**双重依据**（23条直接禁止 + 28.9根本违约），漏了直接依据；②「高度一致」失实。**这与 4a 的双向用法同源**：4a 既要「同条款数值不一致→疑 OCR」、也要「同范本不假设逐字相同、识别真差异」；本条把它落到「空 vs 有正文」这种最隐蔽的差异上——**越是认定「同模板镜像」，越要逐字核每一条，镜像印象会让你跳过真实差异行**。处置：任何「两份高度一致 / 逐条对应 / 逐字相同」的整体判断，落笔前必须**对两份的每一条标题+正文做一次存在性核对**（尤其转租、优先权、特殊约定这类易被一方删/改的条款），有一处不同就不能写「高度一致」，要点明差异（如「扩租另含 X 条正文，一期仅标题」）。
|
||||
|
||||
**⑥ 有约定的事项不拿任意性/兜底性法定标准质疑（意思自治优先，2026-06-17 万达催告期教训）**
|
||||
- 合同已明确约定的事项，**不得再拿"没有约定时才适用"的法定标准质疑其效力**。《民法典》合同编大量条款是"没有约定或约定不明时"才适用。
|
||||
- 典型误用：约定了违约金/催告期/解除条件后，又写"是否符合法定'合理'标准存疑"——错。除非约定违反**强制性规定**或构成**显失公平/格式条款无效**等可推翻情形。
|
||||
- 实例：万达第四条2款已约定"催告10日可解除"，不能再套民法典722条"合理期限"质疑这10天够不够。对偏严苛但合法有效的约定，**只做商业风险提示**（"代价较重，提示注意按时履约/协商更优条款"），不做法律效力质疑。
|
||||
|
||||
**④ 等级调整后的结构维护**：风险在🔴/🟡/🟢板块间移动后——(a) 受影响板块若清空（如🔴须核实区只剩的项都降级走了）→**移除空板块**；(b) 全列风险**编号重排 1–N 连续无跳号**；(c) openpyxl 局部改完跑保真核对（见 Pitfall 1b）。
|
||||
|
||||
**⑦ 审查已履行合同，剔除面向"履行前时点"的过时前瞻提示（2026-06-17 万达物业合同教训）**
|
||||
- 这批合同**都是已实际履行多时的合同**（万达2024/9签、2026/6已运营近两年）。审查时剔除面向**已过去且不可逆时点**（装修前、进场前、签约时）的**前瞻性操作提示**——这类提示对早过了那个时点的合同毫无意义，是马后炮。
|
||||
- 实例：物业合同低风险区"装修一次性费用（建议装修前纳入预算）""用电容量限制（建议核实现有容量是否充足）"两条——装修2024年底已完成、能正常运营近两年即证明用电够用，两条都删。
|
||||
- **保留**面向**当前/未来持续**的提示：如"能耗费每年发生→保留对账凭证"（合同仍在履行、费用持续发生）、退出机制/续租/违约等面向未来履行与退出的风险。续签建议（补任意解除权/不可抗力/办学许可条款）也保留——面向"未来续约"，不是过时前瞻。
|
||||
- 判断标准一句话：问"这条提示指向的时点，是否已经过去且不可逆？"——是→删；指向当前或未来→留。
|
||||
- **跨合同一致性检查**：删某类提示后，复查同表其他合同（主合同/其他校区）有无同类前瞻提示，统一处理。
|
||||
|
||||
**⑦b 履行中合同 + 属常规商业安排的条款 → 直接删除，不写"虽然有X但属常规"提示（Maggie 2026-06-18 世茂装修违约金确立）**
|
||||
- 合同**已在履行**、某条款经核实**属正常商业安排、不构成实际风险**的，**直接不列、不提示**——不要为了"显得审过了"而写"装修违约金1倍属常规督促性、提示按期完成装修开业"之类的安抚性提示。
|
||||
- 实例：世茂6.4装修延误违约金，核实为日租金**1倍**（≈1,100元/天，常规督促性违约金，合同已在履行）→ Maggie 原话"装修延误违约金不奇怪的情况下，不用提示，删除就好"，整条🟡中风险删除，不降级保留、不写提示。
|
||||
- 与⑦同理（⑦删过时前瞻提示，⑦b删常规无风险条款），都是"交付物只留真正要客户注意的风险，不堆无意义提示"。判断：这条款**当前是否真给乙方带来风险**？否（属常规商业安排）→ 删，不提示。
|
||||
|
||||
**⑧ 整体风险分析段（第三部分）须与已确立的定级尺度全程对齐（2026-06-17 万达第三部分重写教训）**
|
||||
- 校区 sheet 末尾的「整体风险分析与建议」段是早期产出、措辞最容易残留**已被推翻的旧判断**。每次定级尺度有更新，**必须回头重写这一段**，不能只改前面的逐条风险列。
|
||||
- 万达第三部分重写时清理掉的旧判断（全部违反本节①-⑥与「模版差异≠法律风险」铁律）：✗"出租方为自然人→偏向甲方"（标签预设/确认偏误）✗"违约金仅2个月→保护不足"（均衡条款，且法律意见书明确2个月违约金不适用无故退租）✗"提前退出风险高"（协商解除可互不担责、继续履行风险极低）✗ 拿"与模版差距大"当风险论证。
|
||||
- 重写后结构（站乙方立场、客观中性、不用预设标签）：整体评价（已履行可正常运行）→主要法律关注点（标条款）→提前解约成本与路径（**直接引同校区法律意见书的权威数字，可溯源**）→操作建议（意见书五步法）→续签建议（面向未来）→低风险事项（核验出租权、模板套用）。
|
||||
- **⚠️ 总结段精简尺度（2026-06-17 Maggie 定稿万达表确立）**：第三部分作为给客户看的「总结」，**只保留客户最需要注意的内容**——整体评价、主要法律关注点、提前解约成本、续签建议。**删掉**：①提前解除的具体操作步骤建议（五步法等程序性操作）②低风险事项提醒（核验出租权、模板套用等）。理由：总结要简明扼要、突出重点，操作细节和低风险事项放在前面逐条风险列里即可，不必在总结里重复，以免淹没真正要客户关注的重点。（注：上一条「重写后结构」是完整版结构；本条是 Maggie 进一步精简后的**最终交付尺度**，以本条为准——总结段不含操作建议段与低风险事项段。）
|
||||
- **⚠️ 汇总表意见简明、删法条号（2026-06-17 Maggie 定稿万达表确立，与第65行呼应）**：汇总表（含第三部分总结）的风险意见**尽量简单明了**，**删掉民法典法条号**（如584/580条等不写进表格正文）。但两类编号**保留**：①合同条款号（第八条、第五条2款等——便于回原文核对，见第50-56行）②引自正式法律意见书的法条（第三部分若直接援引意见书结论，其法条作为依据可留）。一句话：汇总表删「外部法条引用」求简洁，留「合同内部条款定位」便核对。
|
||||
|
||||
**⑨ "保底或提成两者取高"——必须核提成比例是否填了数额，空白即不适用（2026-06-17 世茂青少租赁 Maggie 纠正）**
|
||||
- 商业Mall租赁常见"月租金=每月保底租金 或 每月营业额×提成比例%，两者取高"的约定。**绝不能照搬"两者取高"的字面就写进表**——必须回原文核**提成比例栏是否真的填了数额**。
|
||||
- 世茂青少/高中租赁实例：附件三租金段写"合计33280.59元 **或按当月总营业额（税前）之／%提成；两者取高**"——提成比例是 `/`（空白占位）、**没有数额**。提成租金无从计算，**实践中即不适用，实际只按保底租金计租**。
|
||||
- 正确写法（Maggie 2026-06-17 再纠正：判断过程不进交付物）：金额栏标题写"营业期**保底租金**"、只列保底数额即可——结论栏只放结论，**判断过程不写进汇总表**。既不写"保底与提成取高"（误导以为有提成机制），也不写"提成比例空白→无法计算→不适用"这类推理过程（推导留在审查阶段，不进交付物）。
|
||||
- 推广检查：凡遇"两者取高/就高"类租金约定，逐份核提成比例（%处）填没填数额；空白/`/`/未填→按不适用处理。这是"事实核实、不照搬字面"原则在金额栏的具体落地。
|
||||
|
||||
### ⚠️ 铁律：每份合同逐条审查，不挑不跳，禁标"简化审查"（Maggie 2026-06-17 万达物业合同确立）
|
||||
|
||||
**每一份合同**——无论主合同/附属合同、标准模板/格式文本——都必须**按审查标准逐条审查，从①主体信息 → ②各实体条款 → ③违约/争议/生效 → ④签名落款，全过一遍，不挑重点、不跳条款。**
|
||||
|
||||
- **严禁标注"简化审查""重点审查"之类减档说明**。Maggie 原话："任何一份合同都应该按照审查标准逐条审查，从主体信息到签名落款，不能跳着或者挑着来。" 这种标注既是给客户的负面信号（像在说"没认真审、打了折扣"），也是给偷工减料找说法。审查深度的主次是内部判断，**不写进交付物**。
|
||||
- **合同间的主次（如物业依附租赁）只影响风险权重表述，不影响审查覆盖面**——附属合同照样逐条审。
|
||||
- **逐条审查反而捞出挑审漏掉的真问题（万达物业合同实证）**：从"挑审4条"改为"逐条审"后新发现——①协议性质/主体框架错位（套用"前期物业服务协议"住宅业主模板，乙方实为承租人非业主）②第十七条生效条款"业主办理入住手续签字生效"与承租场景不符③第八条广告牌设置与租赁合同"乙方可免费设广告牌"衔接冲突。挑审时全漏了。
|
||||
- **交付物结构（逐条审查后）**：风险按🔴🟡🟢分级列出（标条款）。物业等附属合同标题与主合同对齐用"站乙方立场独立审查"，不用"简化审查"。
|
||||
- ⚠️ **不加"✅已审查无异常"展示段（Maggie 2026-06-18 反转此前万达打样规则）**：此前为展示"审查覆盖全部条款"，会在 K列末尾加一段"✅已审查无异常"罗列审过且无问题的条款。**Maggie 明确不要这个提示——删除。** 逐条审查是**内部要求**（覆盖面靠内部保证），但交付物**只列真正的风险点，不写"已审查无异常"这类覆盖面展示段**。理由同"判断过程不进交付物""总结段只留客户最需注意的内容"：客户要看的是风险，不是"我审了哪些没问题"的清单。**已有的旧表若带此段，更新时一并删除。**
|
||||
|
||||
**⚠️ 事实问题不靠文本提取下结论（连带自我教训）**：签字/盖章是否空白、印章有无属**事实问题**，PDF 手写签名/印章在 OCR/文本提取里**看不到**。不能凭 `.md` 提取版断言"甲方签字处空白"——必须**看原件 PNG 图片或问 Maggie 确认**。同"自已/自己"教训：提取层看到的"空白/错字"可能只是提取丢失，不是原件真相。涉及签署状态的风险，先核图再定级。
|
||||
|
||||
### ⚠️ 交付物呈现规范（Maggie 2026-06-18 世茂确立）
|
||||
|
||||
两条关于「交付物里放什么、怎么标」的硬规则，与「判断过程不进交付物」「总结段只留客户最需注意的内容」同源——**交付物只为客户服务，不留我的工作痕迹，待客户做的事用颜色凸显。**
|
||||
|
||||
**① 核实痕迹直接删除，客户不需要知道我怎么核的**
|
||||
- "经PDF原件核实""经原件核实""经PDF原件+数学交叉核实""〔关键数字均经…核实〕"等**我自己的核验过程标注**，一律**不写进交付物**——客户只需要看结论，不需要看我怎么验证的。
|
||||
- 实例：世茂物业 K列"逾期缴费滞纳金：每日0.5‰（9.2，**经PDF原件核实**）"→删成"（9.2）"；高中物业末尾整段"〔关键数字均经PDF原件+数学交叉核实：①…②…③…〕"注脚→整段删除。
|
||||
- 核验是我的**内部责任**，留痕放工作记录/主审清单即可，不进客户看的表。这与「判断过程不进交付物」「不加✅已审查无异常展示段」是同一条线：交付物 = 客户视角的结论，不是我的工作日志。
|
||||
|
||||
**② 需客户核实/确认的内容怎么凸显——⚠️ openpyxl 富文本标红会让 Excel 报错，但 WPS 另存可救（2026-06-18 世茂，最终标红成功保留）**
|
||||
- 需求：风险点中**需要客户去核实/确认某个事实**的内容（如"两份合同衔接需核实""建议向客户核实""建议签约时补明或确认2028年度计租标准"）希望**凸显**，方便客户一眼识别待办。
|
||||
- **边界（不管用什么方式凸显都适用）**：①只标"需客户核实/确认事实"的——提示类（提示按时缴费、提示知悉、提示确认衔接）不凸显；②我已核实的不凸显（且核实痕迹要删，见①）；③范围 Maggie 要的是**整条**（从编号到句末），不是只标半句。
|
||||
- 🔴🔴 **铁律：openpyxl 的 `CellRichText` 局部着色会让 Microsoft Excel 报"发现部分内容有问题/需要修复"——但 WPS 打开另存可救回（2026-06-18 世茂，最终标红成功）。** 完整经过：
|
||||
- openpyxl 把带局部色的单元格写成 `inlineStr`+`<is><r><rPr>…`。试过 ①调 `<rPr>` 子元素顺序（rFont→sz→color）②补 `charset=134`/`family=2` ③去掉富文本只留纯文本——**Excel 仍报错**。说明根子不只是富文本，openpyxl 生成的这个表底层某处就不合 Excel 严格 OOXML 校验。
|
||||
- **WPS、OnlyOffice x2t、openpyxl readback、LibreOffice 全都不报错或无法复现**——唯独 Microsoft Excel 报。所以"WPS 打开正常""openpyxl 读回正常"**完全不能当交付合格证据**。Maggie 的客户/她本人用 Excel，Excel 报错就是不合格。
|
||||
- **本地没有能复现 Excel 严格校验的工具**（LibreOffice 在本环境连干净文件都报 "source file could not be loaded"，x2t 太宽松）。→ **改完无法自验 Excel 行为时，必须如实跟用户说"我这边验不了 Excel，你帮我打开看下"，不要断言"修好了"。** 本 session 连续 4+ 次"还是不行"、把用户当测试员，是明确的反面教训，用户失去耐心。
|
||||
- ✅ **要凸显就用不碰富文本的方式（Excel 绝不报错）**：
|
||||
1. **纯文本标记（首选）**：在需核实条前加醒目前缀，如 `【需客户核实】…` / `❗待核实：…`，整条普通黑字、零特殊格式。最稳，Excel/WPS 都不报错。
|
||||
2. **整格统一格式**（`cell.font=Font(...)`、整格背景 `PatternFill`）：安全，但会把整格所有条目一起染——仅当"整格就这一条"时可用。
|
||||
3. **必须某条带色/加粗 → WPS 另存法（2026-06-18 世茂实证：此法成功，Excel 不再报错且红色保留）**：openpyxl 写好带 `CellRichText` 局部标红的 xlsx 后，让用户/我把文件**用 WPS 打开 → 另存为 xlsx**。WPS 会把 openpyxl 那套不合 Excel 严格校验的 XML **重写成规范格式**，结果：①Excel 打开**不再报"需要修复"** ②**红色局部着色保留**。Maggie 亲自验证 Excel 正常打开+红色在。这是\"既要某条标红、又要 Excel 兼容\"目前**唯一跑通**的路径。\n - 代价：需\"WPS 打开另存\"这一步人工（或我若有 WPS CLI 可自动化；本环境暂靠用户手动）。给用户的话术：\"文件我已标红，但 openpyxl 生成的格式 Excel 会报错——你用 WPS 打开后另存一次 xlsx，Excel 就正常了、红色也在。\"\n - ⚠️ 前提：被另存的那一版**必须是带富文本红色的版本**（别拿我中途\"去富文本\"的版本去另存，那样没红色）。\n- **结论**：要\"单元格内某条标红/加粗\"，**先 openpyxl 写富文本红色 → 再 WPS 另存规范化**（已验证可行）；嫌麻烦或纯自动化场景，退而用**纯文本前缀**（`【需客户核实】`）。默认 Maggie 用 Excel、WPS 只是工具，但 WPS 另存这一步是打通富文本标红的关键。完整排查全过程见 `references/openpyxl-excel-richtext-pitfall.md`。
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 三角色分工（四眼分离，Maggie 2026-06-16 确立）
|
||||
|
||||
**核心原理**：做的人查不出自己的错（确认偏误）。有效校对必须是**独立角色拿合同原文重新核**，不是看着成品点头。技术上用 `delegate_task` 开上下文隔离的 subagent，校对员看不到承办思路，只看原文和成品 → 真四眼。
|
||||
|
||||
| 角色 | 谁来当 | 职责 |
|
||||
|------|--------|------|
|
||||
| **① 承办** | 小Maggie主审 + 独立 subagent | **法律审查（动作A）**：小Maggie本人主审，八维全面审查→法律风险清单（不外包，避免超时）；**提取分析（动作B）**：独立 subagent，OCR→要素提取→模版比对→退租敞口→填表+提取依据清单 |
|
||||
| **② 校对** | 独立 subagent ×2 | **法律校对**（维度1-4）‖ **格式校对**（维度5-6） |
|
||||
| **③ 终审** | 小Maggie 本人 | 汇总校对结果、确认问题闭环、最后把关 |
|
||||
|
||||
**防线顺序**：承办 → 校对 → 小Maggie终审 → 交付 → **Maggie最终核对**。到 Maggie 手上前已过三道。
|
||||
|
||||
### 承办拆分规则（2026-06-16 小样验证后定为"方案3：小Maggie主审"）
|
||||
- **OCR 是分叉前的共享前置步骤（2026-06-16 厘清）**：合同 PDF → `.md` 文本只做一次，生成"只读底料"。**小Maggie（法律审查）和 subagent（提取分析）各读同一份 .md 原文，并行不冲突**（都是只读，像两个律师各拿一份复印件）。法律审查**必须亲自读合同原文**——不读原文无法做八维审查。旧流程"subagent 读文件出报告、小Maggie 只汇总"已废止；现在法律判断的源头（读原文）牢牢在小Maggie手里。
|
||||
- **法律审查（动作A）由小Maggie本人主审，默认不外包 subagent**。两条理由：①法律审查最吃专业判断，小Maggie对合同全局上下文最清楚，质量最高；②重型八维审查单个 subagent 极易撞 10 分钟 ACP 超时被杀，半截活白干。
|
||||
- **万达小样实证（2026-06-16）**：法律审查 subagent 跑满 600s 超时被杀；小Maggie补做的版本是本次质量最高的一份且无超时，并独有发现签署页瑕疵（签署日期空白等模版比对看不到的项）。⚠️ 注：该"签署日期空白"当时被评"合同效力存疑"高风险，2026-06-17 经 Maggie 纠正应降为🟢低风险（合同已实际履行、租期明确，形式瑕疵不影响效力）——发现瑕疵是对的，定级要克制，见「风险定级纪律」节。
|
||||
- **提取分析（动作B模版比对）+ OCR + 填表 外包独立 subagent**，机械活可并行、不超时。
|
||||
- **四眼分离不破**：小Maggie主审动作A → 独立法律校对员查；动作B由 subagent 做 → 独立校对员查。做者与校者始终分离（校对查的就是小Maggie主审的成果——正是万达小样里校对揪出"法条未标注"的场景）。
|
||||
- **弹性**：若某段时间小Maggie任务过载、确实抽不出手，可临时降级为"法律审查 subagent"，但必须二选一防超时——①放宽 ACP 超时（`--timeout`）②按维度把八维拆成 2-3 个轻 subagent 再拼。**默认主审，过载才降级。**
|
||||
- 提取分析 subagent context 必须含：合同OCR原文路径、标准模版核心条款清单、"中性输出合规差距、不作风险判断、开头结尾各重申一次声明"。
|
||||
|
||||
### 填表分工（2026-06-16 确立：谁产出谁填，绝不让 subagent 填它没做过的内容）
|
||||
|
||||
**核心矛盾**：汇总表的内容来自**两个源头**——动作B（提取分析，subagent 产）+ 动作A（法律审查，**小Maggie主审产**）。若简单"填表外包 subagent"，会让 subagent 去填一栏它根本没做、是小Maggie做的"法律风险"，必然瞎填或失真。因此填表必须拆成两步两人：
|
||||
|
||||
| 步骤 | 谁干 | 填什么 |
|
||||
|------|------|--------|
|
||||
| **① 填表初稿** | 提取分析 subagent | 只填**它自己产出的**栏位：当事人/面积/金额/期限/核心内容/**模版差异** + 套用 12 列格式、配色、行高 |
|
||||
| **② 合并法律风险** | **小Maggie（终审）本人** | 把主审的**法律风险**结论亲手并入"风险点/备注"栏；与模版差异**分列**、加方法论标注（法律风险 ≠ 模版差距） |
|
||||
| **③ 格式校对** | 格式校对 subagent | 查格式统一、总览-分表一致、加总对不对 |
|
||||
|
||||
**铁律：谁产出谁负责那一栏。** 机械的格式骨架 subagent 搭，小Maggie做的法律风险小Maggie自己填，**绝不让 subagent 去填它没做过的法律判断内容**。这与"方案3 小Maggie主审法律审查"一脉相承——法律判断从审查到落表全程在小Maggie手里，不经 subagent 的手，杜绝失真。
|
||||
|
||||
> 🔴 **模版差异（L列）虽由 subagent 产，但必须满足两个强制条件（Maggie 2026-06-23 补充，对治"外包给 subagent 就不回原件"的隐患）**：
|
||||
> 1. **subagent 的 context 必须含 07 原件路径 + "逐条打开原件比对"强制指令**：不是给一份归纳好的 checklist 让它套，而是给 `07- 房屋租赁合同.docx` 原件（或其全文），明确要求"逐条比对原件，禁止用'商业格式''标准格式'等抽象概念当参照系"。checklist 仅作定位导航，真值以原件为准。
|
||||
> 2. **终审（小Maggie）对 L 列结论像法律风险一样回原件复核，不全信 subagent**：subagent 的模版比对是初稿，终审必须亲自回 07 原件抽查关键条款（缺失项、实质偏离项）是否找全、陈述是否中性、有没有把模版标配当"本合同优势"。这与"动作A 法律审查不外包源头"同源——模版比对的**校验源头**也要在小Maggie手里。
|
||||
> - 教训来源：人民中路 L 列当初没回 07 原件、拿"星展商业格式"概念写差异，漏了第八条抵押"不得→可"、第十二条办学许可证免责款缺失两处实质偏离（详见「模版差异≠法律风险」铁律下的 07 原件铁律）。
|
||||
|
||||
> ⚠️ **退租敞口测算含法律判断，必须小Maggie把关定稿（2026-06-16 Maggie 指示）**：退租敞口（确定责任/不确定责任/可收回/净成本）本质是法律判断，不是机械提取。subagent 可出初稿框架，但**最终结论由小Maggie定稿**，与"法律风险栏"同等对待——不外包拍板。
|
||||
|
||||
> ⚠️ **现行 12 列汇总表中，法律风险与模版差异物理分列：K列=「风险点/备注」装法律风险（动作A产出），L列=「与标准模版差异」装模版差异（动作B产出，回 07 原件比对）。** 两列各自标注性质，绝不混列——这是「模版差异 ≠ 法律风险」铁律在表结构上的落地，防止读者把合规差距误读为法律风险。（此前「11列、K列同时承载两者」的旧表述已于 2026-06-23 作废，见 Step3 12列标准结构。）
|
||||
|
||||
### 六维校对清单（Maggie 列定，逐项打勾）
|
||||
| # | 校对什么 | 谁校 | 自动化 |
|
||||
|---|----------|------|:---:|
|
||||
| 1 | 提取文字准确（面积/金额/期限/当事人回OCR原文核） | 法律校对 | 🟡半自动 |
|
||||
| 2 | 总结要点无错漏（核心内容栏有无漏关键条款） | 法律校对 | 👤 |
|
||||
| 3 | 法律风险完善准确（是否当新合同全面审、有无错漏、定性准否、法条现行有效） | 法律校对 | 👤 |
|
||||
| 4 | 模版核对准确（差异找全、陈述中性、**没把差距当风险**） | 法律校对 | 👤 |
|
||||
| 5 | 汇总要点齐备（字段齐全、总览-分表一致、加总对得上） | 格式校对 | ✅自动 |
|
||||
| 6 | 格式统一（列结构、配色、行高、板块划分合模板） | 格式校对 | ✅自动 |
|
||||
|
||||
- 第5、6点 + 第1点数字部分写成**校验脚本**自动跑（字段空缺、总览-分表一致性、金额加总、列结构比对）——机器不漏不手抖
|
||||
- 第2、3、4点是法律实质判断，法律校对 subagent 做，小Maggie终审复核
|
||||
- **错别字、格式错误、语义逻辑错误是必校项（2026-06-16 Maggie 补充）**：贯穿全部六维，每份交付都要过——错别字（法律/格式校对都查）、格式错误（格式校对）、语义逻辑错误/指代不清（法律校对）。这是基本质量底线，不因走了 workflow 就免检。
|
||||
|
||||
### 校对发现问题后的处理机制（2026-06-16 确立，三角色闭环的"最后一公里"）
|
||||
|
||||
校对员产出《校对意见清单》后，按以下机制流转——做、校、修、核、定一条龙，缺一环不算闭环。
|
||||
|
||||
**① 问题分级**
|
||||
| 类型 | 例子 | 处理 |
|
||||
|------|------|------|
|
||||
| 🔴 **阻断项** | 数字提取错、法律风险定性错、**红线**（把模版差距当法律风险）、法条臆造/未标注 | **改完 + 复核通过前，不交付 Maggie** |
|
||||
| 🟡 **建议项** | 轻微遗漏、措辞、可补充的小点 | 终审判断采纳与否，可当场补或仅记录 |
|
||||
|
||||
**② 谁来修：校对不下场，按问题大小分流**
|
||||
- **铁律：校对员只挑错、不动手改**——一旦它下场改，就又变回"自己查自己"，四眼分离失效
|
||||
- 小问题（标注、个别数字、补一条风险）→ **终审（小Maggie）局部修**，最快
|
||||
- 系统性问题（整段审查跑偏、大面积提取错、立场错）→ **退回对应承办环节返工**，重做那一环
|
||||
- 优先级：**局部修 > 退回返工 > 重做**（与合同审查同一套）
|
||||
|
||||
**③ 改完必须闭环复核，不能"改了就算"**
|
||||
- 修正后拿校对意见**逐条回核**，确认真解决了
|
||||
- 能脚本验证的（数字、格式、标注一致性）就**脚本验证**
|
||||
- 没复核通过 → 不算闭环、不交付
|
||||
|
||||
**④ 反复出现的问题 → 修根因，不只修个案**
|
||||
- 某类问题被校对反复挑出（如法律审查老漏标法条）→ **打回本手册/承办指令模板**，从源头堵住
|
||||
- 修一次性的错 vs 堵住错的来源，后者才治本
|
||||
|
||||
**⑤ 终审最终裁判权**
|
||||
- 校对意见**非绝对权威**。若某条意见本身站不住，终审（小Maggie）有最终取舍权，但**须说明不采纳的理由**
|
||||
- 对最终质量负责的是总负责人，不是机械执行校对清单（如同律所"校稿提意见、定稿人拍板"）
|
||||
|
||||
**实战案例（万达小样 2026-06-16，全流程走通）**：校对员揪出"法律审查4个法条编号（722/585/725/496）未按报告自述方法标注〔待核实〕"——定为 🔴 阻断项 → 小Maggie（终审）局部修正统一加注 → execute_code 脚本复核5个编号全部到位 → 闭环 → 交付。校对同时提的"用电增容14千瓦未提及"为 🟡 建议项，不影响结论，记录即可。
|
||||
|
||||
### Maggie 审核成果后的修改流转（建议默认，2026-06-17）
|
||||
|
||||
交付后 Maggie 亲自审核成果 Excel，往往会调整内容。修改怎么流转，**按改动类型分流**——这是「Maggie最终核对」这道防线的操作细则。Maggie 问「我直接在表格里改，还是把意见给你来改」时，主动按下表建议，不要让她从零纠结：
|
||||
|
||||
| 改动类型 | 谁来改 | 为什么 |
|
||||
|---------|--------|--------|
|
||||
| **长文本**（法律风险表述、模版差异逐条、退租建议、整体风险分析） | **Maggie 给意见 → 小Maggie 改** | ①这些单元格是高度结构化长文本（🔴🟡分级、12项逐条、〔待核实〕标记、分段），在 Excel 单元格里手改长文本，换行/缩进/emoji 标记极易乱；②**跨 sheet 联动**——校区 sheet 改了，总览对应行的「主要风险点」要同步，手改易漏；③**规则一致性**——一套规则覆盖 N 个校区，改一处口径，小Maggie 能把同类表述在其他校区一并对齐，手改只能改一处 |
|
||||
| **短数据字段**（金额、面积、日期、主体名称） | **Maggie 直接在表格改更快** | 纯数据订正，不涉格式/联动，绕小Maggie 反而慢 |
|
||||
|
||||
- Maggie 给意见的形式自由：表格里批注/标黄发回，或文字直接说「X校区某列某条改成……」。
|
||||
- **兜底**：若 Maggie 倾向全部自己在表格改，小Maggie 至少要最后帮她**校对一遍格式 + 跨 sheet 一致性**（总览-分表同步、加总、配色、行高——见 Pitfall 1 行高重算）。
|
||||
- 这道流转走完才真正闭环——接续三角色防线「承办→校对→终审→交付→Maggie最终核对」。
|
||||
|
||||
### Maggie 审核 = 规则提炼机会（边改边沟通，2026-06-17 确立）
|
||||
|
||||
Maggie 的目标是把她每一处审核修改**内化成 skill/规则**，让下次成果一次到位、不用她反复改。达成方式是固定协议，不是临时沟通：
|
||||
|
||||
- **节奏：边改边沟通，不是攒完一起说**（Maggie 2026-06-17 拍板）。理由：要内化的是「**为什么这么改（why）**」而非「改了什么（what）」——理由才是规则，改动只是表象。改完一大批再回头猜理由必猜偏，Maggie 过几天也未必记得当时考量。边改边说，理由最新鲜最准。
|
||||
- 反面教训：培训合同「自已→自己」若只看改动会误提炼成"错别字不用改"，是 Maggie 当场说"己字没错、是读取问题"才避免写错规则。
|
||||
- **不打断 Maggie 节奏**：她改时带一句简短理由即可（哪怕几个字），不必等小Maggie回复就继续审。小Maggie 后台记录、提炼候选规则，**不刷屏**，攒到一个段落或她审完一个校区再汇总成规则清单发她确认/纠偏。
|
||||
- **落地机制**：在工作目录建一份「<项目>审核·规则提炼追踪.md」，每处记一条 `修改点 → Maggie的理由 → 提炼的规则`，并标 `适用范围`（打样阶段写"先在X校区打样，暂不推广"）+ `状态`（待确认/已确认）。Maggie 确认后才标"已确认"并落实，确认前不铺开到其他校区。
|
||||
- **打样优先**：新规则先在一个校区（如万达）打样，给 Maggie 看落实效果（重写后的单元格 + 变化对照），她认可标注方式后才推广全部校区。Maggie 说"打样、不着急其他校区"时严格遵守，不自行铺开。
|
||||
- 提炼出的规则最终固化进本 skill（或对应审核 skill）的正文，不只留在追踪文件里——追踪文件是过程载体，skill 正文才是长期记忆。
|
||||
|
||||
---
|
||||
|
||||
### 可回溯配套
|
||||
承办填表时**同产一份「提取依据清单」**——每个关键字段标来源（第几页第几条）。校对员快速溯源，Maggie 核对时点开即知数字出处。
|
||||
|
||||
### 弹性
|
||||
- **日常增量**（动1-2份）：承办+校对+终审三角色
|
||||
- **批量盘点**（5+份变动）：校对拆**法律校对‖格式校对两个并行 subagent**，专业更纯
|
||||
|
||||
### ⚠️ 校对 subagent 防超时（2026-06-17 世茂重做实证）
|
||||
重型**法律校对**（逐条核对多份合同回原文）极易撞 600s ACP 超时被杀（世茂4份合同的法律校对一次性跑→超时；物业组单独重试仍超时）。三条应对：
|
||||
1. **按合同类型/数量拆小再并行**：4份合同别塞一个法律校对 subagent，拆成"租赁组(2份)‖物业组(2份)"两个并行 slot，每个工作量减半，更易在超时前完成。世茂拆分后租赁组顺利 completed 并揪出2个真问题（甲方违约13.4/13.5遗漏、装修延误违约金10倍vs1倍）。
|
||||
2. **格式校对几乎不超时**（纯脚本核对），优先保它跑通。
|
||||
3. **某组反复超时 → 终审（小Maggie）亲自接管核该组**：物业合同我已主审通读过全文，物业组校对超时后由我亲核物业K列即可，符合"终审最终裁判权+局部修"。**不无限重试消耗时间**。
|
||||
- 检查铁律：`delegate_task` 返回后逐个查 `status`，`timeout`/`error` 的不能当没发生——要么拆小重试，要么终审接管，绝不跳过四眼校对环节。
|
||||
|
||||
### ⚠️ OCR 缺失数字不进表，标〔待核PDF〕不编造（2026-06-17 世茂高中物业实证）
|
||||
提取分析 subagent 报的数字若 **OCR 原文无佐证**（如高中物业第九条违约金率正文 OCR 丢失、subagent 记"1%"实为参照青少物业推测），**终审必须回原文核**：搜不到原文支撑的数字，改写成"〔待核PDF〕提取报告记为X但无OCR原文佐证"，**绝不让无依据数字当结论进交付表**。这是"OCR交付不把校验责任推给用户、不凭提取推测定稿"（Doro/Maggie 一贯铁律）在批量场景的落地。终审核对每个关键数字（违约金率、金额、面积、日期）时，区分"提取已核原文" vs "提取推测待核"，后者一律标待核。
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 增量维护（汇总表是持续台账，不是一次性交付）
|
||||
|
||||
汇总表需随**新增合同 / 合同到期 / 提前解除**持续更新，每次变动走三角色分工，保证隔多久都输出同一套标准。
|
||||
|
||||
- 🟢 **新增**：拉最新版→承办（提取+法律审查）→按板块插行+同步总览→校对→终审
|
||||
- 🟡 **到期**：状态改"已到期"，历史行保留不删（台账可追溯），一般走格式校对
|
||||
- 🔴 **提前解除**：状态改"已解除"，退租敞口→实际结算结果，法律校对核结算
|
||||
|
||||
→ 完整步骤见 `references/incremental-maintenance-sop.md`。**所有变动前置铁律：绝不基于旧本地副本改，先从 Nextcloud 拉最新版 xlsx。**
|
||||
|
||||
---
|
||||
|
||||
## 处理流程
|
||||
|
||||
### 整体策略：两阶段法（推荐）
|
||||
|
||||
当校区数量≥5时，采用两阶段法比逐个校区做效率高得多：
|
||||
|
||||
**阶段一：批量生成分析报告（MD文件）**
|
||||
1. 按复杂度分批，每批最多3个校区并行（delegate_task限制）
|
||||
- 简单批（1-2份合同/校区）：如仅物业合同或仅租赁合同的校区
|
||||
- 中等批（2-4份合同/校区）：如租赁+物业的校区
|
||||
- 复杂批（5+份合同/校区）：如有多份补充协议/扩租的校区，每个占1个slot
|
||||
2. 每个subagent读取该校区的MD合同文件，输出一份分析报告到 `<校区名>/XX校区合同分析报告.md`
|
||||
3. 所有批次完成后，确认17/17（或N/N）覆盖率
|
||||
|
||||
**阶段二：从分析报告提取数据→生成汇总Excel**
|
||||
1. 遍历所有分析报告，提取关键字段
|
||||
2. 构建campuses_data JSON
|
||||
3. 一次性生成包含总览sheet的Excel
|
||||
4. 上传Nextcloud + 发给用户确认
|
||||
|
||||
### 单校区处理流程 —— 统一编号 Step 0→7（Maggie 2026-06-23 定，防误读）
|
||||
|
||||
> 🔢 **权威编号（唯一口径，全 skill / 闸门脚本 / 对外沟通都用这套，不得另起别名）**：
|
||||
> Step 0 盘点归类 → Step 1 取文件+OCR → Step 2 承办(法律审查‖提取分析) → Step 3 写12列Excel → Step 4 三角色校对 → Step 5 小Maggie终审 → Step 6 交付自查+存档 →〔全部校区定稿后〕Step 7 整合总览sheet。
|
||||
> **Step 0→6 是单校区闭环**（每校区独立从头走一遍）；**Step 7 是全局收尾**（所有校区定稿后才做一次，不属于单校区流程）。
|
||||
|
||||
#### Step 0: 文件盘点与归类（首次校区必做）
|
||||
第一次接触某校区，**先盘点文件夹有哪些文件、如何排列，逐一核实确认**，再按"租赁/物业 → 场所/位置 → 签约时间"归类排序。详见 `references/file-inventory-classification.md`。归类层级直接映射校区 sheet 的板块划分。后续新签/变更/解除一律按此规则归位。
|
||||
|
||||
#### Step 1: 从Nextcloud取文件 + OCR
|
||||
```python
|
||||
# 1. docker cp 从 Nextcloud 容器复制 PDF 到本地
|
||||
# 2. OCR 提取文本（参考 deepseek-ocr skill）
|
||||
# - 先转图片: pymupdf → 200dpi PNG
|
||||
# - 逐页 OCR: deepseek_ocr.ocr_file()
|
||||
# - 合并保存为 .md 文件（页间用 ---PAGE--- 分隔）
|
||||
# - 纯扫描件文字层=0 必须 OCR；大文件后台跑（见 Pitfall 4）
|
||||
```
|
||||
|
||||
#### Step 2: 承办（四眼分离前半，两个动作并行）
|
||||
本步是承办环节，**两个动作并行产出**（见「三角色分工」节）：
|
||||
- **动作A · 法律审查 = 小Maggie 本人主审**：亲自 `read_file` 逐字通读本校区合同 OCR 全文（含附件），按八维框架当**全新合同**全面审 → 法律风险清单（不外包 subagent，防超时+保质量）。详见 `references/independent-legal-review-framework.md`。
|
||||
- **动作B · 提取分析 = 独立 subagent**：OCR 要素提取 + 模版比对 + 退租敞口测算 + 填表初稿。
|
||||
- 🔴 **模版比对必须回 `07- 房屋租赁合同.docx` 原件逐条核**（subagent context 必带原件路径 + "逐条比对原件、禁用抽象格式概念"指令；终审回原件复核，见「填表分工」节）。
|
||||
- 简单校区（1-2份合同）单个 subagent 可处理多个校区（最多4个）；复杂校区（5+份）单 subagent 只处理1个。
|
||||
- Subagent context 必含：所有合同MD文件路径、07原件路径、输出路径、报告格式模板、"站南通新东方（乙方/承租方）立场分析，输出中文"。
|
||||
|
||||
#### Step 3: 写入Excel汇总表（12列）
|
||||
每个校区一个独立 sheet。结构如下：
|
||||
|
||||
##### Sheet结构
|
||||
- **Row 1**: 标题（合并A:L），如"万达校区 — 租赁合同梳理"
|
||||
- **Row 2**: 基本信息（合并A:L），物业地址、产权人、物业方（长信息行用 \n 分行防横向截断，见 Pitfall 17）
|
||||
- **Row 3**: 分类标题（如"一、租赁合同"），蓝色底D6E4F0
|
||||
- **Row 4**: 列标题（绿色底E2EFDA）
|
||||
- **Row 5+**: 数据行
|
||||
- 分类之间插入标题行
|
||||
- 最后一个分类: 校区整体风险分析与建议（合并A:L）—— **必含板块，验收必查**
|
||||
|
||||
##### 12列标准结构（校区详情sheet，已确认模版 ✅ Maggie 2026-06-23 裁定）
|
||||
| 列 | 内容 | 宽度 |
|
||||
|---|---|---|
|
||||
| A | 序号 | 5 |
|
||||
| B | 文件名称 | 24 |
|
||||
| C | 合同类型 | 14 |
|
||||
| D | 合同当事人 | 26 |
|
||||
| E | 租赁标的/服务范围 | 22 |
|
||||
| F | 面积(㎡) | 10 |
|
||||
| G | 合同期限 | 20 |
|
||||
| H | 金额/费用 | 20 |
|
||||
| I | 核心内容 | 40 |
|
||||
| J | 当前状态 | 10 |
|
||||
| K | 风险点/备注（**法律风险**，动作A产出） | 40 |
|
||||
| L | 与标准模版差异（**模版差异**，动作B产出） | 40 |
|
||||
|
||||
> 🔴 **L 列独立（Maggie 2026-06-23 裁定）**：模版差异 = 独立的 L 列，**绝不并入 K 列**。这与「模版差异 ≠ 法律风险」铁律严丝合缝——K 列装法律风险（参照法律+司法实践）、L 列装模版差异（参照 07 原件），两件不同性质的事物理分列，杜绝下游把合规差距误读为法律风险。
|
||||
> ⚠️ **此前一度出现「11 列、模版差异并入 K 列」的旧表述，已于 2026-06-23 作废**——全 skill 以 12 列含独立 L 列为唯一口径（与 `column-structure.md`、`independent-legal-review-framework.md` 第103行「分列」、增量维护 SOP「动作B独立产出」一致）。
|
||||
> L 列内容必须回 `07- 房屋租赁合同.docx` 原件逐条比对（见「模版差异≠法律风险」铁律下的 07 原件铁律），物业/补充协议标注"无对应标准模版"。
|
||||
> 文件名称必须用实际PDF文件名（如"北翼玖玖-房租合同.pdf"），不能自起名称。
|
||||
> 按文件夹结构分板块——房租/扩租/物业等，跟客户实际的文件夹对应，不能自行重新归类。
|
||||
|
||||
> 📌 **H列三件套（每个金额/费用项标准动作）**：① 标条款号（数字真实出处，不标"详见附件X"指引条）② 换算"≈X个月月租"③ 推算付款截止日（推不出→总结+红字提示）。
|
||||
> 📌 **需客户核实内容整条标红**（富文本红是最后一步→WPS另存/sharedStrings XML层；中间任何 load_workbook→save 会把红打回纯文本）。
|
||||
|
||||
##### 风险分析区（最后一个section）内容结构
|
||||
1. 【整体风险分析】— 校区级别的风险概述
|
||||
2. 【合同变更与提前解除综合分析】— 提前解约成本、部分退租、免责通道
|
||||
3. 【文件汇总说明】— 文件清单与表格条目的对照关系
|
||||
4. 【建议】— 针对性建议
|
||||
|
||||
#### Step 4: 三角色校对（四眼分离后半）
|
||||
承办成果交独立校对，**做者与校者分离**（见「三角色分工」「六维校对清单」节）：
|
||||
- **法律校对 subagent**（六维1-4）：提取文字准、要点无漏、法律风险准、**模版核对准（差异找全、中性、没把差距当风险）**。
|
||||
- **格式校对 subagent**（六维5-6）：字段齐备、总览-分表一致、加总对得上、列结构/配色/行高合模板。
|
||||
- **校对只挑错不下场改**；产出《校对意见清单》→ 按 🔴 阻断项/🟡 建议项分级流转 → 改完闭环复核（见「校对发现问题后的处理机制」节）。
|
||||
- ⚠️ 重型法律校对易撞 600s 超时：按租赁组‖物业组拆小并行；某组反复超时→终审亲自接管核该组（见「校对 subagent 防超时」节）。
|
||||
|
||||
#### Step 5: 小Maggie终审
|
||||
- 合并主审的**法律风险**结论亲手并入 K 列（动作A产出，不经 subagent）。
|
||||
- **回 07 原件复核 L 列模版差异**（像法律风险一样把关，不全信 subagent）。
|
||||
- 汇总校对结果、确认每个问题闭环、最终裁判权（校对意见非绝对权威，不采纳须说明理由）。
|
||||
|
||||
#### Step 6: 交付前自查 + 存档归位
|
||||
- **交付前自查（铁律，不是跑完代码就交）**：x2t 渲染 PDF → pdftotext 拍平 grep 验各板块文字完整 → vision 看渲染图验视觉（截断/错位/红色，**图先压<400KB防超时**）。详见 `references/onlyoffice-xlsx-render-and-rowheight.md`、`ocr-rate-symbol-verification.md`。
|
||||
- **存档归位（Maggie 2026-06-23 纪律）**：汇总表存到**本校区自己的文件夹** `房租物业合同/<校区名>/`，命名 `<校区名/项目名>-梳理-MJ-YYYYMMDD.xlsx`，不放公共目录、不只留本地 /tmp。
|
||||
- 上传 + scan + 清缓存：
|
||||
```bash
|
||||
docker cp <file> <container>:<nc_path>
|
||||
docker exec <container> chown www-data:www-data <nc_path>
|
||||
docker exec -u www-data <container> php occ files:scan admin --path=<path>
|
||||
docker exec <onlyoffice> bash -c 'find /var/lib/onlyoffice/.../cache/files/ -mindepth 1 -delete'
|
||||
docker restart <onlyoffice>
|
||||
```
|
||||
- 交付 Maggie 核对（用 MEDIA: 发），等她最终核对（见「Maggie 审核成果后的修改流转」节）。
|
||||
|
||||
#### Step 7: 整合总览sheet（⚠️ 全部校区定稿后才做一次，非单校区步骤）
|
||||
|
||||
**现行流程（Maggie 2026-06-22 授权调整，已取代旧的「每做完一个校区即时回填大总览」）**：
|
||||
- **每个校区先单独做完它自己的汇总表**（Step 0→6），逐个交付给 Maggie 核对、定稿。
|
||||
- **所有校区都做完、定稿后，最后再统一整合成总览 sheet**——不再每做一个校区就即时回填大总览。
|
||||
- 总览 sheet 每行一个校区：承租主体、出租方、物业方、面积、期限、租金、物业费、押金、主要风险点、状态→「已梳理」。整合时从各校区已定稿的单表抽取，保证总览与分表一致。
|
||||
- **理由**：单校区逐个打样定稿（格式/定级口径先在单表上对齐 Maggie 要求）再整合，避免在未定稿的口径上铺开大总览、回头大面积返工。与「打样优先、未定稿不铺开」一脉相承。
|
||||
- ⚠️ 这是 Maggie **明确授权的 workflow 调整**，已固化于此——按本条执行；其余流程不得擅自改动（见开头「元规则」）。
|
||||
- 存放：总览表存项目根目录（`履约期内非集采合同-综办/房租物业合同/` 或 Maggie 指定处），与各校区单表（存各自校区文件夹）分工明确。
|
||||
|
||||
## 分析报告模板（每校区MD文件）
|
||||
|
||||
每个校区的分析报告遵循以下标准结构：
|
||||
|
||||
```markdown
|
||||
# XX校区合同全面分析报告
|
||||
|
||||
> **分析立场**：南通新东方（乙方/承租方）
|
||||
> **合同数量**：X份（描述构成）
|
||||
> **物业地址**：XXXX
|
||||
|
||||
## 一、合同概览
|
||||
表格列出所有合同：甲方、乙方、位置、面积、期限、签约日期等。
|
||||
如有多份合同，用总表一目了然。
|
||||
|
||||
## 二、租赁合同详情
|
||||
表格：年租金（含分年列示）、递增规则、免租期、付款方式、押金/保证金、
|
||||
逾期利率、拖欠解约门槛、提前解约赔偿等。
|
||||
有补充协议/变更的，按时间线列出变更历史。
|
||||
|
||||
## 三、物业合同详情（如有）
|
||||
表格：物业费标准、付款周期、滞纳金、电费单价、与租赁合同联动关系等。
|
||||
|
||||
## 四、终止框架分析
|
||||
- 确定vs不确定期限
|
||||
- 提前解约成本估算（确定成本+不确定成本-可收回金额）
|
||||
- 恢复原状义务
|
||||
- 免租期追回条款
|
||||
- 民法典566条/580条适用分析（简要）
|
||||
|
||||
## 五、综合风险评级和建议
|
||||
- 风险评级：🔴高/🟡中/🟢低 + 具体风险项
|
||||
- 针对性建议（按优先级排列）
|
||||
```
|
||||
|
||||
### 汇总表总览sheet 风险等级配色
|
||||
```python
|
||||
# Excel风险等级背景色
|
||||
red_fill = PatternFill(start_color='FFC7CE', fill_type='solid') # 🔴高风险
|
||||
yellow_fill = PatternFill(start_color='FFEB9C', fill_type='solid') # 🟡中风险
|
||||
green_fill = PatternFill(start_color='C6EFCE', fill_type='solid') # 🟢低风险
|
||||
```
|
||||
|
||||
### 总览sheet标准列（12列，已确认模版）
|
||||
| 列 | 内容 | 宽度 |
|
||||
|---|---|---|
|
||||
| A | 序号 | 5 |
|
||||
| B | 校区名称 | 10 |
|
||||
| C | 承租主体 | 20 |
|
||||
| D | 出租方（当前） | 18 |
|
||||
| E | 物业方 | 18 |
|
||||
| F | 当前租赁面积(㎡) | 12 |
|
||||
| G | 租赁期限 | 20 |
|
||||
| H | 季度租金(元) | 15 |
|
||||
| I | 季度物业费(元) | 15 |
|
||||
| J | 押金合计(元) | 12 |
|
||||
| K | 主要风险点 | 35 |
|
||||
| L | 备注 | 25 |
|
||||
|
||||
> ⚠️ 注意：没有"风险等级"列。风险评级信息写在K列（主要风险点）的开头即可。
|
||||
> 不要自行添加列——必须与用户确认的模版完全一致。
|
||||
|
||||
## 模版对比方法论
|
||||
|
||||
> 🔴🔴 **铁律（Maggie 2026-06-23，"记住！！！"）：所有"与模版的比对"一律以 `07- 房屋租赁合同.docx` 原件为唯一基准，必须用 python-docx 打开模版原件逐条核对。**
|
||||
> - **禁止**用"标准商业地产格式""星展商业格式""商业格式常见"等抽象概念当参照系——那是凭印象的二手归纳，不是模版比对。
|
||||
> - **禁止**拿本 skill 的 checklist/方法论归纳条款当模版替身——清单只是导航，真值在 07 原件 docx 里；每次比对都回原件读真身。
|
||||
> - 模版原件取法：`docker cp nextcloud-nextcloud-1:"/var/www/html/data/admin/files/小Maggie协作区/南通新东方/参考文件/07- 房屋租赁合同.docx" /tmp/xxx/07模版原件.docx`（注意 `07-` 后有一个空格）。
|
||||
> - **失效模式（2026-06-23 人民中路+悦拾光实证）**：两份梳理表 L列最初都拿"商业格式"概念写差异、没回 07 原件，结果 ①把模版本身的标配条款（0.1‰逾期、含疫情、优先权…）误当成"本合同特别友好"的优势；②漏掉真实偏离——人民中路第八条抵押被由模版"甲方**不得**抵押"改成"甲方**可**抵押"（对乙方不利）、第十二条办学许可证免责款（模版12.4）被整条删除（教培退出保护缺失）。回原件逐条核才暴露。详见 `references/template-comparison-checklist.md` 顶部铁律。
|
||||
> - **同源判定**：南通新东方多数租赁合同就是 07 模版填空而成（条款号/措辞/顺序逐条对应），正确定性是"与 07 模版高度同源"，差异只在填空值与被改动条款——别把模版标配当本合同特色，也别把"同源合同"误判成"非标准独立友好范本"。
|
||||
|
||||
### 关注的模版核心条款
|
||||
| 条款 | 模版内容 | 对比要点 |
|
||||
|---|---|---|
|
||||
| Art.10.2 任意解除权 | 提前X天通知 + 年租金X%违约金 | 是否有此条款、通知期、违约金比例 |
|
||||
| Art.10.3 甲方终止 | 违约金 + 退押金 + 装修损失公式 | 赔偿是否完整 |
|
||||
| Art.10.4 逾期付款 | 0.1‰/日 + 15天催缴后X天 | 违约金率、宽限期 |
|
||||
| Art.11 不可抗力 | 含疫情+行业治理+政策变更 | 范围是否完整 |
|
||||
| Art.12.4 办学许可证 | 房屋/政策原因无法办证→免责解除 | 是否有此条款 |
|
||||
| Art.8.4 续租 | 提前1个月通知 | 通知期 |
|
||||
| Art.9 优先权 | 优先承租+优先购买 | 是否齐全 |
|
||||
| Art.14.5 非竞争 | 不租给同类机构 | 是否有 |
|
||||
| 补充条款 | 装修改造+标识广告+增容 | 是否有 |
|
||||
|
||||
### 对比原则
|
||||
- 只关注实质性差异，不比对填空值
|
||||
- 违约金比例差异必须量化
|
||||
- 甲方为自然人的合同通常偏差大（非标准格式）
|
||||
- 物业合同无标准模版，标注"物业服务协议，无对应标准模版"
|
||||
|
||||
## 提前退租风险分析框架（参照万达法律意见书）
|
||||
|
||||
每个校区的【合同变更与提前解除综合分析】部分，必须按以下框架展开（不是简单罗列条款原文）：
|
||||
|
||||
### 1. 区分违约金条款的适用范围
|
||||
- 合同中的违约金条款是否覆盖"无故提前退租"？
|
||||
- 很多合同的违约金仅适用于列举的特定违约情形（如欠租、擅自转租等），**不能直接适用于主动退租**
|
||||
- 如有任意解除权条款（模版Art.10.2），则按该条款计算
|
||||
|
||||
### 2. 确定责任 vs 不确定责任
|
||||
| 类别 | 内容 | 说明 |
|
||||
|------|------|------|
|
||||
| **确定责任** | 有明确合同依据的（如押金没收、约定违约金） | 直接计算金额 |
|
||||
| **不确定责任** | 需甲方举证实际损失的 | 列出可能范围 |
|
||||
|
||||
不确定责任的三大类：
|
||||
- **空置期租金损失**：依据《江苏省高级人民法院关于审理城镇房屋租赁合同纠纷案件若干问题的意见》第26条，最长不超过6个月。实际支持金额取决于房屋实际空置时间和甲方是否积极减损
|
||||
- **免租期租金追偿**：如合同约定了装修免租期，甲方可能主张免租期优惠前提（完整履行租期）不存在而追偿。司法实践中法院酌情处理
|
||||
- **恢复原状费用**：视合同约定的迁离标准（"按现状交付" vs "恢复原始结构"）
|
||||
|
||||
### 3. 已付未使用租金
|
||||
- 依据《民法典》第566条（合同解除后的清算规则），承租方有权要求返还已付未使用租金
|
||||
- 与违约赔偿金额**相互抵扣**后计算净额
|
||||
|
||||
### 4. 继续履行风险评估
|
||||
- 依据《民法典》第580条，租赁合同中承租人使用房屋的义务属非金钱债务，不适于强制履行
|
||||
- 江苏地区司法实践：承租人明确表示不再租赁甚至已搬离的，法院通常判决解除+违约责任
|
||||
- 结论：甲方要求继续履行通常不构成实质性法律风险
|
||||
|
||||
### 5. 操作建议
|
||||
按优先级排列：
|
||||
1. 优先协商解除（合同一般有"协商一致可解除互不担责"条款）——最优路径
|
||||
2. 尽早发书面解约通知（EMS或可留痕方式）
|
||||
3. 主动配合房屋交接
|
||||
4. 注意恢复原状义务（如有）+注销营业执照地址
|
||||
5. 保留全部往来证据
|
||||
|
||||
### 6. 综合成本估算表
|
||||
风险分析区必须包含一个综合估算，让客户一目了然：
|
||||
- 确定成本（违约金/押金没收）
|
||||
- 不确定成本范围（空置+免租期+恢复原状）
|
||||
- 可收回金额（押金退还/已付未用租金）
|
||||
- 净成本 = 确定成本 + 不确定成本 - 可收回金额
|
||||
|
||||
> **注意**：此框架源自江苏地区司法实践，其他地区可能有差异。法条引用必须核实现行有效版本。
|
||||
|
||||
## 跨Session续做铁律
|
||||
|
||||
### 1. 维护 PROJECT_STATUS.md
|
||||
在项目工作目录（如 `/tmp/nantong-hr/`）维护一个 `PROJECT_STATUS.md`，每次做完一批或中断前更新：
|
||||
```markdown
|
||||
# XX项目 — 状态文件
|
||||
|
||||
## 最新交付物
|
||||
- 文件名：XXX-20260612.xlsx
|
||||
- Nextcloud路径：小Maggie协作区/XX/
|
||||
- 本地副本：/tmp/XX/XXX.xlsx
|
||||
|
||||
## 进度（N个校区）
|
||||
- ✅ 校区A — sheet+总览已填，Maggie已核对通过
|
||||
- ⏳ 校区B — 待梳理
|
||||
|
||||
## 当前任务
|
||||
补齐XX和YY
|
||||
|
||||
## 模版格式
|
||||
- 总览sheet：12列（列名...）
|
||||
- 校区sheet：按文件夹分板块，每份合同一行...
|
||||
```
|
||||
|
||||
### 2. 续做时的第一步：找最新交付物
|
||||
续做时**不能只看本地 /tmp/**——上次的交付物可能只在 Nextcloud 上。必须：
|
||||
1. 先读 PROJECT_STATUS.md（如果存在）
|
||||
2. 去 Nextcloud 检查实际最新文件（`docker cp` 拉下来）
|
||||
3. 打开 Excel 确认实际进度（哪些 sheet 已有、总览哪些行已填）
|
||||
4. 然后才决定"还差什么"
|
||||
|
||||
**反面案例**：只看了本地的旧版 xlsx（20260609），以为只做了1个校区，从头重做了14个校区还换了格式——实际 Nextcloud 上已有15个校区的 20260610 版本。浪费了大量时间且被用户纠正。
|
||||
|
||||
### 3. 严格遵守已确认的模版格式
|
||||
用户说"你看下北翼玖玖的打样"时，**必须逐列核对模版的实际结构**（列数、列名、有无风险等级列等），不能自行"改进"格式。如果认为需要调整格式，先提出建议让用户确认。
|
||||
|
||||
### 4. "之前改好的X校区"在哪个文件 → 改前必须确认版本，别在旧版上叠加（Maggie 2026-06-18 万达确立）
|
||||
用户说"把之前改好的万达也改一下"时，**不能假设手头/主表里的那份就是"改好的"版本**。多校区项目存在两种载体：①独立单校区文件（如世茂样本单独成档）②18-sheet 主汇总表（各校区一个 sheet）。同一校区可能在两处都有，且**版本不同步**。
|
||||
- **实证**：主汇总表 0612 版里的"万达" sheet，K列仍是 06-17 已被 Maggie 纠正、要降级/删除的旧判断（"出租方自然人→偏向甲方"等）——说明 0612 主表里的万达**不是**"改好的"那一版。在它上面加条款号 = 在旧版上叠加，白做。
|
||||
- **铁律**：改某校区前先 `search_files` 全 Nextcloud + 本地找出该校区的**所有** xlsx 载体，逐个开看哪份是"已改好"的终版（看 K列定级口径是否已对齐最新规则），**版本不明就停下来问 Maggie**，别动手。
|
||||
- 牵连面：改 18-sheet 主表会重存整个文件（影响全部校区），范围比改单校区文件大，更要先确认动的是不是对的载体、是不是该动这个范围。
|
||||
|
||||
## Pitfalls
|
||||
|
||||
### 1. OnlyOffice合并单元格行高不自动扩展
|
||||
合并单元格（如风险分析区A:L合并）设置`height=None`（自动）在OnlyOffice中不生效，内容会被截断。**必须手动计算并设置行高**。
|
||||
|
||||
估算方法：
|
||||
1. 对每行的每列，计算可视行数：将文本按`\n`拆分，每行再按列宽折行（CJK字符占2单位宽，ASCII占1，每行可容纳约 `col_width × 1.2` 个字符单位）
|
||||
2. 对合并单元格，有效列宽 = 所有合并列宽度之和（如A:K合并=231单位）
|
||||
3. 取每行中可视行数最大的列
|
||||
4. 行高 = 可视行数 × 15pt + 20%余量
|
||||
5. **每次新增内容到K/L列或风险分析区后，必须重新计算该行行高**——不要假设原来的高度还够
|
||||
|
||||
> 📐 **行高 409.5/409.6pt 不是 xlsx 天花板，是 OnlyOffice 网页编辑器的 clamp 值**（2026-06-17 实测厘清）：openpyxl 从文件层写 900pt 能保留、OnlyOffice x2t 引擎也不 clamp；只有在**网页版编辑器里打开保存**才会把超限行高压回 ~409.5。所以"调高行高显示全部内容"可行——只要从脚本写、走交付链路上传，别再用网页端编辑保存。完整三层行为、x2t round-trip 测法、截断 vs 数据完整的区分见 `references/onlyoffice-xlsx-rowheight-rendering.md`；行高估算用 `scripts/xlsx-rowheight-analyze.py <文件.xlsx>`（只读，标出"当前行高 < 建议行高"的行）。**注意**：若 Maggie 说"就按当前最高行距、不用调"则保持现状不折腾——能调高≠该擅自调（方案≠授权）。
|
||||
|
||||
### 1b. 局部编辑已交付 xlsx：openpyxl 只改 value 保格式 + 长单元格 PDF 截断真相（2026-06-17 万达打样）
|
||||
|
||||
Maggie 审核后要改某些单元格（如给法律风险列补条款标注）时，**不重新生成整表**，用 openpyxl 局部改：
|
||||
|
||||
```python
|
||||
import openpyxl, shutil
|
||||
shutil.copy2(SRC, OUT)
|
||||
wb = openpyxl.load_workbook(OUT) # 不加 data_only，保留公式/样式
|
||||
ws = wb['万达']
|
||||
ws.cell(row=5, column=11).value = new_text # 只赋 value，字体/换行/对齐/填充/合并/行高自动保留
|
||||
wb.save(OUT)
|
||||
```
|
||||
|
||||
- **只赋 `.value` 不动 `.font/.alignment/.fill`**，样式自动保真。改完务必跑保真核对：逐项比对旧/新单元格的 `font.name`、`font.size`、`alignment.wrap_text`、`alignment.vertical`、`merged_cells.ranges` 数量、`row_dimensions[r].height` 是否一致。
|
||||
- **定位长单元格别靠肉眼数行**：先 `ws.cell(row,col).value[:30]` 确认目标，写入后用 `关键词 in str(cell.value)` 验证内容到位、原错误词清零。
|
||||
- ⚠️ **长单元格在 PDF/打印导出会被列宽截断，但数据层完整、OnlyOffice 在线编辑视图完整**（2026-06-17 实证：870字符的法律风险单元格，OnlyOffice x2t 导 PDF 后 pdftotext 提取不到条款标注，一度误判"写丢了"）。排查时**别用 PDF 文本提取来验证 xlsx 内容是否写入**——要直接 `openpyxl ... data_only=True` 读单元格 value 确认。截断只是导出视图的固有限制（行高920磅+自动换行在编辑视图里足够容纳20行），不是写坏。若客户最终要打印/导 PDF 给客户看，才需另调版式（拆分单元格或缩字号），平时不用管。
|
||||
- 交付命名走 Maggie 后缀式：`原名-rev. MJ-日期.xlsx`（见 file-naming-convention skill）。
|
||||
- ⚠️ **pdftotext 验证长单元格文字完整性必须先去折行再 grep，否则假阴性（2026-06-22 世茂实证）**：x2t 渲染 PDF 后用 `pdftotext` 提取来验证某长句是否完整写入时，pdftotext 会**按单元格列宽把长句折行**（如"未明确具体月份（如是否为12月\n15日）"被换行符断开），直接 `grep "完整句"` 会**全部 ❌ 假阴性**，极易误判成"文字截断/写丢"。正解：先 `tr -d '\n' | tr -d ' '` 把整页拍平成单行，再 `grep` 各关键句——本次拍平后六段全 ✅，证明只是渲染折行、文字完整。**别拿带折行的 pdftotext 输出判截断**（同 Pitfall 1b"别用 PDF 文本提取验证 xlsx 内容"的延伸：要么读 xlsx 数据层，要么 pdftotext 拍平后再比对）。
|
||||
- **交付前渲染自查（铁律，不是跑完代码就交）**：用 OnlyOffice 的 x2t 引擎（Maggie 同款）把 xlsx 渲染成 PDF 看一遍，再用 pdftotext grep 各板块末尾锚点确认无截断。完整配方+权限坑+行高409.5上限真相见 `references/onlyoffice-xlsx-render-and-rowheight.md`。行高统一 **409.6pt**（Maggie 2026-06-17 拍板"按当前最高行距"，不再调更高）。
|
||||
- **🟢 交付前加一道 vision 视觉验收（2026-06-22 vision 配好后确立）**：x2t 渲染 PDF→`pdftoppm` 转 PNG→`vision_analyze` 看图。实测能抓出**纯文字提取（grep）发现不了**的问题：① 红色标记是否真渲染成红色（配合 PIL 像素检测 `(R>120)&(G<90)&(B<90)` 数红像素双重确认）② 文字视觉截断/版面错位 ③ 跨页切断。这是"文字提取验证"的盲区补充——grep 只能证明文字在数据层，看不出视觉呈现。两层都过（pdftotext 拍平 grep 验文字完整 + vision 验视觉呈现）再交。
|
||||
- 🔴 **vision 报"截断"先区分「PDF 分页切断」vs「真数据丢失」，别误判返工（2026-06-22 悦拾光实证）**：vision 看 x2t 渲染图报某超长行（如 736pt 的付款清单）"底部被切断、内容缺失"时，**先回数据层核**：① openpyxl 读该单元格 value（富文本用 `''.join(t.text...)` 取全文）确认内容完整、② 行高已设足够、③ 全 PDF（不只那一页）pdftotext 拍平 grep 该末尾内容——若三者都在，则 vision 看到的"截断"是 **PDF 分页边界把超长行切到下一页**的视觉现象，在 Excel/OnlyOffice 滚动查看完全正常，**不是数据丢失、不需返工**。只有"打印/导PDF给客户看"场景才需优化分页。区分判据：数据层完整 + 跨页能搜到 = 分页现象（不动）；数据层就缺 = 真丢失（修行高/内容）。这与 Pitfall 1b「长单元格 PDF 导出截断但数据完整」同源——视图截断 ≠ 数据坏。
|
||||
|
||||
### 2. 核心内容栏不放基础设施规格
|
||||
"最大供电≥150kW"等基础设施配套约定不是核心商业条款，不放I列（核心内容）。核心内容聚焦于：租金、违约金、解除权、优先权、不可抗力等对业务有实质影响的条款。
|
||||
|
||||
### 2b. 租赁标的（E列）房号/铺号写全，不用"等X铺"省略（Maggie 2026-06-18 世茂确立）
|
||||
E列租赁标的的具体房号/铺号要**全部写上，方便查阅**，不要用"二层18-107-3等5铺"这种省略式。
|
||||
- 改法：把"二层18-107-3**等5铺**"写全为"二层18-107-3、18-108-2、18-110-2、18-111-2、18-112-2号商铺（套内968.28㎡）"。
|
||||
- ⚠️ **物业合同的房号以物业合同自己的原文为准核对**，不能直接套租赁合同的（虽多半相同，仍要回物业 OCR 原文核一遍——世茂物业第51行确含全部5房号，与租赁一致）。
|
||||
- 顺手补套内面积，查阅更完整。
|
||||
- 这条与"H列金额标条款号""K列风险标条款号"同属一个 Maggie 偏好：**交付物要可核对、信息要完整，不图省略**。
|
||||
|
||||
### 3. openpyxl heredoc字符串陷阱
|
||||
在Python heredoc/f-string中写中文+引号混合内容容易触发SyntaxError。建议用`lines.append()`逐行构建长文本，不用多行字符串拼接。
|
||||
|
||||
### 4. OCR大文件用后台进程
|
||||
4份以上大PDF（>5MB每份）在单个`execute_code`中会超300秒。写OCR脚本到临时文件，用`terminal(background=true, notify_on_complete=true)`运行：
|
||||
```python
|
||||
# Write script to /tmp/ocr_batch.py, then:
|
||||
terminal(command="python3 /tmp/ocr_batch.py", background=True, notify_on_complete=True, timeout=900)
|
||||
```
|
||||
OCR跑着的同时，可以并行处理其他校区（先做文件少的校区的OCR+分析）。收到完成通知后再回来做分析和填表。
|
||||
|
||||
### 5. 盘点时必须包含空目录
|
||||
文件夹存在但暂无PDF文件的校区（如待上传的）仍要列入总数和处理清单，标记为"待上传"。不要只统计有PDF的目录——会导致总数与总览sheet不一致。
|
||||
|
||||
### 7. 每完成一个校区就上传并发给用户确认
|
||||
不要攒批——做完一个校区立即上传+验证+**用MEDIA:标签发给用户审阅**，确认格式和内容无误再做下一个。用户明确要求"分析完X先发我看下"，逐个交付是硬性要求。
|
||||
|
||||
### 8. 检查同一校区是否有配套法律意见书
|
||||
处理新校区时先搜索Nextcloud相关目录（不止合同目录，也查同名的独立项目文件夹，如`万达校区租赁/`），看是否有已出具的法律意见书。有的话提取核心结论纳入风险分析和K列。
|
||||
|
||||
### 9. 企微发文件用MEDIA标签
|
||||
**不要用send_message工具发企微文件**（不支持）。在回复正文中写`MEDIA:/path/to/file`，gateway自动处理。详见 wecom-file-send-receive skill。
|
||||
|
||||
### 10. Nextcloud文件上传可能中断（Cloudflare Tunnel限制）
|
||||
Nextcloud通过Cloudflare Tunnel暴露时，大文件（>1MB）上传会被截断——日志报"预期文件大小为X字节，实际写入Y字节"，物理目录只有`.part`/`.ocTransferId*`碎片。
|
||||
|
||||
当用户说"文件已上传"但`find`找不到PDF时：
|
||||
1. `php occ files:scan` 重新扫描
|
||||
2. 检查物理目录是否有 `.part` 碎片（`find <path> -name '*.part'`）
|
||||
3. 查MariaDB确认文件是否注册：
|
||||
```sql
|
||||
docker exec nextcloud-db-1 mariadb -u nextcloud -p<password> nextcloud -e "
|
||||
SELECT f.fileid, f.path, f.name, f.size FROM oc_filecache f
|
||||
WHERE f.parent IN (<parent_ids>) ORDER BY f.path;"
|
||||
```
|
||||
（DB密码在Nextcloud config.php的`dbpassword`字段，不是用户密码）
|
||||
4. 如确认上传未完成，**不要反复让用户重试网页上传**——Cloudflare Tunnel的问题会持续存在
|
||||
|
||||
**替代上传方案**：请用户通过企微私信发文件给小Maggie，文件自动保存到`~/.hermes/cache/documents/`，然后用`docker cp`放入Nextcloud：
|
||||
```bash
|
||||
docker cp '<local_path>' <container>:'<nc_path>/<filename>'
|
||||
docker exec <container> chown www-data:www-data '<nc_path>/<filename>'
|
||||
docker exec -u www-data <container> php occ files:scan admin --path='<scan_path>'
|
||||
```
|
||||
|
||||
### 11. delegate_task并行批次规划
|
||||
按复杂度分三档并行处理（每批最多3个slot，是delegate_task的并发上限）：
|
||||
- **简单**（1-2份合同）：可以多个校区塞进1个subagent处理（如1个slot做4个简单校区）
|
||||
- **中等**（2-4份合同）：每个校区1个slot
|
||||
- **复杂**（5+份合同）：每个校区1个slot，context需列出所有文件路径
|
||||
|
||||
典型3批调度：
|
||||
```
|
||||
Batch 1: [星月+解放+跃龙+通大（1 slot简单）] [通大附+通州金鹰（1 slot简单）] [万达（1 slot中等）]
|
||||
Batch 2: [凤凰文化（1 slot）] [悦拾光（1 slot）] [人民中路（1 slot）]
|
||||
Batch 3: [世茂（1 slot）] [金飞达（1 slot复杂）] [北翼玖玖（1 slot复杂）]
|
||||
```
|
||||
|
||||
### 12. 总览sheet校区总数必须与目录一致
|
||||
盘点校区时必须数目录数（包括空目录），不能只数有PDF的目录。出现空目录说明文件待上传，标记为"待上传"而非跳过。用户会核对总数。
|
||||
|
||||
### 13. 用户说"这个项目继续"时，先确认是哪个项目
|
||||
用户说"继续做"、"接着做"等模糊指示时，不要猜——先用session_search查最近的相关session确认。Maggie有多个并行项目（宠物医疗手册、合同梳理、KnowHow协议等），搞错项目浪费双方时间。如果不确定，直接问。
|
||||
|
||||
### 14. 不要跨文件夹重新归类合同
|
||||
客户的文件夹结构（房租/扩租/物业等）是sheet的板块划分依据。即使物业合同在"扩租"文件夹里，也要放在"扩租系列"板块——不能按合同性质重新归类到"物业系列"。客户对着文件夹找文件，必须一一对应。（用户20260609明确纠正过此问题）
|
||||
|
||||
### 15. subagent生成的JSON结构必须统一
|
||||
并行调度多个subagent时，context中必须明确约定JSON输出格式（字段名、数据类型）。不同subagent可能用不同的key名（如`sections` vs `rows`、`risk_summary`是str还是dict），写入Excel时需要额外处理兼容。建议在context中给出JSON schema示例。
|
||||
|
||||
### 16. 租赁+物业双合同：客户在两份里的当事人身份常相反，填 D列勿混（2026-06-22 人民中路确立）
|
||||
同一校区的租赁合同与物业合同里，客户（新东方）的身份**经常相反**：租赁合同里新东方是**乙方（承租方）**；物业合同里新东方常是**甲方（业主/付费方，向物业公司付费）**。填 D列当事人时**逐份回原文核"甲方/乙方分别是谁"**，别因为"都是新东方的合同"就套同一方向。人民中路实证：租赁甲方=琳大鞍(出租)、乙方=新东方；物业甲方=新东方(付费)、乙方=华光物业。处置：物业行 D列主动加注"本合同中新东方为甲方，与租赁合同当事人方向相反"防误读；**审查立场也随身份切换**——审租赁站承租方(乙方)立场，审物业站付费方(甲方)立场。
|
||||
|
||||
### 17. 行2基本信息等"长横向信息行"用 \n 换行排版，防 PDF 渲染右侧截断（2026-06-22 人民中路 vision 验收确立）
|
||||
合并单元格（A2:L2）里塞一长串"项目 | 出租方 | 物业方 | 承租方"信息时，若写成**单行**，x2t/PDF 渲染会因超出页宽被**右边距截断**（人民中路初版"物业方"后的公司名被切掉，是 vision 视觉验收发现的）。正解：长信息行按主体**用 `\n` 分行排版**（项目一行、出租方+物业方一行、承租方一行），并把行高调够（3行约46pt）。这与 Pitfall 1（行高纵向截断）是两个轴：Pitfall 1 防纵向截断、本条防横向截断。**交付前 vision_analyze 看渲染图能抓出这类横向溢出**——是 vision 工具配好后新增的一道视觉验收价值点。
|
||||
|
||||
### 18. 🔴 新建/增补单校区汇总表：第一步加载本 skill + 对照已确认样本，禁止 openpyxl 裸做（2026-06-22 悦拾光教训）
|
||||
|
||||
被要求「做好/做一下某校区汇总表」时——哪怕指令看起来很简单——**第一步是加载本 skill 并对照已确认的样本（如世茂单校区表）逐板块复刻**，绝不直接 openpyxl 从头裸写。裸做必然漏标准板块、跳过校对。
|
||||
|
||||
- **悦拾光实证（两处当场被 Maggie 指出）**：① 裸做的悦拾光表**漏了「校区整体风险分析与建议」段**（skill「Sheet结构」明确要求每校区 sheet 末尾必有此板块，合并 A:L，含整体评价/主要法律关注点/提前解约成本/续签建议——见 ⑧ 整体风险分析段）；② 整个**三角色 workflow（承办→校对→终审）被跳过**，没走 `delegate_task` 法律校对‖格式校对，没做终审闭环。
|
||||
- **铁律①——整体风险分析与建议段是必须板块，单校区/新增校区表同样要有**：不因「只是一份表/只有一个校区」省略。它是校区 sheet 的收口板块，与逐条风险列同等必备。
|
||||
- **铁律②——指令看似简单 ≠ 可绕过 workflow**：Maggie 给「做好汇总表」这类简短指令时，**仍要走完整 workflow**。她验收时会检查两件事：(a) 标准板块是否齐全（尤其整体风险分析与建议段）；(b) 是否真走了 workflow。两者缺一即返工。
|
||||
- **根因**：把「做表」误判为机械活、绕过 skill 直接裸写代码——于是 skill 里所有沉淀（板块结构、三角色、定级纪律、整体分析段）全部失效。**做表是法律梳理交付物的最后一公里，不是画格子；必须在 skill 框架内做。**
|
||||
- 落地自检（动手前过一遍）：① 我加载本 skill 了吗？② 我对照样本核过板块清单了吗（含整体风险分析与建议段）？③ 我走 workflow / 三角色校对了吗？三个都「是」才动手交付。
|
||||
|
||||
### 19. ✅ 列结构口径已裁定：校区详情 sheet = 12 列含独立 L 列（Maggie 2026-06-23 裁定，原矛盾已消除）
|
||||
|
||||
**背景（历史教训，留作记录）**：skill 内部曾对汇总表列数有两套未对齐的说法——SKILL.md 正文 Step3、第358行一度写"11 列、模版差异并入 K 列"，而 `column-structure.md`、`independent-legal-review-framework.md`「分列」、增量维护 SOP「动作B独立产出」均为"12 列含独立 L 列"。2026-06-23 复盘提请 Maggie 裁定。
|
||||
|
||||
**✅ 裁定结果（唯一口径）**：**校区详情 sheet = 12 列，K 列装法律风险（动作A）、L 列「与标准模版差异」装模版差异（动作B），两者物理分列、绝不并入。** 此前的"11 列/并入 K 列"旧表述全部作废，相关位置（SKILL.md Step3 第525行、第363行、column-structure.md 顶部）已于 2026-06-23 同步更正一致。
|
||||
|
||||
- **为什么 12 列对**：与「模版差异 ≠ 法律风险」铁律严丝合缝——两件不同性质的事（法律风险 vs 合规差距）就该物理分列，挤在 K 列必然让下游误读。多数 reference 文件本就是 12 列口径，"11 列"是某次临时改动没回滚干净的异类。
|
||||
- **模版差异内容铁律不变**：L 列内容**必须回 07 原件逐条核**（见「模版对比方法论」顶部铁律 + 填表分工节的 subagent 强制项），列数已定不影响这条，反而强化它。
|
||||
- **教训**：skill 内部出现"两套说法"时，不应自己"倾向判断"某一套就默认执行（当时我倾向了错的"11 列"），而应提请 Maggie 裁定 + 裁定后立即全文对齐消矛盾——这正是本次的正确处理路径。
|
||||
|
||||
### 20. ⚠️ 三条「合同审查」轨道必须精确区分，别把本梳理线笼统叫「workflow」（2026-06-23 三轮追问教训）
|
||||
|
||||
环境里有**三条名字都含「合同审查」、但性质完全不同**的轨道，极易混为一谈。Maggie 2026-06-23 连问三次（「workflow里模版对比」→「南通新东方租赁合同审查的workflow」→「这个流程」）才让我对准——根因是我把**本 skill 的梳理线**笼统称作「workflow」、还一度跟 uwf 的 `review-contract.yaml` 混了。Maggie 是律师、要求术语精确（USER.md：不用模糊比喻指代有精确定义的技术对象），含糊命名本身就是返工信号。
|
||||
|
||||
| 轨道 | 归谁 | 走什么 | 模版对比？ |
|
||||
|---|---|---|---|
|
||||
| **A. 批量合同审查** | Doro/邱律师团队 | uwf `review-contract.yaml`（classifier→reviewer→editor→复核→deliverer 五角色流水线） | ❌ 不做模版对比 |
|
||||
| **B. 单份文件独立审核** | 南通新东方（Maggie 派） | `nantong-xindongfang-review` skill 的**手动**reviewer+editor 合一模式（**明确「不走 workflow」**） | ❌ 不做模版对比 |
|
||||
| **C. 多校区梳理台账** | 南通新东方（Maggie 派） | **本 skill**（contract-portfolio-analysis）的 Step0→5 + 三角色 | ✅ **模版对比（L列）只在这条线**，回 07 原件 |
|
||||
|
||||
- **要害**：用户问「南通新东方租赁合同审查的 workflow / 模版对比」时，**99% 指的是 C（本 skill 梳理线）**——因为模版对比（L列）只活在 C。别下意识跳到 uwf 的 `review-contract.yaml`（那是 A，与南通新东方严格隔离、且根本不做模版对比，grep 它零命中模版内容）。
|
||||
- **命名纪律**：C 这条线在跟 Maggie 沟通时，称「**南通新东方租赁合同梳理（组合分析）**」或「本 skill 的 Step0→5 流程」，**不要笼统说「workflow」**——「workflow」一词在本环境特指 uwf 那套 YAML 状态机（A），混用会让律师用户反复追问到底指哪条。本 skill 内部把 Step0→5 叫「workflow」是历史习惯（见「元规则」节），但**对外指代时要带限定词**说清是哪条线。
|
||||
- 自检：被问到「合同审查的某个环节」先定位是 A/B/C 哪条，再答；拿不准就先回一句「你指的是 Doro 批量那条、南通单份审核、还是南通梳理台账？」一句话锁定，比答错三轮强。
|
||||
|
||||
### 21. 🔴 校区数/任何「总数」必须用精确列举得出，绝不眼估——南通新东方是 17 个校区（2026-06-23 教训）
|
||||
|
||||
**栽点**：我在 SKILL/脚本/记忆里写「21 个校区」，是扫了一眼 `find ... -type d` 的输出**眼估**的——那次 find 把 `参考文件/`、`万达校区租赁/`、`HRD协商解除/`、`业务合同-培训服务/` 等**非校区目录**也列进来了，我没数就拍了个数。Maggie 当场抓出「你为什么说是 21？是 17」。**最讽刺的是：这正发生在我为「不准凭印象、要逐字核实」写存档的当口**——立规矩的同一下笔就犯了规矩。
|
||||
|
||||
- **铁律：任何进交付物/skill/记忆的「数量、总数、覆盖率」（校区数、合同份数、N/N 覆盖、行数…）必须由精确命令得出，并把得数的命令一并留痕**，绝不眼估、绝不凭印象续写上次的数。
|
||||
- **数校区的唯一正确姿势**：在 `房租物业合同/` 目录内跑 `ls -1d */ | wc -l`（只数子目录、不混入文件），或 `ls -1d */` 逐个列名核对——**不要用 `find -type d`**（它会把上层目录、参考文件、非校区项目目录全捞进来，计数虚高）。
|
||||
- **南通新东方 = 17 个校区**（2026-06-23 精确核定）：万达、世茂、人民中路、凤凰文化、北翼玖玖、南通大厦、小石桥晏园、悦拾光、星月、桃坞路、解放中路、跃龙路、通大、通大附、通州金鹰、金飞达、龙信。注意 `参考文件/`、`万达校区租赁/`（独立法律意见书目录）、`HRD协商解除/`、`业务合同-培训服务/`、`国际青创园租赁/`、`交通银行薪酬代发合作/` **都不是「房租物业合同」下的校区**，别误计入。
|
||||
- **闸门脚本是数量的真相源，不是写死的数字**：`campus-workflow-gate.py` 用**实时 `ls`** 定位校区，靠它而不是任何文档里抄来的数字；文档里出现的「17」只是给人看的提示，若将来校区增减，**以脚本实时列举为准**，并回头改文档别留旧数。
|
||||
- 这条是「第一铁律·逐字通读」「开工铁律·单校区独立闭环」在**计数动作**上的同一抓手：判断要回原文，**计数要回精确列举**，两者都禁印象式推断。
|
||||
|
||||
### 22. 🔴 改本 skill 自身的「多处联动规则」（SKILL.md + 闸门脚本 + reference 三处口径）：一次一处原子改 + 改完 grep 验，别在同一轮里又 patch 又长篇说话（2026-06-23 编号统一耗时 40 分钟教训）
|
||||
|
||||
**栽点**：统一 Step 编号时，SKILL.md 正文、`scripts/campus-workflow-gate.py`、顶部引用三处要同步改。我连续几轮把 `patch` 调用和一大段解说塞在**同一轮回复**里，patch 没真正落地（被下一条用户消息打断/未执行完），我却**没在第一次核实发现「没落地」时就换方法**，反而重复同样的动作好几轮——直到 Maggie 问「为什么这么久，哪里卡住了」。本质是违反了本 skill「不能假设成功、要核实；发现没成功要立即换方法」的同一条纪律，只不过对象从合同换成了 skill 文件自己。
|
||||
|
||||
- **铁律①——一次一处原子改**：改多文件联动规则时，**一个 `patch`/`write_file` 调用只做一处改动，不在同一轮夹带长篇解说**。把「改」和「说」分开：先把这一处改干净、拿到成功回执，再说话/再改下一处。夹带 prose 的复合轮最容易让编辑动作没执行完就被打断。
|
||||
- **铁律②——改完立即 grep 验残留，不靠「我以为改了」**：每改一处，紧接着用 `search_files`/`grep` 扫**旧串是否清零、新串是否到位**（如统一编号后 `grep "Step 3.5\|Step 0→5\|完整 6 步"` 必须为空）。没亲眼看到「旧串 0 残留 + 新串就位」之前，绝不说「改好了/检查好了」。这是「第一职业纪律·结论必有依据、自己核实」在改自己文件时的同一抓手。
|
||||
- **铁律③——多处口径必须全绑定一起验**：Step 编号、列结构（12列/L列）、校区数这类「同一事实散落多文件」的口径，改完跑一次**全树扫描**确认所有副本一致（`grep -rn <旧口径> SKILL.md scripts/ references/`）。本 session 正面案例：最后用一次全树 grep 确认「✅ 全树零残留」+ 实跑闸门脚本看输出，才给出有依据的「好了」。
|
||||
- **判据**：凡是「同一规则要改 N 个文件」的维护任务，N 越大越要原子化 + 每步验，绝不攒成一个大复合轮。被用户追问「卡在哪」时，先如实承认「前面几轮的编辑没落地、我没及时换方法」，再用原子改一次性修干净——不要继续掩饰式重试。
|
||||
|
||||
### 23. 🔴🔴 执行纪律：工具调用单独发、不与长篇 prose 同轮；落地用磁盘核实不靠「我以为」；被打断/没落地立即换方法不重复死动作（2026-06-23 人民中路实跑 40 分钟空耗教训，最高频反复犯）
|
||||
|
||||
**这是本 session 反复犯、被 Maggie 连环追问（「为什么这么慢」「哪里卡住了」「跟我发消息没关系，这个时间你早该完成」）的头号执行问题，比任何内容规则都更先拖垮交付。** 与 Pitfall 22 同根，但适用面是**所有任务执行**（OCR、读合同、跑脚本、改文件……），不限于改 skill 文件。
|
||||
|
||||
- **根因机制（必须正视）**：把「工具调用 + 一段解说话」塞进同一轮回复时，工具要等 prose 写完才执行；用户此时若发新消息，**这一轮被接管、那个还没跑的工具调用直接被丢弃**——不是工具坏，是它根本没执行。表现就是「我以为取了 07 模版/读了那两页，实际磁盘上没有」。而「慢」的体感来自：提交→被丢→下一轮先花一次工具核实没落地→再重做，一来一回空转。\n- **铁律①——动作与解说分轮**：要跑工具就**这一轮只发工具、最多一句话**，结果回来再解释/再决定下一步。绝不「边长篇说边夹个 patch/terminal」。prose 越长，被打断丢弃的窗口越大。\n- **铁律②——每轮先核实再行动，绝不假设上一步成功**：接用户消息的第一个动作 = 用一条命令查磁盘真实状态（`ls -la 工作目录` / `wc -l 产物`），确认上一步到底落没落地，再决定干什么。这是「不能假设成功」在执行层的落地，也是被打断后**唯一正确的续跑姿势**——产物落盘可续，核实即接上，不重来不做丢。\n- **铁律③——发现「没落地」立即换方法，绝不重复同一死动作**：同一个调用连续两轮没成功，就是信号——停下，换更简单/更原子的方式（如把复合 patch 拆成单行替换、把「边说边改」改成「纯工具一发」），而不是第三次第四次重复一模一样的提交。本 session 正是重复了好几轮才换法，才空耗 40 分钟。\n- **铁律④——被追问进度先如实承认，不掩饰**：用户问「卡哪了/为什么慢」时，先用一条命令核实当前真实进度并如实报「X 步没落地、根因是我边说边做被丢、我没及时换方法」，再原子修干净。绝不含糊搪塞「快好了」或继续掩饰式重试——Maggie 明确反感把她当测试员、反感空转。\n- **落地自检（每次要发工具前过一遍）**：① 这一轮我是不是又在「长篇说话 + 夹工具」？是→拆开，先发工具。② 上一步我**亲眼**在工具输出里见到成功回执了吗？没有→先核实别假设。③ 同一动作我是不是已经连试两轮没成？是→换方法别再重复。\n- 这条与「第一职业纪律·结论必有依据自己核实」「Pitfall 22·一次一处原子改+grep 验」三位一体：22 管改 skill 文件、本条管一切任务执行，核心同一句——**少说多做、单发即验、不假设、不空转**。
|
||||
|
||||
## 参考文件
|
||||
- `references/file-inventory-classification.md` — **文件盘点与归类规则**：校区首现时建立，租赁/物业→场所→签约时间，贯穿全流程不跨文件夹重排
|
||||
- `references/ocr-rate-symbol-verification.md` — **OCR 费率符号核对配方（‰ vs %）**：双跑交叉（整页 vs 裁图放大重 OCR）、量级常识闸门、两次不一致即升级人工带裁图、vision provider 未配退路
|
||||
- `references/independent-legal-review-framework.md` — **独立法律审查框架（动作A，八维）**：把每份合同当新合同全面审，区别于模版比对
|
||||
- `references/incremental-maintenance-sop.md` — **增量维护 SOP**：新增/到期/提前解除三类变动的三角色处理流程
|
||||
- `references/chinese-diagram-rendering.md` — **中文流程图/图表渲染**：matplotlib 豆腐块根因+修复，HTML 首选方案，无法自检图像时的退路
|
||||
- `templates/lease-review-flowchart.html` — HTML 流程图起始模板（语义配色、div+箭头字符，中文零乱码）
|
||||
- `references/column-structure.md` — 12列Excel结构详细说明
|
||||
- `references/onlyoffice-xlsx-rowheight-rendering.md` — **OnlyOffice 行高/合并单元格截断/渲染核查**：409.5pt clamp 真相（文件层 vs x2t vs 网页编辑器三层行为）、x2t round-trip 测 clamp、数据完整≠视图不截断、可复用 SOP
|
||||
- `scripts/xlsx-rowheight-analyze.py` — **行高分析脚本**（只读）：估算每个长单元格所需行高，标出可能截断的行
|
||||
- `scripts/fix-richtext-rpr-order.py` — **富文本 rPr 顺序修复脚本**：openpyxl 标红（CellRichText）后把 `<rPr>` 子元素改成 Excel 合规顺序（rFont→sz→color）。⚠️ **实证：修了顺序 Excel 仍报"需要修复"**，本脚本不保证解决问题，仅作记录。支持 `--check` 只检查。**正解是别用富文本标红，用纯文本前缀。**
|
||||
- `scripts/edit-redmarked-xlsx.py` — **安全编辑「已标红（WPS规范化）」xlsx 的脚本+工具库**：绝不用 openpyxl 重存（会毁红色），在 sharedStrings.xml XML 层外科手术只改目标 `<t>`、红 run 不碰。含 `--verify` 五查（sharedStrings在/红色数/zip+XML完整/Content_Types置首/与基线同构）、`--map`（单元格→si索引）、`--show-si`（看 run 结构），及可 import 的 `surgical_edit_si/delete_run_and_renumber/repack`（已验证正确，照抄别重写）。改红标 xlsx 必用。
|
||||
- `references/openpyxl-excel-richtext-pitfall.md` — **openpyxl 富文本→Excel"需要修复"陷阱全记录**：为什么不能用 CellRichText 局部着色、试过的所有修法（rPr 顺序/charset/去富文本全失败）、为什么 WPS/x2t/openpyxl 都骗过自己唯独 Excel 报错、"本地验不了 Excel 就如实告诉用户别当测试员"的行为铁律、正解（纯文本前缀）。
|
||||
- `references/template-comparison-checklist.md` — 标准模版对比清单
|
||||
- `references/termination-risk-framework.md` — 提前退租风险分析框架（法律依据+分析模板+关键判断点）
|
||||
- `references/nextcloud-file-diagnostics.md` — Nextcloud文件上传失败排查步骤（含MariaDB查询方法）
|
||||
- `references/onlyoffice-xlsx-render-and-rowheight.md` — **交付前渲染自查配方**（x2t引擎+权限坑）+ 行高409.5上限真相（网页编辑器clamp根因，统一409.6）
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
# 批量校区审查执行纪律（2026-07-03 龙信返工总结）
|
||||
|
||||
## 根因
|
||||
连续做6个校区（星月→跃龙路→通州金鹰→小石桥晏园→龙信→海门临时），到第4-5个时执行质量明显衰减：
|
||||
- 跳过逐字通读（物业20页中间跳了）
|
||||
- 套用前一校区结论代替独立审查（海门临时照搬龙信结论）
|
||||
- K列法律风险没做八维框架（凭直觉归纳）
|
||||
- 不跑物理检查点脚本
|
||||
- 擅自删除旧文件（没被授权）
|
||||
|
||||
## 铁律
|
||||
|
||||
### 1. Session容量限制
|
||||
**连续做3个校区后，必须主动提醒Maggie开新对话。** 不等用户发现，自己数到第3个就提醒。
|
||||
|
||||
### 2. 每份合同独立一行
|
||||
3份合同=3行，不合并。Maggie原话："3份合同分别提取，分别审阅，做成三行，不要混在一起写"
|
||||
|
||||
### 3. 所有租赁合同必须做07模版比对
|
||||
不论是新东方制式还是甲方制式，租赁合同一律delegate做07比对。L列从比对文件逐条摘。龙信教训：第一版因"非新东方制式"就写了一句"无对应模版"被打回。
|
||||
|
||||
### 4. 不擅自删除任何文件
|
||||
旧版汇总表保留，不清理。Maggie原话："我没让你清理旧表，请恢复这两个旧表，没有让做的事情不要自己擅自进行"
|
||||
|
||||
### 5. 逐字逐句不是口号
|
||||
被问"你是自己逐字逐句审阅的么？"——如果答案是否定的，诚实说，然后补做。不粉饰。衰减信号：
|
||||
- 发现自己在写"条款结构与XX类似"→没独立审
|
||||
- 物业合同20页只grep了关键词→没通读
|
||||
- K列写完觉得"差不多"但说不出某条依据→没审到位
|
||||
|
||||
### 6. H列月租换算写法
|
||||
行内括号写（如"年340,000元（月租≈28,333元）"），不另起行。
|
||||
|
||||
## 解决模式
|
||||
- 做到第3个校区时：停下来，主动告诉Maggie建议开新对话
|
||||
- 每份合同做完K列后自问：这条风险的条款号出处是什么？答不出=返工
|
||||
- 交付前必跑kl-separation-check.py，不凭眼判断
|
||||
+64
@@ -0,0 +1,64 @@
|
||||
# 北翼玖玖 / 金飞达纠偏：17份文件先出“按租赁物+时间顺序”的列表
|
||||
|
||||
## 触发场景
|
||||
- 用户说“先把17个文件列表梳理出来”
|
||||
- 用户强调“根据租赁物，同一租赁物相关合同或文件，按照时间顺序排列”
|
||||
- 校区项目进入正式H/I/K/L审查前，需要先锁定文件编排顺序
|
||||
|
||||
## 本次纠偏结论
|
||||
在北翼玖玖这类多文件校区任务中，**先交付的不是合同类型清单，而是“按租赁物归组 + 组内按时间顺序”的列表**。
|
||||
|
||||
### 具体要求
|
||||
1. 先按**租赁物**分成主线板块；
|
||||
2. 同一租赁物下的**租赁合同、补充协议、退租协议、物业合同、物业补充协议、说明文件**一并放入同组；
|
||||
3. 组内按**签约时间/正文明确生效时间/权利义务转移时间**排序；
|
||||
4. 如果签章页未载明日期，必须明确写“**签署日未载明**”，并说明采用何种时间线索排序；
|
||||
5. 在用户要求“先梳理列表”时，**先给列表，不要抢跑到H/I/K/L审查进度汇报**。
|
||||
|
||||
## 推荐输出格式
|
||||
|
||||
### 租赁物A：……
|
||||
1. 文件名
|
||||
- 性质：……
|
||||
- 时间：……
|
||||
- 说明：……
|
||||
|
||||
### 租赁物B：……
|
||||
1. 文件名
|
||||
- 性质：……
|
||||
- 时间：……
|
||||
- 说明：……
|
||||
|
||||
最后补一句：
|
||||
- 共几组
|
||||
- 共几份
|
||||
- 哪些日期系正文线索排序、哪些日期未载明
|
||||
|
||||
## 本次北翼玖玖实际归组方法
|
||||
### A组：4幢101、102、201室 + 1幢507室
|
||||
主线顺序：
|
||||
- 房租主合同
|
||||
- 物业主合同
|
||||
- 物业减免补充协议
|
||||
- 房租减免补充协议
|
||||
- 物业退租协议
|
||||
- 物业补充协议二
|
||||
- 房屋部分退租协议
|
||||
- 4幢补充协议三（权利义务转移）
|
||||
- 两份物业电费/水电费收款变更补充协议
|
||||
- 房租目录下特殊情况说明
|
||||
|
||||
### B组：1幢205/206/207/208/209室（核心租赁为206-209）
|
||||
主线顺序：
|
||||
- 扩租房屋合同
|
||||
- 配套物业合同
|
||||
- 扩租房屋租赁合同补充协议（权利义务转移）
|
||||
- 扩租物业补充协议
|
||||
- 扩租物业补充协议（电费教育科技）
|
||||
- 扩租目录下特殊情况说明
|
||||
|
||||
## 操作提醒
|
||||
- “按文件夹盘点”与“按租赁物输出”是两层动作：
|
||||
- 盘点时尊重源目录（房租/扩租/物业）
|
||||
- 输出时重建为租赁物主线
|
||||
- 同一事项的重复版本/近似版本（尤其电费、水电费收款主体变更协议）**先保留进列表，再在后续审查中判断是否为同一事项不同版本**。
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
# 校区审查范围与排序铁律（2026-07-13 金飞达纠偏）
|
||||
|
||||
## 适用触发
|
||||
当用户说：
|
||||
- “开始某校区的审查和汇总”
|
||||
- “某校区重新整套做”
|
||||
- “按租赁物分类输出”
|
||||
|
||||
默认这是**校区全部合同/PDF文件**的梳理与审查，不是只抓主租赁合同。
|
||||
|
||||
## 范围铁律
|
||||
必须先盘清该校区**全部相关文件**，至少包括：
|
||||
- 租赁合同
|
||||
- 补充协议
|
||||
- 主体变更协议
|
||||
- 物业合同
|
||||
- 物业补充协议
|
||||
- 授权书
|
||||
- 其他与该租赁物直接相关的辅助文件
|
||||
|
||||
用户未明确排除前，**物业合同也在本轮审查和汇总范围内**。
|
||||
|
||||
## 组织铁律
|
||||
输出结构必须：
|
||||
1. **先按租赁物分类**建板块
|
||||
2. 每个租赁物下放入该租赁物的**全部相关文件**
|
||||
3. 板块内部按**签约时间顺序**排列
|
||||
|
||||
排序主键是：
|
||||
- 第一层：租赁物
|
||||
- 第二层：签约时间
|
||||
- 不是文件类型
|
||||
|
||||
## 禁止事项
|
||||
- 禁止把“租赁审查”理解成“只看租赁合同本体”
|
||||
- 禁止先租赁后物业硬分组
|
||||
- 禁止把同一租赁物的物业合同甩到别的板块
|
||||
- 禁止先做主合同，后想起再补物业合同
|
||||
|
||||
## 例外
|
||||
只有确实**无法挂到具体租赁物**的文件，才单列“其他文件”板块，例如：
|
||||
- 校区层面的总授权书
|
||||
- 无法判断对应租赁物的通用说明文件
|
||||
|
||||
## 与开工闸门的配合
|
||||
开始前应先在开工确认中显式写出：
|
||||
- 本校区有哪些文件
|
||||
- 哪些租赁物板块
|
||||
- 每个板块包含哪些文件
|
||||
- 排序是否已按签约时间锁定
|
||||
@@ -0,0 +1,38 @@
|
||||
# 中文流程图/图表渲染：matplotlib 坑 + HTML 首选方案
|
||||
|
||||
> 2026-06-16 实战教训：给 Maggie 画流程图，matplotlib 反复把中文渲染成"豆腐块"（空心方块 tofu），折腾数轮。根因与可靠方案如下。
|
||||
|
||||
## matplotlib 中文豆腐块根因
|
||||
- 系统装了文泉驿 `wqy-zenhei.ttc`，但 **matplotlib 默认不把 `.ttc` 注册进字体缓存**——`rcParams['font.sans-serif']=['WenQuanYi Zen Hei']` 按"字体名"查找会**静默失败、回退成豆腐块**，不报错。
|
||||
- `fc-list :lang=zh` 能看到字体 ≠ matplotlib 能按名字用它。
|
||||
|
||||
## 可靠修复（若必须用 matplotlib）
|
||||
**给每个 text 显式传 `fontproperties` 指向字体文件**，不靠字体名查找：
|
||||
```python
|
||||
import matplotlib.font_manager as fm
|
||||
FP = fm.FontProperties(fname="/usr/share/fonts/truetype/droid/DroidSansFallbackFull.ttf")
|
||||
# Droid Sans Fallback 是 .ttf、已在缓存、支持全中文，比 .ttc 可靠
|
||||
ax.text(x, y, "租赁合同", fontproperties=FP) # 每处都带 fontproperties
|
||||
```
|
||||
验证某字体文件能否渲染中文：渲染单字 '租'，统计中心 1/3 区域笔画占比，>0.08 是真字、<0.05 是空心豆腐块。
|
||||
|
||||
## ★ 首选方案：用 HTML 而非 matplotlib PNG
|
||||
**给非技术用户（Maggie，经企微/OnlyOffice 看）的中文图表/流程图，优先做成自包含 HTML**：
|
||||
1. **中文渲染零风险**——浏览器直接调系统字体，`font-family:"Microsoft YaHei","PingFang SC","WenQuanYi Zen Hei",sans-serif`，绝不豆腐块。
|
||||
2. **企微能直接打开**，可缩放。
|
||||
3. **可自检**——`browser_navigate` 到 `file://` 后看快照里的文字是否正确，比赌 PNG 字体渲染可靠得多。
|
||||
4. 用 div + border + 颜色块画节点、`↓`/`→` 字符画箭头，配色用语义色（蓝=主审、绿=subagent、金=交付）。
|
||||
|
||||
可复制的起始模板：`templates/lease-review-flowchart.html`。
|
||||
|
||||
## ⚠️ 语义色点用纯 CSS 圆点，不要用 emoji（🔵🟢🔴）（2026-06-22 workflow流程图实证）
|
||||
图例/节点里标语义色，**别用 emoji 彩色圆点**——无头浏览器截图环境（Browserbase 等）常缺 emoji 字体，截图里 emoji 渲染成空心方框 `▢`（文本层 emoji 字符其实完好、`browser_console` 测 `looksLikeBox:false`，只是那个截图环境字体缺失）。但你**无法保证 Maggie 的企微/设备一定有 emoji 字体**，交付物要万无一失。
|
||||
- 正解：用**纯 CSS 圆点** `<span class="dot b"></span>`：`.dot{display:inline-block;width:11px;height:11px;border-radius:50%;border:1.5px solid;}`，各色 `.dot.b{background:#BBD9F0;border-color:#2E6DA4;}`…。任何设备、任何环境稳定显示，不依赖 emoji 字体。
|
||||
- 节点本身已有语义底色时，标题里的 emoji 色点是冗余，直接删（靠底色表达语义即可）。
|
||||
- 表意标记 emoji（⚠️📌✅）可保留——渲染更稳，且是真正的语义标记，不是纯装饰色点。
|
||||
- 自检：`browser_navigate` 到 `file://` 后用 `browser_console` 读 `.lg` 的 textContent 确认文本层完整；再 `vision_analyze`/`browser_vision` 看截图确认色点真渲染成彩色圆点（不是方框）。
|
||||
|
||||
## 图像自检：vision 已配好，是主路径（2026-06-22）
|
||||
vision_analyze/browser_vision 已由技术支持配好可用——交付 PNG/HTML 截图前**先自己 vision 看一遍**验证版面/配色/截断/乱码，这是主路径（实测能准确读出渲染图的配色、文字截断、版面错位、色点是否方框）。
|
||||
- **HTML 双层自检**：`browser_navigate` 到 `file://` 看快照验证中文/结构（文本层）+ `browser_vision` 看视觉层（配色/排版/emoji 方框）——两层都过才发。
|
||||
- **兜底（vision 万一又报 "No LLM provider configured for task=vision" 或连不上）**：不把"看不见的 PNG"直接甩用户，改用能推理正确性的格式——HTML（看 `browser_navigate` 快照验证文本层）或纯文字版流程图（方框+箭头字符，零字体依赖），HTML+纯文字兜底一起发。
|
||||
@@ -0,0 +1,60 @@
|
||||
# 南通汇总表列归类规则 (Maggie 2026-07-01 确认)
|
||||
|
||||
## H列（金额/费用）— 只放纯费用
|
||||
|
||||
✅ 属于H列：
|
||||
- 租金标准（单价+月总额）
|
||||
- 物业费标准
|
||||
- 付款推算（各期金额+日期+❗标注）
|
||||
- 履约保证金
|
||||
- 供电增容费用归属
|
||||
- 水电费标准（单价）
|
||||
- 免费停车位
|
||||
|
||||
❌ 不属于H列（常见错误）：
|
||||
- 违约金 → 归I列（核心内容），违约金是合同权利义务安排，不是费用
|
||||
- 逾期违约金 → 归I列
|
||||
- 擅自转租违约金 → 归I列
|
||||
|
||||
## I列（核心内容）— 客观陈述合同约定
|
||||
|
||||
包含：用途限制、转租条件、装修改造权、广告标识、非竞争、维修责任、解除权机制、不可抗力、优先权、续租、消防义务、管辖、通知方式、**违约金条款**。
|
||||
|
||||
## K列（法律风险）— 聚焦风险，不放有利条款
|
||||
|
||||
K列数据行(r5/r8)只写：
|
||||
- 整体评价（一段）
|
||||
- 需注意的风险点（逐条编号）
|
||||
- 提前退租法律后果分析
|
||||
|
||||
❌ "对乙方有利条款"不放K列 → 放整体段(row 10)续签建议里，措辞为"建议保留以下对乙方有利条款"
|
||||
|
||||
## K列·提前退租分析框架
|
||||
|
||||
### 原则：有约定写约定，无约定写法律规定，不做无锚点推测
|
||||
|
||||
### 情况一：合同有明确约定（如凤凰文化第十条第2款）
|
||||
直接写约定内容，不再延伸：
|
||||
```
|
||||
① 单方解除：提前60日通知 + 初年年租金20%违约金 + 租金及其他费用结算至解除日
|
||||
② 可收回：结算至解除日 + 押金30工作日退还
|
||||
③ 其他法定/约定解除路径（办学许可证/不可抗力等）
|
||||
```
|
||||
**禁止**："可能主张损失""建议协商规避""不确定责任"等无锚点推测。
|
||||
|
||||
### 情况二：合同无明确约定
|
||||
三层分析（每层都有法律依据，不是推测）：
|
||||
1. **法定解除权**：《民法典》563条（不可抗力致目的不能实现、对方根本违约等）+ 租赁特有法定解除
|
||||
2. **无法定事由 = 违约**：《民法典》584条——赔偿因违约造成的损失（含履行后可获利益），上限=可预见损失
|
||||
3. **损失具体构成**：空置期租金（司法实践3-6个月）、押金是否可抵扣、预付租金结算
|
||||
|
||||
## 整体段(row 10)结构
|
||||
|
||||
```
|
||||
【整体评价】
|
||||
【提前退租法律后果】
|
||||
【其他法律关注点】
|
||||
【续签建议】
|
||||
· 建议补充/修改：...
|
||||
· 建议保留以下对乙方有利条款：①办学许可证免责解约权 ②不可抗力 ③优先权 ...
|
||||
```
|
||||
@@ -0,0 +1,70 @@
|
||||
# 汇总表列内容归类规则（Maggie 2026-07-01 确认）
|
||||
|
||||
## H列（金额/费用）—— 只放纯费用信息
|
||||
|
||||
✅ 放H列：
|
||||
- 租金标准+月租金（行内括号写法：如"年191,990元（月租≈15,999元）"）+每期合计
|
||||
- 物业费标准+月物业费
|
||||
- 付款推算（逐期展开：区间+租金+物业=合计+付款期限+❗标注）
|
||||
- 履约保证金/押金
|
||||
- 供电增容费用
|
||||
- 水电费标准（单价）
|
||||
- 免费停车位（权益性质但与费用相关）
|
||||
|
||||
### 付款推算效率规则（2026-07-03）
|
||||
付款推算直接从汇总表已有数据推导：
|
||||
- G列 → 合同起止日期、免租期
|
||||
- H列 → 租金/期、物业费/月、支付方式（半年/季度/年）、提前天数
|
||||
|
||||
无需每次回OCR原文。仅当数据存疑（如附件分期与正文不一致）时才回md核实。
|
||||
|
||||
❌ 不放H列：
|
||||
- 违约金（属合同权利义务安排→归I列）
|
||||
- 逾期付款违约金
|
||||
- 擅自转租违约金
|
||||
- 水电逾期违约金
|
||||
- 单方解除违约金
|
||||
|
||||
## I列（核心内容）—— 客观陈述合同约定的权利义务安排
|
||||
|
||||
包含：
|
||||
- 用途限制、转租条件、装修改造
|
||||
- 非竞争条款、出租方变更、抵押限制
|
||||
- 解除权机制（通知期+违约金+结算方式）
|
||||
- 各类违约金条款（从H列移入）
|
||||
- 不可抗力、续租、优先权
|
||||
- 安全责任、消防义务
|
||||
- 管辖、通知方式
|
||||
|
||||
## K列（法律风险）—— 聚焦风险，不列有利条款
|
||||
|
||||
结构：
|
||||
1. 【整体评价·站承租方立场】一段话概述
|
||||
2. 〇 需注意（逐条列风险点，标条款号）
|
||||
3. ◎ 提前退租法律后果分析
|
||||
4. 【续签建议】（改进建议）
|
||||
|
||||
### 提前退租分析框架
|
||||
|
||||
**核心原则：有约定写约定，无约定写法律规定——都要有依据，不做无锚点推测。**
|
||||
|
||||
#### 情形一：合同有明确约定
|
||||
直接写约定内容，不做额外或然推测。
|
||||
|
||||
示例（凤凰文化）：
|
||||
> ① 单方解除（第十条第2款）：提前60日书面通知+承担初年年租金20%违约金（约16,411元）+租赁租金及其他费用结算至合同解除日。约定明确，退租成本可控。
|
||||
|
||||
❌ 不写："甲方可能主张实际损失""建议协商规避""不确定责任"
|
||||
|
||||
#### 情形二：合同无明确约定
|
||||
写法律规定的三层分析：
|
||||
1. 法定解除权（民法典563条+租赁特有法定解除）
|
||||
2. 无法定事由=违约（民法典584条：赔偿可预见损失）
|
||||
3. 损失具体构成（空置期3-6个月/押金/预付租金）
|
||||
|
||||
### 不总结"对乙方有利条款"
|
||||
|
||||
Maggie确认：不总结对客户有利的条款，对客户实际意义不大。
|
||||
- K列数据行不写
|
||||
- 整体段不写
|
||||
- 续签建议也不写"建议保留"
|
||||
@@ -0,0 +1,585 @@
|
||||
# 南通汇总表各列规则（Maggie 2026-07-01 校准版）
|
||||
|
||||
优先级最高——与 SKILL.md 冲突时以本文件为准。
|
||||
|
||||
## 格式参照基准（Maggie 0703 指令）
|
||||
|
||||
**跃龙路校区为输出格式唯一参照**（"输出格式参照跃龙路，别自己创设"）。具体：
|
||||
- D列：`甲方：XX\n乙方：XX`（简洁，不加括号说明"出租方""承租方"）
|
||||
- E列：地址+用途（`用途：办公`单独一行）
|
||||
- H列付款推算：用`┃`分隔金额和付款期限（`170,000元 ┃ 2026.9.20前`）
|
||||
- H列物业费：必须逐期列出每期金额+付款截止日期，不得写"按年预收类推"
|
||||
- K列标题：`【整体评价·站承租方（乙方）立场】`
|
||||
- K列风险点标题：`〇 需注意`（非"【需注意的风险点】"）
|
||||
- 整体段：`【其他法律关注点】`（非"【法律关注点】"）
|
||||
|
||||
## 🔴 输出格式铁律（Maggie 2026-07-03 龙信返工教训）
|
||||
|
||||
**跃龙路定稿是格式唯一参照物，不得自创格式。** 详见 `references/output-format-canonical-0703.md`。
|
||||
|
||||
新建校区前必须先 `read_file` 跃龙路汇总表各列，照抄格式框架。关键差异点：
|
||||
- K列标题：`【整体评价·站承租方（乙方）立场】` + `〇 需注意`（不是`【整体评价】`+`【需注意的风险点】🔴`）
|
||||
- K列风险编号：纯数字不加emoji（不用🔴🟡🟢）
|
||||
- H列付款推算：`金额 ┃ 付款期限`（┃分隔）
|
||||
- L列差异：`N.【标签】07模版：XX→本合同：XX`
|
||||
- 整体段：`【其他法律关注点】`（不是`【法律关注点】`）
|
||||
- D列：`甲方：XX\n乙方：XX`（简洁，不加"出租方""承租方"括号说明）
|
||||
- 物业行K列：直接"物业合同风险XX。关注点："开头（不用【整体评价·...】框架）
|
||||
|
||||
---
|
||||
|
||||
## H列：金额/费用
|
||||
|
||||
**原则**：只写乙方正常履约需要支付的确定费用。
|
||||
|
||||
- **写什么**：租金标准及总额、物业费、押金、付款推算（各期金额+付款截止日期）等
|
||||
- **不写什么**：违约金、滞纳金、银行账户信息、供电功率等
|
||||
- **判断标准**：这笔钱是乙方正常履约就要付的吗？是→写；是出了问题才产生的→不写
|
||||
- 上面的"写什么""不写什么"均为列举示例，不是穷举清单。按合同实际情况判断。
|
||||
|
||||
### ⚠️ H列混入违约金pitfall（小石桥0707教训）
|
||||
|
||||
物业合同的"逾期滞纳金X%/日"容易被误写入H列——因为它紧挨着物业费标准出现在同一条款中。**判断标准只看一件事：这笔钱是正常履约就要付的吗？** 逾期滞纳金=出了问题才产生=不写H列。应放K列作为风险项。
|
||||
|
||||
常见误入H列的项目（全部应删除）：
|
||||
- ❌ 逾期滞纳金/违约金（0.5%/日、0.1‰/日等）
|
||||
- ❌ 供电功率（不是费用）
|
||||
- ❌ 维修费承担方式（属权利义务分配→I列）
|
||||
- ❌ 押金扣除条件（属违约后果→K列）
|
||||
|
||||
### ⚠️ H列条款号引用必须核对附件实际编号（龙信0708教训）
|
||||
|
||||
附件一/附件三的条目编号不能凭记忆或推测，必须核对原文实际标号。典型错误：
|
||||
- 附件一结构为「1.租金 (1)标准 (2)支付期限 / 2.物业管理费 / 3.保证金 / 4.其他费用」
|
||||
- 错误：把"支付期限"引用为"附件一第2项"（第2项实际是物业管理费）
|
||||
- 正确：应引用为"附件一第1(2)项"
|
||||
|
||||
不同合同的附件结构可能不同（如临时合同无物业管理费项，编号直接跳到第4项）。**每份合同的附件引用必须独立核对该合同自己的编号结构。**
|
||||
|
||||
### H列月租换算格式（Maggie 0703 指令）
|
||||
|
||||
月租换算一律用**行内括号写法**，写在租金标准那行括号里，不单独另起行。
|
||||
- ✅ 正确：`年191,990元（月租≈15,999元）`
|
||||
- ❌ 错误：单独另起一行写"折合月租约15,999元"
|
||||
|
||||
### H列付款推算描述规则（通州金鹰0707教训）
|
||||
|
||||
**当合同有明确的付款日期表格时（如第三条租金表逐期列出付款日），H列付款推算的描述必须引用表格作为权威来源**，不得仅凭合同文本中的一般规则（如"每期结束前15天付下期"）来描述。
|
||||
|
||||
- ✅ 正确：`按合同第三条租金表约定的付款日期（各期起始前1个月）`
|
||||
- ❌ 错误：`每期结束前15天付下期（第三条第2款）`——如果表格实际约定的日期与"15天"不吻合
|
||||
|
||||
**如果文本规则与表格约定存在矛盾**（如文本说"15天前"，但表格显示各期均为"起始前1个月"），须：
|
||||
1. H列以表格日期为准（具体约定优先于一般规则）
|
||||
2. K列补充"付款规则内部矛盾"作为风险项——对方可能援引文本规则主张违约
|
||||
|
||||
**首期付款日特殊处理**：如合同表格有明确的首期付款日期（如"2025-03-20"），须同时标注文本规则和表格日期：`合同生效后10个工作日内（合同表格约定2025.3.20）`
|
||||
|
||||
### 🔴 H列条款来源归属精准规则（0709悦拾光教训）
|
||||
|
||||
H列每项数据后的条款引用必须覆盖**所有实际数据来源**，不能只写主条款号：
|
||||
- 若机制出自主条款（如3.3条描述"预充值电表由甲方代收"），但具体单价/代收主体出自附件（如交房确认书第4点写明"电费0.9元/度，星展代收"），则必须写"（3.3条+交房确认书第4点）"
|
||||
- 禁止简化为仅引主条款——Maggie质疑"总结的依据是哪个合同条款"时，引用不全=无法溯源=不合格
|
||||
- **自检方法**：H列每个带括号引用的数据项，逐一追问"这个数字/这个主体名字，在我引用的条款原文里能不能逐字找到？"——找不到就是漏了来源
|
||||
- 典型场景：水电费单价（主条款写机制+附件写单价）、物业费发票开具方（主条款约定付款+三方协议约定收款方）、保证金退还条件（合同正文+补充协议修改）
|
||||
|
||||
### H列四检（交付前必过——租赁行+物业行都要过）
|
||||
1. 每个金额都标注了条款号出处（且覆盖全部数据来源，见上条）
|
||||
2. 做了月租换算——行内括号写法（≈X元/月）
|
||||
3. 列出了各期具体付款日期
|
||||
4. 未付期次句首标了❗
|
||||
|
||||
### 🔴 H列付款推算必须对应正确费率期（世茂0708教训）
|
||||
|
||||
**递增租金合同中，每期推算必须使用该时段对应的费率，不能全部按第1费率计算。**
|
||||
|
||||
典型错误：合同有第1费率期（2025.12-2027.2）和第2费率期（2027.3-2029.2），第3/4期付款推算全部按第1费率算→少算了递增部分。
|
||||
|
||||
正确做法：
|
||||
1. 先确定每个付款周期的时间段
|
||||
2. 检查该时间段落入哪个费率期（可能跨越两个费率期）
|
||||
3. 跨费率的周期须分段计算：第1费率×N月 + 第2费率×M月
|
||||
4. 验算：用合同附件三载明的第2期总额反推第2费率含税金额
|
||||
|
||||
**附件三有明确载明总额的周期可直接用合同数字**（如"第二期保底租金...金额为人民币401,363.92元"），无需自行推算——反向用它来验证费率是否正确。
|
||||
|
||||
### 🔴 合同中"/"=不适用，不提及（世茂0708教训）
|
||||
|
||||
合同格式文件中留空或填"/"的条款（如"营业额提成：/%"、"促销服务费：/元/㎡"），意味着该项不适用于本合同。**全表各列均不应提及这些不适用条款**：
|
||||
- H列不写"营业额提成比例未填"
|
||||
- I列不写营业额提成取高机制
|
||||
- K列不写"提成比例未填存在争议风险"
|
||||
- L列不写"保底+提成取高"作为差异
|
||||
|
||||
判断标准：如果合同原文用"/"明确表示空白/不适用，就当它不存在。
|
||||
|
||||
**⚠️ 物业行H列同样必须做付款推算**（跃龙路0707审计发现遗漏）：
|
||||
- 物业管理费+公共能耗费=每期总额，按合同约定的结算周期（年/半年/季）逐期列出
|
||||
- 格式与租金推算一致：`❗第N期（起止日）：XX元 ┃ 付款期限YYYY.MM.DD`
|
||||
- 首期如早于合同起始日，注明"首期随签约支付"
|
||||
- 电费等按实结算的只写计费标准，不做推算
|
||||
- **总额必须反映实际合同期限**（含免租期内物业费），不能简单用"年费×整年数"。如合同期为5年4个月，总额=年费÷12×64个月（通州金鹰0707纠正：原写48000×5=240000，实际应为256000）
|
||||
- **末期不足半年/一年的按比例计算**，单独注明"末期N个月按比例"
|
||||
|
||||
### H列付款推算效率（Maggie 0703 确认）
|
||||
|
||||
付款推算可以直接从 G列（起止日期）+ H列已有数据（支付方式、租金标准、递增规则、物业费单价）推算，不需要每次回 md 原文重新读取。具体：
|
||||
1. 从G列取起止日期+免租期
|
||||
2. 从H列取租金/期、物业费/月、支付方式（半年/季/年）、提前天数
|
||||
3. 按周期切分区间 → 算出每期金额+付款截止日
|
||||
|
||||
只有遇到数据存疑（如附件分期跟正文对不上、免租分摊逻辑不清）才需要回 md 核实。
|
||||
|
||||
### 🔴 H列禁止"详见合同""同上"等空壳写法（世茂0708教训）
|
||||
|
||||
**每份合同的H列必须完整写明具体金额和付款推算，不得用"详见合同附件约定""同上"等模糊表述代替。**
|
||||
|
||||
物业合同尤其容易犯此错——因为金额较小、附件结构复杂、项目多，容易偷懒写"管理费详见附件"。但客户看汇总表就是不想翻原文，必须一目了然。
|
||||
|
||||
物业合同H列完整标准：
|
||||
- 履约保证金具体金额
|
||||
- 管理费：单价×面积=月费（不含税+税金+含税合计）
|
||||
- 装修押金+装修管理费（一次性）
|
||||
- 促销服务费（不适用则标"不适用(/)"）
|
||||
- 水电费计费标准
|
||||
- 支付方式+完整付款推算（按年/半年/季，逐期列出）
|
||||
- 合计总额
|
||||
|
||||
三层/扩租合同同理——即使条款结构相同，参数（面积、单价、周期）不同就必须独立写完整数字，不能"同上"。
|
||||
|
||||
---
|
||||
|
||||
## I列：核心内容
|
||||
|
||||
按固定类目逐项摘录合同原文，有就写没有就不写。格式统一为 `· [类目] 原文（条款号）`。
|
||||
## I列：核心内容
|
||||
|
||||
按固定类目逐项提炼合同核心事实，有就写没有就不写。
|
||||
|
||||
### 租赁合同（21个固定类目）
|
||||
用途/转租/装修改造/广告标识/非竞争/维修责任/保险要求/物业服务联动/配套设施/出租方变更/解除权机制/违约金机制/不可抗力/征收拆迁/房屋抵押查封/政策变化/到期处理/恢复原状/优先权/管辖/备案
|
||||
|
||||
### 物业合同（15个固定类目）
|
||||
物业服务内容/服务标准/公共能耗费/特约服务/共用设施管理/装修管理/安保措施/消防安全/保险要求/联动终止/违约责任/退出交接/免责条款/不可抗力/管辖
|
||||
|
||||
### 物业合同I列补充要点（0707审计发现遗漏）
|
||||
除15个固定类目外，以下条款如合同有约定也应在I列提及（属于权利义务分配的实质内容）：
|
||||
- **违约确认时限**：如物业合同约定"违约侵权须N日内书面告知，逾期视为放弃权利"→必须写（影响维权时效）
|
||||
- **不动产转让条款**：如约定"转让不影响合同继续履行"→写入[联动终止]类目
|
||||
- **服务标准引用**：如约定"参照《XX省物业服务N级标准》"→写入[服务标准]类目
|
||||
- **特约服务收费**：如约定"须事先公布收费标准，按实计付"→写入[特约服务]类目
|
||||
|
||||
### 格式规则
|
||||
- 格式：`· [类目] 关键事实（条款号）`
|
||||
- 一行一个类目，精简干练，只留核心事实+条款号
|
||||
- 有就写，没有就不写
|
||||
- 禁止冗余修饰语和重复描述——能用一句话说清的不用两句
|
||||
- 违约金属于权利义务安排，放I列（违约金机制）而不是H列
|
||||
- 同模板多合同时，后续行写"条款结构与XX一致。差异：·面积 ·租期 ·保证金"即可
|
||||
|
||||
### 精简标准（Maggie 0703确认）
|
||||
- ❌ "未经甲方书面同意，乙方对于承租房屋不得以任何形式转租、转让、转借、抵押或其他有损甲方利益的行为"
|
||||
- ✅ "未经书面同意不得转租/转让/转借/抵押（4.5条）"
|
||||
- 原则：摘录核心事实≠原文照抄。用最少的字传达最准确的信息。
|
||||
|
||||
### ⚠️ 格式陷阱（星月0706发现）
|
||||
- ❌ `【类目】内容（条款号）` —— 方括号用了中文书名号，早期校区残留
|
||||
- ❌ 详细展开式（每项一大段话，如"【用途】仅限办公（第二条第1款）；未经甲方书面同意不得改变用途（第二条第2款）\n【转租】允许部分或全部转租……"）——早期跃龙路/通州金鹰残留
|
||||
- ✅ `· [类目] 内容（条款号）` —— 半角方括号+圆点前缀，一行一类目
|
||||
- 重审旧表时首先检查格式是否符合规范，不符合的一并改正
|
||||
|
||||
### I列审计/改写流程（0707跃龙路+通州金鹰+小石桥实践）
|
||||
|
||||
当被要求检查已有汇总表的I列时：
|
||||
1. **先对照21/15类目清单做覆盖检查**——逐个类目看是否已在I列中出现
|
||||
2. **判断"合同无此条款"vs"合同有但I列遗漏"**——回到合同md原文确认
|
||||
3. **如果格式不是`· [类目]`式→整列改写**，不是在旧格式末尾追加。全部改为精简类目式一次到位
|
||||
4. **改写后覆盖率自检**：租赁≥15/21，物业≥10/15（合同无相关条款的不计入分母）
|
||||
5. **删除非核心条款**：合同份数、现场负责人、反舞弊等（见下方"常见应删除项"）
|
||||
|
||||
### 汇总表审计完整流程（Maggie 0707 指令模式）
|
||||
|
||||
当Maggie说"检查下XX校区的汇总表"时，执行以下标准审计：
|
||||
|
||||
### 🔴 I列统筹提炼规则（2026-07-13 金飞达纠正）
|
||||
|
||||
**若同一租赁物没有单独物业合同，而物业管理/公共能耗/消防/装修管理/共用设施/安保等内容已经写进租赁合同正文，那么I列不能只按“租赁合同21类”机械提取。** 必须把该租赁物对应文件中的：
|
||||
- 租赁合同21类要点
|
||||
- 物业合同15类要点（凡已内嵌在租赁合同正文、附件、补充协议里的）
|
||||
|
||||
**一起统筹提炼**。
|
||||
|
||||
也就是说，判断标准不是“有没有单独物业合同文件”，而是：
|
||||
> **该租赁物的全部核心权利义务里，是否已经把物业类安排写进租赁合同。**
|
||||
|
||||
典型应一并纳入I列的内嵌物业要素：
|
||||
- 物业运营管理费/物业费的构成与支付
|
||||
- 公共能耗费、中央空调费、电梯电费、水电费调整机制
|
||||
- 共用设施管理、公共区域布局调整、营业时间管理
|
||||
- 装修管理、装修押金、装修管理费、装修验收
|
||||
- 安保措施、经营管理公约、消防责任书
|
||||
- 退出交接、物业随租赁联动终止
|
||||
- 免责条款中与水电中断、设施故障、公共区域管理相关内容
|
||||
|
||||
**金飞达案例（2026-07-13）**：没有单独物业合同，但主租赁合同/扩租合同/499合同中已写入物业运营管理费、中央空调费、公共区域管理、经营管理公约、消防责任书、电梯电费、停车位等内容。此时I列应按“租赁+物业混合文本”统筹提炼，而不是误判为“缺物业合同所以只做21类”。
|
||||
|
||||
**Step 1: 拉取文件**
|
||||
- docker cp 从Nextcloud取xlsx + 合同md文件到/tmp/
|
||||
|
||||
**Step 2: H列审计**
|
||||
- 检查是否混入非费用项（违约金/滞纳金/供电功率→应删除）
|
||||
- 检查物业费是否有逐期付款推算（没有→补充）
|
||||
- 检查租金付款推算日期是否与合同表格吻合（不吻合→修正描述+K列补充矛盾）
|
||||
- 检查总额计算是否反映实际合同期限（如5年4个月≠5年）
|
||||
|
||||
**Step 3: I列审计**
|
||||
- 对照21/15类目清单做覆盖率检查
|
||||
- 判断格式是否为精简类目式（不是→整列改写）
|
||||
- 补充遗漏类目 + 删除非核心条款
|
||||
|
||||
**Step 4: K列审计**
|
||||
- 逐项回到合同原文核验每条风险是否有据
|
||||
- 检查是否遗漏明显风险（签约主体错配、合同内部矛盾、支付方向瑕疵等）
|
||||
- 验证提前退租分析的金额计算
|
||||
|
||||
**Step 5: 上传**
|
||||
- docker cp回Nextcloud + chown + files:scan
|
||||
|
||||
**报告格式**：按校区输出结构化检查报告，列明"问题→处理"表格。
|
||||
|
||||
### 非固定类目内容的处理（星月0706实践）
|
||||
|
||||
旧表中可能存在不属于21/15个固定类目的条目（如"保证金退还""发票""工商迁入""安全责任""甲方维修"等）。修订时处理原则：
|
||||
- **可归入固定类目的→合并**：甲方维修→并入[维修责任]；保证金退还条件→并入[恢复原状]；甲方违约→并入[解除权机制]
|
||||
- **纯信息性/不影响权利义务分配的→删除**：发票开具要求、工商迁入时限、安全第一责任人声明等
|
||||
- **判断标准**：该信息是否直接影响乙方的权利行使或义务负担？是→找最近的固定类目归入；否→不写
|
||||
- **格式统一**：旧表若用`【类目】`格式，修订时一律改为`· [类目]`
|
||||
|
||||
#### 常见应删除项（小石桥0707补充）
|
||||
|
||||
以下内容不属于核心权利义务，不应出现在I列：
|
||||
- ❌ 合同份数（"一式四份各执两份"）
|
||||
- ❌ 现场负责人姓名/电话
|
||||
- ❌ 反舞弊/举报条款（程序性合规条款）
|
||||
- ❌ 开票信息（户名/税号/账号）
|
||||
- ❌ 签字盖章生效条款
|
||||
- ❌ 补充协议效力条款
|
||||
|
||||
这些属于合同程序性/管理性条款，不影响乙方实质权利义务的行使或负担。
|
||||
|
||||
### 通读强制机制（悦拾光0703教训）
|
||||
Step2动作A法律审查必须用read_file从第1行读到最后一行（分批500行/次），不得用grep抽查代替通读。
|
||||
自检标准：I列类目覆盖数≥阈值（租赁15/21，物业10/15）。
|
||||
建表后必跑 `scripts/i-column-coverage-check.py` 验证覆盖，不够就核查确认。
|
||||
> **同模板简写行的⚠️警告是正常的**（桃坞路0703确认）：使用"条款结构与XX一致。差异：…"简写的行（如扩租行）会因类目标记少而触发低覆盖警告——这不是遗漏，是规则允许的简写。只需确认首份详细行已达到21/21或15/15即可。
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## J列：当前状态
|
||||
|
||||
按实际日期判断：
|
||||
- 合同期限已过 → "已到期"
|
||||
- 未到期且正在履行 → "履行中"
|
||||
- 合同尚未开始（起租日在未来）→ "未开始履行"
|
||||
|
||||
不能不看日期直接写"履行中"。
|
||||
|
||||
---
|
||||
|
||||
## K列：法律风险（站乙方立场）
|
||||
|
||||
### 写什么
|
||||
- 整体评价（简要概括合同对乙方保护程度）
|
||||
- 需注意的风险点（标条款号，说清楚对乙方的实际影响）
|
||||
- 提前退租法律后果分析
|
||||
|
||||
### 不写什么
|
||||
- 对乙方有利的条款（对客户无实际意义）
|
||||
- 续约建议（只放第三部分整体段）
|
||||
- 引用模版做对比（那是L列的事）
|
||||
|
||||
### K列证据纪律（Maggie 0703 纠正）
|
||||
|
||||
K列所有判断必须有合同文本直接支撑，不得超出文本能证明的范围做推论。
|
||||
|
||||
### K列"用途与实际经营不一致"风险模式（龙信0708）
|
||||
|
||||
当合同约定的租赁用途很具体且看上去可能与实际经营不一致时（如约定"新东方学习机"但校区实际做教育培训），K列应提示此风险：
|
||||
- 引用条款链：用途限定条款（如第二条）+ 禁止改变用途条款（如4.8条）+ 甲方解除条款（如6.2(4)"擅自改变用途"）
|
||||
- 建议：确认甲方是否知情并认可实际经营内容
|
||||
- 注意：此判断属于**K列**（风险评价），不属于I列（I列只客观摘录约定用途是什么）
|
||||
|
||||
### K列"合同内部矛盾"风险模式（0707实践总结）
|
||||
|
||||
合同内部条款之间的矛盾是独立的K列风险项。常见模式：
|
||||
1. **付款规则矛盾**：文本一般规则 vs 表格具体约定（如"15天前"vs表格"1个月前"）→对方可择利援引
|
||||
2. **数值矛盾**：正文 vs 附加条款（如供电"120千瓦"vs"65千瓦"）→补充条款效力条款决定优先
|
||||
3. **甲乙方方向矛盾**：条文写"乙方支付至甲方账户"但收款账户是乙方自己的→模版套用瑕疵
|
||||
4. **签约主体矛盾**：合同载明乙方名称与实际盖章公章不一致→可能影响效力认定
|
||||
|
||||
写法统一为：`N. XX条款矛盾/不一致（第X条）：条文A写"..."，但条文B/表格/盖章为"..."。[实务判断]。`
|
||||
|
||||
**典型错误**：
|
||||
- 合同中物业方联系人与出租方为同一人→直接写"实为关联方""X控制的Y公司"
|
||||
- 从联系人身份推断股东/法定代表人/实际控制人身份
|
||||
|
||||
**正确写法**：
|
||||
- "出租方（范存益）同时为物业方（东德物业）的联系人，电话地址一致，两者**可能**存在关联关系，物业服务质量纠纷时需注意利益一致性。"
|
||||
- Maggie 0703 审核确认此措辞：提示了关联可能性，但不做无依据的确定性推断
|
||||
|
||||
规则：
|
||||
- "联系人"≠ 股东/法定代表人/实际控制人，不能从联系人身份推断控制关系
|
||||
- 要证明关联关系需要工商信息，合同文本只能支撑"可能存在关联"
|
||||
- 用语梯度：合同直接写明→"为"；同名同电话同地址→"可能存在关联关系"；纯推测→不写
|
||||
- 同样适用于其他推断（如"实际经营培训"——合同写"办公"就只能说"需确认是否一致"）
|
||||
|
||||
### 提前退租分析规则
|
||||
- 合同有明确约定的（通知期+违约金+结算方式），**写约定内容+展开分析"其他损失"**。
|
||||
- 合同没有明确约定的，回到法律规定做三层分析：
|
||||
①有无法定解除权（民法典563条）
|
||||
→ ②无法定事由则单方退租=违约（584条赔偿可预见损失）
|
||||
→ ③损失构成
|
||||
- 两种情况都要有依据，不写"甲方可能会主张""建议协商规避"这类没有锚点的推测。
|
||||
|
||||
#### 写作风格（Maggie 0708 纠正）
|
||||
- **语言简单明了，只给条款号，不引用合同原文全文**
|
||||
- ❌ 错误：引用完整合同原文再做分析（"第五条3款：'租赁期间，乙方如需提前解租的，应当提前3个月书面告知甲方。在此情况下……'"）
|
||||
- ✅ 正确：直接写结论+条款号（"规范提前解约（第五条3款）：提前3个月书面告知 + 没收保证金56,667元 + 30%违约金102,000元，合计约158,667元。"）
|
||||
- 原则：读者是律师，不需要被教条文写了什么，只需要知道后果是什么+出处在哪
|
||||
|
||||
#### 区分"规范退出"与"擅自退租"（龙信0708实践）
|
||||
同一份合同往往有两条退出路径，法律后果不同，必须分别列明：
|
||||
- **规范提前解约条款**（如5.3条）：乙方主动通知+约定违约金→后果确定，有上限
|
||||
- **擅自退租/违约解除条款**（如4.15条）：未经同意中途退出→后果更重，可能无上限（"不足弥补损失另行赔偿"）
|
||||
两条不能混写。如果只写5.3条却把4.15条"不足弥补另赔""退还已预付未使用"的后果也算进去，属于张冠李戴。
|
||||
|
||||
**写法示例（龙信0708确认格式）**：
|
||||
```
|
||||
【提前退租法律后果】
|
||||
一、规范提前解约（第五条3款）：提前3个月书面告知 + 没收保证金56,667元 + 30%违约金102,000元，合计约158,667元。
|
||||
二、擅自退租（第四条15款）：甲方可解除 + 没收保证金 + 30%违约金 + 不足弥补损失另行赔偿（无上限）+ 退还已预付未使用租金。
|
||||
注：5.3条为规范退出，后果封顶；4.15条为擅自退租，后果更重且无上限。
|
||||
```
|
||||
|
||||
#### "其他损失"必须展开分析（Maggie 0706 纠正）
|
||||
|
||||
合同写"给守约方造成其他损失，违约方还应进行相应赔偿"或"违约金不足弥补损失的据实赔偿"时，**不能只写违约金数字就停**，必须展开分析甲方可主张的损失范围：
|
||||
|
||||
**标准分析结构**：
|
||||
1. 合同约定路径（正常退出）：通知期+同意+违约金
|
||||
2. 甲方可主张的其他损失（逐项列举+估算金额）：
|
||||
- 空置期租金损失（重新招租合理期间，通常3-6个月）
|
||||
- 重新招商费用（中介佣金、广告支出）
|
||||
- 免租期租金追溯（如合同有此条款）
|
||||
- 恢复原状/装修修复费用
|
||||
- 逾期搬离违约金（如合同约定日租金倍数）
|
||||
3. 最大风险敞口估算（各项相加=总数字）
|
||||
4. 擅自退出后果（未获同意时的路径：没收保证金+据实索赔）
|
||||
|
||||
**必须有具体金额**——用合同约定的租金标准×期限算出每项的元数。"约XX元"即可，不求精确到分。
|
||||
|
||||
#### 同模板多合同须分别分析（Maggie 0706 指出）
|
||||
|
||||
同一甲方制式合同、条款结构一致但参数不同（免租期、租金、面积）时，**提前退租法律后果必须逐份单独计算**，不能写"同上"。原因：
|
||||
- 免租期不同→追溯金额可能翻倍（如90天 vs 6个月）
|
||||
- 租金基数不同→赔偿金和空置期损失金额不同
|
||||
- 递增比例不同→后期退出的风险敞口差异更大
|
||||
|
||||
写法：1楼K列单独列出完整的提前退租分析（含数字），末尾加"⚠️与2楼对比"说明差异原因。
|
||||
|
||||
---
|
||||
|
||||
## L列：与07标准模版差异
|
||||
|
||||
- **原则**：纯客观描述文本差异，不做风险判断
|
||||
- **格式**：模版写什么→本合同写什么→差异在哪
|
||||
- **禁止出现的词**：风险、建议、不利、详见
|
||||
- **合同原文含禁用词的处理（桃坞路0703教训）**：合同原文本身可能使用"风险"等禁用词（如"经营风险由乙方承担"）。L列不可直接引用含禁用词的原文，需改写为客观事实描述。
|
||||
- ❌ `证照风险全归乙方`（"风险"触发kl-separation-check）
|
||||
- ✅ `能否获得许可属乙方经营事项，甲方不承担`（客观描述分配结果，不含禁用词）
|
||||
- 原则：用"甲方不承担/由乙方自行解决/乙方经营事项"等客观描述替代含"风险"的原文引用
|
||||
- **来源**：必须从子任务生成的比对文件里逐条摘取
|
||||
- **适用范围（Maggie 0703 纠正）**：**所有租赁合同都必须与07标准模版做对比，不论是否为新东方制式。** 跃龙路（甲方制式）做了55条差异，龙信（甲方制式）做了50条——正因为不是新东方制式，差异才更大、客户才更需要知道缺少了哪些保护。
|
||||
- **非07制式合同**：L列写明"本合同为XX制式（非新东方制式），与07标准模版差异极大。逐条对比如下："，然后**全部差异逐条列出**。仅物业合同/补充协议可以不做07比对。
|
||||
|
||||
### 🔴 L列差异数量诚实原则（龙信0708教训）
|
||||
|
||||
**写了"N项差异"就必须列出全部N项，不能只列"主要差异"十几项。**
|
||||
|
||||
- ❌ "与07标准模版差异极大（40项差异）。主要差异：1.…2.…（只列18项）"——说40项只列18项=不诚实
|
||||
- ✅ "与07标准模版差异极大。逐条对比如下：1.…2.…（全部40项逐条列出）"
|
||||
|
||||
原因：Maggie会数。写了总数就要能对上。要么全部列出，要么不写总数——不允许"只列主要差异"这种偷工减料。
|
||||
|
||||
逐条列出的格式：按07模版条款顺序，分章节标题分组：
|
||||
```
|
||||
【第一条·租赁标的】
|
||||
1. 产权查验：07→XXX；本合同→XXX
|
||||
2. 供电功率：07→XXX；本合同→无此条款
|
||||
【第二条·用途与转租】
|
||||
3. ...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 第三部分"整体风险分析与建议"结构
|
||||
|
||||
按以下顺序排列（Maggie 0701 确认）：
|
||||
1. **【整体评价】** 几句话概括
|
||||
2. **【法律关注点】** 逐条列风险（先于退租分析）
|
||||
3. **【提前退租法律后果】** 按合同约定写
|
||||
4. **【续签建议】** 具体改进建议（只放这里，不放K列）
|
||||
|
||||
---
|
||||
|
||||
## 多合同校区规则
|
||||
|
||||
### 核心原则：每份合同独占一行（Maggie 0703 明确）
|
||||
|
||||
**每份独立的合同文件必须单独一行，不得合并。** 租赁合同、变更协议、物业合同——各自提取、各自审阅、各自一行。
|
||||
|
||||
- Maggie原话（0703）："3份合同分别提取，分别审阅，做成三行，不要混在一起写"
|
||||
- ❌ 错误做法：把租赁合同和主体变更协议合成一行写（即使两者关联密切）
|
||||
- ✅ 正确做法：租赁合同一行 + 变更协议一行 + 物业合同一行，各有独立的板块标题和表头
|
||||
|
||||
### 板块结构
|
||||
|
||||
每种合同类型独立一个板块（"一、房屋租赁合同""二、主体变更协议""三、物业管理服务合同"），每个板块有自己的段标题行+表头行+数据行。
|
||||
|
||||
### 其他排序规则
|
||||
|
||||
- **排序**：按签约时间排序，先签的在前
|
||||
- **同制式合同多份**：详细的K列、L列、I列内容放最早签约的那份行里，后续行写"同上+数据差异"
|
||||
- **多租赁物**：先按租赁物分类，再按时间排列
|
||||
- **板块划分听Maggie指令**：Maggie说"按租赁物分类"→板块标题=租赁物描述；说"按原租赁和扩租分类"→板块标题=业务关系。不自作主张选分类方式。
|
||||
|
||||
### 多租赁物表结构（Maggie指示"按租赁物分类"时）
|
||||
|
||||
板块划分从"按合同类型"变为"按租赁物"。每个租赁物独立板块，内部租赁在前物业在后。
|
||||
|
||||
**世茂校区实例（2026-07-03验证通过）**：
|
||||
- 一、二层商铺（商铺编号XXX，968.28㎡）→ 租赁合同 + 物业合同
|
||||
- 二、三层3023号商铺（347.2㎡）→ 租赁合同 + 物业合同
|
||||
- 三、校区整体风险分析与建议
|
||||
|
||||
**桃坞路校区实例（2026-07-03验证通过，按租赁物分类+时间排序）**：
|
||||
- 一、桃坞服饰城中区201室、中区202室、C区部分房屋（889㎡）→ 租赁合同 + 物业合同
|
||||
- 二、桃坞服饰城C区二层C-818室部分（80.21㎡）→ 租赁合同 + 物业合同
|
||||
- 三、校区整体风险分析与建议
|
||||
> 特征：同一出租方（国企制式）、同一模板，扩租行使用"条款结构与XX一致。差异：…"简写。
|
||||
> KL分离检查：扩租行K列只补充额外风险，不重复原租赁K列已写内容。
|
||||
|
||||
### 按业务关系分类（Maggie指示"按原租赁/扩租分类"时）
|
||||
|
||||
板块划分从"物理租赁物"变为"业务关系"。
|
||||
|
||||
**悦拾光校区实例（2026-07-03验证通过）**：
|
||||
- 一、原租赁（C204、C205、C206）→ 租赁合同 + 能耗费三方协议
|
||||
- 二、扩租（C213、C214、C217、C218、C219、C220）→ 租赁合同 + 能耗费三方协议
|
||||
- 三、校区整体风险分析与建议
|
||||
|
||||
### 辅助协议行处理（能耗费/收款变更/补充协议等）
|
||||
|
||||
非租赁、非物业的辅助协议（如公共能耗费三方协议、收款账户变更协议）：
|
||||
- 独立一行，不与主合同合并
|
||||
- K列：简洁写法（"收款账户变更协议，风险低。关注点：N."），不用【整体评价·...】框架
|
||||
- L列：`XX协议，无对应07标准模版。`（不做07比对）
|
||||
- I列：协议性质+核心约定（如甲方单方解除权等）
|
||||
- H列：写实质费用变更内容（如收款账户信息）
|
||||
|
||||
---
|
||||
|
||||
## 文件纪律（Maggie 0703 纠正）
|
||||
|
||||
### OCR文本保存规则（Maggie 0703 指令）
|
||||
|
||||
**提取并校对好的OCR文本（.md文件）必须保存在同一文件夹下**——即与源PDF同目录。
|
||||
|
||||
- 原租赁合同.pdf → 同目录下保存 原租赁合同_全文.md
|
||||
- 扩租/扩租合同.pdf → 扩租/ 目录下保存 扩租合同_全文.md
|
||||
- 上传到Nextcloud时用 `docker cp` + `files:scan`，与汇总表一起保存
|
||||
|
||||
这些.md文件是审查的工作底稿，客户可对照PDF原件核对。
|
||||
|
||||
### 旧版保留规则
|
||||
|
||||
**旧版汇总表不得擅自删除/覆盖。** 新版文件命名带新日期（如 `-MJ-20260703.xlsx`），与旧版共存。
|
||||
|
||||
规则：
|
||||
- 生成新汇总表时，保留所有旧版文件原位不动
|
||||
- 不需要用户明确指示"保留旧表"——默认就是保留
|
||||
- 用户没有说删除的东西，一律不删
|
||||
- Maggie原话："没有让做的事情不要自己擅自进行"
|
||||
|
||||
这条规则同样适用于：md文件、pdf原件、任何已存在于Nextcloud的文件。只有cleanup cron和Doro明确说"pass"才允许删除。
|
||||
|
||||
---
|
||||
|
||||
## 不创设原则（Maggie 2026-07-03 明确）
|
||||
|
||||
严格按 workflow 和既定规则执行：
|
||||
- 不发明新规则、不加额外步骤、不自创标准
|
||||
- 不擅自做未被指示的操作（如删旧表、改文件名规则、自创格式约定等）
|
||||
- Maggie原话："严格按照Workflow和既定规则，不要创设哈"
|
||||
- Maggie原话："没有让做的事情不要自己擅自进行"
|
||||
|
||||
这包括但不限于：
|
||||
- 不自行决定清理/删除/覆盖旧文件
|
||||
- 不自行增加workflow中没有的检查步骤
|
||||
- 不基于推断创设新规则（如从联系人推断控制关系）
|
||||
- 不在K列创设合同文本不支撑的判断
|
||||
|
||||
---
|
||||
|
||||
## OCR铁律（凤凰文化0701 + 悦拾光0703 + 桃坞路0713教训）
|
||||
|
||||
**所有OCR文本必须全文vision逐页校对，不只是"关键数据"。**
|
||||
|
||||
### 🔴 全文准确性要求（桃坞路0713·Maggie纠正）
|
||||
|
||||
**Maggie原话**：「需要核实的不只是核心数据，所有的文字都要准确。比如租赁合同第二条的租赁用途是商业，不是教育培训，你这次有看到么？」
|
||||
|
||||
**问题模式**：只核对数字（金额、面积、日期）正确就认为"md准确度没问题"，忽略文字内容。OCR会把关键文字变乱码而数字正确。
|
||||
|
||||
**典型失败案例**：
|
||||
- 租赁用途"商业"→`Bik`（乱码），数字全对但用途丢失
|
||||
- 大写金额全错：`会 万武任 硅 佰 建 拾 制 元 伍 角` →实为"叁万贰仟肆佰肆拾捌元伍角"
|
||||
- "崇川区"→"喧川区"，"中区201室"→"服4区201"
|
||||
- 物业费空白→OCR瞎猜成"泣_/元/嘿月"
|
||||
|
||||
**正确做法**：逐页vision全文识别→重写md为完整准确版本。每页都要过vision，包括"标准条款"页面。详见`ocr-and-documents` skill的"Vision Full-Text Extraction Workflow"节。
|
||||
|
||||
**大批量校区（如金飞达88页）**：分session处理（每session 20-30页），图片预先全部转好（`pdftoppm -png -r 200`），新session无缝衔接。避免context degradation导致后半段质量下降。
|
||||
|
||||
不是"看哪里乱就修哪里"——用脚本扫全文自动标红，强制逐条过一遍。
|
||||
跳过任何一处乱码就可能整段关键条款丢失（凤凰文化10.2：整段"初年年租金20%违约金"丢失→审查结论反转→返工）。
|
||||
|
||||
### 🔴 grep抽查 ≠ 逐字通读（悦拾光0703教训·Maggie纠正）
|
||||
|
||||
**Maggie原话**：「不只是关键条款，逐字逐句都要核准校对」「准确严谨是一切工作的基础」
|
||||
|
||||
**栽点**：OCR断行严重时，一个完整句子散落在3-5行，grep只能命中片段无法还原完整语义。
|
||||
|
||||
**典型失败案例**：
|
||||
- 30.3条"每逾期一日甲方有权按拖\n欠金额【3】%\n的标准...逾期支付\n超过【7】日的,甲方有权停止...水、\n电、燃气供应"→grep"停水"零结果→错写"逾期30日停水电"（30日是解除门槛不是停供门槛）
|
||||
- 第36条"可向该房屋所在地人民法院\n起\n诉"→grep"管辖"零结果→错写"合同未明确约定管辖法院"
|
||||
|
||||
**铁律**：
|
||||
1. **必须线性逐页read_file全文**——不能用grep替代通读，grep只是辅助定位
|
||||
2. **grep无结果 ≠ 合同无约定**——可能是OCR用了不同字词（"法院"不含"管辖"、"停止供应"不含"停水"）
|
||||
3. **关键条款必须两份合同交叉核实**——同模版的原租赁和扩租OCR质量不同，一份断行严重的另一份可能完整
|
||||
4. **争议解决/管辖条款通常在合同末尾（第35-37条区域）**——必须显式确认到具体法院，不可因grep零结果就写"未约定"
|
||||
5. **违约金条款常含多个阈值**（逾期N日=停供、逾期M日=解除、逾期K日=违约金起算）——必须完整读完整条，区分不同阈值对应的不同后果
|
||||
|
||||
---
|
||||
|
||||
## 执行诚实性纪律（龙信0703教训）
|
||||
|
||||
见 `references/execution-honesty-0703.md`。核心：
|
||||
|
||||
- "看起来差不多/跟上个校区一样/只有2个月风险有限"不是跳过审查的理由
|
||||
- 每份合同必须独立做八维框架审查（①主体 ②标的 ③期限 ④租金 ⑤违约 ⑥维修 ⑦转租 ⑧争议），不能从另一份合同复制结论
|
||||
- L列模版比对适用于**所有租赁合同**，不分制式。仅物业合同/补充协议可以不比对
|
||||
- 速度不是质量的对手——宁可告知"工作量大需要更多时间"，不偷偷跳过假装做完
|
||||
@@ -0,0 +1,50 @@
|
||||
# Excel汇总表12列结构说明
|
||||
|
||||
> ✅ **权威口径（Maggie 2026-06-23 裁定）：校区详情 sheet = 12 列，含独立 L 列「与标准模版差异」。** 模版差异（动作B，回 07 原件比对）放 L 列，法律风险（动作A）放 K 列，两者**物理分列**，绝不并入。本文件与 SKILL.md Step3「12列标准结构」、第363行、`independent-legal-review-framework.md`「分列」为同一口径，互为引用。
|
||||
> 此前一度出现的「11 列、模版差异并入 K 列」旧表述已全部作废（SKILL.md 正文两处、原 Pitfall 19 已于 2026-06-23 同步更正）。
|
||||
|
||||
## 列定义
|
||||
|
||||
| 列 | 字段 | 宽度 | 内容说明 |
|
||||
|---|---|---|---|
|
||||
| A | 序号 | 5 | 校区内连续编号 |
|
||||
| B | 文件名称 | 24 | 完整PDF文件名 |
|
||||
| C | 合同类型 | 14 | 如"房屋租赁合同（主合同）""补充协议（租金减免）""物业管理协议" |
|
||||
| D | 合同当事人 | 26 | 甲方/乙方/丙方全称，换行分隔 |
|
||||
| E | 租赁标的/服务范围 | 22 | 具体房间号或服务范围 |
|
||||
| F | 面积(㎡) | 10 | 数值+说明（如"622\n（建筑面积）"） |
|
||||
| G | 合同期限 | 20 | 总期限+起止日期+免租期 |
|
||||
| H | 金额/费用 | 20 | 租金/物业费/押金明细 |
|
||||
| I | 核心内容 | 40 | 关键商业和法律条款摘要（不放基础设施规格） |
|
||||
| J | 当前状态 | 10 | "履行中""已履行""已执行" |
|
||||
| K | 风险点/备注 | 40 | 风险提示 + 【合同变更与提前解除】小节 |
|
||||
| L | 与标准模版差异 | 40 | 租赁合同对比结果；物业/补充协议标注"无对应标准模版" |
|
||||
|
||||
## 格式规范
|
||||
|
||||
### 字体
|
||||
- 标题行(Row 1): 微软雅黑 14pt 加粗，居中
|
||||
- 基本信息行(Row 2): 微软雅黑 10pt，左对齐
|
||||
- 分类标题: 微软雅黑 11pt 加粗，左对齐，底色D6E4F0
|
||||
- 列标题: 微软雅黑 10pt 加粗，居中，底色E2EFDA
|
||||
- 数据行: 微软雅黑 10pt，左对齐上对齐，自动换行
|
||||
|
||||
### 行高估算
|
||||
- 标题/分类标题: 30pt
|
||||
- 列标题: 30pt
|
||||
- 数据行: 根据内容，K/L列内容多的需要300-400pt
|
||||
- 风险分析区: 600-750pt（合并单元格必须手动设高度）
|
||||
|
||||
### K列【合同变更与提前解除】标准内容
|
||||
1. 提前解约通知期和违约金
|
||||
2. 押金退还条件
|
||||
3. 甲方终止时的赔偿义务
|
||||
4. 免责解除通道
|
||||
5. 部分退租先例（如有）
|
||||
6. 合同变更方式
|
||||
|
||||
### L列差异标注分级
|
||||
- ⚠️ 开头 = 多处重大偏离
|
||||
- ✅ 开头 = 高度一致
|
||||
- 编号列举具体差异点
|
||||
- 物业/补充协议: "物业服务协议，无对应标准模版" 或 "补充协议，非模版对比范围"
|
||||
@@ -0,0 +1,72 @@
|
||||
# 统一社会信用代码 OCR 核实配方
|
||||
|
||||
## 适用场景
|
||||
合同首页甲乙方统一社会信用代码 OCR 乱码（如 "MA INAEBX26" 应为 "MA1NAEBX26"），需要核实正确值。
|
||||
|
||||
## 核实步骤
|
||||
|
||||
### 1. tesseract 重读首页
|
||||
```bash
|
||||
# 渲染首页 200 DPI
|
||||
python3 -c "
|
||||
import fitz
|
||||
doc = fitz.open('合同.pdf')
|
||||
page = doc[0]
|
||||
mat = fitz.Matrix(200/72, 200/72)
|
||||
pix = page.get_pixmap(matrix=mat)
|
||||
pix.save('page1.png')
|
||||
"
|
||||
|
||||
# 裁剪公司名+信用代码区域（通常页面 15-30% 高度）
|
||||
python3 -c "
|
||||
from PIL import Image
|
||||
img = Image.open('page1.png')
|
||||
w, h = img.size
|
||||
crop = img.crop((0, int(h*0.15), w, int(h*0.30)))
|
||||
crop.save('page1_credit.jpg', 'JPEG', quality=75)
|
||||
"
|
||||
|
||||
# tesseract 读取
|
||||
tesseract page1_credit.jpg stdout -l chi_sim+eng --psm 6
|
||||
```
|
||||
|
||||
### 2. 企查查 web 搜索交叉验证
|
||||
```
|
||||
web_search: "公司全称" 统一社会信用代码 企查查
|
||||
```
|
||||
企查查结果通常直接显示完整 18 位信用代码。
|
||||
|
||||
### 3. 校验位验证（Python）
|
||||
统一社会信用代码第 18 位是校验位，可用以下脚本验证：
|
||||
```python
|
||||
def verify_credit_code(code):
|
||||
if len(code) != 18:
|
||||
return False
|
||||
weights = [1,3,9,27,19,26,16,17,20,29,25,13,8,24,10,30,28]
|
||||
chars = '0123456789ABCDEFGHJKLMNPQRTUWXY'
|
||||
code_map = {c:i for i,c in enumerate(chars)}
|
||||
total = sum(code_map[code[i]] * weights[i] for i in range(17))
|
||||
check = 31 - (total % 31)
|
||||
if check == 31: check = 0
|
||||
expected = chars[check] if check < len(chars) else '?'
|
||||
return expected == code[17], expected, code[17]
|
||||
```
|
||||
|
||||
## OCR 常见误识模式
|
||||
- `MA1NAEBX26` → `MA INAEBX26`（数字0被识别为空格）
|
||||
- `MADQRFT66P` → `MADQRFT66P`（通常正确，但需验证末位校验位）
|
||||
- 数字 `0` 和字母 `O` 混淆
|
||||
- 数字 `1` 和字母 `I` 混淆
|
||||
|
||||
## 判据
|
||||
- tesseract 重读结果与企查查一致 → 采用
|
||||
- tesseract 重读结果与企查查不一致 → 以企查查为准（企查查是权威工商数据源）
|
||||
- 校验位验证不通过 → OCR 有误，回企查查取正确值
|
||||
|
||||
## 与 OCR 完整性检查脚本的关系
|
||||
`ocr-integrity-check.py` 已修复：信用代码中的字母序列（前后有数字的）不再误报为"公司名乱码"。修复方式：检测字母序列前后是否为数字，如是则跳过。
|
||||
|
||||
## 2026-06-29 实证
|
||||
- 解放中路：甲方 "91320600MA1NAEBX26"（企查查确认）
|
||||
- 通大附：甲方 "91320600MA1NAEBX26"（企查查确认）
|
||||
- 通大附：乙方 "91320602MADQRFT66P"（校验位 P 验证通过）
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
# DeepSeek-OCR 主链路与非交互 session 取 key 规则（2026-07-13）
|
||||
|
||||
## 适用场景
|
||||
- 批量扫描件合同梳理
|
||||
- 需要把 PDF / 图片先转成 Markdown 再审查/比对/回填汇总表
|
||||
- 当前环境已把 `SILICONFLOW_API_KEY` 写在 `~/.bashrc`，但 agent 所在 session 不是交互式 shell
|
||||
|
||||
## 本次会话固化结论
|
||||
1. **默认 OCR 主链路改为 DeepSeek-OCR**，脚本：`~/.hermes/scripts/deepseek_ocr.py`
|
||||
2. **不要默认回到 marker-pdf / surya 本地链路**；本地 OCR 只作显式要求下的备选/对照，不是默认方案。
|
||||
3. 批量扫描件建议流程：
|
||||
- 先批量跑 `deepseek_ocr.py` 生成 md
|
||||
- 再做 grep / 规则扫描，筛出乱码、过短、金额大小写冲突、主体名称异常、日期异常
|
||||
- 最后只对异常页做 vision 定点校对
|
||||
4. `deepseek_ocr.py` 已修成：
|
||||
- 先读当前进程环境变量 `SILICONFLOW_API_KEY`
|
||||
- 若当前 session 没带 key，则回退到 `bash -ic` 从 `~/.bashrc` 读取
|
||||
- 读取成功后回填到当前进程环境
|
||||
- 两边都没有才报错：`Missing SILICONFLOW_API_KEY in environment or ~/.bashrc`
|
||||
|
||||
## 为什么要这样做
|
||||
非交互 shell 默认不加载 `~/.bashrc`。如果只在脚本里 `os.environ.get("SILICONFLOW_API_KEY")`，则新 session/批量 terminal 调用会误报“缺 key”，但实际上 `.bashrc` 里已经有 key。
|
||||
|
||||
## 执行口径
|
||||
- 单文件：
|
||||
```bash
|
||||
python3 ~/.hermes/scripts/deepseek_ocr.py /path/to/file.pdf -o /path/to/file.md
|
||||
```
|
||||
- 批量：按合同目录遍历 `.pdf`，逐个输出同名 `.md`
|
||||
- 批量产物出来后，优先筛这几类异常：
|
||||
- 结果过短（只剩标题/前几行）
|
||||
- 金额小写与大写不一致
|
||||
- 主体名称错字/缺字
|
||||
- 日期区间逻辑不通
|
||||
- 银行账户等长数字串
|
||||
|
||||
## 已验证案例
|
||||
- 北翼玖玖 17 份 PDF：已全量跑完 DeepSeek-OCR 输出 md
|
||||
- 发现的典型异常：
|
||||
- 某些物业合同只识别出标题，正文漏识别
|
||||
- 押金小写金额与大写金额明显冲突
|
||||
- 主体名称 OCR 错字（如“崇区川”）
|
||||
|
||||
## 给后续 agent 的一句话
|
||||
**扫描件合同默认先跑 DeepSeek-OCR，再筛异常，再 vision 定点校对；不要一上来就切回本地 OCR。**
|
||||
@@ -0,0 +1,64 @@
|
||||
# DeepSeek OCR 默认主链路（2026-07-13）
|
||||
|
||||
## 结论
|
||||
当任务目标是**把扫描件 / PDF 稳定识别出来**，默认主链路使用：
|
||||
|
||||
- `~/.hermes/scripts/deepseek_ocr.py`
|
||||
- provider / API: **SiliconFlow**
|
||||
- model: `deepseek-ai/DeepSeek-OCR`
|
||||
- env var: `SILICONFLOW_API_KEY`
|
||||
|
||||
不默认回退到本地 `marker-pdf / surya`。只有在以下情形才改走本地链路：
|
||||
1. 用户明确要求离线 / 本地 OCR；
|
||||
2. DeepSeek OCR 存在不可回避的外部约束（如目标环境无法提供 API key 或必须完全脱网）；
|
||||
3. 任务本身不是“先把内容识别出来”，而是明确在做本地 OCR 工具验证 / 对比实验。
|
||||
|
||||
## 本次会话得到的稳定经验
|
||||
### 1. 先定路线，再谈环境
|
||||
本次一开始把“当前 Python 环境被 marker-pdf 安装污染”讲得太重，容易把讨论带到本地 OCR 包冲突上；但用户真正要的是：
|
||||
|
||||
> 能用 DeepSeek OCR 就直接用，不要默认折回本地方案。
|
||||
|
||||
所以遇到 OCR 任务，先回答：
|
||||
- 目标是**稳定抽取内容**，还是**验证本地 OCR 工具**？
|
||||
- 如果是前者，先走 DeepSeek OCR 主链路。
|
||||
|
||||
### 2. 验证必须是真跑，不是口头判断
|
||||
本次实际验证命令：
|
||||
|
||||
```bash
|
||||
bash -ic 'python3 ~/.hermes/scripts/deepseek_ocr.py "/home/maggie/contract-review/其他任务/ht_page-1.png" -o /tmp/deepseek_ocr_final.md'
|
||||
```
|
||||
|
||||
成功返回：
|
||||
- 输入/输出 token 计数
|
||||
- Markdown 文件落地
|
||||
- 读回输出文件后可见 OCR 表格内容
|
||||
|
||||
因此以后汇报“可用”时，必须至少给出：
|
||||
1. 实际命令；
|
||||
2. 实际返回；
|
||||
3. 输出文件或结果句柄。
|
||||
|
||||
### 3. `.bashrc` 中的 key 只对交互式 bash 自动生效
|
||||
本次确认：
|
||||
- `SILICONFLOW_API_KEY` 写在 `~/.bashrc`
|
||||
- 非交互 shell 直接执行时，脚本可能读不到该变量
|
||||
- `bash -ic '...'` 能加载 `.bashrc`，因此验证通过
|
||||
|
||||
因此如果 workflow / 子进程依赖这条 OCR 链路，必须显式保证环境变量可见；不要因为一次 `bash -c` 读不到 key，就误判 DeepSeek OCR 不可用。
|
||||
|
||||
### 4. 脚本不得偷偷依赖硬编码 fallback key
|
||||
本次还暴露出：`deepseek_ocr.py` 曾带硬编码 fallback key。正确做法是：
|
||||
- 只从 `SILICONFLOW_API_KEY` 读取；
|
||||
- 没有 key 就直接报错退出；
|
||||
- 避免“看起来可用，其实在吃脚本里藏着的 key”这种假成功。
|
||||
|
||||
## 汇报口径
|
||||
当用户指定“以后都用这个方案”时，回复应直接、简洁：
|
||||
- 已切换默认 OCR 方案为 DeepSeek OCR；
|
||||
- 已确认环境变量位置；
|
||||
- 已实际跑通；
|
||||
- 本地 marker/surya 不再作为默认主方案。
|
||||
|
||||
不要再把话题绕回“当前主对话模型是不是 DeepSeek”。聊天模型链路 ≠ OCR 链路。
|
||||
@@ -0,0 +1,31 @@
|
||||
# 帝奥地产格式合同 — 与07模版核心差异速查（金飞达实证 2026-06-27）
|
||||
|
||||
> **适用校区**：金飞达（所有合同均使用帝奥地产格式，与07模版结构完全不同）
|
||||
> **比对基准**：07-房屋租赁合同.docx（15条+附加条款）
|
||||
> **帝奥格式**：20条，结构完全重构，偏向保护出租方
|
||||
|
||||
## 缺失的07模版核心条款（帝奥格式均无）
|
||||
|
||||
1. **第七条 出租方变更**：无通知义务，无新业主继续有效
|
||||
2. **第九条 优先购买权**：乙方明确放弃（第11.2条）
|
||||
3. **第十一条 不可抗力**：无疫情/行业治理/政策变更减免权
|
||||
4. **第十二条第4款 办学许可证**：无无法办证退出机制
|
||||
5. **第十四条第4款 租赁备案义务**：无
|
||||
6. **第十四条第5款 竞业限制**：无
|
||||
7. **附加条款**：无装修配合/标识广告/配套设备
|
||||
|
||||
## 帝奥格式特有不利条款
|
||||
|
||||
| 条款 | 内容 | 风险等级 |
|
||||
|---|---|---|
|
||||
| 第10条 房屋返还 | 恢复原状/逾期7日视为放弃物品/停水停电强制措施 | 🔴 |
|
||||
| 第11.2条 | 乙方放弃优先购买权 | 🔴 |
|
||||
| 第11.3条 | 甲方转让后不再承担任何责任 | 🔴 |
|
||||
| 第14条 免责 | 甲方全面免责（自然灾害/盗窃/设施故障/水电中断） | 🔴 |
|
||||
| 第13.5条 逾期违约金 | 每日万分之五（07模版0.1‰的5倍） | 🟡 |
|
||||
| 第13.2条 营业执照注销 | 每日月租金10% | 🔴 |
|
||||
| 第19.5.1条 租金保密 | 泄密恢复原价（主合同120万/年，现价3.1倍） | 🔴 |
|
||||
|
||||
## 合同捆绑关系
|
||||
|
||||
金飞达777+633+499三份合同通过补充协议形成连锁捆绑：任一份出问题牵连全部。
|
||||
@@ -0,0 +1,35 @@
|
||||
# 执行诚实性纪律（龙信 2026-07-03 教训）
|
||||
|
||||
## 起因
|
||||
|
||||
Maggie 发现龙信三份合同的首次梳理没有按 workflow 逐字逐句执行，直接质问"你是自己逐字逐句审阅的么？"，要求重做。
|
||||
|
||||
## 教训
|
||||
|
||||
1. **"看起来差不多/跟上个校区一样/只有2个月风险有限"不是跳过审查的理由**
|
||||
- 海门临时合同虽仅2个月且已到期，但仍需完整做八维框架审查
|
||||
- 每份合同独立做，不能从另一份合同复制结论
|
||||
|
||||
2. **L列模版比对适用于所有租赁合同，不分制式**
|
||||
- 龙信广场（甲方制式）→做了40条差异
|
||||
- 海门临时（甲方制式）→做了32条差异
|
||||
- 正因为不是新东方制式，差异才更大，客户才更需要知道
|
||||
|
||||
3. **速度不是质量的对手**
|
||||
- 宁可告知"工作量大需要更多时间"，不偷偷跳过假装做完
|
||||
- Maggie原话："你不按照规则作出的东西很明显质量不行的，务必按照Workflow和规则执行，不能自己发挥"
|
||||
|
||||
## 行排序规则补充
|
||||
|
||||
默认按签约时间排序（column-rules-0701.md），但 **Maggie明确指定行顺序时以指定为准**。
|
||||
- 龙信0703：Maggie指定"租赁和物业放前两行，海门临时放第三行"→覆盖默认排序
|
||||
- 原则：用户明确指令 > 默认规则
|
||||
|
||||
## K列"模版"禁词
|
||||
|
||||
kl-separation-check.py 对 K列 grep "模版|07模版" 是0容忍——即使上下文是"出租方制式模版"这种描述性用法也会触发。
|
||||
|
||||
**解法**：K列一律用"制式合同"或"制式文本"替代"制式模版"。
|
||||
- ❌ "本合同为甲方制式模版"
|
||||
- ✅ "本合同为甲方制式合同"
|
||||
- ✅ "条款与龙信广场租赁合同几乎一致（出自同一出租方制式文本）"
|
||||
@@ -0,0 +1,29 @@
|
||||
# 文件盘点与归类规则（校区/项目第一次出现时建立）
|
||||
|
||||
> Maggie 2026-06-16 确立。**第一次接触某校区（或某新主体），先把文件家底摸清、按规则排好；此后一切变动都照此归位。** 这是台账可追溯的地基。
|
||||
|
||||
## 第一步 · 盘点
|
||||
看校区文件夹里**有哪些文件、如何排列**，逐一核实确认。不要急着分析——先确认清单完整、文件可读（OCR 是否成功、有无缺失主合同/缺页）。空目录或缺失主合同要标注（如悦拾光缺一期主合同、跃龙路/通州金鹰缺租赁合同只有物业合同）。
|
||||
|
||||
## 第二步 · 按固定规则归类排序
|
||||
```
|
||||
校区文件夹
|
||||
├─ 一、租赁合同
|
||||
│ ① 按【租赁场所 / 位置】分类（如 原租/4幢、扩租/507室、不同铺位）
|
||||
│ ② 每个场所内 按【签约时间】排序：
|
||||
│ 主合同 → 补充协议1 → 补充协议2 → 变更协议 → 解除协议
|
||||
└─ 二、物业合同（归类规则与租赁合同【完全相同】）
|
||||
① 按【场所 / 位置】分类 ② 每个场所内按【签约时间】排序
|
||||
```
|
||||
|
||||
> ⚠️ **物业合同的归类规则与租赁合同一模一样**（场所→时间），**不是"简化归类"**。
|
||||
> **物业合同同样逐条审查、不挑不跳**（与 SKILL.md「每份合同逐条审查」铁律一致）——物业合同的特点只是**风险点天然少、且无对应标准模版**（L列标注"物业服务协议，无对应标准模版"），**绝不等于"简化审查"或"挑重点审"**。审查深度不打折，覆盖面不缩水；归类方式更不简化。
|
||||
> **一般一份租赁合同对应一份物业合同（一对一、成对存在）**——盘点时按场所核对配对关系：每个租赁场所应有对应的物业合同，缺失的要标注（如跃龙路/通州金鹰只有物业、缺租赁合同；反之亦然）。
|
||||
|
||||
## ★ 铁律（贯穿全流程）
|
||||
- 后续 **新签 / 变更 / 解除** 的合同，**一律按此规则归位**——不是堆到末尾，而是插进对应场所、对应时间位置。
|
||||
- 规则贯穿 **生成 · 邮件 · 网盘** 全流程，前后一致。
|
||||
- **不跨文件夹重新归类**：客户的文件夹结构（房租/扩租/物业）就是 sheet 的板块划分依据，即使物业合同放在"扩租"文件夹里，也归到"扩租系列"板块，不按合同性质重排（Pitfall #14，Maggie 20260609 已纠正过一次）。
|
||||
|
||||
## 与汇总表 sheet 板块的对应
|
||||
校区 sheet 的板块（"一、原租赁系列""二、扩租系列""三、物业"等）直接映射这个归类层级。盘点归类做对了，填表板块自然就对。
|
||||
+49
@@ -0,0 +1,49 @@
|
||||
# 通读强制纪律（悦拾光0703教训）
|
||||
|
||||
## 事件
|
||||
|
||||
悦拾光校区审查中，Step2动作A"法律审查"实际做法是：
|
||||
- grep关键词定位 → 读周围片段 → 参考旧版xlsx填补
|
||||
|
||||
这不是"逐字逐句综合全文理解判断"。证据：
|
||||
- 第36条争议解决写得清清楚楚"该房屋所在地人民法院"，但grep没命中"管辖"二字就写了"未明确约定"
|
||||
- 30.3条"超7日停水停电"散在多行（OCR断行），只读到"每日3%"就停了
|
||||
- 14.2条甲方维修影响使用应减租——通读时本应纳入
|
||||
- 26.2/26.5/27.5/8.3/25.5/25.6等条款——如果真通读了不可能漏
|
||||
|
||||
## 根因
|
||||
|
||||
grep只能命中精确关键词。合同OCR断行严重，一个完整句子散落多行，grep无法还原语义。
|
||||
旧表印象≠独立审查。参考旧表填补本质上是复制粘贴不是审查。
|
||||
|
||||
## 纪律（三层保障）
|
||||
|
||||
### 第一层：通读强制
|
||||
Step2动作A必须用read_file从第1行读到最后一行（每批500行），不得用grep代替通读。
|
||||
grep只用于**二次定位验证**（如确认某条款的确切行号），不用于替代阅读。
|
||||
|
||||
### 第二层：覆盖计数自检
|
||||
I列写完后检查条款标签数：
|
||||
- 租赁合同≥15/21类目（有就写没有不写，但必须逐一确认过）
|
||||
- 物业合同≥10/15类目
|
||||
不够就跑 `scripts/i-column-coverage-check.py` 报警核查。
|
||||
|
||||
### 第三层：争议解决+管辖必检
|
||||
每份合同I列写完后，手动确认：
|
||||
- "管辖"类目是否填写？
|
||||
- 填写内容是否与合同末尾条款原文一致？
|
||||
如果I列"管辖"为空或含"未约定"→必须回原文最后5页重新确认。
|
||||
这是悦拾光教训的直接产物。
|
||||
|
||||
## Maggie原话
|
||||
|
||||
> "不只是关键条款，逐字逐句都要核准校对"
|
||||
> "对应的法律审查和风险分析你是逐字逐句综合全文理解判断的么？"
|
||||
> "准确严谨是一切工作的基础"
|
||||
> "你还是要设计一个机制，让你不会偷懒"
|
||||
|
||||
## 自检信号
|
||||
|
||||
- I列条款标签数 < 合同章节数×1.5 = 没通读
|
||||
- "争议解决"写错/写漏 = "逐字逐句"没做到的铁证
|
||||
- K列风险点与旧版雷同但条款号缺失 = 复制旧表没独立审查
|
||||
@@ -0,0 +1,32 @@
|
||||
# H列付款推算——跨费率期计算陷阱（2026-07-08世茂教训）
|
||||
|
||||
## 问题根因
|
||||
合同有多个费率期（如2025.12-2027.2按费率A，2027.3-2029.2按费率B），但付款周期（结算周期12个月）与费率变更日不对齐。
|
||||
|
||||
某一付款期可能横跨两个费率期。必须分段计算。
|
||||
|
||||
## 错误做法（世茂第3/4期）
|
||||
```
|
||||
第3期（2027.5.1-2028.4.30）= 33,280.59 × 12 = 399,367
|
||||
```
|
||||
→ 全部按第1费率计算，少算约12,000元
|
||||
|
||||
## 正确做法
|
||||
1. 先确定每个付款期的起止日
|
||||
2. 看该期内是否跨越费率变更日
|
||||
3. 如果跨越，分段：变更日前×旧费率 + 变更日后×新费率
|
||||
4. 如果不跨越，直接用当期费率×月数
|
||||
|
||||
## 第2费率反推方法
|
||||
当合同只给了第1费率和第2期总金额时：
|
||||
```
|
||||
第2期总金额 = 第1费率×N个月 + 第2费率×M个月
|
||||
第2费率 = (第2期总金额 - 第1费率×N) / M
|
||||
```
|
||||
验证：不含税×(1+税率)=含税（必须算术闭合）
|
||||
|
||||
## 自检清单
|
||||
- [ ] 每期付款金额是否与当期适用费率一致？
|
||||
- [ ] 费率变更日是否在某个付款期中间？如果是，是否分段计算了？
|
||||
- [ ] 最后一期是否不满整个结算周期？月数是否正确？
|
||||
- [ ] 含税=不含税×(1+税率) 算术是否闭合？
|
||||
@@ -0,0 +1,39 @@
|
||||
# H列付款推算规则 (0703)
|
||||
|
||||
## 月租换算写法
|
||||
- **铁律**：月租换算一律用行内括号写法，写在租金标准行内
|
||||
- 格式：`年XX元（月租≈XX元）`
|
||||
- **不允许**单独另起一行写月租换算
|
||||
- 参照标准：通大校区写法
|
||||
- 来源：Maggie 2026-07-03 明确指示："以后的都按通大的写法"
|
||||
|
||||
## 付款推算从汇总表直接计算（高效方法）
|
||||
- **不需要每次回md原文**，H列已有支付方式+租金标准+递增规则+物业费，G列有起止日期+免租期
|
||||
- 流程：
|
||||
1. G列取起止日期+免租期
|
||||
2. H列取租金/期、物业费/月、支付方式（半年一付/季付等）
|
||||
3. 按支付周期切分区间 → 算出每期金额+付款截止日
|
||||
- 仅当数据存疑（如附件分期跟正文对不上）才回md核实
|
||||
- OCR文本有识别噪音，能用汇总表数据就不翻原文
|
||||
|
||||
## 付款推算写入格式
|
||||
```
|
||||
【付款推算】租金+物业费合并列示，半年一付，提前30天（第X条第X款）
|
||||
第1期（起止日期）：租金XX + 物业XX = XX元 ┃ 签约后7天内
|
||||
第2期（起止日期）：租金XX + 物业XX = XX元 ┃ 付款期限YYYY.M.D
|
||||
...
|
||||
❗第N期（起止日期，递增后）：租金XX + 物业XX = XX元 ┃ 付款期限YYYY.M.D
|
||||
```
|
||||
|
||||
### 格式要点
|
||||
- 租金和物业费合并列示，每期分别标出两项金额及合计
|
||||
- ❗标注尚未到期的付款期次（以今天日期判断）
|
||||
- 付款期限 = 期次起始日 - 提前天数
|
||||
- 首期特殊处理（签约后X天内）
|
||||
- 含免租期的期次标注"含免租"
|
||||
- 递增后的期次标注"递增后"
|
||||
|
||||
## 数据验证
|
||||
- 写入前必须验算：各期租金合计 ≈ 合同总租金
|
||||
- 允许四舍五入1元以内差异
|
||||
- 物业费 = 单价×面积×月数，逐期核对
|
||||
@@ -0,0 +1,34 @@
|
||||
# 幻觉防火墙（2026-07-02 星月校区教训）
|
||||
|
||||
## 事件
|
||||
|
||||
星月校区汇总表交付后被Maggie发现：
|
||||
- E列（租赁标的/用途）写了"办公/教育培训/教学相关经营"——但合同原文只约定了"办公"
|
||||
- E列地址只写"南通星月智创园2楼"——合同原文完整地址是"南通市崇川区新胜路6号星月智创园2幢2F"
|
||||
- Maggie判定：整个校区审查不严谨，要求重做
|
||||
|
||||
## 根因
|
||||
|
||||
**没有真正逐字读合同就开始填表。** 看到"南通新东方教育"就用行业常识推断用途是"教育培训"——这是幻觉，不是笔误。如果逐字读了第二条用途条款，不可能写出合同里不存在的内容。
|
||||
|
||||
## 铁律
|
||||
|
||||
**E列和I列的每个事实必须能在OCR全文中ctrl+F搜到对应原文。搜不到=编的=必须改。**
|
||||
|
||||
具体：
|
||||
1. E列"用途"：grep合同"用途"/"经营范围"条款原字填写，不从租户名/行业推断
|
||||
2. E列"地址/标的"：从第一条"租赁标的物"条款完整抄录（含区/路/号/幢/楼层）
|
||||
3. I列"核心内容"：每条前面的[条款号]必须真实存在于合同中
|
||||
4. 不需要加括号备注"合同原文仅约定XX"——客户不需要知道你的工作过程
|
||||
|
||||
## 自检
|
||||
|
||||
填完E/I列后，对每份合同做：
|
||||
```
|
||||
grep -c "你写的关键词" 合同OCR全文.md
|
||||
```
|
||||
返回0 = 你编的 = 停下来回原文找正确表述
|
||||
|
||||
## 后果
|
||||
|
||||
一个字段的幻觉 → Maggie判定整表不可信 → 整个校区重做。成本是原来的2倍+信任损失。
|
||||
@@ -0,0 +1,42 @@
|
||||
# 幻觉事件：星月校区用途字段编造（2026-07-02）
|
||||
|
||||
## 事件
|
||||
|
||||
星月校区两份租赁合同原文：
|
||||
- 1楼：`所租赁房屋仅作为办公用途使用`
|
||||
- 2楼：`所租赁房屋仅作为办公用途使用`
|
||||
|
||||
汇总表E列和I列填写为：`办公/教育培训/教学相关经营`
|
||||
|
||||
Maggie发现后质问："星月的租赁用途，哪里体现了教学配合和教育相关经营？""貌似你出现了幻觉"
|
||||
|
||||
## 根因
|
||||
|
||||
不是OCR乱码问题——原文清楚写了"办公"。失败模式是**从租户名称推断合同内容**：
|
||||
- 看到"南通新东方教育科技有限公司"→大脑自动补全"所以用途是教育培训"
|
||||
- 没有回到合同第二条原文逐字核对就填了表
|
||||
|
||||
## 铁律（补充进地基四铁律·逐字逐句）
|
||||
|
||||
**E列（租赁标的/用途）和I列（核心内容）的每一个事实，必须对应到合同原文具体条款的具体文字。**
|
||||
|
||||
禁止路径：
|
||||
- ❌ 从公司名称推断经营用途
|
||||
- ❌ 从"新东方=教培"的常识推断合同约定
|
||||
- ❌ 从其他校区合同的约定类推本校区
|
||||
- ❌ 任何"应该是""大概率是""结合实际"的脑补
|
||||
|
||||
正确路径：
|
||||
- ✅ grep "用途" → 定位条款 → 逐字抄写原文
|
||||
- ✅ 原文空白/未填写 → 如实标注"合同未明确约定"
|
||||
- ✅ 原文与实际不符 → K列标为风险点，不改E/I列的事实记录
|
||||
|
||||
## 自检口诀
|
||||
|
||||
填E/I列每一格时问自己：**"这个字在合同哪一页哪一条？"**——答不上来就不能写。
|
||||
|
||||
## 修正内容
|
||||
|
||||
1. E列：改为"用途：办公（合同原文仅约定办公）"
|
||||
2. I列：改为"仅限办公用途（合同原文）"
|
||||
3. K列：新增🔴风险点——约定"办公"与实际教育培训可能不一致，触发擅自改变用途解除权
|
||||
@@ -0,0 +1,103 @@
|
||||
# I列核心内容标准（Maggie 2026-07-03 确认）
|
||||
|
||||
## 原则
|
||||
- 按固定类目逐项提炼，有就写没有就不写
|
||||
- 格式：`· [类目] 关键事实（条款号）`
|
||||
- 精简干练——用最少的字传达最准确的信息
|
||||
- **只提取总结，不评论**——I列的职责是客观提取合同条款内容，不做风险评价、不加建议、不写"需注意"。评价属于K列（Maggie 2026-07-08纠正）
|
||||
- 同模板多合同：后续行写"条款结构与XX一致。差异：·面积 ·租期 ·保证金"
|
||||
- **只提取总结，不评论**：I列职责是客观提炼条款内容，不做风险评价、不给建议、不加⚠️评论。评价性内容（"需确认是否一致""建议补充书面确认"）属于K列法律风险分析的职责。I列看到什么写什么，判断留给K列。
|
||||
|
||||
## 租赁合同 21 类目
|
||||
1. 用途
|
||||
2. 转租
|
||||
3. 装修改造
|
||||
4. 广告标识
|
||||
5. 非竞争
|
||||
6. 维修责任
|
||||
7. 保险要求
|
||||
8. 物业服务联动
|
||||
9. 配套设施
|
||||
10. 出租方变更
|
||||
11. 解除权机制
|
||||
12. 违约金机制
|
||||
13. 不可抗力
|
||||
14. 征收拆迁
|
||||
15. 房屋抵押查封
|
||||
16. 政策变化
|
||||
17. 到期处理
|
||||
18. 恢复原状
|
||||
19. 优先权
|
||||
20. 管辖
|
||||
21. 备案
|
||||
|
||||
## 物业合同 15 类目
|
||||
1. 物业服务内容
|
||||
2. 服务标准
|
||||
3. 公共能耗费
|
||||
4. 特约服务
|
||||
5. 共用设施管理
|
||||
6. 装修管理
|
||||
7. 安保措施
|
||||
8. 消防安全
|
||||
9. 保险要求
|
||||
10. 联动终止
|
||||
11. 违约责任
|
||||
12. 退出交接
|
||||
13. 免责条款
|
||||
14. 不可抗力
|
||||
15. 管辖
|
||||
|
||||
## 精简对比示例
|
||||
❌ 冗余：
|
||||
```
|
||||
· [转租] 未经甲方书面同意，乙方对于承租房屋不得以任何形式转租、转让、转借、抵押或其他有损甲方利益的行为（4.5条、第二条）
|
||||
```
|
||||
|
||||
✅ 精简：
|
||||
```
|
||||
· [转租] 未经书面同意不得转租/转让/转借/抵押（4.5条）
|
||||
```
|
||||
|
||||
## ❌ 评论混入示例（龙信0708教训）
|
||||
```
|
||||
【用途】新东方学习机；增加用途或部分转租须甲方同意（第二条）
|
||||
⚠️ 合同限定"新东方学习机"，如实际用途为教育培训/托管，需与甲方确认是否一致...
|
||||
```
|
||||
→ 第二行是风险评价，属于K列。I列只写第一行。
|
||||
|
||||
## 关键输出纪律（Maggie 2026-07-08 确认）
|
||||
|
||||
1. **I列只提取总结不评论** — 核心条款提炼是事实摘录，风险评论属于K列
|
||||
2. **K列提前退租分析** — 简明扼要只标条款号，不引用合同原文全文
|
||||
3. **合同字段"/"=不适用** — 该事项不再提及（如营业额提成为/，H/I/K/L均不写）
|
||||
4. **L列差异数必须全列** — 禁止写"X项差异"只列其中一部分；要么全列要么不写总数
|
||||
5. **H列每份合同完整** — 禁止"同上""详见附件"，必须写明具体金额+完整付款推算
|
||||
6. **整体评价含总费用** — 第三部分校区整体评价必须包含合同期内租金+物业费总费用汇总
|
||||
|
||||
## 覆盖检查
|
||||
建表后跑 `scripts/i-column-coverage-check.py`：
|
||||
- 租赁合同达标阈值：15/21
|
||||
- 物业合同达标阈值：10/15
|
||||
- 报警≠阻断——有些合同确实没这么多类目，核查确认"是真没有还是漏了"即可
|
||||
|
||||
## 通读强制机制（悦拾光 0703 教训）
|
||||
|
||||
### 根因
|
||||
之前做法=grep关键词→读片段→参考旧表填补。本质是关键词抽查+旧表印象，不是独立审查。
|
||||
后果=争议解决"房屋所在地法院"写成"未明确约定"、逾期停水电门槛7日写成30日——错得很基础。
|
||||
|
||||
### 强制规则
|
||||
Step2动作A法律审查必须用read_file从第1行读到最后一行（分批500行/次），**不得用grep抽查代替通读**。
|
||||
|
||||
### 自检信号
|
||||
- I列类目覆盖数≥阈值
|
||||
- 争议解决条款有条款号→证明读到了最后几条
|
||||
- 每个违约金数字都有条款号→证明逐条读了违约章节
|
||||
|
||||
### 避免偷懒的三重保障
|
||||
| 层 | 位置 | 何时触发 |
|
||||
|---|---|---|
|
||||
| 规则文档 | column-rules-0701.md | 加载skill时 |
|
||||
| 模板代码 | builder.py注释里列21+15清单 | 建表时 |
|
||||
| 检查脚本 | i-column-coverage-check.py | 建完表跑一次 |
|
||||
@@ -0,0 +1,36 @@
|
||||
# 增量维护 SOP（新增 / 到期 / 提前解除）
|
||||
|
||||
> 汇总表是**持续维护的法律台账**，不是一次性交付。每次变动都走三角色分工（承办—校对—终审），保证隔多久、哪次对话都输出同一套标准。
|
||||
|
||||
## 通用前置（所有变动，缺一不可）
|
||||
1. **绝不基于旧本地副本改**——先从 Nextcloud 拉最新版 xlsx（见 SKILL.md「跨Session续做铁律」）
|
||||
2. 打开表确认实际现状：改哪个校区、哪一行、当前值是什么
|
||||
3. 新版本按日期递增命名：`南通新东方-租赁合同汇总表-YYYYMMDD.xlsx`
|
||||
4. 登记 todo，变动完成前不脱手
|
||||
|
||||
## 🟢 新增合同（新签 / 扩租 / 补充协议）
|
||||
1. **承办层**：
|
||||
- 提取分析员：OCR → 要素提取 → 模版比对(动作B) → 退租敞口 → 提取依据清单
|
||||
- 法律审查员（独立 subagent）：八维全面法律审查(动作A) → 法律风险清单
|
||||
2. **填表**：定位校区 sheet → 按**文件夹板块**插行（房租/扩租/物业，不跨板块重新归类）→ 同步更新总览对应行（承租主体、面积、租金、风险点等）
|
||||
3. **校对层**：法律校对（维度1-4）‖ 格式校对（维度5-6：字段齐备、总览-分表一致、面积/金额加总）
|
||||
4. **终审**：小Maggie 汇总闭环 → 上传 → 清缓存 → 交付 Maggie
|
||||
|
||||
## 🟡 合同到期
|
||||
1. 该合同行"当前状态" → "已到期（YYYY-MM-DD）"；总览同步
|
||||
2. **整校区退出**：历史行**保留不删除**（台账须可追溯），校区状态标注"已退出"
|
||||
3. **部分到期**（如某铺位到期、其余续租）：只改到期那行，面积/租金加总相应调整
|
||||
4. 一般无新法律内容 → **可跳过法律审查/法律校对**，走格式校对（状态与加总一致性）+ 终审
|
||||
5. ⚠️ 若到期伴随续租新合同 → 续租合同按🟢新增流程全程审查
|
||||
|
||||
## 🔴 提前解除
|
||||
1. "当前状态" → "已解除（YYYY-MM-DD）"
|
||||
2. **退租敞口 → 实际结算结果**：把当初测算的预估敞口，替换为实际发生的结算（实付违约金、押金处理、已退未用租金、恢复原状费用等）
|
||||
3. **法律校对**：核结算结果与解除协议/和解文件一致；若有争议或诉讼，标注状态
|
||||
4. 格式校对 + 终审
|
||||
|
||||
## 变更留痕（所有变动统一收口）
|
||||
- 表内保留**变更记录**（日期 + 事由 + 改动内容 + 经办），便于审计回溯
|
||||
- 改后三项校验：①总览与分表数据一致 ②面积/金额加总对得上 ③风险点已同步
|
||||
- 上传 Nextcloud + `files:scan` + 清 OnlyOffice 缓存并重启（见 SKILL.md Step 5）
|
||||
- 终审通过后交付 Maggie，附变更说明（改了什么、为什么、影响哪些数）
|
||||
+103
@@ -0,0 +1,103 @@
|
||||
# 独立法律审查框架（动作A）
|
||||
|
||||
> **定位**：把每一份合同当作一份**新合同**，站在乙方（承租方）立场，做全面法律风险审查。这是判断"合同本身有没有法律风险"的**唯一依据**。
|
||||
> **与模版比对的区别**：模版比对（动作B）只回答"与内部合规要求差多少"，是中性合规差距，**不能**作为法律风险判断。详见 SKILL.md「铁律：模版差异 ≠ 法律风险」。
|
||||
> **执行者**：独立 subagent（与提取分析员分离），不看承办思路，回到合同原文独立判断。
|
||||
|
||||
## ⚠️ 第0步·审查第一性原则：完整通读全文，准确把握每一条款的上下文语境与语义（2026-06-18 世茂14.x教训确立，最上位主规则）
|
||||
|
||||
**这不是某类高危条款的特殊要求，是法律审查的地基。** 适用对象是**整个合同文件和每一个条款**，不是只针对违约条款——任何一条都可能因没读全、没读懂语境而误判。
|
||||
|
||||
**两层要求，缺一不可：**
|
||||
1. **完整**——`read_file` 把整篇合同 OCR 文本（.md）一次性通读完，建立全文整体理解，再逐条审。不先通读，不开审。
|
||||
2. **准确**——通读不等于把字扫一遍。要**完整准确地把握每个条款的上下文语境与语义**：这条款在合同结构中的位置、与其他条款的勾连（被哪条限定/为哪条做前提/被附件或补充协议修改）、它在合同语境下的**真实语义**（不是字面，是这句话实际指什么）。
|
||||
|
||||
> 顺序铁律：**通读全文建立整体理解 → 在整体语境下逐条精读 → 再下结论**。跳过整体理解直接抽条款，必然丢语境。世茂14.2 我是"字看到了、语义没读懂"——"除…外"那层意思没整合进来，就是只做了"扫字"没做到"把握语义"。
|
||||
|
||||
### 为什么是铁律（拆穿"读不完"的借口）
|
||||
- 世茂14.2教训的根因诊断：我把"逾期付款违约金千分之2"漏了基数、把14.2"除租赁保证金不予退还冲抵违约金外，还应…，不足补足"的**三层叠加只摘了中间一截**。当时我归因为"PDF 11MB 太大不能通读，只能 grep 抽取"——**这是错的，是给"命中即停"找的借口**。
|
||||
- **真相（已实测）**：那 11MB 只是**PDF 扫描图像**的体积；法律审查读的是 **OCR 后的 .md 文本，只有 ~58KB、580行、22960字符**，远在单次 read_file 能力内（上限约10万字符）。一份合同 .md 通常 20–60KB，**几次 read_file 就整篇读完**。输入从来不大，是我没读。
|
||||
- 那句完整的14.2原文**就在 grep 命中的同一行的句首**——"保证金不予退还"那层不需要跨条整合，它就在命中行开头，我却只看了命中点中段。这证明失败点不是"跨条没整合"，而是"连命中那一句都没从头读到尾"。
|
||||
|
||||
### 协议（介质无关，Word/PDF 通用）
|
||||
1. **审查第一步：完整通读全文**。`read_file` 读整篇 .md（580行的合同分2次读、每次约300行即可），形成全文结构理解，再逐条提取。**不先通读，不开审。**
|
||||
2. **逐条精读时把握语境语义**：每读一条，问三件事——①这条在合同结构里管什么？②有没有被别处（其他条款/附件/补充协议）限定、修改、设前提？③它的真实语义是什么（整句从头读到尾，不摘单句、不停在命中点）？
|
||||
3. **grep/检索降级为辅助坐标工具**：只在"已通读、回头定位某条具体位置"时用。**严禁拿 grep 命中的单行当审查依据**——命中行只是"这儿有东西，回去从该条编号读起"的路标。
|
||||
4. **检索定位后必须回读整条款**：grep 命中 `14.2` → 光标退回 `14.2` 条编号 → 从头读到下一个编号 `14.3` 出现为止 → 整条读完、读懂语义再提取。把"命中即停"改成"命中即回读整条"。
|
||||
5. **删除错误认知**："PDF大所以不能通读"是伪命题——审查读的是 KB 级 OCR 文本，不是 MB 级 PDF。文件体积永远不是跳过通读的理由。
|
||||
|
||||
### 高发区加重提示（PDF/OCR）
|
||||
- OCR 把有版式的合同压成**线性长文本**，条款的视觉层次（编号/缩进/分段）塌掉，长句如"除…外，还应…，不足…补足"在纯文本里更易被截断阅读。
|
||||
- 大 PDF 诱使人用检索抽取代替通读——这正是"命中即停"的温床。**越是大 PDF，越要严格执行第0步通读**（因为 OCR 文本其实不大）。
|
||||
- docx 相对安全是**结构红利**（python-docx 按段落读，段落边界强制整条读），不是功力——一旦在 docx 里也改用搜索定位+命中即停，照样翻车。规则对 Word/PDF 同等生效。
|
||||
|
||||
## 八维审查框架
|
||||
|
||||
> ⚠️ **逐条审查铁律（Maggie 2026-06-17）**：八维是审查维度，不是只挑命中的维度写。每份合同（含物业等附属合同）都要**从主体信息到签名落款逐条过一遍，不挑不跳**，禁标"简化审查"。逐条审查是**内部要求**（保证覆盖面），但**交付物不写"✅已审查无异常"展示段**（Maggie 2026-06-18 反转：交付物只列真正风险点，不罗列"审过且无问题"的条款）。详见 SKILL.md「铁律：每份合同逐条审查」节。
|
||||
|
||||
### 1. 主体与出租权基础
|
||||
- 出租方是否为产权人？非产权人出租需核**转租授权链**（产权人→二房东→本合同）是否完整、是否超授权范围
|
||||
- 签约主体是否有签约权限（法定代表人/授权代理人，授权书是否齐备）
|
||||
- 合同甲方名称与产权证、与实际收款主体是否一致；主体变更是否有变更协议衔接
|
||||
- ⚠️ 房屋已抵押/查封：核是否披露、抵押权实现时乙方的继续承租与补偿安排
|
||||
|
||||
### 2. 标的合法性
|
||||
- 租赁用途（教学/培训/办公/商业）与房屋规划用途是否冲突
|
||||
- 消防验收、安全条件是否具备（教育培训对消防要求高）
|
||||
- **办学许可前置**：房屋能否办出办学许可证；办不出时乙方有无无责退出通道
|
||||
- 标的描述（房号、面积、楼层）是否明确、可特定化
|
||||
|
||||
### 3. 权利义务对等性
|
||||
- 甲乙双方违约后果是否失衡（一方重罚、一方轻责）
|
||||
- 解除权配置是否对等（甲方解除门槛 vs 乙方解除门槛）
|
||||
- 单方变更权（甲方单方调租、单方修订管理规则）是否过度
|
||||
|
||||
### 4. 乙方核心保护（承租方视角重点）
|
||||
- **退出机制**：有无任意解除权？通知期、违约金是否合理
|
||||
- **政策/办学许可退出通道**：因政策、房屋原因无法经营/办证时能否无责解除
|
||||
- **不可抗力/情势变更**：范围是否覆盖疫情、行业治理、政策变更；能否减租
|
||||
- **优先权**：优先承租权、优先购买权
|
||||
- **装修投入保护**：装修残值、提前解除时的装修损失赔偿
|
||||
- **非竞争**：甲方能否租给同类竞争机构
|
||||
|
||||
### 5. 违约与救济的合法性与公平
|
||||
- 逾期付款违约金率：是否过高（年化超法律保护上限，乙方可主张调减，民法典585条）
|
||||
- 甲方违约救济是否完整（退押金 + 退预付 + 装修损失 + 诉讼/律师费）
|
||||
- 押金/保证金扣罚条件是否苛刻、退还是否设不合理前提
|
||||
- 违约金条款的**适用范围**：是否覆盖"无故提前退租"，还是仅限列举情形
|
||||
|
||||
### 6. 风险分配
|
||||
- 房屋抵押、查封、拍卖、征收/拆迁的风险由谁承担、有无补偿
|
||||
- 出租方变更（转让/继承）时合同是否继续有效、有无买卖不破租赁的强化约定
|
||||
- 房屋瑕疵、维修责任归属（是否倒置给乙方）
|
||||
- **表述用专业概念统领，别张冠李戴挂法条**（2026-06-17）：出租方变更=**所有权变动**（725买卖不破租赁）；查封/拍卖=**第三人主张权利**（729，≠725）；征收/拆迁=**征收征用**（243）。格式"专业概念（情形举例）"，法条默认不写进表格正文。
|
||||
|
||||
### 7. 争议解决与条款效力
|
||||
- 管辖约定（法院/仲裁、地点是否对乙方不利）
|
||||
- 是否存在无效/可撤销条款（违反强制性规定、显失公平）
|
||||
- 格式条款的提示说明义务（免除甲方责任、加重乙方责任的条款是否尽到提示，民法典496-497条）
|
||||
|
||||
### 8. 完整性与一致性
|
||||
- 必备条款是否齐备（标的、租金、期限、用途、违约责任）
|
||||
- 正文与补充协议/附件有无矛盾（如供电功率、面积、租金前后不一致）
|
||||
- 附件是否完整（产权证明、平面图、授权书、保密承诺书）
|
||||
- 签署是否有效（签字盖章、日期、骑缝）
|
||||
|
||||
## 法条核实铁律
|
||||
- 引用的每条法律法规**必须核实引用时点的现行有效版本**，判断适用新法或旧法
|
||||
- 法条**全文引用**，不归纳、不删改
|
||||
- 案例引用需**案号 + 法院 + 日期**齐全，不写"某法院判决"
|
||||
- （与「法律文书写作铁律」一致）
|
||||
|
||||
## 风险定级纪律（克制，2026-06-17 Maggie 万达打样）
|
||||
站乙方立场 ≠ 把每处瑕疵都往高风险写。定级看**实际影响**，详见 SKILL.md「风险定级纪律」节：
|
||||
- **形式瑕疵**（签署日期空白、印章不全、填空未填）→ 关键履行要素已明确约定且合同已实际履行的，评 🟢 低风险，落"建议补正以规范合同管理"，不写"效力存疑"。
|
||||
- **尽调/核验类**（权属/资质/证照核验）→ 用操作性"请确认已核验…并存档"提示，归 🟢 低风险，不写"未核验→风险"。
|
||||
- **一条风险只讲一件事**，不把真问题与伪问题捆在一条一起拔高。
|
||||
- **事实问题（签字/印章有无）不靠文本提取断言**——PDF 手写/印章在 OCR 里看不到，必须看原件 PNG 或问 Maggie，再定级。
|
||||
- 第8维"签署是否有效"按此纪律执行：日期/签字缺失先核原件图，再按形式瑕疵定级，默认不拔高。
|
||||
|
||||
## 输出
|
||||
- 法律风险清单：每条风险标明依据条款、法律后果、对乙方影响、应对建议
|
||||
- 风险评级：🔴高 / 🟡中 / 🟢低
|
||||
- 写入汇总表"法律风险"信息（与"模版差异"信息**分列**，互不混淆）
|
||||
+51
@@ -0,0 +1,51 @@
|
||||
# 北翼玖玖/金飞达口径新增校准（2026-07-14）
|
||||
|
||||
## 一、输出标准锁定规则
|
||||
当用户明确说：
|
||||
- “17份合同的审查和汇总规则按照金飞达的来”
|
||||
- “格式输出也参照金飞达”
|
||||
|
||||
则本轮校区任务的输出标准应直接锁定为：
|
||||
1. **审查规则**按金飞达口径；
|
||||
2. **汇总规则**按金飞达结构；
|
||||
3. **格式输出**参照金飞达成品；
|
||||
4. 不再混用其他校区风格，除非用户再次改口。
|
||||
|
||||
## 二、板块组织主键
|
||||
当用户进一步明确：
|
||||
- “分类规则还是根据租赁物”
|
||||
- “同一租赁物相关的合同或文件，按照时间顺序排列”
|
||||
|
||||
则必须按以下顺序组织：
|
||||
1. **先按租赁物分组**；
|
||||
2. **每组内放入该租赁物的全部相关文件**（租赁、补充、退租、物业、说明等）；
|
||||
3. **组内再按时间顺序排列**；
|
||||
4. 不能按“租赁合同一堆、物业合同一堆”做机械分堆。
|
||||
|
||||
一句话总纲：
|
||||
> 内容规则看金飞达，编排逻辑看租赁物，组内顺序看时间。
|
||||
|
||||
## 三、进度汇报口径
|
||||
用户问“开始做了么？”时，如果已经做了以下任一动作：
|
||||
- 跑开工闸门；
|
||||
- 实际盘点文件；
|
||||
- 从容器/网盘拉取材料；
|
||||
- 实际读取 md / pdf / docx；
|
||||
- 启动并行提取或子任务；
|
||||
|
||||
则必须用“**已实际完成的动作清单 + 当前所处步骤**”回答，避免泛泛说：
|
||||
- “我开始处理了”
|
||||
- “我接下来继续做”
|
||||
- “我会推进”
|
||||
|
||||
更好的汇报结构：
|
||||
1. 已过什么闸门；
|
||||
2. 已实际盘出多少文件；
|
||||
3. 已读了哪些关键文件；
|
||||
4. 当前处于 Step0 / Step1 / Step2 哪一步；
|
||||
5. 下一步具体做什么。
|
||||
|
||||
## 四、适用场景
|
||||
- 南通新东方校区批量租赁梳理；
|
||||
- 用户要求“参照某已校准校区成品”执行的批量汇总任务；
|
||||
- 多文件、多租赁物的校区梳理任务。
|
||||
+116
@@ -0,0 +1,116 @@
|
||||
# 北翼玖玖 / 金飞达体例落表补充规则（2026-07-14）
|
||||
|
||||
## 触发场景
|
||||
当用户明确提出：
|
||||
- “17份合同根据租赁物，同一租赁物相关的合同或文件，按照时间顺序排列”
|
||||
- “17份合同的审查和汇总规则按照金飞达的来，格式输出也参照金飞达”
|
||||
- “先把列表梳理出来，再开始审查和汇总”
|
||||
|
||||
此时应按本文件执行，而不是直接套一般校区梳理流程。
|
||||
|
||||
---
|
||||
|
||||
## 一、四个锁定动作
|
||||
|
||||
### 1. 规则锁定
|
||||
审查口径、汇总逻辑、风险表达均按**金飞达**口径执行。
|
||||
|
||||
这意味着：
|
||||
- 不再自创“更像桃坞路/跃龙路”的混搭版
|
||||
- K列、整体段、文件说明的表达密度与风格优先看金飞达
|
||||
- 用户明确说“参照金飞达”后，不能再抽象回答“整体参考即可”，必须在实际落表时体现
|
||||
|
||||
### 2. 分组锁定
|
||||
必须先按**租赁物**归组，而不是按“租赁合同一组、物业合同一组、补充协议一组”机械分类。
|
||||
|
||||
同一租赁物相关的下列文件应放入同一组：
|
||||
- 租赁合同
|
||||
- 物业合同
|
||||
- 补充协议
|
||||
- 退租协议
|
||||
- 主体/权利义务转移协议
|
||||
- 账户更正说明 / 特殊情况说明
|
||||
- 其他直接影响该租赁物履行链条的文件
|
||||
|
||||
### 3. 排序锁定
|
||||
同组内按**时间顺序**排列。
|
||||
|
||||
若文件未明确写明签署日：
|
||||
- 先找正文中的原合同签订日
|
||||
- 再看起租日 / 生效日 / 退租日 / 权利义务转移日
|
||||
- 仍无法确定时，标注 **“签署日未载明”**，并按业务发生链条排序
|
||||
|
||||
禁止把“日期不明”当作不排序的理由。
|
||||
|
||||
### 4. 先列表、后审查
|
||||
如果用户先要求“把列表梳理出来”，必须先单独交付：
|
||||
|
||||
> **17份文件按租赁物 + 时间顺序的清单**
|
||||
|
||||
等用户确认排序后，再进入：
|
||||
- H / I / K / L 列审查
|
||||
- 汇总表落表
|
||||
|
||||
禁止一边分组未锁死、一边直接开表。
|
||||
|
||||
---
|
||||
|
||||
## 二、参考表落表纪律
|
||||
开始写单校区正式汇总表前，必须先实际取出并读取：
|
||||
|
||||
1. **当前校区最近版旧表**
|
||||
- 用于继承已确认结构、历史行、板块顺序
|
||||
2. **用户指定的参照校区表**（如金飞达）
|
||||
- 用于锁定输出格式和表达风格
|
||||
|
||||
### 读取参考表时，至少核对这些内容
|
||||
- 标题行写法
|
||||
- 项目信息行写法
|
||||
- 板块标题的组织方式
|
||||
- K列的整体评价与“〇 需注意”句式
|
||||
- L列的客观差异写法
|
||||
- 补充协议、说明文件在表中的落法
|
||||
|
||||
### 禁止事项
|
||||
- 不能只凭记忆说“参照金飞达格式”就直接开写
|
||||
- 不能只借鉴列头，不核对正文表达方式
|
||||
- 不能忽略旧表，直接从零发明一个“新版结构”
|
||||
|
||||
---
|
||||
|
||||
## 三、北翼玖玖类项目的落表顺序建议
|
||||
### 配套一/配套二这类多租赁物项目
|
||||
先按租赁物形成独立板块，再在板块内按时间顺序落：
|
||||
|
||||
- 主租赁合同 / 主物业合同
|
||||
- 费用减免补充协议
|
||||
- 退租协议
|
||||
- 主体/权利义务转移协议
|
||||
- 水电费/账户变更类补充协议
|
||||
- 特殊情况说明
|
||||
|
||||
也就是：
|
||||
> **先主合同，再补充，再退租，再转移，再收尾说明**
|
||||
|
||||
这样才能看出完整履行链条。
|
||||
|
||||
---
|
||||
|
||||
## 四、输出纪律
|
||||
当用户已经明确让你开始正式审查和汇总时，对外汇报进度必须区分：
|
||||
- **材料盘点/排序**
|
||||
- **实质审查（H/I/K/L）**
|
||||
- **正式落表**
|
||||
|
||||
不要把“已经开始整理材料”说成“已经开始正式汇总表写作”；也不要把“已有底稿”说成“已完成审查”。
|
||||
|
||||
准确说法应类似：
|
||||
- Step0已完成
|
||||
- Step1已完成
|
||||
- Step2进行中（哪几份已做H/I/K/L）
|
||||
- Step3是否已开始落xlsx
|
||||
|
||||
---
|
||||
|
||||
## 五、可复用的一句话原则
|
||||
> **金飞达定规则，租赁物定分组，时间线定顺序，列表确认后再落表。**
|
||||
@@ -0,0 +1,54 @@
|
||||
# K列/L列写法规则（Maggie 2026-07-08 纠正）
|
||||
|
||||
## K列提前退租分析
|
||||
|
||||
### 规则
|
||||
- 语言简单明了，不需要引用合同原文全文
|
||||
- 只标条款号，不贴原文段落
|
||||
- 分清不同条款的适用场景（如规范退租vs擅自退租）
|
||||
|
||||
### 示例
|
||||
❌ 冗余写法（被纠正）：
|
||||
```
|
||||
一、规范提前解约（第五条3款）：
|
||||
"租赁期间，乙方如需提前解租的，应当提前3个月书面告知甲方。在此情况下，乙方缴付的全部保证金应被甲方没收，且乙方应按一年总租金的30%向甲方支付违约金。"
|
||||
→ 提前3个月…合计约158,667元。
|
||||
```
|
||||
|
||||
✅ 正确写法：
|
||||
```
|
||||
一、规范提前解约（第五条3款）：提前3个月书面告知甲方 + 没收全部保证金56,667元 + 一年总租金30%违约金102,000元，合计约158,667元。
|
||||
二、擅自退租（第四条15款）：甲方可解除 + 没收保证金 + 30%违约金 + 不足弥补损失另行赔偿（无上限）+ 退还已预付未使用租金。
|
||||
注：5.3条为规范退出，后果封顶；4.15条为擅自退租，后果更重且无上限。
|
||||
```
|
||||
|
||||
### 根因
|
||||
不同条款法律后果不同（一个封顶一个无上限），混在一起写会误导客户对退出成本的判断。必须分开列。
|
||||
|
||||
---
|
||||
|
||||
## L列模版比对
|
||||
|
||||
### 规则（2026-07-08确立）
|
||||
- **说多少项就列多少项，不得遗漏**——写"40项差异"就必须全部列出40项
|
||||
- 不得写"主要差异"然后只列十几项（这是不诚实的）
|
||||
- 按07模版条款顺序逐条对照，用编号列表
|
||||
- 格式：`编号. 差异点名：07→XXX；本合同→XXX`
|
||||
- 差异项分按原合同章节分组（用【第X条·主题】标题）
|
||||
|
||||
### 操作方法
|
||||
1. 从07模版第一条读到最后一条（含附加条款）
|
||||
2. 每条问：本合同有没有？有的话一样还是不一样？
|
||||
3. 不一样的记一项，没有的记"无此条款"
|
||||
4. 数出总数，写在开头
|
||||
5. 逐项列出，不遗漏
|
||||
|
||||
---
|
||||
|
||||
## 附件标号"/"的处理
|
||||
|
||||
### 规则（2026-07-08确立）
|
||||
- 合同附件中填写"/"的字段表示**不适用/留空**
|
||||
- 例如营业额提成比例填"/%"＝该合同不适用营业额提成
|
||||
- 处理方式：**全面清除**——H列不写、I列不提、K列不分析该项风险、L列不比对该项差异
|
||||
- 不得写"比例未填明，存在后续争议风险"——这是错误理解，"/"不是"忘了填"而是"不适用"
|
||||
@@ -0,0 +1,137 @@
|
||||
# nantong-lease-audit Workflow 架构与批量运行指南
|
||||
|
||||
## 概述
|
||||
|
||||
`nantong-lease-audit` 是南通新东方租赁合同梳理的 uwf 状态机工作流（2026-06-27 建成并通过金飞达12份+人民中路2份测试）。
|
||||
|
||||
**架构**：
|
||||
```
|
||||
OCR(手动/脚本) → uwf thread start(每份合同) → Excel builder(汇总) → delivery-gate → 交付
|
||||
```
|
||||
|
||||
**与 contract-portfolio-analysis skill Step 0→7 的关系**：
|
||||
- workflow 替代 Step 2 的 delegate_task 动作B（模版比对）+ rule-analyzer（法律风险分析）+ data-extractor（结构化数据提取）
|
||||
- Step 0（盘点）、Step 1（OCR）、Step 3（Excel生成）、Step 6（交付闸门）仍由脚本完成
|
||||
- Step 4-5（校对+终审）在 workflow 完成后由人工做
|
||||
|
||||
## 4 角色定义
|
||||
|
||||
| 角色 | 耗时(典型) | 产出 |
|
||||
|------|-----------|------|
|
||||
| classifier | 60-90s | 校区、主体、合同类型、模版类型、面积、期限 |
|
||||
| template-diff | 180-200s | 与07模版逐条比对差异清单（供L列） |
|
||||
| rule-analyzer | 280-300s | 独立法律风险分析（供K列）+ 提前退租分析 |
|
||||
| data-extractor | 120-150s | 12列结构化数据 + H列四检 + 数学交叉验证 |
|
||||
|
||||
**单份合同总耗时：~10分钟**（4角色串行）。
|
||||
|
||||
## YAML Frontmatter 输出大小限制
|
||||
|
||||
uwf 的 YAML frontmatter 解析有大小限制。**当角色输出内容超过 ~2000 字符时，frontmatter 解析会失败**，导致 thread suspended。
|
||||
|
||||
**data-extractor 的解决方案**：
|
||||
- 将12列数据写入 `/tmp/nantong-lease-audit/row_data.json` 文件
|
||||
- YAML frontmatter 中只传文件路径：`output_file: /tmp/nantong-lease-audit/row_data.json`
|
||||
- 下游 Excel builder 从文件读取数据
|
||||
|
||||
**规则**：任何 uwf 角色的输出如果包含大量文本（>2000字符），应该：
|
||||
1. 将详细内容写入文件
|
||||
2. frontmatter 中只放文件路径和摘要字段
|
||||
3. 在 procedure 中明确指示 agent 必须写文件
|
||||
|
||||
## 批量启动模式
|
||||
|
||||
### batch_runner.sh 模板
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
UWF=/home/maggie/.hermes/node/bin/uwf
|
||||
WF=nantong-lease-audit
|
||||
CAMPUS=校区名
|
||||
OCR_DIR=/tmp/校区/ocr
|
||||
LOG=/tmp/校区/threads.log
|
||||
|
||||
FILES=("合同1" "合同2" ...) # 文件名（不含.md后缀）
|
||||
THREAD_IDS=()
|
||||
|
||||
for fname in "${FILES[@]}"; do
|
||||
md_path="${OCR_DIR}/${fname}.md"
|
||||
[ ! -f "$md_path" ] && continue
|
||||
|
||||
OUT=$($UWF thread start $WF -p "校区：${CAMPUS} | 合同文件：${fname} | OCR文本路径：${md_path} | 原始文件名：${fname}.pdf" 2>&1)
|
||||
TID=$(echo "$OUT" | python3 -c "import re,sys; t=sys.stdin.read(); m=(re.search(r'\"thread\"\s*:\s*\"([^\"]+)\"', t) or re.search(r'Thread\s+(\S+)', t)); print(m.group(1) if m else '')")
|
||||
|
||||
[ -n "$TID" ] && { THREAD_IDS+=("$TID"); sleep 8; } # 8s CAS settle
|
||||
done
|
||||
|
||||
# exec all threads
|
||||
for tid in "${THREAD_IDS[@]}"; do
|
||||
cd /home/maggie && $UWF thread exec "$tid" -c 20 --background 2>&1
|
||||
sleep 2
|
||||
done
|
||||
|
||||
# Wait loop with auto-resume of suspended threads
|
||||
while true; do
|
||||
ALL_DONE=true
|
||||
for tid in "${THREAD_IDS[@]}"; do
|
||||
STATUS=$(cd /home/maggie && $UWF thread list --all 2>/dev/null | grep "$tid" | awk '{print $3}')
|
||||
if [ "$STATUS" = "suspended" ] || [ "$STATUS" = "idle" ]; then
|
||||
cd /home/maggie && $UWF thread exec "$tid" -c 10 --background 2>&1
|
||||
sleep 5
|
||||
ALL_DONE=false
|
||||
elif [ "$STATUS" != "end" ] && [ "$STATUS" != "cancelled" ]; then
|
||||
ALL_DONE=false
|
||||
fi
|
||||
done
|
||||
$ALL_DONE && break
|
||||
sleep 60
|
||||
done
|
||||
```
|
||||
|
||||
**关键参数**：
|
||||
- `sleep 8` between thread starts：CAS settle 防止 phantom thread
|
||||
- `-c 20 --background`：一次跑20步（足够覆盖4角色）
|
||||
- 自动 resume suspended/idle threads（API 429 限流会导致 suspended）
|
||||
|
||||
### API 限流处理
|
||||
|
||||
14个并发 thread 会触发 API 429 (rate limiting)。表现：
|
||||
- rule-analyzer 或 data-extractor 阶段 suspended
|
||||
- 日志显示 "HTTP 429: Request rate increased too quickly"
|
||||
|
||||
**处理**：batch runner 的 wait loop 自动检测 suspended 状态并 resume。不需要手动干预。
|
||||
|
||||
### 生成 Excel
|
||||
|
||||
```bash
|
||||
# 单份合同
|
||||
python3 scripts/nantong-excel-builder.py <thread-id> <校区名> <xlsx路径> [文件名]
|
||||
|
||||
# 批量（所有已完成的thread）
|
||||
python3 scripts/batch-excel-builder.py <xlsx路径>
|
||||
```
|
||||
|
||||
## Thread Read Quota 陷阱
|
||||
|
||||
`uwf thread read` 默认 quota 只有 4000 字符，**远远不够读取完整输出**（template-diff 和 rule-analyzer 输出通常 10000-30000 字符）。
|
||||
|
||||
**必须用**：`uwf thread read <id> --quota 200000 --start`
|
||||
- `--quota 200000`：200K 字符足够
|
||||
- `--start`：包含 init step
|
||||
|
||||
Excel builder 脚本已内置此参数，不需要手动指定。
|
||||
|
||||
## 测试结果（2026-06-27）
|
||||
|
||||
| 校区 | 合同数 | 总耗时 | 完成率 |
|
||||
|------|--------|--------|--------|
|
||||
| 金飞达 | 12份 | ~60分钟 | 12/12 end |
|
||||
| 人民中路 | 2份 | ~60分钟 | 2/2 end |
|
||||
|
||||
14个并发 thread，API 限流导致部分 thread 需要 auto-resume，但全部完成。
|
||||
|
||||
## 已知问题
|
||||
|
||||
1. **Excel builder 解析精度**：各 thread 输出格式不完全一致，部分行的 C/F 列（合同类型/面积）可能为空
|
||||
2. **K/L 列内容**：data-extractor 的 K/L 列有时写占位符而非实际分析内容（已修复 workflow prompt，但需验证）
|
||||
3. **按租赁物分类排序**：batch builder 按 thread 完成顺序排列，不自动按"租赁物→合同性质→时间"排序——需要后续手动调整或增加排序逻辑
|
||||
@@ -0,0 +1,76 @@
|
||||
# Nextcloud File Upload Diagnostics
|
||||
|
||||
When files appear visible in the Nextcloud web UI but `find` on the container filesystem returns nothing, use this diagnostic sequence.
|
||||
|
||||
## Step 1: Check physical filesystem
|
||||
```bash
|
||||
docker exec <container> find '<nc_data_path>/<dir>' -type f -exec ls -la {} \;
|
||||
```
|
||||
Look for `.part` and `.ocTransferId*` files — these are incomplete upload fragments.
|
||||
|
||||
## Step 2: Rescan
|
||||
```bash
|
||||
docker exec -u www-data <container> php occ files:scan admin --path='<path>'
|
||||
```
|
||||
|
||||
## Step 3: Check Nextcloud logs
|
||||
```bash
|
||||
docker exec <container> tail -20 /var/www/html/data/nextcloud.log | python3 -c "
|
||||
import sys, json
|
||||
for line in sys.stdin:
|
||||
try:
|
||||
d = json.loads(line.strip())
|
||||
if d.get('level', 0) >= 2:
|
||||
print(f'[{d.get(\"time\",\"?\")}] {d.get(\"message\",\"\")[:300]}')
|
||||
except: pass
|
||||
"
|
||||
```
|
||||
Upload failures show: "预期文件大小为 X字节，实际...写入...Y字节"
|
||||
|
||||
## Step 4: Query MariaDB directly
|
||||
Find the DB password first:
|
||||
```bash
|
||||
docker exec <container> grep dbpassword /var/www/html/config/config.php
|
||||
```
|
||||
|
||||
Then query (use `mariadb` client, not `mysql`):
|
||||
```bash
|
||||
docker exec nextcloud-db-1 mariadb -u nextcloud -p<DB_PASSWORD_FROM_CONFIG> nextcloud -e "
|
||||
SELECT f.fileid, f.path, f.name, f.size, FROM_UNIXTIME(f.mtime) as modified
|
||||
FROM oc_filecache f
|
||||
WHERE f.path LIKE '%<search_term>%'
|
||||
ORDER BY f.path;
|
||||
"
|
||||
```
|
||||
|
||||
To find children of a directory (by parent fileid):
|
||||
```bash
|
||||
... -e "SELECT f.fileid, f.parent, f.path, f.name, f.size
|
||||
FROM oc_filecache f WHERE f.parent IN (<parent_id1>, <parent_id2>);"
|
||||
```
|
||||
|
||||
## Step 5: Clean up fragments
|
||||
```bash
|
||||
docker exec <container> find '<path>' -name '*.part' -delete
|
||||
docker exec <container> find '<path>' -name '*.ocTransferId*' -delete
|
||||
```
|
||||
|
||||
## Common root cause
|
||||
Cloudflare Tunnel (free tier) truncates large file uploads. The Nextcloud chunked upload protocol partially writes, then the connection drops. Repeated retries produce the same result.
|
||||
|
||||
**Solution**: Receive files via alternate channel (WeChat private message → `~/.hermes/cache/documents/`) and `docker cp` into Nextcloud.
|
||||
|
||||
## Quirk: docker cp'd file present + md5 correct, but `files:scan` returns 0 and DB row missing (2026-06-17)
|
||||
|
||||
After `docker cp` + `chown www-data` a new xlsx, `php occ files:scan admin --path='小Maggie协作区/.../世茂'` returned all-zeros (`Folders 0 Files 0`) and `oc_filecache` had **no row** for the file — so it was invisible in the web UI despite physically existing with a correct md5.
|
||||
|
||||
**Root cause**: `files:scan` keys off directory mtime; a fresh `docker cp` into an existing dir doesn't always bump the parent mtime, so the scanner skips it.
|
||||
|
||||
**Fix** (verified):
|
||||
```bash
|
||||
# 1. touch the parent dir to force an mtime change
|
||||
docker exec <container> bash -c "touch '/var/www/html/data/admin/files/<REL_PATH>'"
|
||||
# 2. rescan using the admin/files/ prefixed --path form (not the bare share path)
|
||||
docker exec -u www-data <container> php occ files:scan --path="admin/files/<REL_PATH>"
|
||||
```
|
||||
This returns `Updated N` and registers the file. **Always verify after upload** by querying `oc_filecache` for the filename (Step 4) — md5 match alone does NOT prove the file is indexed/visible. Don't tell the user "uploaded" until the DB row exists.
|
||||
+98
@@ -0,0 +1,98 @@
|
||||
# OCR与Workflow教训（2026-06-29 跃龙路校区）
|
||||
|
||||
## 1. 纯扫描件OCR：用ocrmypdf，不用raw tesseract
|
||||
|
||||
**问题**：跃龙路两份合同（租赁合同签字.pdf 11MB + 物业合同.pdf 1.4MB）都是纯扫描件（pdftotext提取0字符）。
|
||||
|
||||
**错误做法**：
|
||||
- 用tesseract直接OCR → 输出大量乱码（"ARR: MEER"应该是"名称：范存益"，"FAK."应该是"平方米"）
|
||||
- 试图用vision_analyze逐页核实 → 连续7次timeout，完全不可用
|
||||
- 转而手动delegate_task让subagent做vision → 部分成功部分失败，耗费大量token和时间
|
||||
|
||||
**正确做法**：
|
||||
```bash
|
||||
# 首选：ocrmypdf（有预处理管线，中文识别质量远高于raw tesseract）
|
||||
ocrmypdf -l chi_sim+eng --output-type pdf 原件.pdf OCR后.pdf
|
||||
# 然后提取文字层
|
||||
pdftotext OCR后.pdf output.md -layout
|
||||
```
|
||||
|
||||
**ocrmypdf vs raw tesseract对比**：
|
||||
|
||||
| 维度 | ocrmypdf | raw tesseract |
|
||||
|------|----------|---------------|
|
||||
| 预处理 | 自动去噪、矫正、二值化 | 无 |
|
||||
| 输出格式 | PDF+A（含文字层） | 纯文本 |
|
||||
| 中文识别质量 | 较好（仍有少量错误） | 很差（大量乱码） |
|
||||
| 适用场景 | 扫描件合同、手写签名页 | 印刷体清晰文档 |
|
||||
|
||||
**注意**：ocrmypdf输出仍有少量错误（空格分割、个别字误识），但整体可读性远优于raw tesseract。关键数字（金额、日期、面积）仍需人工或vision核实。
|
||||
|
||||
## 2. Vision工具timeout处理
|
||||
|
||||
**问题**：vision_analyze对大尺寸扫描件图片（>300KB）频繁timeout。压缩到100KB仍timeout。
|
||||
|
||||
**解决方案**：
|
||||
1. 先尝试压缩：`PIL.Image.resize((1000, ...))` + JPEG quality=50
|
||||
2. 如仍timeout，改用`browser_navigate(file://...)` + `browser_vision`
|
||||
3. 如browser_vision也timeout，用`delegate_task`让subagent做（subagent有独立timeout预算）
|
||||
4. 最终方案：用ocrmypdf替代vision做OCR，只在关键页面用vision核实
|
||||
|
||||
**最佳实践**：先用ocrmypdf做全量OCR，只对关键条款（租金金额、违约金比例、当事人名称）用vision逐页核实。不要试图vision每一页。
|
||||
|
||||
## 3. uwf workflow必须使用
|
||||
|
||||
**教训**：Maggie明确指出"跃龙路又没有按照workflow进行了"。手动做OCR+分析+建表=跳步+质量失控。
|
||||
|
||||
**正确流程**：
|
||||
1. 用ocrmypdf做OCR（或用已有校正OCR文本）
|
||||
2. 启动uwf `nantong-lease-audit` workflow（4角色：classifier→template-diff→rule-analyzer→data-extractor）
|
||||
3. 每个合同一个thread，可并行启动
|
||||
4. 等待所有thread完成（约10-15分钟/合同）
|
||||
5. 读取JSON输出喂给`single-campus-builder.py`
|
||||
|
||||
**uwf启动命令**：
|
||||
```bash
|
||||
# 启动thread
|
||||
uwf thread start nantong-lease-audit -p "校区：X | 合同文件：Y.pdf | OCR文本路径：/tmp/xxx/Y_ocr.md | 原始文件名：Y.pdf"
|
||||
# 后台执行（最多10步）
|
||||
uwf thread exec <thread-id> --count 10 --background
|
||||
# 检查进度
|
||||
uwf thread show <thread-id>
|
||||
# 读取结果
|
||||
uwf thread read <thread-id> --quota 8000
|
||||
```
|
||||
|
||||
**JSON输出路径**：`/tmp/nantong-lease-audit/<校区>-row-data.json`
|
||||
|
||||
## 4. delivery-gate.py文件名模式
|
||||
|
||||
**G1检查**：寻找`模版比对-*.md`格式的文件名（不是`*-template-diff.md`）。
|
||||
- ✅ 正确：`模版比对-跃龙路租赁合同.md`
|
||||
- ❌ 错误：`跃龙路-template-diff.md`
|
||||
|
||||
**修复**：workflow产出的template-diff文件需要复制或重命名：
|
||||
```bash
|
||||
cp /tmp/nantong-lease-audit/跃龙路-template-diff.md /tmp/<校区>/模版比对-跃龙路租赁合同.md
|
||||
```
|
||||
|
||||
**G5检查**：`数据行数≥3`是默认值。对于只有2份合同的校区（租赁+物业），这是**正常情况**，不算失败。如果G5报错但确认校区确实只有2份合同，可安全忽略此项。
|
||||
|
||||
## 5. 物业合同JSON被覆盖
|
||||
|
||||
**问题**：两个合同共用同一个uwf workflow名称（`nantong-lease-audit`），data-extractor角色默认写入`/tmp/nantong-lease-audit/row_data.json`。如果两个thread同时跑，后完成的会覆盖先完成的。
|
||||
|
||||
**解决方案**：
|
||||
- 物业合同没有对应的07模版，不需要走template-diff角色
|
||||
- 物业合同的K列和L列内容需要手动填充（从OCR文本+workflow摘要中提取）
|
||||
- 或者：在builder脚本中直接从OCR文本和物业合同分析摘要手动构造物业数据行
|
||||
|
||||
## 6. ocrmypdf产出仍需OCR完整性检查
|
||||
|
||||
ocrmypdf产出文字层后，用pdftotext提取的.md文件可能仍有少量乱码。需要：
|
||||
1. 运行`ocr-integrity-check.py`检查乱码
|
||||
2. 如果检查失败（检测到公司名乱码等），用vision核实关键页
|
||||
3. 核实后手动修正.md文件中的乱码
|
||||
4. 重新运行检查直到通过，生成`step1.verified` checkpoint
|
||||
|
||||
**快捷方案**：如果之前已有vision校正过的.md文件（本次session中手动校正的），直接复用，不需要重新跑ocrmypdf+检查流程。
|
||||
@@ -0,0 +1,53 @@
|
||||
# OCR Troubleshooting — Binarization Fallback
|
||||
|
||||
## Problem
|
||||
Some scanned PDF pages return empty text when processed with standard `ocrmypdf` + `pdftotext` or `tesseract`. The pages appear to have content visually but the OCR engine produces zero characters.
|
||||
|
||||
## Diagnosis
|
||||
Check if tesseract output is empty:
|
||||
```bash
|
||||
tesseract page.jpg stdout -l chi_sim | wc -c
|
||||
# If 0 chars → page needs binarization
|
||||
```
|
||||
|
||||
Check image statistics to confirm it's not truly blank:
|
||||
```python
|
||||
from PIL import Image
|
||||
import numpy as np
|
||||
arr = np.array(Image.open('page.jpg').convert('L'))
|
||||
print(f'mean={arr.mean():.0f} std={arr.std():.0f}')
|
||||
# If std > 25 → image has content, OCR failure is processing issue
|
||||
```
|
||||
|
||||
## Fix: Binarization (threshold=140)
|
||||
Convert to pure black-and-white before re-running tesseract:
|
||||
|
||||
```python
|
||||
from PIL import Image
|
||||
import numpy as np
|
||||
|
||||
img = Image.open('page.jpg').convert('L')
|
||||
arr = np.array(img)
|
||||
threshold = 140 # Adjust if needed (120-160 range)
|
||||
arr = (arr < threshold).astype(np.uint8) * 255
|
||||
Image.fromarray(arr).save('page_bw.png')
|
||||
```
|
||||
|
||||
Then run tesseract on the binarized image:
|
||||
```bash
|
||||
tesseract page_bw.png stdout -l chi_sim
|
||||
```
|
||||
|
||||
## Vision Tool Timeout Fix
|
||||
If `vision_analyze` times out on scanned pages:
|
||||
1. Check `~/.hermes/config.yaml` → `vision.timeout` (default 30s is too short for large images)
|
||||
2. Increase to 90s: `sed -i 's/timeout: 30/timeout: 90/' ~/.hermes/config.yaml`
|
||||
3. Compress images before sending: resize to 850x1100, quality=60 (~80-120KB per page)
|
||||
4. Send one page at a time, not multiple simultaneously
|
||||
|
||||
## Workflow for Scanned Contracts
|
||||
1. `ocrmypdf -l chi_sim --skip-text input.pdf output_ocr.pdf`
|
||||
2. `pdftotext output_ocr.pdf - | wc -c` — check if text layer exists
|
||||
3. If empty pages: `pdftoppm -jpeg -r 300 input.pdf pages/page` → binarize → tesseract
|
||||
4. Combine: original tesseract pages + binarized pages into single .md file
|
||||
5. For remaining garbled fields: use `vision_analyze` on compressed page images
|
||||
@@ -0,0 +1,47 @@
|
||||
# OCR乱码检测与核实流程（凤凰文化0701教训固化）
|
||||
|
||||
## 背景教训
|
||||
|
||||
凤凰文化广场合同第十条10.2，OCR把：
|
||||
> "提出合同解除的一方，同时应向对方承担初年年租金的【20】%作为违约金。租赁租金及其他费用结算至合同解除日。"
|
||||
|
||||
读成了乱码：
|
||||
> "oe方,同Se【2024】年【10】月【15】日结算至合同解除日"
|
||||
|
||||
由于只对8.4-8.9做了vision核实，跳过了10.2的乱码段，导致：
|
||||
- 整段违约金条款丢失
|
||||
- 审查结论错误（"无违约金"→实际"有20%违约金"）
|
||||
- 返工
|
||||
|
||||
## 强制流程
|
||||
|
||||
```
|
||||
Step 1 OCR完成
|
||||
↓
|
||||
python3 scripts/ocr-garble-detect.py <file.md>
|
||||
↓
|
||||
🔴 高危乱码（无意义英文片段/中英混杂碎片）
|
||||
→ 定位PDF页码（line number / 每页约50行估算）
|
||||
→ vision精读对应页面
|
||||
→ 记录修正内容
|
||||
→ 修改OCR文本或建修正说明文件
|
||||
↓
|
||||
🟡 疑似乱码（中文占比低/异常符号）
|
||||
→ 区分：纯数字表格=正常；邮箱/账号=正常
|
||||
→ 真正乱码→同上vision核实
|
||||
↓
|
||||
全部消灭 → 进入 Step 2
|
||||
```
|
||||
|
||||
## 关键判断：哪些看似正常实则是乱码
|
||||
|
||||
| 表象 | 陷阱 | 正确做法 |
|
||||
|------|------|----------|
|
||||
| "Se【2024】年【10】月【15】日" | 看似日期，实则是违约金条款乱码 | 发现中英混杂+不合语境→必须vision |
|
||||
| "0.4 a/R 元/㎡/月" | 看似单位，"a/R"是"天"的乱码 | 金额/单位附近乱码→vision确认单位 |
|
||||
| "oe方,同" | 短乱码容易被跳过 | 即使只有几个字符异常也必须核实上下文完整段落 |
|
||||
|
||||
## 核心原则
|
||||
|
||||
**不是"看哪里乱就修哪里"，而是脚本扫全文自动标红，强制逐条过一遍。**
|
||||
选择性核实 = 选择性遗漏 = 必然返工。
|
||||
@@ -0,0 +1,53 @@
|
||||
# OCR全文持久化规则（2026-07-02 Maggie明确要求）
|
||||
|
||||
## 核心规则
|
||||
提取+校对好的合同全文**必须保存为 `<原文件名>_全文.md`**，放在原PDF同目录下（Nextcloud对应校区文件夹）。
|
||||
|
||||
## 目的
|
||||
后续任何任务（起草函件、查条款、更新汇总表、模版比对）直接 read_file 秒读，避免重复15-20分钟的Vision/OCR工作。
|
||||
|
||||
## 触发时机
|
||||
每次对扫描件PDF进行OCR/Vision全文提取后，在完成主任务之前，先保存全文md文件。
|
||||
|
||||
## 文件位置示例
|
||||
```
|
||||
世茂/青少/世茂新租赁合同.pdf ← 原文件
|
||||
世茂/青少/世茂新租赁合同_全文.md ← 持久化的提取结果
|
||||
世茂/青少/世茂物业合同.pdf
|
||||
世茂/青少/世茂物业合同_全文.md
|
||||
世茂/高中/3023新东方租赁合同-双签版.pdf
|
||||
世茂/高中/3023新东方租赁合同-双签版_全文.md
|
||||
```
|
||||
|
||||
## 格式
|
||||
```markdown
|
||||
# [文档标题] 全文
|
||||
|
||||
（提取方式：Vision校对 / OCR提取，来源：filename.pdf，提取日期：YYYY-MM-DD）
|
||||
|
||||
--- 第1页 ---
|
||||
|
||||
[page content]
|
||||
|
||||
--- 第2页 ---
|
||||
|
||||
[page content]
|
||||
...
|
||||
```
|
||||
|
||||
## 质量优先级
|
||||
1. **Vision逐页提取**（最佳）：delegate_task → vision_analyze每页 → 合并保存
|
||||
2. **ocrmypdf**（次选）：`ocrmypdf --force-ocr -l chi_sim+eng` → pymupdf提取
|
||||
3. 不接受：仅靠tesseract raw（中文法律文本乱码率太高）
|
||||
|
||||
## 操作步骤
|
||||
1. Vision/OCR提取完成后，写入 `/tmp/` 临时文件
|
||||
2. `sudo cp /tmp/file.md /home/maggie/nextcloud/data/data/admin/files/...`
|
||||
3. `sudo chown www-data:www-data <target>`
|
||||
4. `sudo docker exec -u www-data nextcloud-nextcloud-1 php occ files:scan --path=<path>`
|
||||
|
||||
## 与汇总表的关系
|
||||
- 汇总表（`*-梳理-*.xlsx`）是**结构化审查结果**（12列）
|
||||
- 全文md是**原始文本存档**（逐页）
|
||||
- 两者互补：汇总表用于快速查信息，全文md用于精确引用条款原文
|
||||
- 后续新增校区开工时，先检查是否已有全文md，有则直接读取不必重跑Vision
|
||||
@@ -0,0 +1,122 @@
|
||||
# OCR 费率符号核对配方（‰ vs %，扫描件）
|
||||
|
||||
**适用**：扫描件合同里逾期违约金/滞纳金/利率等**日费率**字段，OCR 文本出现 `%`/`‰`/`0.5`/`1`/`2` 等，量级可疑（年化超约100%就该警觉）。这是 10× 量级错误的高发点（千分号 ‰ 被误识成百分号 %）。
|
||||
|
||||
## 核心原则
|
||||
1. **绝不信单次 OCR 的小符号**。扫描件 OCR 对 ‰/% 经常判错。
|
||||
2. **双跑交叉**：整页 OCR vs 裁图放大重 OCR。**两次不一致 = 机器判不准已证明 → 升级人工**，不在两个机器结果里挑一个。
|
||||
3. **升级人工带放大裁图**（`MEDIA:` 发 Maggie 肉眼终判那一个像素符号），不甩空问题。
|
||||
4. 机器判不准时，交付物先标 `〔OCR数值，单位以PDF原件为准〕`，**不武断定值**。
|
||||
|
||||
## 量级常识闸门（先口算，再核符号）
|
||||
- 日费率写进表前先口算年化：`每日 X × 365`。
|
||||
- **年化超约 100% 就该警觉**：每日 2% = 年化 730%（荒谬）；每日千分之2(2‰) = 年化 73%（合理）。
|
||||
- 逾期违约金/滞纳金日费率正常落在 **万分之几 ~ 千分之几**（年化约 18%~73%）。见到"每日1%、每日2%"先疑 ‰ 被误识成 %。
|
||||
- 折年化别算错：0.5%/日 = 年化 182.5%（不是18.25%）；万分之5/日才是年化 18.25%。
|
||||
|
||||
## 命令级配方
|
||||
|
||||
### 1. 定位费率条款在第几页（扫描件 PDF 文本层通常为空，必须 OCR 切图）
|
||||
切图一般已在 OCR 阶段产出（`<合同名>_imgs/p<N>.png`，约 200dpi / 1654×2340）。按章节缩小页范围（如"乙方违约责任/第九条"），对候选页跑 tesseract，命中含费率特征词（`应付未付`/`滞纳金`/`延误一日`/`每延误`）的页：
|
||||
|
||||
```python
|
||||
import subprocess, os
|
||||
def ocr(img, psm=6):
|
||||
return subprocess.run(["tesseract", img, "stdout", "-l", "chi_sim+eng", "--psm", str(psm)],
|
||||
capture_output=True, text=True).stdout or ""
|
||||
# 对 <imgs>/p{N}.png 跑，命中含"滞纳金"+"延误"+"应付未付"的页即 9.2 所在页
|
||||
```
|
||||
|
||||
### 2. 裁出费率行、放大 3–4 倍、多 psm 重 OCR
|
||||
整页全文 OCR 找到费率行的行号占比，按比例裁该纵向区段（不依赖 TSV 分词，更稳）：
|
||||
|
||||
```python
|
||||
from PIL import Image
|
||||
lines = [l for l in ocr(img).split("\n") if l.strip()]
|
||||
idx = next(i for i,l in enumerate(lines) if ("应付未" in l or "付金额" in l or "加付滞纳金" in l))
|
||||
im = Image.open(img); W,H = im.size
|
||||
frac = idx/len(lines)
|
||||
y0, y1 = max(0,int(H*(frac-0.06))), min(H,int(H*(frac+0.10)))
|
||||
crop = im.crop((0,y0,W,y1)).resize((W*3,(y1-y0)*3), Image.LANCZOS)
|
||||
crop.save("/tmp/_rate_crop/<条款>.png")
|
||||
# 对裁图再多 psm 重 OCR：for psm in (7,6,11,13): ocr(crop_path, psm)
|
||||
```
|
||||
|
||||
### 3. 判读
|
||||
- 两次（整页 vs 裁图）符号**一致** → 采信，去掉待核标记，写进表。
|
||||
- 两次**不一致**（如 `0.5%` vs `0.5‰`，或 `1%` vs `1‰`）→ 机器判不准已坐实 → 走第4步。
|
||||
|
||||
### 4. 升级人工（带证据）
|
||||
- 把第2步裁好的放大 PNG 用 `MEDIA:/tmp/_rate_crop/<条款>.png` 发 Maggie，问"数字后这个符号是 % 还是 ‰"。
|
||||
- Maggie 定值后，把交付表里该条从 `〔待核〕` 改成确定值，闭环。
|
||||
|
||||
## ✅ vision_analyze 已配好——符号终判的主路径（2026-06-22 人民中路实证）
|
||||
vision 工具已由技术支持配好可用。**现在符号判不准时，主路径是先自己 `vision_analyze` 看裁好的整页/裁图终判**，能自核就不必裁图发 Maggie；自核仍拿不准的才交人。crop-OCR 多 psm 仍可能裁偏（本次裁两次都偏到隔壁条款），vision 看整页反而一步到位。
|
||||
|
||||
**🔑 vision 终判的精髓 = 让它做「同页符号交叉对比」**，不要只问"这是%还是‰"。提问里点名让它拿**同一页别处确定的符号**作参照：
|
||||
> "请找到第十条4款的违约金率符号，并和同一页第2款/第3款的「10%」对比——4款那个符号右下方是一个圆圈(%)还是两个圆圈(‰)？"
|
||||
|
||||
实证：人民中路租赁第十条4款，vision 自动拿同页第2/3款的"10%"百分号比对，确认4款符号"明显比%更宽、右下方两个圆圈"= **0.1‰**（年化3.65%）；物业第九条2款同法确认 **0.5%**（年化182.5%）。同页对比比孤立看一个符号可靠得多——人眼/模型判 ‰vs% 都靠"和已知符号比宽窄、数圆圈个数"。
|
||||
|
||||
**仍要带量级闸门复核**：vision 给的符号要和年化常识对得上（0.1‰=3.65%对逾期违约金偏低但合理；若 vision 说某逾期费率是"每日5%"=年化1825%就该反问）。vision 偶发 `Connection error`，重试即可（本次租赁那张第一次 Connection error、重试成功）。
|
||||
|
||||
## 🔴 发 vision 前必须先压缩图片——防超时（2026-06-23 实测确立）
|
||||
当前 vision 配置：`gemini-3.5-flash`（经 litellm-sora 代理），**timeout 仅 30 秒**。实测：
|
||||
- **2.5MB 原图（200dpi PNG，1654×2340）→ Request timed out 失败**
|
||||
- **压到 ~385KB（宽1100px JPG q85）→ 秒过、读得准**
|
||||
所以**铁律：任何图发 vision_analyze 前，先 resize 到宽 ≤1100px、转 JPG，体积压到 ~300–400KB**：
|
||||
```python
|
||||
from PIL import Image
|
||||
im = Image.open(src)
|
||||
w,h = im.size; nw = 1100; nh = int(h*nw/w)
|
||||
im.resize((nw,nh), Image.LANCZOS).convert("RGB").save(dst, quality=85)
|
||||
```
|
||||
- 压缩后清晰度仍足够 vision 数圆圈、读符号、判版面（实测 0.1‰/% 区分无误）。
|
||||
- 超时是"图太大传不完"，不是模型不行——别因一次 timeout 就判 vision 不可用，先压图重试。
|
||||
- 单次失败重试 1–2 次（偶发 Connection error）；连续失败才退兜底（tesseract 双跑+裁图发 Maggie）。
|
||||
|
||||
## ✅ vision 能力边界 —— 定位"精核兜底"，不是"批量主力"（2026-06-23 实测确立）
|
||||
vision 在差质量扫描件（文字层=0 的纯扫描 PDF，正是本项目 PDF 识别出问题的根因）上**实测够用**，但用对位置：
|
||||
- **✅ 适合（单页/单点精读核对）**：① 费率符号 ‰/% 同页交叉终判 ② 标红颜色是否真红（配 PIL 像素检测）③ 版面横向/纵向截断、跨页切断 ④ 关键数字（金额/日期/比例）人工复核兜底。
|
||||
- **❌ 不适合（批量全文提取）**：8 页合同全文 OCR 不要逐页喂 vision——一页一次调用、还可能超时，慢且不划算。**全文底料仍用传统 OCR（deepseek-ocr / tesseract）跑一遍**。
|
||||
- **最佳架构（已被实测验证 = 现行 skill 设计）**：传统 OCR 出全文底料 → vision 精核可疑点/符号/版面。两层各司其职，不互相替代。
|
||||
- **交付前 vision 三查清单**（图都先压缩）：① 文字完整（pdftotext 拍平 grep）② 视觉呈现（vision 看渲染图：截断/错位/红色）③ 符号量级（vision 同页对比 + 年化闸门）。三查全过再交。
|
||||
|
||||
## 退路（vision 万一又不可用）
|
||||
- 若 `vision_analyze` 报 `No LLM provider configured for task=vision` 或持续连不上：退到 **tesseract 双跑 + 裁图发 Maggie**（上面命令级配方）。
|
||||
- 这是兜底，不是主路径——vision 已配好，优先自核。
|
||||
|
||||
## 像素分析绕过 vision 核「单元格字体颜色」（2026-06-22 世茂实证）
|
||||
|
||||
**场景**：交付的标红 xlsx 改完，要确认「某条是不是红字 / 整格有没有误染红」，但 vision 未配、自己看不了图。**不必干等 WeiWei 配 vision**——x2t 渲染成 PDF→PNG 后，用 PIL+numpy 直接读像素统计红/黑占比，机器就能给出客观判断。
|
||||
|
||||
```python
|
||||
from PIL import Image
|
||||
import numpy as np
|
||||
img = Image.open("渲染页.png").convert("RGB")
|
||||
arr = np.array(img)
|
||||
r,g,b = arr[:,:,0].astype(int), arr[:,:,1].astype(int), arr[:,:,2].astype(int)
|
||||
red_mask = (r>120)&(g<90)&(b<90)&(r-g>50)&(r-b>50) # 明显红字
|
||||
black_mask = (r<90)&(g<90)&(b<90) # 黑字
|
||||
# 逐 20px 水平带判主色，能定位「哪几行是红的」，比整页占比更准
|
||||
for y in range(0, arr.shape[0], 20):
|
||||
br, bk = red_mask[y:y+20].sum(), black_mask[y:y+20].sum()
|
||||
if br+bk < 100: continue # 跳过空白带
|
||||
print(y, "红" if br>bk else "黑")
|
||||
```
|
||||
|
||||
- **判读**：红字带 ≈ 该红的条数 → 正常；红字带远多于黑字带 → 整格误染红，要查 XML。
|
||||
- ⚠️ **但像素只是辅助**：渲染会让部分红 rPr 不生效、红黑混杂，像素比例不绝对。**XML 层的精确计数才是真相源**——核颜色最终回 `sharedStrings.xml` 数 `rgb="FFFF0000"`（见下条 bug 教训）。像素分析用于「快速判断有没有大面积异常」，精确定位用 XML。
|
||||
|
||||
## ⚠️ 颜色计数 bug：精确匹配 `rgb="FFFF0000"`，绝不子串匹配（2026-06-22 教训）
|
||||
|
||||
数红色 run 时**必须精确正则** `re.findall(r'rgb="FFFF0000"', xml)`，**绝不能** `'FF0000' in etree.tostring(rpr)`——黑色 `FF000000` 里也含子串 `F0000`，子串匹配会把每个黑字 run 误判成红字，导致长单元格（多 run 的 K列风险格）被误报「整格泛红」。世茂栽点：`red_run_count` 一度报 K8/K11/A16 各 8/15/20 个红 run、全表 47 红，虚惊一场要返工；精确匹配后真红就 6 处全对（4个付款提示 H列 + K8第1条 + A16第6条「需核实」句）。`edit-redmarked-xlsx.py` 的 `red_run_count` 已修为精确匹配。**任何「整格泛红」的判断，先用精确 `rgb="FFFF0000"` 复核再下结论。**
|
||||
|
||||
## 实证（世茂校区，2026-06-18）
|
||||
| 条款 | 整页OCR | 裁图重OCR | 判定 |
|
||||
|---|---|---|---|
|
||||
| 租赁14.1 逾期付款违约金 | `2%` | （上午已核）`千分之2` | ✅ 确认 **2‰**（年化73%合理；2%=年化730%荒谬） |
|
||||
| 青少物业9.2 滞纳金 | `0.5%`(读成"0.5吃") | `0.5‰` | ⚠️ 打架 → 裁图发 Maggie 终判 |
|
||||
| 高中物业9.2 滞纳金 | `1%` / `1‰`（两跑不同） | `1‰` | ⚠️ 打架 → 裁图发 Maggie 终判 |
|
||||
|
||||
教训：四份合同同批扫描，OCR 在 ‰/% 上三跑三种组合。任何一条都不能拿单次 OCR 定稿。
|
||||
@@ -0,0 +1,67 @@
|
||||
# OCR复用 + OnlyOffice渲染技巧
|
||||
|
||||
## OCR复用（跳过Step 1提取）
|
||||
|
||||
前session已提取的 `*_全文.md` / `*_全文_OCR.md` 文件若已存放于Nextcloud校区目录，
|
||||
可直接复用，无需重新OCR。
|
||||
|
||||
### 确认步骤：
|
||||
```bash
|
||||
# 1. 列出已有MD文件
|
||||
sudo docker exec nextcloud-nextcloud-1 find "<校区容器路径>" -name "*.md" -type f | sort
|
||||
|
||||
# 2. 逐份对照PDF清单——每份PDF都有对应MD即可跳过提取
|
||||
# 3. docker cp 到本地
|
||||
sudo docker exec nextcloud-nextcloud-1 cat "<容器内MD路径>" > /tmp/<工作目录>/<文件名>.md
|
||||
|
||||
# 4. 仍须跑 garble 检测确认质量
|
||||
python3 ~/.hermes/skills/legal/contract-portfolio-analysis/scripts/ocr-garble-detect.py <文件>.md
|
||||
|
||||
# 5. 高危乱码 vision 核实 → 全灭后进 Step 2
|
||||
```
|
||||
|
||||
### 世茂校区实证（2026-07-02）：
|
||||
4份合同全部已有MD提取文件，直接跑garble检测：
|
||||
- 青少租赁：15处高危（大部分在目录页OCR噪声+附件表格），关键条款vision验证通过
|
||||
- 青少物业：6处高危
|
||||
- 高中租赁：18处高危
|
||||
- 高中物业：2处高危
|
||||
|
||||
关键金融数据（面积/租金/税率）通过vision交叉验证确认准确后，整体Step 1节省约20分钟。
|
||||
|
||||
---
|
||||
|
||||
## OnlyOffice x2t 渲染 — 写XML的权限问题
|
||||
|
||||
### 问题：
|
||||
`docker exec ... bash -c 'cat > /tmp/convert.xml << EOF ...'` 经常报 "Permission denied"，
|
||||
因为容器内 `/tmp` 可能被前次操作留下的 root 文件占用。
|
||||
|
||||
### 解决方案：用 Python 写文件
|
||||
```bash
|
||||
sudo docker exec nextcloud-onlyoffice-1 rm -f /tmp/input.xlsx /tmp/output.pdf /tmp/convert.xml
|
||||
sudo docker cp <本地xlsx> nextcloud-onlyoffice-1:/tmp/input.xlsx
|
||||
|
||||
sudo docker exec nextcloud-onlyoffice-1 python3 -c "
|
||||
with open('/tmp/convert.xml', 'w') as f:
|
||||
f.write('''<?xml version=\"1.0\" encoding=\"utf-8\"?>
|
||||
<TaskQueueDataConvert xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\">
|
||||
<m_sFileFrom>/tmp/input.xlsx</m_sFileFrom>
|
||||
<m_sFileTo>/tmp/output.pdf</m_sFileTo>
|
||||
<m_nFormatTo>513</m_nFormatTo>
|
||||
</TaskQueueDataConvert>''')
|
||||
"
|
||||
|
||||
sudo docker exec nextcloud-onlyoffice-1 /var/www/onlyoffice/documentserver/server/FileConverter/bin/x2t /tmp/convert.xml
|
||||
sudo docker cp nextcloud-onlyoffice-1:/tmp/output.pdf <本地输出路径>
|
||||
```
|
||||
|
||||
### 关键点：
|
||||
- 先 `rm -f` 清理旧文件避免权限冲突
|
||||
- 用 `python3 -c` 写文件比 bash heredoc 可靠（避免容器内 shell 权限/重定向问题）
|
||||
- `m_nFormatTo=513` = PDF格式
|
||||
|
||||
### 已知限制：
|
||||
- x2t渲染PDF时，白色字体在深色背景上可能不显示（字体嵌入问题）
|
||||
- 这不影响xlsx本身——用户在OnlyOffice中打开时白色文字正常显示
|
||||
- 视觉验证时注意：标题行的白色文字不显示≠格式错误，属x2t渲染特性
|
||||
@@ -0,0 +1,61 @@
|
||||
# OCR + Vision 双引擎校对流程 (跃龙路经验 0703)
|
||||
|
||||
## 问题背景
|
||||
扫描件PDF用ocrmypdf提取的文字有大量识别错误：
|
||||
- 数字被乱码覆盖（如金额行变成 `SH CAL bi` 等）
|
||||
- 合同条款编号错位
|
||||
- 签章区域干扰正文识别
|
||||
- "扫描全能王"水印被当正文
|
||||
|
||||
## 推荐流程
|
||||
|
||||
### Step 1: OCR提取（作为初始底稿）
|
||||
```bash
|
||||
ocrmypdf --force-ocr -l chi_sim+eng --sidecar /tmp/XXX-ocr.txt input.pdf output.pdf
|
||||
```
|
||||
|
||||
### Step 2: PDF转图片（逐页）
|
||||
```python
|
||||
import fitz
|
||||
doc = fitz.open('input.pdf')
|
||||
for i in range(len(doc)):
|
||||
page = doc[i]
|
||||
pix = page.get_pixmap(dpi=200)
|
||||
pix.save(f'/tmp/XXX-p{i+1}.png')
|
||||
```
|
||||
|
||||
### Step 3: Vision逐页核实（关键数据页）
|
||||
- 优先核实：金额页（租金标准/各年租金/押金/物业费）
|
||||
- 明确问题：指定需要逐字抄写的数据类型
|
||||
- 每页一个vision_analyze调用，问题要具体
|
||||
|
||||
### Step 4: 数学交叉验证
|
||||
验算所有可推导的数字关系：
|
||||
- 年递增：base × (1+rate)^(n-1) = 第n年租金
|
||||
- 免租分摊：总额 ÷ 年数 = 每年减免
|
||||
- 减免后 = 合同租金 - 年减免额
|
||||
- 单价反推：年总额 ÷ 365 ÷ 面积 = 元/㎡/天
|
||||
- 物业费：单价 × 面积 × 12 = 年总额
|
||||
|
||||
### Step 5: 整理md全文
|
||||
- 以vision核实的数据为准（非OCR原始文本）
|
||||
- 保留合同结构（条款编号+标题）
|
||||
- 签章信息如实记录（印章文字、编号）
|
||||
- 空白/未填写项标注"（未填写）"
|
||||
- 文件存放：同一文件夹，命名格式 `XXX合同_全文.md`
|
||||
|
||||
## OCR常见错误类型（跃龙路实例）
|
||||
| 原文 | OCR错误 |
|
||||
|------|---------|
|
||||
| 崇川区 | 贮川区 |
|
||||
| 范存益 | 无法识别 |
|
||||
| 6230520420020988877 | 6930520420020988877 |
|
||||
| 361017.12 | 3610417.142 |
|
||||
| 平方米 | FAK |
|
||||
| 乙方 | EM |
|
||||
| 续租 | SA |
|
||||
|
||||
## 效率提示
|
||||
- 6页以内的合同：全部逐页vision（最可靠）
|
||||
- 6页以上：OCR为底稿 + 关键数据页vision + 数学验算
|
||||
- 所有金额/日期/面积/费率必须经vision确认，不能只信OCR
|
||||
+73
@@ -0,0 +1,73 @@
|
||||
# OnlyOffice xlsx 渲染自查 + 行高 409.5 上限真相
|
||||
|
||||
> 用途：交付前用 **Maggie 实际看的引擎**（OnlyOffice，非 LibreOffice）把汇总表 xlsx 渲染成 PDF/图片做视觉自查；并厘清"长内容行高调不上去"的根因，避免重复踩坑浪费时间。
|
||||
> 来源：2026-06-17 万达行高验证 + 世茂重做渲染自查。
|
||||
|
||||
## 一、x2t 渲染 xlsx → PDF（用 OnlyOffice 引擎，保真度最高）
|
||||
|
||||
OnlyOffice 文档转换器 `x2t` 在容器 `nextcloud-onlyoffice-1` 内，是 Maggie 在线编辑/查看时的同款引擎。比 `libreoffice --headless --convert-to pdf` 更能反映她看到的真实效果。
|
||||
|
||||
**format code**：513 = PDF。
|
||||
|
||||
**完整配方（已验证可用）**：
|
||||
```bash
|
||||
# 1. 容器内建可写目录（默认root建后chmod 777，让ds用户能写pdf输出）
|
||||
docker exec nextcloud-onlyoffice-1 bash -c 'rm -rf /tmp/sx; mkdir -p /tmp/sx; chmod 777 /tmp/sx'
|
||||
|
||||
# 2. 主机预先写好转换配置 xml（关键：不要在容器内用 > 重定向，会因权限失败），cp进去
|
||||
# /tmp/s_convert.xml 内容：
|
||||
# <?xml version="1.0" encoding="utf-8"?>
|
||||
# <TaskQueueDataConvert xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
|
||||
# <m_sFileFrom>/tmp/sx/s.xlsx</m_sFileFrom>
|
||||
# <m_sFileTo>/tmp/sx/s.pdf</m_sFileTo>
|
||||
# <m_nFormatTo>513</m_nFormatTo>
|
||||
# <m_bIsNoBase64>true</m_bIsNoBase64>
|
||||
# </TaskQueueDataConvert>
|
||||
docker cp /path/to/target.xlsx nextcloud-onlyoffice-1:/tmp/sx/s.xlsx
|
||||
docker cp /tmp/s_convert.xml nextcloud-onlyoffice-1:/tmp/sx/s.xml
|
||||
docker exec nextcloud-onlyoffice-1 bash -c 'chmod 666 /tmp/sx/s.xlsx /tmp/sx/s.xml'
|
||||
|
||||
# 3. 以 ds 用户身份跑 x2t（x2t 本身就是 ds 进程，必须 -u ds）
|
||||
X2T=/var/www/onlyoffice/documentserver/server/FileConverter/bin/x2t
|
||||
docker exec -u ds nextcloud-onlyoffice-1 bash -c \
|
||||
"LD_LIBRARY_PATH=/var/www/onlyoffice/documentserver/server/FileConverter/bin $X2T /tmp/sx/s.xml 2>&1; echo x2t=\$?"
|
||||
|
||||
# 4. 取回 + 转图片自查
|
||||
docker cp nextcloud-onlyoffice-1:/tmp/sx/s.pdf /tmp/out.pdf
|
||||
pdftoppm -png -r 100 /tmp/out.pdf /tmp/out_img/s
|
||||
```
|
||||
|
||||
### ⚠️ 权限坑（踩过3次才通）
|
||||
- `x2t` 以 **ds 用户**运行，ds 的 HOME（`/var/www/onlyoffice/documentserver`）**不可写**。
|
||||
- ds 能写 `/tmp` 和 `/var/lib/onlyoffice/documentserver/App_Data`。
|
||||
- **致命点**：若用 root 建 `/tmp/xxx` 目录，ds 写不进 → `Permission denied` + `x2t=126/2`。修复=建目录后 `chmod 777`。
|
||||
- **第二个坑**：在容器内用 `cat > s.xml <<EOF` 重定向写 xml 也会因 ds 权限失败。**正确做法：主机写好 xml，docker cp 进去**，不在容器内重定向。
|
||||
- 成功标志：`x2t=0` 且 `/tmp/sx/s.pdf` 由 `ds ds` 所有、size>0。
|
||||
|
||||
### 截断检测用文本提取，不靠肉眼
|
||||
渲染图片若无 vision 工具看不了内容时，用 `pdftotext` 抽全文，grep 各板块**末尾独特锚点句**是否都在（在=数据完整无截断）。比看图更可靠。
|
||||
> ⚠️ pdftotext 会按列宽把长句**折行**，直接 grep 完整句会假阴性——先 `tr -d '\n' | tr -d ' '` 把整页拍平再 grep（见主 SKILL Pitfall 1b 末条）。
|
||||
|
||||
### ⚠️ LibreOffice headless 渲超高行 xlsx 会卡死/被 SIGKILL → 直接走 x2t，别耗重试（2026-06-22 悦拾光实证）
|
||||
交付前想出 PDF 自查时，**别先试 `libreoffice --headless --convert-to pdf`**——当 xlsx 含**超高行 + 海量文本单元格**（如 K列法律风险 800字、行高 600–700pt）时，LibreOffice headless 转换阶段会**卡死**，前台 `timeout` 到点被 `-15`、加 `-env:UserInstallation` 独立 profile 重试仍 `-9`(SIGKILL)。诊断特征：`libreoffice --version` 秒回正常、`free -h` 内存充足（11G+ 可用），**唯独 `--convert-to` 这一步挂**——证明不是环境/内存问题，是 LibreOffice 对「超高行+超长单元格」headless 排版的已知缺陷。
|
||||
- **别浪费在 LibreOffice 上反复试**（本次连耗 4 次 -9/-15 才转向）：内存够、版本正常却 `--convert-to` 挂，立即判定为超高行触发的 LO 缺陷，**直接切到本文上半「x2t 渲染」配方**。x2t 是 Maggie 实际看文件的引擎、对超高行无此问题，本就该优先用它，不该先绕 LibreOffice。
|
||||
- 主 SKILL 已有铁律「LibreOffice 与 OnlyOffice 不同源、最终验收用 x2t」——本条补充其**故障模式**：LO 不只是「页数不准」，遇超高行会**直接转换失败**，更没有当 fallback 的价值。
|
||||
- 清残留：转换挂掉常留 soffice 僵尸进程，重试前 `pkill -9 -f soffice; pkill -9 -f oosplash`。
|
||||
|
||||
### ⚠️ 程序化截断自检：用 skill 自带脚本，别每次手写行高估算（2026-06-22 悦拾光教训）
|
||||
交付前判断「K列长文会不会被行高截断」，**直接跑 `scripts/xlsx-rowheight-analyze.py <文件.xlsx>`**（只读，按列宽折行估每行所需高度、标出「当前行高 < 建议行高」的行），不要在 `execute_code` 里临时手写一版行高估算函数——本次就因手写估算**严重偏低**（K列 800字实际需 43 行≈665pt，手写版只给了 21 行≈321pt），自检时才发现差一倍，白绕一圈。脚本已沉淀正确的 CJK 折行口径（中文按2宽、按 `\n` 切段逐段折行、向上取整），照用即可。设完行高用同口径复检 `可显行数 ≥ 需求行数` 全绿再渲染。
|
||||
|
||||
## 二、行高 409.5 pt 上限真相（别再浪费时间调高）
|
||||
|
||||
长内容单元格"行高调不上去"的根因已查清：
|
||||
|
||||
| 层 | 行为 |
|
||||
|---|---|
|
||||
| xlsx 文件格式 | **允许** >409.5pt（openpyxl 写 900 读回 900） |
|
||||
| OnlyOffice **x2t 批量引擎** | **接受** 900pt，round-trip 不 clamp |
|
||||
| OnlyOffice **网页版编辑器** | **存盘时 clamp 到 ~409.5pt** ← 这是 Maggie 编辑保存后高行变矮的真因 |
|
||||
|
||||
- 实测：给行设 760pt 交付，Maggie 在 OnlyOffice 网页版打开编辑保存后，被压回 409.6pt。**不是 xlsx 上限，是网页编辑器 clamp**。
|
||||
- **Maggie 的决定（2026-06-17）**："行距搞不定就算了，就按照目前的最高行距就好。" → **统一用 409.6pt，不再折腾调更高**。
|
||||
- 实务影响：单格约容纳 18–20 个折行；超长内容（如 K 列 700+ 字、第三部分 800+ 字）在网页**在线编辑视图可滚动看全、数据层完整**，只有导 PDF 给客户打印时才需另调版式（拆单元格/缩字号）。平时 409.6 即可，与万达定稿一致。
|
||||
- 若某份确需更高且**不经网页编辑器存盘**（直接文件层交付），x2t 引擎会认 900pt——但 Maggie 已拍板用 409.6，除非她另有指示，不要自作主张调高。
|
||||
+59
@@ -0,0 +1,59 @@
|
||||
# OnlyOffice xlsx 行高、合并单元格截断与渲染核查（2026-06-17 万达表确立）
|
||||
|
||||
汇总表的「校区整体风险分析」段是横跨整行的合并单元格（如 A11:L11），内容长达 800~1200+ 字、30~47 个逻辑行。OnlyOffice 渲染这类超长合并单元格时极易**截断显示**，而 Maggie 对「文字必须完整显示不截断」是硬要求。本文件记录踩过的坑、真实成因、以及可复用的核查方法。
|
||||
|
||||
## 一、行高 409.5/409.6pt 不是格式天花板，是 OnlyOffice 网页编辑器的 clamp 值
|
||||
|
||||
这是反复出现的谜题：**自己设了 760pt 的行，交付后再打开变成了 409.6pt。** 实测厘清三层行为，别再被误导：
|
||||
|
||||
| 层 | 行为 | 实测结论 |
|
||||
|---|---|---|
|
||||
| **xlsx 文件格式本身** | openpyxl 写 `row_dimensions[N].height = 900` → 存盘 → 读回 = 900 | ✅ 文件层**不限制**行高，900pt 能正常写入并保留 |
|
||||
| **OnlyOffice x2t 批量引擎** | xlsx(900pt) 经容器内 x2t 做 xlsx→xlsx round-trip → 读回 row 仍 = 900 | ✅ **不 clamp**。从文件层写的高行高，x2t 渲染/转换链路认 |
|
||||
| **OnlyOffice 网页版编辑器** | 在浏览器里打开编辑、点保存 | ❌ **会把超过 ~409.5pt 的行高压回 409.5/409.6**。这就是「我的 760 变成 409.6」的真凶 |
|
||||
|
||||
**结论与操作要点：**
|
||||
- 「调高行高让全部内容显示」在技术上**可行**——只要**从文件层（openpyxl 脚本）写入并经交付链路上传**，不要让结果再被网页编辑器存盘一次。
|
||||
- 一旦用户/自己在 OnlyOffice **网页端编辑并保存**过，超限行高就被打回 409.5。若交付后还要网页端再编辑，高行高保不住。
|
||||
- 设了 `height` 即自动 `customHeight=True`（openpyxl 中 `customHeight` 无 setter，不要试图直接赋值，会 `AttributeError`）。
|
||||
- **若 Maggie 明确说「就按当前最高行距，不用调」→ 不折腾，保持现状交付。** 别因为自己测出能调高就擅自改——方案≠授权。
|
||||
|
||||
## 二、数据完整 ≠ 视图不截断（核查别只看 pdftotext）
|
||||
|
||||
OnlyOffice/x2t 导 PDF 时，**被行高裁掉的文字仍会写进 PDF 文本层**。所以：
|
||||
- `pdftotext` 提取到尾部锚点句 = 数据在文件里（867 字符全在），**但不等于在编辑器视图里可见**。
|
||||
- 真正的「截断」是**视图层**问题（行高 < 内容所需高度时底部被裁），不是数据丢失。
|
||||
- 因此「数据完整性」用 pdftotext 验，「视图是否截断」要靠**行高是否 ≥ 内容估算高度**来判断（见下方脚本），或渲染成图片肉眼看。
|
||||
- ⚠️ 另一个坑：x2t 导 PDF 时**对超长合并单元格本身也会截断渲染**（PDF 里只画出前一部分，如只渲染「12,000」后面没了）——这是导出视图的固有限制，不代表数据丢。判断数据完整以 openpyxl 读单元格 `.value` 字符数为准。
|
||||
|
||||
## 三、可复用核查工具
|
||||
|
||||
### 行高分析脚本（再跑用）
|
||||
`scripts/xlsx-rowheight-analyze.py <文件.xlsx>`：只读分析每个 sheet 的长内容单元格，按合并宽度 + 字号估算所需视觉行数和建议行高，与当前行高对比，标出「可能截断」的行。不改文件。中文每字≈2.1 宽度单位、每视觉行≈15.5pt（10pt 字）是经验系数。
|
||||
|
||||
### x2t round-trip 测 clamp / 渲染（本地 OnlyOffice 实例）
|
||||
容器 `nextcloud-onlyoffice-1`，x2t 路径 `/var/www/onlyoffice/documentserver/server/FileConverter/bin/x2t`。
|
||||
```bash
|
||||
# xlsx→xlsx round-trip（测网页引擎是否 clamp 行高；format 257 = xlsx）
|
||||
docker cp in.xlsx nextcloud-onlyoffice-1:/tmp/t/in.xlsx
|
||||
docker exec nextcloud-onlyoffice-1 bash -c 'cat > /tmp/t/c.xml <<EOF
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<TaskQueueDataConvert xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
|
||||
<m_sFileFrom>/tmp/t/in.xlsx</m_sFileFrom><m_sFileTo>/tmp/t/out.xlsx</m_sFileTo>
|
||||
<m_nFormatTo>257</m_nFormatTo><m_bIsNoBase64>true</m_bIsNoBase64>
|
||||
</TaskQueueDataConvert>
|
||||
EOF
|
||||
LD_LIBRARY_PATH=/var/www/onlyoffice/documentserver/server/FileConverter/bin /var/www/onlyoffice/documentserver/server/FileConverter/bin/x2t /tmp/t/c.xml'
|
||||
# format 513 = PDF（渲染成 PDF 看版面）；之后主机 pdftoppm -png -r 110 out.pdf 转图
|
||||
```
|
||||
- x2t 退出码 `88` = 目标 format code 不对（不是文件坏）。xlsx→xlsx 用 257，xlsx→PDF 用 513；不要走 8193 bin 中间格式做 xlsx round-trip。
|
||||
- 主机有 `soffice`/`libreoffice`、`pdftoppm`/`pdfinfo`/`pdftotext`、中文字体 wqy-zenhei，可做降级渲染。
|
||||
|
||||
### 截断检测（文本锚点法）
|
||||
取目标长单元格**尾部**几句独特锚点，去掉空格后在 PDF 全文 grep——但记住第二节：命中只证明数据在，视图是否截断仍以行高估算为准。
|
||||
|
||||
## 四、一句话 SOP
|
||||
1. 估算：`scripts/xlsx-rowheight-analyze.py 文件.xlsx` → 看哪些行 `当前行高 < 建议行高`。
|
||||
2. 若需调高且用户同意：openpyxl 设 `row_dimensions[N].height = 建议值`，从文件层写、走交付链路上传，**别再用网页端编辑保存**。
|
||||
3. 若用户说保持当前最高 → 不动。
|
||||
4. 数据完整性单独用 openpyxl 读 `.value` 字符数确认，不靠 PDF。
|
||||
+71
@@ -0,0 +1,71 @@
|
||||
# openpyxl 富文本局部着色 → Excel "需要修复" 陷阱（2026-06-18 世茂血泪全记录）
|
||||
|
||||
## 结论先行（2026-06-18 最终反转：WPS 另存救活了红色）
|
||||
|
||||
**openpyxl 的 `CellRichText` 局部标红会让 Microsoft Excel 报"发现部分内容有问题，是否修复"**（点修复后丢富文本→红色全没）。本 session 用尽各种手改 XML 的修法都没在 Excel 里直接救活——**但最后一步成了：openpyxl 写好红 → 用 WPS 打开 → 另存为 xlsx，Excel 不再报错且红色保留**（Maggie 亲验 Excel 正常打开+红色在）。WPS 另存把 openpyxl 的不规范 XML（`inlineStr`+`CellRichText`）整体重写成规范格式（`sharedStrings.xml`），消除所有不合规处，这才是 Excel 认它的真因。
|
||||
|
||||
所以"单元格内某条标红、其余黑、Excel 兼容"**有跑通的路**：`openpyxl 写富文本红 → WPS 另存`。两步缺一不可。嫌 WPS 那步麻烦/纯自动化场景，退而用**纯文本前缀**（`【需客户核实】…`，整条黑字零格式，Excel 绝不报错）。
|
||||
|
||||
## 需求背景
|
||||
|
||||
Maggie 要把汇总表里"需要客户去核实/确认某个事实"的风险点**整条标红**（如"两份合同衔接需核实""建议签约时补明2028租金"），方便客户一眼看到待办。一个单元格里装着一整列风险点（🔴1-3、🟡4-9…），只有其中某一条要红 → 必须"单元格内局部不同颜色" → 只能用富文本。
|
||||
|
||||
## 试过的修法，全部在 Excel 里失败
|
||||
|
||||
1. **openpyxl 原生 `CellRichText` + `InlineFont(color=...)`** → Excel 报错。
|
||||
- 数据层验证（解压 xlsx 读 sheet XML）红色精确写入了，WPS 打开也正常，openpyxl readback 也对——**但 Excel 报错**。
|
||||
2. **修 `<rPr>` 子元素顺序**：openpyxl 输出 `<rFont/><color/><sz/>`，OOXML schema 要求 `<rFont/>→<sz/>→<color/>`（sz 在 color 前）。手改 XML 把 53 个 rPr 全调正 → **Excel 仍报错**。
|
||||
3. **补 `<charset val="134"/>`（中文字符集）+ `<family val="2"/>`**：styles.xml 里正常字体都有 charset/family，富文本 rPr 缺了。补齐 + 正确顺序（rFont→charset→family→sz→color）→ **Excel 仍报错**。
|
||||
4. **去掉所有富文本，恢复纯文本** → Excel **还是报**（轻微，能打开）。说明根子不只是富文本，openpyxl 生成的这张表底层某处本就不合 Excel 严格校验。
|
||||
|
||||
## 为什么这么难定位——验证工具全部"宽松"，骗过自己
|
||||
|
||||
| 工具 | 行为 | 能否当 Excel 合格证据 |
|
||||
|---|---|---|
|
||||
| openpyxl readback | 读回红色正确、XML 合法（lxml 解析过） | ❌ 不能 |
|
||||
| WPS | 打开完全正常、红色在 | ❌ 不能（WPS 容错宽松） |
|
||||
| OnlyOffice x2t | 转换成功、渲染出红色 | ❌ 不能（太宽松） |
|
||||
| LibreOffice headless | 本环境**连干净文件都报 `source file could not be loaded`** | ❌ 不能（环境本身坏，不代表 Excel） |
|
||||
| **Microsoft Excel** | **报"发现部分内容有问题/需要修复"** | ✅ 这才是真相 |
|
||||
|
||||
**致命点**：本地没有任何能复现 Excel 严格 OOXML 校验的工具。所有手头工具都比 Excel 宽松，导致我反复"修好了→还是不行"，把用户当测试员（连续 4+ 次"还是不行"），用户失去耐心。
|
||||
|
||||
## 行为铁律（比技术更重要）
|
||||
|
||||
1. **改完无法自验 Excel 行为时，如实说"我这边验不了 Excel，你帮我打开看下"，绝不断言"修好了"。** 没有复现工具就别打包票。
|
||||
2. **"WPS 打开正常"≠交付合格**。Maggie 和她客户用 Microsoft Excel，以 Excel 为准。
|
||||
3. **别在一个底层格式有问题的文件上反复打补丁**——越补越不可控。识别到"连纯文本版都报错"时就该换根本方案，而不是继续修富文本。
|
||||
|
||||
## 正确做法（Excel 绝不报错）
|
||||
|
||||
- **首选·纯文本标记**：需核实条前加 `【需客户核实】` / `❗待核实：` 前缀，整条黑字。
|
||||
- **整格统一格式**：`cell.font=Font(bold=True/color=...)`、`PatternFill` 背景色——安全，但整格所有条目一起染，仅"整格一条"时可用。
|
||||
- **真要某条带色**：让用户用 **WPS 打开→另存为 xlsx**，WPS 重写为规范格式后 Excel 不再报错、富文本保留（需用户手动一步）。
|
||||
|
||||
## 附
|
||||
|
||||
- 若硬要走富文本（不推荐），`scripts/fix-richtext-rpr-order.py` 可把 rPr 顺序修成 Excel 合规——但**本 session 实证：修了顺序 Excel 仍报错**，所以这个脚本不保证解决问题，仅作记录。
|
||||
- 富文本验证小坑：判断红色 run 别用宽松 `'FF0000' in run`——黑色 `FF000000` 含子串 `FF0000` 会被误判成红。必须精确匹配 `rgb="FFFF0000"`（红）排除 `rgb="FF000000"`（黑）。
|
||||
|
||||
## ⚠️ 二次编辑陷阱：openpyxl 重存会把 WPS 救回的红色一键毁掉（2026-06-18 世茂实证）
|
||||
|
||||
WPS 另存后的好文件存储 = `sharedStrings.xml` + 富文本红 `<r>` run。**对它再做任何 `openpyxl.load_workbook → 改 → save` 都会把成果作废**：openpyxl 把整表打回 `inlineStr`、`sharedStrings.xml` 消失、**红色 run 3→0**，Excel 又报"需要修复"。实测：改个 H11 单元格而已，红色全没了——幸亏改前留了 WPS 好基线 `_bak_`，才回得来。
|
||||
|
||||
**铁律：改已标红（WPS规范化）的 xlsx，改一个字都不能用 openpyxl 存。** 正解是在 `sharedStrings.xml` 的 XML 层做外科手术。
|
||||
|
||||
### 外科手术流程（已验证正确）
|
||||
|
||||
1. **改前先备份** WPS 好版本为 `_bak_*.xlsx`（openpyxl 一旦失手，这是唯一退路）。
|
||||
2. `zipfile` 解压好文件到临时目录。
|
||||
3. **定位"改哪个格 → 改第几条 si"**：`sheet1.xml` 里 `<c r="H11" t="s"><v>45</v></c>` 的 `<v>45` 就是 sharedString 索引。`--map` 一键列出全部映射。
|
||||
4. lxml 打开 `xl/sharedStrings.xml`，**只动目标 `<si>` 的 `<t>` 文字**：
|
||||
- 纯文本格（无红 run）→ 清空子节点、重写单个 `<t xml:space="preserve">新文本</t>`。
|
||||
- 含红 run 的格 → **只改黑色 `<r>` 的 `<t>`**；红 `<r>`（带 `<rPr>…<color rgb="FFFF0000"/>`）一个字不碰。
|
||||
- 删一条红色风险项 + 顺移编号：`si.remove(目标<r>)` 后把后续 `<r>` 的 `"10. "→"9. "` 等前缀顺移，保 1–N 连续。删红 run 时红色计数随之 −1。
|
||||
5. **规范重打包**：`[Content_Types].xml` 必须 zip 第一项、`_rels/` 次之，否则 LibreOffice 等严格解析器报 `source file could not be loaded`（Excel/WPS 宽容，但别赌）。`ZIP_DEFLATED`。
|
||||
|
||||
### 改后五查（本地验不了 Excel 时能做的最强保证，过了再发 Maggie）
|
||||
|
||||
① `xl/sharedStrings.xml` 仍在（不在 = openpyxl 又把富文本毁了）；② 红色 run 数 = 预期（删 1 条红就 3→2，没删则不变，精确数 `rgb="FFFF0000"`）；③ `zipfile.testzip()` 通过 + 所有 `.xml/.rels` lxml 可 `fromstring`；④ 目标格文字已更新、编号连续、旧表述（"留白/未约定"等）全表 `grep` 0 残留；⑤ 与 WPS 好基线部件清单同构（差异仅空目录条目可接受）。
|
||||
|
||||
一键：`python3 scripts/edit-redmarked-xlsx.py --verify 改后.xlsx --baseline WPS好基线.xlsx --expect-red 2`。完整实现（解压→按 si 改 `<t>`→删 run 顺移→规范重打包→五查 + 可 import 的工具函数）见 `scripts/edit-redmarked-xlsx.py`，照抄别重写。
|
||||
@@ -0,0 +1,66 @@
|
||||
# Output Consistency for Multi-Campus Batch Processing
|
||||
|
||||
**Lesson learned**: 2026-06-30 — 跃龙路 vs 解放中路/星月等7校区
|
||||
|
||||
## Root Cause: LLM Context Anchoring
|
||||
|
||||
LLM output style is heavily influenced by what's in the context window:
|
||||
- **Consecutive processing** (same session, same time window): previous campus outputs are still in context → LLM naturally "copies the style" → consistent output
|
||||
- **Separated processing** (different session, different time): previous outputs are gone → LLM generates with its own default style → drift
|
||||
|
||||
This is NOT a workflow bug or a rules problem. The rules were the same. The output format specification was the same. But the LLM produced different styles because the **contextual anchor** was different.
|
||||
|
||||
Maggie's concern (verbatim): "金额，风险，模版对比各列内容的审查和修改意见表达都不一样了...第一批里从解放中路到星月的审查逻辑和表达都是一致的，为什么到跃龙路又变掉了？"
|
||||
|
||||
## Three-Layer Defense
|
||||
|
||||
### Layer 1: Fixed Templates in Workflow Prompt (hardest constraint)
|
||||
|
||||
Embed complete output examples + "禁止" (prohibited) rules directly in the data-extractor role's procedure section. Example structure:
|
||||
|
||||
```yaml
|
||||
H列格式规范:
|
||||
风格: 段落式叙述
|
||||
结构: 【租金】→【付款推算】→【押金】→【物业费】→【违约金】
|
||||
禁止:
|
||||
- bullet符号（•、-、*）
|
||||
- "【大类·条款号】"合并标题
|
||||
- 过度拆分为逐行小条目
|
||||
|
||||
K列格式规范:
|
||||
风格: 先【整体评价】段落，再❗【需客户核实】编号列表
|
||||
禁止:
|
||||
- "10项风险（3高/5中/2低）："统计式开头
|
||||
- "1.【高·第十条】"标签格式
|
||||
- markdown表格列风险
|
||||
|
||||
L列格式规范:
|
||||
风格: 一句话说明+编号列表
|
||||
禁止:
|
||||
- "34处差异（16缺失/15修改/3新增）vs 07模版："统计式开头
|
||||
- "【核心缺失】"分类小标题
|
||||
- "vs"分隔模版和合同
|
||||
```
|
||||
|
||||
Updated in nantong-lease-audit.yaml v2 (hash: `C77579MQ9QPKE`).
|
||||
|
||||
### Layer 2: Load Previous Campus Output as Reference
|
||||
|
||||
Before generating data for a new campus, read the most recent completed campus xlsx and extract H/K/L column content as style reference:
|
||||
|
||||
```bash
|
||||
REF_XLSX=$(ls -t /path/to/campuses/*/*梳理*.xlsx 2>/dev/null | head -1)
|
||||
```
|
||||
|
||||
Use openpyxl to read H/K/L values from the first data row, inject into the data-extractor prompt context.
|
||||
|
||||
### Layer 3: Post-Processing Validation Script
|
||||
|
||||
Run `scripts/output-style-check.py <row-data.json>` after data extraction:
|
||||
- Checks 8 rules across H/K/L/J columns
|
||||
- Exit 0 = pass, exit 1 = fail (lists specific issues)
|
||||
- If fail → fix the specific issues before proceeding to xlsx generation
|
||||
|
||||
## Key Insight
|
||||
|
||||
Rules alone are insufficient to prevent style drift. The LLM needs **concrete examples in context** at the moment of generation. Three layers provide redundancy: if Layer 1 is imperfectly followed, Layer 2 gives a fresh anchor, and Layer 3 catches what slips through.
|
||||
@@ -0,0 +1,143 @@
|
||||
# 汇总表输出格式规范（跃龙路定稿为唯一基准）
|
||||
|
||||
> Maggie 2026-07-03 指令："输出格式参照跃龙路，别自己创设"
|
||||
> 龙信首次交付因自创格式被退回重做。
|
||||
|
||||
## 铁律：不得自创格式
|
||||
|
||||
跃龙路-梳理-MJ-20260703.xlsx 是格式唯一参照物。所有新校区必须与其视觉一致。
|
||||
不熟悉格式时先 `read_file` 跃龙路汇总表各列内容，照抄格式框架填数据。
|
||||
|
||||
---
|
||||
|
||||
## D列（合同当事人）格式
|
||||
|
||||
```
|
||||
甲方：XX（自然人）
|
||||
乙方：南通新东方教育科技有限公司
|
||||
```
|
||||
|
||||
- 简洁，不加多余括号说明（如"出租方""承租方"）
|
||||
- 签约日期不放D列（放G列或不单独列）
|
||||
|
||||
## E列（租赁标的/服务范围）格式
|
||||
|
||||
```
|
||||
地址全文
|
||||
用途：XX
|
||||
```
|
||||
|
||||
- 末行加用途
|
||||
|
||||
## G列（合同期限）格式
|
||||
|
||||
```
|
||||
2026年X月X日至20XX年X月X日
|
||||
（XX个月，含免租装修期XX天/个月）
|
||||
免租装修期：2026.X.X-2026.X.X
|
||||
```
|
||||
|
||||
## H列（金额/费用）格式
|
||||
|
||||
```
|
||||
【押金】XX元（第X条）
|
||||
【租金】XX元/年（含税），≈XX元/月（第X条）
|
||||
【物业费】...
|
||||
【水电费】...
|
||||
【支付方式】半年一付XX元/期，先付后用（第X条）
|
||||
【付款推算】...
|
||||
第1期（起-止）：金额 ┃ 付款期限
|
||||
❗第2期（起-止）：金额 ┃ 付款期限
|
||||
```
|
||||
|
||||
- 付款推算各行用全角空格缩进 + `┃` 分隔金额和付款日期
|
||||
- ❗标记未付期次（句首）
|
||||
|
||||
## I列（核心内容）格式
|
||||
|
||||
```
|
||||
【用途】...（第X条）
|
||||
【转租】...（第X条）
|
||||
【装修】...
|
||||
【维修责任】甲方：...；乙方：...（第X条）
|
||||
【违约金·逾期付款】每日X‰（第X条）
|
||||
【违约金·逾期归还】...
|
||||
【违约金·乙方提前解租】...
|
||||
【违约金·甲方提前解租】...
|
||||
【不可抗力/政府拆迁】...
|
||||
...
|
||||
【争议解决】XX人民法院（第X条）
|
||||
```
|
||||
|
||||
- 违约金用 `【违约金·XX】` 子标签区分
|
||||
|
||||
## K列（法律风险）格式
|
||||
|
||||
```
|
||||
【整体评价·站承租方（乙方）立场】
|
||||
本合同为...
|
||||
|
||||
〇 需注意
|
||||
1. 条款名（第X条X款）：具体风险说明。
|
||||
2. ...
|
||||
3. ...
|
||||
|
||||
【提前退租法律后果】
|
||||
提前X月书面告知 + ...
|
||||
```
|
||||
|
||||
### ⚠️ 禁止事项（龙信首次被退回的原因）：
|
||||
- ❌ 不用 🔴🟡🟢 emoji标记风险等级
|
||||
- ❌ 不用 `【需注意的风险点】` 作小标题
|
||||
- ❌ 不用 `【整体评价】` 不带"·站承租方（乙方）立场"后缀
|
||||
- ✅ 用 `〇 需注意` 作风险列表引导词
|
||||
- ✅ 用纯数字编号（1. 2. 3.）不加emoji前缀
|
||||
|
||||
## L列（与07标准模版差异）格式
|
||||
|
||||
```
|
||||
本合同为甲方（XX）制式合同，非新东方标准制式，与07标准模版差异极大（N项差异）。主要差异：
|
||||
1.【差异标签】07模版：XX→本合同：XX
|
||||
2.【差异标签】07模版：XX→本合同：XX
|
||||
...
|
||||
```
|
||||
|
||||
- 每条差异用 `【标签】07模版：...→本合同：...` 格式
|
||||
- 物业合同写 `物业服务协议，无对应07标准模版。`
|
||||
|
||||
## 整体风险分析与建议段格式
|
||||
|
||||
```
|
||||
【整体评价】
|
||||
XX校区共N份合同...
|
||||
|
||||
【其他法律关注点】
|
||||
1. ...
|
||||
2. ...
|
||||
|
||||
【提前退租法律后果】
|
||||
- 租赁合同：...
|
||||
- 物业合同：...
|
||||
- 5年总租赁成本约：...
|
||||
|
||||
【续签建议】
|
||||
1. ...
|
||||
2. ...
|
||||
```
|
||||
|
||||
### ⚠️ 注意：
|
||||
- 用 `【其他法律关注点】` 不是 `【法律关注点】`
|
||||
- 关注点用纯数字编号不加emoji
|
||||
- 总成本计算放在提前退租法律后果段末尾
|
||||
|
||||
## 物业行K列格式（简洁版）
|
||||
|
||||
```
|
||||
物业合同风险XX。关注点：
|
||||
1. ...
|
||||
2. ...
|
||||
3. ...
|
||||
```
|
||||
|
||||
- 不用 `【整体评价·站承租方（乙方）立场】` 开头
|
||||
- 直接一句话概括+编号列风险点
|
||||
@@ -0,0 +1,54 @@
|
||||
# Output Style Consistency — Three-Layer Defense
|
||||
|
||||
## Problem (2026-06-30 Maggie discovery)
|
||||
When processing multiple campuses in separate sessions, the LLM's data-extractor output drifts in style because earlier campus outputs are no longer in context. The first batch (解放中路→星月, 7 campuses) was consistent due to context anchoring — each campus saw the previous output and copied its style. When 跃龙路 was processed in a new session, the LLM had no reference and generated a different style:
|
||||
- H列: bullet-list format instead of paragraph-style
|
||||
- K列: statistical tag format ("10项风险（3高/5中/2低）") instead of narrative ("【整体评价】...")
|
||||
- L列: categorized headers ("【核心缺失16项】") instead of numbered list
|
||||
|
||||
Maggie: "金额，风险，模版对比各列内容的审查和修改意见表达都不一样了"
|
||||
|
||||
## Root Cause
|
||||
LLM context anchoring effect: style consistency comes from seeing previous outputs in context, not from prompt instructions alone. When context window resets between sessions, the anchoring is lost.
|
||||
|
||||
## Three-Layer Defense (implemented in nantong-lease-audit v2 workflow)
|
||||
|
||||
### Layer 1: Fixed Templates in Workflow Prompt
|
||||
In the data-extractor role's procedure, embed concrete style examples with explicit "禁止" (prohibited) patterns:
|
||||
|
||||
```yaml
|
||||
# H列 format: paragraph-style with 【】category headers, no bullets
|
||||
# K列 format: 【整体评价】opening + ❗【需客户核实】numbered list
|
||||
# L列 format: one-line relationship statement + numbered diff list
|
||||
# J列: exactly "履行中"/"已到期"/"已解除", no parenthetical explanations
|
||||
```
|
||||
|
||||
### Layer 2: Reference Loading Before Generation
|
||||
Before generating data for a new campus, load the most recent completed campus's xlsx and extract H/K/L content as style anchor:
|
||||
|
||||
```bash
|
||||
REF_XLSX=$(ls -t /path/to/房租物业合同/*/*梳理*.xlsx 2>/dev/null | head -1)
|
||||
```
|
||||
|
||||
Read with openpyxl, inject into prompt context. LLM sees "previous campus looks like this" and naturally aligns.
|
||||
|
||||
### Layer 3: Post-Processing Validation
|
||||
Run `output-style-check.py` after generation, before upload:
|
||||
|
||||
```bash
|
||||
python3 ~/.hermes/scripts/output-style-check.py <campus>-row-data.json
|
||||
```
|
||||
|
||||
Checks 8 rules:
|
||||
- H列: no bullet symbols (•/-/*), no "【category·clause】" merged headers
|
||||
- K列: no statistical openings ("X项风险(Y高/Z中)"), no "序号·等级·条款号" tags, no markdown tables, must have 【整体评价】
|
||||
- L列: no statistical openings ("X处差异(Y缺失/Z修改)"), no "【核心缺失/修改】" sub-headers, no "vs" separators
|
||||
- J列: exact match "履行中"/"已到期"/"已解除"
|
||||
|
||||
Exit 0 = pass, exit 1 = list violations for fix.
|
||||
|
||||
## Workflow Integration
|
||||
In nantong-lease-audit.yaml v2 (hash C77579MQ9QPKE), the data-extractor procedure sections 5-6 implement layers 1-2. Layer 3 is run manually after workflow completes, before xlsx generation.
|
||||
|
||||
## Script Location
|
||||
`~/.hermes/scripts/output-style-check.py` — standalone, no dependencies beyond stdlib json/re/sys.
|
||||
@@ -0,0 +1,95 @@
|
||||
# 输出风格一致性规则（2026-06-30 跃龙路教训）
|
||||
|
||||
## 背景
|
||||
|
||||
LLM输出风格依赖**上下文锚定效应**——同一session连续处理多校区时，前序输出在上下文中，LLM自然"照着前面写"，风格一致。新session/新时间段处理时，前序输出不在上下文中，LLM按自己的理解重新生成风格，导致不一致。
|
||||
|
||||
**根因**：这不是规则问题，不是workflow问题，是LLM固有特性。
|
||||
|
||||
## 三层防线
|
||||
|
||||
| 层 | 机制 | 位置 |
|
||||
|---|---|---|
|
||||
| 第一层（治本） | workflow prompt中写死格式模板+示例+禁止项 | `nantong-lease-audit.yaml` data-extractor角色procedure第5节 |
|
||||
| 第二层（治标） | 跑新校区前自动加载前序校区xlsx的H/K/L列 | `nantong-lease-audit.yaml` data-extractor角色procedure第6节 |
|
||||
| 第三层（兜底） | 生成后跑校验脚本 | `python3 scripts/output-style-check.py` |
|
||||
|
||||
## H/K/L/J列格式规范
|
||||
|
||||
### H列（金额/费用）——段落式叙述
|
||||
|
||||
**正确风格**：用【】标注大类，条款号用中文括号，不用bullet符号
|
||||
|
||||
```
|
||||
【租金】一期一交，当期缴纳次年租金（首期14个月，后续各期12个月）（第三条）
|
||||
前三年100,564.80元/年（月租≈8,380.40元），后两年递增5%为105,593.04元/年（月租≈8,799.42元）（含税）
|
||||
【付款推算】起租日2026/3/18，每年一付，每期租金到期日前一个月内付（第三条）：
|
||||
第1期2026/5/18–2027/5/17：100,564.80元（首期14个月含免租期...
|
||||
```
|
||||
|
||||
**月租换算**（2026-07-03 Maggie确认）：一律用行内括号写法，写在租金标准行内。
|
||||
- ✅ `年191,990元（月租≈15,999元）`
|
||||
- ❌ 单独另起一行写"折合月租约15,999元"
|
||||
|
||||
**付款推算逐期格式**（2026-07-03 星月定稿）：
|
||||
```
|
||||
【付款推算】租金+物业费合并列示，半年一付，提前30天（第四条第3款）
|
||||
第1期（2024.8.1-2025.1.31）：租金95,995 + 物业12,624 = 108,619元 ┃ 签约后7天内
|
||||
第2期（2025.2.1-2025.7.31）：租金95,995 + 物业12,624 = 108,619元 ┃ 付款期限2025.1.2
|
||||
❗第7期（2027.8.1-2028.1.31，递增后）：租金100,795 + 物业12,624 = 113,419元 ┃ 付款期限2027.7.2
|
||||
```
|
||||
- 每期独立一行：区间 + 租金 + 物业 = 合计 ┃ 付款期限
|
||||
- ❗标注当前尚未到期的付款
|
||||
- 含免租期/递增的期次加括号说明
|
||||
- 数据来源：直接从H列（租金标准/物业费/支付方式）+ G列（起止日期/免租期）推算即可，无需每次回OCR原文
|
||||
|
||||
**禁止**：
|
||||
- bullet符号（•、-、*）
|
||||
- "【租金·第四条】"这种"大类·条款号"合并标题
|
||||
- 过度拆分为逐行小条目
|
||||
- 月租换算单独占一行
|
||||
|
||||
### K列（法律风险）——整体评价+核实项+叙述式
|
||||
|
||||
**正确风格**：先【整体评价】段落，再❗核实项编号列表，再具体风险叙述式
|
||||
|
||||
```
|
||||
【整体评价·站承租方（乙方）立场】本合同为甲方（运营管理公司）制式文本，条款整体偏中性...整体风险中等。
|
||||
|
||||
❗【需客户核实】
|
||||
1. 出租方为运营管理公司（南通鸿城运营管理有限公司）：建议核验甲方与产权人之间的授权委托关系...
|
||||
2. 合同用途为"商业"与新东方实际教学/培训用途不符...
|
||||
```
|
||||
|
||||
**禁止**：
|
||||
- "10项风险（3高/1中高/5中/1低）："统计式开头
|
||||
- "1.【高·第十条第1款】"标签格式
|
||||
- markdown表格列风险
|
||||
|
||||
### L列（模版差异）——叙述式开头+编号列表
|
||||
|
||||
**正确风格**：先一句话说明合同与07的关系，再编号列表
|
||||
|
||||
```
|
||||
本合同为甲方（运营管理公司）制式文本，与07模版结构、编号、措辞均不同（非07模版填空版）。
|
||||
|
||||
主要文本差异（共25条逐条差异+12条缺失条款）：
|
||||
1. 合同标题：模版为"房屋租赁合同"；本合同为"房屋租赁协议"
|
||||
2. 甲方权属保证：模版有详细权属保证+查验+违约解除条款；本合同仅"甲方承诺..."（第五条）
|
||||
```
|
||||
|
||||
**禁止**：
|
||||
- "34处差异（16缺失/15修改/3新增）vs 07模版："统计式开头
|
||||
- "【核心缺失16项】"分类小标题
|
||||
- "vs"分隔模版和合同
|
||||
|
||||
### J列（状态）——只写三个字
|
||||
|
||||
`履行中` / `已到期` / `已解除`，不加括号说明。
|
||||
|
||||
## 校验
|
||||
|
||||
```bash
|
||||
python3 scripts/output-style-check.py /tmp/nantong-lease-audit/<校区>-row-data.json
|
||||
# exit 0 = 通过，exit 1 = 列出具体问题
|
||||
```
|
||||
@@ -0,0 +1,106 @@
|
||||
# PDF OCR Troubleshooting for Scanned Chinese Contracts
|
||||
|
||||
**Lesson learned**: 2026-06-30 — 通州金鹰 (23MB lease + 1.4MB property contract)
|
||||
|
||||
## Problem Pattern: Mixed OCR Results
|
||||
|
||||
Scanned PDFs of Chinese contracts often produce:
|
||||
- Some pages: clean OCR text via `ocrmypdf` + `pdftotext`/`pymupdf`
|
||||
- Other pages: completely empty output (0 chars)
|
||||
- Other pages: garbled character soup (`\u0000` null bytes, random symbols)
|
||||
|
||||
## Diagnosis
|
||||
|
||||
```python
|
||||
from PIL import Image
|
||||
import numpy as np
|
||||
|
||||
for i in range(1, N+1):
|
||||
img = Image.open(f'pages/page-{i}.jpg').convert('L')
|
||||
arr = np.array(img)
|
||||
mean = arr.mean() # ~160-170 for scanned contracts
|
||||
std = arr.std() # ~30-37 for text-heavy pages
|
||||
# If tesseract returns 0 chars but mean/std look normal → needs preprocessing
|
||||
```
|
||||
|
||||
## Fix 1: Binary Threshold Conversion
|
||||
|
||||
Standard tesseract OCR produces empty output on some scanned pages. The fix:
|
||||
|
||||
```python
|
||||
from PIL import Image
|
||||
import numpy as np
|
||||
|
||||
for i in empty_pages:
|
||||
img = Image.open(f'pages/page-{i}.jpg').convert('L')
|
||||
arr = np.array(img)
|
||||
threshold = 140 # Key value: too high = lose text, too low = noise
|
||||
arr = (arr < threshold).astype(np.uint8) * 255
|
||||
bw = Image.fromarray(arr)
|
||||
bw.save(f'pages/page-{i}_bw.png')
|
||||
# Then: tesseract pages/page-{i}_bw.png stdout -l chi_sim
|
||||
```
|
||||
|
||||
**Why this works**: Some scanners produce pages where the background is very slightly off-white (mean ~168 vs pure white 255). Tesseract's adaptive thresholding fails on these. Hard binary threshold at 140 separates text (dark, <140) from background (>140) cleanly.
|
||||
|
||||
## Fix 2: Vision Service Timeout
|
||||
|
||||
`vision_analyze` times out on large images (>200KB at 300dpi). Always compress:
|
||||
|
||||
```python
|
||||
from PIL import Image
|
||||
img = Image.open(f'pages/page-{i}.jpg')
|
||||
img = img.resize((img.width // 3, img.height // 3), Image.LANCZOS)
|
||||
img.save(f'pages/page-{i}_small.jpg', quality=60)
|
||||
# Target: 80-95KB per page at 850x1100 pixels
|
||||
```
|
||||
|
||||
## Fix 3: ocrmypdf Text Layer Extraction Failure
|
||||
|
||||
Even after `ocrmypdf`, the embedded text layer may be garbled when extracted via `pdftotext` or `pymupdf`. This is a known issue with `ocrmypdf` + tesseract for Chinese text.
|
||||
|
||||
**Solution**: Don't rely on `ocrmypdf`'s text layer. Instead:
|
||||
1. Use `ocrmypdf` to produce the OCR'd PDF (for archiving)
|
||||
2. Separately extract pages as images: `pdftoppm -jpeg -r 300 input.pdf pages/page`
|
||||
3. Run tesseract directly on each image
|
||||
4. For empty pages, apply binary threshold (Fix 1) and retry
|
||||
|
||||
## Workflow: Complete OCR Pipeline
|
||||
|
||||
```bash
|
||||
# 1. Extract pages as images
|
||||
pdftoppm -jpeg -r 300 "contract.pdf" pages/page
|
||||
|
||||
# 2. Standard tesseract on all pages
|
||||
for f in pages/page-*.jpg; do
|
||||
tesseract "$f" "${f%.jpg}" -l chi_sim 2>/dev/null
|
||||
done
|
||||
|
||||
# 3. Identify empty pages (0 chars)
|
||||
for f in pages/page-*.txt; do
|
||||
chars=$(wc -c < "$f")
|
||||
if [ "$chars" -lt 10 ]; then
|
||||
echo "EMPTY: $f"
|
||||
fi
|
||||
done
|
||||
|
||||
# 4. Binary threshold + retry on empty pages (Python)
|
||||
# 5. Vision for remaining empty pages (compress to <100KB first)
|
||||
# 6. Concatenate all page texts into final OCR file
|
||||
```
|
||||
|
||||
## Known OCR Garble Patterns in Chinese Contracts
|
||||
|
||||
| OCR Output | Likely Value | Context |
|
||||
|---|---|---|
|
||||
| "于65" / "也65" / "了芋65" | 765 | Area in ㎡ |
|
||||
| "巧" / "葬" | 15 / 30 | Working days |
|
||||
| "101" | 10 | Percentage |
|
||||
| "0.1‰%o" | 0.1‰ | Daily penalty rate |
|
||||
| "直通市赴" | 南通市通州区 | City name |
|
||||
| "驳玉年" | 2025年 | Year |
|
||||
| "瑞殉年" | 2025年 | Year |
|
||||
| "嫂万元整" | 肆万元整 | Amount in Chinese |
|
||||
| "103" | 10 | Working days |
|
||||
|
||||
**Rule**: Never guess OCR values. Mark as "⚠️待核实原件" in the Excel and list in 需客户核实 section.
|
||||
@@ -0,0 +1,136 @@
|
||||
# 物理依赖链架构（2026-06-29 确立）
|
||||
|
||||
## 设计理念
|
||||
|
||||
规则写在skill里是"纸面约束"——看了可以跳过。物理依赖链把关键步骤之间的依赖变成"物理约束"——上一步没做完，下一步**跑不起来**。
|
||||
|
||||
核心区别：
|
||||
| | 纸面规则 | 物理依赖链 |
|
||||
|---|---|---|
|
||||
| 什么时候卡 | 做完后检查（事后） | 做之前检查（事前） |
|
||||
| 能不能绕过 | 能（不跑检查直接发） | 不能（脚本直接中止） |
|
||||
| 靠什么保证 | 人的记性 | checkpoint文件 |
|
||||
|
||||
## 三道卡口
|
||||
|
||||
### 卡口1：OCR完整性 → 建表
|
||||
|
||||
```
|
||||
Step 1 OCR完成
|
||||
↓
|
||||
ocrmypdf → pdftotext → .md文件
|
||||
↓
|
||||
python3 scripts/ocr-integrity-check.py <工作目录>
|
||||
↓ 检查：无乱码/无占位符
|
||||
↓ 通过 → 生成 step1.verified
|
||||
↓ 不通过 → 列出问题，不生成checkpoint
|
||||
↓
|
||||
Step 3 建表时：
|
||||
single-campus-builder.py 检查 step1.verified 是否存在
|
||||
不存在 → sys.exit(1)，表中止
|
||||
```
|
||||
|
||||
### 卡口2：模版比对 → 建表
|
||||
|
||||
```
|
||||
Step 2 动作B完成（delegate subagent）
|
||||
↓
|
||||
subagent产出 模版比对-*.md
|
||||
↓
|
||||
python3 scripts/template-diff-verify.py <工作目录>
|
||||
↓ 检查：文件存在、>2000字节、≥10个条款号、≥3个差异关键词
|
||||
↓ 通过 → 生成 step2b.verified
|
||||
↓ 不通过 → 列出问题，不生成checkpoint
|
||||
↓
|
||||
Step 3 建表时：
|
||||
single-campus-builder.py 检查 step2b.verified 是否存在
|
||||
不存在 → sys.exit(1)，表中止
|
||||
```
|
||||
|
||||
### 卡口3：最终闸门
|
||||
|
||||
```
|
||||
Step 6 交付前
|
||||
↓
|
||||
python3 scripts/delivery-gate.py <xlsx> <工作目录> <校区名>
|
||||
↓ 9项检查（G1-G9）
|
||||
↓ 全过 → exit 0，可以发
|
||||
↓ 任一不过 → exit 1，禁止发
|
||||
```
|
||||
|
||||
## 环境变量
|
||||
|
||||
建表脚本通过环境变量 `CAMPUS_WORKDIR` 定位工作目录：
|
||||
|
||||
```bash
|
||||
CAMPUS_WORKDIR=/tmp/人民中路 python3 templates/single-campus-builder.py
|
||||
```
|
||||
|
||||
如果不设此变量，建表脚本跳过checkpoint检查（向后兼容），但 delivery-gate 事后仍会拦截 G8/G9。
|
||||
|
||||
## 已修复的误报模式（2026-06-29 多校区实证）
|
||||
|
||||
### ocr-integrity-check.py 误报
|
||||
|
||||
| 模式 | 误报原因 | 修复 |
|
||||
|------|---------|------|
|
||||
| 统一社会信用代码（如91320600MA1NAEBX26） | 代码中的英文字母（MA1NAEBX）被识别为"公司名乱码" | 脚本已增加前后字符检查：字母前后有数字→跳过 |
|
||||
| 合同编号（如XYZL-20241029-2#1F） | 4+连续大写字母匹配乱码正则 | 临时修复：将XYZL替换为Xyzl（小写）避免匹配 |
|
||||
| 签名页英文残留 | 扫描件签名区域的OCR噪声 | 用正则替换为[签章]占位符 |
|
||||
|
||||
**修复后仍可能触发的情况**：如果OCR文件中出现新的非标准英文序列，脚本仍会报"公司名乱码"。此时需判断：
|
||||
- 前后有数字（如信用代码）→ 手动修正OCR文件中的具体位置
|
||||
- 签名/盖章区域 → 用正则批量替换为[签章]
|
||||
- 真正的乱码（关键字段无法识别）→ 用vision或tesseract看原图补全
|
||||
|
||||
### template-diff-verify.py 误报
|
||||
|
||||
| 模式 | 误报原因 | 修复 |
|
||||
|------|---------|------|
|
||||
| "模版表述："（冒号） | 原正则只匹配"模版表述为" | 已改为`模版表述[为：:]`，同时匹配冒号 |
|
||||
| subagent用"无此条款"描述差异 | 原关键词列表不含此表述 | 已新增"无此条款"和"不存在"为有效关键词 |
|
||||
|
||||
## OCR补全的tesseract降级方案
|
||||
|
||||
当`vision_analyze`超时（常见于高分辨率扫描件）时，tesseract可作为降级方案：
|
||||
|
||||
```python
|
||||
import fitz
|
||||
doc = fitz.open('合同.pdf')
|
||||
page = doc[page_index]
|
||||
mat = fitz.Matrix(200/72, 200/72) # 200 DPI
|
||||
pix = page.get_pixmap(matrix=mat)
|
||||
pix.save(f'page_{page_index+1}.png')
|
||||
```
|
||||
|
||||
```bash
|
||||
tesseract page_X.png stdout -l chi_sim+eng --psm 6 2>/dev/null
|
||||
```
|
||||
|
||||
**适用场景**：
|
||||
- 读取合同首页（甲乙方信息、地址、信用代码）
|
||||
- 读取特定条款段落（裁剪页面局部区域）
|
||||
- 补充OCR .md文件中的乱码位置
|
||||
|
||||
**不适用场景**：
|
||||
- 手写签名、印章内容（tesseract无法识别）
|
||||
- 低对比度扫描件（需先二值化处理）
|
||||
|
||||
## 企业入驻合同等非标准格式（2026-06-29 星月实证）
|
||||
|
||||
部分园区使用"企业入驻合同"而非标准"房屋租赁合同"格式。特征：
|
||||
- 合同标题为"企业入驻合同"或"入驻协议"
|
||||
- 包含物业管理费（打包在租金中或单独列出）
|
||||
- 条款结构与07模版完全不同（无07模版的条款号体系）
|
||||
- 常见于创业孵化器、科技园区、产业园
|
||||
|
||||
**处理方式**：subagent模版比对时仍需与07模版比对（找出缺失的保护性条款），但在L列注明"本合同为企业入驻合同格式，非07标准模版"。
|
||||
|
||||
## 脚本清单
|
||||
|
||||
| 脚本 | 位置 | 作用 |
|
||||
|------|------|------|
|
||||
| ocr-integrity-check.py | scripts/ | 检查OCR .md文件乱码/占位符 → step1.verified |
|
||||
| template-diff-verify.py | scripts/ | 检查模版比对输出充实度 → step2b.verified |
|
||||
| single-campus-builder.py | templates/ | 建表前检查两个checkpoint |
|
||||
| delivery-gate.py | scripts/ | 最终9项闸门（含G8/G9复查checkpoint） |
|
||||
@@ -0,0 +1,59 @@
|
||||
# Pitfalls from 2026-07-03 Session (龙信+跃龙路+通州金鹰+星月+小石桥晏园)
|
||||
|
||||
## 🔴 Pitfall 30: 所有租赁合同必须做模版比对——不论制式
|
||||
|
||||
**栽点（龙信·2026-07-03）**：龙信广场为甲方制式商铺租赁合同（非新东方制式），错误判断"非新东方制式无需比对"，L列直接写"非新东方制式合同，无对应07标准模版"。Maggie追问"为什么没有做租赁合同和标准合同的对比？"
|
||||
|
||||
**铁律**：所有租赁合同不论制式都必须与07标准模版做delegate_task比对。
|
||||
- 新东方制式 → 比对（找出微调差异）
|
||||
- 甲方制式 → 比对（差异更大，更需要让客户看到缺失了哪些保护）
|
||||
- 自由协商合同 → 比对
|
||||
- 物业合同、主体变更协议 → 不需要比对（类型不同）
|
||||
|
||||
**根因**：误把"是否为同一模版"当作是否比对的判断依据。正确逻辑是：比对的目的是让客户看到"相比新东方标准保护，本合同缺了什么"——越不是新东方制式，差异越大，越需要比对。
|
||||
|
||||
---
|
||||
|
||||
## Pitfall 31: 多份合同必须分行，不得合并
|
||||
|
||||
**栽点（小石桥晏园·2026-07-03）**：将租赁合同和主体变更协议合成一行。Maggie明确要求："3份合同分别提取，分别审阅，做成三行，不要混在一起写"。
|
||||
|
||||
**铁律**：每份独立合同PDF = 汇总表中独立一行。
|
||||
- 租赁合同 → 独立一行
|
||||
- 主体变更协议 → 独立一行
|
||||
- 物业合同 → 独立一行
|
||||
- 不可将变更协议"合并"到租赁合同行内
|
||||
|
||||
---
|
||||
|
||||
## Pitfall 32: 不得擅自删除旧版文件
|
||||
|
||||
**栽点（通州金鹰·2026-07-03）**：新建汇总表后擅自删除了旧版xlsx（0626/0630版）。Maggie指出"我没让你清理旧表，请恢复"。
|
||||
|
||||
**铁律**：只有在Maggie明确说"删掉旧的"/"清理"时才能删除。新版文件上传后旧版保留，不主动清理。
|
||||
|
||||
---
|
||||
|
||||
## Pitfall 33: K列关联关系的表述须有合同文本依据
|
||||
|
||||
**栽点（跃龙路·2026-07-03）**：K8写"物业方（范存益控制的东德物业）与出租方（范存益本人）实为关联方"。Maggie指出：合同只能证明他是联系人，不能证明他是股东/法定代表人/实控人。
|
||||
|
||||
**修正后写法**："出租方（范存益）同时为物业方（东德物业）的联系人，电话地址一致，两者可能存在关联关系，物业服务质量纠纷时需注意利益一致性。"
|
||||
|
||||
**铁律**：K列的每一句论断必须能在合同文本中找到直接依据。不能从合同文字推导出未经验证的法律事实（如"控制""实为"等断言）。
|
||||
|
||||
---
|
||||
|
||||
## 效率提升：H列付款推算可从汇总表数据直接推算
|
||||
|
||||
**场景**：Maggie确认"根据汇总表的信息是不是也可以推算？这样是不是效率高点？"
|
||||
|
||||
**方法**：H列已有支付方式（半年一付、提前X天）、租金标准、递增规则、物业费单价，G列有起止日期和免租期。这些信息足够直接推算每一期的金额和付款截止日，不需要每次回md原文。
|
||||
|
||||
**适用条件**：数据明确无歧义时直接从H/G列推算。只有遇到数据存疑（如附件分期跟正文对不上）才需要回md核实。
|
||||
|
||||
---
|
||||
|
||||
## H列月租换算写法统一（Maggie 2026-07-03）
|
||||
|
||||
月租换算一律用行内括号写法：写在租金标准那行括号里（如"年XX元（月租≈XX元）"），不单独另起一行。
|
||||
@@ -0,0 +1,141 @@
|
||||
# 旧表重做模式（2026-07-13 金飞达重做教训）
|
||||
|
||||
## 适用场景
|
||||
|
||||
当用户明确说：
|
||||
- “忽略之前做过的汇总表，重新开始”
|
||||
- “不要沿用旧表，重新做”
|
||||
- “旧表不作为依据，重新汇总和审查”
|
||||
|
||||
则本轮任务进入**旧表重做模式**。
|
||||
|
||||
## 核心规则
|
||||
|
||||
### 1. 旧表只可作为线索，不可作为数据来源
|
||||
旧表可以用于：
|
||||
- 找文件清单
|
||||
- 参考板块结构
|
||||
- 回忆历史模版比对方向
|
||||
- 辅助定位此前做过的合同组合
|
||||
|
||||
旧表**不可以**用于：
|
||||
- 直接复用 D~L 列文字
|
||||
- 直接复制付款推算
|
||||
- 直接沿用 K 列风险结论
|
||||
- 直接沿用 L 列差异表述
|
||||
|
||||
**铁律**：新表的 D~L 列内容必须回到现有 `_全文.md` / 合同原文重新生成。
|
||||
|
||||
---
|
||||
|
||||
### 2. 必须重新读取规则，不得默认“上次做法仍然对”
|
||||
开工前必须重新核读至少以下规则：
|
||||
- 输出格式基准（跃龙路/桃坞路）
|
||||
- K/L 分工规则
|
||||
- H 列付款推算规则
|
||||
- I 列类目覆盖规则
|
||||
- 07 模版逐条比对规则
|
||||
|
||||
原因：用户说“重新开始”，不仅是重做表，也是**重置旧判断**。不能因为“这个校区以前做过”就把旧格式、旧逻辑直接续上。
|
||||
|
||||
---
|
||||
|
||||
### 3. 排序和板块以本轮用户指令为准
|
||||
如果用户本轮明确指定：
|
||||
- “按租赁物分类”
|
||||
- “同一租赁物按签约时间排列”
|
||||
- “输出格式按照桃坞路校区”
|
||||
|
||||
则必须以本轮要求重排，不能沿用旧表的：
|
||||
- 按合同类型分组
|
||||
- 按 workflow 完成顺序排列
|
||||
- 按旧版人工习惯排序
|
||||
|
||||
**一句话**：旧表结构不是规范，用户这轮指令才是规范。
|
||||
|
||||
---
|
||||
|
||||
### 4. 先产出一份新的可验证成品，再继续精修
|
||||
重做时不要先陷入“必须一次做到极致”而迟迟不出成品。正确节奏：
|
||||
1. 基于现有 md 和原文先生成一份新的 xlsx
|
||||
2. 立即跑校验：
|
||||
- `kl-separation-check.py`
|
||||
- `i-column-coverage-check.py`
|
||||
- H 列人工四检
|
||||
3. 再针对暴露的问题做第二轮精修
|
||||
|
||||
这样可以先保证：
|
||||
- 有真实交付物
|
||||
- 有工具输出支撑
|
||||
- 后续优化有具体落点
|
||||
|
||||
---
|
||||
|
||||
### 5. I 列覆盖报警要区分“合同缺项”与“漏提取”
|
||||
`i-column-coverage-check.py` 报警后，不能机械追求“全部消警”。
|
||||
|
||||
尤其是以下合同：
|
||||
- 临时仓储合同
|
||||
- 简短补充协议
|
||||
- 只有价格/主体变更的协议
|
||||
|
||||
这类文本天然不具备完整的 21 类租赁主合同要素，报警可能是**合理报警**。
|
||||
|
||||
处理方式：
|
||||
- 主租赁合同：优先补足到阈值以上
|
||||
- 简短合同：人工核实“确实没有这些类目”后保留报警结论即可，不为过关硬凑内容
|
||||
|
||||
---
|
||||
|
||||
### 6. H 列付款时间必须独立重算
|
||||
用户如果特别点名“付款时间要推算”，则 H 列不能复用旧表付款描述，必须按现有条款重新算：
|
||||
- 首期付款区间
|
||||
- 后续期次
|
||||
- 先付后付 / 后付前置天数
|
||||
- 免租期是否并入首期
|
||||
- 物业费是否与租金同步结算
|
||||
- 补充协议是否改了原付款机制
|
||||
|
||||
**铁律**：哪怕旧表看起来“差不多”，也必须重算一遍。
|
||||
|
||||
---
|
||||
|
||||
### 7. K/L 列必须同步重建，不得“旧K旧L沿用”
|
||||
重做模式下最容易偷懒的地方就是 K/L 列。
|
||||
|
||||
但用户要求“重新开始”时：
|
||||
- **K 列**必须回到合同原文，重新做八维审查与提前退租分析
|
||||
- **L 列**必须重新按 07 模版逐条对照，不得只搬旧表结论
|
||||
|
||||
尤其当：
|
||||
- 合同排序变了
|
||||
- 板块结构变了
|
||||
- 同一租赁物的合同关系重新被识别了
|
||||
|
||||
旧 K/L 直接搬运会导致逻辑错位。
|
||||
|
||||
---
|
||||
|
||||
## 实务提示
|
||||
|
||||
### 推荐工作顺序
|
||||
1. 盘点本轮实际要纳入的新表文件清单
|
||||
2. 按用户要求先定板块结构和顺序
|
||||
3. 逐份回读 `_全文.md`
|
||||
4. 先写 D~J
|
||||
5. 再写 K（八维+提前退租）
|
||||
6. 再写 L（07 模版差异）
|
||||
7. 生成 xlsx
|
||||
8. 跑校验并修正
|
||||
|
||||
### 不推荐做法
|
||||
- 直接在旧 xlsx 上修修补补
|
||||
- 先复制旧表全文再逐格改
|
||||
- 默认旧 K/L 正确，仅小修
|
||||
- 用旧付款推算“参考一下就当新结果”
|
||||
|
||||
---
|
||||
|
||||
## 来源
|
||||
|
||||
2026-07-13 金飞达校区：用户明确要求“忽略之前做过的汇总表，重新开始”，并强调付款时间重新推算、八维审查不能忘、07 模版逐条比对、按租赁物分类和同一租赁物按签约时间排列。实践证明：正确做法是把旧表降级为线索源，而不是底稿源。
|
||||
@@ -0,0 +1,78 @@
|
||||
# 重做校区 Workflow（Maggie指出质量问题后）
|
||||
|
||||
> 2026-07-01 凤凰文化实证：Maggie发现OCR读取质量差→模版比对有错误→汇总表不准确，要求按workflow重做。
|
||||
|
||||
## 触发场景
|
||||
- Maggie看了汇总表后说"有问题"/"重新做"
|
||||
- 发现OCR误读导致模版比对结论错误
|
||||
- 发现关键字段（费率、单位、条款内容）与原件不符
|
||||
|
||||
## 流程（仍走完整闸门，不跳步）
|
||||
|
||||
### 1. 仍然跑闸门脚本
|
||||
```bash
|
||||
python3 scripts/campus-workflow-gate.py <校区名>
|
||||
```
|
||||
即使是重做，也跑闸门。这不是形式主义——重做时更容易因为"上次做过了"而跳步。
|
||||
|
||||
### 2. Step 1 聚焦 vision 修正
|
||||
- 不需要重跑 ocrmypdf 全篇（原始 OCR 文本已有）
|
||||
- **聚焦**：对乱码区域逐页 `pdftoppm → vision_analyze`，获取真实内容
|
||||
- **产出**：一份 OCR 修正说明文档（列出每处修正：原OCR读什么→实际是什么）
|
||||
- 修正说明存工作目录，后续 delegate_task 要引用
|
||||
|
||||
### 3. Step 2 delegate_task 必须携带 vision 修正值
|
||||
这是**最关键的差异**——重做时 subagent 读到的仍是同一份乱码 OCR 文件。
|
||||
|
||||
**错误做法**：只给 OCR 文件路径，期望 subagent 自己发现问题
|
||||
```python
|
||||
# ❌ subagent 会重复产出错误结论
|
||||
delegate_task(context="OCR路径: /tmp/.../租赁-OCR.md", ...)
|
||||
```
|
||||
|
||||
**正确做法**：在 context 中显式列出所有 vision 修正
|
||||
```python
|
||||
# ✅ subagent 会用修正值覆盖乱码
|
||||
delegate_task(
|
||||
context="""
|
||||
文件路径：
|
||||
- 07模版: /tmp/.../07模版-全文.txt
|
||||
- 租赁合同OCR: /tmp/.../租赁-OCR.md
|
||||
|
||||
关键修正信息（vision核实，OCR中这些地方有乱码需用修正版）：
|
||||
- 8.4条: 物业费为0.4元/㎡/天（不是/月），换算=12.167元/㎡/月
|
||||
- 8.5条: 水费4.2元/吨；电费=国家电价+0.53元/度服务费
|
||||
- 8.6条: 仅"物业期限=租赁期限"一句，不涉及网络电话
|
||||
- 第十条10.2: 租赁租金结算至合同解除日（无违约金条款）
|
||||
""",
|
||||
toolsets=["file", "terminal"]
|
||||
)
|
||||
```
|
||||
|
||||
### 4. Step 3-6 正常走
|
||||
- 用模板脚本(single-campus-builder.py)重新建表
|
||||
- 新表体现修正后的正确内容
|
||||
- K/L分工自检、格式卡口、H列四检照做
|
||||
- 存档时删除旧版、上传新版、files:scan
|
||||
|
||||
## 常见陷阱
|
||||
|
||||
| 陷阱 | 后果 | 防范 |
|
||||
|------|------|------|
|
||||
| 只改 xlsx 不重做比对 | L列仍是旧的错误内容 | 必须重新 delegate_task 做比对 |
|
||||
| delegate_task 不带修正值 | subagent 重复犯同样错误 | context 写清楚每一处修正 |
|
||||
| 认为"上次做过了所以快" | 跳步、漏检 | 跑闸门，贴todo，逐项打勾 |
|
||||
| 修正了物业费单位但忘改K列风险分析 | K列仍引用旧数据 | 全表重建，不手动patch |
|
||||
| 旧版xlsx没删 | Nextcloud有两个版本，Maggie看到旧的 | 上传新版前rm旧版 |
|
||||
|
||||
## 凤凰文化实证（2026-07-01）
|
||||
|
||||
发现的OCR问题：
|
||||
- 8.4: "0.4元/㎡/天" 被误读为 "0.4 a/R 元/㎡/月"（单位吞没）
|
||||
- 8.5: 严重乱码，水费4.2元/吨和电费+0.53元/度完全丢失
|
||||
- 8.6: 被错误描述为"网络电话防火门"（实为物业期限=租赁期限）
|
||||
- 8.7-8.8: 消防条款大段乱码
|
||||
- 第五条5.3: 水电逾期违约金万分之五/日不可读
|
||||
|
||||
修正方法：vision逐页精读第5-8页原始PDF，获取真实文本
|
||||
结果：31条模版比对差异（旧版25条），所有修正内容正确纳入
|
||||
@@ -0,0 +1,323 @@
|
||||
# 纯扫描件合同 OCR 配方（image-only PDF → 可读文本）
|
||||
|
||||
> 适用：南通新东方多数校区合同是**纯扫描件**——`pdftotext` 文字层字符数 ≈ 0（个位数），
|
||||
> 必须 OCR 才能读。人民中路、跃龙路实证此配方干净好用，优先于 deepseek_ocr 路径。
|
||||
|
||||
## 配方（tesseract 引擎，中英混排）
|
||||
|
||||
```bash
|
||||
# 1) ocrmypdf 给扫描件加文字层（force-ocr 强制重做，image-dpi 300 提清晰度）
|
||||
ocrmypdf -l chi_sim+eng --force-ocr --image-dpi 300 租赁.pdf 租赁-ocr.pdf
|
||||
# 2) pdftotext -layout 抽文本（-layout 保留表格的列对齐，读租金表/费用表更可靠）
|
||||
pdftotext -layout 租赁-ocr.pdf 租赁-OCR.md
|
||||
```
|
||||
|
||||
- `-l chi_sim+eng`：中文简体+英文，合同里身份证号/账号/英文条款都能认。
|
||||
- **为什么用 ocrmypdf 而非 deepseek/裸 tesseract**：① 一步产出**带文字层的 PDF**（后续 x2t 渲染、人工查阅都能用）；② `pdftotext -layout` 出来的文本**保留空间布局**，财务表格的列不会糊成一行；③ tesseract 对扫描合同的正文条款识别率足够高。
|
||||
- **大文件后台跑**：10MB+ 的扫描 PDF（如跃龙路租赁 10.9MB）OCR 要几分钟，写脚本 `terminal(background=true, notify_on_complete=true)`，发出后并行做别的（见 SKILL Pitfall 4）。
|
||||
- **验证**：OCR 后 `wc -c 租赁-OCR.md` 字符数应从 ~0 跳到**数千~数万**（人民中路租赁 8 页→31420 字符、物业 3 页→6111；跃龙路 6+6 页同量级）。仍是个位数=OCR 没生效，回查 ocrmypdf 报错。
|
||||
|
||||
## 两个必防的 OCR 失真（扫描件通病）
|
||||
|
||||
### ① 财务表格"大写金额"几乎必乱码 → 以阿拉伯数字为准
|
||||
正文条款 OCR 可读，但租金表里的**中文大写金额**（"壹拾壹万玖仟…"）常被识别成乱码（`SRSAU`、`SRSAUT SAAR` 之类）。处置：
|
||||
- **关键金额一律以阿拉伯数字栏为准**（如 `119,190.75`），大写乱码忽略，**不照抄乱码进表**。
|
||||
- 数额存疑/阿拉伯数字也不清 → 回原图 `vision_analyze` 核，或走金额数学交叉验证（不含税×(1+税率)=含税，见 SKILL「4d/数学交叉验证」）。
|
||||
|
||||
### ② 抬头/公司名乱码 → 裁高清局部图 vision 逐笔辨认 + 多处交叉核
|
||||
扫描件首页抬头（甲方/乙方公司全称）常因字号小/印章压字而 OCR 乱码，**且这是梳理表的关键基础项，不能蒙**。处置：
|
||||
```bash
|
||||
pdftoppm -png -f 1 -l 1 -r 400 租赁.pdf hd_p1 # 400dpi 高清渲染首页
|
||||
# python: PIL 裁抬头区(高度~4%-16%) → resize 宽1200 → 存 jpg quality≥90 (<400KB 防 vision 超时)
|
||||
```
|
||||
- 把抬头局部图喂 `vision_analyze`，要求**逐字辨认、看不清就明说哪个字看不清、禁止猜测填充**。
|
||||
- **多处交叉核**：公司名在合同里通常出现 3+ 处（抬头、第三条收付款户名、落款、骑缝章），用整页+高清局部两次独立辨认互证；**与旧梳理表/兄弟合同的记法对撞**——不一致就是该名称 OCR 不稳的信号，必须核到底。
|
||||
- 人民中路实证：旧表(0622)甲方记"南通琳大鞍房屋…"，本次 vision 高清逐笔辨认为"南通**森大蒂**房屋建设开发有限公司"（"森"=品字三木，确非"琳"），纠正了旧表的误识。**OCR 与旧表都可能错，回高清原图 vision 核才是真值。**
|
||||
|
||||
## ③ tesseract 空白输出救援：二值化（binarization）回退（2026-06-26 通州金鹰实证）
|
||||
|
||||
### 症状
|
||||
`ocrmypdf` 整份跑完，`pdftotext` 抽出来的文本**只有前几页、后几页完全空白**（80 字节的 `\f` 换页符）。拆出空白页单独 `tesseract` 直接读 PNG 也**一字不输出**——但 PNG 文件大小正常（2-3MB），`numpy` 统计非白像素 1000 万+，**页面有内容、只是 tesseract 读不出来**。
|
||||
|
||||
### 根因
|
||||
扫描件对比度低/底色不均/噪点多，tesseract 默认的灰度处理在纹理复杂的旧扫描件上找不到文字边界。
|
||||
|
||||
### 正解：二值化（threshold=128）→ tesseract
|
||||
```python
|
||||
from PIL import Image
|
||||
img = Image.open('page.png')
|
||||
gray = img.convert('L') # 灰度
|
||||
bw = gray.point(lambda x: 0 if x < 128 else 255, '1') # 阈值 128 二值化
|
||||
bw.save('page_bin.png')
|
||||
```
|
||||
```bash
|
||||
tesseract page_bin.png stdout -l chi_sim+eng
|
||||
```
|
||||
二值化后 tesseract 能正常识别，输出与正常 OCR 页面同质量。
|
||||
|
||||
### 必做步骤
|
||||
- 先 `pdftoppm -r 200 -png` 渲染空白页 → 二值化 → tesseract（通州金鹰 p4-p8 五页全救回）
|
||||
- **不要增加二值化阈值试错**——128 是标准阈值，低对比度扫描件用 128 即可；若 128 仍不输出，优先怀疑页面本身无文字（检查 `numpy` 非白像素数），而非阈值问题
|
||||
- 二值化后 OCR 出来的文本与正常 `ocrmypdf` 产出同质量，直接合并使用
|
||||
|
||||
## ④ 特定乱码字段核实：tesseract → browser_vision 降级链（2026-06-29 解放中路实证）
|
||||
|
||||
### 问题场景
|
||||
OCR/tesseract 能读出大部分合同文本，但**特定字段仍然乱码**（如"壹"被读成"过"、数字被吃0、条款号后的填空值模糊）。需要 vision 核实具体字符，但 `vision_analyze` 反复超时。
|
||||
|
||||
### 诊断：fitz 文字层检测
|
||||
```python
|
||||
import fitz
|
||||
doc = fitz.open('合同.pdf')
|
||||
for i in range(doc.page_count):
|
||||
text = doc[i].get_text()
|
||||
if not text.strip():
|
||||
print(f'Page {i+1}: 纯扫描页（无文字层）')
|
||||
else:
|
||||
print(f'Page {i+1}: {len(text)} chars')
|
||||
```
|
||||
纯扫描件 `fitz.get_text()` 返回空字符串 → 必须先 OCR。OCR 后的 PDF 有文字层但部分字符乱码 → 进入 vision 核实。
|
||||
|
||||
### vision_analyze 超时问题
|
||||
`vision_analyze` 对合同页面图片（即使压缩到 325KB/400×565px 的 72 DPI JPEG）**连续超时 5 次**（2026-06-29 解放中路实证）。全页 300 DPI PNG（2.5MB）更不用说。**不要反复重试 vision_analyze——它对这个场景不可靠。**
|
||||
|
||||
### 正解：tesseract 全页 + browser_vision 局部裁图
|
||||
|
||||
**第一层：tesseract 全页 OCR（已做，处理 90% 文本）**
|
||||
```bash
|
||||
# 300 DPI 渲染每页 → tesseract 逐页读
|
||||
python3 -c "
|
||||
import fitz
|
||||
doc = fitz.open('合同.pdf')
|
||||
for i in range(doc.page_count):
|
||||
pix = doc[i].get_pixmap(matrix=fitz.Matrix(300/72, 300/72))
|
||||
pix.save(f'page_{i+1}.png')
|
||||
"
|
||||
tesseract page_N.png stdout -l chi_sim+eng --psm 6
|
||||
```
|
||||
tesseract 对中文合同正文条款识别率高（解放中路第六条完整读出、第十二条大部分可读）。
|
||||
|
||||
**第二层：browser_vision 局部裁图（处理 tesseract 仍乱码的具体字符）**
|
||||
```python
|
||||
from PIL import Image
|
||||
# 1. 打开 300 DPI 页面图
|
||||
img = Image.open('page_3.png') # 2481x3510
|
||||
w, h = img.size
|
||||
# 2. 裁剪目标区域（如第12.1条第4项，约在页面25-35%高度）
|
||||
crop = img.crop((100, int(h*0.25), w-100, int(h*0.45)))
|
||||
# 3. 缩放到 600-800px 宽，存 JPEG quality=80
|
||||
crop_resized = crop.convert('RGB').resize(
|
||||
(600, int(crop.height * 600 / crop.width)), Image.LANCZOS)
|
||||
crop_resized.save('crop_target.jpg', 'JPEG', quality=80)
|
||||
```
|
||||
```
|
||||
# 4. browser_navigate file:///tmp/xxx/crop_target.jpg
|
||||
# 5. browser_vision 问具体问题（如"第4项中'拖欠租金累计达几个月的'数字是多少"）
|
||||
```
|
||||
|
||||
### 关键要点
|
||||
- **browser_vision 和 vision_analyze 是不同的后端**——browser_vision 通过浏览器截图+视觉模型，对小图片处理更稳定，本 session 一次成功
|
||||
- 裁图要**精准定位目标条款区域**，不要裁全页（太大）也不要裁太窄（缺上下文）
|
||||
- 问题要**具体**："第4项中拖欠租金累计达几个月的数字是什么"比"请读出全部文字"效果好
|
||||
- 中文大写数字（壹/贰/叁）在扫描件中常被 tesseract 误识为形近字，**必须 vision 确认**
|
||||
- 文件大小控制在 50-100KB（JPEG quality=75-80, 600px 宽），避免超时
|
||||
|
||||
### 完整降级链总结
|
||||
```
|
||||
fitz.get_text() 空 → ocrmypdf 全篇 OCR → pdftotext 取文本
|
||||
↓ tesseract 能读的 → 直接用
|
||||
↓ tesseract 乱码的具体字段 → 裁区域 + browser_vision
|
||||
↓ browser_vision 也超时 → 如实告诉 Maggie，请她核对原件
|
||||
↓ 绝不能 → 用旧表数据填 + 手动创建 checkpoint（Pitfall 39）
|
||||
```
|
||||
|
||||
## ⑤ 统一社会信用代码 OCR 乱码修复 + 网络交叉验证（2026-06-29 通大附+凤凰文化实证）
|
||||
|
||||
### 问题场景
|
||||
OCR 把统一社会信用代码中的英文字母部分读乱（如 `MA1NAEBX26` → `MA INAEBX26`，数字间插入空格；`MADQRFT66P` 被完整读出但无法确认是否正确）。`ocr-integrity-check.py` 将 3+ 连续大写字母匹配为"公司名乱码"——但信用代码中的字母部分是合法的。
|
||||
|
||||
### ocr-integrity-check.py 修复（已落地 2026-06-29）
|
||||
脚本增加信用代码排除逻辑：检测匹配到的字母序列前后是否有数字，有则判定为信用代码的一部分并跳过。
|
||||
|
||||
### 网络交叉验证技巧
|
||||
OCR 信用代码不完整时，用企查查/天眼查 web search 验证：
|
||||
```
|
||||
web_search: "公司全称" 统一社会信用代码
|
||||
```
|
||||
已验证案例：
|
||||
- 南通青创企业管理咨询有限公司：91320600MA1NAEBX26（企查查）
|
||||
- 南通新东方教育科技有限公司：91320602MADQRFT66P（校验位验证通过）
|
||||
- 南通业玖物业管理有限责任公司：企查查未查到（可能是小公司或名称细微差异），但 tesseract 重跑清晰读出
|
||||
|
||||
### 信用代码校验位验证
|
||||
```python
|
||||
weights = [1,3,9,27,19,26,16,17,20,29,25,13,8,24,10,30,28]
|
||||
chars = '0123456789ABCDEFGHJKLMNPQRTUWXY'
|
||||
code_map = {c:i for i,c in enumerate(chars)}
|
||||
total = sum(code_map[code[i]] * weights[i] for i in range(17))
|
||||
check = 31 - (total % 31)
|
||||
expected = chars[check] if check < len(chars) else '?'
|
||||
# expected == code[17] → 校验通过
|
||||
```
|
||||
|
||||
## ⑥ 签名页/签章区域乱码处理（2026-06-29 多校区实证）
|
||||
|
||||
### 问题场景
|
||||
合同最后 1-2 页（签名盖章页）OCR 产出大量无意义英文字母序列（`AAA`、`LIV`、`BREE`、`RUE`、`ANON` 等），是印章/手写签名/骑缝章被 OCR 引擎误识别的产物。
|
||||
|
||||
### 处理方式
|
||||
```python
|
||||
import re
|
||||
# 替换 3+ 连续大写字母为 [签章] 占位符
|
||||
lines[idx] = re.sub(r'[A-Z]{3,}', '[签章]', lines[idx])
|
||||
```
|
||||
|
||||
### 判断标准
|
||||
- 出现在签名页（通常最后 1-2 页）
|
||||
- 上下文含"甲方签字""乙方盖章""日期"等关键词
|
||||
- 这些区域不含合同实质条款，替换后不影响完整性检查
|
||||
- 替换后 `ocr-integrity-check.py` 不再报这些位置的问题
|
||||
|
||||
## ⑦ vision 全不可用时的 delegate_task 降级（2026-06-29 跃龙路实证）
|
||||
|
||||
### 问题场景
|
||||
`vision_analyze` 连续超时 7+ 次（即使图片压缩到 119KB JPEG），`browser_vision` 也间歇性超时。所有视觉工具在同一 session 中同时不可用。
|
||||
|
||||
### 正解：delegate_task 批量分发 OCR 核实
|
||||
```python
|
||||
delegate_task(tasks=[
|
||||
{"goal": "Read scanned contract page and transcribe ALL text. Focus on: ...",
|
||||
"toolsets": ["vision", "file"]},
|
||||
# 最多 3 个并行
|
||||
])
|
||||
```
|
||||
- **subagent 的 vision 后端可能与父 agent 不同**——同一时段父 agent vision 全挂，subagent 有 2/3 成功读取（跃龙路实证：task 1 超时但 task 2、3 成功）
|
||||
- **混合策略**：给每个 subagent 不同的页面 + 具体的提取目标（不要笼统"读全文"），提高单次成功率
|
||||
- **subagent 也超时时的兜底**：用已有 tesseract OCR 输出 + 上下文推理重建文本，标注哪些段落是推断而非 vision 确认的
|
||||
|
||||
### 关键要点
|
||||
- delegate_task 的 vision 调用走独立的模型实例，timeout 行为不总与父 agent 一致
|
||||
- 把最关键的乱码页（租金表、签名页、违约金条款）优先分配给 subagent
|
||||
- 返回结果里 subagent 会自报"vision failed, used OCR instead"——**检查 status 和 summary**，不能假设全部成功
|
||||
|
||||
## ⑧ 单位后缀误读（天→月、年→月等）——数学交叉验证必抓（2026-07-01 凤凰文化实证）
|
||||
|
||||
### 问题场景
|
||||
OCR 将"0.4元/㎡/**天**"误读为"0.4 a/R 元/㎡/月"——单位"天"被吞掉或变成乱码，导致后续模版比对报告错误地认为物业费(0.4元/月)与租金(12.167元/月)是两个不同标准。实际上：0.4元/天 × 365÷12 = **12.167元/月**，两者完全一致。
|
||||
|
||||
### 根因
|
||||
扫描件中"天"字笔画简单（仅3画），在低质量扫描+OCR识别中极易丢失或被误读为符号碎片（如"a/R"）。类似地，"月""年"等单位后缀也可能被吃掉。
|
||||
|
||||
### 检测方法：数学交叉验证
|
||||
合同中单价通常后面紧跟一个**月总额表格**。验证公式：
|
||||
```python
|
||||
stated_unit_price = 0.4 # OCR 读出的数字
|
||||
area = 562 # 面积
|
||||
table_monthly = 6837.854 # 表格中月费
|
||||
|
||||
# 如果是 元/㎡/月：
|
||||
if_monthly = stated_unit_price * area # 0.4 × 562 = 224.8 ≠ 6837.854 → 不匹配！
|
||||
# 如果是 元/㎡/天：
|
||||
if_daily = stated_unit_price * area * 365 / 12 # 0.4 × 562 × 30.417 = 6837.85 ✓ 匹配！
|
||||
```
|
||||
**匹配失败 = 单位被误读**。必须回原图 vision 确认真实单位。
|
||||
|
||||
### 铁律
|
||||
- 凡 OCR 读出单价+单位（元/㎡/月、元/㎡/天、元/吨等），必须用**表格中的月总额**做交叉验证
|
||||
- 不匹配时，优先怀疑单位被OCR吃掉/替换，而非合同本身矛盾
|
||||
- 模版比对报告中若涉及"费率标准不同"的结论，必须先过此验证
|
||||
|
||||
### 连锁影响
|
||||
此类误读会导致模版比对报告产出错误结论（如"物业费0.4元/月与租金12.167元/月**不同**"），进而误导汇总表K列风险判断。修正路径：OCR产出后、写比对报告前，所有涉及金额/费率的字段过一遍数学交叉验证。
|
||||
|
||||
## ⑨ OCR严重乱码段落对模版比对的污染（2026-07-01 凤凰文化8.5-8.8实证）
|
||||
|
||||
### 问题场景
|
||||
扫描件第6页8.5-8.8区域OCR产出如下乱码：
|
||||
```
|
||||
8.5 甲方按照部 门 标准 及水、电 指 和
|
||||
定为 :水 国家 电价 计收
|
||||
8.6 Fak ) 租赁 期限保持 一致
|
||||
```
|
||||
基于此写出的模版比对报告将8.5概括为"水电费按部门标准及国家电价计收"（丢失具体费率），将8.6描述为"网络、电话、防火门等配套设施约定"（完全搞错——8.6只是说物业期限=租赁期限，网络电话防火门内容在8.7-8.8）。
|
||||
|
||||
### 真实内容（vision核实）
|
||||
- **8.5**：水费按**4.2元/吨**计收；电费按**国家电价+0.53元/度服务费**（随国家调价联动）
|
||||
- **8.6**：物业服务期限与租赁期限一致，随解除/终止而终止（仅此一句）
|
||||
- **8.7-8.8**：消防远程联网、疏散楼梯、二消改造等详细消防义务
|
||||
|
||||
### 铁律
|
||||
- **模版比对报告中，每一条差异的描述必须基于可读的OCR文本或vision核实结果**
|
||||
- 如果某条款区域OCR输出含3+个连续乱码词（如"Fak""peMet iy ecsapae"），该区域必须先vision确认真实内容，再写入比对报告
|
||||
- **不得对乱码文本做"合理推测"后写入比对报告**——推测错误比留空更有害
|
||||
- 比对报告中遇到OCR不可读段落，标注"[OCR不可读，需原件核实]"比写错误描述强
|
||||
|
||||
## ⑩ 重做校区时 delegate_task 必须携带 vision 修正值（2026-07-01 凤凰文化实证）
|
||||
|
||||
### 问题场景
|
||||
发现OCR质量问题后重做某校区，重新发 delegate_task 让 subagent 做模版比对。如果 context 只给 OCR 文件路径，subagent 读到的仍是乱码文本，会重复产出错误结论（如"物业费0.4元/月"、"8.6为网络电话条款"）。
|
||||
|
||||
### 正解：在 delegate_task context 中显式列出所有 vision 修正
|
||||
```python
|
||||
delegate_task(
|
||||
goal="对比租赁合同与07模版，生成逐条差异清单...",
|
||||
context="""
|
||||
文件路径：
|
||||
- 07模版: /tmp/.../07模版-全文.txt
|
||||
- 租赁合同OCR: /tmp/.../租赁合同-OCR.md
|
||||
|
||||
关键修正信息（vision逐页核实，OCR中这些地方有乱码需用修正版）：
|
||||
- 8.4条: 物业费为0.4元/㎡/天（不是/月），换算=12.167元/㎡/月
|
||||
- 8.5条: 水费4.2元/吨；电费=国家电价+0.53元/度服务费
|
||||
- 8.6条: 仅"物业期限=租赁期限"一句，不涉及网络电话
|
||||
- ...
|
||||
""",
|
||||
toolsets=["file", "terminal"]
|
||||
)
|
||||
```
|
||||
|
||||
### 铁律
|
||||
- **OCR修正后重做比对 ≠ 只重发 delegate_task**——必须把修正值写进 context
|
||||
- subagent 不会自动跑 vision，它只能读文件；如果文件本身有乱码而 context 没给修正，subagent 就会按乱码理解
|
||||
- 修正信息的格式："条款号: 真实内容（不是XXX）"——明确标注哪里被误读、正确值是什么
|
||||
- 这同样适用于首次做比对时发现OCR乱码区域——先vision核实，再发subagent，context带修正值
|
||||
|
||||
## ⑪ OCR产出md文件事后核实流程（2026-07-13 桃坞路实证）
|
||||
|
||||
### 场景
|
||||
md文件已产出并保存，但用户（或后续任务）质疑准确度，需要系统性核实而非重跑OCR。
|
||||
|
||||
### 核实方法：vision逐页比对
|
||||
```bash
|
||||
# 1. 把PDF关键页渲染成图片（200dpi够用，关键是覆盖含数据的页面）
|
||||
pdftoppm -png -r 200 -f 1 -l 1 合同.pdf verify/p1
|
||||
pdftoppm -png -r 200 -f 2 -l 2 合同.pdf verify/p2
|
||||
# 2. vision_analyze 每张图，问具体数据点（金额、面积、日期、当事人）
|
||||
# 3. 与md文件对应段落逐项比对
|
||||
```
|
||||
|
||||
### 桃坞路4份合同核实发现的典型OCR失真模式
|
||||
|
||||
| 失真类型 | 频率 | 影响 | 处置 |
|
||||
|---------|------|------|------|
|
||||
| 封面公章区乱码（前10-16行） | 每份必现 | 不影响条款提取 | 可忽略 |
|
||||
| 大写金额全乱 | 物业合同必现 | 中等——引用时必须用小写数字 | 以阿拉伯数字为准（已有①） |
|
||||
| 收款账户段排版错乱 | 偶发 | 低——信息可拼凑 | 核对账号12位数字即可 |
|
||||
| 个别汉字形近误识（崇→喧、饰→4） | 偶发 | 低——不影响数据 | 已知正确值时直接修正 |
|
||||
| 手写填空处空白被OCR虚构文字 | 偶发 | 中——会产生虚假数据 | vision确认原件是否真的填写了 |
|
||||
|
||||
### 核实策略（效率优先）
|
||||
1. **不需逐字全文核对**——重点核对：金额、面积、日期、费率、百分比、当事人名称、账号
|
||||
2. **优先核对第2页**（通常含租金/期限/保证金等核心条款），封面页和签字页优先级最低
|
||||
3. **数学交叉验证仍是最快手段**：如首期=年租金÷2？物业年费=单价×面积×365？通过=可信
|
||||
4. **只需vision核对md中有乱码嫌疑的段落**——正常可读的中文条款OCR准确率>98%无需逐字核
|
||||
5. **结论模板**：核实后向用户报告"核心数据准确+已发现的具体问题列表"，让用户知道哪些可信哪些需注意
|
||||
|
||||
### 与全流程的关系
|
||||
- 新做校区：OCR后立即跑 `ocr-integrity-check.py`（自动检测乱码）→ 高危区vision核实 → 写入md
|
||||
- 事后核实（本场景）：直接 pdftoppm + vision 比对关键页，快速出结论
|
||||
- 两者互补：integrity-check 抓格式异常，vision比对抓语义错误（如空白处虚构文字）
|
||||
|
||||
## 与既有规则的关系
|
||||
- 这是「第一铁律·逐字通读」「OCR 不可信回原件核」在**扫描件取文本**环节的落地配方。
|
||||
- 费率符号（‰ vs %）的双跑/裁图核对走 `references/ocr-rate-symbol-verification.md`；本文管的是**整篇取文本 + 抬头/金额两类高频失真 + 二值化救援 + 信用代码修复 + 签章乱码处理 + 单位误读 + 乱码段落处理**。
|
||||
@@ -0,0 +1,48 @@
|
||||
# 世茂校区合同结构（2026-07-02 核实）
|
||||
|
||||
## 文件分布
|
||||
```
|
||||
世茂/
|
||||
├── 青少/
|
||||
│ ├── 世茂新租赁合同.pdf (26页, 纯扫描无文字层)
|
||||
│ └── 世茂物业合同.pdf
|
||||
├── 高中/
|
||||
│ ├── 3023新东方租赁合同-双签版.pdf (26页, 纯扫描无文字层)
|
||||
│ └── 世茂物业（高中）.pdf
|
||||
├── 世茂-梳理-MJ-20260626.xlsx
|
||||
└── 南通新东方-世茂校区租赁合同梳理-MJ-20260618.xlsx
|
||||
```
|
||||
|
||||
## 关键发现：两套合同为同一模版
|
||||
|
||||
青少和高中的租赁合同**逐字一致**（世茂制式），包括：
|
||||
- 页数相同（26页）
|
||||
- 条款编号对齐
|
||||
- **第八条（商铺维修）完全相同**
|
||||
|
||||
### 第八条核心条款（维修/渗漏相关）
|
||||
|
||||
| 条款 | 内容摘要 |
|
||||
|------|----------|
|
||||
| 8.1 | 非乙方原因→甲方/管理公司尽快维修；**乙方代修权**：甲方拒不维修→乙方可代修，费用按江苏省修缮定额由甲方承担。例外：玻璃隔断/卷闸门无论归属均乙方责任 |
|
||||
| 8.2 | 乙方正常使用+爱护内部设施；使用不当→乙方维修/赔偿 |
|
||||
| 8.3 | 小范围修缮须书面申请甲方批准 |
|
||||
| **8.4** | **甲方应确保商铺屋顶、墙壁、主要供水管道及动力电缆符合国家安全规范** |
|
||||
| 8.5 | 甲方保证电梯/消防/空调等公共设施正常 |
|
||||
| 8.6 | 甲方入户检查须事先书面通知+避开营业 |
|
||||
| 8.7 | 紧急情况可无通知强入（明显过错除外） |
|
||||
| 8.8 | 窗户/玻璃破损→乙方绝对责任（无论过错/保险） |
|
||||
|
||||
### 第十三条相关（甲方违约）
|
||||
- **13.4.3**：甲方未承担维修责任或支付维修费用，致使乙方无法继续租用→乙方可单方解约+索赔
|
||||
|
||||
## OCR注意事项
|
||||
- 两份租赁合同均为**纯扫描件**（fitz.get_text() 返回空）
|
||||
- 必须全量Vision逐页读取
|
||||
- 物业合同同理需确认是否有文字层
|
||||
|
||||
## 法律函件引用建议
|
||||
因两套合同维修条款完全一致，在起草维修通知/催告函时：
|
||||
- 可统一引用"《租赁合同》第八条第1款及第4款"（无需区分青少/高中版本）
|
||||
- 配合民法典第713条（出租人不履行维修义务→承租人可自行维修，费用由出租人负担）
|
||||
- 物业合同第5.1条亦有类似甲方维修义务约定
|
||||
@@ -0,0 +1,27 @@
|
||||
# 本 skill 的自维护：去重、消冲突、防膨胀（2026-06-23 Maggie 授权优化时确立）
|
||||
|
||||
## 为什么需要
|
||||
本 skill 是「一条条积累」起来的（每次 Maggie/Doro 纠正就追加一条），必然产生两类病：
|
||||
- **重复**：同一规则在多处各自展开，措辞还不完全一致 → 互相「打架」（人民中路 L 列出错的土壤之一）。
|
||||
- **膨胀**：996 行 / 151K 字节 / 24 个 `##` + 62 个 `###`。开工前光扫一遍就吃掉大量注意力 = **延迟源本身**。
|
||||
|
||||
## 安全去重方法（已验证，照此做）
|
||||
1. **先量化诊断，不靠感觉**：用 execute_code 按主题词聚类数重复次数（`text.count(关键词)`），找命中最高的几类（实测：标红 110、H列 102、OCR符号 63、Excel安全 61、模版 58）。
|
||||
2. **区分「规则本身」vs「技术细节展开」**：规则（标什么/不标什么、判据、退路）一字不留在正文；技术操作细节（XML 外科手术、五查步骤、命令配方、排查叙事）才下沉。⚠️ 关键词**嵌在规则正文里**的（如「4a 跨副本对撞」「违约金基数」）是规则，不是复读，**不能动**。
|
||||
3. **下沉前提：reference 已完整存着该规则**。先 `read_file` 确认真身在 reference 里，删正文复读才零风险。reference 不全的，先补全 reference 再删正文。
|
||||
4. **正文留最硬的铁律，细节进 reference**：如标红区保留 4 条硬铁律（唯一路径=WPS另存／红必须最后一步／二次编辑别 openpyxl 重存／别当测试员），把「试过哪些修法、怎么做 XML 手术、五查怎么验」下沉。开工扫一遍仍记得「怎么不踩坑」，动手时再翻 reference 拿完整配方。
|
||||
5. **改前备份**：`cp SKILL.md SKILL.md.bak_$(date +%Y%m%d_%H%M%S)`，改坏随时回滚。
|
||||
6. **dry-run 定边界再 patch**：先打印将删区块的首尾行 + 锚点唯一性校验（`find_line` 返回恰好 1 个），确认边界外的规则保留、脏 `\n` 字面转义字符一并清，再动手。
|
||||
7. **改后验收（逐项 grep，不凭印象说「改好了」）**：① 字节数变化（看 `wc -c` 不是行数）② 每条规则判据/退路/指针关键词仍在 ③ 脏字符清零 ④ reference 真身未动（行数不变）。
|
||||
|
||||
## 度量陷阱
|
||||
体量真实指标看**字节数**（`wc -c`），**不是行数**——中文 3 字节，标红那批行数只减 11 但字节减 9.5K(−6%)、标红主题命中 110→71。execute_code 的 `len(text)` 是 UTF-8 字符数（≈68K），与磁盘字节数（151K）差 ~2.2 倍，别混用两个口径报数。
|
||||
|
||||
## 🔴 已知设计冲突（2026-06-23 确认，修复需 Maggie 授权）
|
||||
**闸门脚本 `scripts/campus-workflow-gate.py` 把 Step2 吐成 `Step2-A 法律审查` / `Step2-B 提取分析` 两条串行 todo，与 SKILL.md 正文「动作A 法律审查 ‖ 动作B 提取分析 **并行**」的设计自相矛盾。** 我照串行 todo 逐项打勾 → 把本该并行的两件事做成串行（人民中路实证，是慢的根因之一）。
|
||||
- **正解**：Step2 开工**第一个动作 = 立刻 `delegate_task` 把动作B（提取+模版比对）甩到后台**，发出的同一秒自己开始读法律 → 两件事真并行。我是单线程，「不外包动作A」≠「串行做两件事」。
|
||||
- **修法（待授权）**：gate 脚本把 Step2-A/2-B 合成一条，并把「⚡先发 subagent 甩动作B」顶到 Step2 todo 最前。
|
||||
- **通则**：脚本吐出的 todo 与正文口径必须一致——改了正文流程设计，必须同步改 gate 脚本，否则脚本在物理上诱导我违背正文。
|
||||
|
||||
## 执行纪律权重失衡（设计层观察，提权需授权）
|
||||
核实类铁律在正文命中上百次，而「边说边做／动作与解说分轮」的执行纪律（Pitfall 23）只 11 次、埋在最末。几十条「多核实多写」在每个回合把我拽向「多写、边说边做」，是延迟的**系统性诱因**。实证：同样 77 行合同，前面反复「读不出来」耗 40 分钟，最后一条 `sed` 0.X 秒读完——慢在执行不在任务。提权方向：把执行纪律提到与「第一铁律·逐字通读」并列，并写明它优先于核实类铁律对单个回合的占用（核实照做，放到结果回来那一轮做，不和动作抢同一轮）。
|
||||
@@ -0,0 +1,23 @@
|
||||
# Step 0 盘点——配对检查铁律
|
||||
|
||||
## 教训来源
|
||||
世茂校区 2026-07-02：通知函只引了1份物业合同（217L0363b），被Maggie纠正"物业合同也是两份"。实际是2份租赁对应2份物业（青少217L0363a-1→217L0363b，高中217L0457a→217L0457b）。
|
||||
|
||||
## 规则
|
||||
每份租赁合同必须确认是否有对应的物业管理服务合同（同校区/同楼层/同租赁物）。
|
||||
|
||||
### 检查清单
|
||||
1. 列出所有租赁合同（按校区、楼层、面积分）
|
||||
2. 逐份找对应物业合同（合同编号通常有规律：a→b，a-1→b等）
|
||||
3. 确认配对关系后在盘点清单中标注：`租赁XXX ↔ 物业YYY`
|
||||
4. 如果有租赁合同找不到对应物业合同，标注为"待确认"——向客户询问
|
||||
|
||||
### 常见配对模式
|
||||
- 合同编号后缀：`a` / `a-1` = 租赁，`b` = 物业（世茂）
|
||||
- 同一校区多楼层 = 可能每层各一份租赁+物业
|
||||
- 扩租补充协议可能有单独的物业补充协议
|
||||
|
||||
### 漏配后果
|
||||
- 汇总表遗漏合同 → 返工
|
||||
- 法律文书（通知函、催告函）引用不完整 → 被纠正
|
||||
- 权利主张遗漏物业方义务 → 策略不完整
|
||||
+16
@@ -0,0 +1,16 @@
|
||||
# Step 1 快捷路径：复用已有提取文件
|
||||
|
||||
## 场景
|
||||
|
||||
该校区合同的 `_全文.md` 或 `_全文_OCR.md` 已存在于 Nextcloud 对应目录下——通常是因为之前为其他任务（如通知函起草、单条款查询、函件引用等）已做过 OCR/提取。
|
||||
|
||||
## 规则
|
||||
|
||||
1. **可直接复用**：不需要重新跑 OCR，不需要重新 marker-pdf 提取。已有文件即为 Step 1 产出。
|
||||
2. **仍需跑 garble-detect 验证**：`ocr-garble-detect.py` 必须跑一遍确认质量，高危乱码仍需 vision 消灭后才能进 Step 2。
|
||||
3. **判断标准**：文件存在 + garble-detect 通过 = Step 1 完成，可直接标记 step1.verified。
|
||||
4. **不适用情况**：如果文件明显是旧版/不完整（如只提取了部分页面、OCR 质量极差大面积乱码），仍需重做。
|
||||
|
||||
## 来源
|
||||
|
||||
2026-07-02 世茂校区开工时确认：四份合同（青少租赁/物业 + 高中租赁/物业）的全文 MD 均在之前做渗漏维修通知函时已提取完毕，Maggie 确认可直接复用避免重复工作。
|
||||
@@ -0,0 +1,34 @@
|
||||
# Step 1 跳过策略——复用已有OCR全文
|
||||
|
||||
## 适用条件
|
||||
当合同文件夹中已存在 `_全文.md` 或 `_全文_OCR.md` 文件时，Step 1 可以跳过OCR提取。
|
||||
|
||||
## 前提
|
||||
- MD文件确实是从对应PDF提取的（检查文件头注释/来源标注）
|
||||
- 文件修改日期不早于PDF修改日期（排除旧版本残留）
|
||||
|
||||
## 仍然必做
|
||||
即使跳过OCR提取，以下步骤**不能跳过**：
|
||||
|
||||
1. **Copy到工作目录**：`sudo docker exec cat ... > /tmp/<workdir>/`
|
||||
2. **跑 ocr-garble-detect.py**：扫全文乱码
|
||||
3. **高危行 vision 核实**：
|
||||
- TOC页（目录页）的乱码可以标记为"非实质"忽略
|
||||
- 附件表格（租金/面积/保证金）的乱码必须核实
|
||||
- 核心条款（维修/违约/解除）的乱码必须核实
|
||||
4. **关键财务数据交叉验证**：
|
||||
- 单价 × 面积 = 月租总额？
|
||||
- 不含税 × 税率 = 税金？
|
||||
- 保底租金 × 月数 ≈ 保证金？
|
||||
|
||||
## 实例
|
||||
世茂校区(2026-07-02)：4份合同MD文件都已存在，直接复用。garble检测结果：
|
||||
- 世茂新租赁：15处高危（主要在TOC+附件表格），vision确认核心条款完整
|
||||
- 世茂物业青少：6处高危
|
||||
- 高中租赁：18处高危
|
||||
- 高中物业：2处高危
|
||||
|
||||
关键发现：附件三（租金表）的OCR乱码虽然触发高危，但数字部分清晰可读，经vision确认后可进入Step 2。
|
||||
|
||||
## 时间节省
|
||||
跳过OCR约节省15-30分钟/份（扫描件OCR+后台处理时间）。4份合同合计节省约1-2小时。
|
||||
@@ -0,0 +1,73 @@
|
||||
# 汇总表复核/审计方法论
|
||||
|
||||
当 Maggie 要求"检查""核查""看看是否按规则做的"时使用。与建表不同：这是对已交付表格的逆向验证。
|
||||
|
||||
## 触发词
|
||||
|
||||
- "检查下XX的核心条款总结是否…"
|
||||
- "法律风险分析是否…逐字逐句审查的"
|
||||
- "付款时间有没有推算"
|
||||
- "是不是按照要点进行的"
|
||||
|
||||
## 审计流程
|
||||
|
||||
### 准备阶段
|
||||
1. 从 Nextcloud 拉取最新 xlsx（docker cp，禁用 /tmp 残留）
|
||||
2. 拉取对应的合同源文件（.md OCR全文），确保逐字可读
|
||||
3. Python 读取 xlsx 全部单元格内容
|
||||
|
||||
### H列审计
|
||||
1. **租赁合同行**：
|
||||
- 四检逐项验证（条款号、月租换算、付款推算、❗标注）
|
||||
- 计算验证：年租金÷2=半年期金额？免租分摊后数字对得上？递增率×base=下年数字？
|
||||
- 付款日期推算：每期起始日-提前天数=付款截止日？
|
||||
2. **物业合同行**：
|
||||
- 必须有逐期付款推算（不能只写费率+支付方式）
|
||||
- 物业费+公共能耗费=每期总额
|
||||
- 按年/季/半年结算周期列出每期金额+付款截止日
|
||||
- 电费等按实结算的写明计费标准即可
|
||||
3. **跨行一致性**：物业费在租赁合同H列提及的数字与物业合同H列一致
|
||||
|
||||
### I列审计
|
||||
1. **对照固定类目清单**：
|
||||
- 租赁合同21类目：用途/转租/装修改造/广告标识/非竞争/维修责任/保险要求/物业服务联动/配套设施/出租方变更/解除权机制/违约金机制/不可抗力/征收拆迁/房屋抵押查封/政策变化/到期处理/恢复原状/优先权/管辖/备案
|
||||
- 物业合同15类目：物业服务内容/服务标准/公共能耗费/特约服务/共用设施管理/装修管理/安保措施/消防安全/保险要求/联动终止/违约责任/退出交接/免责条款/不可抗力/管辖
|
||||
2. **逐类目核对**：合同原文有→I列是否覆盖？I列写了→条款号是否正确？
|
||||
3. **内容准确性**：I列摘述是否忠实于原文含义？有无曲解/遗漏关键限定词？
|
||||
|
||||
### K列审计
|
||||
1. **每项风险回溯原文**：K列每个风险点必须能在合同原文中找到直接文本支撑
|
||||
2. **计算验证**：如"年化182.5%"→0.5%×365=182.5% ✓
|
||||
3. **立场检查**：是否一致站乙方（新东方/承租方）立场？
|
||||
4. **遗漏扫描**：通读合同全文，有无明显对乙方不利的条款未被提及？
|
||||
- 常见遗漏项：签约主体错配（合同载明方≠实际盖章方）、签约日期空缺、面积约定模糊、付款方向歧义
|
||||
5. **证据纪律**：有无超出文本做确定性推断？（"联系人同名"→只能写"可能关联"不能写"控制"）
|
||||
|
||||
### L列审计
|
||||
1. 是否纯客观差异描述（无"风险""建议"等禁用词）
|
||||
2. 差异条目是否与合同原文一致（非凭记忆写的）
|
||||
3. 与K列无交叉（风险判断归K，客观差异归L）
|
||||
|
||||
## 输出格式
|
||||
|
||||
审计结果按以下结构报告：
|
||||
|
||||
```
|
||||
## [校区名]汇总表检查报告
|
||||
|
||||
### 一、[检查项名称]（❗缺失/✅准确/⚠️有遗漏）
|
||||
- 现状描述
|
||||
- 问题点
|
||||
- 建议动作
|
||||
|
||||
### 结论表
|
||||
| 检查项 | 状态 | 需要动作 |
|
||||
|--------|------|----------|
|
||||
| ... | ❌/✅/⚠️ | ... |
|
||||
```
|
||||
|
||||
## 注意事项
|
||||
|
||||
- 审计不是重做——只要数字/条款对得上就确认，不重新改写措辞
|
||||
- 发现问题后报告即可，不自动修改（等Maggie说"去补上"再动手）
|
||||
- 物业合同容易被忽略（因为"风险较低"），审计时必须同等重视
|
||||
@@ -0,0 +1,113 @@
|
||||
# 标准模版对比清单（房屋租赁合同）
|
||||
|
||||
> 🔴 **前置关卡（2026-07-01 凤凰文化教训）：比对前必须确认OCR文本可靠性。**
|
||||
> - 逐段扫描OCR输出，凡含3+连续乱码词的段落，必须先 vision 核实真实内容再写入比对报告
|
||||
> - 所有涉及**金额/费率+单位**的条款，必须做数学交叉验证（单价×面积=月总额？单位是天/月/年？）
|
||||
> - 典型案例：凤凰文化8.4条OCR读出"0.4元/㎡/月"实为"0.4元/㎡/**天**"（0.4×562×365/12=6837.854=表格月费，验证通过）
|
||||
> - 乱码段落不得做"合理推测"后写入报告——标注"[OCR不可读，需原件核实]"比写错误描述强
|
||||
> - 详见 `references/scanned-pdf-ocr-recipe.md` ⑧⑨ 两节
|
||||
|
||||
> ⚠️ **铁律（Maggie 2026-06-23，不可违背）：所有"与模版的比对"，一律以 `07- 房屋租赁合同.docx` 原件为唯一基准，必须打开模版原件逐条核对。**
|
||||
> - 禁止用"标准商业地产格式""星展商业格式""商业格式常见"等抽象概念当参照系 —— 那是凭印象的二手归纳，不是模版比对。
|
||||
> - 禁止拿本 checklist 的归纳条款当模版替身 —— 本清单只是导航，真值在模版 docx 里。每次比对都要回原件读真身。
|
||||
> - 教训来源：悦拾光、人民中路两份梳理表的 L 列最初都用"商业格式"概念写差异，未回 07 原件，被 Maggie 两次纠正。模版原件位置见下。
|
||||
> - 模版原件取法：`docker cp nextcloud-nextcloud-1:"/var/www/html/data/admin/files/小Maggie协作区/南通新东方/参考文件/07- 房屋租赁合同.docx" /tmp/xxx/07模版原件.docx`（注意 `07-` 后有一个空格）
|
||||
|
||||
> 🔴🔴 **K列法律风险 vs L列模版差异——下笔分工铁律（Maggie 2026-06-24 人民中路 K/L 混淆纠正）**：本清单产出的差异**只进 L列**，**绝不**拿来当 K列法律风险的论证。两列指向同一条款也要各写各的：
|
||||
> | | K列（法律风险·独立审查） | L列（模版差异·纯文本对比） |
|
||||
> |---|---|---|
|
||||
> | 参照系 | 法律+司法实践，**与模版无关** | 07 模版原件 |
|
||||
> | 起笔 | "本合同第X条这样约定→对乙方什么后果→怎么改" | "第X条：模版表述为【原文】；本合同表述为【原文】" |
|
||||
> | 禁止字样 | 模版/07/被放宽/被删除/被改为 | 风险/不利/建议/应/需关注/详见K列 |
|
||||
> | 自检 | grep "模版\|07" = 0 | grep "风险\|建议\|不利\|详见" = 0 |
|
||||
> - **遮模版测试**：把"模版怎么写"整个遮住，K列那条风险论述**仍完整成立**才算独立审查；遮住就垮 = L列逻辑混进了 K列。
|
||||
> - ✅ K列正例：「本合同约定甲方可将租赁标的抵押或出典（第八条1款）。租赁期间一旦抵押权被实现或标的被司法拍卖，可能影响乙方正常使用…建议约定租赁期间不得抵押/出典。」
|
||||
> - ✅ L列正例：「第八条1款：模版表述为'甲方不得将租赁标的进行财产抵押或出典'；本合同表述为'甲方可将租赁标的进行财产抵押或出典'。」（不加任何评价）
|
||||
> - ❌ 反例（已废，两件事混了）：K列写「抵押限制被放宽：07模版'不得抵押'→本合同'可抵押'」← 用模版差异驱动风险，应改成上面 K列正例的写法。
|
||||
|
||||
模版文件：参考文件/07- 房屋租赁合同.docx
|
||||
|
||||
## 逐条对比导航（仅供定位条款位置；每条的具体内容、措辞、数值一律以 07 原件为准，不得拿本清单的归纳当模版真值）
|
||||
|
||||
### 第一条 租赁标的
|
||||
- [ ] 甲方保证合法出租权+提供权证
|
||||
- [ ] 建筑面积/使用面积明确
|
||||
- [ ] 供电功率保证（不放核心内容栏，仅配套设施）
|
||||
|
||||
### 第二条 租赁期限及房屋用途
|
||||
- [ ] 免租期约定
|
||||
- [ ] 用途：办公、教学及相关经营
|
||||
- [ ] 可转租给关联单位（需甲方书面同意）
|
||||
|
||||
### 第三条 房屋租金
|
||||
- [ ] 租金构成说明（"租金包括…"）
|
||||
- [ ] **发票条款**：甲方未提供合规发票→乙方可延付且不违约
|
||||
- [ ] 发票虚假/失效→损失由甲方承担
|
||||
- [ ] 乙方开票账户信息
|
||||
|
||||
### 第四条 租赁押金
|
||||
- [ ] **押金退还范围**：期满/解除/终止后X工作日内全退
|
||||
- [ ] 押金收据遗失说明函条款
|
||||
|
||||
### 第五条 物业服务费及其他
|
||||
- [ ] 水电按独立计数表+国家标准
|
||||
- [ ] 法定税费由甲方承担
|
||||
- [ ] 除明确约定外不再支付其他费用
|
||||
|
||||
### 第六条 房屋维修、装修
|
||||
- [ ] 甲方维修义务+代为维修+抵消租金
|
||||
- [ ] 维修拖延违约金（日租金/日，15日以上可解除）
|
||||
- [ ] **消防条款**：符合国家标准+通过验收+证明文件一致
|
||||
|
||||
### 第七条 出租方的变更
|
||||
- [ ] 转让所有权须提前X天通知
|
||||
- [ ] 新所有者继续履行本合同+补充协议
|
||||
|
||||
### 第八条 房屋的抵押、转租、续租
|
||||
- [ ] **甲方禁止抵押**出租房屋
|
||||
- [ ] 续租通知期：**1个月**（注意偏差）
|
||||
- [ ] 甲方不答复视为同意续租
|
||||
- [ ] 看房权：须**征得乙方同意**（注意是否降级为"通知"）
|
||||
|
||||
### 第九条 优先权
|
||||
- [ ] 优先承租权
|
||||
- [ ] 优先购买权
|
||||
|
||||
### 第十条 合同解除、违约责任 ⭐ 重点
|
||||
- [ ] **10.2 任意解除权**：提前X天书面通知+年租金X%违约金+**"除法定或本合同约定外"限定**
|
||||
- [ ] **10.3 甲方终止**：年租金X%违约金+全额退押金+退预付款+装修损失(总造价÷总期间×未用期间)+**诉讼费律师费**
|
||||
- [ ] **10.4 逾期付款**：0.1‰/日+15日逾期+催缴后X日→可解除。注意OCR可能将‰误识为%
|
||||
- [ ] 10.5 甲方管理不善→赔损失+**严重影响→可解除且不违约**
|
||||
- [ ] 10.6 甲方迟延交付→日租金违约金+**免租期/起租日顺延**
|
||||
|
||||
### 第十一条 不可抗力 ⭐ 重点
|
||||
- [ ] 范围含：地震、台风、大火、战争、**疫情**、**政府政策变更**
|
||||
- [ ] 11.3 **行业治理**：乙方可要求减免租金**或延长租期**
|
||||
- [ ] 严重影响→乙方可解除且**不构成违约**
|
||||
- [ ] 是否有"公证机构出具证明"额外举证要求（不利）
|
||||
|
||||
### 第十二条 合同的变更、解除或终止
|
||||
- [ ] 变更须双方协商一致+书面形式
|
||||
- [ ] 政府征用/拆迁→详细退还义务+装修赔偿归乙方
|
||||
- [ ] 迁离标准：按**现状**交付（注意是否变为"保持原状"→可能有恢复原状义务）
|
||||
- [ ] **12.4 办学许可证**：房屋本身原因+政策原因→免责解除+退押金+退预付款
|
||||
|
||||
### 第十三条 法律适用与争议
|
||||
- [ ] 租赁房屋所在地法院管辖
|
||||
|
||||
### 第十四条 附则
|
||||
- [ ] 甲方X日内办理租赁备案+**不配合→乙方可解除+赔偿**
|
||||
- [ ] **非竞争条款**：大楼+商圈不租给同类机构
|
||||
- [ ] 反商业贿赂举报条款
|
||||
- [ ] 补充条款是否填写（有些合同填"无"→缺少办学保障）
|
||||
|
||||
### 附加条款
|
||||
- [ ] 装修改造条款
|
||||
- [ ] 标识设置及广告位
|
||||
- [ ] 配套设备（增容等）
|
||||
|
||||
## 对比结果分类
|
||||
- 🔴 重大缺失/偏离（任意解除权缺失、不可抗力范围窄、办学许可证缺失）
|
||||
- 🟡 中等差异（续租通知期延长、看房权降级、非竞争范围缩小）
|
||||
- 🟢 基本一致
|
||||
- ⚪ 形式差异（份数等）
|
||||
@@ -0,0 +1,50 @@
|
||||
# 提前退租风险分析框架——法律依据与实务要点
|
||||
|
||||
> 源自万达校区提前退租法律意见书（2026.5.6出具），适用于江苏地区租赁合同。
|
||||
|
||||
## 核心法律依据
|
||||
|
||||
### 1. 违约损害赔偿
|
||||
**《民法典》第584条**：当事人一方不履行合同义务或者履行合同义务不符合约定，造成对方损失的，损失赔偿额应当相当于因违约所造成的损失，包括合同履行后可以获得的利益；但是，不得超过违约一方订立合同时预见到或者应当预见到的因违反合同可能造成的损失。
|
||||
|
||||
### 2. 合同解除后的清算
|
||||
**《民法典》第566条第1款**：合同解除后，尚未履行的，终止履行；已经履行的，根据履行情况和合同性质，当事人可以请求恢复原状或者采取其他补救措施，并有权请求赔偿损失。
|
||||
|
||||
### 3. 非金钱债务不适于强制履行
|
||||
**《民法典》第580条**：当事人一方不履行非金钱债务或者履行非金钱债务不符合约定的，对方可以请求履行，但是有下列情形之一的除外：（一）法律上或者事实上不能履行；（二）债务的标的不适于强制履行或者履行费用过高；（三）债权人在合理期限内未请求履行。
|
||||
|
||||
> 租赁合同中承租人使用房屋的义务属非金钱债务，法院通常认为"不适于强制履行"。
|
||||
|
||||
### 4. 空置期损失上限（江苏地区）
|
||||
**《江苏省高级人民法院关于审理城镇房屋租赁合同纠纷案件若干问题的意见》第26条**：因承租人违约行为导致房屋租赁合同解除的，出租人可以要求承租人赔偿租赁房屋闲置期间的租金损失，但最长不得超过六个月。
|
||||
|
||||
> 实际支持金额取决于：房屋实际空置时间、甲方是否积极减损（减损义务）
|
||||
|
||||
## 分析模板
|
||||
|
||||
### 确定责任
|
||||
| 项目 | 金额 | 依据 |
|
||||
|------|------|------|
|
||||
| 押金没收（如合同约定） | X元 | 合同第X条 |
|
||||
| 约定违约金（如适用） | X元 | 合同第X条 |
|
||||
|
||||
### 不确定责任（需甲方举证）
|
||||
| 项目 | 金额范围 | 依据 |
|
||||
|------|----------|------|
|
||||
| 空置期租金损失 | 0 ~ 月租金×6 | 江苏高院意见第26条 |
|
||||
| 免租期租金追偿 | 0 ~ 免租期租金 | 司法实践酌情 |
|
||||
| 恢复原状费用 | 视装修情况 | 合同迁离条款 |
|
||||
|
||||
### 可收回金额
|
||||
| 项目 | 金额 | 依据 |
|
||||
|------|------|------|
|
||||
| 已付未使用租金 | X元 | 民法典第566条 |
|
||||
|
||||
> 违约金/损失赔偿与已付未使用租金应相互抵扣后计算净额。
|
||||
|
||||
## 关键判断点
|
||||
|
||||
1. **违约金条款是否覆盖主动退租**：很多合同的违约金仅列举特定违约情形（欠租、擅自转租等），"无故提前退租"不在列举范围内→违约金标准不能直接适用→需依据实际损失主张
|
||||
2. **免租期追偿的争议**：免租期优惠的前提是完整履行租期，提前退租时甲方可主张追偿，但法院会酌情处理，不一定全额支持
|
||||
3. **恢复原状vs按现状交付**：注意区分合同约定——"恢复原始结构"意味着需拆除装修，"按现状交付"则无此义务
|
||||
4. **继续履行风险**：极低。江苏地区法院一致态度——承租人已明确不再租赁甚至已搬离的，即使出租人坚持要求继续履行，法院通常直接判决解除+违约责任
|
||||
@@ -0,0 +1,65 @@
|
||||
# UWF Workflow Pitfalls for nantong-lease-audit
|
||||
|
||||
**Last updated**: 2026-06-30
|
||||
|
||||
## Pitfall 1: File Name Collision — Multiple Contracts per Campus
|
||||
|
||||
The `nantong-lease-audit` workflow writes output to:
|
||||
```
|
||||
/tmp/nantong-lease-audit/{{ campus }}-row-data.json
|
||||
```
|
||||
|
||||
When a campus has **multiple contracts** (e.g., 租赁 + 物业), running both contracts through the workflow causes the second to **overwrite** the first's JSON file.
|
||||
|
||||
**Discovered**: 通州金鹰 — 租赁合同 wrote `通州金鹰-row-data.json`, then 物业合同 overwrote it.
|
||||
|
||||
**Fix**: When running multiple contracts for the same campus:
|
||||
1. Run them sequentially (not in parallel) — OR —
|
||||
2. After each workflow completes, rename/copy the output before starting the next:
|
||||
```bash
|
||||
# After lease contract workflow completes:
|
||||
cp /tmp/nantong-lease-audit/通州金鹰-row-data.json \
|
||||
/tmp/nantong-lease-audit/通州金鹰-租赁-row-data.json
|
||||
# Then run property contract workflow (will overwrite 通州金鹰-row-data.json)
|
||||
```
|
||||
3. When building the xlsx, read both JSON files separately
|
||||
|
||||
**Current workaround used**: Read the lease contract data from CAS step output (`uwf step show <hash>`) if the JSON was overwritten, then manually reconstruct the property contract data.
|
||||
|
||||
## Pitfall 2: Workflow Prompt Variable Not Passed
|
||||
|
||||
The classifier role's moderator instruction shows empty values:
|
||||
```
|
||||
分类合同。OCR文本路径：，校区：，原始文件名：
|
||||
```
|
||||
|
||||
This happens when the `ocr_path`, `campus`, and `filename` variables are not properly interpolated from the thread start prompt. The classifier still works because the OCR path is in the task context, but the moderator prompt looks incomplete.
|
||||
|
||||
**Root cause**: The thread start prompt uses Chinese colons `：` which may not match the YAML template variable syntax. Current workaround: the classifier reads the OCR path from the task context anyway.
|
||||
|
||||
## Pitfall 3: Workflow v1 → v2 Hash Change
|
||||
|
||||
When the workflow YAML is updated and re-registered:
|
||||
- Old hash: `7KZ5BWT12R5RJ` (v1, no format templates)
|
||||
- New hash: `C77579MQ9QPKE` (v2, with H/K/L format templates + reference loading)
|
||||
|
||||
Threads started before the update continue using the old hash. Always verify which hash is active:
|
||||
```bash
|
||||
uwf workflow show nantong-lease-audit # Shows current hash
|
||||
```
|
||||
|
||||
## Pitfall 4: Background Exec Returns "Step 1 running"
|
||||
|
||||
When using `uwf thread exec <id> --count 20 --background`, the foreground output may show only:
|
||||
```
|
||||
Step 1 classifier → running
|
||||
```
|
||||
|
||||
This does NOT mean only step 1 ran. The background worker continues processing all steps. Check actual progress with:
|
||||
```bash
|
||||
uwf step list <thread-id>
|
||||
uwf thread show <thread-id>
|
||||
```
|
||||
|
||||
Expected progression: classifier → template-diff → rule-analyzer → data-extractor → end.
|
||||
Total time: ~15-20 minutes for all 4 steps.
|
||||
+63
@@ -0,0 +1,63 @@
|
||||
# 金飞达纠偏：workflow执行纪律（2026-07-13）
|
||||
|
||||
## 背景
|
||||
|
||||
在多校区租赁梳理任务中，出现过一种错误执行方式：先由主线程把 H/I/K/L 全部快速拼一版，再补做 subagent 模版对比和细化。这种做法与既定 workflow 冲突。
|
||||
|
||||
## 正确 workflow 分工
|
||||
|
||||
### 主线程（小Maggie本人）
|
||||
负责：
|
||||
1. 通读合同全文
|
||||
2. 做 **K列独立法律风险审查**
|
||||
3. 写 **提前退租法律后果**
|
||||
4. 最终整合 H/I/K/L 进入总表
|
||||
|
||||
### 独立 subagent
|
||||
负责：
|
||||
1. **L列07模版对比**
|
||||
2. 只输出“07模版怎么写 / 本合同怎么写”的客观差异
|
||||
3. 禁止掺入风险、不利、建议等判断词
|
||||
|
||||
### 可选独立 subagent
|
||||
负责：
|
||||
1. **H列+I列** 草稿
|
||||
2. H列付款推算和I列核心条款提炼
|
||||
3. 但最终仍由主线程统一核表
|
||||
|
||||
## 正确顺序
|
||||
|
||||
1. 盘点文件，按租赁物分类
|
||||
2. 读取/确认全文 md 可用
|
||||
3. **主线程做K列**
|
||||
4. **subagent并行做L列**
|
||||
5. H/I同步完成
|
||||
6. 汇总成表
|
||||
7. 跑 K/L 分离检查 + I列覆盖检查 + H列四检
|
||||
|
||||
## 禁止顺序
|
||||
|
||||
- ❌ 主线程先自己把 H/I/K/L 全部搭一版，再说“后面精修”
|
||||
- ❌ 先出总表骨架，再补起 subagent 的模版对比
|
||||
- ❌ 用“我知道workflow”代替“我已经按workflow执行”
|
||||
|
||||
## 原因
|
||||
|
||||
### 1. 防止K列被L列逻辑污染
|
||||
错误思路：
|
||||
> 因为和07不一样，所以有风险
|
||||
|
||||
正确思路：
|
||||
> 合同原文这样约定 → 对乙方有什么法律后果 → 风险是什么
|
||||
|
||||
### 2. 防止L列掺入法律判断
|
||||
L列必须保持纯客观。若由主线程在做K列的同时顺手做L列，极易把“风险”“不利”“建议”带入L列。
|
||||
|
||||
### 3. 这种任务不接受“阶段性交付思维”
|
||||
多校区租赁梳理不是“先拼骨架、后慢慢补”的任务。第一次产出就应按完整 workflow 落地，否则很容易在后补过程中混列、漏审、逻辑串位。
|
||||
|
||||
## 实务口令
|
||||
|
||||
> 我做K列独立法律审查的同时，subagent做L列模版对比；H/I同步处理；最后统一核表。
|
||||
|
||||
这句话是该类任务的 workflow 核心。
|
||||
@@ -0,0 +1,228 @@
|
||||
#!/usr/bin/env python3
|
||||
# -*- coding: utf-8 -*-
|
||||
"""
|
||||
南通新东方租赁梳理 — 批量 Excel Builder
|
||||
========================================
|
||||
从所有已完成的 nantong-lease-audit workflow threads 中提取数据，
|
||||
按校区分 sheet，合并到一个工作簿。
|
||||
|
||||
用法：
|
||||
python3 batch-excel-builder.py <输出xlsx路径>
|
||||
|
||||
例：
|
||||
python3 batch-excel-builder.py /tmp/南通-workflow-batch.xlsx
|
||||
|
||||
前置：所有thread已跑完（status=end）。
|
||||
"""
|
||||
import subprocess, json, re, sys, os
|
||||
|
||||
UWF = "/home/maggie/.hermes/node/bin/uwf"
|
||||
|
||||
def run(cmd):
|
||||
r = subprocess.run(cmd, capture_output=True, text=True)
|
||||
return r.stdout
|
||||
|
||||
def get_thread_read(thread_id):
|
||||
"""获取thread完整markdown输出（需要大quota）"""
|
||||
return run([UWF, "thread", "read", thread_id, "--quota", "200000", "--start"])
|
||||
|
||||
def get_all_nantong_threads():
|
||||
"""Get all completed nantong-lease-audit threads"""
|
||||
r = subprocess.run([UWF, "workflow", "list"], capture_output=True, text=True)
|
||||
# Find nantong-lease-audit hash(es)
|
||||
wf_hashes = []
|
||||
for line in r.stdout.strip().split('\n'):
|
||||
if 'nantong-lease' in line.lower():
|
||||
parts = line.split()
|
||||
if len(parts) >= 2:
|
||||
wf_hashes.append(parts[1])
|
||||
|
||||
if not wf_hashes:
|
||||
print("No nantong-lease-audit workflow found")
|
||||
return []
|
||||
|
||||
r = subprocess.run([UWF, "thread", "list", "--all"], capture_output=True, text=True)
|
||||
threads = []
|
||||
for line in r.stdout.strip().split('\n'):
|
||||
for h in wf_hashes:
|
||||
if h in line:
|
||||
parts = line.split()
|
||||
if len(parts) >= 3 and parts[2] == 'end':
|
||||
threads.append(parts[0])
|
||||
return threads
|
||||
|
||||
def get_thread_info(thread_id):
|
||||
"""Get campus and filename from thread prompt"""
|
||||
text = run([UWF, "thread", "read", thread_id, "--quota", "500"])
|
||||
campus_m = re.search(r'校区：(\S+)', text)
|
||||
file_m = re.search(r'合同文件：([^|]+)', text)
|
||||
ocr_m = re.search(r'OCR文本路径：(\S+)', text)
|
||||
return {
|
||||
'campus': campus_m.group(1) if campus_m else '',
|
||||
'filename': file_m.group(1).strip() if file_m else '',
|
||||
'ocr_path': ocr_m.group(1) if ocr_m else '',
|
||||
}
|
||||
|
||||
def extract_step_output(thread_text, role_name):
|
||||
"""Extract <output> content from a specific role step"""
|
||||
pattern = rf'## Step \d+: {role_name}.*?\n<output>\n(.*?)\n</output>'
|
||||
m = re.search(pattern, thread_text, re.DOTALL)
|
||||
return m.group(1) if m else ""
|
||||
|
||||
def extract_frontmatter(output_text):
|
||||
"""Extract YAML frontmatter fields from step output"""
|
||||
m = re.search(r'^---\n(.*?)\n---', output_text, re.DOTALL)
|
||||
if not m:
|
||||
return {}, output_text
|
||||
fm_text = m.group(1)
|
||||
body = output_text[m.end():].strip()
|
||||
result = {}
|
||||
current_key = None
|
||||
current_val = []
|
||||
is_multiline = False
|
||||
for line in fm_text.split('\n'):
|
||||
if not line.strip():
|
||||
if is_multiline: current_val.append('')
|
||||
continue
|
||||
km = re.match(r'^(\w[\w_]*):\s*(.*)', line)
|
||||
if km and not line.startswith(' '):
|
||||
if current_key: result[current_key] = '\n'.join(current_val).strip()
|
||||
current_key = km.group(1)
|
||||
val = km.group(2).strip()
|
||||
if val == '|' or val == '':
|
||||
is_multiline = True
|
||||
current_val = []
|
||||
else:
|
||||
is_multiline = False
|
||||
current_val = [val]
|
||||
elif is_multiline and current_key:
|
||||
current_val.append(line.strip())
|
||||
if current_key: result[current_key] = '\n'.join(current_val).strip()
|
||||
return result, body
|
||||
|
||||
def build_campus_sheet(wb, campus, rows):
|
||||
"""Build a campus sheet with all contract rows"""
|
||||
import openpyxl
|
||||
from openpyxl.styles import Font, PatternFill, Alignment, Border, Side
|
||||
|
||||
F = Font(name='微软雅黑', size=10)
|
||||
FB = Font(name='微软雅黑', size=10, bold=True)
|
||||
TITLE_FONT = Font(name='微软雅黑', size=14, bold=True, color='FFFFFFFF')
|
||||
fill_title = PatternFill(start_color='FF8B1A2B', fill_type='solid')
|
||||
fill_sec = PatternFill(start_color='FFC0504D', fill_type='solid')
|
||||
fill_hdr = PatternFill(start_color='FFE2EFDA', fill_type='solid')
|
||||
fill_sub = PatternFill(start_color='FFF2F2F2', fill_type='solid')
|
||||
thin = Side(style='thin')
|
||||
border = Border(left=thin, right=thin, top=thin, bottom=thin)
|
||||
AL = Alignment(horizontal='left', vertical='top', wrap_text=True)
|
||||
AC = Alignment(horizontal='center', vertical='center', wrap_text=True)
|
||||
|
||||
ws = wb.create_sheet(campus[:31])
|
||||
widths = dict(A=5, B=20, C=17, D=27, E=23, F=9, G=21, H=36.33, I=34, J=8, K=50, L=35)
|
||||
for c, w in widths.items():
|
||||
ws.column_dimensions[c].width = w
|
||||
|
||||
def merge_row(r, text, font, fill, h=None, al=AC):
|
||||
ws.merge_cells(f'A{r}:L{r}')
|
||||
cell = ws.cell(r, 1, text); cell.font = font; cell.fill = fill; cell.alignment = al
|
||||
for col in range(1, 13):
|
||||
ws.cell(r, col).fill = fill; ws.cell(r, col).border = border
|
||||
if h: ws.row_dimensions[r].height = h
|
||||
|
||||
r = 1
|
||||
merge_row(r, f'{campus}校区 — 租赁合同梳理', TITLE_FONT, fill_title, 30); r += 1
|
||||
merge_row(r, f'共{len(rows)}份合同',
|
||||
Font(name='微软雅黑', size=10, bold=True, color='FF404040'), fill_sub, 76, AL); r += 1
|
||||
|
||||
HDR = ['序号','文件名称','合同类型','合同当事人','租赁标的/服务范围','面积(㎡)',
|
||||
'合同期限','金额/费用','核心内容','当前状态','法律风险（站乙方立场）','与07标准模版差异']
|
||||
for ci, h in enumerate(HDR, 1):
|
||||
c = ws.cell(r, ci, h); c.font = FB; c.fill = fill_hdr; c.alignment = AC; c.border = border
|
||||
ws.row_dimensions[r].height = 30; r += 1
|
||||
|
||||
for idx, row in enumerate(rows, 1):
|
||||
ws.cell(r, 1, str(idx)).font = F; ws.cell(r, 1).alignment = AC; ws.cell(r, 1).border = border
|
||||
for ci, col in enumerate('BCDEFGHIJKL', 2):
|
||||
c = ws.cell(r, ci, row.get(col, '')); c.font = F; c.alignment = AL; c.border = border
|
||||
ws.row_dimensions[r].height = 300; r += 1
|
||||
|
||||
ws.freeze_panes = 'A4'
|
||||
return ws
|
||||
|
||||
def main():
|
||||
out_path = sys.argv[1] if len(sys.argv) > 1 else '/tmp/南通-workflow-batch.xlsx'
|
||||
|
||||
print("=== 获取所有已完成的nantong-lease-audit threads ===")
|
||||
threads = get_all_nantong_threads()
|
||||
print(f"找到 {len(threads)} 个已完成的thread")
|
||||
|
||||
if not threads:
|
||||
print("No completed threads found. Exiting.")
|
||||
sys.exit(1)
|
||||
|
||||
campus_data = {}
|
||||
for tid in threads:
|
||||
info = get_thread_info(tid)
|
||||
campus = info['campus']
|
||||
if not campus:
|
||||
print(f" SKIP {tid}: no campus info")
|
||||
continue
|
||||
|
||||
print(f" 处理 {tid}: {campus} / {info['filename']}")
|
||||
thread_text = get_thread_read(tid)
|
||||
|
||||
cls_output = extract_step_output(thread_text, 'classifier')
|
||||
cls_fm, _ = extract_frontmatter(cls_output)
|
||||
td_output = extract_step_output(thread_text, 'template-d')
|
||||
td_fm, td_body = extract_frontmatter(td_output)
|
||||
ra_output = extract_step_output(thread_text, 'rule-analy')
|
||||
ra_fm, ra_body = extract_frontmatter(ra_output)
|
||||
de_output = extract_step_output(thread_text, 'data-extra')
|
||||
de_fm, de_body = extract_frontmatter(de_output)
|
||||
|
||||
row = {}
|
||||
row['B'] = info['filename'] + '.pdf' if info['filename'] else cls_fm.get('contract_title', '')
|
||||
row['C'] = cls_fm.get('contract_type', '')
|
||||
row['D'] = f"甲方：{cls_fm.get('party_a', '')}\n乙方：{cls_fm.get('party_b', '')}"
|
||||
row['E'] = cls_fm.get('property_address', '')
|
||||
row['F'] = cls_fm.get('area_sqm', '')
|
||||
start = cls_fm.get('term_start', '')
|
||||
end = cls_fm.get('term_end', '')
|
||||
free = cls_fm.get('rent_free_period', '')
|
||||
row['G'] = f"{start}至{end}\n免租期：{free}" if start else ''
|
||||
|
||||
for col in 'HIJ':
|
||||
pattern = rf'{col}\.\s+[^：:]+[：:]\s*(.*?)(?=\n[A-L]\.\s|\nh_column|\Z)'
|
||||
m = re.search(pattern, de_body, re.DOTALL)
|
||||
row[col] = m.group(1).strip() if m else ''
|
||||
h_pattern = r'H\.\s+金额/费用[：:]\s*(.*?)(?=\nI\.\s|\Z)'
|
||||
hm = re.search(h_pattern, de_body, re.DOTALL)
|
||||
if hm: row['H'] = hm.group(1).strip()
|
||||
|
||||
risk = ra_fm.get('risk_detail', ra_body[:5000])
|
||||
term = ra_fm.get('termination_analysis', '')
|
||||
row['K'] = risk + ('\n\n' + term if term else '')
|
||||
row['L'] = td_fm.get('diff_detail', td_body[:3000])
|
||||
|
||||
if campus not in campus_data:
|
||||
campus_data[campus] = []
|
||||
campus_data[campus].append(row)
|
||||
|
||||
import openpyxl
|
||||
wb = openpyxl.Workbook()
|
||||
wb.remove(wb.active)
|
||||
|
||||
for campus, rows in campus_data.items():
|
||||
print(f" {campus}: {len(rows)} rows")
|
||||
build_campus_sheet(wb, campus, rows)
|
||||
|
||||
os.makedirs(os.path.dirname(out_path) or '.', exist_ok=True)
|
||||
wb.save(out_path)
|
||||
print(f"\n✅ 已保存: {out_path}")
|
||||
|
||||
print(f"\n=== 汇总 ===")
|
||||
for campus, rows in campus_data.items():
|
||||
print(f" {campus}: {len(rows)}份合同")
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
@@ -0,0 +1,182 @@
|
||||
#!/usr/bin/env python3
|
||||
# -*- coding: utf-8 -*-
|
||||
"""
|
||||
单校区开工闸门 / Campus Workflow Gate
|
||||
=====================================
|
||||
南通新东方租赁合同梳理——每开一个新校区，动手前必须先跑这个脚本。
|
||||
|
||||
为什么存在：防止"开新校区时凭上个校区的印象乱跑/跳步"。
|
||||
这是物理闸门——脚本把【从头到尾的完整流程】+【单校区独立闭环纪律】打印出来，
|
||||
逼自己逐条确认，不跑不准动手填表。
|
||||
|
||||
🔴 通读强制纪律（悦拾光0703教训，详见 references/fulltext-reading-discipline-0703.md）：
|
||||
Step2动作A法律审查必须 read_file 从第1行读到最后一行（每批500行），不得 grep 代替。
|
||||
I列按21/15固定类目逐项摘录原文（格式：· [类目] 原文（条款号））。
|
||||
建完表后跑 scripts/i-column-coverage-check.py 报警核查覆盖率。
|
||||
|
||||
用法：
|
||||
python3 campus-workflow-gate.py <校区名>
|
||||
例：
|
||||
python3 campus-workflow-gate.py 人民中路
|
||||
|
||||
它会：
|
||||
1. 打印「单校区独立闭环纪律」——本校区从 Step0 从头做，不受其他校区影响
|
||||
2. 打印完整 Step 0→7 workflow + 三角色 + 交付物板块的强制清单
|
||||
3. 定位该校区在 Nextcloud 的源文件夹 + 汇总表应存放的位置（=校区自己的文件夹）
|
||||
4. 生成一份待打勾的 todo 文本，贴进 todo 工具
|
||||
"""
|
||||
import sys, os, subprocess
|
||||
|
||||
NC_CONTAINER = "nextcloud-nextcloud-1"
|
||||
NC_BASE = "/var/www/html/data/admin/files/小Maggie协作区/南通新东方/履约期内非集采合同-综办/房租物业合同"
|
||||
NC_DAV = "小Maggie协作区/南通新东方/履约期内非集采合同-综办/房租物业合同"
|
||||
|
||||
def campus_dir_exists(campus):
|
||||
p = f"{NC_BASE}/{campus}"
|
||||
r = subprocess.run(["docker","exec",NC_CONTAINER,"test","-d",p],
|
||||
capture_output=True)
|
||||
return r.returncode == 0
|
||||
|
||||
def list_campus_files(campus):
|
||||
p = f"{NC_BASE}/{campus}"
|
||||
r = subprocess.run(["docker","exec",NC_CONTAINER,"bash","-c",f'ls -la "{p}"'],
|
||||
capture_output=True, text=True)
|
||||
return r.stdout
|
||||
|
||||
def main():
|
||||
if len(sys.argv) < 2:
|
||||
print("用法: python3 campus-workflow-gate.py <校区名>")
|
||||
print("例: python3 campus-workflow-gate.py 人民中路")
|
||||
sys.exit(1)
|
||||
campus = sys.argv[1].strip()
|
||||
|
||||
bar = "=" * 70
|
||||
print(bar)
|
||||
print(f" 单校区开工闸门 · 校区 = 【{campus}】")
|
||||
print(bar)
|
||||
|
||||
# ---- 第一道：独立闭环纪律 + 地基四铁律 ----
|
||||
print("""
|
||||
🔴🔴 单校区独立闭环纪律（Maggie 2026-06-23 立，开工前默念）🔴🔴
|
||||
1. 本校区从 Step 0 从头做到 Step 6 独立跑一遍(Step 7 总览是全部校区定稿后的全局收尾)。
|
||||
2. 绝不受其他校区影响——不拿"上个校区做过/世茂悦拾光是这样"的印象代替
|
||||
本校区的逐字通读、逐条审查、回 07 原件比对。每个校区都是第一次。
|
||||
3. 别的校区的结论、定级、措辞，统统不假设适用于本校区；一切回本校区原文。
|
||||
4. 这是一次"全新合同全面审"，不是"套上一份的模子"。
|
||||
|
||||
🔴🔴 地基四铁律（Maggie 2026-06-26 重申，优先级最高）🔴🔴
|
||||
1. 逐字逐句：亲自读完整篇OCR，一字不跳。OCR乱码停→vision核实，不准跳过猜值。
|
||||
🔴 Step1完成后必跑 ocr-garble-detect.py 扫全文乱码，高危行逐条vision消灭（教训：
|
||||
凤凰文化10.2乱码未核实→整段"初年年租金20%违约金"丢失→审查结论反转→返工）
|
||||
2. 整体理解：通读全文后再逐条审，先建立全文结构认知。
|
||||
3. 上下文联系：每读一条问"这条被别处限定/修改了吗？"
|
||||
4. 逻辑分析：数字、比例、日期、主体用逻辑推一遍——合理吗？自洽吗？
|
||||
""")
|
||||
|
||||
# ---- 第二道：完整流程强制清单 ----
|
||||
print("""———— 完整 WORKFLOW（缺一步不交付）————
|
||||
Step 0 文件盘点归类：按文件夹结构（房租/扩租/物业），含空目录，不跨夹重排
|
||||
Step 1 取 PDF + OCR→.md（大文件后台跑；纯扫描件文字层=0 必 OCR）
|
||||
Step 2 承办（四眼分离前半）【并行,不串行】：
|
||||
⚡ 开工第一动作 = 立刻 delegate_task 发动作B 到后台,发出的同一秒自己开读动作A
|
||||
· 动作B 提取分析 = subagent(后台先发)：OCR要素+模版比对+退租敞口+填表初稿
|
||||
· 动作A 法律审查 = 小Maggie本人主审(B发出后立即开读)，亲自 read_file 逐字通读全文，
|
||||
八维框架，当全新合同审（独立法律审查框架）—— 两件事同时跑,绝不先做完A再做B
|
||||
· 🔴 模版比对必须回 07-房屋租赁合同.docx 原件逐条核（subagent context 带原件路径）
|
||||
Step 3 写 Excel：12 列（K=法律风险/L=模版差异，物理分列）；
|
||||
按文件夹分板块；末尾必有「整体风险分析与建议」段
|
||||
· 各列规则详见 references/column-rules-0701.md（Maggie校准版，优先级最高）
|
||||
· H列四检：①条款号 ②月租换算 ③付款推算 ④❗标注。缺一不过，不过不交付。
|
||||
· 需客户核实内容整条标红（富文本红是最后一步→WPS另存/sharedStrings XML层）
|
||||
Step 4 三角色校对：法律校对 ‖ 格式校对（六维清单）→ 闭环复核
|
||||
Step 5 小Maggie终审：合并法律风险栏、回07原件复核L列、确认问题闭环、最后把关
|
||||
· 🔴 K/L 分工自检(必跑)：K列 grep "模版|07模版|07-房屋"=0(独立审查不引模版,
|
||||
匹配"07模版"而非裸07防误命中金额数字)；L列 grep "风险|建议|不利|详见"=0(纯客观不下判断)。
|
||||
任一非0即回去拆分。判据=遮模版测试：把"模版怎么写"遮住,K列风险论述仍完整成立才算独立。
|
||||
Step 6 交付前自查+存档：x2t渲染PDF + pdftotext拍平grep验文字 + vision验视觉(图先压<400KB)
|
||||
→ 汇总表存本校区文件夹 + files:scan + 清OO缓存 → 发Maggie核
|
||||
〔全部校区定稿后〕Step 7 整合总览sheet（全局收尾，非单校区步骤）
|
||||
———— 交付物必含板块（验收必查）————
|
||||
逐条风险(🔴🟡🟢分级,标条款号) + 整体风险分析与建议段 + L列模版差异(回07原件)
|
||||
""")
|
||||
|
||||
# ---- 第三道：存放纪律 + 定位 ----
|
||||
print(bar)
|
||||
print(" 📁 汇总表存放纪律（Maggie 2026-06-23 立）")
|
||||
print(bar)
|
||||
exists = campus_dir_exists(campus)
|
||||
if exists:
|
||||
print(f"✅ 校区源文件夹已定位：")
|
||||
print(f" 容器路径: {NC_BASE}/{campus}/")
|
||||
print(f" WebDAV : {NC_DAV}/{campus}/")
|
||||
print(f"\n 本校区文件清单：")
|
||||
for line in list_campus_files(campus).splitlines():
|
||||
if line.strip() and not line.startswith("total"):
|
||||
print(f" {line}")
|
||||
else:
|
||||
print(f"⚠️ 未在标准路径找到校区目录【{campus}】。请先核对校区名，或确认目录是否在别处：")
|
||||
print(f" 预期: {NC_BASE}/{campus}/")
|
||||
print(f" （17 个校区均在 房租物业合同/ 下，标准名单：")
|
||||
print(f" 万达、世茂、人民中路、凤凰文化、北翼玖玖、南通大厦、小石桥晏园、悦拾光、")
|
||||
print(f" 星月、桃坞路、解放中路、跃龙路、通大、通大附、通州金鹰、金飞达、龙信）")
|
||||
print(f"""
|
||||
🔴 本校区汇总表【必须】存到本校区自己的文件夹下，不放别处、不放公共目录：
|
||||
存放路径: {NC_DAV}/{campus}/
|
||||
命名规则: {campus}-梳理-MJ-YYYYMMDD.xlsx （当事人/项目名+文件名+修改人+日期）
|
||||
—— 每个校区的汇总表归到各自校区文件夹，与该校区合同放一起，便于客户对照查阅。
|
||||
""")
|
||||
|
||||
# ---- 第四道：吐出 todo 文本 ----
|
||||
print(bar)
|
||||
print(" ⬇️ 把下面这份 todo 贴进 todo 工具，逐项打勾（缺一项不交付）")
|
||||
print(bar)
|
||||
todos = [
|
||||
f"[{campus}] Step0 文件盘点归类(含空目录,不跨夹重排;多租赁物先按租赁物分类再按签约时间排列;详细K/L/I放最早签约那份行里后续写同上)",
|
||||
f"[{campus}] Step1 取PDF+OCR→.md(纯扫描件必OCR)+保存.md到同目录 → 跑 ocr-garble-detect.py 扫乱码 → 高危乱码每处vision核实消灭 → 全灭才进Step2",
|
||||
f"[{campus}] Step2 承办【并行,不串行】⚡开工第一动作=立刻 delegate_task 发动作B(模版比对回07原件,仅租赁合同需比对,物业等其他合同不需要)到后台 → 发出的同一秒自己开读动作A(本人逐字通读全文+八维当全新合同审)。两件事同时跑,绝不先做完A再做B",
|
||||
f"[{campus}] Step3 写12列Excel(K法律风险/L模版差异分列)+H列四检+整体风险分析段+标红。🔴必须用 templates/single-campus-builder.py 照抄改值，禁裸写 openpyxl。🔴建L列前必read_file subagent比对文件，从里面逐条摘差异。🔴各列规则见 references/column-rules-0701.md（多合同时详细K/L放最早签约那份行里，后续行写同上）",
|
||||
f"[{campus}] Step4 三角色校对(法律‖格式)闭环复核",
|
||||
f"[{campus}] Step5 终审:合并法律风险+回07原件复核L列+K/L分工自检(K列grep'模版|07'=0,L列grep'风险|建议|不利|详见'=0)+确认闭环",
|
||||
f"[{campus}] Step6 交付自查(x2t渲染+pdftotext验文字+vision验视觉)+存本校区文件夹",
|
||||
f"[{campus}] 存档:汇总表存到本校区文件夹 {campus}/ + files:scan + 清OO缓存",
|
||||
]
|
||||
for i, t in enumerate(todos, 1):
|
||||
print(f" {i}. {t}")
|
||||
print()
|
||||
|
||||
# ---- 🔴 第五道：物理卡口（防跳步）----
|
||||
print(bar)
|
||||
print(" 🔴🔴 物理卡口（以下两条不做到 = 返工，不交付）🔴🔴")
|
||||
print(bar)
|
||||
print("""
|
||||
卡口① 格式强制：Step3 写表必须用模板脚本
|
||||
→ 路径：~/.hermes/skills/legal/contract-portfolio-analysis/templates/single-campus-builder.py
|
||||
→ 方法：cp 到工作目录，改 TODO 标记的值（标题、项目信息、D5..L5、D8..L8、整体段、输出路径）
|
||||
→ 禁止：自己 openpyxl 裸写样式、自创颜色、改列头措辞
|
||||
→ 自检：交付前打开文件，和人民中路定稿并排对比——标题酒红底白字？段标题红底？行2灰底？
|
||||
K列头="法律风险（站乙方立场）"？L列头="与07标准模版差异"？冻结A5？行高30/76/409.5？
|
||||
|
||||
卡口② 模版比对强制：Step2 动作B 必须 delegate_task subagent
|
||||
→ 不能：自己读07模版后手写L列差异（会漏、会简略、会凭印象）
|
||||
→ 做法：OCR完成后立即 delegate_task，context 含 07模版路径 + 两份合同OCR路径
|
||||
→ 🔴 建表前必做：read_file 读 subagent 比对文件全文，L列从里面逐条摘、不从脑子里摘
|
||||
→ 自检①：subagent 返回的差异清单是否 ≥ 20 条？
|
||||
→ 自检②：L列每条差异是否都能在 subagent 比对文件里找到原文对应？
|
||||
"甲方制式格式，与07模版不同"这种一句话概括 = 没读 subagent 文件 = 返工
|
||||
subagent 抓到的差异（如举报邮箱新增、供电功率矛盾、首期期间变更）
|
||||
你在 L 列里没写 = 没读 subagent 文件 = 返工
|
||||
|
||||
卡口③ 交付前格式自检（跑脚本，不凭眼）：
|
||||
→ python3 scripts/kl-separation-check.py <out.xlsx> # K列零模版、L列零判断词
|
||||
→ python3 -c "import openpyxl; wb=openpyxl.load_workbook('<out.xlsx>');
|
||||
ws=wb[wb.sheetnames[0]];
|
||||
assert ws.cell(1,1).fill.start_color.rgb=='FF8B1A2B','标题不是酒红底';
|
||||
assert ws.cell(3,1).fill.start_color.rgb=='FFC0504D','段标题不是红底';
|
||||
assert ws.cell(4,11).value=='法律风险（站乙方立场）','K列头不对';
|
||||
assert ws.cell(4,12).value=='与07标准模版差异','L列头不对';
|
||||
print('OK')"
|
||||
""")
|
||||
print("提醒：开工前默念独立闭环纪律——本校区从头做，不受其他校区影响。")
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
@@ -0,0 +1,233 @@
|
||||
#!/usr/bin/env python3
|
||||
# -*- coding: utf-8 -*-
|
||||
"""
|
||||
交付前闸门 / Delivery Gate
|
||||
=========================
|
||||
每次交付南通新东方梳理表前，必须跑这个脚本。
|
||||
不通过 = 不发文件。不通过 = 回去补 workflow。
|
||||
|
||||
用法：
|
||||
python3 delivery-gate.py <xlsx路径> <工作目录> <校区名>
|
||||
|
||||
例：
|
||||
python3 delivery-gate.py /tmp/金飞达/金飞达-梳理-MJ-20260627.xlsx /tmp/金飞达 金飞达
|
||||
|
||||
检查项：
|
||||
G1. 模版比对 subagent 是否执行过（工作目录是否有 模版比对-*.md）
|
||||
G2. K/L 分工自检是否通过
|
||||
G3. 格式自检是否通过（标题酒红底、段标题红底、列头正确）
|
||||
G4. 整体风险分析段是否存在
|
||||
G5. 数据行数是否合理（至少 文件数 行）
|
||||
G6. 文件是否已上传 Nextcloud
|
||||
G7. OCR占位符残留检测（【…】/〔待核PDF〕/OCR模糊 等，任一残留=禁止交付）
|
||||
"""
|
||||
import sys, os, subprocess, re
|
||||
import openpyxl
|
||||
|
||||
def fail(msg):
|
||||
print(f"❌ {msg}")
|
||||
return False
|
||||
|
||||
def ok(msg):
|
||||
print(f"✅ {msg}")
|
||||
return True
|
||||
|
||||
def check_g1(workdir):
|
||||
"""G1: 模版比对 subagent 是否执行过"""
|
||||
import glob
|
||||
files = glob.glob(os.path.join(workdir, "模版比对-*.md"))
|
||||
if not files:
|
||||
return fail("G1 模版比对：未找到模版比对输出文件。Step2 动作B 必须 delegate_task subagent 做模版比对。")
|
||||
f = files[0]
|
||||
size = os.path.getsize(f)
|
||||
if size < 1000:
|
||||
return fail(f"G1 模版比对：{os.path.basename(f)} 仅 {size} 字节，内容过短，可能未完整执行。")
|
||||
return ok(f"G1 模版比对：{os.path.basename(f)} ({size:,} 字节)")
|
||||
|
||||
def check_g2(xlsx_path):
|
||||
"""G2: K/L 分工自检"""
|
||||
# 直接用 kl-separation-check.py
|
||||
script = os.path.expanduser("~/.hermes/skills/legal/contract-portfolio-analysis/scripts/kl-separation-check.py")
|
||||
r = subprocess.run(["python3", script, xlsx_path], capture_output=True, text=True)
|
||||
if r.returncode != 0:
|
||||
return fail(f"G2 K/L自检：未通过\n{r.stdout}")
|
||||
return ok("G2 K/L自检：通过")
|
||||
|
||||
def check_g3(xlsx_path):
|
||||
"""G3: 格式自检"""
|
||||
try:
|
||||
wb = openpyxl.load_workbook(xlsx_path)
|
||||
ws = wb[wb.sheetnames[0]]
|
||||
# 找到第一个列头行（含"序号"的）
|
||||
hdr_row = None
|
||||
for r in range(1, 30):
|
||||
if ws.cell(r, 1).value == '序号':
|
||||
hdr_row = r
|
||||
break
|
||||
if not hdr_row:
|
||||
return fail("G3 格式：未找到列头行")
|
||||
checks = [
|
||||
("标题酒红底", ws.cell(1,1).fill.start_color.rgb == 'FF8B1A2B'),
|
||||
("段标题(K列头)", ws.cell(hdr_row, 11).value == '法律风险（站乙方立场）'),
|
||||
("段标题(L列头)", ws.cell(hdr_row, 12).value == '与07标准模版差异'),
|
||||
]
|
||||
for name, passed in checks:
|
||||
if not passed:
|
||||
return fail(f"G3 格式：{name} 不正确")
|
||||
return ok("G3 格式自检：通过")
|
||||
except Exception as e:
|
||||
return fail(f"G3 格式：打开失败 - {e}")
|
||||
|
||||
def check_g4(xlsx_path):
|
||||
"""G4: 整体风险分析段"""
|
||||
try:
|
||||
wb = openpyxl.load_workbook(xlsx_path)
|
||||
ws = wb[wb.sheetnames[0]]
|
||||
for r in range(ws.max_row, 1, -1):
|
||||
v = ws.cell(r, 1).value
|
||||
if v and '整体风险分析' in str(v):
|
||||
return ok(f"G4 整体风险分析段：存在（行{r}）")
|
||||
return fail("G4 整体风险分析段：未找到。每校区必须包含「整体风险分析与建议」段。")
|
||||
except Exception as e:
|
||||
return fail(f"G4 整体风险分析段：打开失败 - {e}")
|
||||
|
||||
def check_g5(xlsx_path, min_rows=3):
|
||||
"""G5: 数据行数"""
|
||||
try:
|
||||
wb = openpyxl.load_workbook(xlsx_path)
|
||||
ws = wb[wb.sheetnames[0]]
|
||||
data_rows = 0
|
||||
for r in range(5, ws.max_row + 1):
|
||||
v = ws.cell(r, 1).value
|
||||
if v and re.match(r'^\d+$', str(v).strip()):
|
||||
data_rows += 1
|
||||
if data_rows < min_rows:
|
||||
return fail(f"G5 数据行数：仅 {data_rows} 行，需 ≥ {min_rows}")
|
||||
return ok(f"G5 数据行数：{data_rows} 行")
|
||||
except Exception as e:
|
||||
return fail(f"G5 数据行数：打开失败 - {e}")
|
||||
|
||||
def check_g6(xlsx_path, campus):
|
||||
"""G6: 文件是否已上传 Nextcloud"""
|
||||
fname = os.path.basename(xlsx_path)
|
||||
nc_path = f"/var/www/html/data/admin/files/小Maggie协作区/南通新东方/履约期内非集采合同-综办/房租物业合同/{campus}/{fname}"
|
||||
r = subprocess.run(
|
||||
["docker", "exec", "nextcloud-nextcloud-1", "test", "-f", nc_path],
|
||||
capture_output=True
|
||||
)
|
||||
if r.returncode == 0:
|
||||
return ok(f"G6 Nextcloud：已上传 {campus}/{fname}")
|
||||
else:
|
||||
return fail(f"G6 Nextcloud：未上传到 {campus}/{fname}。请先 docker cp + files:scan。")
|
||||
|
||||
def check_g7(xlsx_path):
|
||||
"""G7: OCR占位符残留检测（【…】、〔待核PDF〕、OCR模糊 等）"""
|
||||
patterns = [
|
||||
r'【\.{1,5}】', # 【…】、【...】
|
||||
r'【…】', # 中文省略号
|
||||
r'〔待核PDF〕', # 待核标记
|
||||
r'〔待核〕',
|
||||
r'OCR模糊', # OCR模糊标记
|
||||
r'OCR无法识别',
|
||||
r'OCR乱码',
|
||||
r'待补全',
|
||||
]
|
||||
try:
|
||||
wb = openpyxl.load_workbook(xlsx_path, data_only=True)
|
||||
hits = []
|
||||
for ws in wb.worksheets:
|
||||
for r in range(1, ws.max_row + 1):
|
||||
for c in range(1, ws.max_column + 1):
|
||||
v = ws.cell(r, c).value
|
||||
if not v:
|
||||
continue
|
||||
sv = str(v)
|
||||
for pat in patterns:
|
||||
if re.search(pat, sv):
|
||||
col_letter = openpyxl.utils.get_column_letter(c)
|
||||
m = re.search(pat, sv)
|
||||
start = max(0, m.start() - 10)
|
||||
end = min(len(sv), m.end() + 10)
|
||||
ctx = sv[start:end].replace('\n', ' ')
|
||||
hits.append(f" [{ws.title}] {col_letter}{r}: ...{ctx}...")
|
||||
if hits:
|
||||
msg = f"G7 OCR占位符残留：发现 {len(hits)} 处未补全的OCR标记\n" + "\n".join(hits[:5])
|
||||
if len(hits) > 5:
|
||||
msg += f"\n ...（共 {len(hits)} 处，仅显示前5处）"
|
||||
msg += "\n 铁律：OCR读不出的必须用vision看原图补全，不能用占位符交付。"
|
||||
return fail(msg)
|
||||
return ok("G7 OCR占位符：无残留（全表扫描通过）")
|
||||
except Exception as e:
|
||||
return fail(f"G7 OCR占位符：检查失败 - {e}")
|
||||
|
||||
def check_g8(workdir):
|
||||
"""G8: OCR完整性checkpoint（物理依赖链第一环）"""
|
||||
checkpoint = os.path.join(workdir, 'step1.verified')
|
||||
if not os.path.exists(checkpoint):
|
||||
return fail(f"G8 OCR依赖链：checkpoint不存在\n 路径: {checkpoint}\n 说明: Step1 OCR完成后必须运行 ocr-integrity-check.py 生成checkpoint\n 动作: python3 scripts/ocr-integrity-check.py {workdir}")
|
||||
# 读取checkpoint内容确认
|
||||
with open(checkpoint, 'r', encoding='utf-8') as f:
|
||||
content = f.read()
|
||||
if 'OCR完整性检查通过' not in content:
|
||||
return fail(f"G8 OCR依赖链：checkpoint内容异常\n {checkpoint} 未包含'OCR完整性检查通过'")
|
||||
return ok(f"G8 OCR依赖链：checkpoint存在且有效")
|
||||
|
||||
def check_g9(workdir):
|
||||
"""G9: 模版比对checkpoint（物理依赖链第二环）"""
|
||||
checkpoint = os.path.join(workdir, 'step2b.verified')
|
||||
if not os.path.exists(checkpoint):
|
||||
return fail(f"G9 模版比对依赖链：checkpoint不存在\n 路径: {checkpoint}\n 说明: Step2 动作B必须delegate subagent做模版比对，然后运行验证脚本\n 动作: python3 scripts/template-diff-verify.py {workdir}")
|
||||
# 读取checkpoint内容确认
|
||||
with open(checkpoint, 'r', encoding='utf-8') as f:
|
||||
content = f.read()
|
||||
if '模版比对验证通过' not in content:
|
||||
return fail(f"G9 模版比对依赖链：checkpoint内容异常\n {checkpoint} 未包含'模版比对验证通过'")
|
||||
return ok(f"G9 模版比对依赖链：checkpoint存在且有效")
|
||||
|
||||
def main():
|
||||
if len(sys.argv) < 4:
|
||||
print("用法: python3 delivery-gate.py <xlsx路径> <工作目录> <校区名>")
|
||||
print("例: python3 delivery-gate.py /tmp/金飞达/金飞达-梳理-MJ-20260627.xlsx /tmp/金飞达 金飞达")
|
||||
sys.exit(1)
|
||||
|
||||
xlsx = sys.argv[1]
|
||||
workdir = sys.argv[2]
|
||||
campus = sys.argv[3]
|
||||
|
||||
if not os.path.exists(xlsx):
|
||||
print(f"❌ 文件不存在: {xlsx}")
|
||||
sys.exit(1)
|
||||
|
||||
bar = "=" * 60
|
||||
print(bar)
|
||||
print(f" 交付闸门 · {campus}")
|
||||
print(bar)
|
||||
print()
|
||||
|
||||
results = [
|
||||
check_g1(workdir),
|
||||
check_g2(xlsx),
|
||||
check_g3(xlsx),
|
||||
check_g4(xlsx),
|
||||
check_g5(xlsx, min_rows=3),
|
||||
check_g6(xlsx, campus),
|
||||
check_g7(xlsx),
|
||||
check_g8(workdir),
|
||||
check_g9(workdir),
|
||||
]
|
||||
|
||||
print()
|
||||
print(bar)
|
||||
passed = sum(1 for r in results if r)
|
||||
total = len(results)
|
||||
if all(results):
|
||||
print(f" ✅ 全部通过 ({passed}/{total}) —— 可以交付")
|
||||
print(bar)
|
||||
sys.exit(0)
|
||||
else:
|
||||
print(f" ❌ {total - passed}/{total} 项未通过 —— 禁止交付，回去补 workflow")
|
||||
print(bar)
|
||||
sys.exit(1)
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
@@ -0,0 +1,238 @@
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
edit-redmarked-xlsx.py — 安全编辑「已标红（WPS规范化）」的 xlsx，红色 run 一个字不碰。
|
||||
|
||||
背景（2026-06-18 世茂实证）：
|
||||
WPS 另存后的好 xlsx 用 sharedStrings.xml + 富文本红 <r> run 存储「某条标红」。
|
||||
对它 openpyxl.load_workbook→改→save 会把整表打回 inlineStr、红色 run 全部归零、
|
||||
sharedStrings.xml 消失，Excel 重新报「需要修复」——成果一键作废。
|
||||
正解：在 sharedStrings.xml 的 XML 层做外科手术，只改目标 <t> 文字，红 <r> run 原样保留。
|
||||
|
||||
本脚本提供：
|
||||
1) --verify 只读·五查（本地验不了 Excel，这是能自动做的最强保证）
|
||||
2) 可 import 的工具函数 surgical_edit_si() / delete_run_and_renumber() / repack()
|
||||
—— 已知正确的实现，未来 session 直接 import 或照抄，别重新踩坑。
|
||||
|
||||
⚠️ 红色 = rgb="FFFF0000"。重打包必须 [Content_Types].xml 在 zip 第一项。
|
||||
⚠️ 改前先把 WPS 好版本另存 _bak_ 备份；改完五查全过再发 Maggie 用 Excel 终判。
|
||||
|
||||
用法：
|
||||
# 五查（改后必跑）
|
||||
python3 edit-redmarked-xlsx.py --verify 改后.xlsx --baseline WPS好基线.xlsx
|
||||
# 列出每个格子用的 sharedString 索引（定位「要改哪个格→改第几条 si」）
|
||||
python3 edit-redmarked-xlsx.py --map 文件.xlsx [--sheet sheet1.xml]
|
||||
# 打印某条 si 的 run 结构（看哪些 <r> 是红色、文字开头）
|
||||
python3 edit-redmarked-xlsx.py --show-si 文件.xlsx 47
|
||||
"""
|
||||
import sys, os, re, zipfile, shutil, argparse, tempfile
|
||||
from lxml import etree
|
||||
|
||||
NS = "{http://schemas.openxmlformats.org/spreadsheetml/2006/main}"
|
||||
RED = "FFFF0000"
|
||||
|
||||
|
||||
# ---------- 只读探针 ----------
|
||||
def red_run_count(xlsx):
|
||||
"""数红色富文本 run 数（精确匹配 rgb="FFFF0000"）。
|
||||
⚠️ 2026-06-22 教训：务必用精确 rgb="FFFF0000" 匹配，绝不能用
|
||||
`'FF0000' in etree.tostring(rpr)` 子串匹配——黑色 FF000000 里也含 'F0000'，
|
||||
会把黑字 run 误判成红字，导致 K列长单元格被误报"整格泛红"。
|
||||
"""
|
||||
z = zipfile.ZipFile(xlsx)
|
||||
if "xl/sharedStrings.xml" not in z.namelist():
|
||||
# 退化成 inlineStr 了——红色多半已丢，去 sheet 里数
|
||||
total = 0
|
||||
for n in z.namelist():
|
||||
if re.match(r"xl/worksheets/sheet\d+\.xml", n):
|
||||
total += len(re.findall(rf'rgb="{RED}"', z.read(n).decode()))
|
||||
return total, False # False = 没有 sharedStrings（危险信号）
|
||||
ss = z.read("xl/sharedStrings.xml").decode()
|
||||
return len(re.findall(rf'rgb="{RED}"', ss)), True
|
||||
|
||||
|
||||
def cell_si_map(xlsx, sheet="xl/worksheets/sheet1.xml"):
|
||||
"""返回 {单元格坐标: sharedString索引}，用于把「改哪个格」翻成「改第几条 si」。"""
|
||||
z = zipfile.ZipFile(xlsx)
|
||||
sx = z.read(sheet).decode()
|
||||
out = {}
|
||||
for m in re.finditer(r'<c r="([A-Z]+\d+)"[^>]*\bt="s"[^>]*>\s*<v>(\d+)</v>', sx):
|
||||
out[m.group(1)] = int(m.group(2))
|
||||
return out
|
||||
|
||||
|
||||
def show_si(xlsx, idx):
|
||||
"""打印第 idx 条 si 的 run 结构（红/黑 + 文字开头），定位要改/要删哪个 run。"""
|
||||
z = zipfile.ZipFile(xlsx)
|
||||
root = etree.fromstring(z.read("xl/sharedStrings.xml"))
|
||||
si = root.findall(f"{NS}si")[idx]
|
||||
print(f"=== si[{idx}] ===")
|
||||
for i, ch in enumerate(si):
|
||||
tag = ch.tag.replace(NS, "")
|
||||
if tag == "r":
|
||||
rpr = ch.find(f"{NS}rPr")
|
||||
t = ch.find(f"{NS}t")
|
||||
is_red = rpr is not None and RED in etree.tostring(rpr, encoding="unicode")
|
||||
txt = (t.text or "")[:55] if t is not None else ""
|
||||
print(f" [{i}] {'🔴红' if is_red else ' 黑'} | {txt!r}")
|
||||
elif tag == "t":
|
||||
print(f" [{i}] 纯t | {(ch.text or '')[:55]!r}")
|
||||
|
||||
|
||||
def verify(xlsx, baseline=None, expect_red=None):
|
||||
"""五查：sharedStrings在 / 红色数 / zip+XML完整 / (可选)与基线同构。返回 True/False。"""
|
||||
ok = True
|
||||
z = zipfile.ZipFile(xlsx)
|
||||
names = z.namelist()
|
||||
|
||||
# ① sharedStrings 仍在
|
||||
has_ss = "xl/sharedStrings.xml" in names
|
||||
print(f"① sharedStrings.xml: {'✅在' if has_ss else '❌丢失(openpyxl毁了富文本!)'}")
|
||||
ok &= has_ss
|
||||
|
||||
# ② 红色 run 数
|
||||
n_red, _ = red_run_count(xlsx)
|
||||
tail = f"（预期 {expect_red}）" if expect_red is not None else ""
|
||||
match = (expect_red is None) or (n_red == expect_red)
|
||||
print(f"② 红色run数: {n_red}{tail} {'✅' if match else '❌'}")
|
||||
ok &= match
|
||||
|
||||
# ③ zip 完整 + 所有 XML 部件可解析
|
||||
bad = z.testzip()
|
||||
parts_ok, parts_bad = 0, []
|
||||
for n in names:
|
||||
if n.endswith(".xml") or n.endswith(".rels"):
|
||||
try:
|
||||
etree.fromstring(z.read(n)); parts_ok += 1
|
||||
except Exception as e:
|
||||
parts_bad.append((n, str(e)[:50]))
|
||||
print(f"③ zip完整={'✅' if bad is None else '❌'+str(bad)}; "
|
||||
f"XML部件 {parts_ok}个OK"
|
||||
+ (f" ❌{parts_bad}" if parts_bad else " ✅"))
|
||||
ok &= (bad is None) and not parts_bad
|
||||
|
||||
# ④ Content_Types 必须第一项（严格解析器要求）
|
||||
first = names[0] if names else ""
|
||||
ct_first = first == "[Content_Types].xml"
|
||||
print(f"④ [Content_Types].xml 在首位: {'✅' if ct_first else '⚠️ 实为 '+first}")
|
||||
# 不计入硬失败（Excel/WPS 宽容），仅告警
|
||||
if not ct_first:
|
||||
print(" ↳ 严格解析器(LibreOffice)会报 source file could not be loaded；建议重打包置首。")
|
||||
|
||||
# ⑤ 与基线同构（部件清单）
|
||||
if baseline:
|
||||
zb = set(zipfile.ZipFile(baseline).namelist())
|
||||
zo = set(names)
|
||||
only_mine = {x for x in zo - zb if not x.endswith("/")}
|
||||
only_base = {x for x in zb - zo if not x.endswith("/")}
|
||||
iso = not only_mine and not only_base
|
||||
print(f"⑤ 与基线部件同构: {'✅' if iso else '❌'} "
|
||||
+ (f"我多:{only_mine} 基线多:{only_base}" if not iso else "(差异仅空目录条目可接受)"))
|
||||
ok &= iso
|
||||
|
||||
print(f"\n{'✅ 五查通过——可发 Maggie 用 Excel 终判' if ok else '❌ 有项未过——先修再发'}")
|
||||
return ok
|
||||
|
||||
|
||||
# ---------- 编辑工具（import 用；已验证正确，照抄别重写） ----------
|
||||
def surgical_edit_si(work_dir, edits: dict):
|
||||
"""
|
||||
在解压目录 work_dir 的 xl/sharedStrings.xml 上，按 {si索引: 新纯文本} 改纯文本格。
|
||||
仅适用于「纯文本 si」（无红 run）。含红 run 的格用下面 delete_run_and_renumber 或手写。
|
||||
"""
|
||||
ssp = os.path.join(work_dir, "xl", "sharedStrings.xml")
|
||||
tree = etree.parse(ssp)
|
||||
sis = tree.getroot().findall(f"{NS}si")
|
||||
for idx, new_text in edits.items():
|
||||
si = sis[idx]
|
||||
for c in list(si):
|
||||
si.remove(c)
|
||||
t = etree.SubElement(si, f"{NS}t")
|
||||
t.set("{http://www.w3.org/XML/1998/namespace}space", "preserve")
|
||||
t.text = new_text
|
||||
tree.write(ssp, xml_declaration=True, encoding="UTF-8", standalone=True)
|
||||
|
||||
|
||||
def delete_run_and_renumber(work_dir, si_idx, match_prefix, renum: dict):
|
||||
"""
|
||||
含红 run 的格：删掉文字以 match_prefix 开头的那个 <r>（连同其红色），
|
||||
再按 renum {旧前缀: 新前缀} 顺移后续编号。红 run 之外的一律不动。
|
||||
例：删 "9. " 那条红，renum={"10. ":"9. ","11. ":"10. ","12. ":"11. "}
|
||||
"""
|
||||
ssp = os.path.join(work_dir, "xl", "sharedStrings.xml")
|
||||
tree = etree.parse(ssp)
|
||||
si = tree.getroot().findall(f"{NS}si")[si_idx]
|
||||
target = None
|
||||
for r in si.findall(f"{NS}r"):
|
||||
t = r.find(f"{NS}t")
|
||||
if t is not None and t.text and t.text.startswith(match_prefix):
|
||||
target = r; break
|
||||
if target is None:
|
||||
raise ValueError(f"si[{si_idx}] 没找到以 {match_prefix!r} 开头的 run")
|
||||
si.remove(target)
|
||||
for r in si.findall(f"{NS}r"):
|
||||
t = r.find(f"{NS}t")
|
||||
if t is not None and t.text:
|
||||
for old, new in renum.items():
|
||||
if t.text.startswith(old):
|
||||
t.text = new + t.text[len(old):]; break
|
||||
tree.write(ssp, xml_declaration=True, encoding="UTF-8", standalone=True)
|
||||
|
||||
|
||||
def repack(work_dir, out_xlsx):
|
||||
"""规范重打包：[Content_Types].xml 第一，_rels/ 次之，其余原序。ZIP_DEFLATED。"""
|
||||
if os.path.exists(out_xlsx):
|
||||
os.remove(out_xlsx)
|
||||
files = []
|
||||
for folder, _, fs in os.walk(work_dir):
|
||||
for fn in fs:
|
||||
full = os.path.join(folder, fn)
|
||||
arc = os.path.relpath(full, work_dir).replace(os.sep, "/")
|
||||
files.append((arc, full))
|
||||
|
||||
def key(it):
|
||||
a = it[0]
|
||||
if a == "[Content_Types].xml": return (0, a)
|
||||
if a.startswith("_rels/"): return (1, a)
|
||||
return (2, a)
|
||||
|
||||
files.sort(key=key)
|
||||
with zipfile.ZipFile(out_xlsx, "w", zipfile.ZIP_DEFLATED) as zf:
|
||||
for arc, full in files:
|
||||
zf.write(full, arc)
|
||||
return out_xlsx
|
||||
|
||||
|
||||
def extract(xlsx):
|
||||
"""解压到新临时目录，返回目录路径。"""
|
||||
d = tempfile.mkdtemp(prefix="redxlsx_")
|
||||
with zipfile.ZipFile(xlsx) as z:
|
||||
z.extractall(d)
|
||||
return d
|
||||
|
||||
|
||||
# ---------- CLI ----------
|
||||
def main():
|
||||
ap = argparse.ArgumentParser(description=__doc__, formatter_class=argparse.RawDescriptionHelpFormatter)
|
||||
ap.add_argument("--verify", metavar="XLSX", help="五查（只读）")
|
||||
ap.add_argument("--baseline", metavar="GOOD", help="WPS好基线，用于同构对比")
|
||||
ap.add_argument("--expect-red", type=int, help="改后预期红色run数（删1条红=基线-1）")
|
||||
ap.add_argument("--map", metavar="XLSX", help="列出单元格→sharedString索引")
|
||||
ap.add_argument("--sheet", default="xl/worksheets/sheet1.xml")
|
||||
ap.add_argument("--show-si", nargs=2, metavar=("XLSX", "IDX"), help="打印某条 si 的 run 结构")
|
||||
args = ap.parse_args()
|
||||
|
||||
if args.verify:
|
||||
sys.exit(0 if verify(args.verify, args.baseline, args.expect_red) else 1)
|
||||
if args.map:
|
||||
for coord, idx in sorted(cell_si_map(args.map, args.sheet).items(),
|
||||
key=lambda kv: (kv[0][0], int(re.sub(r"\D", "", kv[0])))):
|
||||
print(f" {coord:>5} -> si[{idx}]")
|
||||
return
|
||||
if args.show_si:
|
||||
show_si(args.show_si[0], int(args.show_si[1]))
|
||||
return
|
||||
ap.print_help()
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
@@ -0,0 +1,85 @@
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
fix-richtext-rpr-order.py — 把 openpyxl CellRichText 写出的 <rPr> 子元素顺序
|
||||
改成 OOXML 合规顺序 (rFont -> sz -> color)。
|
||||
|
||||
⚠️⚠️ 重要警告（2026-06-18 世茂实证）：
|
||||
本脚本只修 rPr 顺序，但实测 **修了顺序 Microsoft Excel 仍报"需要修复"**。
|
||||
openpyxl 生成的富文本表在 Excel 严格校验下还有其他不合规处（去掉富文本只留
|
||||
纯文本都仍报错）。所以本脚本 **不保证解决 Excel 报错**，仅作"试过什么"的记录。
|
||||
|
||||
正解：不要用 CellRichText 做局部标红/加粗，改用纯文本前缀（【需客户核实】…）。
|
||||
详见 ../references/openpyxl-excel-richtext-pitfall.md
|
||||
|
||||
用法：
|
||||
python fix-richtext-rpr-order.py <文件.xlsx> # 原地修复
|
||||
python fix-richtext-rpr-order.py <文件.xlsx> --check # 只检查，不改
|
||||
python fix-richtext-rpr-order.py <文件.xlsx> --sheet sheet2.xml # 指定 sheet
|
||||
"""
|
||||
import sys, re, zipfile, os
|
||||
|
||||
|
||||
def analyze(xlsx, sheet_name="xl/worksheets/sheet1.xml"):
|
||||
z = zipfile.ZipFile(xlsx)
|
||||
if sheet_name not in z.namelist():
|
||||
sheets = [n for n in z.namelist() if re.match(r"xl/worksheets/sheet\d+\.xml$", n)]
|
||||
print(f"指定 sheet 不存在；可用：{sheets}")
|
||||
return None, None
|
||||
xml = z.read(sheet_name).decode("utf-8")
|
||||
rprs = re.findall(r"<rPr>(.*?)</rPr>", xml, flags=re.S)
|
||||
bad = 0
|
||||
for inner in rprs:
|
||||
p_sz = inner.find("<sz")
|
||||
p_color = inner.find("<color")
|
||||
if p_sz != -1 and p_color != -1 and p_sz > p_color:
|
||||
bad += 1 # color 在 sz 之前 = 错误顺序
|
||||
return xml, (len(rprs), bad)
|
||||
|
||||
|
||||
def fix(xlsx, sheet_name="xl/worksheets/sheet1.xml"):
|
||||
xml, stats = analyze(xlsx, sheet_name)
|
||||
if xml is None:
|
||||
return
|
||||
total, bad = stats
|
||||
print(f"rPr 总数 {total}，错误顺序 {bad}")
|
||||
if bad == 0:
|
||||
print("无需修复（顺序已合规）。注意：顺序合规 ≠ Excel 不报错，见脚本顶部警告。")
|
||||
return
|
||||
|
||||
def _fix(m):
|
||||
inner = m.group(1)
|
||||
rf = re.search(r"<rFont[^/]*/>", inner)
|
||||
cs = re.search(r"<charset[^/]*/>", inner)
|
||||
fam = re.search(r"<family[^/]*/>", inner)
|
||||
b = re.search(r"<b[^/]*/>", inner)
|
||||
i = re.search(r"<i[^/]*/>", inner)
|
||||
sz = re.search(r"<sz[^/]*/>", inner)
|
||||
co = re.search(r"<color[^/]*/>", inner)
|
||||
# OOXML 顺序: rFont, charset, family, b, i, ..., sz, color
|
||||
parts = [x.group(0) for x in (rf, cs, fam, b, i, sz, co) if x]
|
||||
return "<rPr>" + "".join(parts) + "</rPr>"
|
||||
|
||||
fixed = re.sub(r"<rPr>(.*?)</rPr>", _fix, xml, flags=re.S)
|
||||
tmp = xlsx + ".tmp"
|
||||
with zipfile.ZipFile(xlsx, "r") as zin, zipfile.ZipFile(tmp, "w", zipfile.ZIP_DEFLATED) as zo:
|
||||
for it in zin.namelist():
|
||||
zo.writestr(it, fixed.encode("utf-8") if it == sheet_name else zin.read(it))
|
||||
os.replace(tmp, xlsx)
|
||||
print(f"已修复并写回 {xlsx}")
|
||||
print("⚠️ 仍需用 Microsoft Excel 实际打开验证——本脚本不保证消除 Excel 报错。")
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
if len(sys.argv) < 2:
|
||||
print(__doc__)
|
||||
sys.exit(1)
|
||||
path = sys.argv[1]
|
||||
sheet = "xl/worksheets/sheet1.xml"
|
||||
if "--sheet" in sys.argv:
|
||||
sheet = "xl/worksheets/" + sys.argv[sys.argv.index("--sheet") + 1]
|
||||
if "--check" in sys.argv:
|
||||
_, stats = analyze(path, sheet)
|
||||
if stats:
|
||||
print(f"rPr 总数 {stats[0]}，错误顺序 {stats[1]}")
|
||||
else:
|
||||
fix(path, sheet)
|
||||
@@ -0,0 +1,132 @@
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
I列类目覆盖检查器 — 建表后跑，报警但不阻断。
|
||||
检查I列是否覆盖了足够多的固定类目，不够就报警提示人工核查。
|
||||
|
||||
用法: python3 i-column-coverage-check.py <xlsx_file>
|
||||
|
||||
规则：
|
||||
租赁合同行：21个固定类目，≥15个不报警，<15个报警提示核查
|
||||
物业合同行：15个固定类目，≥10个不报警，<10个报警提示核查
|
||||
能耗协议/其他：不检查
|
||||
|
||||
报警≠阻断：有些合同确实没这么多类目，报警只是提醒逐一确认"是真没有还是漏了"。
|
||||
"""
|
||||
import sys, re
|
||||
import openpyxl
|
||||
|
||||
LEASE_CATEGORIES = [
|
||||
'用途', '转租', '装修改造', '广告标识', '非竞争', '维修责任', '保险要求',
|
||||
'物业服务联动', '配套设施', '出租方变更', '解除权机制', '违约金机制',
|
||||
'不可抗力', '征收拆迁', '房屋抵押查封', '政策变化', '到期处理',
|
||||
'恢复原状', '优先权', '管辖', '备案'
|
||||
]
|
||||
|
||||
PROPERTY_CATEGORIES = [
|
||||
'物业服务内容', '服务标准', '公共能耗费', '特约服务', '共用设施管理',
|
||||
'装修管理', '安保措施', '消防安全', '保险要求', '联动终止',
|
||||
'违约责任', '退出交接', '免责条款', '不可抗力', '管辖'
|
||||
]
|
||||
|
||||
LEASE_THRESHOLD = 15
|
||||
PROPERTY_THRESHOLD = 10
|
||||
|
||||
|
||||
def check_row(row_num, cell_value, contract_type):
|
||||
"""检查一行I列的类目覆盖情况"""
|
||||
if not cell_value:
|
||||
return None
|
||||
|
||||
text = str(cell_value)
|
||||
|
||||
if contract_type == 'lease':
|
||||
categories = LEASE_CATEGORIES
|
||||
threshold = LEASE_THRESHOLD
|
||||
type_name = '租赁合同'
|
||||
elif contract_type == 'property':
|
||||
categories = PROPERTY_CATEGORIES
|
||||
threshold = PROPERTY_THRESHOLD
|
||||
type_name = '物业合同'
|
||||
else:
|
||||
return None
|
||||
|
||||
found = []
|
||||
missing = []
|
||||
for cat in categories:
|
||||
# 检查类目是否出现在文本中（允许【】或[]包裹）
|
||||
if re.search(rf'[·\-\[\【]{cat}[\]\】]?', text) or cat in text:
|
||||
found.append(cat)
|
||||
else:
|
||||
missing.append(cat)
|
||||
|
||||
coverage = len(found)
|
||||
total = len(categories)
|
||||
|
||||
result = {
|
||||
'row': row_num,
|
||||
'type': type_name,
|
||||
'coverage': coverage,
|
||||
'total': total,
|
||||
'threshold': threshold,
|
||||
'found': found,
|
||||
'missing': missing,
|
||||
'alert': coverage < threshold
|
||||
}
|
||||
return result
|
||||
|
||||
|
||||
def main():
|
||||
if len(sys.argv) < 2:
|
||||
print("用法: python3 i-column-coverage-check.py <xlsx_file>")
|
||||
sys.exit(1)
|
||||
|
||||
filepath = sys.argv[1]
|
||||
wb = openpyxl.load_workbook(filepath)
|
||||
ws = wb.active
|
||||
|
||||
results = []
|
||||
for row in range(1, ws.max_row + 1):
|
||||
# 判断合同类型（C列）
|
||||
c_val = str(ws.cell(row, 3).value or '').strip()
|
||||
i_val = ws.cell(row, 9).value
|
||||
|
||||
if not i_val or not c_val:
|
||||
continue
|
||||
|
||||
if '租赁' in c_val and '物业' not in c_val:
|
||||
contract_type = 'lease'
|
||||
elif '物业' in c_val:
|
||||
contract_type = 'property'
|
||||
else:
|
||||
continue # 能耗协议等不检查
|
||||
|
||||
result = check_row(row, i_val, contract_type)
|
||||
if result:
|
||||
results.append(result)
|
||||
|
||||
if not results:
|
||||
print("⚠️ 未找到租赁/物业合同行，请确认文件结构。")
|
||||
sys.exit(0)
|
||||
|
||||
all_pass = True
|
||||
for r in results:
|
||||
status = '✅' if not r['alert'] else '⚠️'
|
||||
if r['alert']:
|
||||
all_pass = False
|
||||
print(f"{status} Row {r['row']} [{r['type']}]: {r['coverage']}/{r['total']} 类目"
|
||||
f"（阈值{r['threshold']}）")
|
||||
if r['alert']:
|
||||
print(f" 缺失类目: {', '.join(r['missing'])}")
|
||||
print(f" → 请逐一核查：是合同确实没有，还是提取时漏了？")
|
||||
print()
|
||||
|
||||
if all_pass:
|
||||
print(f"\n✅ I列类目覆盖检查通过（{len(results)}行全部达标）。")
|
||||
else:
|
||||
alert_count = sum(1 for r in results if r['alert'])
|
||||
print(f"\n⚠️ {alert_count}行I列类目覆盖不足，请核查确认。")
|
||||
print(" 说明：报警≠错误。有些合同确实没这么多类目，核查确认即可。")
|
||||
|
||||
|
||||
if __name__ == '__main__':
|
||||
main()
|
||||
@@ -0,0 +1,95 @@
|
||||
#!/usr/bin/env python3
|
||||
# -*- coding: utf-8 -*-
|
||||
"""
|
||||
K/L 分工自检 / K-L Column Separation Check
|
||||
==========================================
|
||||
校区梳理表 Step5 终审必跑：验证 K 列(法律风险) 与 L 列(模版差异) 职责分离。
|
||||
|
||||
· K 列(第 11 列)= 独立法律审查，从合同条款本身起笔，**绝不引模版**
|
||||
→ 不得出现 "模版 / 07模版 / 07-房屋 / 07标准 / 相对模版 / 被放宽 / 被删除 / 被改为"
|
||||
· L 列(第 12 列)= 纯客观文本对比，只陈述 "模版表述为X；本合同表述为Y"
|
||||
→ 不得出现 "风险 / 建议 / 不利 / 详见"(判断词与向 K 列导流的话)
|
||||
|
||||
⚠️ K 列匹配 "07模版 / 07-房屋 / 07标准" 而非裸 "07"——裸 07 会误命中金额数字
|
||||
(如租金 377,507.80 里的 "507")，2026-06-24 跃龙路实证误报，已修正。
|
||||
|
||||
判据·遮模版测试：把"模版怎么写"整个遮住，K 列那条风险论述仍完整成立才算独立审查；
|
||||
遮住就垮 = L 列逻辑混进了 K 列。
|
||||
|
||||
用法：
|
||||
python3 kl-separation-check.py <校区梳理表.xlsx>
|
||||
退出码：0 = 通过；1 = 有违规(需回去拆分 K/L)；2 = 用法错误
|
||||
|
||||
注：本脚本只查 K(11)/L(12) 两列的数据行。整体段(合并 A:L，在第 1 列)里
|
||||
"【与07标准模版的文本差异】" 小节合法含"模版/07"，不在本脚本检查范围——
|
||||
那是整体段按设计单独成段的客观对比，不是 K 列。
|
||||
"""
|
||||
import sys
|
||||
import re
|
||||
import openpyxl
|
||||
|
||||
K_FORBIDDEN_LITERAL = ["模版", "相对模版", "被放宽", "被删除", "被改为"]
|
||||
K_FORBIDDEN_REGEX = r"07模版|07-?房屋|07标准"
|
||||
L_FORBIDDEN_LITERAL = ["风险", "建议", "不利", "详见"]
|
||||
|
||||
|
||||
def cell_text(cell):
|
||||
"""取单元格纯文本，兼容 CellRichText(可迭代) 与标量。"""
|
||||
v = cell.value
|
||||
if v is None:
|
||||
return ""
|
||||
if isinstance(v, str):
|
||||
return v
|
||||
try:
|
||||
return "".join(getattr(t, "text", str(t)) for t in v)
|
||||
except TypeError:
|
||||
return str(v)
|
||||
|
||||
|
||||
def is_header(text):
|
||||
"""表头行启发式：K 表头='法律风险…'/'风险点…'；L 表头='与…模版差异'。"""
|
||||
head = text[:10]
|
||||
if ("法律风险" in head or "风险点" in head) and len(text) < 40:
|
||||
return True
|
||||
if text.startswith("与") and "模版差异" in text and len(text) < 40:
|
||||
return True
|
||||
return False
|
||||
|
||||
|
||||
def check(path):
|
||||
wb = openpyxl.load_workbook(path)
|
||||
violations = []
|
||||
for ws in wb.worksheets:
|
||||
for r in range(1, ws.max_row + 1):
|
||||
k = cell_text(ws.cell(r, 11))
|
||||
l = cell_text(ws.cell(r, 12))
|
||||
if k and not is_header(k):
|
||||
kb = [w for w in K_FORBIDDEN_LITERAL if w in k]
|
||||
kb += re.findall(K_FORBIDDEN_REGEX, k)
|
||||
if kb:
|
||||
violations.append((ws.title, f"K{r}", "独立审查不得引模版", kb))
|
||||
if l and not is_header(l):
|
||||
lb = [w for w in L_FORBIDDEN_LITERAL if w in l]
|
||||
if lb:
|
||||
violations.append((ws.title, f"L{r}", "纯客观对比不得下判断", lb))
|
||||
return violations
|
||||
|
||||
|
||||
def main():
|
||||
if len(sys.argv) < 2:
|
||||
print("用法: python3 kl-separation-check.py <校区梳理表.xlsx>")
|
||||
sys.exit(2)
|
||||
v = check(sys.argv[1])
|
||||
if not v:
|
||||
print("✅ K/L 分工自检通过：K 列零模版引用、L 列零判断词。")
|
||||
sys.exit(0)
|
||||
print("❌ K/L 分工自检发现违规（需回去拆分）：")
|
||||
for sheet, cell, why, hits in v:
|
||||
print(f" [{sheet}] {cell}: {why} — 命中 {hits}")
|
||||
print("\n判据·遮模版测试：把'模版怎么写'遮住，K 列风险论述仍完整成立才算独立。")
|
||||
print("L 列只陈述'模版表述为X；本合同表述为Y'，判断与建议归 K 列。")
|
||||
sys.exit(1)
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
@@ -0,0 +1,201 @@
|
||||
#!/usr/bin/env python3
|
||||
# -*- coding: utf-8 -*-
|
||||
"""
|
||||
南通新东方租赁梳理 — Excel Builder v2
|
||||
=====================================
|
||||
从nantong-lease-audit workflow的thread输出中提取结构化数据，
|
||||
生成12列Excel汇总表。K列和L列直接从rule-analyzer和template-diff步骤提取。
|
||||
|
||||
用法：
|
||||
python3 nantong-excel-builder.py <thread-id> <校区名> <输出xlsx路径> [文件名]
|
||||
"""
|
||||
import sys, os, subprocess, json, re
|
||||
|
||||
UWF = "/home/maggie/.hermes/node/bin/uwf"
|
||||
|
||||
def run(cmd):
|
||||
r = subprocess.run(cmd, capture_output=True, text=True)
|
||||
return r.stdout
|
||||
|
||||
def get_thread_read(thread_id):
|
||||
"""获取thread的完整markdown输出"""
|
||||
return run([UWF, "thread", "read", thread_id, "--quota", "200000", "--start"])
|
||||
|
||||
def extract_step_output(thread_text, role_name):
|
||||
"""从thread read的markdown中提取某role的<output>内容"""
|
||||
pattern = rf'## Step \d+: {role_name}.*?\n<output>\n(.*?)\n</output>'
|
||||
m = re.search(pattern, thread_text, re.DOTALL)
|
||||
return m.group(1) if m else ""
|
||||
|
||||
def extract_frontmatter(output_text):
|
||||
"""从step output中提取YAML frontmatter为dict"""
|
||||
# YAML frontmatter is between the first --- and second ---
|
||||
m = re.search(r'^---\n(.*?)\n---', output_text, re.DOTALL)
|
||||
if not m:
|
||||
# Try without leading ---
|
||||
m = re.search(r'^(.*?)\n---', output_text, re.DOTALL)
|
||||
if not m:
|
||||
return {}, output_text
|
||||
|
||||
fm_text = m.group(1)
|
||||
body = output_text[m.end():].strip()
|
||||
|
||||
result = {}
|
||||
current_key = None
|
||||
current_val = []
|
||||
is_multiline = False
|
||||
|
||||
for line in fm_text.split('\n'):
|
||||
if not line.strip():
|
||||
if is_multiline:
|
||||
current_val.append('')
|
||||
continue
|
||||
|
||||
# Check for new key: value
|
||||
km = re.match(r'^(\w[\w_]*):\s*(.*)', line)
|
||||
if km and not line.startswith(' '):
|
||||
# Save previous key
|
||||
if current_key:
|
||||
result[current_key] = '\n'.join(current_val).strip()
|
||||
current_key = km.group(1)
|
||||
val = km.group(2).strip()
|
||||
if val == '|' or val == '':
|
||||
is_multiline = True
|
||||
current_val = []
|
||||
else:
|
||||
is_multiline = False
|
||||
current_val = [val]
|
||||
elif is_multiline and current_key:
|
||||
current_val.append(line.strip())
|
||||
|
||||
if current_key:
|
||||
result[current_key] = '\n'.join(current_val).strip()
|
||||
|
||||
return result, body
|
||||
|
||||
def main():
|
||||
if len(sys.argv) < 4:
|
||||
print("用法: python3 nantong-excel-builder.py <thread-id> <校区名> <输出xlsx路径> [文件名]")
|
||||
sys.exit(1)
|
||||
|
||||
thread_id = sys.argv[1]
|
||||
campus = sys.argv[2]
|
||||
output_path = sys.argv[3]
|
||||
filename = sys.argv[4] if len(sys.argv) > 4 else ""
|
||||
|
||||
# 1. 获取thread完整输出
|
||||
print(f"读取thread {thread_id} ...")
|
||||
thread_text = get_thread_read(thread_id)
|
||||
|
||||
# 2. 解析classifier
|
||||
cls_output = extract_step_output(thread_text, 'classifier')
|
||||
cls_fm, cls_body = extract_frontmatter(cls_output)
|
||||
print(f"Classifier: campus={cls_fm.get('campus','?')}, template={cls_fm.get('template_type','?')}")
|
||||
|
||||
# 3. 解析template-diff → L列
|
||||
td_output = extract_step_output(thread_text, 'template-d')
|
||||
td_fm, td_body = extract_frontmatter(td_output)
|
||||
diff_detail = td_fm.get('diff_detail', td_body)
|
||||
print(f"Template-diff: {td_fm.get('total_diffs', '?')}处差异")
|
||||
|
||||
# 4. 解析rule-analyzer → K列
|
||||
ra_output = extract_step_output(thread_text, 'rule-analy')
|
||||
ra_fm, ra_body = extract_frontmatter(ra_output)
|
||||
risk_detail = ra_fm.get('risk_detail', ra_body)
|
||||
term_analysis = ra_fm.get('termination_analysis', '')
|
||||
if term_analysis:
|
||||
risk_detail += '\n\n' + term_analysis
|
||||
print(f"Rule-analyzer: {ra_fm.get('risk_count', '?')}项风险")
|
||||
|
||||
# 5. 解析data-extractor → B-J列
|
||||
de_output = extract_step_output(thread_text, 'data-extra')
|
||||
de_fm, de_body = extract_frontmatter(de_output)
|
||||
|
||||
# 从data-extractor的output中提取B-J列
|
||||
columns = {}
|
||||
for col_letter in 'BCDEFGHIJ':
|
||||
# Try pattern "B. 文件名称：xxx" or just the value after the column letter
|
||||
pattern = rf'{col_letter}\.\s+[^：:]+[：:]\s*(.*?)(?=\n[A-L]\.\s|\nh_column|\Z)'
|
||||
m = re.search(pattern, de_body, re.DOTALL)
|
||||
if m:
|
||||
columns[col_letter] = m.group(1).strip()
|
||||
else:
|
||||
columns[col_letter] = ''
|
||||
|
||||
# 文件名
|
||||
if filename:
|
||||
columns['B'] = filename
|
||||
elif not columns.get('B'):
|
||||
columns['B'] = cls_fm.get('ocr_text_path', '').split('/')[-1].replace('.md', '.pdf')
|
||||
|
||||
# K列 = 法律风险（从rule-analyzer提取）
|
||||
columns['K'] = risk_detail[:8000] if risk_detail else '（法律风险分析待补充）'
|
||||
|
||||
# L列 = 模版差异（从template-diff提取）
|
||||
columns['L'] = diff_detail[:5000] if diff_detail else '（模版差异分析待补充）'
|
||||
|
||||
print(f"Columns: B={columns.get('B','?')[:30]} | K={len(columns.get('K',''))}chars | L={len(columns.get('L',''))}chars")
|
||||
|
||||
# 6. 生成Excel
|
||||
import openpyxl
|
||||
from openpyxl.styles import Font, PatternFill, Alignment, Border, Side
|
||||
|
||||
F = Font(name='微软雅黑', size=10)
|
||||
FB = Font(name='微软雅黑', size=10, bold=True)
|
||||
TITLE_FONT = Font(name='微软雅黑', size=14, bold=True, color='FFFFFFFF')
|
||||
fill_title = PatternFill(start_color='FF8B1A2B', fill_type='solid')
|
||||
fill_sec = PatternFill(start_color='FFC0504D', fill_type='solid')
|
||||
fill_hdr = PatternFill(start_color='FFE2EFDA', fill_type='solid')
|
||||
fill_sub = PatternFill(start_color='FFF2F2F2', fill_type='solid')
|
||||
thin = Side(style='thin')
|
||||
border = Border(left=thin, right=thin, top=thin, bottom=thin)
|
||||
AL = Alignment(horizontal='left', vertical='top', wrap_text=True)
|
||||
AC = Alignment(horizontal='center', vertical='center', wrap_text=True)
|
||||
|
||||
wb = openpyxl.Workbook()
|
||||
ws = wb.active
|
||||
ws.title = campus[:31] # sheet name max 31 chars
|
||||
|
||||
widths = dict(A=5, B=20, C=17, D=27, E=23, F=9, G=21, H=36.33, I=34, J=8, K=50, L=35)
|
||||
for c, w in widths.items():
|
||||
ws.column_dimensions[c].width = w
|
||||
|
||||
def merge_row(r, text, font, fill, h=None, al=AC):
|
||||
ws.merge_cells(f'A{r}:L{r}')
|
||||
cell = ws.cell(r, 1, text); cell.font = font; cell.fill = fill; cell.alignment = al
|
||||
for col in range(1, 13):
|
||||
ws.cell(r, col).fill = fill; ws.cell(r, col).border = border
|
||||
if h: ws.row_dimensions[r].height = h
|
||||
|
||||
r = 1
|
||||
merge_row(r, f'{campus} — 租赁合同梳理', TITLE_FONT, fill_title, 30); r += 1
|
||||
|
||||
proj = (f"物业项目：{cls_fm.get('property_address', '未知')}\n"
|
||||
f"甲方：{cls_fm.get('party_a', '未知')}\n"
|
||||
f"乙方：{cls_fm.get('party_b', '未知')}")
|
||||
merge_row(r, proj, Font(name='微软雅黑', size=10, bold=True, color='FF404040'), fill_sub, 76, AL); r += 1
|
||||
|
||||
HDR = ['序号','文件名称','合同类型','合同当事人','租赁标的/服务范围','面积(㎡)',
|
||||
'合同期限','金额/费用','核心内容','当前状态','法律风险（站乙方立场）','与07标准模版差异']
|
||||
for ci, h in enumerate(HDR, 1):
|
||||
c = ws.cell(r, ci, h); c.font = FB; c.fill = fill_hdr; c.alignment = AC; c.border = border
|
||||
ws.row_dimensions[r].height = 30; r += 1
|
||||
|
||||
# 数据行
|
||||
row = ['1']
|
||||
for col in 'BCDEFGHIJKL':
|
||||
row.append(columns.get(col, ''))
|
||||
|
||||
for ci, v in enumerate(row, 1):
|
||||
c = ws.cell(r, ci, v); c.font = F
|
||||
c.alignment = AC if ci in (1,3,6,10) else AL; c.border = border
|
||||
ws.row_dimensions[r].height = 409.5
|
||||
|
||||
ws.freeze_panes = f'A{r+1}'
|
||||
|
||||
os.makedirs(os.path.dirname(output_path) or '.', exist_ok=True)
|
||||
wb.save(output_path)
|
||||
print(f"\n✅ 已保存: {output_path}")
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
@@ -0,0 +1,116 @@
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
OCR乱码检测器 — Step1 OCR完成后必跑。
|
||||
扫描OCR文本中所有疑似乱码行，输出vision核实清单。
|
||||
每一处乱码都必须vision对应PDF页面核实后才能进Step2。
|
||||
|
||||
用法: python3 ocr-garble-detect.py <ocr_file.md>
|
||||
|
||||
判定规则：
|
||||
1. 多个无意义英文片段（连续3+字母非常见词）
|
||||
2. 中文占比过低（正常合同行>50%，低于30%标红）
|
||||
3. 中英混杂碎片（典型OCR乱码模式）
|
||||
4. 异常符号密集（>20%非正常字符）
|
||||
|
||||
误报处理：
|
||||
- 纯数字表格行（日期+金额）→ 正常，核对数字即可
|
||||
- 邮箱/网址/银行账号 → 正常
|
||||
- 英文缩写（USD/RMB/PDF）→ 正常
|
||||
真正需要vision的是：含中文碎片+英文乱码的混合行（如"oe方,同Se"）
|
||||
|
||||
教训(凤凰文化0701)：
|
||||
Line 204 "Se【2024】年【10】月【15】日" 被跳过未核实，
|
||||
导致整段违约金条款丢失（实际是"初年年租金20%作为违约金"）。
|
||||
代价=审查结论反转（"无违约金"→"有20%违约金"）。
|
||||
"""
|
||||
import re, sys
|
||||
|
||||
def is_garbled(line):
|
||||
"""判断一行是否疑似乱码，返回原因或None"""
|
||||
stripped = line.strip()
|
||||
if not stripped or len(stripped) < 5:
|
||||
return None
|
||||
|
||||
# 1. 连续3+个无意义英文字母组合（非常见英文词）
|
||||
nonsense_en = re.findall(r'[a-zA-Z]{3,}', stripped)
|
||||
common_words = {'pdf','ocr','usd','rmb','the','and','for','with','from',
|
||||
'www','com','xdf','jpg','png','doc','docx','xlsx','occ',
|
||||
'vision','step','check','null','true','false'}
|
||||
real_nonsense = [w for w in nonsense_en
|
||||
if w.lower() not in common_words
|
||||
and not re.match(r'^[A-Z]{1,4}$', w)]
|
||||
if len(real_nonsense) >= 2:
|
||||
return f"多个无意义英文片段: {real_nonsense[:3]}"
|
||||
|
||||
# 2. 单行中文字符占比过低（正常合同行中文应>50%）
|
||||
chinese_chars = len(re.findall(r'[\u4e00-\u9fff]', stripped))
|
||||
total_chars = len(re.findall(r'\S', stripped))
|
||||
if total_chars > 10 and chinese_chars / total_chars < 0.3:
|
||||
# 排除纯数字表格行（日期+金额）和邮箱/账号行
|
||||
if re.match(r'^[\d\.\-\s\|/,]+$', stripped):
|
||||
return None # 纯数字表格行
|
||||
if '@' in stripped or re.match(r'^[A-Z]{2,4}:', stripped):
|
||||
return None # 邮箱或字段标签
|
||||
return f"中文占比过低({chinese_chars}/{total_chars}={chinese_chars/total_chars:.0%})"
|
||||
|
||||
# 3. 常见OCR乱码模式：小写英文碎片+中文混杂
|
||||
if re.search(r'[a-z]{2,}\s+[a-z]{2,}\s+[a-z]{2,}', stripped) and chinese_chars > 0:
|
||||
return "中英混杂碎片（典型OCR乱码）"
|
||||
|
||||
# 3b. 日期区域英文字母污染（凤凰文化10.2教训：Se【2024】年【10】月→整段丢失）
|
||||
if re.search(r'[A-Za-z]{2,}\s*【\d{4}】', stripped) and chinese_chars > 0:
|
||||
return "日期区域字母污染（高风险：可能整段条款被OCR吃掉）"
|
||||
|
||||
# 4. 特殊符号异常密集
|
||||
special = len(re.findall(r'[^\w\u4e00-\u9fff\s，。、；：""''（）【】《》\-\+\.\%\/\|]', stripped))
|
||||
if special > 5 and total_chars > 0 and special / total_chars > 0.2:
|
||||
return f"异常符号密集({special}个)"
|
||||
|
||||
return None
|
||||
|
||||
|
||||
def main():
|
||||
if len(sys.argv) < 2:
|
||||
print("用法: python3 ocr-garble-detect.py <ocr_file.md>")
|
||||
sys.exit(1)
|
||||
|
||||
filepath = sys.argv[1]
|
||||
with open(filepath, 'r') as f:
|
||||
lines = f.readlines()
|
||||
|
||||
garbled = []
|
||||
for i, line in enumerate(lines, 1):
|
||||
reason = is_garbled(line)
|
||||
if reason:
|
||||
garbled.append((i, line.strip()[:80], reason))
|
||||
|
||||
if not garbled:
|
||||
print("✅ 未检测到明显乱码行。可以进入Step 2。")
|
||||
else:
|
||||
# 区分真乱码 vs 可能误报（纯数字/邮箱等）
|
||||
real_garble = [g for g in garbled if '无意义英文' in g[2] or '中英混杂' in g[2]]
|
||||
maybe_garble = [g for g in garbled if g not in real_garble]
|
||||
|
||||
print(f"⚠️ 检测到 {len(garbled)} 处疑似乱码（其中 {len(real_garble)} 处高危）\n")
|
||||
|
||||
if real_garble:
|
||||
print("🔴 高危乱码（必须vision核实，不核实不进Step2）：")
|
||||
for lineno, text, reason in real_garble:
|
||||
print(f" Line {lineno:3d} | {reason}")
|
||||
print(f" | {text}")
|
||||
print()
|
||||
|
||||
if maybe_garble:
|
||||
print("🟡 疑似乱码（核对数字/格式是否正确）：")
|
||||
for lineno, text, reason in maybe_garble:
|
||||
print(f" Line {lineno:3d} | {reason}")
|
||||
print(f" | {text}")
|
||||
print()
|
||||
|
||||
print(f"--- 高危 {len(real_garble)} 处必须vision核实 + 疑似 {len(maybe_garble)} 处核对数值 ---")
|
||||
print("操作：对每处高危乱码，定位PDF页码 → vision精读 → 记录修正内容")
|
||||
print("全部消灭后才能进入 Step 2。")
|
||||
|
||||
|
||||
if __name__ == '__main__':
|
||||
main()
|
||||
@@ -0,0 +1,232 @@
|
||||
#!/usr/bin/env python3
|
||||
# -*- coding: utf-8 -*-
|
||||
"""
|
||||
OCR完整性检查 / OCR Integrity Check
|
||||
==================================
|
||||
物理依赖链第一环：OCR → 建表
|
||||
|
||||
检查OCR后的.md文件是否有未补全的乱码/占位符。
|
||||
如果有，拒绝生成checkpoint，建表脚本将因此中止。
|
||||
|
||||
用法：
|
||||
python3 ocr-integrity-check.py <工作目录>
|
||||
|
||||
检查模式：
|
||||
1. 公司名乱码：连续3+英文字母出现在中文语境中（如"HAT"代替公司名）
|
||||
2. 地址残缺：【…】、〔…〕、"了 B}"等占位符模式
|
||||
3. 关键数字乱码：字母代替数字（如"5 1 te"代替"号1幢"）
|
||||
4. OCR标记残留：OCR模糊、OCR无法识别、待补全等
|
||||
|
||||
通过 → 生成 step1.verified checkpoint（含签名）
|
||||
失败 → 列出所有需要vision补全的字段，不生成checkpoint
|
||||
|
||||
退出码：0=通过，1=有问题需补全
|
||||
|
||||
🔴 安全机制：checkpoint文件包含HMAC签名，防止手动创建
|
||||
"""
|
||||
import sys, os, re, json, glob, hmac, hashlib
|
||||
from datetime import datetime
|
||||
|
||||
# checkpoint签名密钥（固定值，脚本内置）
|
||||
CHECKPOINT_SECRET = b'ocr-integrity-check-v1-2026-06-29'
|
||||
|
||||
def generate_checkpoint_signature(workdir, md_files, timestamp):
|
||||
"""生成checkpoint签名"""
|
||||
# 签名内容：工作目录+文件列表+时间戳
|
||||
sign_content = f"{workdir}|{','.join(sorted(md_files))}|{timestamp}"
|
||||
sig = hmac.new(CHECKPOINT_SECRET, sign_content.encode('utf-8'), hashlib.sha256).hexdigest()
|
||||
return sig[:16] # 取前16位
|
||||
|
||||
def check_ocr_file(md_path):
|
||||
"""检查单个.md文件的OCR完整性"""
|
||||
issues = []
|
||||
|
||||
with open(md_path, 'r', encoding='utf-8') as f:
|
||||
content = f.read()
|
||||
lines = content.split('\n')
|
||||
|
||||
# 模式1：公司名乱码 - 连续3+大写字母或混合大小写英文（中文语境中）
|
||||
# 例如："HAT CP RRA)" 应该是公司名
|
||||
company_garble = re.finditer(r'[A-Z]{3,}(?:\s+[A-Z]{2,}){0,2}', content)
|
||||
for m in company_garble:
|
||||
# 排除常见的合理英文（如OCR、PDF、API等）
|
||||
if m.group() not in ['OCR', 'PDF', 'API', 'URL', 'HTTP', 'HTTPS', 'JSON', 'XML', 'LOGO', 'EMS', 'WPS',
|
||||
'PAGE', 'REMARK', 'NOTE', 'TODO', 'FIXME', 'HACK', 'XXX', 'EOF']:
|
||||
# 排除统一社会信用代码中的字母部分（前后有数字的字母序列）
|
||||
pre = content[max(0, m.start()-2):m.start()]
|
||||
post = content[m.end():min(len(content), m.end()+2)]
|
||||
if (pre and pre[-1:].isdigit()) or (post and post[:1].isdigit()):
|
||||
continue # 信用代码中的字母，跳过
|
||||
line_num = content[:m.start()].count('\n') + 1
|
||||
context_start = max(0, m.start() - 20)
|
||||
context_end = min(len(content), m.end() + 20)
|
||||
context = content[context_start:context_end].replace('\n', ' ')
|
||||
issues.append({
|
||||
'type': '公司名乱码',
|
||||
'line': line_num,
|
||||
'pattern': m.group(),
|
||||
'context': f"...{context}...",
|
||||
'fix': '用vision看原图，补全公司全称'
|
||||
})
|
||||
|
||||
# 模式2：地址残缺占位符
|
||||
placeholder_patterns = [
|
||||
(r'【\.{1,5}】', '中文省略号占位符'),
|
||||
(r'【…】', '中文省略号占位符'),
|
||||
(r'〔\.{1,5}〕', '方括号省略号占位符'),
|
||||
(r'了\s*[A-Za-z0-9]}', '地址残缺模式（如"了 B}"）'),
|
||||
]
|
||||
for pat, desc in placeholder_patterns:
|
||||
for m in re.finditer(pat, content):
|
||||
line_num = content[:m.start()].count('\n') + 1
|
||||
context_start = max(0, m.start() - 20)
|
||||
context_end = min(len(content), m.end() + 20)
|
||||
context = content[context_start:context_end].replace('\n', ' ')
|
||||
issues.append({
|
||||
'type': desc,
|
||||
'line': line_num,
|
||||
'pattern': m.group(),
|
||||
'context': f"...{context}...",
|
||||
'fix': '用vision看原图，补全完整地址'
|
||||
})
|
||||
|
||||
# 模式3：OCR标记残留
|
||||
ocr_markers = [
|
||||
r'OCR模糊',
|
||||
r'OCR无法识别',
|
||||
r'OCR乱码',
|
||||
r'OCR识别失败',
|
||||
r'待补全',
|
||||
r'〔待核PDF〕',
|
||||
r'〔待核〕',
|
||||
]
|
||||
for marker in ocr_markers:
|
||||
for m in re.finditer(marker, content):
|
||||
line_num = content[:m.start()].count('\n') + 1
|
||||
context_start = max(0, m.start() - 15)
|
||||
context_end = min(len(content), m.end() + 15)
|
||||
context = content[context_start:context_end].replace('\n', ' ')
|
||||
issues.append({
|
||||
'type': 'OCR标记残留',
|
||||
'line': line_num,
|
||||
'pattern': m.group(),
|
||||
'context': f"...{context}...",
|
||||
'fix': '用vision看原图补全，删除标记'
|
||||
})
|
||||
|
||||
# 模式4：关键字段中的字母代替数字
|
||||
# 例如："5 1 te 202" 应该是 "号1幢202"
|
||||
# 检测：中文+空格+单个字母+空格+数字 的模式
|
||||
digit_garble = re.finditer(r'[\u4e00-\u9fff]\s+[a-zA-Z]\s+\d{2,4}', content)
|
||||
for m in digit_garble:
|
||||
line_num = content[:m.start()].count('\n') + 1
|
||||
context_start = max(0, m.start() - 10)
|
||||
context_end = min(len(content), m.end() + 10)
|
||||
context = content[context_start:context_end].replace('\n', ' ')
|
||||
issues.append({
|
||||
'type': '数字乱码（字母代替）',
|
||||
'line': line_num,
|
||||
'pattern': m.group(),
|
||||
'context': f"...{context}...",
|
||||
'fix': '用vision看原图，确认正确数字'
|
||||
})
|
||||
|
||||
# 模式5：严重乱码段落（连续3+英文无义词，如"peMet iy ecsapae"、"Fak"开头）
|
||||
# 表明该区域OCR完全失败，不可用于模版比对
|
||||
garble_patterns = re.finditer(r'(?:[a-zA-Z]{3,}\s+){2,}[a-zA-Z]{2,}', content)
|
||||
for m in garble_patterns:
|
||||
# 排除已知英文短语
|
||||
text = m.group().strip()
|
||||
if any(kw in text.lower() for kw in ['page', 'total', 'remark', 'note']):
|
||||
continue
|
||||
line_num = content[:m.start()].count('\n') + 1
|
||||
context_start = max(0, m.start() - 15)
|
||||
context_end = min(len(content), m.end() + 15)
|
||||
context = content[context_start:context_end].replace('\n', ' ')
|
||||
issues.append({
|
||||
'type': '严重乱码段落（OCR完全失败）',
|
||||
'line': line_num,
|
||||
'pattern': text[:40],
|
||||
'context': f"...{context[:60]}...",
|
||||
'fix': '该区域OCR不可读，必须vision核实原文后才能写入比对报告'
|
||||
})
|
||||
|
||||
return issues
|
||||
|
||||
def main():
|
||||
if len(sys.argv) < 2:
|
||||
print("用法: python3 ocr-integrity-check.py <工作目录>")
|
||||
print("例: python3 ocr-integrity-check.py /tmp/人民中路")
|
||||
sys.exit(1)
|
||||
|
||||
workdir = sys.argv[1]
|
||||
if not os.path.isdir(workdir):
|
||||
print(f"❌ 工作目录不存在: {workdir}")
|
||||
sys.exit(1)
|
||||
|
||||
# 查找所有OCR产出的.md文件
|
||||
md_files = glob.glob(os.path.join(workdir, '*.md'))
|
||||
md_files += glob.glob(os.path.join(workdir, 'md', '*.md'))
|
||||
md_files += glob.glob(os.path.join(workdir, 'ocr', '*.md'))
|
||||
|
||||
if not md_files:
|
||||
print(f"❌ 未找到OCR产出的.md文件: {workdir}")
|
||||
sys.exit(1)
|
||||
|
||||
print(f"检查 {len(md_files)} 个OCR文件的完整性...\n")
|
||||
|
||||
all_issues = []
|
||||
for md_file in md_files:
|
||||
fname = os.path.basename(md_file)
|
||||
issues = check_ocr_file(md_file)
|
||||
if issues:
|
||||
all_issues.append((fname, issues))
|
||||
|
||||
checkpoint_path = os.path.join(workdir, 'step1.verified')
|
||||
|
||||
if all_issues:
|
||||
print("❌ OCR完整性检查失败\n")
|
||||
for fname, issues in all_issues:
|
||||
print(f" {fname}: {len(issues)} 个问题")
|
||||
for i, issue in enumerate(issues[:5], 1): # 只显示前5个
|
||||
print(f" {i}. [{issue['type']}] 第{issue['line']}行")
|
||||
print(f" {issue['context']}")
|
||||
print(f" → {issue['fix']}")
|
||||
if len(issues) > 5:
|
||||
print(f" ... 还有 {len(issues) - 5} 个问题")
|
||||
print(f"\n⛔ 未生成checkpoint: {checkpoint_path}")
|
||||
print(" 建表脚本将拒绝执行，直到所有问题用vision补全。")
|
||||
|
||||
# 写入问题清单供后续处理
|
||||
issues_log = os.path.join(workdir, 'step1.issues.json')
|
||||
with open(issues_log, 'w', encoding='utf-8') as f:
|
||||
json.dump({
|
||||
'timestamp': datetime.now().isoformat(),
|
||||
'issues': {fname: issues for fname, issues in all_issues}
|
||||
}, f, ensure_ascii=False, indent=2)
|
||||
print(f" 问题清单已保存: {issues_log}")
|
||||
|
||||
sys.exit(1)
|
||||
else:
|
||||
print("✅ OCR完整性检查通过\n")
|
||||
for md_file in md_files:
|
||||
print(f" ✓ {os.path.basename(md_file)}")
|
||||
|
||||
# 生成checkpoint（含签名）
|
||||
timestamp = datetime.now().isoformat()
|
||||
signature = generate_checkpoint_signature(workdir, md_files, timestamp)
|
||||
|
||||
with open(checkpoint_path, 'w', encoding='utf-8') as f:
|
||||
f.write(f"OCR完整性检查通过\n")
|
||||
f.write(f"时间: {timestamp}\n")
|
||||
f.write(f"文件数: {len(md_files)}\n")
|
||||
for md_file in md_files:
|
||||
f.write(f" - {os.path.basename(md_file)}\n")
|
||||
f.write(f"签名: {signature}\n")
|
||||
|
||||
print(f"\n✓ checkpoint已生成: {checkpoint_path}")
|
||||
print(f" 签名: {signature}")
|
||||
sys.exit(0)
|
||||
|
||||
if __name__ == '__main__':
|
||||
main()
|
||||
@@ -0,0 +1,120 @@
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
output-style-check.py — 检查data-extractor输出的H/K/L列是否符合统一风格规范。
|
||||
用法：python3 output-style-check.py <campus>-row-data.json
|
||||
返回：exit 0 = 通过，exit 1 = 风格不符（列出具体问题）
|
||||
|
||||
This is Layer 3 of the output consistency defense (see references/output-consistency.md).
|
||||
Run AFTER data extraction, BEFORE xlsx generation. If it fails, fix the specific
|
||||
issues in the JSON before proceeding.
|
||||
"""
|
||||
|
||||
import json
|
||||
import sys
|
||||
import re
|
||||
|
||||
def check_h_column(text):
|
||||
"""检查H列（金额/费用）格式"""
|
||||
issues = []
|
||||
|
||||
# 禁止bullet符号
|
||||
if re.search(r'[•\-\*]\s', text):
|
||||
issues.append("H列含bullet符号（•/-/*），应使用段落式叙述")
|
||||
|
||||
# 禁止"大类·条款号"合并标题
|
||||
if re.search(r'【[^】]*·第[一二三四五六七八九十\d]+条', text):
|
||||
issues.append("H列含'【大类·条款号】'合并标题，应分开写")
|
||||
|
||||
# 必须有【】大类标注
|
||||
if '【' not in text:
|
||||
issues.append("H列缺少【】大类标注（如【租金】【付款推算】等）")
|
||||
|
||||
return issues
|
||||
|
||||
def check_k_column(text):
|
||||
"""检查K列（法律风险）格式"""
|
||||
issues = []
|
||||
|
||||
# 禁止统计式开头
|
||||
if re.search(r'\d+项风险（\d+高', text):
|
||||
issues.append("K列用统计式开头（如'10项风险（3高/5中/2低）'），应以【整体评价】开头")
|
||||
|
||||
# 禁止"序号·等级·条款号"标签
|
||||
if re.search(r'\d+\.\s*【[高中低][中高]?·', text):
|
||||
issues.append("K列用'序号·等级·条款号'标签格式（如'1.【高·第十条】'），应用叙述式")
|
||||
|
||||
# 禁止markdown表格
|
||||
if '| #' in text or '|---|' in text:
|
||||
issues.append("K列含markdown表格，应用叙述式段落")
|
||||
|
||||
# 必须有【整体评价】
|
||||
if '【整体评价' not in text:
|
||||
issues.append("K列缺少【整体评价】段落")
|
||||
|
||||
return issues
|
||||
|
||||
def check_l_column(text):
|
||||
"""检查L列（模版差异）格式"""
|
||||
issues = []
|
||||
|
||||
# 禁止统计式开头
|
||||
if re.search(r'\d+处差异（\d+缺失', text):
|
||||
issues.append("L列用统计式开头（如'34处差异（16缺失/15修改/3新增）'），应叙述式说明")
|
||||
|
||||
# 禁止分类小标题
|
||||
if '【核心缺失' in text or '【核心修改' in text:
|
||||
issues.append("L列用'【核心缺失/修改】'分类小标题，应使用编号列表")
|
||||
|
||||
# 禁止"vs"分隔
|
||||
if ' vs ' in text:
|
||||
issues.append("L列用'vs'分隔模版和合同，应用中文叙述（如'模版为XX；本合同为XX'）")
|
||||
|
||||
return issues
|
||||
|
||||
def main():
|
||||
if len(sys.argv) < 2:
|
||||
print("用法: python3 output-style-check.py <campus>-row-data.json")
|
||||
sys.exit(2)
|
||||
|
||||
filepath = sys.argv[1]
|
||||
try:
|
||||
with open(filepath, 'r', encoding='utf-8') as f:
|
||||
data = json.load(f)
|
||||
except Exception as e:
|
||||
print(f"❌ 无法读取文件: {e}")
|
||||
sys.exit(2)
|
||||
|
||||
all_issues = []
|
||||
|
||||
# Check H column (fees)
|
||||
if 'fees' in data and data['fees']:
|
||||
h_issues = check_h_column(data['fees'])
|
||||
all_issues.extend(h_issues)
|
||||
|
||||
# Check K column (risk_detail)
|
||||
if 'risk_detail' in data and data['risk_detail']:
|
||||
k_issues = check_k_column(data['risk_detail'])
|
||||
all_issues.extend(k_issues)
|
||||
|
||||
# Check L column (diff_detail)
|
||||
if 'diff_detail' in data and data['diff_detail']:
|
||||
l_issues = check_l_column(data['diff_detail'])
|
||||
all_issues.extend(l_issues)
|
||||
|
||||
# Check J column (status) - should be just "履行中", no extra text
|
||||
if 'status' in data and data['status']:
|
||||
status = data['status'].strip()
|
||||
if status not in ['履行中', '已到期', '已解除']:
|
||||
all_issues.append(f"J列状态值不规范: '{status}'，应为'履行中'/'已到期'/'已解除'（不加括号说明）")
|
||||
|
||||
if all_issues:
|
||||
print(f"❌ 风格检查未通过（{len(all_issues)}个问题）：")
|
||||
for i, issue in enumerate(all_issues, 1):
|
||||
print(f" {i}. {issue}")
|
||||
sys.exit(1)
|
||||
else:
|
||||
print("✅ 风格检查通过：H/K/L/J列格式符合统一规范")
|
||||
sys.exit(0)
|
||||
|
||||
if __name__ == '__main__':
|
||||
main()
|
||||
@@ -0,0 +1,154 @@
|
||||
#!/usr/bin/env python3
|
||||
# -*- coding: utf-8 -*-
|
||||
"""
|
||||
模版比对验证 / Template Diff Verify
|
||||
===================================
|
||||
物理依赖链第二环：动作B → 建表
|
||||
|
||||
检查subagent的模版比对输出是否存在且内容充实。
|
||||
如果有问题，拒绝生成checkpoint，建表脚本将因此中止。
|
||||
|
||||
用法：
|
||||
python3 template-diff-verify.py <工作目录>
|
||||
|
||||
检查项：
|
||||
1. 工作目录是否有 模版比对-*.md 文件
|
||||
2. 文件大小是否 > 2000 字节（排除空文件或极简概括）
|
||||
3. 是否包含条款号（如"第X条"、"X.X条"）
|
||||
4. 是否包含差异描述（如"模版表述为"、"本合同表述为"）
|
||||
|
||||
通过 → 生成 step2b.verified checkpoint
|
||||
失败 → 拒绝生成checkpoint
|
||||
|
||||
退出码：0=通过，1=有问题
|
||||
"""
|
||||
import sys, os, re, glob
|
||||
from datetime import datetime
|
||||
|
||||
def check_template_diff(workdir):
|
||||
"""检查模版比对输出文件"""
|
||||
issues = []
|
||||
|
||||
# 查找模版比对输出文件
|
||||
diff_files = glob.glob(os.path.join(workdir, '模版比对-*.md'))
|
||||
diff_files += glob.glob(os.path.join(workdir, 'template-diff-*.md'))
|
||||
|
||||
if not diff_files:
|
||||
issues.append({
|
||||
'type': '文件缺失',
|
||||
'detail': f'工作目录 {workdir} 未找到模版比对输出文件（模版比对-*.md 或 template-diff-*.md）',
|
||||
'fix': 'Step2 动作B 必须 delegate_task subagent 做模版比对'
|
||||
})
|
||||
return issues
|
||||
|
||||
for diff_file in diff_files:
|
||||
fname = os.path.basename(diff_file)
|
||||
size = os.path.getsize(diff_file)
|
||||
|
||||
# 检查1：文件大小
|
||||
if size < 2000:
|
||||
issues.append({
|
||||
'type': '内容过短',
|
||||
'detail': f'{fname} 仅 {size} 字节，疑似极简概括而非逐条比对',
|
||||
'fix': 'subagent 应产出详细的逐条比对报告，不是"甲方制式格式，与07模版不同"一句话'
|
||||
})
|
||||
continue
|
||||
|
||||
# 读取文件内容
|
||||
with open(diff_file, 'r', encoding='utf-8') as f:
|
||||
content = f.read()
|
||||
|
||||
# 检查2：是否包含条款号
|
||||
clause_pattern = r'第[一二三四五六七八九十\d]+条|[一二三四五六七八九十\d]+\.\d+'
|
||||
clause_matches = re.findall(clause_pattern, content)
|
||||
if len(clause_matches) < 10:
|
||||
issues.append({
|
||||
'type': '条款号不足',
|
||||
'detail': f'{fname} 仅找到 {len(clause_matches)} 个条款号引用，疑似未逐条比对',
|
||||
'fix': '模版比对必须回 07 原件逐条核对，不能概括性描述'
|
||||
})
|
||||
|
||||
# 检查3：是否包含差异描述关键词
|
||||
diff_keywords = [
|
||||
r'模版表述[为：:]',
|
||||
r'本合同表述[为：:]',
|
||||
r'模版.*本合同',
|
||||
r'差异',
|
||||
r'缺失',
|
||||
r'新增',
|
||||
r'修改为',
|
||||
r'变更为',
|
||||
r'无此条款',
|
||||
r'不存在',
|
||||
]
|
||||
keyword_count = sum(1 for kw in diff_keywords if re.search(kw, content))
|
||||
if keyword_count < 3:
|
||||
issues.append({
|
||||
'type': '差异描述不足',
|
||||
'detail': f'{fname} 差异描述关键词仅 {keyword_count} 个，疑似未详细比对',
|
||||
'fix': '比对报告应包含"模版表述为X；本合同表述为Y"的具体差异描述'
|
||||
})
|
||||
|
||||
# 检查4：行数（逐条比对应该有足够行数）
|
||||
lines = content.split('\n')
|
||||
if len(lines) < 30:
|
||||
issues.append({
|
||||
'type': '行数不足',
|
||||
'detail': f'{fname} 仅 {len(lines)} 行，疑似未逐条展开',
|
||||
'fix': '逐条比对报告应有足够行数覆盖所有条款差异'
|
||||
})
|
||||
|
||||
return issues
|
||||
|
||||
def main():
|
||||
if len(sys.argv) < 2:
|
||||
print("用法: python3 template-diff-verify.py <工作目录>")
|
||||
print("例: python3 template-diff-verify.py /tmp/人民中路")
|
||||
sys.exit(1)
|
||||
|
||||
workdir = sys.argv[1]
|
||||
if not os.path.isdir(workdir):
|
||||
print(f"❌ 工作目录不存在: {workdir}")
|
||||
sys.exit(1)
|
||||
|
||||
print(f"检查模版比对输出...\n")
|
||||
|
||||
issues = check_template_diff(workdir)
|
||||
checkpoint_path = os.path.join(workdir, 'step2b.verified')
|
||||
|
||||
if issues:
|
||||
print("❌ 模版比对验证失败\n")
|
||||
for i, issue in enumerate(issues, 1):
|
||||
print(f" {i}. [{issue['type']}]")
|
||||
print(f" {issue['detail']}")
|
||||
print(f" → {issue['fix']}\n")
|
||||
|
||||
print(f"⛔ 未生成checkpoint: {checkpoint_path}")
|
||||
print(" 建表脚本将拒绝执行，直到模版比对完成。")
|
||||
sys.exit(1)
|
||||
else:
|
||||
# 找到通过的文件
|
||||
diff_files = glob.glob(os.path.join(workdir, '模版比对-*.md'))
|
||||
diff_files += glob.glob(os.path.join(workdir, 'template-diff-*.md'))
|
||||
|
||||
print("✅ 模版比对验证通过\n")
|
||||
for df in diff_files:
|
||||
fname = os.path.basename(df)
|
||||
size = os.path.getsize(df)
|
||||
print(f" ✓ {fname} ({size:,} 字节)")
|
||||
|
||||
# 生成checkpoint
|
||||
with open(checkpoint_path, 'w', encoding='utf-8') as f:
|
||||
f.write(f"模版比对验证通过\n")
|
||||
f.write(f"时间: {datetime.now().isoformat()}\n")
|
||||
f.write(f"文件数: {len(diff_files)}\n")
|
||||
for df in diff_files:
|
||||
fname = os.path.basename(df)
|
||||
size = os.path.getsize(df)
|
||||
f.write(f" - {fname} ({size} 字节)\n")
|
||||
|
||||
print(f"\n✓ checkpoint已生成: {checkpoint_path}")
|
||||
sys.exit(0)
|
||||
|
||||
if __name__ == '__main__':
|
||||
main()
|
||||
@@ -0,0 +1,70 @@
|
||||
#!/usr/bin/env python3
|
||||
"""只读分析 xlsx 每个 sheet 的长内容单元格：按合并宽度+字号估算所需视觉行数与建议行高，
|
||||
与当前行高对比，标出可能截断的行。不修改文件。
|
||||
|
||||
用法: python3 xlsx-rowheight-analyze.py <文件.xlsx> [最小字符阈值,默认80]
|
||||
|
||||
背景见 references/onlyoffice-xlsx-rowheight-rendering.md：
|
||||
- 409.5/409.6pt 是 OnlyOffice 网页编辑器的 clamp 值，不是 xlsx 格式天花板
|
||||
- openpyxl 从文件层可写 >409.5 且 x2t 引擎不 clamp
|
||||
经验系数：中文每字≈2.1 宽度单位（西文≈1.05），每视觉行≈15.5pt(10pt字)。
|
||||
"""
|
||||
import sys, math
|
||||
import openpyxl
|
||||
from openpyxl.utils import get_column_letter, range_boundaries
|
||||
|
||||
DEFAULT_WIDTH = 8.43
|
||||
|
||||
def col_width(ws, col_letter):
|
||||
dim = ws.column_dimensions.get(col_letter)
|
||||
return dim.width if (dim and dim.width) else DEFAULT_WIDTH
|
||||
|
||||
def merged_info(ws, coord):
|
||||
for m in ws.merged_cells.ranges:
|
||||
if coord in m:
|
||||
c0, r0, c1, r1 = range_boundaries(str(m))
|
||||
total = sum(col_width(ws, get_column_letter(c)) for c in range(c0, c1 + 1))
|
||||
return total, str(m)
|
||||
col = ''.join(filter(str.isalpha, coord))
|
||||
return col_width(ws, col), None
|
||||
|
||||
def estimate_height(text, total_width, font_sz):
|
||||
cap = max(total_width, 1)
|
||||
visual_rows = 0
|
||||
for line in text.split("\n"):
|
||||
w = sum((2.1 if ord(ch) > 0x2000 else 1.05) for ch in line)
|
||||
visual_rows += max(1, math.ceil(w / cap))
|
||||
per_row = 15.5 if (font_sz or 11) <= 11 else (font_sz * 1.4)
|
||||
return visual_rows, math.ceil(visual_rows * per_row + 8)
|
||||
|
||||
def main():
|
||||
if len(sys.argv) < 2:
|
||||
print(__doc__); sys.exit(1)
|
||||
path = sys.argv[1]
|
||||
threshold = int(sys.argv[2]) if len(sys.argv) > 2 else 80
|
||||
wb = openpyxl.load_workbook(path)
|
||||
print(f"FILE: {path}\nSHEETS: {wb.sheetnames}\n")
|
||||
for ws in wb.worksheets:
|
||||
heights = {r: round(d.height, 1) for r, d in ws.row_dimensions.items() if d.height}
|
||||
flagged = []
|
||||
for row in ws.iter_rows():
|
||||
for cell in row:
|
||||
if cell.value and isinstance(cell.value, str) and len(cell.value) > threshold:
|
||||
tw, mrange = merged_info(ws, cell.coordinate)
|
||||
fsz = cell.font.sz or 11
|
||||
vr, sug = estimate_height(cell.value, tw, fsz)
|
||||
cur = heights.get(cell.row)
|
||||
short = cur is not None and cur < sug
|
||||
flagged.append((cell.coordinate, mrange, len(cell.value),
|
||||
cell.value.count(chr(10)) + 1, round(tw, 1), vr, sug, cur, short))
|
||||
if not flagged:
|
||||
continue
|
||||
print(f"===== {ws.title} (max_row={ws.max_row}) =====")
|
||||
for co, mr, ln, ll, tw, vr, sug, cur, short in flagged:
|
||||
mark = " ⚠️可能截断" if short else ""
|
||||
print(f" {co} merge={mr} chars={ln} lines={ll} w={tw} "
|
||||
f"=> est_rows={vr} SUGGEST={sug}pt current={cur}{mark}")
|
||||
print()
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
@@ -0,0 +1,79 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="zh-CN">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>流程图模板</title>
|
||||
<style>
|
||||
* { margin:0; padding:0; box-sizing:border-box; }
|
||||
body { font-family:"Microsoft YaHei","PingFang SC","WenQuanYi Zen Hei","Droid Sans Fallback",sans-serif;
|
||||
background:#f4f6f8; color:#1a1a1a; padding:16px; line-height:1.5; }
|
||||
h1 { font-size:20px; text-align:center; margin-bottom:4px; color:#1a2b3c; }
|
||||
.sub { text-align:center; font-size:12px; color:#667; margin-bottom:20px; }
|
||||
.legend { display:flex; flex-wrap:wrap; justify-content:center; gap:8px; margin-bottom:18px; font-size:12px; }
|
||||
.lg { display:inline-flex; align-items:center; gap:5px; padding:3px 9px; border-radius:6px; border:1.5px solid; }
|
||||
.fig { background:#fff; border-radius:12px; padding:20px 14px; margin-bottom:26px; box-shadow:0 2px 10px rgba(0,0,0,.06); }
|
||||
.fig h2 { font-size:16px; color:#1a2b3c; margin-bottom:4px; padding-left:6px; border-left:4px solid #2E6DA4; }
|
||||
.fig .desc { font-size:12px; color:#778; margin:6px 0 16px 10px; }
|
||||
.row { display:flex; justify-content:center; align-items:stretch; gap:14px; flex-wrap:wrap; }
|
||||
.node { border-radius:10px; padding:10px 12px; border:2px solid; font-size:13px; text-align:center;
|
||||
min-width:130px; display:flex; flex-direction:column; justify-content:center; }
|
||||
.node b { display:block; font-size:13.5px; margin-bottom:3px; }
|
||||
.node small { font-size:11.5px; color:#3a3a3a; line-height:1.45; }
|
||||
/* 语义配色：蓝=主审/人 绿=自动/subagent 灰=系统 金=交付 橙=决策 红=回流/铁律 */
|
||||
.me{background:#BBD9F0;border-color:#2E6DA4;} .agent{background:#C6E5C6;border-color:#3C8C3C;}
|
||||
.gray{background:#ECEFF1;border-color:#90A4AE;} .dec{background:#FCE4B0;border-color:#E0922F;}
|
||||
.rework{background:#F5C6C6;border-color:#C0392B;} .gold{background:#F5E6A8;border-color:#C9A227;}
|
||||
.lgold{background:#FBF3D5;border-color:#C9A227;}
|
||||
.arrow { text-align:center; color:#37474F; font-size:18px; margin:7px 0; font-weight:bold; }
|
||||
.arrow small { font-size:11px; display:block; color:#555; }
|
||||
.full { width:100%; } .dashed { border-style:dashed; }
|
||||
.note { font-size:11.5px; color:#555; font-style:italic; text-align:center; margin-top:10px; }
|
||||
.col { display:flex; flex-direction:column; gap:7px; align-items:center; flex:1; min-width:170px; }
|
||||
.col .arrow { margin:2px 0; font-size:15px; }
|
||||
.branches { display:flex; gap:12px; align-items:flex-start; }
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<!-- 用法：div+border 画节点、↓/→ 字符画箭头。中文走系统字体，零豆腐块风险。
|
||||
节点 class 选语义色：me/agent/gray/dec/rework/gold。
|
||||
单列流程用 .row + .arrow 交替；并行分支用 .branches>.col。 -->
|
||||
<h1>标题</h1>
|
||||
<div class="sub">副标题 / 制作人 / 日期</div>
|
||||
<div class="legend">
|
||||
<span class="lg me">🔵 人/主审</span>
|
||||
<span class="lg agent">🟢 自动/subagent</span>
|
||||
<span class="lg gray">⬜ 系统/流转</span>
|
||||
<span class="lg dec">🔶 决策</span>
|
||||
<span class="lg gold">🟡 交付</span>
|
||||
</div>
|
||||
|
||||
<div class="fig">
|
||||
<h2>图1 · 单列流程示例</h2>
|
||||
<div class="desc">说明文字</div>
|
||||
<div class="row"><div class="node gray full"><b>起点</b></div></div>
|
||||
<div class="arrow">↓</div>
|
||||
<div class="row">
|
||||
<div class="node me"><b>节点A</b><small>子说明</small></div>
|
||||
<div class="node agent"><b>节点B</b><small>子说明</small></div>
|
||||
</div>
|
||||
<div class="arrow">↓<small>条件标签</small></div>
|
||||
<div class="row"><div class="node gold full"><b>终点/交付</b></div></div>
|
||||
<div class="note">脚注</div>
|
||||
</div>
|
||||
|
||||
<div class="fig">
|
||||
<h2>图2 · 并行分支示例</h2>
|
||||
<div class="branches">
|
||||
<div class="col">
|
||||
<div class="node agent full"><b>分支1</b></div>
|
||||
<div class="arrow">↓</div><div class="node gray full">步骤</div>
|
||||
</div>
|
||||
<div class="col">
|
||||
<div class="node dec full"><b>分支2</b></div>
|
||||
<div class="arrow">↓</div><div class="node gray full">步骤</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,175 @@
|
||||
# -*- coding: utf-8 -*-
|
||||
"""
|
||||
单校区梳理表生成器模板 / Single-Campus Review Table Builder
|
||||
==========================================================
|
||||
照抄改值即可，别每个校区从头裸写 openpyxl（Pitfall 18：禁止裸做）。
|
||||
2026-06-26 八个校区验证通过。
|
||||
|
||||
改这些就够了（搜 TODO）：
|
||||
· ws.title / 大标题 / 项目信息行(r2)
|
||||
· r5 租赁数据行的 D5..L5、r8 物业数据行的 D8..L8（如无物业合同则跳过r6-r8）
|
||||
· 整体段（如无物业则整体段在r6-r7）
|
||||
· 输出路径 out
|
||||
|
||||
🔴 地基四铁律（开工前必默念）：
|
||||
1.逐字逐句 2.整体理解 3.上下文联系 4.逻辑分析
|
||||
OCR乱码→vision核实，不准猜值；地址不一致→搜注册地址；租金跳变→做算术。
|
||||
|
||||
铁律内化点（已固化进结构，别违反）：
|
||||
① 12列：K=法律风险 / L=模版差异。建表后必跑 kl-separation-check.py。
|
||||
② 列宽以人民中路定稿为唯一基准。
|
||||
③ H列四检（交付前必过）：条款号/月租换算/付款推算/❗标注。
|
||||
④ K列必含「提前退租法律后果分析」段（每校区必做）。
|
||||
④b K列禁用"模版"一词（含"制式模版"等复合形式）→改用"制式合同""制式文本"。
|
||||
kl-separation-check.py 的 regex 无法区分语境，一律触发。龙信0703已验证。
|
||||
⑤ 纯文本❗做标记，不用富文本红字。
|
||||
⑥ 末尾必有「整体风险分析与建议」段。
|
||||
⑦ 列归类规则（详见 references/column-allocation-rules.md）：
|
||||
· H列只放纯费用，违约金归I列（核心内容）
|
||||
· K列聚焦风险，"对乙方有利条款"放整体段续签建议="建议保留"
|
||||
· K列退租分析：有约定写约定，无约定写法律规定，禁无锚点推测
|
||||
⑧ 多租赁物时按租赁物分板块（非按合同类型），每板块内租赁前物业后。
|
||||
详见 references/column-rules-0701.md「多租赁物表结构」。
|
||||
模板脚本需手动调整板块结构（段标题=租赁物描述，非合同类型）。
|
||||
"""
|
||||
import os, sys
|
||||
# ---- 事前拦截：物理依赖链检查 ----
|
||||
# 建表前必须确认OCR已补全 + 模版比对已完成，否则脚本直接中止
|
||||
WORKDIR = os.environ.get('CAMPUS_WORKDIR', '')
|
||||
if WORKDIR:
|
||||
_checkpoints = {
|
||||
'step1.verified': 'OCR完整性未通过（先运行 ocr-integrity-check.py）',
|
||||
'step2b.verified': '模版比对未完成（先 delegate subagent 做动作B，再运行 template-diff-verify.py）',
|
||||
}
|
||||
for ckpt, msg in _checkpoints.items():
|
||||
path = os.path.join(WORKDIR, ckpt)
|
||||
if not os.path.exists(path):
|
||||
print(f"⛔ 建表中止：{msg}")
|
||||
print(f" 缺少checkpoint: {path}")
|
||||
sys.exit(1)
|
||||
print(f"✅ 事前拦截通过：{WORKDIR} 的OCR和模版比对checkpoint均存在")
|
||||
# 如果未设CAMPUS_WORKDIR则跳过检查（向后兼容），但delivery-gate事后仍会拦
|
||||
|
||||
import openpyxl
|
||||
from openpyxl.styles import Font, PatternFill, Alignment, Border, Side
|
||||
|
||||
# ---- 样式常量（人民中路定稿基准：酒红主色 + 微软雅黑10）----
|
||||
F = Font(name='微软雅黑', size=10)
|
||||
FB = Font(name='微软雅黑', size=10, bold=True)
|
||||
TITLE = Font(name='微软雅黑', size=14, bold=True, color='FFFFFFFF')
|
||||
SUB = Font(name='微软雅黑', size=10, bold=True, color='FF404040')
|
||||
SEC = Font(name='微软雅黑', size=11, bold=True, color='FFFFFFFF')
|
||||
fill_title = PatternFill(start_color='FF8B1A2B', fill_type='solid')
|
||||
fill_sec = PatternFill(start_color='FFC0504D', fill_type='solid')
|
||||
fill_hdr = PatternFill(start_color='FFE2EFDA', fill_type='solid')
|
||||
fill_sub = PatternFill(start_color='FFF2F2F2', fill_type='solid')
|
||||
thin = Side(style='thin')
|
||||
border = Border(left=thin, right=thin, top=thin, bottom=thin)
|
||||
AL = Alignment(horizontal='left', vertical='top', wrap_text=True)
|
||||
AC = Alignment(horizontal='center', vertical='center', wrap_text=True)
|
||||
|
||||
wb = openpyxl.Workbook()
|
||||
ws = wb.active
|
||||
ws.title = '校区名' # TODO
|
||||
|
||||
widths = dict(A=5, B=20, C=17, D=27, E=23, F=9, G=21, H=36.33, I=34, J=8, K=50, L=35)
|
||||
for c, w in widths.items():
|
||||
ws.column_dimensions[c].width = w
|
||||
|
||||
|
||||
def merge_row(r, text, font, fill, h=None, al=AC):
|
||||
ws.merge_cells(f'A{r}:L{r}')
|
||||
cell = ws.cell(r, 1, text)
|
||||
cell.font = font
|
||||
cell.fill = fill
|
||||
cell.alignment = al
|
||||
for col in range(1, 13):
|
||||
ws.cell(r, col).fill = fill
|
||||
ws.cell(r, col).border = border
|
||||
if h:
|
||||
ws.row_dimensions[r].height = h
|
||||
|
||||
|
||||
# ---- r1 大标题 ----
|
||||
merge_row(1, '校区名 — 租赁合同梳理', TITLE, fill_title, 30) # TODO
|
||||
|
||||
# ---- r2 项目信息 ----
|
||||
proj = ('物业项目：……\n'
|
||||
'出租方（租赁甲方）：…… | 物业方（物业乙方）：……\n'
|
||||
'承租方（乙方）：……') # TODO
|
||||
merge_row(2, proj, SUB, fill_sub, 76, AL)
|
||||
|
||||
# ---- r3 板块一 ----
|
||||
merge_row(3, '一、房屋租赁合同', SEC, fill_sec, 22,
|
||||
Alignment(horizontal='left', vertical='center', wrap_text=True))
|
||||
|
||||
HDR = ['序号', '文件名称', '合同类型', '合同当事人', '租赁标的/服务范围', '面积(㎡)',
|
||||
'合同期限', '金额/费用', '核心内容', '当前状态',
|
||||
'法律风险（站乙方立场）', '与07标准模版差异']
|
||||
for ci, h in enumerate(HDR, 1):
|
||||
c = ws.cell(4, ci, h)
|
||||
c.font = FB
|
||||
c.fill = fill_hdr
|
||||
c.alignment = AC
|
||||
c.border = border
|
||||
ws.row_dimensions[4].height = 30
|
||||
|
||||
# ---- r5 租赁数据行 ----
|
||||
# TODO 填 D5..L5。
|
||||
# H列四检：①条款号 ②月租换算(≈X个月) ③付款推算(各期具体日期) ④❗标注(未付期次)
|
||||
# H5 只放纯费用（租金/物业费/保证金/水电费标准），违约金归I列
|
||||
# 🔴 I5 租赁合同必检21类目（有就写没有不写，直接摘原文，格式=· [类目] 原文（条款号））：
|
||||
# 用途/转租/装修改造/广告标识/非竞争/维修责任/保险要求/物业服务联动/配套设施/
|
||||
# 出租方变更/解除权机制/违约金机制/不可抗力/征收拆迁/房屋抵押查封/政策变化/
|
||||
# 到期处理/恢复原状/优先权/管辖/备案
|
||||
# 🔴 I列物业合同必检15类目：
|
||||
# 物业服务内容/服务标准/公共能耗费/特约服务/共用设施管理/装修管理/安保措施/
|
||||
# 消防安全/保险要求/联动终止/违约责任/退出交接/免责条款/不可抗力/管辖
|
||||
# K5 独立审查：从"本合同第X条这样约定→对乙方什么后果"起笔
|
||||
# K5 必含：需注意风险点 + 提前退租法律后果(有约定写约定,无约定写法律规定,禁推测)
|
||||
# K5 禁放"对乙方有利条款" → 移到整体段续签建议="建议保留"
|
||||
# L5 纯客观：只摆文本差异事实，禁止"风险/建议/不利/详见"
|
||||
row5 = ['1', '租赁合同.pdf', '房屋租赁合同', 'D5…', 'E5…', '面积', 'G5…', 'H5…', 'I5…', '履行中', 'K5…', 'L5…']
|
||||
for ci, v in enumerate(row5, 1):
|
||||
c = ws.cell(5, ci, v)
|
||||
c.font = F
|
||||
c.alignment = (AC if ci in (1, 3, 6, 10) else AL)
|
||||
c.border = border
|
||||
ws.row_dimensions[5].height = 409.5
|
||||
|
||||
# ---- r6-r8 物业板块（如无物业合同则跳过，整体段改为r6-r7）----
|
||||
merge_row(6, '二、物业管理服务合同', SEC, fill_sec, 22,
|
||||
Alignment(horizontal='left', vertical='center', wrap_text=True))
|
||||
for ci, h in enumerate(HDR, 1):
|
||||
c = ws.cell(7, ci, h)
|
||||
c.font = FB
|
||||
c.fill = fill_hdr
|
||||
c.alignment = AC
|
||||
c.border = border
|
||||
ws.row_dimensions[7].height = 30
|
||||
# TODO 填 D8..L8。物业合同新东方常为甲方,与租赁当事人方向相反,D8加注。
|
||||
row8 = ['2', '物业合同.pdf', '物业管理服务合同', 'D8…', 'E8…', '面积', 'G8…', 'H8…', 'I8…', '履行中', 'K8…',
|
||||
'物业服务协议，无对应07标准模版。']
|
||||
for ci, v in enumerate(row8, 1):
|
||||
c = ws.cell(8, ci, v)
|
||||
c.font = F
|
||||
c.alignment = (AC if ci in (1, 3, 6, 10) else AL)
|
||||
c.border = border
|
||||
ws.row_dimensions[8].height = 200
|
||||
|
||||
# ---- r9-r10 整体风险分析与建议（必含板块）----
|
||||
merge_row(9, '三、校区整体风险分析与建议', SEC, fill_sec, 22,
|
||||
Alignment(horizontal='left', vertical='center', wrap_text=True))
|
||||
# TODO 结构：【整体评价】→【需客户核实】→【提前退租法律后果】→【其他关注点】→【有利条款】→【续签建议】
|
||||
overall = '【整体评价】\n……' # TODO
|
||||
merge_row(10, overall, F, PatternFill(start_color='FFFFFFFF', fill_type='solid'), 350, AL)
|
||||
ws.cell(10, 1).font = F
|
||||
|
||||
ws.freeze_panes = 'A5'
|
||||
out = '/tmp/<校区>/校区名-梳理-MJ-YYYYMMDD.xlsx' # TODO
|
||||
wb.save(out)
|
||||
print('saved', out)
|
||||
# 建表后必做：1) python3 scripts/kl-separation-check.py <out> 验K/L分工
|
||||
# 2) python3 scripts/i-column-coverage-check.py <out> 验I列类目覆盖（详见 references/i-column-standard-0703.md）
|
||||
# 3) H列四检逐项过
|
||||
# 4) x2t渲染PDF + pdftotext拍平grep验文字 + vision验视觉
|
||||
+114
@@ -0,0 +1,114 @@
|
||||
# 模版比对报告——{校区名}租赁合同
|
||||
|
||||
**合同名称：** {合同标题}
|
||||
**甲方：** {出租方名称}
|
||||
**乙方：** {承租方名称}
|
||||
**房屋坐落：** {地址}
|
||||
**建筑面积：** {面积}
|
||||
**租赁期限：** {起止日期}
|
||||
**比对模版：** 07-房屋租赁合同.docx（南通新东方参考模版）
|
||||
|
||||
---
|
||||
|
||||
## 一、关键要素提取
|
||||
|
||||
| 要素 | 本合同内容 |
|
||||
|------|-----------|
|
||||
| 合同标题 | {标题} |
|
||||
| 甲方 | {名称} |
|
||||
| 乙方 | {名称} |
|
||||
| 甲方住所 | {地址} |
|
||||
| 联系电话 | {电话} |
|
||||
| 房屋地址 | {地址} |
|
||||
| 房屋结构 | {结构} |
|
||||
| 建筑面积 | {面积} |
|
||||
| 用途 | {用途} |
|
||||
| 租赁期限 | {期限} |
|
||||
| 免租期 | {免租期及起止日期} |
|
||||
| 各期租金 | {逐期列示金额及期间} |
|
||||
| 发票类型 | {发票类型} |
|
||||
| 付款条件 | {付款触发条件及期限} |
|
||||
| 租金支付周期 | {支付频率及截止日} |
|
||||
| 履约保证金 | {金额} |
|
||||
| 保证金退还 | {退还条件及期限} |
|
||||
| 违约金标准 | {比例/金额} |
|
||||
| 逾期利息 | {利率/费率} |
|
||||
| 管辖法院 | {法院} |
|
||||
| 合同份数 | {份数} |
|
||||
|
||||
---
|
||||
|
||||
## 二、逐条差异比对（≥20条）
|
||||
|
||||
### 第1条：{差异主题}
|
||||
|
||||
- **模版表述为**【{模版原文摘录}】
|
||||
- **本合同表述为**【{本合同原文摘录}】
|
||||
|
||||
### 第2条：{差异主题}
|
||||
|
||||
- **模版表述为**【{模版原文摘录}】
|
||||
- **本合同表述为**【{本合同原文摘录}】
|
||||
|
||||
...（逐条列示，每条差异写明主题、模版原文、本合同原文）
|
||||
|
||||
---
|
||||
|
||||
## 三、补充差异（模版有、本合同无的条款）
|
||||
|
||||
| 序号 | 模版条款 | 说明 |
|
||||
|------|---------|------|
|
||||
| 1 | {条款号+标题} | {简要说明该条款内容} |
|
||||
| 2 | ... | ... |
|
||||
|
||||
---
|
||||
|
||||
## 四、退租敞口测算
|
||||
|
||||
### 1. 乙方主动提前退租
|
||||
|
||||
**适用条款：第X条**
|
||||
> "{原文摘录}"
|
||||
|
||||
| 退租时点 | 违约金金额 | 计算方式 |
|
||||
|---------|-----------|---------|
|
||||
| 第1-N期 | ¥{金额} | {计算过程} |
|
||||
|
||||
### 2. 甲方违约导致乙方退租
|
||||
|
||||
**适用条款：第X条**
|
||||
> "{原文摘录}"
|
||||
|
||||
| 退租时点 | 甲方应付违约金 | 另需退还 |
|
||||
|---------|-------------|---------|
|
||||
| 第1-N期 | ¥{金额} | {退还项目} |
|
||||
|
||||
### 3. 因不可抗力/政策原因退租
|
||||
|
||||
**适用条款：第X条**
|
||||
> "{原文摘录}"
|
||||
|
||||
敞口 = {金额或说明}
|
||||
|
||||
### 4. 因拆迁/房屋毁损
|
||||
|
||||
**适用条款：第X条**
|
||||
> "{原文摘录}"
|
||||
|
||||
敞口 = {金额或说明}
|
||||
|
||||
### 5. 退租敞口汇总
|
||||
|
||||
| 退租情形 | 乙方最大损失 | 乙方最大获赔 |
|
||||
|---------|-----------|-----------|
|
||||
| 乙方主动退租 | ¥{金额} | — |
|
||||
| 甲方违约 | — | ¥{金额}+{退还项目} |
|
||||
| 不可抗力/政策 | ¥{金额} | ¥{金额} |
|
||||
| 拆迁/房屋毁损 | ¥{金额} | {补偿说明} |
|
||||
|
||||
---
|
||||
|
||||
*报告生成日期：{日期}*
|
||||
*比对方法：逐条打开07模版原件与OCR文本逐项比对*
|
||||
*OCR质量验证：所有金额/费率已做数学交叉验证；乱码段落已vision核实*
|
||||
*本报告中性客观，仅列出差异，不含风险判断*
|
||||
Reference in New Issue
Block a user