出门在外收到任务，我用 TRAE SOLO 把电脑“叫醒”干活

前言

周六下午，我在外面等朋友。

正刷着美团纠结吃什么，群里突然弹出一条消息：

"你前几天导入的那个定位插件，后台持续定位这块，Android 和 iOS 的逻辑是不是不太一样？"

看到这句话的时候，我沉默了大概三秒。

不是因为问题有多难，而是因为：没看到代码，我也不敢乱说。

这个定位插件我前几天确实刚接入过，印象里涉及 Android 前台服务、iOS 后台定位权限、坐标系转换这些逻辑。但具体文件在哪、入口函数叫什么、参数怎么传，我已经记不太清了。

开发最怕的不是"我不会"，而是"我好像知道，但代码不在眼前"。

以前遇到这种情况，我大概率会回一句：

"我晚点看一下。"

但以我的性格，回完这句话之后，接下来一整天都会有种"心里还挂着事"的感觉。

刚好这次在体验 TRAE SOLO 移动端，我就想试试：人不在电脑前，能不能先通过手机把电脑里的代码上下文拉出来？

于是我打开 TRAE SOLO 移动端，准备把电脑"叫醒"。

先找到插件入口

我没有一上来就让 AI 分析代码，而是先发了一句很简单的话：

帮我看一下当前项目里跟定位插件相关的目录结构，不要改代码，先把关键文件列出来。

很快，TRAE SOLO 把项目里的相关目录找了出来。

这个插件在 uni_modules 下面

目录结构大概是这样的：

go 复制代码

uni_modules/
  xxx-location/
    index.uts
    README.md
    package.json
    utssdk/
      interface.uts
      coord.uts
      app-android/
        index.uts
      app-ios/
        index.uts

看到这个结构，我脑子里的记忆开始拼起来了。

interface.uts 主要定义入参和返回值；

coord.uts 负责坐标系转换；

app-android/index.uts 是 Android 端实现；

app-ios/index.uts 是 iOS 端实现。

这一步其实挺关键。

很多时候临时处理问题，不是马上改代码，而是先知道自己该看哪里。尤其是这种跨端插件，Android 和 iOS 的实现分散在不同目录里，如果没有电脑，很容易只凭印象乱说。

而这次，我人还在外面，电脑已经开始替我翻项目了。

先看接口：这个插件到底暴露了什么能力

找到入口后，我继续让 TRAE SOLO 打开接口定义文件，重点看传参和返回值。

从接口上看，这个插件的配置项并不复杂，核心参数主要有这些：

makefile 复制代码

gps?: boolean
coordType?: string
background?: boolean
time?: number
distance?: number
onlyOnce?: boolean

简单整理一下：

gps 控制是否优先高精度定位；

coordType 控制输出 gcj02 还是 wgs84；

background 控制是否启用后台定位；

time 是定位时间间隔；

distance 是距离间隔；

onlyOnce 表示是否只定位一次。

返回值里除了经纬度、速度、海拔、精度这些常规字段，还包含了一些 GNSS 相关信息，比如：

复制代码

signalLevel
satelliteCount
usedInFixCount
cn0DbHzAvg

看到这里，我基本确认了一点：这个插件不是简单包一层系统定位 API，而是把持续定位、后台定位、坐标系转换，以及部分定位信号质量信息都封装进去了。

当然，这些字段在不同平台上的表现肯定不完全一样。Android 能拿到的信息会更多一些，iOS 侧通常不会暴露这么细。

这时候，我已经可以先在群里回一句：

"这个插件不是单纯 getLocation，它有持续定位、后台定位和坐标系转换。Android 和 iOS 的实现确实不一样，我再看一下启动逻辑。"

听起来像认真看过代码。

事实上，也确实是电脑替我认真看了代码。

Android：后台定位靠前台服务撑住

接着我让 TRAE SOLO 看 Android 端实现，重点关注后台持续定位相关逻辑。

Android 这边的核心思路可以概括成一句话：

如果开启后台定位，就需要先处理通知权限和前台服务，再启动定位监听。

也就是说，Android 后台持续定位不是简单调用一次定位 API 就完事了。它背后至少涉及这些环节：

复制代码

检查系统定位服务
申请前台定位权限
申请后台定位权限
检查通知权限
启动前台服务
注册定位监听
必要时注册 GNSS 状态回调
停止时移除监听并停止服务

这条链路只要漏掉一环，后台定位就可能表现得很玄学。

比如权限给了，但通知没开；

比如前台能定位，退到后台就停；

比如 GPS 有结果，但回调频率不符合预期；

比如系统定位服务没开，代码再努力也没用。

所以 Android 这边的重点，不只是"能不能定位"，而是要看权限、通知、前台服务和定位监听有没有完整串起来。

说得通俗一点：

Android 后台定位不是写一个函数那么简单，更像是跟系统规则打太极。

iOS：重点是 Always 权限和后台模式

Android 看完之后，我又让 TRAE SOLO 打开 iOS 端实现。

iOS 这边的代码看起来更短，但关键点也很明确。

如果只是前台定位，一般申请 When In Use 权限即可；

如果要后台持续定位，就需要 Always 权限，并且工程里要配置后台定位能力。

也就是说，iOS 这边更需要关注：

objectivec 复制代码

定位权限描述是否配置
是否申请 Always 权限
是否开启 UIBackgroundModes -> location
是否允许后台位置更新
distanceFilter 是否设置过大
系统是否限制后台定位

所以 Android 和 iOS 的排查思路并不一样。

Android 更关注前台服务、通知权限、后台定位权限；

iOS 更关注 Always 授权、后台模式和系统策略。

表面上都是"后台定位"，但底层完全是两套玩法。

这也是我这次想确认的重点：不能因为两个端都叫后台定位，就默认它们的实现逻辑一样。

坐标系转换也要顺手看一眼

继续往下看，我发现插件里还有一个 coord.uts，专门处理坐标系。

这个点也挺重要。

插件没有简单地把系统原始坐标直接抛出去，而是允许调用方通过 coordType 指定输出坐标系，大概支持：

复制代码

gcj02
wgs84

默认偏向 gcj02，如果调用方指定 wgs84，就返回原始坐标；如果需要在国内地图中展示，则会做对应转换。

很多定位问题表面看是"不准"，实际可能是坐标系没对上。

比如拿 wgs84 的坐标直接放到国内地图上，位置就可能出现偏移。所以这个插件把坐标系做成参数，至少给调用方留了选择空间。

这部分我也准备后面补到文档里：不要只写"返回经纬度"，还要说明默认坐标系是什么，什么时候需要切换。

让 TRAE SOLO 帮我整理排查清单

代码看得差不多之后，我没有立刻改插件。

一是手机屏幕确实不适合长时间改这种跨端代码；

二是这个问题本身更像是在问"应该怎么排查"。

于是我让 TRAE SOLO 根据刚才看到的实现，整理一份前后台定位问题排查清单，区分 Android 和 iOS。

整理后大概是这样：

markdown 复制代码

Android 排查重点：

1. 系统定位服务是否开启
2. 是否已授权前台定位权限
3. Android 10+ 是否已授权后台定位权限
4. Android 13+ 是否已授权通知权限
5. 前台服务是否成功启动
6. GPS_PROVIDER / NETWORK_PROVIDER 是否可用
7. time / distance 参数是否设置过大
8. onlyOnce 是否误设为 true
9. 停止定位时是否正确移除监听并停止服务

markdown 复制代码

iOS 排查重点：

1. 是否配置定位权限描述
2. 是否配置 UIBackgroundModes -> location
3. 是否拿到 Always 权限
4. background=true 时是否允许后台更新
5. pausesLocationUpdatesAutomatically 是否符合预期
6. distanceFilter 是否设置过大
7. App 退后台后系统是否限制定位

这份清单不算复杂，但很实用。

更重要的是，它不是 AI 凭空生成的一份通用建议，而是基于当前项目里的实际代码整理出来的。

如果没有代码上下文，AI 可能只能告诉我"检查权限、检查定位服务、检查系统设置"。但 TRAE SOLO 直接看了项目文件，所以它能围绕这个插件的真实实现来分析。

这就是我觉得它和普通聊天式 AI 不太一样的地方。

TRAE SOLO 真正帮到我的地方

这次我没有在手机上大改代码，也不建议在手机上硬改这种跨端定位插件。

屏幕小、上下文长、平台差异多，强行在手机上改，容易把自己写急眼。

但 TRAE SOLO 移动端确实帮我完成了几件事：

第一，它帮我远程找到插件目录，不用凭记忆猜文件在哪。

第二，它帮我快速梳理了接口参数和返回值，比如 background、coordType、time、distance 这些配置到底控制什么。

第三，它帮我对比了 Android 和 iOS 的实现差异。

Android 重点是权限、通知、前台服务和定位监听；

iOS 重点是 CoreLocation、Always 权限和后台模式。

第四，它帮我把代码逻辑整理成了一份排查清单，方便我在群里先把方向说清楚。

以前遇到这种情况，我人在外面，大概率只能回一句"晚点看"。

这次至少可以先把问题往前推进一步。

当然，它不能直接代替你去开发

体验完之后，我对 TRAE SOLO 移动端的定位反而更清晰了。

它不是让手机变成 IDE。

复杂重构、原生服务调试、权限兼容问题，最后肯定还是要回到电脑前处理。

但它很适合这种"临时需要看代码上下文"的场景：

复制代码

查目录
看接口
读核心函数
整理逻辑
生成排查清单
远程跑简单命令
把电脑端任务接到手机上继续问

这些事情以前必须坐到电脑前才能开始，现在可以先用手机推进一段。

对开发者来说，这个差别挺明显的。

因为很多工作不是一上来就写代码，而是先判断问题在哪、该看哪个文件、该怎么跟别人解释。

最后

朋友到的时候，我已经把这个定位插件的大概逻辑看完，也把 Android 和 iOS 的差异整理了出来。

群里那边我回了一段：

这个插件 Android 后台定位主要靠前台服务和通知权限撑住，iOS 主要看 Always 权限和后台 location mode。坐标系默认走 gcj02，也可以切 wgs84。具体问题我晚点回电脑再测，但排查方向基本是这些。

我人还在外面，电脑已经先上班了。

而且它干的不是"帮我写一段看起来像代码的东西"，而是真的打开项目、看插件、读接口、梳理实现。

这大概就是我理解的移动端 AI 办公：

不是在手机上硬写代码，而是在电脑不在眼前的时候，依然能把代码上下文叫出来。

所以这次体验之后，我对 TRAE SOLO 移动端的印象不是"手机也能写代码"。

而是：

出门在外，电脑没带，但代码不一定非得等我回去才开始看。