先写清机器人在哪里被触发，再谈功能
同一个机器人在私聊、群组和频道里的行为差别很大。私聊里用户必须先发起对话或点击 Start，机器人才能给他发消息，所以「主动通知所有人」这类需求要先问清用户从哪里进入。群组里要确认机器人是否是管理员、是否需要读取全部消息；默认的隐私模式下，机器人只能收到命令、对它的回复和提及它的消息，需求依赖关键词监听时必须提前说明。需求文档第一页建议只写三件事：使用场景（私聊、群、频道、Mini App 入口）、角色（普通用户、管理员、运营）、每个角色能触发的命令或按钮。
流程按状态写，不要按功能名罗列
「支持下单」「支持查询」只是功能名，开发和验收都没法对齐。更可用的写法是状态表：当前状态、用户输入、机器人回复、下一状态、失败时去哪里。例如下单流程至少要写明用户中途退出、重复点击、超时未支付、输入格式错误四种分支。还有一个技术原因要提前知道：内联按钮的 callback_data 有长度限制（官方文档标注为 1 到 64 字节），复杂上下文不能塞进按钮里，必须由服务端保存会话状态。因此状态数量和分支数量，比「功能点个数」更接近真实工作量，也是报价和变更时更合理的计量依据。
数据要写明存什么、谁拥有、保留多久
至少列出四类：用户标识（建议以 Telegram 的数字 user id 为主键，用户名可以修改，不适合当唯一标识）、业务数据（订单、积分、工单等）、消息与日志、第三方凭据（支付、API Key、云服务密钥）。每一类写清存放位置、谁有读取权限、保留多久、能否导出和删除。如果需求涉及用户资料或支付信息，还要确认是否有所在地区的合规要求，这部分属于你的业务责任，开发方只能按你给出的规则实现。数据库和服务器账号应登记在甲方名下，开发方使用子账号，避免交付后数据只能向开发方索取。
机器人令牌和部署环境的归属必须在交接清单里
机器人由 BotFather 创建，令牌等同于控制权。需要确认：机器人由谁的 Telegram 账号创建，令牌由谁保管，开发期间是否使用测试机器人、上线时是否更换令牌。令牌一旦出现在聊天记录、代码仓库或截图里，就应当在 BotFather 里重新生成。部署方面要写明接收更新的方式（webhook 或长轮询，二者不能同时使用）、服务器与域名由谁采购、HTTPS 证书谁续期、日志放哪里、崩溃后如何重启。交接清单建议包含：源码仓库、环境变量清单、部署步骤、数据库结构、第三方账号列表，缺任何一项，后续换人维护都会出问题。
验收条目要能被复现，也要写明不包含什么
可验收的条目由三部分构成：前置条件、操作、预期结果，例如「新用户首次点击 Start，收到欢迎语并看到三个菜单按钮」。除了正常路径，还要覆盖异常输入、权限不足、第三方接口失败时的提示。性能类要求要给出可测的数字，比如多少人同时操作、回复延迟上限，并说明测试环境。Telegram 对发送频率有限制（具体数值以官方文档为准），群发类需求要在验收里注明限速与失败重试的处理方式。同样重要的是排除项：多语言、管理后台、数据报表、后续平台规则变化带来的改动，是否包含在本次范围，要明确写出。
什么情况下应先缩小范围或暂停定制
出现以下任一情况，建议先把需求拆成可验证的第一期，而不是直接定制全量：状态流程说不清楚，只能用「类似某某机器人」描述；依赖的第三方接口还没有开通或没有文档；数据归属和令牌保管没有明确负责人；验收只写「运行稳定」「体验良好」。另外，向未授权用户批量私信、抓取他人群成员信息、规避平台限制这类需求，既可能违反 Telegram 的规则，也会让机器人随时被限制，不应作为定制范围。第一期做小、验收清楚，再按已跑通的流程追加功能，通常比一次性交付大而全的方案更可控。