Files

T

wuyang6 40d7c92a1d fix session routing and subagent visibility

2026-06-12 11:06:04 +08:00

7.4 KiB

Raw Blame History

name, description, when_to_use, aliases, allowed_tools

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

Report Briefing Skill

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

核心原则

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

指标格式硬约束

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

指标名：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：每项有动作、对象、数量或验收标准。

通用输出骨架

项目进展/模型优化

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

数据/评测集建设

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

策略评估/下线

- <策略评估/下线标题>
  - 数据分析：<链接>
    - <数据集 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 不要简单写成“清理 = 不进优化集”。先写结论：

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

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

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

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

- 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 是否能直接变成后续工作项？
是否删除了重复解释和过深嵌套？

7.4 KiB Raw Blame History Unescape Escape