群聊爬楼 → 选题雷达

场景

编辑部、产品组、市场部，几乎每个团队都有这样一个群：大家每天往里甩信息，一会儿有人贴一条新消息，一会儿有人补充背景，聊着聊着又拐到别的方向上去了。

信息很多，也很有用。但等到真正要用的时候，问题来了——刚才是谁提的？最后决定跟进哪个？那条关键信息被刷到哪去了？

想找回来只能吭哧吭哧爬楼。

提示词

读取「XX 讨论组」群最近两周关于「XX 主题」的聊天记录和相关云文档，
梳理成一份线索清单，分成三档：

【本周重点】已经形成共识、这周就要推进的
【持续观察】有价值但时机未到，需要跟踪的
【观察池】提到过但信息不足，先存着的

每条线索包含：
- 一句话说清楚是什么
- 谁提出的、什么时候
- 当前掌握的关键信息
- 负责人（群里有人认领的写上，没人认领的留空）
- 待核实项（还需要确认什么）

另外单独列一块【已排除】：
被讨论过但决定不跟进的，写清楚原因。

处理完同步到飞书多维表格「XX 选题雷达」，
字段按上面的结构建，方便我们后续继续筛选和补充。

每条标出信息来源，我要能点回原始消息。

为什么这么写

分三档而不是给一个大列表。 「本周重点 / 持续观察 / 观察池」对应三种不同的动作。一个不分级的清单等于没分级，你还是得自己排优先级。

「已排除」这一块很多人想不到，但它很值钱。 团队讨论中被 pass 掉的东西，过两个月又会有人重新提出来，然后重新讨论一遍。把「为什么不做」记下来，能省掉大量重复讨论。

「待核实项」。 群聊里的信息经常是半成品——有人说「听说他们融了 B 轮」，这条得核实才能用。把待核实项单独列出来，避免半成品被当成事实用下去。

同步到多维表格。 这是从「一份总结」变成「一个可协作的系统」的关键一步。多维表格里大家能继续筛选、补充、更新状态，而不是看完一份文档就完了。

实测效果

有编辑部实测了这个用法：让豆包工作读取团队近期围绕某个行业主题的群聊。它很快找到了相关群聊记录和云文档，把之前群里总结的重点准确提取出来，分成「本周重点」「持续观察」「观察池」，补上负责人和待核实项，连被 pass 掉的选题和原因也写清楚了。

最后同步进多维表格，一份可以继续筛选、补充和协作的选题雷达就有了。

整个过程不用重新上传聊天记录，也不用解释团队此前讨论过什么。

验收清单

• [ ] 你记得的几条重要线索都在里面
• [ ] 每条能点回原始消息
• [ ] 分档合理（挑两条看看，档位对不对）
• [ ] 负责人没有被瞎猜
• [ ] 多维表格字段完整，能筛选

变体

换个场景，同一套结构：

设成定时任务： 每周一早上自动跑一次，增量更新多维表格。见 04 定时任务。加一句「只处理上次运行之后的新消息，已在表里的线索更新状态而不是重复新建」。

常见问题

漏了重要线索。 群聊里的信息很多是靠上下文才能理解的（一个链接 + 一句「这个有意思」）。让它输出「已处理的消息数和时间范围」，确认覆盖完整。

同一条线索重复出现。 加一句「同一件事在不同时间被讨论的，合并成一条，按时间线组织信息」。

分档不准。 把标准写得更具体：「本周重点 = 群里有人明确认领并给了时间；持续观察 = 有人表示有价值但没人认领；观察池 = 只被提及一次没有后续讨论」。