--- author: OOMOL author_url: https://oomol.com/zh-cn/about/ datePublished: 2026-10-15 title: 让 AI 持续跟进项目，怎样少发重复提醒，又不漏掉变化？ description: 持续跟进的难点，是相对上次确认的状态说清发生了什么。以项目交付为例，说明助手要保留哪些状态、怎样区分新消息与真实变化，以及没有变化、检查失败和到期时该分别报告什么。 lang: zh-CN canonical_url: https://oomol.com/zh-cn/blog/ai-follow-up-changes/ markdown_url: https://oomol.com/zh-cn/blog/ai-follow-up-changes.md --- ![日历保留已确认的周五交付，改到周一的请求仍待决定](/blog/ai-follow-up-changes/zh-cn-cover.webp) *AI 生成的概念插图，内容为假设示例。* 假设你让 AI 帮忙盯着一个周五交付的项目。周一，它提醒客户还没确认材料；周二，它又发来几乎相同的摘要。到了周三，客户已经在邮件里提出延期，项目看板却仍然写着周五交付。助手把两个日期都放进了报告，最后建议你“持续关注”。 你还是得打开邮件，查看看板，再问一次负责人。 持续跟进需要保留上一次的判断，并说明这一次有什么变化。如果每次运行都重新概括全部材料，助手很容易把旧消息写成新进展，也可能把尚未确定的提议当作已经生效的安排。 ## 一次摘要之后，还需要留下什么 跨应用整理信息的尝试已经不少。Composio 的[家庭日报案例](https://composio.dev/blog/building-a-daily-family-newspaper)把日历、天气和趣味内容组成一份当天的小报；Lindy 的 [AI teammate 介绍](https://www.lindy.ai/blog/ai-teammate)讨论了持续上下文与主动跟进。这些内容说明当天的信息可以整理成什么，但没有回答一个更具体的问题：连续两次检查之间，应该保留哪些已经确认的判断。 一份当天摘要帮助你了解眼前的安排；一项持续跟进的任务，还需要解释事情相对上一次发生了什么。 以项目交付为例，第一次整理完材料后，值得留下的内容很少：当前确认的交付日期、仍在等待的材料、负责跟进的人，以及支持这些判断的来源。还要记下这次检查覆盖到什么时间，哪些来源没有读到。 这份记录就是下一次检查的起点。它可以保存在应用数据库、任务记录或一份受控文档中，具体形式由助手系统决定。重要的是后续运行确实能读到它，并且知道其中哪些内容已经确认，哪些只是推测。 如果上一次只有一句“项目进展正常”，下一次就很难解释到底哪里变了。 ## 新消息不一定意味着事情有了进展 同一份材料被转发到群里，邮箱里多了一封“收到，谢谢”，看板上有人修改了任务描述。这些都是新记录，但对交付的影响不同。 可以围绕任务关心的事实做比较。对于这个项目，你真正需要知道的是：材料是否齐备，交付日期是否改变，谁接下了待办，以及是否出现新的阻塞。 下面是一组假设情况： | 本次读到的内容 | 应怎样理解 | 适合怎样提醒 | | --- | --- | --- | | 同事转发了周一的材料请求 | 同一事项，尚无新的交付信息 | 不重复推送同一条提醒，到期仍提醒 | | 客户发来了此前缺少的附件 | 材料已收到，是否满足要求仍需检查 | 说明收到什么、还缺什么 | | 客户询问能否改到下周一 | 出现了改期请求 | 标为待决定，保留当前确认日期 | | 负责人明确同意改期 | 出现新的确认记录 | 说明原日期、新日期和确认来源 | 识别同一条记录，可以使用源系统提供的标识；判断不同记录是否描述同一件事，还需要结合项目、参与人和内容。仅凭标题相同，无法可靠地把两封邮件合并。仅凭文字不同，也不应认为项目又向前推进了一步。 已经明确的字段适合直接比较，需要理解语义的地方再交给模型。比如先找出日期字段发生变化的任务，再让 AI 阅读相关讨论，解释这次变化是否已经得到确认。 ## 邮件和看板不一致时，把分歧留下来 周三的邮件提出下周一交付，看板仍然写着周五。哪一个才算数？ “更新得更晚”只能说明记录时间，不能说明发言人有权改变安排。邮件可能是一项请求，看板可能尚未更新，也可能只是引用了另一项任务的日期。 团队可以提前约定依据。例如，交付日期以指定负责人的确认为准，看板用于记录确认后的安排。这样，助手看到改期邮件时，就能把它归入待确认事项；看到负责人同意后，再指出看板还需要同步。 没有约定时，助手应当把两条记录放在一起，说明分歧，交给负责人决定。下面是一个虚构的提醒示例： > 客户在今天的邮件中请求将交付改到下周一；项目看板仍为本周五。当前可读取的记录中，尚未找到负责人的改期确认。请确认是否接受请求。 引用来源时，应当给出真实、可打开的链接；只写“客户邮件”或“看板”，负责人仍然无法核对。 这里需要人做决定，而且要求很明确。相比“请持续关注项目风险”，负责人知道自己该回答什么，也能直接打开依据。 ## 没有变化、检查失败和到期，要分开处理 持续运行的助手需要允许安静的结果。如果指定来源检查正常，事情也没有变化，就可以记录检查结果，按约定不再推送一份重复摘要。 但邮箱读取失败时，不能得出相同结论。助手只知道自己没能完成检查，应该保留最近一次成功读取的位置，并说明本次遗漏的来源。恢复访问后，需要补查遗漏期间的记录；如果接口提供增量游标，可以按其约定续读，否则应设计覆盖遗漏时间的查询。不能只查恢复当天，就假定中间没有变化。 Viktor 的[自动化悄然失效](https://viktor.com/blog/why-automations-die-quietly)描述了长期运行的任务失效后很难被察觉。跟进任务也是一样：没有发来提醒时，你应该能查到它上次是否执行过、检查了哪些来源。 还有一种情况，即使没有新消息也需要提醒：约定的期限到了。客户一直没有回复，到了双方约定的跟进时间，这件事就值得再次出现。 因此，提醒可以来自实际变化，也可以来自事先约定的时间条件。任务结束、取消或被负责人接管后，还需要停止相应提醒。否则，一项已经完成的工作仍会每天要求你关注。 ## OOMOL 为跟进任务提供应用连接 要比较两次检查之间的变化，助手需要读取真实系统里的记录。在 OOMOL 中，[Connector SDK](https://oomol.com/zh-cn/docs/connector-sdk/) 说明了如何选择已授权的连接账号、调用相应的应用操作；网关负责持有凭证并发起实际请求。 例如，为项目跟进连接工作邮箱和项目管理工具，再核对它们是否提供所需的搜索、详情读取和更新时间字段。不同服务的查询范围、历史记录和增量能力各不相同，需要按具体接口确认。 上一次确认的状态、不同来源之间的关联、提醒条件和停止条件，则由助手或业务流程保存和执行。连接成功之后，这些任务规则仍然需要落实。 第一版可以只开放必要的读取操作，把变化报告交给负责人。需要同步看板或回复客户时，再按[权限控制指南](https://oomol.com/zh-cn/docs/access-control/)配置相应操作，并明确执行目标与确认方式。 团队如果需要自己管理连接服务，可以使用 OOMOL 的开源项目 [OpenConnector](https://openconnector.io/)，按[自部署指南](https://oomol.com/zh-cn/docs/openconnector-self-hosting/)管理凭据、操作策略和运行记录。 ## 用同一个项目，连续检查两次 可以从 [OOMOL Connections](https://console.oomol.com/connections) 连接任务所需的应用，让支持调用连接能力、能够保存任务状态的助手处理一个范围明确的请求： > 帮我跟进这个项目的交付日期和待交材料。先读取指定邮件会话与项目任务，整理当前已确认状态、待确认事项和来源，保存为后续比较的依据。本次只把结果交给我，不修改源系统。下次检查时，说明相对这次发生了什么变化；没有变化时不重复摘要，读取失败时说明缺失。提醒时间与停止条件由我确认后再设置。 第一次检查，核对它是否选对了项目、邮件和负责人。第二次可以用测试材料加入一条重复转发、一项改期请求和一条正式确认，观察助手能否区分三者。再让一个来源暂时不可用，检查它会不会把读取失败说成“没有进展”。 等这些判断符合预期，再安排定时运行。你收到的下一次提醒，就应该能回答一个具体问题：相对上次确认的状态，现在有什么需要你处理？