卡内基梅隆大学造了26个假App，测试AI手机助手有多懂你

这项由卡内基梅隆大学主导的研究发表于2026年6月，论文编号为arXiv:2606.09764，有兴趣深入了解的读者可以通过该编号查询完整论文。

你有没有想过，如果手机里住着一个真正懂你的AI助手，它能帮你做什么？不是那种你说"帮我查一下天气"、它老老实实回答"今天20度"的简单助手，而是一个真正了解你生活的助手——它知道你常去哪家餐厅、你跟哪些朋友借过钱、你下周有个飞往纽约的航班、你的银行卡余额不太够再多刷一次。这样的助手，才算真正有用。

问题在于：现有的AI测试，根本没法考出这种能力。现有的测试方式就像让厨师考试时只问"怎么切洋葱"，从不考"如果锅里已经有了昨天剩下的食材，你今天该做什么菜"。这就是卡内基梅隆大学的研究团队注意到的核心缺口。他们决定亲自动手，建造一个能真正测出"懂你"这件事的手机AI基准测试，这个测试叫做**iOSWorld**。

一、为什么要造一个假的手机世界来测AI

研究团队发现，当前所有针对手机AI助手的测试，都把任务限定在一个"孤立的沙盒"里——就好比让一个人在完全陌生的酒店房间里执行任务，房间里没有任何属于他自己的东西，他不知道自己是谁、不知道自己平时有什么习惯，也不知道外面的世界发生了什么。这种测试的结果，只能说明AI能不能按按钮，而不能说明AI是否真的帮到了你这个真实的人。

更具体地说，现有的测试几乎全部集中在安卓手机或者电脑桌面上，而iOS（苹果手机操作系统）虽然占据了美国超过58%的手机市场份额、全球活跃设备超过25亿台，却几乎没有专门针对它的AI测试。这个空白非常明显。

于是研究团队做了一件听起来有点疯狂但实际上很合理的事：他们从头开始建造了26个完整的iOS应用程序，这些App涵盖了一个真实人类数字生活的几乎全部场景——银行、打车、外卖、旅行预订、社交聊天、健身记录、餐厅订位、购物、待办事项……然后，他们给这26个App注入了同一个虚构人物的完整生活数据。这个人叫**乔丹·艾弗里（Jordan Avery）**，居住在旧金山，在一家叫Northstar Studio的公司做自动化工程师，正在训练半程马拉松，下周有一班从旧金山飞纽约的航班，每月给朋友Arnav转650美元房租，最近在Chipotle点了外卖……

这26个App里的数据彼此关联、互相印证，就像真实生活一样。在外卖App里点了一单Chipotle，银行账单里就会出现对应的扣款，邮件收件箱里也会有收据。SkyTrip里记录的航班，和StayFinder里的酒店预订日期对得上，Notes里还有提醒。每一条数据都不是孤立存在的，它们构成了乔丹这个人完整的数字足迹。

这就是iOSWorld的核心野心：不只是测试AI能不能完成一个动作，而是测试AI能不能理解一个人。

二、三种难度的考题，层层递进考验AI助手

研究团队设计了133个测试任务，按照难度分成三大类，就像学校里的小测验、期中考和期末考一样，逐级递进。

最基础的一类叫"单App任务"，共27道。这类题只涉及一个App，考的是最基本的操作能力，例如在DineSpot（类似OpenTable的订餐App）里搜索旧金山有户外座位的餐厅，然后给Harborline Seafood订一个今晚7点、两人的位子；或者在QuickChat（类似WhatsApp）里搜索"Brooklyn Half"，找到提到这个词的对话，然后回复确认已经报名。这类任务的目标是确认AI能正常使用一个App。

第二类叫"多App任务"，共60道，也是三类中数量最多的。这类题要跨越2到8个App，把信息从一个地方搬运到另一个地方。举个例子：检查QuickBite（类似DoorDash）里最近一次Chipotle的订单，然后去MyBank（类似Chase银行App）查找对应的刷卡记录，接着在Mail里找到收据邮件，最后把有没有价格差异这件事记录在Notes里。另一道题则是这样：查看StayFinder里卡塔利娜岛的行程（4月18日到21日），查看那几天的天气预报，再翻出TasteRank（类似Beli美食榜单App）里"想去尝试"清单上有没有附近的餐厅，最后把所有信息整理进Notes。

第三类叫"记忆与个性化任务"，共46道。这类题是真正考验"懂你"的难题。题目不会告诉AI应该去哪里找答案，AI必须自己去探索、发现、推断。比如：看看CityRide（类似Uber的打车App）的使用记录，分析我最常走哪条路线，然后按照这条路线叫一辆车。或者：翻阅TrailBlaze（类似Strava的运动记录App）里的跑步数据，推断出我平时的跑步规律和偏爱的路线，查看天气App看我平时跑步时间段的天气状况，然后给我的跑步群发条消息。这类任务平均需要跨越4.4个App，因为推断一个人的习惯，往往需要从多个数据源里拼凑线索。

这133道题并非凭空捏造，而是由一个AI编程助手（Claude Code）仔细阅读每个App的源代码和种子数据之后生成的，确保每道题都有真实答案。然后，人工标注员把每道题都在模拟器上亲自走了一遍，验证可行性。最初生成的175道候选题里，有44道因为存在问题——比如不存在的航线、对不上的食物名称、指向无法到达的App界面——被修正或淘汰，最终留下133道有效题目。

三、AI助手的两种"视力"：只能看屏幕，还是还能看无障碍数据

在测试这些AI的时候，研究团队设计了两种不同的条件，就像测试一个外科医生——一种是让他用普通灯光做手术，另一种是给他配上高清头灯和放大镜。

第一种条件叫"仅视觉模式"。在这种模式下，AI每一步只能看到手机的截图，就像普通人用眼睛盯着屏幕。它必须从像素里判断哪里有按钮、哪里有文字、点哪里才能前进。屏幕截图分辨率为706×1536像素，坐标系统是0到1000的范围。AI能做的操作包括：点击某个坐标、输入文字、滑动屏幕、按Home键、等待几秒、以及宣布任务完成并给出答案。

第二种条件叫"视觉+XML模式"。在这种模式下，AI除了看截图，还能额外收到一份由苹果开发者工具XCUITest提取的"无障碍树"——这是一份以XML格式呈现的界面元素清单，告诉AI当前屏幕上每个可交互元素的类型（比如按钮、文本框、列表项）、它的名称、当前显示的值、在坐标系统里的精确位置，以及一个用于程序识别的ID。在这种模式下，AI额外获得了两种能力：可以直接用元素ID精准点击，无需估算坐标；还可以用App的包名直接跳转打开某个App，不用在主屏幕上用眼睛找图标。

这两种模式的区别很重要。研究团队明确指出：在真实部署的环境里，一个消费级AI助手只有"仅视觉"这种能力，因为XCUITest是苹果专供开发者的工具，普通App无法调用。所以"仅视觉"的得分反映的是现实中能达到的水平，而"视觉+XML"则代表一个理论上限——如果系统有特权访问界面数据，AI能达到多好。

四、六个AI选手的真实发挥：从不及格到勉强及格

研究团队测试了六个AI系统，包括五个商业前沿模型和一个开源模型。商业模型方面，测试了Anthropic公司的Claude Opus 4.6和Claude Sonnet 4.6、OpenAI的GPT-5.4和GPT-5.4 Mini，以及Google的Gemini 3 Flash。开源模型则是Qwen3.5 35B-A3B，这是阿里巴巴团队发布的一个混合专家架构模型，总参数量350亿但每次激活的只有30亿。每个模型在两种条件下各跑一遍，共12种配置，每次任务最多允许走50步。

成绩说出来可能有点令人意外。在"视觉+XML"模式下，表现最好的是Claude Opus 4.6，整体通过率达到了52%。它在单App任务上拿到了81.5%，在记忆与个性化任务上拿到54.3%，但在多App任务上只有36.7%。Claude Sonnet 4.6紧随其后，整体46.6%，单App任务甚至高达92.6%。GPT-5.4整体39.8%，而Gemini 3 Flash整体只有28.6%。

开源模型Qwen3.5在两种模式下都表现不佳，"视觉+XML"整体只有10.5%，"仅视觉"也只有12.8%。更奇特的是，当你给它加上XML数据，它的表现不但没提升，反而在多App任务上从6.7%直接跌到了0%。

从"仅视觉"模式来看，所有前沿商业模型的整体通过率都挤在20%到29%之间，Sonnet和Opus以29%和26%领跑，而Gemini虽然通过率只有27.8%，但每道题平均只需要21步就能结束，而Anthropic和OpenAI的模型平均要走42到45步，效率上Gemini更高。

还有一个有趣的反转现象：GPT-5.4 Mini在加上XML数据后，通过率从26.3%跌到了15.8%，有22道原本能过的题变成了失败。研究团队发现，XML数据大概每步会多增加约3100个token（可以理解为AI处理信息的基本单位），这对GPT-5.4 Mini来说已经超过了它有效处理的上限，信息越多反而越乱。这说明某些模型在容量上存在瓶颈，更多信息不一定带来更好表现。

五、为什么XML的帮助如此巨大，以及失败的三种方式

加上XML数据之后，强模型的提升幅度非常显著：Opus从26.3%上升到51.9%，整整涨了25.6个百分点；Sonnet从28.6%涨到46.6%；GPT-5.4从20.3%涨到39.8%。

这么大的提升背后，原因其实并不神秘。在只能看截图的情况下，iOS手机存在几个让AI特别头疼的问题。密密麻麻的界面让坐标估算非常容易出错，一个小小的切换开关可能只有几像素宽，视觉判断稍有偏差就点错了位置。从主屏幕切换App需要找到图标，但图标也可能在不同页面，这本身就是好几个步骤的障碍。iOS没有安卓那种通用的返回键，返回必须靠界面左上角的按钮或者从屏幕左边缘向右划，这个操作很多AI基本不会主动用——研究数据显示，在总计12255次滑动操作里，只有133次（1.1%）是左边缘向右的返回滑动。

研究团队统计了422个前沿模型在"视觉+XML"模式下的失败案例，把失败原因分成三类。最常见的是"耗尽步数"，占51%——AI没干完就用完了50步的预算，通常发生在多App任务（55%）和记忆任务（52%）上。第二类是"放弃了"，占26%，指AI在没完成任务的情况下提前停止，最终得分低于67%，GPT-5.4 Mini有47%的失败属于这种。第三类是"过早停止"，占23%，指AI差不多快做完了但停早了，最终得分在67%以上，这种情况在单App任务里最多（48%）。

Qwen3.5的失败模式则完全不同。它在加上XML之后，有约50%的失败案例是陷入了重复动作的死循环——比如在设置6:45闹钟这个简单任务里，它在时间滚轮上连续发出了38次一模一样的向下滑动操作，从第6步到第46步，既没改成正确时间，也没设置标签，也没点保存，就这样把50步预算全部浪费掉了。

六、一个五应用综合财务分析的成功案例，以及三个让人扼腕的失败案例

研究团队在论文里展示了几个具体的运行轨迹，让人对AI的实际表现有更直观的感受。

Opus在"视觉+XML"模式下成功完成了一项需要跨越五个App的财务汇总任务。任务要求是："给我一个全面的财务情况总览。检查MyBank的账户余额、SplitPay的待处理请求、MegaMart的订阅情况、FreshCart的即将送货订单，以及CloudDocs里的预算表格，并预测下个月的支出。"Opus在第3步就从MyBank里拉出了账户余额，第7步查看了SplitPay里的待还款记录，第22步打开了CloudDocs里的预算追踪表格，第28步写完了跨越五个App的综合分析，全程只用了29步，满分通过。

另一个成功案例是Opus完成了一个DineSpot订位加TeamChat通知的连续任务——在DineSpot找到一家旧金山有户外座位的餐厅并订了位，然后跑去TeamChat的#general频道把预定细节发给团队。"视觉+XML"版Opus用22步完成，而同一个模型在"仅视觉"模式下则卡在了外卖结账页面的一个小小支付确认开关上，用完50步都没打开TeamChat，最终得分只有0.20。

失败的案例同样具体。Opus在一个通勤模式分析任务里走到了第24步才到达MyBank的交易记录界面，但等到第50步预算用完时，CloudSheets里的数据还没录完，最终得分0.45。GPT-5.4在一个叫车任务里，把出发时间和预计费用都查对了，却在走了8步之后停在了最后"请求打车"的按钮面前，没有点那个按钮就宣布完成，得了0.80分。还有一个记忆任务，Opus翻查了Notes里的生日信息、在QuickChat里找到了家人的讨论、在MegaMart里找到了合适预算范围内的礼物，但等它想去DineSpot订餐厅时，50步已经耗尽，被加入等候名单了事，得分0.50。

七、用步数换精度，以及评分的公正性如何保证

每道题最多50步的限制，并不是随意定的。研究团队绘制了"步数预算-通过率曲线"，发现单App任务在走到第20步时就基本饱和了，再多走也没什么提升空间。多App任务则一直到第40步都还在持续改善，说明这类任务本身需要更多操作空间。记忆与个性化任务的曲线则参差不齐，Opus在走到第30步时整体通过率只有17%，但到第50步时跳到了54%，说明这类任务的后半段存在大量关键突破，截断太早会严重低估其能力。

至于评分的公正性，研究团队采用了"LLM-as-a-Judge"的方式——用GPT-5.4 Mini来批改每一道题。批改时，它会看到整条操作轨迹（包括每一步的截图和操作记录）以及AI最终给出的答案，然后根据配套的评分标准（每道题有4到13条可独立核查的评分细则，平均8.4条）给出一个通过或失败的判断。

为了验证这个自动批改有没有偏差，研究团队找了4个人工标注员，在128条Opus轨迹上独立打分，然后与AI批改进行对比。结论是：任务级别的一致性达到89%，Cohen's kappa值为0.77（这是衡量两个评判者之间一致性的统计指标，0.77属于"高度一致"的范围）。细则级别的kappa为0.69，Pearson相关系数为0.85，说明两者对同一批数据的判断高度吻合。148处分歧里，AI偏宽松（把失败判成通过）79次，偏严格（把通过判成失败）69次，没有明显的系统性偏向。

研究团队还测试了换用其他AI来当批改员会不会影响结论，结果发现Gemini 3 Flash、GPT-5 mini等换用其他批改员后，结论基本一致。唯一的异常是GPT-5.4（完整版）当批改员时，它会过度严苛地拒绝，在128条轨迹里只有1个误判为通过，却有27个误判为失败，是所有批改员里表现最差的。

八、给开源模型装上专属工具，表现能翻倍

研究团队还做了一项有趣的额外实验，专门针对表现最差的Qwen3.5开源模型。这个实验的目的是验证一个猜想：Qwen3.5之所以表现差，到底是因为它脑子不够用（模型能力不足），还是因为给它的操作工具太笨拙（界面工具不合适）？

实验做法是：保持模型、任务、评分和50步预算都不变，只把操作工具换掉——把原来那7个通用动作（点击、滑动、输入等）换成专门为每个App定制的高层工具，比如caltrack.log_food（记录一餐到CalTrack里）、mybank.send_zelle（用MyBank发一笔Zelle转账）。这套定制工具通过MCP（模型上下文协议）服务器提供，截图依然保留，但操作的颗粒度从"点这个坐标"变成了"执行这个语义动作"。

结果很说明问题：通过率从12.8%跳升到24.8%，平均评分细则完成度从0.33提升到0.683，几乎翻了一倍。同样一个Qwen3.5模型，面对同样的133道题，仅仅因为手里拿到了更好用的工具，成绩就大幅提升。不过即便如此，它依然落后于所有前沿商业模型，说明工具固然重要，基础能力也是瓶颈。

从论文附录里展示的具体案例可以看出差距的来源：同一道DineSpot订位题，Qwen3.5用定制工具17步完成并满分通过，而用通用工具则在筛选菜单上卡了整整50步，最后连预约都没做到，只得了0.25分。

九、这项研究还留下了什么，以及未来还能走多远

iOSWorld作为一个开源测试平台，在发布时包含了所有26个App的完整源代码、乔丹·艾弗里这个人物的全部种子数据、133道测试题及其评分细则，还有评估代码和一个AWS云跑通方案——因为跑这个测试需要macOS和Xcode，不是人人都有Mac电脑，所以研究团队提供了EC2管理的Mac云实例，让没有苹果硬件的研究人员也能提交任务。

从数字的角度来看当前的局限性也很清晰：最好的模型组合（Opus + 视觉+XML）整体才过了52%，而多App任务只有37%。51%的失败案例是在走完50步之后依然没做完任务。这意味着当前的AI在处理真实生活的复杂连环任务时，依然存在相当大的能力缺口。研究团队在结论中指出，要关闭这个缺口，需要三方面的进展：更强的循环检测与自我纠错能力（避免反复做同样的事）、更精准的视觉定位能力（在密集界面里准确点到目标），以及能够感知用户历史数据的规划能力（真正把乔丹是谁、有什么习惯融入推理过程）。

此外，iOSWorld目前只有一个虚构用户（乔丹·艾弗里）。研究团队已经开放了种子数据框架和任务生成流水线，任何人可以按照同样的方式创造一个新的虚构人物并生成对应的任务集，支持未来的多用户、多场景评测扩展。

归根结底，这项研究做的事情听起来很简单：造了26个假App，塞进一个虚构人物的生活数据，然后考了几个AI助手。但它真正挑战的问题却很深刻——一个AI助手，到底算不算懂你？现在的答案是：懂一点，但远远不够。单独用一个App时还凑合，一旦任务需要跨越多个App、调用你的历史和习惯，最聪明的AI也只能做到一半。手机里那个"懂你的助手"，还需要走很长一段路。

Q&A

Q1：iOSWorld测试和现有的手机AI测试有什么不同？

A：iOSWorld的最大不同在于它给AI注入了一个真实用户的完整生活数据。现有测试通常是让AI在空白App里完成孤立任务，而iOSWorld里的26个App全部共享同一个虚构用户乔丹·艾弗里的数据——银行账单、聊天记录、外卖历史、航班预订等互相关联，就像真实的手机一样。测试的任务也因此更难，需要AI跨多个App理解用户习惯并做出推断。

Q2：视觉+XML模式为什么能让AI表现好这么多？

A：加上XML数据之后，AI可以直接知道屏幕上每个按钮的精确位置和名称，不需要从截图里估算坐标。还能用App的程序ID直接跳转打开任何App，不必在主屏幕上找图标。这消除了iOS界面里的很多障碍，比如小按钮难点、切换App容易走错、没有通用返回键等问题。数据显示，Opus的整体通过率因此从26.3%提升到51.9%，涨了将近26个百分点。

Q3：Qwen3.5开源模型为什么在加上XML之后反而表现变差了？

A：主要原因是XML数据让每一步需要处理的信息量大幅增加，大约每步多出3100个token。对于Qwen3.5这个规模的模型来说，这超过了它能有效处理的上限，信息太多反而导致它频繁陷入重复动作的死循环——比如在同一个地方连续滑动38次都不知道换动作。这说明更多的输入信息并不总是有帮助，模型的处理能力本身才是瓶颈。