从"一段话"到"一张表"
AI 输出如果只停在一段自然语言里 ✔，下游就没法自动用 ✔ ——
报表、看板、工单都吃结构化数据 ✔。
把模型的输出接到报表，关键在于"稳定的 schema + 可校验的流转" ✔。
一、四步流转（每步都要可校验）
① 抽取：模型输出结构化对象（schema 固定 ✔）
② 校验：类型、范围、枚举、业务规则（见约束变校验 ✔）
③ 落库：按幂等键 upsert（见接线那篇 ✔）
④ 展现：报表/看板读库（不让报表直接读模型输出 ✔）
第 ④ 步最关键 ✗→✔：让报表直接消费模型输出时 ✔，
模型一漂格式，报表就崩 ✔；落库后再展现，模型异常只影响入库环节 ✔。
二、schema 设计的三条纪律
- 字段名稳定（改字段 = 破坏下游 ✔ → 加新字段而非改名 ✔）；
- 可空要显式（
null与"缺失"含义不同，要写清 ✔）； - 带元数据（
model/generated_at/confidence✔ —— 见不确定性传递 ✔）。
示例 ✔：
{ "order_id": "A123", "risk_level": "high",
"reasons": ["金额超过阈值", "首次交易"],
"confidence": "medium", "model": "…", "generated_at": "2024-05-12T09:00:00Z" }
三、三个常见坑
- 让模型直接生成 SQL 或报表公式 ✗（既不可校验，也是安全风险 ✔ —— 见权限模型 ✔）；
- 字段语义漂移 ✗（同一字段今天表示"金额"明天表示"含税金额" ✔）→ 写进字段字典 ✔；
- 没有"数据来源"标记 ✗（下游无法区分人工填写与模型填充 ✔）。
四、该观测什么
- 结构化成功率（能通过校验的比例 ✔）；
- 按字段的校验失败分布（哪个字段最容易错 ✔ → 该字段的示例与说明要改 ✔）；
- 下游报表的异常率（落库后数据质量问题 ✔）；
- 人工修正率（按字段统计 ✔ —— 修正率高的字段说明抽取不可靠 ✔）。
五、一条判据
报表里的每个数字 ✔，能否追溯到具体哪次模型调用 ✔ 与谁（或什么规则）校验过 ✔？
不能，说明结构化流转还缺"可追溯"这一环 ✗。