每天到工位先掏出手机点打卡，这事我坚持了三年，直到有一天我实在烦了，决定把手机彻底交给AI。当时刷到一个叫AutoGLM的开源手机智能体框架，正好我电脑上还挂着智谱GLM-4.7的模型服务，就顺手做了个小实验：让手机自己打开打卡App、自动定位、点击提交，最后再给我截个图骗不了的那种。第一次跑通的那天上午，我盯着屏幕看它自己完成整套流程，说实话心里有点发毛，但更多的是兴奋——原来手机不是只能装应用，它本身就可以是一间AI实验室。这篇文章就是那个实验的完整复盘。我会从AutoGLM的核心原理讲起，再拆解环境搭建、打卡任务的落地实操、踩坑记录，最后聊聊怎么把这个能力迁移到别的场景。适合谁看？一个是每天被固定流程反复折腾的上班族，另一个是对AI Agent感兴趣、想动手搞点真东西的开发者。不管你是哪种，这篇文章里没有玄学，只有能复现的步骤和我替你们走过的弯路。1. 为什么手机能当AI实验室：AutoGLM的原理与玩法拆解1.1 AutoGLM到底是啥：从“会聊天”到“会动手”大模型我们已经很熟了，你问它“怎么打卡”，它能给你写一篇800字攻略。但AutoGLM这类开源智能体框架解决的是另一件事：让它真的去执行。两者的差别就像教练和运动员，教练说得头头是道，运动员才是上场跑完那个。手机端的智能体要干活，本质上是三件事：看屏幕、想下一步、动手操作。看屏幕靠截图和多模态理解，想下一步靠大模型推理，动手靠系统辅助功能接口模拟点击、滑动、输入。AutoGLM干的事情，就是把这三步拧成一个闭环：截图 → GLM-4.7分析当前界面 → 返回一个结构化操作指令 → 系统执行 → 再次截图验证结果。这里必须强调一个容易被忽略的点：它做的不是简单的坐标点击自动化，坐标点击那种方案又脆又傻，换个分辨率就全废。AutoGLM走的是语义层操作——模型看的是界面文本和控件类型，比如“找到一个按钮，它的文字是打卡，点击它”。哪怕界面布局变了，只要按钮文字还在，它就能重新定位。这一点直接决定了这套方案在真实App里的存活率。1.2 从“会聊天”到“会动手”：任务拆解是核心能力我一开始以为，只要对模型说一句“帮我打卡”就完事了。真跑起来才发现，模型能理解这句话，但它不知道你的打卡App长什么样、按钮藏在哪里、中间会不会弹广告。所以做智能体任务，核心不是写Prompt，而是把目标拆成“可执行步骤”。我自己的方法是先把流程写成伪代码：如果屏幕上有“打卡”App图标，点击它。等待App完成加载，识别“考勤打卡”入口。点击“定位打卡”或者“打卡”按钮。如果弹出“确认提交”弹窗，点击“确定”。验证屏幕出现“打卡成功”之类的提示，截图留证。这一步做得好不好，直接决定后面模型的具体表现。拆得越细，模型就越少产生歧义。AutoGLM的框架通常支持“任务指令 + 操作定义”的结构化输入，你可以把上面这种伪代码转成它认识的格式。这也是我最想让你先记住的经验：智能体不是魔法，它是把人的步骤感翻译给机器听。2. 环境准备：搭建一套极简的手机自动化实验环境2.1 物料清单：你需要准备的设备与安装包这套实验的最低配置很亲民，不用顶配旗舰机，但有些基础条件必须满足：一台Android手机，系统版本建议8.0以上，太老的无障碍接口不完整。开启开发者选项和USB调试，用于连接电脑查看日志、安装调试包。一个AutoGLM运行环境，可以直接拉开源仓库的代码自己编译，也可以用社区编好的预构建版本。一个GLM-4.7模型服务，两选一：本地部署（需要一张显存大点的显卡，或者用量化版本跑CPU）或者调用在线API。ADB工具包，电脑上装一个，方便做日志抓取和命令下发。需要说明的是，这里说到的AutoGLM和GLM-4.7并不是一套完整商业系统，更像是“轮子”。我们真正要做的，是把轮子装到自己的车上。我自己的实践是用一台闲置的老Android机当测试机，因为自动化框架要不断试错，主力机上装来装去容易影响日常使用。2.2 初始化配置：开通无障碍服务与必要的权限这是整套流程里最敏感也最关键的环节。手机自动化为什么普遍要开“无障碍服务”？因为Android系统出于安全考虑，不允许普通App直接替用户点击屏幕，无障碍服务是官方留出来的合法通道，原本是为了帮助视障用户操作手机。智能体框架正是借了这条通道，才实现的点击、滑动、读取控件内容。配置路径大同小异：设置 → 无障碍 → 已下载的服务 → 找AutoGLM对应的服务，开启即可。这里有个容易踩的坑：很多手机厂商会在后台杀掉无障碍服务，特别是某些主打“省电优化”的机型，明明设置好了，过几个小时再一看，服务已自动关闭。解决办法是在系统设置里把智能体App锁定后台，多任务卡片上点锁，部分激进系统还需要在电池优化里设置为“不限制”。除了无障碍，还要给摄像头权限吗？不需要，AutoGLM默认抓取屏幕截图，不需要拍照权限。但存储权限要开，因为截图文件要落盘；位置权限要谨慎处理，比如打卡App会要求定位，那是App自己的权限请求，属于自动化执行过程中的正常交互。2.3 模型服务接入：本地部署还是在线API？参数怎么选AutoGLM本身只是个“手”，负责操作手机。GLM-4.7才是“脑子”，负责看屏幕、出决策。所以第二步是把两者串起来。我以我自己的环境举例。本地部署方案：下载GLM-4.7对应的开源权重，用标准推理脚本启动本地服务，监听特定端口。内存和显存是主要门槛，我是量化版本加载，大约占用不到16G显存，CPU模式也能跑，但每一步决策可能要等几十秒，体验比较痛苦。在线API方案更省心，注册之后拿一个密钥，在AutoGLM配置里填上接口地址和模型名即可。这里有个重要的参数经验：温度temperature要调低，比如0.1～0.3。原因很简单，自动化操作需要稳定，不需要创造力。温度太高，模型同一任务十次能给你出十种不同写法，执行起来非常不稳定；温度低一点，它倾向于输出保守、可预测的操作序列。另一个参数是max_tokens，关于这个我要多说两句：模型既要输出动作，又要输出验证条件，给太少会导致动作被截断，建议至少给到1024以上，复杂任务给2048。3. 自动打卡落地：从Prompt设计到端侧部署的完整流程3.1 定义打卡任务的“动作序列”：状态机思考法忠实用户已经知道，「说一句话私AI就自动打开App操作」的难度在于，模型需要随时判断当前处于流程的哪一步。所以我建议在Prompt中用“状态机”的思路，把任务划分成多个封闭的状态：初始状态：桌面状态A：打卡App首页状态B：登录页状态C：考勤页面终态：打卡成功每个状态干什么、如何判断进入下一状态，全部在Prompt里写清楚。相当于给模型一张地图，而不是让它瞎猜。以我实际使用的模板为例，任务描述部分我会这样写：任务：在XX打卡App上完成打卡。 你可以使用的操作： - tap(text)：点击包含指定文本的控件 - input(text)：在输入框填入文本 - wait(秒)：等待界面加载 - back()：返回上一级 - screenshot()：截取当前屏幕 - verify(text)：断言当前屏幕出现期望文本 请严格按以下状态顺序执行： 1. 如果屏幕不在打卡App，先打开App。 2. 等待进入App首页，寻找“考勤打卡”或“打卡”按钮。 3. 点击打卡按钮后，如果出现定位授权或提交确认弹窗，选择允许或确定。 4. 每步执行后截图，并输出当前状态为OK或FAIL。 5. 当屏幕出现“打卡成功”字样时，停止操作，输出最终结果。这段Prompt没有华丽的词藻，但模型理解起来非常准确。别把提示词写成“请你帮我打卡”，那是不负责任的。好的任务描述应该像给实习生写SOP，一条一条列清楚。3.2 执行与验证：为什么每一步都要“截图证明”我最初版本的Prompt没有验证步骤，模型一股脑往下点，结果点错了还在继续，甚至退出打卡App回桌面了。后来我才加上了“verify”这一步，就是上一步操作完成后，必须截图确认预期界面出现，再进入下一步。本质上这是给智能体加了一道“自检回路”。如果某一步验证失败，模型应该停下来，而不是硬着头皮执行后面的步骤，或者盲目重试。在实际运行中，这个设计救了我很多次。比如打卡按钮被广告弹窗挡住，验证失败后模型停下来报告“未找到目标控件”，我再针对弹窗增加一条处理规则，整个流程才变稳。这里有一个特别细节的处理：等待时间。App加载慢是常态，如果刚点完按钮立刻验证，大概率失败。我习惯在关键点击之后加一个wait(2～3秒)，等页面稳定后再验证。参数别写死太长，否则一次打卡要半分钟，人早自己点完了。3.3 定时触发：让它每天自己跑起来流程跑通只是第一步，能做到“每天到点自动执行”才算真的解放双手。定时触发我试过两条路线：第一条是手机本地的自动化工具，设定每天固定时间发出一个任务广播，唤醒AutoGLM去执行打卡任务。这个方案的好处是不依赖电脑，但要求自动化工具与AutoGLM之间能通信，有些时候要写一点简单的任务脚本来桥接。第二条是电脑端定时器，每次到点通过ADB向手机下发一条执行命令。优点是可操控性强，日志也好收集；缺点是手机要连着电脑，或者在同一局域网内开启网络调试。我最后采用的是手机端定时方案。具体实现不复杂：在自动化工具里添加每天09:00的打卡任务，动作是启动AutoGLM并传入任务ID。我还做了一个保护逻辑：如果当天已经打卡成功，就跳过执行，避免重复提交。这一点建议所有做自动化的朋友都加上，没人想因为脚本抽风再跑一遍流程的。3.4 从命令行到无人值守：一次完整的真实运行记录为了让概念更具体，我把一次真实运行的日志简化一下，大概是下面这个样子：[09:00:01] 任务启动：打卡任务 [09:00:02] 当前界面=桌面，开始查找图标 [09:00:05] 执行 tap("考勤打卡") [09:00:08] wait(2秒) [09:00:10] 截图验证，发现登录页，进入状态B [09:00:11] 执行 input("手机号") [09:00:13] 执行 input("密码") [09:00:15] 执行 tap("登录") [09:00:19] 截图验证，发现首页，进入状态C [09:00:21] 执行 tap("上班打卡") [09:00:23] 弹窗出现，exec da("确定") [09:00:26] 截图验证，发现“打卡成功”，任务结束整个流程26秒，而我自己手动操作通常也要15秒左右，这个效率完全可接受。而且中间不需要我的任何干预，模型像一个非常听话的实习生，每一步都会先看再动。第一次跑通那会儿我真就坐在旁边看着，有种在带新人的感觉。4. 实操中踩过的坑：误触、弹窗、网络白屏与界面变化4.1 弹窗拦截与误触：一招解决“模型被广告带走”手机App最大的敌人不是人脸识别，是五花八门的弹窗。打卡App时不时弹出“签到有礼”“升级提示”“红包领取”，模型第一步点打卡按钮还好，万一弹窗刚好出现在按钮上面，它可能就点进广告页里出不来了。我的处理方法是给Prompt加一条“弹窗优先”规则：任何一步执行前，先截图检查是否出现“关闭”“跳过”“取消”等弹窗关闭按钮，如果出现且内容与当前任务无关，优先点击关闭，再执行原计划操作。这条规则写进去之后，任务成功率至少提高了三成。别小看这一句，弹出拦截本质上就是智能体在动态世界中保持目标稳定的能力。4.2 网络白屏与等待时长：别让模型在加载页里硬刚打卡App偶尔会出现白屏或加载动画停留很久的情况。模型如果看到白屏，它会敏感地认为“目标控件不存在”，然后给出FAIL，白白打断流程。后来我在验证逻辑里增加了一个“等待确认”机制：当预期控件未出现时，先等待2秒再截图确认，如果连续两次确认仍失败，才判断为异常。这个机制的好处是大幅减少误报。但你也别太乐观，有些App加载要十秒以上，2秒根本不够。再狠一点的处理是设一个“最大等待时长”，比如15秒，超过这个时间就判定网络异常并停止任务。杜绝了模型卡在加载页里反复重试直到把流量耗尽的情况。4.3 UI版本更新：当按钮名字从“打卡”变成“完善信息”打卡App没人会承诺UI永远不变。某次小版本更新后，按钮文字从“上班打卡”改成了“开始考勤”，模型找不到目标控件，整个流程就断了。这是所有自动化方案都会遇到的宿命问题。但是我发现一个增强鲁棒性的写法：在Prompt里给按钮准备别名。比如“寻找打卡相关按钮（可能叫：打卡、开始考勤、上班打卡、签到）”。模型在语义理解上的优势在这里体现出来了，就算文字有所变化，它也能通过上下文推断出哪个是打卡入口。这比传统自动化脚本里写死一个坐标或者一个固定控件ID要坚强得多。4.4 重复打卡与幂等保护这条是血的教训。有几次定时任务执行时，打卡结果还没弹出来，模型以为失败了，又重新点了一遍，结果当天出现了两条打卡记录，被HR提醒过一次。所以我在任务描述里明确加了“幂等”这个约束：执行前先查看当天是否已有打卡记录，如果有，立即停止。模型看到“已打卡”标识就不会再执行。这个逻辑建议所有自动化任务都内置，不只是打卡，涉及资金、数据写入类的操作尤其要注意。5. 从打卡到更多场景：把手机变成个人AI工作流5.1 场景迁移：自动回复、订餐、信息整理整套方案跑通之后，你会发现手机上的重复劳动窗口基本都被打开了。同原理可以迁移的场景我列几个：自动查天气并整理出行建议，早上推送通知。自动回复工作群里的固定问候，比如“收到”。自动打开外卖App，按预设订单完成订餐。自动整理短信里的验证码，汇总到备忘录。自动把公交卡、地铁App里的余额截图存到账本。每一个场景的落地方式和打卡任务完全一样：拆步骤 → 写状态 → 加验证 → 设触发。我给朋友演示的时候，经常会说这不是做一个App，而是给你手机配置一名“数字员工”，你只负责定目标，具体操作它来做。5.2 边界与安全提醒：能自动化的，不等于该自动化的提到这里我必须泼一盆冷水：手机自动化越强大，越要克制。涉及密码输入、支付转账、人脸识别等敏感操作，我不建议交给智能体全自动执行。不是技术上做不到，而是一旦出现误触发或指令被污染，后果远超过省下的那点时间。比较稳妥的模式是“半自动”：智能体负责导航和操作，遇到支付确认之类的关键节点，停下来等人类点头。隐私方面也要心里有数。你要给AutoGLM赋予非常高的系统权限，它相当于能替你在手机上做几乎任何事。所以尽量只在一台专用手机上跑，别在主力手机上装；任务Prompt里也别写明文密码，尽量用系统级的密码管理方式去处理，或者干脆只做免登录的流程。5.3 给新手的入门建议：从小任务开始，先不要贪多如果你也想把手机改造成自己的AI实验室，我的建议是从一个特别小、特别无风险的任务开始，比如“自动打开天气App并截图”。这个任务不涉及任何敏感操作，即使跑砸了也没什么损失。跑通之后再逐步增加步骤，比如登录、填表、跨App跳转。每增加一个环节，就多观察一次日志，确认稳定后再管下一个。另外不建议一上来就折腾本地模型部署。先接在线API把流程跑通，理解智能体的工作方式之后再考虑离线部署。很多人在环境配置这一步就被劝退了，其实是把顺序搞反了，工具是次要的，核心是把“拆解任务”和“设计验证”这两个思维练出来。我在实际使用中最大的体会是：把手机交给AI不难，难的是你信不信任它。信任不是靠感觉，是靠一步一步的验证堆出来的。当你看到打卡App在无人工干预的前提下，每天准点完成那套流程，并且在状态日志里留下“验证通过”四个字，你会觉得这块手机屏幕，确实就是一个真正属于你的小实验室。
每天到工位先掏出手机点打卡，这事我坚持了三年，直到有一天我实在烦了，决定把手机彻底交给AI。当时刷到一个叫AutoGLM的开源手机智能体框架，正好我电脑上还挂着智谱GLM-4.7的模型服务，就顺手做了个小实验：让手机自己打开打卡App、自动定位、点击提交，最后再给我截个图骗不了的那种。第一次跑通的那天上午，我盯着屏幕看它自己完成整套流程，说实话心里有点发毛，但更多的是兴奋——原来手机不是只能装应用，它本身就可以是一间AI实验室。这篇文章就是那个实验的完整复盘。我会从AutoGLM的核心原理讲起，再拆解环境搭建、打卡任务的落地实操、踩坑记录，最后聊聊怎么把这个能力迁移到别的场景。适合谁看？一个是每天被固定流程反复折腾的上班族，另一个是对AI Agent感兴趣、想动手搞点真东西的开发者。不管你是哪种，这篇文章里没有玄学，只有能复现的步骤和我替你们走过的弯路。1. 为什么手机能当AI实验室：AutoGLM的原理与玩法拆解1.1 AutoGLM到底是啥：从“会聊天”到“会动手”大模型我们已经很熟了，你问它“怎么打卡”，它能给你写一篇800字攻略。但AutoGLM这类开源智能体框架解决的是另一件事：让它真的去执行。两者的差别就像教练和运动员，教练说得头头是道，运动员才是上场跑完那个。手机端的智能体要干活，本质上是三件事：看屏幕、想下一步、动手操作。看屏幕靠截图和多模态理解，想下一步靠大模型推理，动手靠系统辅助功能接口模拟点击、滑动、输入。AutoGLM干的事情，就是把这三步拧成一个闭环：截图 → GLM-4.7分析当前界面 → 返回一个结构化操作指令 → 系统执行 → 再次截图验证结果。这里必须强调一个容易被忽略的点：它做的不是简单的坐标点击自动化，坐标点击那种方案又脆又傻，换个分辨率就全废。AutoGLM走的是语义层操作——模型看的是界面文本和控件类型，比如“找到一个按钮，它的文字是打卡，点击它”。哪怕界面布局变了，只要按钮文字还在，它就能重新定位。这一点直接决定了这套方案在真实App里的存活率。1.2 从“会聊天”到“会动手”：任务拆解是核心能力我一开始以为，只要对模型说一句“帮我打卡”就完事了。真跑起来才发现，模型能理解这句话，但它不知道你的打卡App长什么样、按钮藏在哪里、中间会不会弹广告。所以做智能体任务，核心不是写Prompt，而是把目标拆成“可执行步骤”。我自己的方法是先把流程写成伪代码：如果屏幕上有“打卡”App图标，点击它。等待App完成加载，识别“考勤打卡”入口。点击“定位打卡”或者“打卡”按钮。如果弹出“确认提交”弹窗，点击“确定”。验证屏幕出现“打卡成功”之类的提示，截图留证。这一步做得好不好，直接决定后面模型的具体表现。拆得越细，模型就越少产生歧义。AutoGLM的框架通常支持“任务指令 + 操作定义”的结构化输入，你可以把上面这种伪代码转成它认识的格式。这也是我最想让你先记住的经验：智能体不是魔法，它是把人的步骤感翻译给机器听。2. 环境准备：搭建一套极简的手机自动化实验环境2.1 物料清单：你需要准备的设备与安装包这套实验的最低配置很亲民，不用顶配旗舰机，但有些基础条件必须满足：一台Android手机，系统版本建议8.0以上，太老的无障碍接口不完整。开启开发者选项和USB调试，用于连接电脑查看日志、安装调试包。一个AutoGLM运行环境，可以直接拉开源仓库的代码自己编译，也可以用社区编好的预构建版本。一个GLM-4.7模型服务，两选一：本地部署（需要一张显存大点的显卡，或者用量化版本跑CPU）或者调用在线API。ADB工具包，电脑上装一个，方便做日志抓取和命令下发。需要说明的是，这里说到的AutoGLM和GLM-4.7并不是一套完整商业系统，更像是“轮子”。我们真正要做的，是把轮子装到自己的车上。我自己的实践是用一台闲置的老Android机当测试机，因为自动化框架要不断试错，主力机上装来装去容易影响日常使用。2.2 初始化配置：开通无障碍服务与必要的权限这是整套流程里最敏感也最关键的环节。手机自动化为什么普遍要开“无障碍服务”？因为Android系统出于安全考虑，不允许普通App直接替用户点击屏幕，无障碍服务是官方留出来的合法通道，原本是为了帮助视障用户操作手机。智能体框架正是借了这条通道，才实现的点击、滑动、读取控件内容。配置路径大同小异：设置 → 无障碍 → 已下载的服务 → 找AutoGLM对应的服务，开启即可。这里有个容易踩的坑：很多手机厂商会在后台杀掉无障碍服务，特别是某些主打“省电优化”的机型，明明设置好了，过几个小时再一看，服务已自动关闭。解决办法是在系统设置里把智能体App锁定后台，多任务卡片上点锁，部分激进系统还需要在电池优化里设置为“不限制”。除了无障碍，还要给摄像头权限吗？不需要，AutoGLM默认抓取屏幕截图，不需要拍照权限。但存储权限要开，因为截图文件要落盘；位置权限要谨慎处理，比如打卡App会要求定位，那是App自己的权限请求，属于自动化执行过程中的正常交互。2.3 模型服务接入：本地部署还是在线API？参数怎么选AutoGLM本身只是个“手”，负责操作手机。GLM-4.7才是“脑子”，负责看屏幕、出决策。所以第二步是把两者串起来。我以我自己的环境举例。本地部署方案：下载GLM-4.7对应的开源权重，用标准推理脚本启动本地服务，监听特定端口。内存和显存是主要门槛，我是量化版本加载，大约占用不到16G显存，CPU模式也能跑，但每一步决策可能要等几十秒，体验比较痛苦。在线API方案更省心，注册之后拿一个密钥，在AutoGLM配置里填上接口地址和模型名即可。这里有个重要的参数经验：温度temperature要调低，比如0.1～0.3。原因很简单，自动化操作需要稳定，不需要创造力。温度太高，模型同一任务十次能给你出十种不同写法，执行起来非常不稳定；温度低一点，它倾向于输出保守、可预测的操作序列。另一个参数是max_tokens，关于这个我要多说两句：模型既要输出动作，又要输出验证条件，给太少会导致动作被截断，建议至少给到1024以上，复杂任务给2048。3. 自动打卡落地：从Prompt设计到端侧部署的完整流程3.1 定义打卡任务的“动作序列”：状态机思考法忠实用户已经知道，「说一句话私AI就自动打开App操作」的难度在于，模型需要随时判断当前处于流程的哪一步。所以我建议在Prompt中用“状态机”的思路，把任务划分成多个封闭的状态：初始状态：桌面状态A：打卡App首页状态B：登录页状态C：考勤页面终态：打卡成功每个状态干什么、如何判断进入下一状态，全部在Prompt里写清楚。相当于给模型一张地图，而不是让它瞎猜。以我实际使用的模板为例，任务描述部分我会这样写：任务：在XX打卡App上完成打卡。 你可以使用的操作： - tap(text)：点击包含指定文本的控件 - input(text)：在输入框填入文本 - wait(秒)：等待界面加载 - back()：返回上一级 - screenshot()：截取当前屏幕 - verify(text)：断言当前屏幕出现期望文本 请严格按以下状态顺序执行： 1. 如果屏幕不在打卡App，先打开App。 2. 等待进入App首页，寻找“考勤打卡”或“打卡”按钮。 3. 点击打卡按钮后，如果出现定位授权或提交确认弹窗，选择允许或确定。 4. 每步执行后截图，并输出当前状态为OK或FAIL。 5. 当屏幕出现“打卡成功”字样时，停止操作，输出最终结果。这段Prompt没有华丽的词藻，但模型理解起来非常准确。别把提示词写成“请你帮我打卡”，那是不负责任的。好的任务描述应该像给实习生写SOP，一条一条列清楚。3.2 执行与验证：为什么每一步都要“截图证明”我最初版本的Prompt没有验证步骤，模型一股脑往下点，结果点错了还在继续，甚至退出打卡App回桌面了。后来我才加上了“verify”这一步，就是上一步操作完成后，必须截图确认预期界面出现，再进入下一步。本质上这是给智能体加了一道“自检回路”。如果某一步验证失败，模型应该停下来，而不是硬着头皮执行后面的步骤，或者盲目重试。在实际运行中，这个设计救了我很多次。比如打卡按钮被广告弹窗挡住，验证失败后模型停下来报告“未找到目标控件”，我再针对弹窗增加一条处理规则，整个流程才变稳。这里有一个特别细节的处理：等待时间。App加载慢是常态，如果刚点完按钮立刻验证，大概率失败。我习惯在关键点击之后加一个wait(2～3秒)，等页面稳定后再验证。参数别写死太长，否则一次打卡要半分钟，人早自己点完了。3.3 定时触发：让它每天自己跑起来流程跑通只是第一步，能做到“每天到点自动执行”才算真的解放双手。定时触发我试过两条路线：第一条是手机本地的自动化工具，设定每天固定时间发出一个任务广播，唤醒AutoGLM去执行打卡任务。这个方案的好处是不依赖电脑，但要求自动化工具与AutoGLM之间能通信，有些时候要写一点简单的任务脚本来桥接。第二条是电脑端定时器，每次到点通过ADB向手机下发一条执行命令。优点是可操控性强，日志也好收集；缺点是手机要连着电脑，或者在同一局域网内开启网络调试。我最后采用的是手机端定时方案。具体实现不复杂：在自动化工具里添加每天09:00的打卡任务，动作是启动AutoGLM并传入任务ID。我还做了一个保护逻辑：如果当天已经打卡成功，就跳过执行，避免重复提交。这一点建议所有做自动化的朋友都加上，没人想因为脚本抽风再跑一遍流程的。3.4 从命令行到无人值守：一次完整的真实运行记录为了让概念更具体，我把一次真实运行的日志简化一下，大概是下面这个样子：[09:00:01] 任务启动：打卡任务 [09:00:02] 当前界面=桌面，开始查找图标 [09:00:05] 执行 tap("考勤打卡") [09:00:08] wait(2秒) [09:00:10] 截图验证，发现登录页，进入状态B [09:00:11] 执行 input("手机号") [09:00:13] 执行 input("密码") [09:00:15] 执行 tap("登录") [09:00:19] 截图验证，发现首页，进入状态C [09:00:21] 执行 tap("上班打卡") [09:00:23] 弹窗出现，exec da("确定") [09:00:26] 截图验证，发现“打卡成功”，任务结束整个流程26秒，而我自己手动操作通常也要15秒左右，这个效率完全可接受。而且中间不需要我的任何干预，模型像一个非常听话的实习生，每一步都会先看再动。第一次跑通那会儿我真就坐在旁边看着，有种在带新人的感觉。4. 实操中踩过的坑：误触、弹窗、网络白屏与界面变化4.1 弹窗拦截与误触：一招解决“模型被广告带走”手机App最大的敌人不是人脸识别，是五花八门的弹窗。打卡App时不时弹出“签到有礼”“升级提示”“红包领取”，模型第一步点打卡按钮还好，万一弹窗刚好出现在按钮上面，它可能就点进广告页里出不来了。我的处理方法是给Prompt加一条“弹窗优先”规则：任何一步执行前，先截图检查是否出现“关闭”“跳过”“取消”等弹窗关闭按钮，如果出现且内容与当前任务无关，优先点击关闭，再执行原计划操作。这条规则写进去之后，任务成功率至少提高了三成。别小看这一句，弹出拦截本质上就是智能体在动态世界中保持目标稳定的能力。4.2 网络白屏与等待时长：别让模型在加载页里硬刚打卡App偶尔会出现白屏或加载动画停留很久的情况。模型如果看到白屏，它会敏感地认为“目标控件不存在”，然后给出FAIL，白白打断流程。后来我在验证逻辑里增加了一个“等待确认”机制：当预期控件未出现时，先等待2秒再截图确认，如果连续两次确认仍失败，才判断为异常。这个机制的好处是大幅减少误报。但你也别太乐观，有些App加载要十秒以上，2秒根本不够。再狠一点的处理是设一个“最大等待时长”，比如15秒，超过这个时间就判定网络异常并停止任务。杜绝了模型卡在加载页里反复重试直到把流量耗尽的情况。4.3 UI版本更新：当按钮名字从“打卡”变成“完善信息”打卡App没人会承诺UI永远不变。某次小版本更新后，按钮文字从“上班打卡”改成了“开始考勤”，模型找不到目标控件，整个流程就断了。这是所有自动化方案都会遇到的宿命问题。但是我发现一个增强鲁棒性的写法：在Prompt里给按钮准备别名。比如“寻找打卡相关按钮（可能叫：打卡、开始考勤、上班打卡、签到）”。模型在语义理解上的优势在这里体现出来了，就算文字有所变化，它也能通过上下文推断出哪个是打卡入口。这比传统自动化脚本里写死一个坐标或者一个固定控件ID要坚强得多。4.4 重复打卡与幂等保护这条是血的教训。有几次定时任务执行时，打卡结果还没弹出来，模型以为失败了，又重新点了一遍，结果当天出现了两条打卡记录，被HR提醒过一次。所以我在任务描述里明确加了“幂等”这个约束：执行前先查看当天是否已有打卡记录，如果有，立即停止。模型看到“已打卡”标识就不会再执行。这个逻辑建议所有自动化任务都内置，不只是打卡，涉及资金、数据写入类的操作尤其要注意。5. 从打卡到更多场景：把手机变成个人AI工作流5.1 场景迁移：自动回复、订餐、信息整理整套方案跑通之后，你会发现手机上的重复劳动窗口基本都被打开了。同原理可以迁移的场景我列几个：自动查天气并整理出行建议，早上推送通知。自动回复工作群里的固定问候，比如“收到”。自动打开外卖App，按预设订单完成订餐。自动整理短信里的验证码，汇总到备忘录。自动把公交卡、地铁App里的余额截图存到账本。每一个场景的落地方式和打卡任务完全一样：拆步骤 → 写状态 → 加验证 → 设触发。我给朋友演示的时候，经常会说这不是做一个App，而是给你手机配置一名“数字员工”，你只负责定目标，具体操作它来做。5.2 边界与安全提醒：能自动化的，不等于该自动化的提到这里我必须泼一盆冷水：手机自动化越强大，越要克制。涉及密码输入、支付转账、人脸识别等敏感操作，我不建议交给智能体全自动执行。不是技术上做不到，而是一旦出现误触发或指令被污染，后果远超过省下的那点时间。比较稳妥的模式是“半自动”：智能体负责导航和操作，遇到支付确认之类的关键节点，停下来等人类点头。隐私方面也要心里有数。你要给AutoGLM赋予非常高的系统权限，它相当于能替你在手机上做几乎任何事。所以尽量只在一台专用手机上跑，别在主力手机上装；任务Prompt里也别写明文密码，尽量用系统级的密码管理方式去处理，或者干脆只做免登录的流程。5.3 给新手的入门建议：从小任务开始，先不要贪多如果你也想把手机改造成自己的AI实验室，我的建议是从一个特别小、特别无风险的任务开始，比如“自动打开天气App并截图”。这个任务不涉及任何敏感操作，即使跑砸了也没什么损失。跑通之后再逐步增加步骤，比如登录、填表、跨App跳转。每增加一个环节，就多观察一次日志，确认稳定后再管下一个。另外不建议一上来就折腾本地模型部署。先接在线API把流程跑通，理解智能体的工作方式之后再考虑离线部署。很多人在环境配置这一步就被劝退了，其实是把顺序搞反了，工具是次要的，核心是把“拆解任务”和“设计验证”这两个思维练出来。我在实际使用中最大的体会是：把手机交给AI不难，难的是你信不信任它。信任不是靠感觉，是靠一步一步的验证堆出来的。当你看到打卡App在无人工干预的前提下，每天准点完成那套流程，并且在状态日志里留下“验证通过”四个字，你会觉得这块手机屏幕，确实就是一个真正属于你的小实验室。