hamibot 1.6.1：从 AutoJS 分叉到安卓自动化 SaaS 的七年
hamibot 是什么
现在打开 hamibot 1.6.1，你看到的不再是一个简单的自动化脚本编辑器——配对设备后，控制权在浏览器里。云端控制台实时显示每台设备的在线状态、已装脚本列表和运行日志，脚本市场里上千款现成脚本按分类排序，付费和免费的都有。普通用户不需要写一行代码，挑一个脚本点"运行"就能让手机自动打卡、抢货、批量发视频。
这和它的起点差得太远。
安装
hamibot下载后只支持安卓，安装包 19.22M，不需要 root——这一点从某个关键版本开始就成了它的核心卖点。安装过程就是普通 APK 的流程，但有三个权限必须提前开齐，否则脚本跑起来只会卡住不动：无障碍服务（系统设置 → 无障碍 → hamibot → 打开开关）、后台弹出界面（部分 ROM 在悬浮窗权限里）、屏幕截图权限（首次运行 OCR 或图片匹配类脚本时会弹窗，建议点"始终允许"避免反复打断）。配对设备需要在控制台扫码或输配对码，配对成功后 App 基本就退到后台常驻了，日常操作都在网页上完成。注意不要用系统清理工具把 hamibot 的后台进程杀掉——它靠前台服务保活，杀了之后远程指令会收不到。
来路：从本地脚本到云端控制台的分叉点
hamibot 的根在 AutoJS——那个让安卓自动化从开发者圈子走向大众的本地脚本运行时。最早的 hamibot 更像是 AutoJS 的一个"远程控制台 + 脚本市场"的商业化分支，但这个分叉远不止加了一层壳。
第一个决定性的转向，是"不用 root"这件事。早期 AutoJS 的部分能力依赖 root 或无障碍服务，hamibot 团队把全部操作路径收敛到无障碍服务 + 后台弹窗 + 截图这三个系统级权限上，硬砸出了一条不需要 root 也能跑完整自动化链路的路径。这个取舍直接把目标用户从"会写 JavaScript 的极客"扩大到了"能装 APK 的普通用户"。
第二个转折点是脚本市场的上线。AutoJS 的脚本分发靠 GitHub issue、论坛帖子、QQ 群文件，hamibot 把它做成了平台内的标准化入口——分类检索、付费购买、一键安装、分成结算。对用户来说门槛降到了"选脚本 → 点运行"，对开发者来说则有了变现渠道。市场最热门的品类从一开始就是电商抢购（泡泡玛特抽盒机、小米商城新品上架）和社交运营（短视频一键多平台发布），这两类场景的共同特点是"重复性高、时间窗口敏感、需要多设备并行"——恰好踩中了 hamibot 多设备管理的架构优势。
第三个关键变化是云端控制台的定型。AutoJS 没有真正意义上的远程能力，局域网内的调试都要自己搭 Web 服务。hamibot 把设备配对、指令下发、定时触发、运行日志全部放进网页，一个账号能配多台手机，同一脚本能并行下发——这套架构让工作室场景变得可行，也让"手机农场"不再是个复杂的工程问题。
规律：七年迭代里团队一直在死磕什么
从 1.x 一路看过来，hamibot 的迭代节奏有一个非常稳定的优先级排序——
脚本市场的生态建设排在最前面。脚本上架审核、作者分成、市场分类优化、试用机制……这些功能的更新频率远高于底层自动化能力本身。可以说 hamibot 团队把产品重心放在了"让更多好脚本进来"这件事上，而不是"让自动化引擎更快"。
无障碍服务这条路径一直在加固。每个版本都在修补不同 ROM 上的兼容性——小米 MIUI 的后台弹窗拦截、华为 EMUI 的后台清理、OPPO ColorOS 的无障碍服务随机断开……这些问题没有银弹，只能逐台设备去测去适配。团队的做法是把已知的 ROM 陷阱记录下来，在 App 启动时做自动检测并给出引导提示，而不是让用户自己踩坑。
远程能力持续深化，但本地编辑器一直没删。这是个有意思的平衡——hamibot 的重心明显在云端控制台，但本地脚本编辑器和调试功能始终保留，说明团队没有完全放弃开发者群体。脚本可以在本地编辑器里写、调试，再上传到市场，也可以直接配对设备后在本地跑。这让 hamibot 既服务普通用户，又没把开发者推开。
有一件事一直没做：iOS 支持。样本文档里也明确说了 hamibot 只支持安卓，这几年没传出任何 iOS 适配的消息。考虑到 iOS 的自动化生态完全不同（Shortcuts、Automation、TestFlight），这条路线很可能从一开始就不在规划里——聚焦安卓，把这条线做深做透，而不是分散精力。
预判：从 SaaS 平台到行业工具的下一步
照这个迭代节奏往下推，我觉得 hamibot 下一步大概率会往"行业化工具"走——
脚本市场目前是通用型的，但电商、社交、测试这几个场景的需求已经开始分化。电商需要更精细的验证码处理、多账号管理、防风控策略；社交需要内容调度、批量素材管理、平台反作弊对抗。hamibot 可能会为头部场景推出"场景模板包"或"行业版"，把散落在市场里的零散脚本整合成完整工作流。
多设备管理能力还没到顶。目前是"一个账号配多台，统一下发脚本"，但没有设备分组、没有任务队列优先级、没有跨设备协同（比如 A 设备负责刷库存，B 设备负责下单）。如果 hamibot 想在工作室场景里站稳，这些能力迟早得补。
另外一个值得观察的方向是 OCR 和图像匹配的内置化。样本文档里已经提到 OCR 脚本需要截图权限，目前是第三方脚本作者自己集成 OCR 库。如果 hamibot 把 OCR 做成平台级能力（内置、免费、云端调用），那脚本作者写起来会快很多，普通用户也不用关心权限配置——但这涉及成本（云端 OCR 是花钱的），得看团队的商业化策略愿不愿意承担。
当然这些都是从迭代规律推的，不当官方口径传。
写在最后：hamibot 这七年的路，本质上是一个本地工具走向 SaaS 平台的典型案例——从"让会写代码的人省时间"，变成"让不会写代码的人也能自动化"。这条路不算惊艳，但走得很稳，每个关键转折点都踩在了用户需求的实处。接下来往哪走，还得看脚本市场里那些跑在最前面的场景，会把平台拽向哪个方向。
本文為個人基於網路公開資料整理編寫，非官方內容，僅供學習交流參考；軟體版權歸原作者所有，請支持正版；使用過程中遇到問題請查閱官方管道，本文不承擔任何責任。
