别被吓着，这篇文章不是来说 IFS RSVP Bot 要停止维护，何况我还没打算在短期内停掉它——事实上这段时间我确实有在维护代码，只是功能性更新这方面很久没动是真的。
只是，IFS RSVP Bot 能够存活超过快半年时间，并依然被大部分中国大陆地区城市的 Ingress First Saturday 活动使用，已经是我所创建的各种「大坑」里走得最长远的一个项目。我觉得现在这个时间点来重新审视 bot 身上发生的各种事情，也相对合适重新对项目的未来做一点整理。
IFS RSVP Bot 项目是怎么诞生的？
IFS RSVP Bot 是在 Ingress First Saturday 活动在大陆「复活」后的第一轮活动前（2019 年 3 月初）就被开发出来。
彼时的 bot 项目没有一个正式的名称（甚至 git 也是在本地诞生的），仅仅只是为了在广东佛山的 2019 年 4 月 IFS 活动使用。至于开发 bot 的动机，也就是为了简化佛山 IFS 的活动流程，参考中国大陆以外 Ingress Mission Day 活动的登记 bot 来制作的。
后来与昆明某位友军的私下讨论之后，最终有了「将 bot 做成每个城市都能用」的想法。名字也非常朴素，IFS RSVP Bot 就是用于 IFS 活动 RSVP 管理的 bot。
彼时的 bot 功能和现在并没有什么很大的差异。第一个版本的 bot 实际上就已经实现了一个城市多场 IFS 活动分会场的功能。（附带一句，如果你参与过第一场 IFS 的申请工作，那么你应该清楚这个功能背后，游戏官方与大陆 PoC 玩家之间发生过什么事……）在后来更新的版本中，bot 新增了诸多实用功能，例如支持多位签到人员操作、AP 下限限制等等功能。
现在的 IFS RSVP Bot 虽然实现的功能依然非常简单，但切实解决了 IFS 活动相关的报名信息和数据管理上的不便。虽然现在依然谈不上「一键解决所有事情」，但至少比以往使用传统纸笔抄写和人工计算而言，是一个不小的进步。大概这也是为什么 IFS RSVP Bot 能直到现在都能被诸多城市使用的缘故吧。
为什么迟迟不做 OCR 识别功能？
这个功能的确是我第一个版本做出来的时候就想做的，也是大家呼声最高的功能。但我一直压着没有做。
你要说我懒，我当然不会反驳（因为这也是实事之一）。但更重要的原因我也在 bot 的官方群里有所谈及，当然那时候说的只是一个大概想法。在这里，我会再做一个更详细的说明。
我的观点是：目前为止，对比 OCR 功能投入产出比太低，所以短期内是不会再考虑实现这个功能。
首先是 OCR 功能在 bot 的应用范围对比它的开发成本而言是不平衡的。在 IFS RSVP Bot 中，OCR 功能的使用场景有两个：签到和签退步骤的数据提交。在我的想法中，单独为这两个功能去做 OCR 有些杀鸡用牛刀，虽然这两个功能的确是 bot 使用率最高的功能，但对比 OCR 服务的接入成本，个人认为投入产出比实在是有些低：你实际上依然是在提交数据，只是提交的数据从文字变成图片而已，减少的只是核对数据的一点精力——它完全可以通过增加签到人员的数量来解决，OCR 在其中的价值就被削弱了。
另外，即使加入了 OCR 功能，签到和签退的步骤可能反而更麻烦了。在 IFS RSVP Bot 的整体流程中，为了避免非常潜在的数据造假问题（虽然我倾向于相信绝大部分玩家都不会这样做），所有签到和签退数据都需要签到人员来核对并录入。加入 OCR 功能能不能将它下放给玩家自助提交？不行，因为 Ingress 的玩家资料页截屏并不能体现截屏时间点。截屏发给签到人员，由他们提交？基于同样理由，签到人员依然需要对你发来的截屏进行审核，才能提交给 bot。那么，由签到人员打开你的资料页截屏呢？不是不可以，但也有许多玩家选择隐藏自己的详细特工资料，签到与签退步骤对他们来说变得更麻烦了；而且签到人员需要一个个资料截屏发给 bot，工作量未必就比一个个手动数据更少。
再加上对 PoC 而言的额外的维护成本。以我本人的技术力，以及目前 bot 代码的维护参与者只有我一个人（😭）的事实而言，为 bot 从头做一个 OCR 功能绝对是不现实的，这个功能必然需要用到第三方服务。而 IFS RSVP Bot 作为一个开源项目，第三方服务的接口使用权限必然无法做到所有实例开箱可用的状态。换句话说，即使我能在 bot 里做好 OCR 功能，你想要在 bot 里使用，必然需要自己注册一个新的服务，甚至需要付费使用，实际上，这已经开始违逆 IFS RSVP Bot 的「尽可能开箱即用」和「专注核心功能」的初衷。
顺便说一句，连我都觉得使用 Airtable 来统计数据的方案的确是一个槽点：不仅利用它作为数据库的开发成本比 SQL 还高，而且部署起来也谈不上「开箱即用」这个说法。但它带来的好处就是更清爽的排名视图，以及快速导出数据、提交官方的操作，对 bot 的体验提升简直是全方位的。这个投入产出比，比 OCR 大到不知道哪里去了。
为什么单独一个城市需要单独做一个 Bot？
我其实也有很多次想到过「能不能做成平台来避免部署」这样的问题，但最终还是因为各种各样的原因放弃。
独立做成平台的好处很多。例如，使用 bot 之前只需要一次审核，平台就可以直接完成创建活动、抓取报名信息、数据导出等等的操作，不需要再对着 Heroku 或者其他操作系统的终端界面头疼，所有签到人员也只需要接入一个 bot 就能完成操作，甚至直接脱离 bot 做成相对更方便使用的形式，真正的「开箱即用」。
现在的状态好处也有不少。最明显的，就是你可以任意将 bot 部署在你喜欢的平台：虽然我出于「开箱即用」的想法以及拥有免费服务的缘故，推荐你在 Heroku 部署这个 bot（还专门做了优化），但你依然可以在你希望部署的任何一台可以运行 Node.js 程序的服务器上来跑 bot。对于有额外功能需求的城市而言，他们也可以任意修改代码来完成部署，不需要对我们进行功能请求。
总体来说，各有各的好处，也代表了两种不同的开发路径。IFS RSVP Bot 选择开源并让每个城市独立部署自己的 bot，更多是因为某种历史遗留问题：因为它本身并没有考虑兼容其他城市 IFS 场次的使用。
也许未来在合适的时间，对「开箱即用」的极致追求会让我彻底推翻 IFS RSVP Bot 目前的形态，变成真正的 SaaS 形式，但短期内如此大的开发路径更变几乎是不可能的，所以这种形式还会保留很长一段时间。
当然我知道很多人会反对我把 bot 变成 SaaS 形式吧。XD
Bot 在未来会有什么样的新功能？
说实话，我也不知道。因为我觉得目前 IFS RSVP Bot 的形态已经能够满足绝大部分 IFS 活动签到与签退使用。可能会有一些细节上的东西可以再追求一下，但形式基本上不会怎么变化。
最近其实最想在 bot 上做到的事情，就是 i18n（internationalization），即多语言支持，因为 IFS 活动的签到与签退需求一定不仅仅在中国大陆中存在，在全球皆然，做 i18n 也是为了让 bot 能够让大陆以外地区的玩家也能享受流畅的活动体验。
不过做 i18n 必然需要不同语言的语料支持。写这篇文章的时候我还特意去 bot 的翻译项目看了一眼，不出所料，完全和一个死掉的项目没有任何差异。功能方面，实际上我已经做好 80% 的多语言工作（以英语为基础），剩下的工作就是 Airtable 的多语言表格模板，以及文档的英语翻译。但由于这段时间的状态实在是有些糟糕透顶，这两件事情至今依然是处于搁置状态。
另一个希望的方向就是官方合作，比如，一些数据接口上的支持，就能让 bot 的体验提升不止一星半点。但更大问题是，他们凭什么和你合作：他们完全可以自己做 SaaS 平台来替代你；当然更棒的情况是，直接在 Ingress 服务器后台全自动抓取数据，PoC 只需要承担活动组织的责任就可以了。事实上，做这样的事情必然会在一些法律问题上打一点擦边球。我不希望看到这样的情况，在项目主页的 disclaimer 就是为了避免这样的情况而标注的。
有一点可以放心的是，IFS RSVP Bot 项目会继续运行下去：既然项目能够在今天依然有许多城市使用，那么它自然对多数人而言是有价值的，我当然没有理由在这个时候叫停它，更何况我认为它现在的状态好得不能再好了。只是，我觉得这个项目和我本人可能需要更多人的支持：任何形式的帮助，对项目而言都是可遇而不可求的。
你希望 IFS RSVP Bot 以后会有怎么样的惊喜？在下面的评论区告诉我，或是入群聊聊吧。