查提醒时为什么会看到全局结果？

如果你在 GoWork 里问“我有哪些提醒？”，默认看到的通常是全局生效任务，而不是当前聊天里的子集。先说结论：这不是串会话，也不是列表查错了，而是因为“任务查询范围”和“通知回到哪里”本来就是两回事。对大多数用户来说，“我有哪些提醒”真正想问的是我现在整体还有哪些活跃任务，而不是“这个聊天里刚好绑定了哪几条”。

这个边界在 GoWork 里很关键，因为它不只是一个会弹消息的提醒器。OmniGoAI 的 GoWork 同时要处理任务触发、运行上下文、通知目标和任务查询。如果把这些层混在一起，最常见的误解就是：任务明明是在当前聊天里创建的，为什么列表里还会出现别的提醒；或者明明结果会回当前会话，为什么默认查询不是 current conversation。

如果你已经看过 GoWork 定时任务通知会发到哪里？ 和 盯着检查和每天提醒不是一回事，这篇文章会把问题收窄到查询动作本身：为什么在 GoWork 里查提醒时，默认更适合用 all，而不是 current conversation？

先说结论：提醒列表默认回答的是“整体盘点”

当用户问“我有哪些提醒”“我现在有几个定时任务”“哪些任务还在生效”时，更自然的真实意图通常是：

1. 把我还活着的提醒都列出来；
2. 不要只看某一个聊天窗口；
3. 让我知道系统里整体还有哪些自动化在运行。

所以在这类问题上，默认按全局范围查询通常更合理。all scope 回答的是账户级盘点问题，current conversation 回答的是会话级过滤问题。 两者不是谁更正确，而是默认回答的粒度不同。

为什么 current conversation 不是默认值？

因为大部分时候，它太窄了。

想象一个很常见的使用场景：

• 你在网页端建了一个每周提醒；
• 在 Telegram 里建了一个明天上午的提醒；
• 在另一个团队会话里建了一个监控任务；
• 然后你回到当前聊天，问一句“我有哪些提醒？”

如果系统这时只返回当前聊天里的一条或两条，用户通常不会觉得“范围控制得很好”，只会觉得“怎么少了”。换句话说，默认 current conversation 往往更像漏报，而不是精准。

这也是为什么“我有哪些提醒”更适合作为全局盘点，而“这个聊天里的提醒有哪些”才适合缩成当前会话查询。

任务创建在当前聊天，不代表列表也只该看当前聊天

这是最容易混淆的一点。

很多用户会自然地把下面三件事当成同一件事：

1. 我在哪个聊天里创建了任务；
2. 任务结果会回到哪个聊天；
3. 我现在查列表时应该看到哪些任务。

但在 GoWork 里，这三层本来就分开：

• 创建入口：你在哪个会话里下达了任务；
• 通知目标：任务跑完后结果发去哪个 conversation；
• 查询 scope：你查列表时，是看全部活跃任务，还是只看当前聊天绑定的任务。

一条任务完全可能同时满足下面两个条件：

• 默认通知回当前会话；
• 但在“我有哪些提醒”里出现在全局列表。

这并不矛盾，因为它回答的是两个不同问题。

什么场景下，全局列表才真正符合直觉？

场景 1：你只是想盘点还有多少自动化在跑

比如：

• “我现在有几个提醒？”
• “还有哪些定时任务没停？”
• “帮我看看现在都开着什么自动跟进。”

这些问题本质上都不是某个会话内的问题，而是整体状态问题。默认用全局范围，才不会漏掉别的渠道和别的聊天里建的任务。

场景 2：任务和通知目标不在同一个地方

GoWork 支持在一个会话里创建任务，却把结果送到另一个会话或渠道。比如：

• 在网页里创建；
• 把结果发去钉钉群；
• 或者把监控命中结果发到固定项目会话。

这时如果你只按当前聊天过滤，看到的就不是完整图景。全局视角更适合管理任务，当前会话视角更适合定位一个具体聊天绑定了什么。

场景 3：有些任务本来就是静默运行

还有一类任务不会在每次执行时都发通知，比如：

• 每 5 分钟轮询一次，只在命中条件时通知；
• 后台周期汇总，只在失败时告警；
• 单纯保留 run 历史，不做实时消息推送。

如果用户用“我有哪些提醒”来盘点系统里还在跑的自动化，全局列表能把这些静默任务也一起带出来。否则用户很容易误以为“没通知就等于没任务”。

那什么时候 current conversation 才是对的？

当用户明确在问“这个聊天里的提醒”时。

典型说法包括：

• “当前会话有哪些提醒？”
• “这个聊天里绑定了哪些定时任务？”
• “刚刚在这里建的那个提醒还在吗？”
• “只看这个会话里的任务。”

此时重点已经不是整体盘点，而是会话内过滤。也就是说，current conversation 不是不重要，而是不该偷换成全局默认。

为什么很多人会把 scope 和通知目标搞混？

因为两者都在回答“和会话有关的问题”，但回答的根本不是一回事。

scope 回答的是：查哪些任务

这是列表查询的问题。你想看全局，还是只看当前会话？它解决的是“看见哪些记录”。

通知目标回答的是：结果发到哪里

这是任务执行完成后的投递问题。它解决的是“运行结果回到哪个 conversation”。

一个很常见的误区是：

• 任务结果会回当前聊天；
• 所以列表默认也应该只看当前聊天。

这个推理并不成立。因为“结果去哪”与“盘点范围多大”本来就不是同一个字段。

为什么全局默认更适合多数用户？

因为用户在问“我有哪些提醒”时，通常是管理心态，不是局部排障心态。

他们更关心的是：

1. 我有没有忘记取消某些任务；
2. 有没有重复的提醒；
3. 还有哪些自动化在持续跑；
4. 哪些任务可能在别的聊天里创建过但我已经忘了。

这些都要求默认返回一个更完整的视图，而不是当前会话里的窄切片。

如果系统把默认值设成 current conversation，用户就得先知道自己要去哪个聊天里找，才有机会把全部任务拼回来。这不符合“列表查询”应有的管理体验。

一个简单判断法：用户到底在问盘点，还是在问定位？

可以用一句很简单的话区分。

盘点型问题：默认看 all

例如：

• “我有哪些提醒？”
• “我现在有几个定时任务？”
• “还在生效的任务有哪些？”

这些都是整体盘点。

定位型问题：才看 current conversation

例如：

• “当前会话里有哪些提醒？”
• “这个聊天里的定时任务有哪些？”
• “这里只绑定了哪几个任务？”

这些是局部定位。

设计提醒列表时，最容易踩的三个坑

坑 1：把默认列表做得太窄

默认只看当前会话，短期看像是“更专注”，实际常常等于漏掉别处创建的任务。

坑 2：把创建入口误当成查询范围

任务是在这里创建的，不代表现在盘点时就只该看这里。创建位置和查询范围不应该强绑定。

坑 3：把通知回传逻辑误当成列表逻辑

任务结果会回当前聊天，不代表列表默认也该限定当前聊天。前者是投递，后者是查询。

常见问题

FAQ 1：为什么我在这个聊天里查提醒，会看到别的任务？

因为“我有哪些提醒”默认更适合返回全局活跃任务，而不是只返回这个聊天绑定的子集。这通常是在做整体盘点，不是串会话。

FAQ 2：那 current conversation 有什么用？

当你明确只想看当前聊天绑定的任务时，它就很有用。比如排查“这里刚建的任务还在不在”时，就应该缩成当前会话范围。

FAQ 3：如果任务结果默认回当前聊天，为什么列表不也默认当前聊天？

因为通知目标和查询范围是两层概念。一个决定结果发到哪，一个决定你在盘点时看哪些记录。

FAQ 4：静默任务为什么也应该出现在全局列表里？

因为它们虽然不一定每次通知你，但依然是活跃自动化。全局盘点时把它们纳入列表，才能让用户知道系统里还有哪些任务正在运行。

理解 GoWork 的提醒列表，关键不是把它当成一个“消息框”，而是把它看成任务管理视图。只要你把“创建入口”“通知目标”“查询 scope”拆开，为什么默认返回 all、为什么 current conversation 只在明确点名时才更合适，就会一下变清楚。如果你想继续把边界摸透，可以再看 GoWork 定时任务通知会发到哪里？ 和 GoWork 下载页，顺着实际任务创建和查询流程走一遍，会更容易建立正确直觉。