---
name: report-briefing
description: 将数据分析、模型优化、策略下线、评测集建设、上线指标、badcase 复盘等内容整理成领导汇报版本。适合用户要求“汇报一下”“30 秒版本”“简洁结论”“给领导看”“整理回报/汇报 skill”，或需要把复杂分析产物压缩成背景、关键数据、例子、结论和后续 ToDo。
when_to_use: 用户希望把数据分析或项目进展转成汇报口径、复盘为什么之前表达不适合汇报、统一不同类型周报/项目回报格式、或需要一版面向决策者的简洁分点材料时使用。
aliases: leadership-report, exec-brief, report-summary, 汇报, 回报, 领导汇报
allowed_tools: read_file, write_file, edit_file, grep_search, glob_search, python_exec
---

# Report Briefing Skill

使用这个 skill 把分析结果压缩成“领导能快速判断进展、收益、风险和下一步”的汇报，不写长篇分析报告。

## 核心原则

1. 先交代“我们在做什么工作”和当前状态，再给数据和结论。不要一上来只写“结论”。
2. 任何指标必须同时给百分比和分子分母，格式强制为 `50%(100/200)`；对比指标写成 `old%(a/b)->new%(c/d)`。
3. 区分“指标”和“规模”：准确率、召回率、diff 率、基线、覆盖率是指标，必须带分子分母；训练集 578 条、评测集 935 条是规模，可只写数量。
4. 用少量关键数据支撑判断，不展开所有中间分析。每个数据集或评测集只保留最能支持决策的 2-4 个数。
5. 例子只服务于解释覆盖范围或典型问题，每类 1-2 个。不要把样例堆成样本列表。
6. 结构可以因任务变化，但每段都要回答一个决策问题：做了什么、效果如何、风险是什么、下一步做什么。
7. ToDo 用业务动作命名：清洗、抽审、构建评测集、模型优化、上线评估、离线对比、下线评估。不要写泛泛的“继续分析”。

## 指标格式硬约束

所有带百分比的指标必须写成：

```text
指标名：50%(100/200)
指标名：50%(100/200)->80%(160/200)
指标名：50%(100/200)->80%(160/200)（+30%）
```

注意：

- 分子分母之间不要省略；`58.18%->73.9%` 这种不合格，除非原始材料确实没有分子分母，此时标注为 `58.18%->73.9%（缺分子分母）`。
- 同一行内有多个指标时，每个指标都要带自己的 `(a/b)`。
- `GSB：30:54:16` 这种人工对比结论不是百分比指标，可以保持原样；如有采样量，写 `采样 100 条，GSB：30:54:16`。
- 空提升或从 0 起步写 `0%(0/n)->93.72%(388/414)`，不要写 `0->93.72%`。

## 汇报的“魂”

无论内容是模型优化、策略下线、评测集建设还是上线评估，优先抽成下面几个信息块，按需要取舍：

- **工作项**：一句话说明项目目标和当前状态，例如“快慢分发问题优化，模型已上线”。
- **关键收益**：列最重要的离线/线上指标变化，使用 `old%(a/b)->new%(c/d)`。
- **安全性/上线风险**：列大盘集、TOP diff、Random diff、GSB 等兜底指标。
- **数据建设**：写清评测集/训练集规模、当前基线、覆盖范围、典型例子。
- **问题定位**：用 1-3 个分桶说明不能优化、需要策略处理、需要人工清洗的原因。
- **后续 ToDo**：每项有动作、对象、数量或验收标准。

## 通用输出骨架

### 项目进展/模型优化

```markdown
- <项目/问题>：
  - <进展状态>：<已完成训练/已上线/preview 评测中/待下线评估>
  - 模型优化：
    - <评测集 A>：<old%(a/b)>-><new%(c/d)>
    - <评测集 B>：<old%(a/b)>-><new%(c/d)>
  - 上线指标：
    - <线上回放/大盘集>：<指标%(a/b)>，<采样量和 GSB 如有>
  - 后续 ToDo：
    - <动作 + 对象 + 验收标准>
```

### 数据/评测集建设

```markdown
- <评测集/训练集建设>：
  - <数据集名>（<N> 条），<基线或当前模型>：<pct%(a/b)>
  - 覆盖范围：
    - <类型 A>：<一句定义>
      - <例子 1>
      - <例子 2>
    - <类型 B>：<一句定义>
      - <例子 1>
  - 后续：<抽审/补齐/清洗/上线评估>
```

### 策略评估/下线

```markdown
- <策略评估/下线标题>
  - 数据分析：<链接>
    - <数据集 A>，线上样本 <N> 条：
      - <分桶 1>：<p%(n/N)>
      - <分桶 2>：<p%(n/N)>
      - <可优化/可下线/需评测>：<p%(n/N)>
    - <数据集 B>，线上样本 <N> 条：
      - <分桶 1>：<p%(n/N)>
      - <分桶 2>：<p%(n/N)>
      - <可优化/可下线/需评测>：<p%(n/N)>
  - 后续 ToDo：
    - <动作 1>：<数量 + 判断标准>
    - <动作 2>：<数量 + 覆盖范围>
```

字段命名要贴近汇报对象：

- `模型可优化候选` / `初筛正例评测集（模型可优化）`：用于说明模型能吃掉哪部分。
- `模型推理非复杂/无可用历史`：用于说明为什么不能直接当正例。
- `topQuery/缺 prompt`：用于说明是配置或链路口径，需单独治理。
- `上线指标`：用于说明收益是否安全。
- `覆盖范围`：用于说明数据集不是随机堆样本，而是覆盖明确问题类型。

## topQuery 口径

topQuery 不要简单写成“清理 = 不进优化集”。先写结论：

```markdown
- topQuery 当前不能直接归入模型优化，需要进一步按 query 分析并清理配置。
```

分析时按“配置去留”而不是“是不是复杂多轮”判断：

- 意图明确的 topQuery：可能保留配置，不作为模型优化目标。例如 `播放音乐`、`关闭音乐`、`打开座椅通风`。
- 依赖上下文的 topQuery：建议下线固定配置；如果业务仍需召回，再由模型或上下文规则补。例如 `不走高速`、`走高速`、`第二个`、`添加途经点`、`停车场`、`西门`。

如果要给领导看，先给覆盖集中度：

```markdown
- topQuery 影响较大，占全量 <p%(n/N)>，去重后 <k> 个 query；分布集中，Top10 覆盖 <p10%(n10/n)>，Top20 覆盖 <p20%(n20/n)>。
```

## 粒度规则

好的汇报句子：

- `processing 策略召回，线上样本 7,460 条：topQuery 22.4%(1,671/7,460)，模型推理非复杂 57.8%(4,310/7,460)，模型可优化 19.8%(1,479/7,460)。`
- `车控意向性评测集：56.88%(372/654)->95.26%(605/654)。`
- `TOP diff 率：3.96%(485/12,260)，采样 100 条评估 GSB：30:54:16。`
- `高置信正例评测集从 2,431 条模型可优化候选里抽审 500 条，覆盖当前轮复杂、历史复杂后的确认/选择、目的地补槽、路线修改、地图信息承接。`

避免的写法：

- 只说“剩余大多是噪声”，但不给占比。
- 写 `50%` 但没有 `(100/200)`。
- 一上来写结论，没说当前在评估什么工作。
- 把 topQuery 直接等同于“不能优化”或“应该删除”。
- 列很多 query 类型但不说明它们对应什么决策。
- 写长段解释，让用户再帮忙压缩。

## 自检清单

输出前检查：

- 是否先说明了任务背景？
- 所有指标是否都是 `pct%(a/b)` 格式？
- 对比指标是否都是 `old%(a/b)->new%(c/d)` 格式？
- 每个数据集是否有总量、分桶和占比？
- 是否解释了模型优化、策略处理、数据清洗各自的边界？
- topQuery 等配置类问题是否用“配置去留 + 是否需要模型补召回”的视角？
- ToDo 是否能直接变成后续工作项？
- 是否删除了重复解释和过深嵌套？