如果机器人需要在一条消息中显示可操作的状态卡片，第一步应当是说明用户要完成什么，而不是先要求“把网页塞进 Telegram”。一个明确的状态和两个按钮，可能已经能完成任务；只有信息之间需要更紧密的视觉关系时，才值得评估更复杂的卡片。
Telegram 的 Widgets 官方文档描述了一种消息内交互界面。它和重新发送普通文本有不同的生命周期，选型时尤其需要考虑旧消息和旧界面如何继续工作。以下是基于公开文档的需求设计建议，不是已交付客户案例，也不是 BotFatherV2 已上线的功能公告。
用一个具体任务判断是否需要卡片
假设要做一个个人处理进度查询工具：用户打开某条记录，看当前阶段、上次更新时间，并执行允许的下一步。先把任务缩小到三件事：看懂状态、知道能做什么、确定操作是否完成。
可以按下面的顺序取舍：
- 如果状态只需一行文字、操作只有少数几个固定选项，先做普通消息与按钮。更换界面应带来可验证的收益，例如减少理解错误，而不只是让界面更像网页。
- 如果用户需要在同一张卡片中比较多个状态、看图形反馈，再评估 Widgets。为每个视觉元素写出它帮助用户作出的决定；没有用途的动效可以先删去。
- 如果任务需要长表单、复杂导航或跨页面操作，把它作为独立应用界面的需求评估，不要把全部流程硬压进一条聊天消息。
这些是项目范围的选择建议，不代表任何界面技术已经被当前机器人构建平台支持。
先核对 Telegram 的公开边界
截至 2026 年 11 月 11 日，官方说明中的关键边界是：
- Widget 是消息中的自包含 HTML 界面，在无网络访问的沙箱内运行；它不能自行从外部网站刷新业务数据。
- HTML 在发送后固定，变化的是由机器人写入的状态。修改界面代码需要发送新 Widget，不能假设编辑状态就能更新旧界面。
- 文档明确区分生产与测试环境：当前生产环境仅支持与机器人的私聊；群组、Inline 与转发等更广场景仍需按测试环境说明理解。
- 它不是 Mini App；文档列出的输入不包含键盘。需要用户连续输入文字的任务，应另外设计输入入口。
因此，一个在测试群中演示成功的卡片，不能直接成为“生产群已经支持”的验收证据。项目开始前应写明目标环境、聊天类型和所需客户端，交付时逐一核对。
“保持在最后”要拆成三个不同需求
“让状态一直看得见”并不够具体。至少先区分：
- 用户能重新找到记录入口。
- 卡片内部展开内容时，阅读位置不跳动。
- 聊天持续出现新消息时，某条卡片仍固定显示在视口内。
官方文档说明，CSS 的 position: fixed 参照的是消息气泡，setResizeAnchor 控制的是卡片高度变化时气泡哪一边保持位置。这不能当成“卡片永远置底”或聊天置顶的实现承诺。
需求中可以先规定一个可验收的替代目标：用户执行 /status 后能找到最新有效记录入口；旧入口显示自身状态或清楚说明已被替换。不要把“容易找回”和“始终悬浮”混成同一项功能。
先写状态约定，再设计视觉
在进度卡片这个假设方案中，建议先定义记录标识、状态版本和允许的动作，再画布局。下面的规则是本文建议的业务契约：
- 卡片显示“正在提交”时，只表示请求处理中；只有机器人确认业务状态已更新，才显示完成。
- 旧卡片提交的动作需要重新核对当前状态和操作者资格。按钮仍然可见，不等于该动作现在仍有效。
- 对于没有权限、记录不存在、状态已变化或请求失败，分别给出能理解的结果，不能都画成成功。
- 重开聊天或重新找到旧消息时，能够区分这张卡片展示的是当前状态还是历史快照。需要新鲜度的字段应显示更新时间。
- 如要在不同位置展示同一业务记录，先决定哪些字段可共享、哪些字段仅供当前用户查看，再选择状态组织方式。
这里的独立工作是定义界面与业务记录之间的关系。无需为了卡片选型重新实现一套通用重试或权限系统；已有的按钮动作验收指南可用于检查底层操作。
别把更新机器人当成修好了所有旧卡片
由于界面 HTML 固定，发布计划应包含新旧卡片如何共存。可以先做一份兼容清单：旧界面可能发送什么动作、旧数据缺少什么字段、新后端是否还能理解，以及什么时候明确要求用户打开新版入口。
例如，新版把“处理中”拆成两个阶段时，不应让旧界面把未知状态当成“已完成”。可以设计一个可理解的旧版提示，并保留回到最新记录的入口。这个提示是否能够在旧版卡片显示，必须根据旧代码已有的处理分支验证，不能在发布后才假设它存在。
机器人代码回滚也需要检查旧消息是否仍可使用。回滚代码和替换已经发送的界面是两件不同的发布工作。
一份可编辑的需求和验收清单
下面是待评估方案，不是平台配置说明：
为个人记录设计状态查询界面。第一阶段先交付普通消息与按钮，再单独评估 Widgets。只讨论当前已验证环境，不承诺群组或 Inline 生产支持。每张卡片关联记录和版本，展示状态及更新时间；执行动作前重新检查权限与当前业务状态。处理中、成功、无权限、过期和失败要有不同结果。列出旧界面与新版后端的兼容策略。若当前 SDK 不支持所需方法或事件，保留普通消息方案，不把未支持项标为已完成。
验收时至少记录：
- 目标客户端和真实生产私聊中的首次打开、关闭重开及滚动后找回。
- 新卡片、旧卡片分别对同一记录作操作，结果是否一致且可解释。
- 更新状态时是否仍显示过期值，失败是否误显示为成功。
- 浅色、深色、窄屏和长文本下，关键信息是否可读、动作是否可发现。
- 新增聊天消息后，实际行为是否符合约定，而不是用气泡内布局冒充聊天固定位置。
- 升级与代码回滚后，旧入口、未知状态和不支持的环境是否有明确处理。
这些是待执行测试，本文没有部署或实测 Widget。
BotFatherV2 的关联与下一步
BotFatherV2可通过 AI 对话创建和修改 Telegram 机器人，支持版本发布、导入已有 Telegram Serverless 机器人，以及保留当前业务数据的代码回滚。可以把上面的交互与兼容要求作为需求讨论起点。
但本次公开帮助文档不足以确认其固定 SDK 已支持 Widgets 的发送方法和事件，不能把 Telegram 官方能力写成产品现成功能。任意 npm 模块及 Node/Bun 运行时 API 不在固定校验范围内；AI 辅助开发也不等于生成的机器人具有自主 AI Agent 能力。Widget 在沙箱中不联网，更不意味着机器人后端已经具备某个外部 API 或模型服务。
明确下一步是：先列出所需方法、事件和目标环境，核验 SDK；不满足时继续使用普通消息与按钮，或者单独评估定制实现。BotFatherV2 为独立产品，与 Telegram 官方 BotFather 无隶属关系。
来源与核查日期
- Telegram：Telegram Widgets，英文官方设计与接口文档，未标注固定发布日期，核查于 2026 年 11 月 11 日。生产范围和接口后续可能调整，实施前应重读。
- BotFatherV2：产品主页、使用 AI 开发，同日核验，仅用作产品能力与支持边界证据。