audience-brief

audience-brief — 受众分层话术打包器

把当前上下文里的发现 / 改动 / 状态 / 计划，按目标受众打包成一段可直接复制粘贴进飞书的消息。纯编排、零基建：不拉数、不落盘、不发送——只出稿、停在预览、等用户自己发。

这个 skill 解决的是一个反复出现的返工：给 RD 要英语、给运营要中文人话、给老板要短，证据要带版本号和路径——这些偏好过去每条消息都要用户第二轮补纠（「用英语」单独作为一条纠正消息出现过 ~6 次）。这里把档位固化，力争零补纠。

什么时候用

• 用户已经在当前会话里拿到了要传达的内容（一个发现、一次修复、一个版本状态、一个计划），只是要「包装成一段话发出去」。
• 触发词：「整理一段话我发给研发」「给运营的人话版」「发老板」「我发研发用」「share 给运营」「发飞书群」。
• 不适用：需要先做分析/归因/审计才有内容的场景（先去做那件事）；需要真正发送到某个群/某个人（本 skill 只出稿到预览，发送由用户手动完成 or 另走发送通道 skill）；妙记会议纪要总结（走 meeting-notes）。

核心流程（5 步）

1. 识别受众

从触发语和上下文判定目标受众，落到四档之一：RD / 运营 / 老板 / local team。

• 明确说了「研发 / RD / eng / 研发用」→ RD 档。
• 说了「运营 / ops」→ 运营档。
• 说了「老板 / leadership / 汇报 / 上级」→ 老板档。
• 说了「local team / 本地团队 / 区域 review」→ local team 档（本质是 RD 档的事实陈述式 + 保留字段名，但语气面向非工程受众，默认英文或双语，视 local team 语言而定）。
• 含混时只问一句（不要连环追问）：例如「这条是发给研发（英文、带版本号/路径）还是运营（中文人话）？」，拿到答案立即出稿。

2. 按档位出稿

三档模板见下方「档位规格」。每档的语言 / 语气 / 长度 / 证据密度都是硬约束。

3. 运营 / 老板档强制 humanizer 收尾

运营档和老板档出稿后，必须调用 humanizer skill（v2.8.0）过一遍再交给用户——去掉 AI 腔（rule-of-three、em dash 滥用、空洞 -ing 分析、promotional 词、negative parallelism 等）。

• RD 档不过 humanizer：RD 档要的是事实陈述式的英文，humanizer 反而可能软化掉技术精确性。
• humanizer 有度：过一遍是为了「像人写的」，不是为了「口语化到丢字段名」。见下方 guardrail「有点人话过度了」——涉及 eval 里明确声明的字段名，直接引用原文，不要意译、不要拆成大白话。

4. 支持变体

用户常在同一条消息上要变体，主动支持、也在预览里提示可切换：

• 5 行版：压到 5 行以内（老板档默认即此）。
• 一段话版：不分点，一整段（发飞书群/私聊常用）。
• 中英双语单发：中英各一段，用于单发私聊场景（一条消息里中英都给到）。

5. 输出即贴 + send-gate 停在预览

• 输出即贴：交付的正文无 markdown 残留——不要 **加粗**、不要 # 标题、不要 ``` 代码围栏、不要 markdown 列表符号（飞书粘贴进去会变成裸星号/井号）。要分点就用中文顿号编号或纯换行。证据里的路径 / 版本号 / trace_id 直接写明文。
• send-gate：出稿后停在预览，明确说「这是预览，确认后你自己复制发出 / 告诉我要调哪里」。绝不代发、不调发送通道。这是与用户「停在最后一步我来提交」纪律一致的硬闸门。

档位规格

RD 档（研发 / eng）

• 语言：英文。（这是最高频的补纠点——见 guardrail「用英语，然后我是发飞书消息」，过去 ~6 次都是第二轮才补。本档默认直接英文，不要先出中文再等纠。）
• 长度：2–4 句。精炼。
• 语气：事实陈述式 = 「我发现的问题 + 建议」，不是技术细节堆砌、不是长篇报告。（配套纠正原话：「不用带这么多技术细节，更多是描述我发现的问题和建议」。）
• 证据（必带）：版本号、trace_id、文件路径 / 文件名。缺任何一个就是不合格——见 guardrail「给我具体的文件路径，文件名，版本号」。若上下文里拿不到某个证据字段，先问用户或去查，不要糊过去。
• humanizer：不过。