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：不过。

运营档（ops）

• 语言：中文人话。
• 术语：少术语、少黑话；但必要的字段名 / 系统字段保留原文，不过度口语化（如 eval 里的字段名、活动 ID、region key——直接引用，不要翻成大白话）。见 guardrail「有点人话过度了」。
• 必带：具体数字（有数字才有说服力，「有数字/可解释」是运营档的底线）。
• humanizer：过（v2.8.0）。

老板档（leadership / boss）

• 长度：5 行内。（默认就是 5 行版变体。）
• 内容：结论先行、只保留决策/影响相关信息，砍掉过程细节。
• humanizer：过（v2.8.0）。

local team 档

• RD 档的事实陈述式变体，面向非工程的本地团队：默认英文或按 local team 语言，保留字段名 / region key / 活动上下文，语气比纯 RD 档更少技术堆砌。含混时问一句 local team 用什么语言。

Guardrails（逐字来自审计证据，落盘不得改写）

以下是用户真实说过的纠错原话，是本 skill 存在的理由，出稿前逐条自检：

「用英语，然后我是发飞书消息」 — 出处：内部会话审计记录 2026-06-23。含义：给研发默认英文，且是要粘贴进飞书的一段话，不要先出中文让用户第二轮再纠。

「有点人话过度了，涉及具体 eval 内明确声明的字段名的时候可以直接引用」 — 出处：内部会话审计记录 2026-06-02。含义：人话有度——语域落在「大白话」与「技术堆砌」之间；eval 字段名等专有名词直接引用原文，不要为了口语化而意译或拆解。

「给我具体的文件路径，文件名，版本号」 — 出处：内部会话审计记录 2026-06-24（原句「你检查的是哪个版本，给我具体的文件路径，文件名，版本号等细节信息，我发给研发」）。含义：RD 档证据密度是硬性的——路径、文件名、版本号、trace_id 一个都不能省。

相关技能

• humanizer（v2.8.0）：运营 / 老板档强制收尾。本 skill 调它，不重复它的能力。
• meeting-notes：会议纪要 → 群消息，是另一条链路（妙记输入）；本 skill 是「当前上下文发现 → 受众消息」，不重叠。
• lark-im：真正的发送通道。本 skill 只到预览，用户确认后如需代发再走 lark-im（但默认仍是用户自己复制发出）。

当日验收

用本会话现成素材出 RD / 运营两档各一条，零补纠即过（真实验收 = 连续 3 条对外消息的观察期）。