日志很多，"洞察"很少
AI 系统通常不缺日志 ✗，缺的是每周固定看的三张表 ✔。
没有固定节奏，就只能在出事后临时捞数据 ✗ —— 那时往往已经晚了 ✔。
建议每周看三张表 ✔：质量表、成本表、失败表 ✔。
表一：质量表（按功能）
功能 ｜ 调用量 ｜ 成功率 ｜ 校验通过率 ｜ 负反馈率 ｜ 该拒答却作答率
看什么 ✔：
- 该拒答却作答率（编造倾向 ✔）—— 这条最该严 ✔；
- 负反馈率的变化（不是绝对值 ✔，是趋势 ✔）；
- 某个功能的成功率突然下降 → 大概率是上游或版本变化 ✔。
表二：成本表（按功能 × 租户）
功能/租户 ｜ 调用量 ｜ 单位成本 ｜ 总成本 ｜ 占比 ｜ 重试占比
看什么 ✔：
- Top 3 占比（集中度太高说明有异常使用 ✔）；
- 重试占比（纯浪费 ✔）；
- 单位成本周环比（> 20% 要查 ✔）。
表三：失败表（按失败类型）
失败类型 ｜ 次数 ｜ 占比 ｜ 环比 ｜ 样例（1 条）
看什么 ✔：
- 哪一类在涨（不是总量 ✔）；
- 有没有新类型（新增的坏模式最危险 ✔）；
- 样例必须是原文（不要只给统计 ✔）—— 看原文常常一眼就看出原因 ✔。
三张表的三个纪律
- 同一口径、同一周期 ✔（否则无法比较 ✔）；
- 每张表有一句结论 ✔（"本周编造占比从 4% 升到 7%，主要来自长文档场景" ✔）；
- 结论要转成待办 ✔（谁、什么时候、怎么验证 ✔）。
怎么开始（不用等数据平台）
- 第一周：从现有日志里手工捞三张表 ✔（一条 SQL 或一段脚本 ✔）；
- 第二周：把手捞的脚本固定下来 ✔，每周同一时间跑 ✔；
- 第三周：把结论与待办记进同一份文档 ✔（便于看历史 ✔）；
- 之后再考虑做看板 ✗（不要一开始就做 BI 项目 ✔）。
一条判据
每周一早上，有没有人能在 15 分钟内拿出这三张表 ✔（且与上周同口径 ✔）？
不能，说明观测还停在"出事再查" ✗。