AndroMeld 能把安卓手机搬进电脑,还能扫码?

今天看到一个叫 AndroMeld 的工具，第一反应是：又一个手机投屏软件？

随后看到一段约 11 秒的演示，我改变了判断。

电脑浏览器打开腾讯云登录页，上面有微信二维码。旁边是一个安卓微信窗口。演示者打开扫一扫，拖着微信窗口向二维码移动。扫码区域覆盖二维码后，微信出现了腾讯云的授权页面。

整个动作只涉及屏幕上的窗口，画面呈现出直接用桌面内容扫码的效果。

下文以循环动图呈现用户提供的约 11 秒原始演示，并附授权页关键帧。

先说明证据范围：我看的是这段演示和产品公开资料，还没有拿自己的手机实测。视频展示了二维码识别和授权页，最后停在 Allow、Decline 两个按钮前，没有展示点击授权后的完整登录结果。

但这个画面已经足够提出一个值得讨论的问题：如果手机应用能接收电脑上的图像，电脑又能控制手机，那些必须回到手机完成的流程，会发生什么变化？

手机继续运行，电脑多了一个入口

AndroMeld 由 Catching Now 开发。围绕连接自己的安卓手机，它有手机端 App、网页版，以及 Mac 客户端。

连接后，应用继续运行在手机上，已有账号和数据也留在那里；电脑负责显示界面、传递输入。

这意味着，手机里的服务不需要先推出电脑版本，你也可以在电脑上操作它。

官网首页截图，2026 年 10 月 13 日。右侧为官网产品演示。

网页版可以打开手机应用、管理文件、接收通知、同步文本剪贴板，以及播放手机应用的声音。不同 App 可以放在不同窗口里，调整大小、并排排列。当前最多同时打开四个设备窗口，完整手机屏幕也算一个，文件和终端窗口另外计算。

Windows、Linux、Mac、iPad 都可以通过浏览器使用。受控手机需要 Android 14 及以上版本，并提前安装、激活 AndroMeld；浏览器所在设备无需安装客户端。

Mac 版的价值则在于系统集成：手机文件出现在 Finder 里，手机通知进入 Mac 通知中心，还能把手机摄像头用于电脑会议。通话、拖拽等功能受系统版本和机型支持限制。

网页版官网截图。浏览器提供操作界面，应用实际运行在连接的手机上。

日常场景很好理解：坐在电脑前，用键盘回复手机消息；整理手机照片，再送进电脑剪辑；使用某个只有移动端的服务。提前完成远程设置后，还可以连接留在家里、保持在线的备用手机。

按当前官方网页，网页版功能免费；Mac 免费版对新开手机窗口和通过 Finder 向手机写入文件设有每周额度。远程连接如果使用官方中转服务，流量另外计费。

它和 scrcpy，差别在哪里？

熟悉安卓的人，可能会想到 scrcpy，也就是常说的 screen copy。

两者都有远程显示和控制手机的能力。用 scrcpy 打开手机上的微信扫一扫，微信仍然可以调用手机实体摄像头。如果摄像头对着电脑二维码，便有机会正常识别。scrcpy 本身也支持直接输出手机摄像头画面。

所以，把 scrcpy 理解为不能扫码，会混淆远程控制与摄像头能力。

AndroMeld 在这些能力之外，提供了浏览器入口、应用独立窗口、文件和通知集成，以及面向 AI 的控制接口。这些功能让它更容易进入日常电脑工作流程。

不过，视频里的桌面取景扫码又涉及另一项能力。普通投屏只把手机画面送到电脑；这段演示呈现的是电脑画面被用于手机扫码的效果。

图像向哪个方向流动，是理解这段演示的重点。

拖动窗口，为什么就能识别二维码？

视频里，打开扫一扫后，扫码区域开始显示电脑桌面。拖动窗口时，区域里的内容随窗口位置变化。覆盖到二维码后，出现识别标记，接着进入授权页面。

原视频转成的循环动图：扫码区域随窗口位置变化，覆盖二维码后进入授权页。

最符合这个现象的解释是：软件取得窗口对应位置的桌面图像，把它提供给手机端扫码流程。拖动窗口，就相当于改变取景位置。

可以把这条链路理解为：

电脑上的二维码 → 桌面图像采集 → 手机端图像输入 → 微信识别 → 授权确认。

这里的内部实现仍属于推断。单靠视频，无法判断它采用虚拟摄像头、其他图像输入接口，还是专门的扫码适配。

官方文档确认，部分 Android 16 及以上设备支持在 Meld Mode 中向手机应用提供电脑摄像头和麦克风输入。这证明产品具有跨设备输入能力，却不能直接解释桌面取景扫码的全部细节，也不能据此认定这段演示的最低系统要求。

演示同样没有给出物理布置，我们无法仅凭屏幕录像排除所有其他拍摄方式。但扫码区域跟随桌面窗口位置变化，是支持桌面图像输入这一解释的重要线索。

视频最后进入腾讯云授权页，尚未展示确认后的登录结果。

浏览器凭什么能控制一部手机？

仅靠打开网页，无法获得整部安卓手机的控制权。AndroMeld 在手机端有一套激活和授权流程。

根据官方说明，可以通过无线调试、已授权的 USB 连接，或者 Shizuku 激活。激活后的设备组件使用 Android shell 权限提供屏幕控制等功能，无需 root。

ADB 是 Android 的调试桥梁；Shizuku 则可以让普通应用经由具备调试权限的服务调用系统接口。AndroMeld 把这些底层能力包装成了用户可操作的产品。

Meld Mode 还会把应用打开到独立显示区域，再呈现在电脑窗口里。因此，你看到的多个窗口对应手机上的应用显示能力，具体兼容性仍由应用和手机系统决定。

网络侧，开发者公开的 TURN 中转项目确认了 WebRTC 的使用：优先尝试设备之间直接连接；跨网直连失败时，可以通过中转转发加密流量。

配对、授权、显示和输入，这几件事组合起来，浏览器才成为手机的远程操作入口。

连接码帮助建立配对，新浏览器仍需在手机上获得批准。手机端保留已配对设备列表，也可以撤销访问权限。

AI 能不能替你扫码登录？

我最先想到的场景，就是出门后遇到必须用手机确认的登录。

如果桌面取景能力在自己的设备上可用，就有机会把打开登录页、启动扫一扫、移动窗口和处理确认页串成自动化流程，手机也无需固定在显示器前。

这仍是一个待验证的设想。视频没有展示 AI；完成整条流程，需要电脑端窗口控制、手机端操作接口，以及手机系统和微信版本的配合。

AndroMeld 的 Mac 版提供 MCP 服务，AI 可以通过工具连接手机、观察界面、点击、滑动、输入和启动应用。网页版没有这项 MCP 集成。

这里有个容易忽略的限制：官方产品指南写明，MCP 当前操作的是 Phone Screen，尚未覆盖 Meld Mode 独立窗口。 视频展示的正是独立微信窗口。因此，拥有手机 MCP 接口，不等于已经具备视频里的完整拖动扫码链路。

它仍然有吸引力。查询移动端服务、处理手机里的表单、整理信息，都可能通过已有界面完成。很多应用没有向 AI 开放 API，界面控制给了自动化另一条路径。

只是，界面随时可能变化，网络会断，登录会过期，弹窗也会打断任务。能完成一次演示，与能持续运行，是两种不同的工程要求。

微信会不会识别到这种操作？

目前没有公开证据能够证明，微信一定识别 AndroMeld 或 scrcpy，也没有证据保证它们不可检测。

从技术上看，应用可能观察到它有权访问的显示、输入设备和摄像头环境信息；服务端还可以结合登录设备、网络、失败次数和账号历史分析异常行为。哪些信号被采集、权重多大，微信并未公开完整细节。

对 AI 控制，官方还披露了一项具体信号：MCP 任务运行期间会启用手机的 Android 无障碍功能，应用可能注意到这一状态；最后一次请求约一分钟后，AndroMeld 会将其关闭。这说明远程操作可能留下可观察信息，但不能据此断定微信已使用这一信号检测 AndroMeld。

把实体手机当作不会被识别的保证，也缺乏依据。实体手机可以承载自动化操作，平台依然可能分析行为模式。

甚至读取调试状态这件事，都不能套用旧经验。当前 Android 官方文档说明，ADB_ENABLED 和开发者选项状态这两个字段对第三方应用始终返回 0。机型、系统版本和权限边界，都会影响实际可见信息。

我更愿意用三个问题判断这类工具：

这段视频回答了第一问中的二维码识别部分，后两问仍需分别验证。 技术演示本身也不构成平台对第三方自动化登录的许可。

识别二维码、稳定执行、获得平台接受，需要分别讨论。

手机的操作入口正在变多

我对 AndroMeld 的兴趣，来自这组能力连起来后的变化。

手机继续保存账号、运行应用。电脑提供大屏幕、键盘和桌面内容。AI 再通过工具接口参与操作。许多过去要拿起手机才能做的事，开始有机会进入电脑上的工作流程。

扫码动作尤其直观：过去，人负责把一个屏幕里的二维码交给另一部设备；现在，软件开始承担这段信息传递。

手机仍然在那里，但围绕它的操作入口，已经延伸到了浏览器、桌面和 AI。