Appearance
知识推送的注意力路由：从摘要到点名
第二部 · Agent 实践 · 第18章
撰写日期：2026-07-05
结论
团队知识库每新增一篇文档，bot 往群里发一张介绍卡。这个场景我迭代了四轮，最大的转变是重新定义这张卡的本职：
上新推送的本职不是"介绍这篇文档"，而是帮群里每个人在 3 秒内决定：我要不要读、读哪里。 摘要是内容的压缩，路由是注意力的分配——只有后者值得占用全员的群消息。
1. 摘要式推送为什么无效
| 摘要式 | 路由式 | |
|---|---|---|
| 回答的问题 | 这篇讲了什么 | 谁该读、读哪一段、为什么 |
| 读者要做的事 | 自己判断和我有没有关系 | 被点名的点进去，没点名的安心跳过 |
| 隐含假设 | 所有人对所有文档等概率感兴趣 | 注意力是稀缺资源，按人分配 |
| 失败模式 | 全员划过，推送通道被"训练废掉" | 点错人（可修）、漏点人（要治理） |
"没被点名的可以放心跳过"确实是路由的价值，但这个信息应该由"不点名"本身传达，而不是写出来——我第一版模板要求明说"其他人可略过"，实际跑起来发现：一个十人团队，每张卡都在对大多数人说一遍"你可以走了"，重复且带着打发感。终版规则：只点该看的人，没点到的一个字都不提。
2. 卡片模板：三行 + 署名
| 行 | 内容 | 约束 | 职责 |
|---|---|---|---|
| 🧭 一句话 | 这篇是什么 | ≤30 字，说信息量，不复述标题 | 3 秒定性 |
| 👀 建议谁看 | 按相关性点名 + 一句理由 | 1~4 人，同类可分组；作者绝不点；未点名者一字不提 | 注意力分配 |
| 🎯 重点看 | 最值钱的一个点 | ≤40 字，具体到章节 / 数字 / 可复用物 | 给被点名者一个入口 |
| ✍️ 署名行 | 作者 ＋ 原文链接 | 合并一行不占空间 | 归属与跳转 |
生成 Prompt 的脱敏模板：
text
知识库刚新增一篇文档，要在 N 人团队群里播报。你的产出是**注意力路由**，
让每个人 3 秒内决定要不要读。总共不超过 150 字，严格输出以下三行：
🧭 一句话：<这篇是什么，≤30字，说信息量不复述标题>
👀 建议谁看：<按真实相关性点名（1~4 人，同类可分组如「产品线：A/B」），
每人/组理由 ≤12 字；漏掉真该看的人比多点一个更糟；作者本人绝不点；
确实全员相关才写全员；只点该看的人，没点到的一字不提，
禁止出现「其他人可略过」这类打发人的表述>
🎯 重点看：<1 个最值钱的点，具体到章节/数字/可复用的东西，≤40字>
作者：{author}
团队成员画像：{roster}
文档标题：{title}
文档内容（截断）：{excerpt}3. 路由的正确性来自数据和校验，不止 Prompt
四轮迭代里真正提升路由质量的，都不是措辞技巧：
作者感知。 早期版本不知道文档作者是谁，于是闹了笑话：把一篇文档郑重其事地路由给它的作者本人。修法是从平台元数据取 creator 喂进 Prompt——路由系统必须知道"这条信息从谁那来"，否则会把信息推回源头。
Prompt 约束 + 代码守门双保险。 "作者本人绝不点"写进 Prompt 只是软约束，配套一条硬校验：生成结果的点名行若命中作者名，直接判生成失败、重新生成。上线当天这条校验就真拦下过一次模型跑偏。我的判断可以概括为：
LLM 输出里每一条"绝不"，都需要一个代码层的守门员。Prompt 负责让模型大概率做对，校验负责让做错的结果永远出不了门。
同一原则的另外两个守门员：形状校验——模板要求恰好三行、各以固定符号开头，就按这个形状硬性验收，模型附加的任何"说明""自言自语"直接判失败重试（我真收到过模型在卡片末尾追加一段对输入的评论）；切断子进程 stdin——headless 调用 CLI 型模型时，子进程会把继承到的管道残留拼进上下文，这是一个容易被忽略的注入面，显式传空 stdin 一行修掉。
点名上限是漏点的结构性原因。 我曾为压卡片长度把点名硬限 1~2 人——对多方相关的文档（产品、设计都沾边）就必然漏点，被漏掉的成员看到卡片的第一反应是"这推荐不准"。修正原则：路由系统里，漏掉真该看的人比多点一个更糟（recall 优先）。配合"同类分组"（产品线：A/B；设计线：C/D）可以在不涨长度的前提下涨覆盖。
路由精度的上限 = 成员画像质量。 一位成员在画像里是"资料待补充"，模型从机制上就永远不会点到 TA——这不是模型问题，是数据盲区。团队版 User Model（每人的角色、专长、在做什么）是路由系统的一等公民数据：画像有多少空白，路由就有多少盲区，而且盲区是静默的。
画像的坑还有一种更隐蔽的形态：写了但写偏了。比如某位成员画像只写了"创始人 / 战略"，产品向的文档就永远路由不到 TA——尽管 TA 实际深度参与产品决策。被点名的人不会抱怨（多收一条推荐无感），被漏掉的人才会发现"这推荐不准"。运营结论：盲区清零是一次性的排查工程（把每个空白和写偏的条目对着真人核一遍），维持靠流程——新成员入队 checklist 里必须有"补画像"一项，否则 TA 从加入那天起就收不到任何点名。
4. 时机：静候期，别吆喝半成品
新文档"被发现"不等于"写完了"。直接播报会把作者写到一半的草稿曝光给全员——对作者是打扰也是尴尬。做法：
| 机制 | 设计 |
|---|---|
| 静候期 | 新文档先入队，连续 N 分钟（如 10 分钟）无编辑才视为定稿放行 |
| 计时重置 | 队列期间每次编辑动作重置静候计时 |
| 只播一次 | 每篇只播报一次，后续编辑不再触发（避免"改个错字又被全员通知"） |
| 介绍按定稿生成 | 播报时以最新内容生成介绍，不用入队时的旧稿 |
5. 措辞是权力位置
两处一字之差的修订，都来自真实使用反馈：
| 原措辞 | 改为 | 原因 |
|---|---|---|
| 谁要看 | 建议谁看 | 前者是分派任务，后者是提供建议——bot 是参谋不是上级 |
| 其他人可略过 | （删除，不提未点名者） | 每张卡对大多数人说"你可以走了"，重复且打发人 |
推送文案的语气，实际上定义了 bot 在组织里的权力位置，这类措辞值得逐字抠。