让用户手动输入 @username，并不是选择人员、群组或频道的稳妥方式。用户名并非必填项，也可能发生变化；复制输入容易出错；名称相近的群更容易选错。Telegram 的请求按钮可以让操作人从符合条件的列表中选择，并把结构化的用户或群组信息返回给机器人。
但输入更准确，不代表授权问题已经解决。一次选择只说明这次请求选中了谁或哪个群；它不能证明被选中的用户同意接收消息，也不能证明机器人仍能访问该群，更不能让旧的管理员批准永久有效。
先确定请求用户还是请求群组
python-telegram-bot 的 KeyboardButtonRequestUsers 文档提供普通用户或机器人、Premium 状态等筛选条件，一次最多可选 1–10 个用户，还可以请求姓名、用户名和头像。
KeyboardButtonRequestChat 首先要求区分频道与群组/超级群；可选条件包括是否为论坛群、是否有用户名、是否由请求人创建、请求人和机器人需要的管理员权限，以及机器人是否已在群内。
| 选择类型 | 适合用途 | 不能据此推断 |
|---|---|---|
| 请求用户 | 选择任务负责人、管理员候选人或参与者记录 | 允许联系、订阅或代替对方操作 |
| 请求群组 | 选择某个工作流使用的群组、论坛群或频道 | 永久成员关系、当前权限或发布批准 |
每个按钮只承担一个清楚目的。“选择通知目标群”比一个同时用于发布、导出和管理的通用“选择群组”按钮更容易审核。
用 request_id 把响应对应回原请求
两种请求对象都包含一个有符号 32 位 request_id，同一条消息内必须唯一；共享结果会带回同一个值。它用于关联按钮交互，不是所选用户或群组的身份 ID。
同一条消息里的不同按钮要分配不同 request ID，并保存这次请求的含义：预期选择类型、发起人、工作流记录、创建时间和过期时间。收到响应后，若请求未知、过期、已经使用、发起人不匹配或类型不符，应拒绝处理，不能随手挂到“当前正在进行”的设置流程上。
不要只维护一个全局“最后请求”。两位管理员同时配置不同群组时，不能让后发请求覆盖先发请求的目标。
稳定 ID 与展示字段要分开保存
UsersShared 响应包含 request ID 和被共享的用户序列；ChatShared 包含 request ID、chat ID，以及机器人事先请求时才可能出现的标题、用户名和头像。
用返回的 user ID 或 chat ID 作为身份主键；姓名、标题、用户名和头像只作为可选的展示快照。它们可能为空，也可能稍后改变，不能替代稳定 ID 用于所有权、去重或路由判断。
chat ID 可能超出有符号 32 位范围；上述文档建议使用能够安全容纳有符号 64 位整数的存储。不要把它塞进过窄的数据库列，也不要经过可能丢失精度的客户端格式。
只请求当前流程真正需要的字段
任务分配可能只需要用户 ID 和展示名，不需要头像；目标群确认可能需要群标题，但不需要公开用户名。逐项决定可选字段，并告诉操作人将保存什么。
保留周期也要最小化。如果标题或头像只用于一次确认页面，就先判断是否有必要长期写入业务存储。不要默认把完整选择响应复制到群日志或客服工单。
按下按钮的人同意在这次交互中向机器人分享信息，不等于被选择的人同意营销订阅，也不授权机器人把结果公开到其他聊天。
执行业务动作前重新检查权限
筛选条件能减少错误选择，却不能成为永久权限缓存。选择完成后到实际执行前，请求人可能失去管理员权限，机器人可能被移除，工作流保存的目标也可能已经改变。
在执行敏感动作前，复核当前接口确实能够核验的事项：发起人仍拥有设置会话，请求尚未消费，选择结果与预期记录一致，当前所需访问权限仍然存在。如果固定 SDK 无法核验某项权限或无法接收这种选择更新，就停在清晰的人工确认步骤，而不是显示“自动配置成功”。
群发或发布还应增加单独确认页，展示目标和即将执行的动作。仅仅选择成功，绝不能直接发送消息。
可以直接交给 AI 的需求模板
为社群助手增加一个私聊设置流程。维护者可以选择一名普通用户作为管理员候选人，或选择一个群组/超级群作为工作流目标。两类选择使用独立按钮和唯一 request ID，并绑定维护者及设置记录。保存稳定的 user/chat ID；请求到的姓名、用户名和群标题只用于确认。拒绝未知、过期、重复、跨用户或类型不符的响应。选择用户不代表对方订阅消息，选择群组也不得自动发布。保存目标前，重新核验固定 SDK 支持的当前成员与管理员条件，并让维护者确认。如果当前 SDK 无法处理 request-user/request-chat 更新，应明确报告限制，并退回到带清晰人工核验步骤的流程。
第一版只做选择与确认。定时任务、群发或外部服务应在分别核实支持范围和授权规则后再添加。
发布后的验收清单
- 同一条消息里的两个请求按钮具有不同 request ID，并分别对应正确动作；
- 两位维护者可同时设置，不会串用户、群组或工作流记录；
- 过期或重复提交的共享响应不会修改数据；
- 用户选择结果不能满足等待中的群组请求，反过来也一样；
- 用户名或群标题变化不会创建第二条身份记录；
- 大数值 chat ID 写入并读出后完全一致；
- 姓名、用户名、标题或头像为空时，流程仍按约定运行；
- 选择后、确认前失去必要权限时，进入可审核的失败状态，而不是显示成功；
- 选择人员不会发送未经同意的消息，选择群组也不会发送未经确认的内容。
这些是应在测试机器人和受控群组中执行的建议用例，并不代表生成的机器人已经通过测试。
与 BotFatherV2 的关系和边界
BotFatherV2通过 AI 对话帮助创建和修改 Telegram Serverless 机器人。生成版本前，应把选择类型、关联规则、存储字段、权限复核和失败处理完整写进需求确认卡。
公开使用 AI 开发文档说明，校验器使用固定 SDK 范围，不支持任意 npm 模块或 Node/Bun 运行时 API。本文引用的框架资料用于解释 Telegram 数据语义，不代表平台安装了这些框架，也不代表当前 SDK 已支持所有字段。
AI 辅助开发也不会让发布后的机器人自动获得自主 Agent 能力。BotFatherV2 是独立产品，与 Telegram 官方 BotFather 无隶属关系。请审查生成源码和验证报告，并在发布后到真实 Telegram 中测试选择更新及当前权限。
来源与核验说明
- python-telegram-bot 项目：KeyboardButtonRequestUsers，v22.8 英文参考文档，页面未标注独立发布日期；
- python-telegram-bot 项目：KeyboardButtonRequestChat，v22.8 英文参考文档，页面未标注独立发布日期；
- python-telegram-bot 项目：UsersShared，v22.8 英文参考文档，页面未标注独立发布日期；
- python-telegram-bot 项目：ChatShared，v22.8 英文参考文档，页面未标注独立发布日期。
以上四页均于 2026 年 10 月 23 日核验。本文将类型定义整理为原创的设置、授权、数据最小化与验收清单，不把抓取日期写成新功能发布日期。