在钉钉里用 GoWork 做定时提醒和自动跟进

如果你的目标只是“在钉钉里定个时间，到点提醒我一下”，那日历、待办或普通机器人已经能做一部分。但如果你的目标是在钉钉里直接交代一件事，让系统在稍后自动提醒、持续检查、按条件跟进，并把结果再送回原来的聊天，那你真正需要的不是一个会发消息的 Bot，而是一套带执行能力的定时任务系统。

这正是 OmniGoAI 的 GoWork 在解决的问题。GoWork 可以把钉钉消息当成任务入口，把自然语言里的“明天早上提醒我”“每 10 分钟检查一次”“如果还没人回复就再跟进”翻译成后台任务，再由助理继续执行并回传结果。对团队协作来说，这意味着钉钉不再只是消息入口，而是提醒、执行和自动跟进的统一界面。

如果你已经看过 把 AI 助理接进钉钉/飞书/Telegram：GoWork 助理实践 和 用 GoWork 定时任务做巡检、日报和自动跟进，这篇文章会把场景再收窄一步：当入口固定是钉钉时，什么样的定时提醒和自动跟进才真正有用？

先说结论：钉钉里的“定时提醒”一旦要跟工作流连接，就不只是提醒

很多团队说“想在钉钉里接个 AI，顺便做定时提醒”，真实需求通常不是单纯的闹钟，而是下面几类：

1. 每个工作日早上 9 点把未完成事项摘要发到钉钉会话；
2. 每天下午 6 点提醒我跟进还没回复的客户或同事；
3. 每 10 分钟检查一次某个页面、表单或工单状态，有变化再通知我；
4. 某个后台任务做完后，自动回到原来的钉钉聊天里汇报结果。

这几类需求的共同点是：时间只是触发器，真正的价值在于到点后系统会不会先做一轮事。如果工具只能到点吐一句固定文案，那你还是要自己打开页面、查状态、想下一步。对团队来说，这类“提醒了但没推进”的自动化很快就会失去吸引力。

所以在钉钉里做定时任务，最实用的思路不是“把提醒搬进聊天”，而是“把定时触发接到执行层后面”。

为什么很多钉钉机器人做了提醒，却还是不好用？

因为它们只覆盖了最前面的一步：到点发消息。

一个最基础的钉钉机器人通常可以做到：

• 收到指令；
• 记录一个时间；
• 到点往群里或私聊里发一段文本。

但真实工作里更常见的是：

• “明天上午提醒我确认审批，如果还没过就顺手催一下”；
• “每个工作日 9 点发一版待办摘要，不要只发一句‘记得看待办’”；
• “盯着发布状态，一完成就通知这个会话”；
• “今晚 8 点提醒我复查，如果已经有人回复就别提醒了”。

这些需求都依赖三层能力：

1. 检查状态：到点后先看审批、工单、页面或消息有没有变化；
2. 保留上下文：知道当初盯的是哪件事、该回到哪个会话；
3. 继续行动：命中条件后总结、回传，必要时停止后续轮询。

也就是说，真正好用的钉钉定时任务，不该只是会发提醒，而应该会先执行、再回传结果。

在钉钉里，哪些需求最适合先交给 GoWork？

1. 固定时间的提醒和摘要

这是最容易落地的一类，例如：

• 每晚 8 点提醒我回顾今天待办；
• 每周一 9 点把本周重点任务列出来；
• 每个工作日下午 5:30 提醒我检查还有哪些事项没收口。

这类需求看起来简单，但只要你希望它输出的不是一句空提醒，而是一版当前状态摘要，它就已经从“提醒工具”升级成“定时执行任务”。

2. 自动跟进

这是钉钉场景里特别高频的一类。

例如：

• 今天下午 6 点如果对方还没回我，就提醒我跟进；
• 领导还没批这条审批的话，晚点再催一次；
• 某个需求提了以后，如果 24 小时没人认领，就回到群里提醒。

这类场景的难点不在“几点提醒”，而在“到点时系统要先判断现在还需不需要提醒”。一旦能做这层判断，钉钉里的自动跟进就比单纯的闹钟有价值得多。

3. 周期巡检和状态观察

很多团队希望直接在钉钉里说：

• “每 10 分钟看一次这个页面，有变化就告诉我”；
• “每小时检查一次日志里有没有新的 ERROR”；
• “盯着这个任务状态，一完成就通知我”。

这类需求表面上像提醒，实质上更接近轻量监控。它们的核心不是“按时说一句话”，而是“按频率去看真实状态”。GoWork 这类助理式系统的优势就在这里：它能把聊天里的自然语言，转成真正会执行的周期任务。

为什么“每天几点”和“每隔几分钟”在钉钉里不能混着理解？

这是设计定时任务时最容易踩的坑之一。

“每天早上 9 点发我一版摘要”强调的是固定钟点；“每 10 分钟检查一次有没有更新”强调的是固定频率。两者看起来都带时间，但背后是两种完全不同的任务模型。

它们分别适合：

1. 固定钟点：日报、早晚提醒、班次交接、下班前汇总；
2. 固定频率：网页观察、工单状态轮询、任务完成等待、条件命中后通知。

如果把“盯着某个状态”错误地做成“每天提醒一次”，表面上像有自动化，实际上等于没盯住。反过来，如果本来只是每天固定发送摘要，却做成“从现在起每隔 6 小时一次”，触发时间又会漂移，团队也很难形成稳定预期。

所以一个真正可用的钉钉定时系统，必须能区分“固定几点”和“按频率轮询”这两类表达。

把定时任务接进钉钉后，团队为什么更容易真正用起来？

因为钉钉本来就是很多团队日常协作的主入口。

一旦定时任务的创建、触发和回传都发生在钉钉里，会带来三个直接变化：

• 任务入口更顺手：用户直接在聊天里说出需求，不必切到另一个后台；
• 结果更容易被看到：提醒、摘要和状态回传都回到原会话，不会散落在别的系统；
• 上下文更少丢失：谁交代的、在说哪件事、结果该发回哪里，都能沿着会话继续保留。

这也是为什么很多团队不是缺一个“提醒能力”，而是缺一个能把提醒嵌进现有协作流的执行层。钉钉负责入口和触达，助理负责理解与执行，两者接上以后，自动化才会从工具层进入团队日常。

做钉钉定时任务时，最容易踩的三个坑

坑 1：只记时间，不记对象和上下文

比如用户说“明天下午提醒我跟进那个审批”，如果系统只记住“明天下午提醒”，却没记住“那个审批”具体指什么，到点后的提醒就会变成一句失去上下文的废话。

真正可用的做法，是让任务不仅保存时间，还保存任务对象、来源会话和后续动作。

坑 2：把监控类需求做成普通提醒

“有变化再告诉我”“一旦完成就通知我”“每隔几分钟看一下”这些都不是普通提醒。它们的本质是轮询任务或条件监控。如果只做成固定时间提醒，用户会以为系统在盯，实际上根本没有观察任何状态。

坑 3：结果没有回到发起任务的钉钉会话

很多所谓自动化在技术上已经“跑了”，但结果留在另一个后台页面，或者一个平时没人看的日志界面里。对团队成员来说，这等于没做。

钉钉场景里最重要的一点，恰恰是形成闭环：在钉钉里交代 → 后台继续执行 → 结果回到原钉钉会话。没有这一步，定时任务很难真正被当成协作工具来依赖。

如果你第一次把 GoWork 用在钉钉里，最值得先自动化什么？

最稳妥的起点通常有三类。

第一类：每日固定摘要

例如未处理待办、工单汇总、审批清单、发布复查提醒。这类任务结果清晰、重复度高，最容易快速建立信任。

第二类：低风险状态检查

例如页面能不能打开、某个状态有没有变化、某个任务是否完成。这些判断规则明确，非常适合先自动化。

第三类：容易忘但需要按时跟进的事项

例如催办、回访、审批复查、值班确认。它们不复杂，但特别容易因为忙而被推迟；一旦交给定时系统，收益通常很直接。

一个实用判断：你要的是“钉钉提醒”，还是“钉钉里的自动执行”？

可以直接问自己 5 个问题：

1. 到点后，系统是否需要先检查状态？
2. 这件事是否依赖当前会话的上下文？
3. 条件命中后，系统是否需要自动总结、通知或停止轮询？
4. 结果是否必须回到原来的钉钉聊天？
5. 这类事情是否会重复出现，而且手工执行很容易漏掉？

如果其中有 2~3 条答案是“是”，那你真正需要的通常已经不是普通提醒，而是能在钉钉里持续执行的 AI 助理。

常见问题

FAQ 1：在钉钉里做定时任务，和普通机器人提醒有什么差别？

普通提醒更像“到点喊一声”；GoWork 更适合“到点先做一轮，再把结果发回来”。当任务依赖检查、上下文和回传时，这个差异会非常明显。

FAQ 2：哪些钉钉场景最适合先用定时任务？

通常是每日摘要、低风险状态检查，以及需要按时跟进但容易忘的事项。这三类最容易看见自动化的实际收益。

FAQ 3：为什么很多团队做了提醒却还是觉得不好用？

因为它们只实现了“定时发消息”，没有实现“定时执行并回传结果”。提醒本身不是终点，闭环执行才是价值所在。

FAQ 4：GoWork 适合拿来做钉钉里的监控型任务吗？

适合，但前提是把需求按“轮询/观察状态”来设计，而不是误写成固定时间提醒。凡是“一旦发生就告诉我”“每几分钟看一次”的需求，都更接近执行型定时任务。

如果你想让钉钉里的 AI 不只是“会回话”，而是“会记得、会按时做、会把结果带回来”，那关键就不是多接一个机器人接口，而是把聊天入口、定时调度和执行层接起来。想亲自试试，可以从 GoWork 下载页 开始，再结合 GoWork 助手能力文档 看看它已经能接手哪些提醒和自动跟进任务。