★ FEATURED ARTICLE 最近圈子里讨论得最热闹的话题不是某个模型又刷了排行榜而是AI开始“动手干活”了。我连续几天刷到十几条消息说的都是同一件事AI在替你点外卖、AI在替你写周报、AI在替你排版幻灯片。有人管这波叫“AI Agent”有人叫“自动化助手”也有人直接说“AI接管设备”。叫法不一样但现象已经很明显——AI正在从“回答问题”走向“直接操作你的手机和办公软件”从操作 iPhone 上的 App 到驱动幻灯片自动生成背后都在构建同一个闭环理解界面、拆解意图、执行动作。这篇文章我准备把手头收集和实测过的 8 个方向的项目放到一起拆它们有的盯着手机屏幕有的扎进办公套件看起来是两拨人做的东西也不一样但核心逻辑完全同源。适合正在做智能体开发、办公自动化或者想搞清楚“AI 到底怎么控制软件”的读者。我已经跑通了其中几个的最小可用版本后面会直接给出可复现的思路和踩坑记录方便你自己落地。1. 8 个项目的全景扫描它们都在拆同一个闭环1.1 手机端项目把界面变成AI能看懂的语言先说手机这边的项目。有一个开源的 iOS 操作代理做的思路很有意思不依赖任何官方接口只管截图把屏幕像素变成“视觉语言”配合语音指令去判断用户想干什么。实际演示场景是用户对着手机说“帮我把相册里最近一张照片发到某聊天软件”项目通过连续截图、识别界面元素、模拟点击一步步完成。这套路本质是“长得像人一样看屏幕”。另一个项目走的是 Android 无障碍服务路线。无障碍服务本身是为了辅助视障用户设计的可以读取当前界面的控件树——相当于把屏幕上的按钮、输入框、列表项全部变成结构化数据。这个项目利用该能力实现跨 App 数据搬运比如从邮件里提取一串确认码自动切到银行 App 粘贴并提交。相比纯视觉方案它在 Android 上更稳速度也更快因为拿到的控件信息不是“猜”出来的而是系统给的精确位置。还有一类项目聚焦通讯场景比如通话与消息的智能代理。它做的事情是根据来电上下文判断是否需要代接再结合用户预设的规则生成回复内容。比如开会时来电话自动识别出是快递就回复“放门口”识别出是推销直接挂断并拉黑。这类项目把“自动操作”和“语义决策”结合得特别紧本质上已经不是简单的脚本而是有判断力的代理。最后一个是跨 App 工作流的调度器。它把“截图识别元素—执行点击—校验结果”封装成可编排的流水线支持把多个 App 的操作串成一个任务。比如早上打开某新闻 App 签到、去某购物 App 领积分、再到记账 App 记一笔开销三分钟的人工操作它每晚自动跑一遍。这个项目虽然不是纯 AI 驱动但 AI 承担了“动态识别新界面”的能力比传统定时脚本聪明得多。1.2 办公软件端项目从生成内容到驱动软件本身办公软件方向的思路更偏“生成 执行”。其中一个演示文稿自动生成项目输入一段大纲文本它会自动拆出章节结构、匹配模板版式、生成配图占位然后调用办公软件的扩展接口把幻灯片逐页写出来。我实测过十分钟能做出一个二十页的汇报初稿基础的排版和内容填充已经像模像样剩下要做的就是人工润色。表格方向有一个自然语言助手项目专门处理电子表格。它能把中文指令翻译成公式、格式规则、条件判断。最典型的例子是输入“把销售额大于一万的标成红色同时计算每个销售员的占比”它能自动生成条件格式脚本和统计公式并且直接写进表格文件。这个方向最难的不是生成公式本身而是理解表格的物理结构——哪一列是数值、哪一列是姓名、表头占几行。文档协作方向的项目集中在会议场景。有一个会议纪要机器人把录音转写、说话人分离、要点提取、待办生成串成一条流水线。转写完成后自动把会议结论整理成结构化摘要按“决定事项、待办清单、风险点”三个板块输出然后写入协同文档并通知相关人。它把“语音识别—语义理解—文档写入”三段能力捏在了一起。还有一个邮件与日程助理项目逻辑是读取邮件内容自动起草回复建议并识别邮件里的时间地点信息生成日程条目。比如收到一封“周五下午三点碰一下项目进度”的邮件它自动创建日程事件、设置提醒、回一封确认邮件草稿。我 实测最省心的一点是它不会直接发送只生成草稿和日程用户点确认就算完事既省时间又不会翻车。1.3 这 8 个项目的共同底座感知、理解、执行把上面这 8 个项目并排放能看出一个非常清晰的共性每条链路都有三段式结构。第一段是感知层负责把界面变成 AI 能理解的输入。手机端靠截图、无障碍节点、控件树办公端靠文档结构、单元格坐标、段落样式。第二段是理解层也就是调度大模型把用户指令和界面状态对齐大模型在这里不负责生成文章而是负责“读懂界面布局判断下一步动作”。第三段是执行层通过模拟点击、调用扩展接口、写入文件等操作把意图落到实际动作上。过去几年大家做的自动化是基于规则的脚本只要界面变了脚本就废。现在这批项目把 AI 塞进中间层界面的动态变化由视觉和理解能力来兜底脚本只负责最后执行。这带来的变化不只是“更聪明”而是整套自动化逻辑从“写死”变成了“看懂再操作”。理解了这一点后面看每个项目都不会迷路。2. 手机操作 AI 的核心原理与边界2.1 感知层人看的是“画面”机器要的是“结构”手机操作 AI 最关键的一步是感知。人类看一眼屏幕就知道“右上角有个关闭按钮”但机器不知道。机器有三种方式拿到界面信息第一种是截图后做视觉识别AI 模型直接看图标注出每个元素的位置和含义第二种是通过系统辅助接口读控件树拿到按钮的文本、坐标、类型第三种是混合模式截图为主、结构信息为辅互相校准。这里要纠正一个常见误解很多朋友以为视觉方案更通用、更“高级”实际用下来正好相反。在 Android 上只要目标 App 没有特殊防御控件树方案又稳又快因为位置是系统给的不存在误判。而视觉方案的优势在于“没有接口也能跑”比如 iOS 上无法读取任意 App 的控件树只能靠截图。两个方案不是二选一而是互补。我在实测中发现一个比较隐蔽的坑无障碍服务读到的控件树在 WebView 场景下经常是乱套的按钮文本和实际显示不一致。原因是 Web 页面有自己的 DOM 结构系统把它转译成无障碍节点时经常丢信息。这时候只能靠视觉方案兜底。所以在设计感知层时我强烈建议做成“双通道”优先结构信息遇到异常自动切换到截图识别。2.2 理解层大模型的任务不是“聊天”而是“决策”感知层拿到界面信息后接下来要交给大模型做决策。这一步的核心工作是把用户意图映射到界面元素上。比如用户说“帮我把亮度调低”模型看到屏幕上有“设置”“显示与亮度”等元素就需要规划出动作序列先进入设置、找到亮度滑块、计算要拖动的距离、执行拖动并检查结果。这里的关键不只是“看懂界面”还包括拆解长任务。很多操作不能一步完成模型需要把目标拆成多步并在每步之后重新检查界面状态决定继续还是修正。我测试下来用「截图序列 操作历史 用户指令」作为输入比单张截图单独推理准确率高很多。原因很简单界面状态是动态的AI 必须知道“上一步发生了什么”才能判断“下一步该怎么办”。我在工程里还会给模型加一个“安全动作白名单”。像点击、输入、滑动这类低风险动作允许直接执行但涉及删除、支付、发送消息等不可逆操作必须经过用户确认。这样设计不是为了限制智能而是为了兜底。大模型的幻觉问题目前还解决不了它的判断偶尔会错得离谱如果没有这层护栏一次误操作的成本是用户无法接受的。2.3 边界意识哪些事坚决不适合交给手机 AI虽然这些项目看着很酷但边界感一定要有。我目前的判断是高频、低风险、流程固定的操作最适合交给手机 AI比如签到、填表、数据搬运、消息归类。这类操作做了几千遍模式稳定出错的影响也很小。高风险操作暂时别碰比如支付、批量删数据、自动发送对外消息。不是技术上做不到而是责任界定不清楚。有一次我测试一个自动整理短信的项目它把一条银行验证码短信误判成营销信息差点归档掉。这类问题一旦发生用户不会管是“模型幻觉”还是“配置错误”结果都是不信任。权限最小化原则必须执行到位。我给手机项目授权的范围通常只有读取当前界面、模拟点击、截图。定位、通讯录、短信这类敏感权限不该给就绝对不给。有些方案为了省事直接申请系统级权限这是在给自己埋雷。自动化工具的底线是可以技术激进但权限必须克制。3. 办公软件 AI 驱动的底层逻辑与实现路径3.1 演示文稿生成核心不是内容是版式控制演示文稿自动生成项目看似是让 AI 写内容实际最花功夫的是版式控制。我拆过类似项目的逻辑发现它内部维护了一套模板库每套模板定义了标题字号、正文位置、配色方案、图片占位规则。AI 拿到大纲后第一步不是写文字而是“分页”——根据内容密度把大纲切成若干页再为每页选择合适的版式。分页是一个容易被低估的难点。一句话和三段话不能放同一页配图和纯文本页的版式也不同。我见过的最靠谱做法是让模型先输出一个“页面内容块”结构每块标明类型标题页、要点页、图文页、数据页再由程序匹配模板。这样比让模型直接控制坐标稳定得多因为模型擅长结构理解不擅长像素级排版。生成之后还有一步容易被忽略校验。生成完的幻灯片经常出现文字溢出、图片遮挡文本框的问题。好的项目会调用办公软件接口做一轮自动化检查测量文本框宽度和内容长度发现溢出就自动缩小字号或换版式。这一步的效果直接决定了交付物能不能直接拿去用而不是“看起来差不多要手动改半天”。3.2 表格自然语言处理困难在于理解“表格物理结构”表格方向的项目最难的部分不是公式生成而是“读懂表格的物理结构”。一个表格文件里可能有合并单元格、多级表头、空行、标签页同样的“销售额”可能出现在不同列。模型需要先把这些结构信息解析清楚才能把自然语言指令映射到正确的单元格范围。我在测试一个中文指令转公式的项目时就遇到过这个问题。用户说“计算每个月的增长率”但表格里月份是横向排列的而模型默认按纵向理解生成的公式引用范围完全错误。后来项目组调整了策略先把整个工作表的结构信息用表格方式序列化包括行列号、合并关系、数据类型再喂给模型推理。效果提升非常明显。这里给一个非常实用的建议处理表格任务时不要直接用截图让模型看一定要先生成结构化的“表头-行列-样例值”数据。大模型对 JSON 结构的理解远强于对坐标和视觉的感知。把表格转成结构化文本再推理准确率能提升一大截而且调试也更方便出错了能直接看到是哪一行引用错。3.3 文档协作自动化把语音、文字、任务流串成一条线会议纪要和邮件日程助理这类项目技术含量不在单一环节而在“串联”。语音转写已经很成熟摘要提取也不难难的是把转写文本里的“周五下午三点”正确解析成日程事件把“张总说需要跟进”正确归类到待办清单并且把结果无损地写入文档系统。我拆解过一个会议纪要项目它的处理链条是这样的先做说话人分离和转写然后按时间窗切分转写文本每一段都标注说话人接着让大模型做结构化提取输出“决定事项”“待办任务”“风险问题”三类条目最后通过文档扩展接口写入指定位置。整个过程看起来很顺但任何一个环节出问题都会传导到下一步。传输链路最容易坏的是中间那一步——结构化提取。转写文本是口语化的很多东西说不完整“这个方案还是得推”“他说下周二之前给结果”。模型要理解指代关系判断“他”是谁“这个方案”指哪个方案。所以我建议在这类项目里把“上下文窗口”拉长把参会人列表、会议主题、子议题一并喂给模型而不是只给孤立的一句话。上下文越完整提取的准确率越高。4. 实操复现从零搭一个能操作手机屏幕的最小 Agent4.1 技术选型和环境准备纸上谈兵没意思我直接分享一个可落地的最小方案。目标是让 AI 通过看屏幕截图理解用户指令然后操作手机完成一个简单任务。技术栈我选的是Python 3.10 某商用大模型视觉接口 ADB 调试桥。手机端使用 Android 更有优势因为 ADB 可以直接执行点击、滑动、截图操作不需要绕弯。环境准备步骤如下先安装 Python 和 ADB手机开启开发者模式并连接电脑确认adb devices能识别到设备。大模型接口只需要申请一个带视觉能力的 API Key。整个过程不涉及 App 注入也不需要 root所以风险很低适合拿来练手。这里重点说明一下选型逻辑为什么用 ADB 而不是无障碍服务因为做最小 Demo 时ADB 的指令最直接adb shell input tap x y一行命令就能点击日志也清晰。无障碍服务虽然更接近实际问题场景但需要写一个完整 App 并配置权限调试成本高。先用 ADB 跑通闭环再替换执行层是正确的节奏。4.2 核心代码骨架感知-决策-执行三步走完整的代码逻辑可以分成四段截图、理解、解析动作、执行点击。我把核心骨架贴出来稍微改一下就能跑import base64 import json import subprocess import time import requests def get_screenshot(): 通过 adb 截图并转成 base64 返回 subprocess.run([adb, exec-out, screencap, -p, , screen.png], shellTrue) with open(screen.png, rb) as f: return base64.b64encode(f.read()).decode() def ask_model(screenshot_base64, instruction): 调用大模型视觉接口输入截图和指令输出结构化动作 prompt f 你是一个手机操作助手。请分析当前屏幕截图理解用户指令并规划操作。 用户指令{instruction} 请严格输出 JSON格式为 {{action: tap | swipe | input | done | error, params: {{x: 100, y: 200, text: 可选}}, reason: 简要说明你的判断依据}} 只输出 JSON不要输出其他内容。 resp requests.post( https://api.example.com/v1/chat/completions, headers{Authorization: Bearer YOUR_API_KEY}, json{ model: vision-model, messages: [ {role: user, content: [ {type: image_url, image_url: {url: fdata:image/png;base64,{screenshot_base64}}}, {type: text, text: prompt}, ]}, ], }, timeout30, ) return json.loads(resp.json()[choices][0][message][content]) def execute_action(action): 根据模型输出的动作结构执行 adb 命令 if action[action] tap: x, y action[params][x], action[params][y] subprocess.run([adb, shell, input, tap, str(x), str(y)]) elif action[action] swipe: x1, y1 action[params][x1], action[params][y1] x2, y2 action[params][x2], action[params][y2] subprocess.run([adb, shell, input, swipe, str(x1), str(y1), str(x2), str(y2)]) elif action[action] input: text action[params][text] subprocess.run([adb, shell, input, text, text.replace( , %s)]) else: print(任务结束或出错, action) def run(instruction, max_steps5): for step in range(max_steps): screenshot get_screenshot() response ask_model(screenshot, instruction) print(f步骤{step 1}: {response[reason]}) if response[action] done: print(任务完成) break execute_action(response) time.sleep(2) if __name__ __main__: run(帮我把屏幕亮度调到最高)这段代码的思路非常直接截图送给模型模型返回 tap/swipe/input 指令程序用 ADB 执行然后截图再看结果循环直到模型认为任务完成。实际运行时有几个参数需要重点调每步之间的等待时间截图后要等界面渲染稳定、最大步数防止模型陷入死循环、以及 prompt 里对 JSON 格式的严格约束。我建议把max_steps设置成 5 到 8 步步数太少任务做不完太多容易失控。4.3 参数细节与容错设计最容易被忽略的是“屏幕坐标精度”问题。大模型看到的截图分辨率和手机屏幕实际分辨率不一定一致。比如截图是 1080x2400模型输出的坐标也是在这个坐标系里的但某些设备有系统导航栏占位。我建议在执行点击前先做一次坐标比例校准模型输出的坐标除以截图宽高再乘以实际屏幕宽高。容错设计绝对不能少。我给这个 Demo 加了三层保险第一层是“动作前的状态检查”截图给模型的同时附带一个提示词“如果目标已经在当前屏幕请不要重复点击”。这能显著减少连续点击同一个位置的蠢问题。第二层是“重复动作检测”记录最近三个动作如果模型连续输出完全相同的 tap 坐标直接判定异常并停止。第三层是人工确认开关在execute_action里加一个--dry-run参数只打印动作不真正执行用于测试阶段调试。5. 常见问题与排查技巧实录5.1 坐标偏差导致点不准坐标偏差是新手最常遇到的问题。表现是模型明明看到了按钮在“中间”点击后却没有任何反应。原因通常有几种截图分辨率与执行坐标不一致、系统导航栏和状态栏让有效区域偏移、部分 App 有顶栏悬浮球会压住真实按钮。我的排查顺序是先确认截图尺寸与手机实际分辨率是否一致再看 UI 缩放比例开发者选项里的“最小宽度”设置对坐标影响很大最后在代码里把点击坐标可视化点完立刻截一张图用红点标注点击位置一眼就能看出偏到哪里。大部分坐标问题都是缩放造成的校准一次即可根治。5.2 页面异步加载导致状态误判第二个高频问题出现在含网络请求的页面。模型点击了“查询”按钮截图时页面还在转圈模型认定“没有反应”于是又点一次。连续点击导致重复提交结果查询了两次甚至弹出了重复数据。这个问题在跑实际项目时特别常见。解决方案是引入“等待机制”每执行完一个动作不要立刻截图先调用adb shell dumpsys activity或者简单粗暴地sleep 1.5秒。更项目的做法是在截图后让模型多判断一个字段“页面是否处于加载状态”如果是加载状态就直接返回“待定”不执行任何操作。加载状态识别可以通过元素检测或者视觉判断来完成。5.3 模型幻觉声称点击了实际没有执行有一次测试中模型返回的 JSON 里action字段是done理由是“亮度已经调到最大”。我看了截图亮度根本没变。这就是典型的模型幻觉——它根据屏幕元素的视觉特征自己“脑补”了执行结果。这种问题没法完全消除只能通过工程手段缓解。我目前的做法是在模型决策前给它一个“状态对比”提示词把上一步截图和当前截图都发过去让它先判断“从上一帧到这一帧界面有没有变化”再决定下一步。因为大模型对图片前后的差异判断能力很强一旦意识到“图片没变”就不会再幻想操作已经完成。这个技巧帮我把这类幻觉降低了七八成。5.4 自动化操作的安全自查清单不管项目规模大小上线前都要过一遍安全自查。我整理了一份固定检查清单检查项具体要求权限范围只申请当前任务必需权限敏感权限能免则免高风险操作删除、发送、支付类操作必须强制人工确认执行日志每一步动作都留日志包括坐标、原因、时间戳失败熔断连续失败或异常动作达到阈值立即停止数据隐私截图和文字内容不做持久化存储用完即删人机退出任何时候用户说“停止”都要能立刻终止任务这份清单看起来简单实际每一行都踩过坑。比如“执行日志”这条最开始我嫌冗余没加后来一个自动操作出错用户质疑是软件点了删除按钮翻了半天没有任何记录根本没法排查。从那以后我宁可多写日志也不能让操作变成一个黑盒。安全不是锦上添花是这类项目的底线。6. 实操之后的经验沉淀跑完这几个方向的 Demo我对“AI 接管手机和办公软件”这件事有了更具体的判断。先说一个比较反直觉的体会技术难点不在 AI 模型本身而在“工程缝合”。模型的理解能力现在已经够用了真正花时间的是把截图、坐标、控件树、文档接口这些零散工程组件稳妥地串起来并做好容错。哪一环不稳整个链路就垮掉。另一个深刻体会是不要贪心。刚开始做这类项目最容易犯的错是想一步到位做一个“万能助手”什么任务都能接。我做第一个 Demo 时也是这样结果各个场景互相干扰稳定性差到没法用。后来改成“单任务深度优化”先只做“整理验证码并归档”这一个场景把准确率做到能接受再横向扩展效果立刻不一样。如果你现在正准备上手我的建议非常明确先挑一个频率高、风险低、边界清楚的小场景比如“把网页表格导出成本地文件”或者“把会议录音生成待办清单”跑通一遍完整的感知-理解-执行闭环。跑通之后你自然会理解哪些环节有坑、哪些参数要调再决定要不要扩大到更复杂的任务。方向是对的剩下的就是动手把脏活累活干一遍。
阅读完成 · 觉得有帮助？
