Python Telegram 机器人开发：ptb v20+ 异步架构与 FSM

没有对话，只有更新

你的程序是一个被片段调用的函数：有人发了这段文字，有人按了那个按钮，有人加入了这个群组。每次调用到来时，都不记得之前发生过什么。

因此，一切感觉像对话的东西，都是你保存的状态，以某个人和某个聊天为键，在每个片段开始时读取。“先问名字，再问地址”并不是你代码里的一个序列——而是一条写着这个人正处在问地址这一步的备注，被写下来，并在他的下一条消息到来时被查出来。

这就让那条备注的存放位置成为第一个架构决策，也是最常被无意中做出的决策。把它放在内存里也是一个决策，即使它是默认行为，其后果见下面的测验。

先设计死胡同

一个感觉完整的机器人和一个感觉坏掉的机器人之间的差别，几乎从来不在顺利路径上——顺利路径第一个下午就能跑通。差别在于其他所有情况，而有四个地方人们会留下未定义的行为。

每一步的意外输入。你要求输入一个数字，却收到一张照片、一个贴纸、一篇小作文，或者一个“hi”。每一步都需要一个回复来说明想要什么，因为替代方案是沉默，而沉默会被读作失败。

从每个状态都能逃出去。一个在任何地方都始终有效的命令，并且要说明这一点。人们经常半途放弃；没有出路，他们就会困在一个自己不再想要的表单里，而他们能找到的唯一补救办法就是拉黑机器人。

过期的按钮。总会有人按下三个月前某条消息上的按钮，那是一个已经不存在的流程，甚至可能是在你的机器人被重写之后。那次按下会像其他任何更新一样到达，应当给出一个解释而不是报错——并且应该编辑那条消息，让过期的按钮不再诱人。

超时。一段半途而废的对话应该过期，而不是永远搁在那里，既因为这个人已经走开了，也因为一条没有终点的状态记录是一个小泄漏，会变成大泄漏。

失败看起来像什么都没发生

网页出错时，人们会看到错误。机器人出错时，人们看到的是缺席——他们发了东西，却什么都没回来。他们会断定它坏了，或者自己做错了什么，而其中一部分人会干脆不再使用。

所以有两件事不是可选项。捕获失败并向用户说点什么，哪怕只是说出了问题、请他们重试。以及把详细信息发到你会看的地方——一个私有频道是传统的答案，而且确实很好，因为它把你的错误放在你已经在看的同一个应用里。

有一个教训是吃了亏才学会的：没有限速的错误频道，在事故期间会产生成千上万条相同的消息，并触发第 091 步讲的发送限制，到那时它恰好在最需要的时候停止工作。把重复的合并起来，或者只发一个计数。

相关的正常失败情况是被拉黑。人们会拉黑机器人；这很平常，不是错误。向拉黑了你的人发送会失败，正确的回应是把他标记为不可达并停止尝试，而不是永远重试。一个把拉黑当作临时故障的广播循环，会把生命浪费在重试那些最不可能回来的人身上。

现在试试——五分钟

四个步骤，而最后一个是大多数机器人从未被做过的。

1. 写出回复一个命令的十五行版本 用你已经会用的任何语言。它立刻就能工作，这正是重点——难点从来不在这里。
2. 加一个兜底回复，回应任何意外输入 在添加任何功能之前。这是对机器人手感影响最大的单项改动。
3. 在对话中途重启它，看看用户看到什么 然后决定那个流程是需要能挺过重启的状态，还是只需要一条更好的消息。
4. 把它交给一个没见过它的人 在旁边看着，不要帮忙。每一次犹豫都是一条缺失的消息，你两分钟内就会找到三条。

该存什么，以及你能少存到什么程度

人们发给机器人的一切都会到达你的服务器。保留它是一个选择，而大多数项目的默认做法是全都保留，因为删除需要做决定，而存储不需要。

弄清楚你真正需要什么，只存那些。一个回答问题的机器人通常除了当前对话什么都不需要。一个接单的机器人需要订单，而不是产生订单的那十四条消息。一个管理群组的机器人需要操作记录，而不是它所看到的对话副本——而且如果隐私模式关闭（第 086 步），它会看到大量内容。

原因并不抽象。一份所有人消息的日志，在任何事情出错的那天都是一份负担——服务器被入侵、同事离职、一个你没预料到的请求。你从未存储的数据不会泄露，不会被传唤，也不会被意外公开。你毫无理由存储的数据纯粹是负担。

由此得出两个实用习惯。给任何对话性数据设置过期时间，让存储自己清空，而不是无限增长。以及说明你保留了什么，写在机器人自己的描述里或某个命令里——一段诚实的话，几乎没有机器人有，而这恰恰是谨慎的人在用它之前会寻找的东西。

这个阶段的常见问题