读书会把“书籍推荐”和“线下活动”分成两个话题。成员在活动区查询报名，机器人却把结果发到推荐区，或者发进 General。消息成功送达了群组，不代表送达了正确的话题。
这篇文章讨论超级群论坛中的回复目的地，不讨论私聊机器人如何组织长任务。先把“发到哪个群”和“发到群里的哪个话题”写成两项可检查的要求，再考虑新增功能。
群组、话题和消息，是三个不同的定位信息
aiogram 的 sendMessage 文档将目标聊天与 message_thread_id 分开列出；后者用于指定论坛话题。它还单独列出 direct_messages_topic_id，不要把不同聊天形态的字段互换。
给实现者的需求至少应区分这三项：
| 信息 | 本例中的职责 | 不能代替什么 |
|---|---|---|
| 聊天标识 | 定位读书会所在的超级群 | 不能单独决定回复落在哪个话题 |
| 话题标识 | 在该群中定位活动区 | 不能用话题名称或其他群的编号替换 |
| 原消息标识 | 记录本次请求，或在需要时引用它 | 不是任意情况下都能充当目标话题编号 |
python-telegram-bot 的 ForumTopic 文档同样区分话题标识和名称。因此，一个合理的业务设计是按“聊天标识 + 话题标识”保存普通话题的路由关系，名称只用于显示和人工核对。把“线下活动”改名成“十月活动”，不应自动新建一套报名数据。
这里的组合键是设计建议，不是要求安装某个框架，也不表示话题本身是权限隔离区。成员能否查询名单，仍需另行授权。
General 要单独约定，别靠猜编号修复
Telegram 的 Forum topics 文档说明，每个论坛都有特殊的 General 话题，普通话题也可以暂时关闭。该页属于 Telegram 原生 API（MTProto）文档，不是可以直接粘贴到 Bot API 或 Serverless SDK 的调用示例。
尤其不要看到原生 API 文档中的 General 编号为 1，就把每一次缺失的话题字段都补成 message_thread_id = 1。应先确认当前接口与 SDK 如何表示 General，以及发送方法如何选择目标。
需求可以明确两种情况：在 General 发起的请求按已验证的 General 发送方式回复；已知来自普通话题、却没有取得可用路由信息的请求，按路由异常处理。不要把“目标信息丢了”悄悄解释成“用户想去 General”。
回复目标跟随这次请求，不跟随最新消息
设想成员先在活动区发出查询，随后又在推荐区发了另一条消息。如果机器人把“群里最后活跃的话题”保存成全局变量，稍后完成的查询就可能跟着第二条消息走。
建议在接收请求时保存该次处理所需的目标上下文，并让对应输出使用这份上下文。需要持久化的处理，则应评估当前存储是否能保存必要的路由信息；不要假设下一次执行还能读取同一进程的内存。
排查时可以使用一份不含成员正文的记录：请求编号、目标聊天、目标话题类型、普通话题标识、发送结果。先比对输入与输出的目的地，不要一开始就导出全部群聊内容。也不要让维护者在公开群发送机器人令牌作为排查材料。
目标不可用时，不要自动改发到另一个区
话题被关闭、删除或发送失败时，机器人需要明确的业务策略。下面是推荐的安全默认值，而不是对 Telegram 错误码或事件覆盖率的保证：暂停这次输出，记录目标和失败类型，交由有权限的维护者核对；不要自动换到 General，也不要根据相同名称猜另一个话题。
如果业务确实需要备用目的地，应提前由管理员配置并确认可见范围。比如允许把不含个人信息的故障摘要发到运维区，不等于允许把报名名单转发过去。恢复后也要重新核对路由，不能只以“终于发送成功”为验收结果。
给 AI 的需求可以这样写
创建一个读书会论坛群助手。第一版只在一个获准的超级群中处理 /status，返回固定的活动状态文案，不需要外部 API 或付费 AI。普通话题中的请求必须回复到原话题；General 使用当前 SDK 已验证的发送方式。目标上下文按请求保存，不使用最后活跃话题。话题改名不改变已有绑定。已知来自普通话题但路由缺失，或者目标不可用时，不得改发到 General；保留最少故障信息供管理员检查。先确认当前 SDK 能接收并发送话题上下文；若不能，明确说明，缩小为已验证的单一聊天入口，不假装支持多话题。
固定状态文案可以先验证路由，不必为了测试目的地而接入报名数据库。路由验收通过后，再单独说明真实数据的查询范围和授权规则。
发布后按这些情况验收
- 在同一群的话题 A、B 交叉发送请求，逐条核对回复目的地。
- 在两个测试群中使用相似名称的话题，确认不会跨群匹配。
- 给话题改名后再次请求，路由不因显示名称变化而失效。
- 在 General 和普通话题分别测试，确认实现没有盲目补编号。
- 在管理员可控的测试环境中关闭话题，或测试失效绑定；失败输出不会转移到其他区。
- 对需要跨执行保存目标的流程，检查重新执行及发布兼容版本后仍使用正确上下文；无法保留时明确失败，不猜测目的地。
这些是建议执行的真实 Telegram 测试，不代表本文已经替你的机器人做过验证。
与 BotFatherV2 的关系和边界
BotFatherV2支持通过 AI 对话创建和修改机器人，适合把上面的路由规则整理进需求确认卡。是否支持话题字段与发送方式，必须检查当前固定 SDK、生成报告和发布后的真实行为；本文引用框架文档不表示平台会安装这些框架。
2026 年 10 月 20 日核对的公开开发文档仍说明：不支持任意 npm 模块或 Node/Bun 运行时 API，首版不新增依赖付费 AI 的机器人运行能力。AI 辅助开发不等于运行时自主智能体。BotFatherV2 是独立产品，与 Telegram 官方 BotFather 无隶属关系。
来源与核验说明
- Telegram：Forum topics，英文官方原生 API 文档。
- aiogram 团队：sendMessage，英文文档，读取时显示 3.31.0。
- python-telegram-bot 项目：ForumTopic，英文文档，读取时显示 22.8。
- BitBear Studio：使用 AI 开发，中文产品边界说明。
以上页面均于 2026 年 10 月 20 日核验，未明确标注单页发布日期，不作为当日新功能资讯。另在本次核验中，产品的 /en-US 地址返回 404；英文读者可使用当前可访问的英文首页和英文开发文档。