我不是小布丁
@xiaobuding
移动端开发的最后一块拼图补上了：mobile-mcp 开源项目把 MCP 接进移动设备自动化，让 AI 直接操控并测试真实手机（仓库：github.com/mobile-next/mo… ）。
它解决的痛点很具体：以前用 AI 写 App，模型能飞快把 Flutter／Swift／Kotlin 代码写完，可一到运行调试，你还是得手动安装、点屏幕、查断点——写码和验证之间断了一层。
mobile-mcp 把这层接上了：跨 iOS 与 Android（含模拟器与真机）、开箱对接 Claude Code、Codex、Gemini 这些 agent；AI 终于从"代码生成器"进化成"端到端测试工程师"——启动应用、模拟用户手势、实时校验 UI 逻辑与状态，全是它自己来。
这个补位正好把今晚"一个写、一个挑"那条线推完整。Jane Street 让 agent 互相挑错，讲的是逻辑层的审；这条补的是手指层的验——代码对不对，终究要点开跑一遍、滑一下看看动不动。写与测都进了 agent 的手，从生成到验收的链条才真正闭环；缺这一环的团队，写得再快也要人肉点屏幕，速度全卡在验证断点上。
它设计里最值得抄的是那个取舍：结构化指令大于暴力视觉。给模型发全分辨率截图看着直观，实则烧 token 还容易被渲染超时骗出假报错；mobile-mcp 走的是通过 MCP 暴露底层无障碍树（UIAutomator／XCUITest）——拿结构化的控件树代替像素。
这与本周反复出现的方向又一次对上：PageIndex 用树代替碎片、Nimbus 让文档可机读、这条用控件树代替截图——三件事不同领域，同一个答案：能给结构就别给像素，能给事实就别给形容。省的是钱，赚的是稳定。
留一格清楚的边界：真机操控的权限与安全要自己盯好——能替你点屏幕的手，也能点错地方；"免费套餐""开箱即用"是项目方口径，实际适配多少机型、多少控件场景，得拿自己的 App 试；无障碍树方案在复杂自绘 UI 上的表现也未必理想。
给要做移动端 QA 的人一句落地的：挑你 App 里三个最常回归的页面，让 agent 走一遍完整流程（打开、输入、提交、看结果），记下它自己发现的断言数量和误报次数——发现比你手点的多、误报比你手写的少，这条链就可以交出去了；否则先从最稳的一个页面开始放权。
