让 AI 持续跟进项目，怎样少发重复提醒，又不漏掉变化？

AI 生成的概念插图，内容为假设示例。

假设你让 AI 帮忙盯着一个周五交付的项目。周一，它提醒客户还没确认材料；周二，它又发来几乎相同的摘要。到了周三，客户已经在邮件里提出延期，项目看板却仍然写着周五交付。助手把两个日期都放进了报告，最后建议你“持续关注”。

你还是得打开邮件，查看看板，再问一次负责人。

持续跟进需要保留上一次的判断，并说明这一次有什么变化。如果每次运行都重新概括全部材料，助手很容易把旧消息写成新进展，也可能把尚未确定的提议当作已经生效的安排。

一次摘要之后，还需要留下什么

跨应用整理信息的尝试已经不少。Composio 的家庭日报案例把日历、天气和趣味内容组成一份当天的小报；Lindy 的 AI teammate 介绍讨论了持续上下文与主动跟进。这些内容说明当天的信息可以整理成什么，但没有回答一个更具体的问题：连续两次检查之间，应该保留哪些已经确认的判断。

一份当天摘要帮助你了解眼前的安排；一项持续跟进的任务，还需要解释事情相对上一次发生了什么。

以项目交付为例，第一次整理完材料后，值得留下的内容很少：当前确认的交付日期、仍在等待的材料、负责跟进的人，以及支持这些判断的来源。还要记下这次检查覆盖到什么时间，哪些来源没有读到。

这份记录就是下一次检查的起点。它可以保存在应用数据库、任务记录或一份受控文档中，具体形式由助手系统决定。重要的是后续运行确实能读到它，并且知道其中哪些内容已经确认，哪些只是推测。

如果上一次只有一句“项目进展正常”，下一次就很难解释到底哪里变了。

新消息不一定意味着事情有了进展

同一份材料被转发到群里，邮箱里多了一封“收到，谢谢”，看板上有人修改了任务描述。这些都是新记录，但对交付的影响不同。

可以围绕任务关心的事实做比较。对于这个项目，你真正需要知道的是：材料是否齐备，交付日期是否改变，谁接下了待办，以及是否出现新的阻塞。

下面是一组假设情况：

本次读到的内容	应怎样理解	适合怎样提醒
同事转发了周一的材料请求	同一事项，尚无新的交付信息	不重复推送同一条提醒，到期仍提醒
客户发来了此前缺少的附件	材料已收到，是否满足要求仍需检查	说明收到什么、还缺什么
客户询问能否改到下周一	出现了改期请求	标为待决定，保留当前确认日期
负责人明确同意改期	出现新的确认记录	说明原日期、新日期和确认来源

识别同一条记录，可以使用源系统提供的标识；判断不同记录是否描述同一件事，还需要结合项目、参与人和内容。仅凭标题相同，无法可靠地把两封邮件合并。仅凭文字不同，也不应认为项目又向前推进了一步。

已经明确的字段适合直接比较，需要理解语义的地方再交给模型。比如先找出日期字段发生变化的任务，再让 AI 阅读相关讨论，解释这次变化是否已经得到确认。

邮件和看板不一致时，把分歧留下来

周三的邮件提出下周一交付，看板仍然写着周五。哪一个才算数？

“更新得更晚”只能说明记录时间，不能说明发言人有权改变安排。邮件可能是一项请求，看板可能尚未更新，也可能只是引用了另一项任务的日期。

团队可以提前约定依据。例如，交付日期以指定负责人的确认为准，看板用于记录确认后的安排。这样，助手看到改期邮件时，就能把它归入待确认事项；看到负责人同意后，再指出看板还需要同步。

没有约定时，助手应当把两条记录放在一起，说明分歧，交给负责人决定。下面是一个虚构的提醒示例：

客户在今天的邮件中请求将交付改到下周一；项目看板仍为本周五。当前可读取的记录中，尚未找到负责人的改期确认。请确认是否接受请求。

引用来源时，应当给出真实、可打开的链接；只写“客户邮件”或“看板”，负责人仍然无法核对。

这里需要人做决定，而且要求很明确。相比“请持续关注项目风险”，负责人知道自己该回答什么，也能直接打开依据。

没有变化、检查失败和到期，要分开处理

持续运行的助手需要允许安静的结果。如果指定来源检查正常，事情也没有变化，就可以记录检查结果，按约定不再推送一份重复摘要。

但邮箱读取失败时，不能得出相同结论。助手只知道自己没能完成检查，应该保留最近一次成功读取的位置，并说明本次遗漏的来源。恢复访问后，需要补查遗漏期间的记录；如果接口提供增量游标，可以按其约定续读，否则应设计覆盖遗漏时间的查询。不能只查恢复当天，就假定中间没有变化。

Viktor 的自动化悄然失效描述了长期运行的任务失效后很难被察觉。跟进任务也是一样：没有发来提醒时，你应该能查到它上次是否执行过、检查了哪些来源。

还有一种情况，即使没有新消息也需要提醒：约定的期限到了。客户一直没有回复，到了双方约定的跟进时间，这件事就值得再次出现。

因此，提醒可以来自实际变化，也可以来自事先约定的时间条件。任务结束、取消或被负责人接管后，还需要停止相应提醒。否则，一项已经完成的工作仍会每天要求你关注。

OOMOL 为跟进任务提供应用连接

要比较两次检查之间的变化，助手需要读取真实系统里的记录。在 OOMOL 中，Connector SDK 说明了如何选择已授权的连接账号、调用相应的应用操作；网关负责持有凭证并发起实际请求。

例如，为项目跟进连接工作邮箱和项目管理工具，再核对它们是否提供所需的搜索、详情读取和更新时间字段。不同服务的查询范围、历史记录和增量能力各不相同，需要按具体接口确认。

上一次确认的状态、不同来源之间的关联、提醒条件和停止条件，则由助手或业务流程保存和执行。连接成功之后，这些任务规则仍然需要落实。

第一版可以只开放必要的读取操作，把变化报告交给负责人。需要同步看板或回复客户时，再按权限控制指南配置相应操作，并明确执行目标与确认方式。

团队如果需要自己管理连接服务，可以使用 OOMOL 的开源项目 OpenConnector，按自部署指南管理凭据、操作策略和运行记录。

用同一个项目，连续检查两次

可以从 OOMOL Connections 连接任务所需的应用，让支持调用连接能力、能够保存任务状态的助手处理一个范围明确的请求：

帮我跟进这个项目的交付日期和待交材料。先读取指定邮件会话与项目任务，整理当前已确认状态、待确认事项和来源，保存为后续比较的依据。本次只把结果交给我，不修改源系统。下次检查时，说明相对这次发生了什么变化；没有变化时不重复摘要，读取失败时说明缺失。提醒时间与停止条件由我确认后再设置。

第一次检查，核对它是否选对了项目、邮件和负责人。第二次可以用测试材料加入一条重复转发、一项改期请求和一条正式确认，观察助手能否区分三者。再让一个来源暂时不可用，检查它会不会把读取失败说成“没有进展”。

等这些判断符合预期，再安排定时运行。你收到的下一次提醒，就应该能回答一个具体问题：相对上次确认的状态，现在有什么需要你处理？