Bot Token 谁拿着，谁就控制这个机器人
Bot Token 是机器人对外调用 Bot API 的唯一凭证。任何持有令牌的人都能收发消息、改 webhook、读取机器人可见的用户数据。所以交付时不能只问「令牌给了没有」，要问「交付后还有谁手里有旧令牌」。开发方在测试、调试、日志和聊天记录里留下的令牌副本，都算持有。合同或交付清单里应写明：交付完成后开发方不再保留可用令牌，并配合验收时重置。
用重置令牌验收，比口头保证可靠
BotFather 可以重新生成令牌，旧令牌随即失效。建议把它设为验收步骤：买方在自己的 Telegram 账号下操作重置，把新令牌只写进自己的服务器环境变量，再确认机器人在新环境里正常响应，同时确认旧令牌调用返回未授权。这一步能同时验证两件事：买方确实能进入 BotFather 对应的机器人，以及程序没有把令牌写死在开发方控制的地方。另外要核对机器人是由谁的 Telegram 账号创建的。BotFather 提供转移机器人所有权的选项，具体入口和限制以当时界面为准。如果机器人挂在开发方个人账号下，买方即便拿到令牌，管理权也并不完整。
源码交付的范围要写到可复现构建
「交付源码」至少要拆成几项：完整仓库及提交历史或明确的快照、依赖清单与锁文件、环境变量清单（只列名称和用途，不附真实值）、数据库结构与迁移脚本、部署脚本或说明。验收标准建议定为：买方在一台干净环境里，只凭仓库和说明就能构建并启动，不需要向开发方追问。另需约定授权范围：是转让全部权利，还是仅授予使用许可；代码中引用的第三方库和闭源组件，其许可是否允许买方继续使用与修改。这类条款以双方合同为准，不要靠默认理解。
托管归属决定机器人能不能持续在线
托管要分开约定四类资源：服务器或云账号、域名与证书、数据库及备份、监控与日志。最稳妥的做法是这些资源一开始就在买方名下，开发方只获得受限授权。如果由开发方代为托管，应写清托管期限、费用谁付、数据导出方式和迁移配合义务。判断标准很具体：如果开发方明天停止响应，买方是否仍能独立保持机器人运行并取得全部数据。答案是否定的，说明托管归属还没有谈清楚。webhook 地址、反向代理和定时任务也要列入交接，它们常被遗漏，却决定机器人换环境后是否还能收到消息。
机器人调用的其他密钥和账号也要一并交接
机器人往往还接了支付、短信、AI 接口、云存储等第三方服务，密钥通常放在开发方自己的账号里。交付清单应逐项列出这些服务、对应账号的持有人和计费方式，并要求买方用自己的账号重新签发密钥。如果机器人与 Google Play 上的应用联动，例如推送通知、客服入口或登录绑定，还要核对应用侧的开发者账号、服务端回调地址和签名配置是否与机器人使用同一套归属，避免机器人转给买方而应用侧仍指向开发方的服务。涉及开发者账号交接的部分，以平台当时的账号管理页面和规则为准。
验收之后的责任边界要提前写明
交付不等于结束，常见纠纷出在售后。建议约定：验收通过的标志（令牌已重置、买方环境已跑通、开发方访问权限已撤销）、保修期内修复哪类缺陷、新需求如何计费、Telegram Bot API 变动导致的失效由谁处理。停止或换方案的信号也应提前说好：买方无法独立部署、开发方拒绝撤销访问权限，或源码无法在干净环境构建，这三种情况出现任一种，就不应付尾款，应先补齐交接再验收。