募集说明书 · 全文交叉复核

> 知识产权声明：本技能及相关文档、脚本代码的著作权归 投行小机灵 所有。
>
> 使用许可：✅ 允许个人学习、研究、非商业用途使用；✅ 允许修改后个人使用；❌ 禁止直接复制核心算法用于商业产品或竞争性服务；❌ 禁止移除或修改作者署名后重新分发；❌ 禁止将本技能包装成独立产品对外销售。
>
> 免责声明：本技能提供的分析结果、计算口径与处理建议仅供参考，不构成投资建议或专业法律/审计意见。使用者应自行结合原始文件判断并承担相应风险。

0. 铁律

1. 执行流程

三层分工：机器保证不漏，人保证判准。 不要一上来就通读 docx，先跑 §1.1～§1.3。

> 凡规则能判定的，一律不进第三层。 §2 人工清单里"靠注意力过"的检查项已尽量下沉到第一层——

> 编号类候选的核实口径（2026-09-18 示例案两条误报的流程教训）：编号字符可能来自
> Word 自动编号（numPr + numbering.xml），渲染引擎生成、不写入 w:t 文本层——
> dump/字面文本里"没有编号"≠ 文档里没有编号。第三层核实编号类候选时必须查渲染层：
> 看 dump 行内 |自= 标注，或解包 docx 查该段 w:pPr/w:numPr 与 numbering.xml 的
> start/numFmt。只对 dump 文本 grep 就确认编号缺陷 = 用被告的证据审被告
> （核实手段与扫描器共享同一文本层盲区，两层同盲必出假阳性）。
> 市场用户调用时必须产出逐次一致的结果，不能依赖模型当次注意力（会漏、会幻觉）。
> 下沉的判据、实测数据、已知边界见 §1.2；仍留在第三层的只有"定性、口径辨析、语义对撞"。

1.0 报告期口径路由（动手前先问）

第 16 类判定、以及"某主体报告期未更新到目标口径"的批注，都以用户选定的报告期口径为基准。
不问就判 → 要么整片误报，要么漏报。财务报告期与业务报告期可以不一致，必须分开问。

用一次 AskUserQuestion 同时问两项：

口径 ↔ 期末对照（"及一期"即最新一期，通常为半年报）：

• 期末以用户确认为准；脚本会把"文档内出现的最新期间"回显在报告头部，二者不一致时以用户口径为准。
• 业务口径允许就是"近三年"（如新签合同额、账龄分布等运营数据）——所以不能用"是否到最新一期"一刀切。

确认后把两个口径传进去：

python <本技能>/scripts/scan_docx.py "<源docx>" "<输出md>" --fin 2026-06 --biz 2025-12

> 未传参时脚本按文档自动推断，并在报告头部标注「未传参」——那是占位值，不是复核结论。

1.1 抽取 + 前置检测

python <本技能>/scripts/dump_docx.py "<源docx路径>"
# → <同目录>/_dump/doc_linear.txt   段落线性文本，[P#####|样式] 索引
# → <同目录>/_dump/tables.txt       T1..Tn 全部表格
# → <同目录>/_dump/textboxes.txt    **文本框文字**（`Paragraph.text` 读不到，须一并复核）

先看输出的三项前置检查：

环境：用已安装 python-docx 的解释器（如虚拟环境的 <venv>/Scripts/python.exe）；同一发行版的裸解释器通常没有该库，会报 ModuleNotFoundError。

定位约定（报告与批注锚点共用）：P##### = 第 N 段（含标题与空段，从 0 起）；T## = 第 N 张表；§ = 章节号。

1.2 机械扫描（27 类候选）

python <本技能>/scripts/scan_docx.py "<源docx路径>" "<输出md>"
# 第 27 类（正文单点数值 vs 表数值）需 per-project 主体简称，缺省不运行：
python <本技能>/scripts/scan_docx.py "<源docx>" "<输出md>" --aliases <aliases.json>

①角色名一致性 ②数字格式异常 ③编号跳号 ③b编号重号 ④日期分布 ⑤术语对撞 ⑥业务要素枚举 ⑦占位符残留 ⑧重复字眼 ⑨编号标点畸形 ⑩关键日期角色 ⑩b日期角色序 ⑪现金流期间衔接 ⑫跨表同指标对撞 ⑬编号父级回退 ⑭残句 ⑮形近主体名 ⑯报告期口径一致性 ⑰金额↔占比自洽 ⑱叙事↔表单位 ⑲期间新鲜度 ⑳声明计数vs表行数 ㉑期间报表时点化 ㉒空白编号标题 ㉓绝对量词+占比值 ㉔跨段整句重复 ㉕表内%标记不统一 ㉖正文序列vs表行数值 ㉗正文单点vs表数值。

> ③跳号=值缺、③b重号=值重、⑬父级回退=层级回退——三个编号维度正交，都须查（不可只查其一）。三判据为何正交、"为什么必须机械化"的论证见 references/27类判据-逐类案例与误报根因.md（质疑或改判据时才读）。

逐节怎么读：

> 每类的历史案例、误报根因、设计权衡见 references/27类判据-逐类案例与误报根因.md（质疑或改判据时才读）。

> 扫描器不下结论，只报候选 + 证据位置；判据与语义对撞由第三层做。
> 性能铁律：取段落样式必须用 fast_style_reader()，不可用 p.style.name——后者对无显式样式的段落会全量扫描样式表（本文档 2,459 段实测 57 秒）。改前 110s → 改后 12.7s，产物逐字节一致。

1.3 表内勾稽自动复算

python <本技能>/scripts/check_tables.py "<源docx路径>" "<输出md>"

逐表逐列三类复算：

判定分级与处置：

容差：金额 0.05+0.005n、占比 0.05+0.01n（n=项数）；尾差单列一节，不计入问题（示例项目 53 处，全为 ±0.01 级）。尾差 清单的用途 = 给业务端一个"哪些是四舍五入正常差异"的底数。

归责边界（报告措辞勿越界）：

• 加和：归责无歧义——表值即合计行。
• 净额／减退：报组内不平、不指认错在哪一行（流入/流出/净额任改一个都能配平）。定位须靠另一条独立勾稽反证——示例项目 T39 用"三项活动净额之和 = 底行现金及现金等价物净增加额"排除净额、锁定错在流出小计。工具只报组，归责与定位依据须写进报告。

自证：原文件 FAIL 须逐项为真（示例项目 1 项 = 已知硬伤 T39，零误报）；并做注入错误测试（改 N 个单元格破坏勾稽 → 重跑查 N/N 命中，示例项目 10/10）。

> 五条误报根因、双向自证实测数据、工程铁律、归责链范例见 references/表内勾稽复算-设计与误报治理.md——改脚本或质疑某条判定时才读。

2. 人工排查八类清单（逐类过，不要只挑眼熟的）

> 先看这张分工表——已经下沉到第一层的，不要再靠注意力重做（重做既慢又不可复现）。
> 下沉判据与实测数据见 §1.2；本节的剩余价值是语义级判断（定性、口径辨析、语义对撞）。

类 1 · 参与机构与角色（最高频硬伤）

同一角色在不同章节写成不同主体。逐个角色拉全链条：
释义 → §1 交易结构 → §2 专项计划概况（2.x）→ §3 参与方基本信息（3.1.x）→ §5 主体简介（5.x）→ §8 费用 → §11 销售方案 → §13 信息披露。

高发角色：托管银行、监管银行、销售/推广机构、初始债权人之代理人、资产服务机构、评级机构、登记托管机构。

必查：小节标题写"监管银行"而正文写"托管人/托管业务/托管行"——同节内角色混用，通常是复制上一节未替换主体。

类 2 · 关键日期与时点

• 设立日/缴款截止日/基准日（封池日）/交割日/签署页日期 → 须排出唯一时间线；任一处早于基准日或晚于签署页即硬伤。能机检的部分已下沉（§1.2 第 10 类报「同角色多日期」）；时间线序关系（谁早于谁）仍须人工排。
• 现金流预测假设中的日期（设立日、分配基准日、兑付日、回款日）须与释义、正文条款逐项对齐。
• 分配基准日、兑付日、回收款转付日的月份是否与现金流预测表各期"回收款收款期间"兼容。
• 报告期口径：检索"截至20XX年末/末"是否与报告期末一致（常见错：报告期 6 月末却写"年末"）。

类 3 · 交易条款前后一致

逐条对撞下列成对条款（前后各一处，逐字比）：

类 4 · 风险揭示维度

• 重要提示风险项列表 vs 第十章 10.1.x 列表 → 逐项做映射表，找只在一边出现的项。
• 章名引用一致性（重要提示引"风险提示与防范措施" vs 正文标题"风险揭示与防范措施"）。
• 内容与标题错配：正文讲资产负债率/有息负债，标题却是"基础资产的现金流预测风险"——极常见。
• 合格标准/法律意见（"债务人与…之间无诉讼"）vs 风险揭示（"存在一户债务人涉诉金额较大"）→ 口径范围不同，须衔接说明。

类 5 · 财务与业务数据勾稽

• 正文数字 vs 表格：逐组回表核对（占比、金额、单位）。高发：把"金额 X 亿元"误当"占比 X%"；正文与表内不符（形近复制）；单位漏"万"（差 1 万倍）。
• 表内：分项加和 = 合计？占比合计 = 100%？先扣已披露尾差再判（机检口径见 §1.3）。
• 同一指标跨表：主表 vs 摘要表（量级性差异是笔误不是尾差——如示例项目 T39 的 100 亿元级）。
• 数字格式：千分位误作小数点（234.567.89）、多余小数位（5,678.901）、双百分号（63.21%%）。
• 环比/同比文字 vs 表值：同句内用列示绝对额反算降幅，不一致即硬伤。
• 口径词：称"余额"却用"账面价值"，而同说明书另有"账面余额"行。
• 有息负债/存续证券规模等"结论支撑数"：正文一处 vs 明细表合计，差一个量级即硬伤。

类 6 · 现金流预测表（ABS/REITs 必查）

• 各期"回收款收款期间"须单调递增、首尾相接：第 n+1 期起算日 = 第 n 期止算日。1 张错，其余通常沿用同一错误 → 必须批量核、批量改。已机械化（§1.2 第 11 类，逐表全查）。
• 各期之和 = 合计；"支付优先级本金"合计 = 优先级发行规模。
• 覆盖率（静态/各压力情景）表值 vs 正文注释逐项对。
• 压力情景假设表（利率/逾期率/违约损失率）：空白用"\"表示不适用 vs 正文写 0.00% → 口径不一致，建议统一。

类 7 · 编号、术语、文字重复、残句

• 编号跳号：阿拉伯 10.1.15 → 10.1.17（缺 10.1.16）、7.3.2 → 7.3.4、（15）→（17）。见 §1.2 第 3 类，自动扫出。
• 中文序号缺号须人工确认：机检已按"值回退即重启"过滤回退型跨节重启，但「递增型跨节」与「同节真缺号」形态一致。实测样例报出的 （一）基本资料 → （三）股权结构 经核确为真缺号——中间"历史沿革"小节漏写"（二）"前缀（该小节标题无编号，肉眼易滑过）。
• 编号重号：同一编号出现两次以上（1.5／1.5.1／1.5.2 各两次、§7 的 7.1／7.2／7.3 各两次）——拼接稿未重排的铁证，须在定稿前统一重编。见 §1.2 第 3b 类，自动扫出。与跳号是两个正交维度（跳号＝值缺、重号＝值重），不可只查其一。
• 章节号错位：§5.5 项下出现 5.4.4；同节后文已是 5.5.5。已机械化（§1.2 第 13 类「编号父级回退」）。
• 多余标点：8.2..3。已机械化（§1.2 第 9 类「编号标点畸形」）。
• 残句（缺谓语）：「截至20XX年6月末，示例集团重大诉讼、仲裁事项等情况。」——通常是漏掉原应写入的结论。已机械化（§1.2 第 14 类）。
• 错别字：主体名（"示列集团"）、期次（"示例应收账款2期"）、语义错字（"向本集团增值2000万"应为"增资"）。主体名已机械化（§1.2 第 15 类「形近主体名」）；期次错字仍须人工（无「高频正名」可依）；语义错字仍须人工——增值/增资类已探明频次/形近/切词三路不可行、唯一可行判据（全文孤例+行内事项列对仗）泛化须配易混词对词表、收益递减，决策留人工（2026-09-18，示例 T27 案）。机器能力边界：错别字造成局部不收敛（同表/同槽位其余正确）可机械判；全文一致地错/孤立自洽无锚点则连检查都检查不出来（信息论边界）。
• 列表完整性：董监高表载 5 名董事、正文"董事简历"只列 2 人 → grep 确认其余姓名全文 0 命中，方可判缺漏。
• 文字重复（叠字/整句）：见 §1.2 第 8 类自动扫出（示例项目 3/3 全真、零误报）；2 字叠字不在机检范围，通读留意。

类 8 · 业务要素枚举 vs 本期实际构成（最易漏，实测漏检后补充）

凡描述性文本枚举业务要素（款项类型、交易类型、资产类型、所处阶段），须与本期结构化事实表对撞：枚举集合 ⊆ 本期实际集合。

三步：①抽"本期事实集合"（款项类型分布表、行业/区域分布表、企业性质表、基础资产清单、项目完工情况表）；②全文检索要素词 贸易款|货款|服务费|质保金|质量保证金|工程款|货物贸易|贸易服务|服务提供，逐处判"定义性"还是"描述性"；③描述性文本中的要素若不在本期事实表 → 列为问题。

判据（避免误伤）：

• 定义性/条件性表述（§1.5 释义各条、"基础合同"定义、合格标准各款）→ 列举"可能情形"，涵盖宽于本期可以接受，不列。如合格标准 (t)"属于质保金的应收账款占比不超过 5%"是门槛条款（允许入池、设上限），≠ 本期实际存在质保金；"货物贸易和服务提供的合同性文件或施工承包/分包的合同性文件"属"或"式涵盖。
• 描述性/揭示性表述（重要提示、第十章风险揭示、§6.1.x"本期基础资产…"特征描述、"本期/本专项计划"现状陈述）→ 必须据实，枚举本期不存在的要素即为问题。

典型命中（实测）：

易漏原因：不是"两处数值不一致"（可机械 grep），而是"文本枚举 ⊄ 事实集合"——须先把事实集合从表里抽出来再比；错处成族出现（同一模板段复制到重要提示 + 第十章），发现一处必须全族扫。

3. 交付 A：复核报告

报告给人读。文件名 <项目名>_全文交叉复核报告.md，H1 标题 《文件名》全文交叉复核报告，结构固定：

条目写法：每条必须给出两处（或多处）定位 + 原文摘录 + 矛盾点 + 建议修正方向；🔴 段宜用对照表（位置｜原文）。

附表 A：复算明细（必须留痕）

• 关键数字用两种独立路径复算（"分项加和"与"小计−净额"双验），单一路径可能被同一个错误掩盖。
• 只写加和与结论；判"✓ 无矛盾"的项也要列出——这是"确实核过"的证据，也防止下轮重复劳动。

其它：一句话结论要敢下判断（如"该版本是多来源拼接稿，存在 N 套互相冲突的机构版本，属不能对外报送状态"）；修订顺序按对报送的影响排：机构与角色 → 关键日期 → 交易结构表述 → 数据 → 编号文字；交付物极简——不写方法论自夸、不重复已列内容、不写"给程序员看的元信息"。

3.1 发现归因表（强制项，交付报告必须含）

报告 §7（三态自证）必须附一张发现归因表，逐条标注每条发现的来源层级，并给出脚本覆盖率：

报告必须显式写出：三条各自的条数 + 脚本覆盖率 = 第一层直判 ÷ 总发现条数。
覆盖率 < 50% 时，报告一句话结论旁必须注明「本篇以人工定性为主，结论依赖复核人判断、跨模型不可复现」。
目的（2026-09-18 示例案教训）：报告写"机械扫描 + 自动复算"会让读者误以为结论都是脚本产出的；
实测该案 32 条批注中仅 6 条（19%）是脚本直判、21 条（66%）是纯人工——不标归因就是"宣称口径 > 实际完成度"。
每次交付后应据此表评估"哪些纯人工发现可下沉为脚本判据"，持续收缩第三层（见 §5 下沉纪律）。

4. 交付 B：批注版副本

报告给人读，批注版给人改。进入审核/修改环节一律交批注版：源件另存副本，每条发现以 Word 批注挂在对应文字上。

# 1) 先自校验锚点（必做，有失败/回退不得继续）
py <本技能>/scripts/annotate_docx.py check "<源docx>" anchors.json
# 2) 通过后再生成批注版（脚本内自动跑交付前验证）
py <本技能>/scripts/annotate_docx.py build "<源docx>" anchors.json "<输出docx>"
# 3) 生成批注清单（必须用脚本，勿手写）
py <本技能>/scripts/annotate_docx.py checklist "<源docx>" anchors.json "<输出md>"

anchors.json = 报告条目 → 文档位置的映射（单一数据源）：

{"level":"🔴","label":"🔴-1","kind":"p","hint":733,
 "snippet":"甲银行股份有限公司某分行",
 "comment":"【🔴-1 硬性矛盾｜托管银行主体冲突】\n…\n▸ 建议：…"}

• kind="p" 锚定第 hint 段；kind="t" 锚定第 hint 张表中含 snippet 的单元格；
  kind="pe" 锚定第 hint 个空段落——用于"空白编号标题"这类缺陷：标题只剩 Word 自动编号
  （编号字符只在 numbering 渲染层、不写入 w:t），paragraph.runs == []，用 kind="p" 必 FAIL。
  此时 snippet 写说明而非文本证据，脚本补一个空 run 承载批注区间（段落文本不变）。
  段落非空时报 NOT_EMPTY 并提示改用 kind="p"，不会把批注静默贴到正确文字上。
• 第 16 类（报告期口径）命中一律挂"表标题所在段"（kind="p"，脚本已在报告里给出 P#####），
  snippet 取表标题原文（如"最近三年及一期…利润表"），批注正文写"该表报告期未更新到选定口径（财务 2026-06），请确认"。
  挂表内单元格会锚到数字、审阅者看不出是哪张表。
• hint 直接用报告里的 P#####/T##——报告定位与锚点必须同源，否则等于重新找一遍位置。
• 批注清单按级别列「编号／锚定位置／所挂原文片段／问题」，供逐条勾选，也是"哪条批注挂在哪"的可追溯记录；须与批注同源，手写会与实际落点脱节。

4.1 五条硬约束（各踩过坑）

1. snippet 写"证据本身"，不写引导语。 批注区间由 run 边界决定：写"担任托管银行的"会锚到引导语所在 run，证据（"甲银行股份有限公司某分行"）在下一个 run，高亮区不含证据。snippet 用错误数值／冲突机构名／错别字。
2. check 通过再 build。 FALLBACK（未落在 hint 上）通常是 snippet 命中了更早的同类单元格（典型：现金流预测表第 5 期的 2027-9-1 先命中第 3 期），换更唯一片段（如 2029-3-1（不含该日））。
3. 一处问题多处出现 → 逐处落点，但须同时满足 A、B 两条件，缺一即合并为单条（把另一侧作为证据写进批注正文）：
   - A 落点处各需独立动作（改／核／补）。批注是"待办"，不是"指路牌"——仅作为证据的一侧不落点：如"正文 A 与表 B 冲突"，若表 B 正确、只有正文要改，则只落正文，表 B 写进批注正文即可（落两处＝让审阅者把同一件事读两遍）。
   - B 空间分离——不在一屏之内、不属同一语义连续体。两处合起来才构成问题者不落点（单看任一处均无异常）：如"封包日 vs 设立日间隔 6 个月"（紧邻两段）、"披露时点 A vs B 不一致"。
   - 正例（A+B 双满足）：18 处图表编号重号散落全文（每处都要改）；5 张表同错挂 5 条（首条写完整说明，余者写"同 X"）——只挂一条，审阅者逐张看必漏；同一矛盾的三处各不相同的表述且均须修改（如"实际控制人为省国资委"／"无实际控制人"／"相对控股"）。
   - 同表多格可分别落点：表格审阅是逐格进行的，同一条问题的多个待改格（如某表漏一行 + 两格占比虚增）各自都是独立待办 → 逐格落点。
   - 脚本仅暴露、不裁决（机制化"换模型跑不漏提示"）：annotate_docx.py 的 list_resume_anchors() 列出全部 ↳ 复述型落点（check 输出 [提示] 段、build 打印提示但不阻断）。是否合并仍是人工按判据 A 裁决——因为"各需独立动作"是语义判断，段距、kind、↳ 前缀等机械特征均无法可靠 proxy（实测段距 4 应合并、段距 5 应独立、段距 768 反而同一矛盾，任何固定阈值都过拟合）。故脚本只做零参数的纯结构暴露（label 前缀匹配），不设阈值、不拦截。
4. 批注只写副本，源件不动，交付前逐段比对正文文本须 0 差异。
5. 重打包会重建 [Content_Types].xml：python-docx 丢弃源件中"无部件使用"的 <Default> 声明（实测丢 Extension="JPG"）；zip 内 0 字节目录项（以 / 结尾）不再写入属正常，不算内容丢失（判"部件丢失"前先排除目录项）。脚本已自动补回声明。

4.2 交付前自证（verify() 自动输出，须逐项为真）

真实部件  源=N 副本=N+1 | 源有副本无=无 | 新增=['word/comments.xml']
媒体部件字节一致: True
正文段落 X/X，文本差异 0 处
批注数: N（须 == anchors.json 条数）
commentRange N/N | commentReference N | ref 闭环=True
批注区间交叉/未闭合: 0
XML 良构: 全部通过

> 实测样例（示例项目 ABS）：部件 44→45、正文 2,459 段零差异、72 条批注、区间交叉 0、XML 全良构。
> 副本体积可能小于源件（实测 1.17 MB → 0.96 MB）：重打包统一按 DEFLATE 压缩，判据看"解压后部件字节是否一致"，不看 zip 体积。

4.3 写入纪律（三条都实测踩过）

1. 同一文件的多次编辑不要并行提交（后写覆盖先写，实测"部分修改未落盘、工具却报成功"）。批量改锚点用一次原子补丁 + 断言（替换命中数必须 == 1），或收敛为 anchors.json 单一数据源。
2. 不要用 shell heredoc 给 .py 打"含转义的补丁"：\n／\uXXXX 经"bash → python 字面量 → 写文件"三层解析会失真（实测把 '\n'.join(out) 写成真实换行，破坏源文件）。改用 Write 写补丁脚本再执行，或只替换不含转义的纯文本锚；打完立即 py_compile 校验。
3. 编号与已交付报告对齐后再写锚点：报告已占用的编号（如 🟠-9）须顺延，否则清单与报告编号打架。改 label 时同步改 comment 内引用——用占位符两步替换，避免 -9→-10 后又把新 -10 改成 -11 的链式灾难。

5. 脚本与参考

> 改完必跑：动过任一脚本后，二十三份 selftest_*.py 必须全量重跑且全绿
> （各文件独立运行，退出码 0 = 通过）；只跑被改动那一类不足以证明无回归——
> 三个编号类（跳号／重号／父级回退）共用 group_numbering，改一处会影响另两处。
> 新增模块级名字（常量/函数）前必须先 grep -n "^名字" 全文查重——
> 2026-09-18 实测：第 18 类新增 STOP_CHARS 覆盖了 clean_entity 的同名
> 截断字符集，主体名前缀清洗静默失效，自测全绿（用例没踩前缀路径），
> 直到真实文档 diff 才暴露。查重脚本自身也要防伪绿（awk 取列错误曾使查重失效）。
> 回归口径：语法检查全过 + 二十三份测试全绿 + 真实样本零误报 + 注入自证全中 + 两次运行逐字节一致，五项齐了才算完成。

回归测试（23 份 selftest_*.py）：各自防回退断言与锁死的关键教训见 references/脚本清单-自证细节.md——改脚本或质疑某条判定时才读。

能力边界（只复核，不改数）：①源件含 Word 修订 → 提取结果仅为修订前基线（见 §1.1），须先接受/拒绝全部修订另存副本再复核；②需做报告期更新、数据换期、数值替换等改数操作 → 不在本技能范围内，由使用者先行完成并另存，再对成品做复核。