我为 Developers Map 的支持流程构建了 Telegram 机器人、Mini App 和客服操作界面。其中一个任务是：当请求重复，或 Telegram 已接受回复但程序没有收到确认时，仍能保留工单状态。

请求可能重复，客服可能再次点击按钮，Telegram 也可能接受了消息，但连接在程序得知成功之前中断。同时，用户又在同一个聊天里开了第二张工单。不需要任何恶意：普通网络连接自己就能制造一场小危机。

从菜单到工作流程

我为 Developers Map 构建了 Telegram 机器人、Mini App 和客服支持界面。它是主服务旁边的一套独立工具；这不意味着我是 Developers Map 的作者，也不赋予机器人修改主平台用户账户的权限。

这个页面使用预先准备的工单，展示原始支持界面。它让人看到机器人旁边的工作区，而不只是机器人的菜单。

支持概览

归档界面 · 演示数据

支持概览
已保存的项目画面 · 无交互控件

系统具备俄语和英语的已确认答案库、单个聊天内的多张工单，以及保存在私有 R2 中的附件。此实现关闭了 AI 回复。用户得到的是可预期的支持，而不是模型自由编写别人产品的工作方式。

工单里展示了一段演示对话。可以测试可用的本地客服操作；真实 Telegram 用户不会收到来自这个演示的任何内容。

工单对话

归档界面 · 演示数据

工单对话
已保存的项目画面 · 无交互控件

先记录事件，再执行操作

传入事件保存在 D1 中。队列和定时处理器将它们送到 Durable Objects 上的聊天协调器。随后引擎更新工单状态，并把待发出的操作写入 outbox，即准备发送内容的表。

这样就可以在一次数据库操作中，把工单变更与发送消息的意图绑定起来。否则可能出现一种奇怪的中间状态：消息已经发给了对方，系统却仍认为什么都没发生。也可能正好相反。

Mini App 命令拥有稳定标识符和版本检查。重复请求会被识别；基于旧状态执行的操作，不应悄悄覆盖客服较新的工作。

最值得关注的状态是“结果未知”

如果外部发送可能已经发生，自动重试就可能造成重复。因此，不确定的结果不能被当成需要立即重试的普通错误。这种情况下，重试是客服在理解风险后作出的独立决定。

这不是对数学意义上完美送达的承诺，而是一种不再把不确定性藏在绿色指示灯后面的办法。

可运行实例已为试点部署；完整的用户验收仍是独立阶段。WhatsApp 和电子邮件不会因为曾出现在计划里，就自动成为已接通的渠道。

可运行实例已为试点部署。演示可以从工单列表进入客服对话；完整的用户验收尚未完成。WhatsApp 和电子邮件未接通，此实现关闭了 AI 回复。

相关故事：Developers Map 产品概念。