产品讨论频道里，几条建议没有及时看，过了一周就沉到历史消息里。偶尔想起来，只记得讨论过某个功能，已经不知道该搜谁、搜哪个词。
第七期的一次使用中，Agent 回看了最近一个月的 Slack 产品讨论，整理出提议与参与情况。橘子由此发现漏看的想法，接着让它给出消息链接，再回去补读。这个结果很具体：找回了值得读的几段讨论。
检索范围要跟着问题走
如果想找产品建议，可以限定频道、日期和议题。Slack 的搜索支持 in:、日期修饰符和 is:thread 等条件，官方文档列出了用法。
Agent 可以帮助组织检索词，但结果里仍要说明查过哪里。只读一个频道，就可能漏掉其他频道的后续决定；只读主消息，没有展开回复，也无法判断建议是否已有人处理。
与其一次要求总结整个工作区，不如先找一个具体问题：最近一个月，有没有关于注册流程、尚未得到明确回应的建议？结果容易人工抽查，漏掉什么也更容易发现。
读到后面，建议可能已经有了结论
假设月初有人提议缩短注册表单。后面的线程中，有人补充了必要字段的原因，最终决定先修改帮助文案。如果只摘出第一条建议，读者很可能再次发起已经结束的讨论。
每条推荐可以附上简短的当前状态：提出了什么，后续是否有结论，为什么还值得看。没有找到结论时，就写没有找到，不从沉默推断大家同意了。
链接最好直接到消息或线程。回到频道首页后还要重新搜索，会抵消摘要省下的时间。涉及多个时间段的讨论，也应分别保留出处，避免把一次旧结论套到新的条件上。
计数适合找线索，不适合评价一个人
节目中的任务统计了谁提出想法、谁参加讨论。这样的表可以帮助找到联系人，却很难用于比较贡献。连续五条补充可能只表达一个意见，一条指出关键限制的回复则可能改变整个方案。
设计稿、代码、线下讨论也未必在搜索范围里。用聊天里看得见的工作给人排名，会遗漏大量信息。如果目的只是补读，按主题和当前状态排列就够了。
读完后，有时需要回应，有时只需把已有结论放进正在做的项目。需要跟进时，把对应线程链接附在任务里，后续参与者也能查到已有讨论。
相关资料
- 回看产品讨论并发现漏看想法的案例
- 索取消息链接，再回到原讨论补读
- Slack：Search in Slack，查阅于 2026 年 10 月 26 日。