范本式报告生成（Template Report Writer）
概述
范本式报告生成不是"改改数字"，而是高风险的数据搬运工作。历史报告既是范本也是陷阱：其中每一个数字、每一处时间表述、每一条结论都可能过期。此技能通过"事实层（Fact Layer）单一数据源渲染"机制，将报告生成拆解为：读范本 → 验输入 → 选方案 → 建事实层 → 渲染报告 → 七项自检 → 交付。
铁律（任何情况下不可违反）
- 数字唯一来源：报告中出现的任何数字，只能来自本期数据文件，或来自对本期数据的显式计算（计算必须向用户声明）。禁止把历史报告中的数字当作事实沿用。历史报告的数字慎重使用，且必须能在本期数据或用户提供的口径中追溯到来源。
- 单一事实源渲染：同一指标在正文、表格、摘要、图表中出现多处时，全部从事实层取值渲染，禁止同一指标在不同位置二次手写。
- 缺失即缺失：本期数据缺失的指标，报告中写"数据待补"，并在交付时单列缺失清单。禁止用上期值填充、禁止估算、禁止"约为/预计"式补数。
- 口径三元组：每个指标入事实层时必须声明三元组——单位（亿元/万元/户/笔…）、期间（本月/1-N月/时点/日均…）、口径（含/不含某项、全行/某条线…）。三元组不明确时停止并询问用户；与历史报告口径不一致时停止并确认。
- 结论绑数据：每条结论、判断、点评必须能指认一条本期数据作为依据。数据依据反转（如由正增长变负增长）时，结论必须重写，不得保留历史报告的原结论。
- 敏感数据披露：报告涉及客户姓名、身份证号、银行卡号、手机号、账号等敏感信息时，必须在交付说明中明确告知用户（位置+类型），由用户决定脱敏方式。不得静默保留。
- 禁止歧义猜测：模板不清晰、数据源不清晰、口径不清晰时，先向用户确认，禁止自行假设后直接生成。
工作流程
阶段 0：输入盘点
逐项确认三要素，缺项即向用户索要：
| 要素 | 说明 | 缺失时处理 |
|---|---|---|
| 历史报告 | 上期成品报告（1份或多份），作为模板/框架/风格参照 | 无历史报告则不适用本技能，改为普通报告写作 |
| 本期数据 | 最新一期数据文件（Excel/CSV/文本等） | 必须索要，无数据不生成 |
| 生成方案与特殊要求 | 用户对方案 A/B/C 的选择，或特殊指令 | 无明确指定时按"阶段 2"的规则判断并复述确认 |
读取历史报告时，同时提取并记录（供后续自检使用）：
- 全部时间表述（"X月"、"1-N月"、"X季度"、"X年以来"、年份等）
- 全部机构名（支行/条线/部门名）
- 报告结构与章节标题
- 每章节的分析要点类型（总量→增速→排名→结构→结论 的行文套路）
阶段 1：歧义确认（生成前必做）
向用户确认以下事项，任何一项不清晰都不得跳过（可合并为一次提问，附上自己的默认判断供用户勾选）：
- 本期报告期间：本期是几月/几季度？累计口径是"1-N月"还是其他？
- 数据源范围：上传的数据文件中，哪些 Sheet/列/文件是本期数据？是否存在多版本（初稿/终稿）？
- 指标对应关系：历史报告中的指标名与数据文件中的字段名是否一一对应？对不上的列（如"时点余额"vs"日均余额"）必须逐条确认。
- 口径变化：本期数据的单位、统计区间、时点/日均、含/不含范围，与历史报告是否一致？发现任何不一致，列出差异请用户裁决。
- 生成方案：A/B/C 哪一种（见阶段 2）。
- 特殊要求：是否需要增删章节、调整口径、更换排名规则等。
确认结果逐条复述，用户认可后才进入阶段 3。
阶段 2：选择生成方案
| 方案 | 做法 | 适用场景 |
|---|---|---|
| A 严格模板替换 | 逐段对照历史报告：保留章节结构、行文措辞、分析框架、表格版式，只替换数据与时间表述。分析逻辑完全继承，不新增观点。 | 常规月度/季度通报，格式固定、考核口径不变。用户未指定时的默认方案。 |
| B 框架继承 + 重新分析 | 从历史报告提取结构框架与分析要点清单（写什么维度、按什么顺序、用到哪些指标），然后基于本期数据重新撰写全部分析内容。观点可以更新，但章节框架保持一致。 | 数据变化较大、上期结论已不成立、需要体现新亮点，但报告体例不能变。 |
| C 定制发散生成 | 以用户特殊要求为准，直接对本期数据展开新分析；历史报告仅作风格、深度、详略粒度的参照。 | 专项分析、领导临时要求、非例行报告。 |
判断规则：用户明确指定 → 用指定方案；未指定 → 建议方案 A 并说明理由；数据结构发生大变化（指标增减、口径调整）→ 主动建议 B 或 C 并解释。
阶段 3：构建事实层（Fact Layer）
这是本技能防错的核心机制。先建事实层，再渲染报告。规范详见 references/fact-layer.md。
- 从本期数据文件提取报告所需的全部指标，写入事实层（JSON 文件，建议命名
facts_<期间>.json）。 - 每条指标记录：指标名、值、单位、期间、口径、来源（文件名+Sheet+单元格/列）、是否计算所得（含计算公式）。
- 派生指标（增速、占比、排名、差额等）在事实层中登记计算公式与输入值，标记
derived: true。 - 数据文件中找不到的指标，登记进缺失清单（
missing列表），标记"数据待补"。 - 历史报告中的数字一律不进入事实层（除用户明确提供的基准值）。
阶段 4：渲染报告
- 按所选方案生成报告草稿。
- 渲染规则：所有数字从事实层取值；每次写入一个数字前核对事实层条目。
- 时间表述全局更新：本期期间、累计区间、年份，按阶段 1 确认的口径全文替换，包括标题、页眉、表格表头、脚注中的时间。
- 机构名核对：历史报告中的支行/条线名，逐个确认本期是否仍适用（机构撤并、更名、考核范围调整）。
- 方案 A/B 下逐段自查"这段的分析逻辑是否被本期数据支持"：支持则保留逻辑换数据；反转则重写结论；不支持且无数据则删除或标"数据待补"。
阶段 5：交付前自检（七项检查）
自检清单及操作方法详见 references/checklist.md。三项可脚本化检测必须实际运行脚本（用法见下），不得"目测代替"：
| # | 检查项 | 方法 |
|---|---|---|
| 1 | 上期内容残留（最高频出错点） | 脚本 scripts/stale_term_scan.py + 人工复查机构名、定性表述 |
| 2 | 同指标多值不一致 | 脚本 scripts/number_consistency_check.py 对照事实层 |
| 3 | 敏感数据 | 脚本 scripts/pii_scan.py |
| 4 | 缺失数据填充 | 人工核对：报告中"数据待补"处与事实层 missing 清单一一对应 |
| 5 | 数字来源合规 | 人工核对：抽查每个数字可回溯到事实层条目 |
| 6 | 结论绑数据 | 逐条结论自查依据指标名与数据方向 |
| 7 | 口径一致 | 人工核对三元组在标题、表头、正文中的表述一致 |
发现问题的处理：能定位的直接修复并复跑脚本；定位不了的列入交付说明的"待确认"项。
阶段 6：交付
交付物 = 报告成品 + 数据说明。数据说明必须包含：
- 计算声明：哪些数字是派生计算的（指标名、公式、输入值）。
- 缺失清单：所有"数据待补"项及其在报告中的位置。
- 敏感数据披露：报告中敏感信息的位置与类型（来自 PII 扫描结果）。
- 口径确认记录：与历史报告不一致并经用户确认的口径变化。
- 遗留待确认项（如有）。
脚本使用方法
三个检测脚本均用 Python 3 运行，参数用 -- 传入，输出 JSON 或人类可读列表。报告文件支持 .md/.txt/.docx（docx 先转出纯文本）。
# 1. 上期残留检测：扫描报告中的时间表述，标记与本期期间不符的残留
python scripts/stale_term_scan.py <报告文件> --period "2026年10月" [--cumulative "1-10月"] [--extra "支行A,支行B"]
# 2. 同指标多值检测：对照事实层，检查报告中同一指标数值是否一致
python scripts/number_consistency_check.py <报告文件> --facts facts_2026-10.json
# 3. 敏感信息检测：身份证/手机号/银行卡号/账号等
python scripts/pii_scan.py <报告文件> [--mask]
脚本输出的是"疑似问题"，最终裁决由模型结合上下文判断（如"2025年"出现在同比分析中是合法的），但每一处报警必须在自检结论中逐条处置（通过/修复/说明原因），不得忽略。
Resources
references/fact-layer.md— 事实层 JSON 格式规范、渲染规则、计算声明格式。阶段 3 必读。references/checklist.md— 七项自检的详细操作方法、常见出错案例。阶段 5 必读。scripts/stale_term_scan.py— 上期时间残留检测。scripts/number_consistency_check.py— 同指标多值检测。scripts/pii_scan.py— 敏感信息检测。
