audience-brieflisted

# 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 残留**——不要 `**加粗**`、不要 `#` 标题、不要 ``` 代码围栏、