只有一部手机，怎么扫码：一次登录态救援的完整接力

只有一部手机，怎么扫码：一次登录态救援的完整接力

Case · 小跟班实录 02

问题

小跟班的很多能力，前提是”登录态在线”：发视频、拉数据、回评论，都要求平台认为”是一个真人在操作”。

真人操作靠什么证明？扫码。

某天早上，发布任务启动时发现：平台登录态过期了，页面上是一面扫码墙。按标准流程，把登录二维码发给用户，用户用手机上的平台 App 扫一下，几秒钟的事。

但这次的实际情况是：用户只有一部手机，且不在电脑前。

二维码显示在电脑屏幕上，扫码的 App 在用户口袋里的手机里——用户连”看到二维码”都做不到。这不是操作繁琐的问题，是扫码这件事在物理上不成立。

大多数人第一次意识到：家庭 AI 助手要真正可用，最大的障碍不是模型不够聪明，而是这类”必须人到场”的断点。断点一天不消除，助手就一天需要人守着。

图：这段经历后来被做成视频《只有一部手机，怎么扫码？》。这一帧是视频里小跟班的回答——整个方案的核心就这一句。

方案

小跟班没有停下来等用户回家。它做了四步接力，每一步都在替换”人必须在场”这个前提。

第一步：承认此路不通。 二维码推到微信后，没有傻等。它确认了一个关键事实：用户只有一部手机，扫码动作物理上无法完成——于是主动放弃扫码路线，而不是反复推送二维码制造焦虑。

第二步：找替代通道。 平台不止一种登录方式。除了扫码，还有短信验证码登录——这条路只需要用户”看一眼手机、念 6 个数字”，不需要第二台设备。小跟班切换到短信通道，把验证码请求发了出去。

第三步：把交互成本压到极限。 整个过程中用户做的事只有一件：收到短信，回 6 个数字。没有安装 App、没有点链接、没有念一串字符。验证码有时效，第一轮过期了，小跟班自动重发第二轮——重试逻辑它自己扛，用户不需要理解”验证码为什么失效”。

第四步：闭环留证。 登录成功后，它继续做完了原定任务：发布视频、核验私密状态、回传链接，并把整个救援过程记录归档。事后复盘时，每一轮验证码的时间、失效原因、通道切换的决策点都有据可查。

图：救援四步卡。整个过程中用户的全部投入，是看了眼手机、念了 6 个数字。

结果

登录恢复全程，用户的总投入是一条 6 位数字的短信回复。

原定任务照常完成：视频发布上线，私密状态经独立路径验证确认，链接回传。整个过程中用户没有回到电脑前——“人不在场”从障碍变成了不需要考虑的变量。

这次事故之后，“登录态健康检查”被加进了每日例检：发布任务启动前先验登录态，发现过期直接走短信接力，不再等任务失败后才补救。后来几次登录态过期，用户甚至感觉不到——只在事后收到一条”已自动恢复”的通知。

一个衍生收获：这段经历本身被做成了视频（《只有一部手机，怎么扫码？》），发布后成为账号数据最好的一条。最好的内容素材，就藏在产品自己解决真实问题的过程里。

边界

• 短信通道是平台给的备份，不是破解。 全程用的是平台官方的验证码登录能力。如果某平台只有扫码一种方式，这条接力就走不通——小跟班的处理是明确报告”此平台无法远程恢复”，而不是硬闯。
• 验证码的正确性由人保证。 小跟班能做的是把验证码请求发出去、把时效重试扛下来，但 6 位数字必须由用户亲自读取回复。这是身份验证的安全边界，不该被绕过，也绕不过。
• 自动化动作有明确红线。 滑块验证、风控墙这类平台安全机制，设计原则是”停手报告”，绝不自动拖拽或反复重试——那是对平台的对抗，风险远大于收益。
• 接力依赖预先打通的通道。 短信能到用户手机、用户的回复能回到小跟班，靠的是事先配置好的消息链路。链路断了，方案再好也执行不了——所以链路本身也在每日例检里。

---

本文为小跟班（3HomeTech 家庭 AI 助手）运行实录，事件经过与数据均来自运行留档。