我希望 TraeCode 未来可以打通从“代码”到“真实设备”的最后一公里。
介绍自己
我是一名后端开发，平时也会折腾一些 iOS、Android 和跨平台应用。
同时，我还是一名 16GB 内存 MacBook Pro 用户。
这句话为什么要单独说出来？
因为做移动端开发的时候，我经常感觉自己不是在开发 App，而是在进行一场：
“谁先把我的内存吃完”的生存竞赛。
TraeCode 要跑。
IDE 要跑。
浏览器几十个标签页舍不得关。
有时候后端服务、数据库、Docker 也在后台默默活着。
这时候如果再打开一个模拟器，活动监视器里的内存压力就开始逐渐变得喜庆。
所以我一直有一个很朴素的愿望：
既然我手边本来就有一台真手机，为什么还要让 Mac 再辛苦地模拟一台假的？
我希望未来 TraeCode 可以直接连接真实手机，让真机成为 AI 可以观察、理解甚至参与操作的运行设备。
我对 TraeCode 的愿景
希望新增什么功能
我希望未来手机端也可以安装一个轻量版 Trae。
比如我正在开发一个 iOS、Android、Flutter 或 React Native 应用。
电脑打开 TraeCode，手机打开 Trae，通过：局域网自动发现、扫码配对、USB、Wi-Fi等方式建立安全连接。
连接完成后，我的手机直接出现在 TraeCode 的设备面板中。
比如：
Devices
-
iPhone —— 已连接
-
Android —— 已连接
-
iPad —— 已连接
之后 TraeCode 可以实时看到真机上的应用画面。
我可以直接告诉它：
帮我看看手机上这个页面为什么有问题。
然后我拿起手机正常操作。
TraeCode 在电脑上同步观察整个过程。
但我希望它做的并不仅仅是“远程投屏”。
真正有价值的是：
让手机画面成为 TraeCode 调试上下文的一部分。
它可以同时结合：手机实时画面、当前设备型号、系统版本、App 运行日志、网络请求、当前页面、UI 层级、项目代码、我的操作路径，一起分析问题。
这样真机就不再只是一个“显示 App 的屏幕”，而是成为 TraeCode 可以理解的运行环境。
为什么我觉得这项能力很有必要
现在如果 AI 想直接参与移动端调试，最容易想到的方案就是启动模拟器。
模拟器当然很好用。
但作为一名 16GB MacBook 用户，我对“再开一个模拟器”这几个字多少有一点心理阴影。
开发的时候，电脑上可能已经同时运行着：
TraeCode、IDE、浏览器、后端服务，偶尔再来一个 Docker。
这个时候模拟器一开，我就会下意识看一眼活动监视器。
然后发现：
内存压力从“还行”逐渐进入“大家都别动”的状态。
项目再大一点，编译再猛一点，可能就开始出现一种很有移动开发特色的场面：
App 还没跑起来，风扇先跑起来了。页面还没开始掉帧，Mac 先开始掉帧了。Bug 还没定位，我先开始考虑要不要关浏览器。有时候最让我纠结的甚至不是代码，而是：“这个 Chrome 标签页到底舍不舍得关？”
所以我会觉得，未来如果 TraeCode 本身越来越强，Agent 还要分析代码、运行命令、处理上下文，那么再让电脑额外承担一套虚拟手机环境，其实是在让有限的资源继续互相抢。
但问题是：
**我的桌子旁边明明就躺着一台真 iPhone。**它有自己的 CPU，自己的 GPU、内存、操作系统、传感器。而且它才是最终真正运行这个 App 的地方。
那为什么不能让：
电脑负责 TraeCode 和开发。
手机负责运行 App。
各干各的。
别再让我的 16GB 内存一个人扛下所有。
第二个问题更重要：
模拟器始终不是真手机。
移动应用和 Web 最大的区别之一，就是它和真实硬件、真实系统环境联系非常紧密。
例如：相机、麦克风、蓝牙、陀螺仪、蜂窝网络、弱网、内存压力、GPU性能、温升、不同厂商系统。很多移动端问题在模拟器里根本体现不出来。
比如：
模拟器上页面丝滑得像发布会 Demo，到了真实老手机上却像 PPT。
模拟器里键盘弹出一切正常，真机上直接把底部按钮顶到失踪。
Wi-Fi 环境下图片秒开，切到地铁里的蜂窝网络以后开始表演“永远加载中”。
标准 Android 环境没问题，换一台不同厂商的手机，权限流程突然有了自己的想法。
还有相机、蓝牙、陀螺仪这类功能，本身就高度依赖真实硬件。
所以我觉得未来移动端 AI 调试真正重要的方向，不应该只是：
让 TraeCode 更会操作模拟器。
而应该进一步做到：
让 TraeCode 直接进入真实设备。
希望优化什么场景
我最希望优化的是移动端开发中的：真机调试。
例如我正在开发一个 App。
运行到真机以后，我发现某个页面有问题。
现在的操作通常是：
手机发现问题，截图或者录屏，回到电脑。告诉 AI：“我刚刚点了这里，然后页面变成这样。”复制控制台日志。再让 AI 根据描述猜测问题。
整个过程中：
人其实是在充当手机和 AI 之间的信息中转站。
而且这个中转站表达能力还不一定稳定。
有时候我会对 AI 说：
“就是那个按钮，往下一点，旁边那个，不是这个，是刚才那个页面里的那个。”
说完我自己都觉得信息质量堪忧。
但如果 TraeCode 能直接连接手机，这个流程可以完全改变。
我可以直接说：
Trae，我现在操作一遍，你帮我看看。
然后：打开 App，进入某个页面，点击按钮，键盘弹出来，页面突然错位。
此时 TraeCode 已经看到了全过程。
我只需要问：
为什么刚才键盘出来以后按钮消失了？
TraeCode 就可以结合：真机画面 + UI 状态 + 运行日志 + 当前代码直接分析。
这时候 AI 不再需要让我努力描述：“那个按钮好像往下面跑了一点。”
因为：它自己看见了。
我甚至希望进一步支持：
AI 真机测试
例如我告诉 TraeCode：
帮我测试一下登录和注册流程。
TraeCode 可以在真实手机上协助完成：打开 App，点击注册，填写输入框，申请系统权限，上传照片，切换页面，完成注册，整个过程中持续检查：
-
有没有崩溃
-
有没有白屏
-
有没有页面错位
-
有没有明显卡顿
-
按钮是否可以点击
-
接口是否报错
-
权限流程是否正常
一旦出现问题：
自动保存当时的手机画面、运行日志、操作路径以及关联代码。
最后输出：
真机测试报告。
甚至修改代码以后，可以再次在同一台手机上执行刚刚的测试流程。
最终形成：
修改代码 → 真机运行 → AI 观察 → 发现问题 → 修复 → 重新真机验证
这样一个完整闭环。
希望如何融入我的工作流
我希望它最终可以成为 TraeCode 一个很自然的一级能力。
就像现在开发环境里有：Files、Terminal、Git、Browser。未来也可以增加：Devices
打开以后，就是我当前可以连接的真实设备。
例如：iPhone、Android 手机、iPad、Android 平板
甚至以后可以继续扩展到：Apple Watch、Wear OS、电视、车机、IoT 设备。
这样 TraeCode 理解的不再只是：
“这段代码是什么。”
还可以理解：
“这段代码最终运行在什么设备上，以及它在那里到底表现成什么样。”
你希望它以什么形态出现
我希望整个过程尽可能简单。
移动端设备安装 Trae。
电脑打开 TraeCode。
第一次使用扫码完成安全配对。
之后在同一个局域网里，可以自动发现之前授权过的设备。
TraeCode 左侧或者底部增加一个：
Devices / 真机设备
面板。
点击设备以后，可以看到：实时手机画面、当前运行 App、设备信息、系统版本、App 日志、网络请求、CPU / 内存 / FPS、测试记录
然后最重要的是：
这些信息全部可以直接提供给 Agent。
我不需要学习复杂的新操作。
依然是在 TraeCode 聊天框里直接说：
看一下手机现在这个页面。
或者：
我操作一遍，你帮我找 Bug。
或者：
对比一下 Android 和 iPhone 上这个页面有什么区别。
甚至如果同时连接一台 iPhone、一台 Android 和一台平板：
TraeCode 可以同时运行并观察三个真实设备。
帮助检查：
不同平台的布局差异；
不同尺寸设备的适配问题；
Android 和 iOS 行为差异；
真实设备上的性能问题。
这对于跨平台开发尤其有价值。
最后，我并不是觉得模拟器应该被替代。
模拟器依然非常适合快速开发、系统版本切换和大规模自动化测试。
但我希望 TraeCode 可以给移动端开发多一个选择：
不要总是在电脑里创造一台假的手机。
毕竟我的 MacBook 只有 16GB 内存。
它已经很努力了。
真的。
有时候，
直接看看我手里的这台真的就好了。
我特别期待未来某一天：
当 App 在真机上出现一个奇怪问题时，
我不需要再截图、录屏、复制日志，然后努力向 AI 描述：
“刚才我点了一下这里，然后它好像动了一下，接着页面就不对了……”
我只需要说一句：
Trae，你看一下我的手机。
然后它回答：
看到了。
这时候我就可以放心地把模拟器关掉。
顺便再多开两个 Chrome 标签页。
