用Trae+Kuikly搞定开源鸿蒙跨端应用开发实战解析

开源鸿蒙（OpenHarmony）应用开发圈子里，跨平台方案一直是个让人纠结的点。这半年我一直在折腾 KuiklyUI 生态，试着用 Kuikly 搭一套能同时跑在 OpenHarmony 和 Android/iOS 上的跨端工程，而真正把开发效率拉起来的，是搭配了 Trae 这个 AI 编程工具。这篇文章就把我用 Trae 开发 Kuikly-OH 跨端应用的全过程、踩过的坑和现在的效率玩法完整梳理一遍，给正在选型或者已经入坑开源鸿蒙跨端开发的朋友一个参考。

我默认读这篇文章的人已经对 OpenHarmony 应用开发有基本认知，至少知道 DevEco Studio 怎么建工程、hvigor 是干嘛的。如果你连 ArkTS 和 ArkUI 都还没摸过，建议先花一周过一遍官方入门文档，再回来看这玩意儿，否则有些细节你会看得比较吃力。但如果你已经在用 ArkUI 写页面，又被它的跨端能力搞得头疼，那这篇文章应该能帮你打开一个新思路。

1. 为什么是 Kuikly + Trae 这个组合

1.1 开源鸿蒙的跨端痛点

OpenHarmony 原生的 UI 开发框架是 ArkUI，配合 ArkTS 语言，搞声明式 UI 开发确实比早期的类 Web 写法舒服不少。但你要是真正把一个业务工程落地，就会发现几个绕不开的问题。首先是 ArkTS 的生态相对年轻，三方库少，很多在 Android/iOS 上随手一拉的依赖，到了 OpenHarmony 上要么没有，要么版本滞后。其次是语言壁垒，ArkTS 虽然语法接近 TypeScript，但整个工具链、组件模型、状态管理思路和前端生态不完全一样，前端团队切入需要成本，客户端团队切入又觉得别扭。

这个背景下，跨端方案就成了很多团队的救命稻草。我试过 Flutter 的 OpenHarmony 分支，社区还在早期，很多插件要自己补；React Native 那边也有厂商在适配，但性能和原生能力打通一直有争议。真正让我觉得思路对路的，是 Kuikly 这套方案。它的核心思路是用 Kotlin 写 UI 代码，通过自研的 DSL 语法映射到各端渲染引擎，目前已经有可用的 OpenHarmony（Kuikly-OH）、Android 和 iOS 支持。一套业务代码，三个平台跑，而且 UI 层是自绘的，不像 WebView 方案那样有性能天花板。

1.2 Trae 在这个链路里的定位

工程选型只是第一步，真正干活的时候，我发现自己被大量模板代码和 API 记忆拖住了。Kuikly 的 DSL 语法虽然简洁，但组件有哪些参数、修饰符怎么组合、状态管理怎么绑，这些细节不可能全记在脑子里。我去翻文档的频次高得离谱，一个页面写完，文档切换了十几次。

Trae 在这个链路里解决的就是这个痛。它是一个 AI 编程 IDE，底层接了大模型能力，能理解你整个工程上下文，而不只是当前打开的那个文件。我用它写 Kuikly 页面的时候，只需要描述清楚页面长什么样、要什么交互，它能直接给出可编译的 Kotlin 代码，连 import 都不用自己手敲。更实用的是它的 Agent 模式，你让它“去把这三个页面的通用组件抽出来”，它会自己去翻你的目录结构、看现有代码风格、然后动手改，而不是像普通补全工具那样只在你光标位置接一句话。

我没有一上来就吹它有多神，因为实际用起来，它也有不少让人血压升高的时刻。但至少在 Kuikly-OH 这个领域，Trae 对 Kotlin 语法的理解深度、对工程结构的感知能力，比我之前用过的几个 AI 插件都要强。后面我会详细拆解它的正确用法和翻车现场。

2. 环境准备与工程初始化

2.1 工具链清单

在碰代码之前，先把工具链理清楚。用 Kuikly 开发 OpenHarmony 应用，不是一个 DevEco Studio 就能搞定的，它牵扯到 Node 环境、包管理器、OpenHarmony SDK、还有 Kuikly 自己的命令行工具。我把这套环境在 Windows 和 macOS 上都搭过一遍，踩了不少坑，这里直接给你一份能用的清单。

这里面最容易被忽略的是 Node 版本。我第一次装的时候，系统里是老旧的 Node 12，跑 Kuikly 脚手架直接报错，提示语法不支持。后来切到 18 才消停。如果你用的是公司统一发的办公电脑，环境变量里可能还有一堆历史遗留的 Node 路径，建议先 node -v 看清楚到底走的哪个版本，再动手。

DevEco Studio 的版本也要注意，太老的版本对 OpenHarmony SDK 的支持不完整，有些新 API 在编译期就过不去。我用的做法是把 DevEco 升级到最新稳定版，SDK 也一并更新，虽然偶尔会遇到插件缓存冲突，但整体比守着旧版本强。

2.2 创建 Kuikly-OH 跨端工程

环境齐了之后，创建工程本身不算复杂，但有几个顺序问题值得说道说道。

先用 npm 安装 Kuikly 的脚手架工具，这一步很简单：

bash复制npm install -g kuikly-cli

装完之后，执行创建命令：

bash复制kuikly create MyCrossApp

它会问你选择支持哪些平台，我选了 OpenHarmony、Android、iOS 三个。这里有个细节：如果你一开始只选了 OpenHarmony，后面要加 Android 平台，手动往工程里补模块会非常痛苦，因为涉及 Gradle 配置、依赖仓库、还有资源目录结构。所以哪怕你现在只想先跑 OpenHarmony，也建议把后面可能用到的平台都勾上，用不到的时候别碰对应目录就行。

创建完成后的目录结构大致是这样：

code复制MyCrossApp/
├── shared/                 # 跨端共享代码，Kotlin 写的核心业务逻辑和 UI
├── ohos/                   # OpenHarmony 工程模块，内含 entry 应用入口
├── android/                # Android 工程模块
├── ios/                    # iOS 工程模块
├── build.gradle.kts        # 根 Gradle 配置（Android/iOS 构建用）
└── settings.gradle.kts

核心逻辑都在 shared 模块里，用 Kotlin 编写，通过 Kuikly 的 DSL 编写 UI。ohos 目录则是一个标准的 OpenHarmony 工程，里面会有 entry/src/main/ets 这类目录，但你会发现这里面的代码很少，它只是一个壳工程，负责加载并渲染 shared 模块里定义的 UI 内容。

这种“壳 + 核心”的架构是 Kuikly 跨端的关键。你在 shared 里写的业务代码，编译期会分别打到各个平台的包里去，各平台只负责提供一个渲染容器。这也是它和 WebView 方案的核心理由：最终运行的是原生渲染，不是网页。

2.3 DevEco Studio 打开工程的方式

创建好的工程不能直接双击打开，尤其是 ohos 目录，需要用 DevEco Studio 的“导入”功能，选到 ohos 目录这一层，让它识别为 OpenHarmony 工程。很多人在这里犯迷糊，把整个 MyCrossApp 目录拖进去，结果 DevEco 完全识别不了。

导入之后，DevEco 会自动解析工程结构，然后弹窗提示你下载依赖，主要是 ohpm 的包。这里有个网络问题：ohpm 默认源在国外，国内环境下载慢到离谱，甚至直接失败。你需要在 ~/.ohpm/.ohpmrc 或者 DevEco 的 SDK 配置里，把 registry 换成国内镜像源。这一步不做，后面每一步都会卡。

配置好之后，先别急着写代码，跑一次空编译。DevEco Studio 里点击 Sync 按钮，等它把依赖都拉下来，编译一次，确保壳工程能正常生成 HAP 包。这一步通过了，环境才算真的准备好。

2.4 Trae 工程配置

Trae 这边相对简单，直接导入工程目录就行。它会自动识别工程的构建系统和文件结构，建立索引。这里我建议你花十分钟做两件事，后面用起来会省很多事。

第一，在工程根目录建一个项目规则文件，Trae 支持通过 .trae/rules 目录来配置项目级的规则说明。这个文件是给 AI 看的上下文，你要把工程的架构写清楚，比如：

markdown复制# MyCrossApp 工程开发规则

这是一个使用 Kuikly 框架的跨端工程。
核心业务代码位于 shared 模块，使用 Kotlin 语言编写。
UI 层使用 Kuikly 的 DSL 语法，禁止直接使用 Android Compose 或 SwiftUI 的 API。
OpenHarmony 壳工程位于 ohos 目录，业务代码请勿修改 ohos/entry/src/main/ets 下的文件。
状态管理使用 Kuikly 提供的 state/event 机制，不要引入外部状态库。

为什么要写这个？因为 Trae 的模型默认对 Kotlin、Compose 这类技术栈的理解更偏向 Android 原生开发。如果它不知道你在写 Kuikly，它就很容易给你生成一堆 Compose 风格的代码，运到 OpenHarmony 上直接编译失败。规则文件等于给它划定了一条边界，让它别跑偏。

第二，配置好模型参数。Trae 支持多家模型接入，我自己主力用 Claude 系列，代码生成的准确率明显更高。如果你用默认模型觉得不满意，别急着抱怨，先看看是不是模型选型的问题。预算有限的话，DeepSeek 这类国产模型也能跑，就是复杂代码的推理深度差一些，生成的代码要多花点时间改。

完成这两步，环境就算真正准备好了。下面进入实操环节，我会用一个待办事项应用作为例子，完整走一遍用 Trae 开发 Kuikly-OH 页面的流程。

3. 用 Trae 开发一个跨端页面的完整实操

3.1 需求拆解与提示词设计

很多人用 AI 编程工具，都是甩一句话过去，比如“帮我写个待办页面”，然后 AI 生成的东西又糙又没法用，就说这工具不行。实际上，Prompt 质量直接决定输出质量。这不是玄学，是模型特性决定的：你给它的信息颗粒度越细，它越能在合理范围内做推演。

我做一个待办事项的跨端页面，会先在心里把需求切成三层：数据层、逻辑层、展示层。数据层要有一个待办事项的列表，包含 id、标题、是否完成、创建时间这些字段，最好带本地持久化。逻辑层要有新增待办、勾选完成、删除待办这些操作。展示层就是列表页面的 UI，包含输入框、添加按钮、列表项、空态提示。

然后我会把这三层需求描述给 Trae，用一条多行的提示词：

text复制在 MyCrossApp 工程的 shared 模块中，新建一个 TodoPage 页面，使用 Kuikly 的 DSL 语法。

需求说明：
1. 数据模型 TodoItem，包含 id（String）、title（String）、isDone（Boolean）、createdAt（Long）。
2. 使用 Kuikly 提供的状态管理能力维护一个可变列表 todos。
3. 页面顶部是文本输入框和添加按钮，点击添加按钮把输入内容生成 TodoItem 并加入列表。
4. 列表使用 LazyColumn 实现，每个列表项左侧是 Checkbox，右侧是标题文本，已完成项的文字显示删除线。
5. 支持滑动或点击删除按钮移除待办项。
6. 列表为空时，显示“暂无待办事项”的文案。
7. 所有 UI 组件和修饰符，请使用 @kuikly 包下提供的 API，不要使用 Compose 的 androidx API。

生成后请附上需要 import 的完整包名列表。

我故意在最后强调了两件事：用 Kuikly 的 API，以及输出 import 列表。前者防止它跑偏到 Compose 写法，后者方便我快速检查它有没有引入不该引入的东西。

3.2 生成核心代码与逐段校正

Trae 根据上面的提示词，生成了一大段代码。这里我挑几个片段展示，不是贴完整代码，重点是让没接触过 Kuikly 的朋友感受一下 DSL 长什么样。

数据模型和状态管理这部分，它生成的是这样：

kotlin复制// shared/src/commonMain/kotlin/com/example/mycrossapp/TodoPage.kt

class TodoItem(
    val id: String,
    val title: String,
    var isDone: Boolean = false,
    val createdAt: Long = System.currentTimeMillis()
)

class TodoViewModel {
    val todos: ListState<TodoItem> = listStateOf(mutableStateListOf())

    fun addTodo(title: String) {
        if (title.isBlank()) return
        val item = TodoItem(id = UUID.randomUUID().toString(), title = title)
        todos.value.add(item)
    }

    fun toggleTodo(id: String) {
        val index = todos.value.indexOfFirst { it.id == id }
        if (index >= 0) {
            todos.value[index] = todos.value[index].copy(isDone = !todos.value[index].isDone)
        }
    }

    fun removeTodo(id: String) {
        todos.value.removeAll { it.id == id }
    }
}

这里有个值得说的地方：ListState<TodoItem> 和 listStateOf 是 Kuikly 的状态管理 API，不是 Android 的 MutableStateFlow。Trae 能准确用对这套 API，得归功于项目规则文件里那句“使用 Kuikly 提供的 state/event 机制”。如果少了这条约束，它大概率会生成 StateFlow 或者 Compose 的 mutableStateListOf，虽然逻辑差不多，但在 Kuikly 环境里可能用不了。

页面 UI 部分，它生成的是这样：

kotlin复制@Composable
fun TodoPage(viewModel: TodoViewModel) {
    var inputText by remember { mutableStateOf("") }

    Column(
        modifier = Modifier.fillMaxWidth().padding(16.dp)
    ) {
        Text(
            text = "待办事项",
            style = TextStyle(fontSize = 20.sp, fontWeight = FontWeight.Bold)
        )

        Spacer(Modifier.height(12.dp))

        Row(verticalAlignment = Alignment.CenterVertically) {
            TextField(
                value = inputText,
                onValueChange = { inputText = it },
                modifier = Modifier.weight(1f),
                placeholder = "输入新的待办"
            )
            Spacer(Modifier.width(8.dp))
            Button(
                onClick = {
                    if (inputText.isNotBlank()) {
                        viewModel.addTodo(inputText)
                        inputText = ""
                    }
                },
                modifier = Modifier.padding(start = 4.dp)
            ) {
                Text("添加")
            }
        }

        Spacer(Modifier.height(16.dp))

        if (viewModel.todos.value.isEmpty()) {
            Box(Modifier.fillMaxWidth().padding(vertical = 48.dp), contentAlignment = Alignment.Center) {
                Text("暂无待办事项", color = Color.Gray)
            }
        } else {
            LazyColumn {
                items(viewModel.todos.value, key = { it.id }) { item ->
                    TodoItemRow(
                        item = item,
                        onToggle = { viewModel.toggleTodo(item.id) },
                        onRemove = { viewModel.removeTodo(item.id) }
                    )
                }
            }
        }
    }
}

我一眼扫过去，整体风格是对的，但有两个细节要改。第一是 @Composable 注解，这是 Compose 的注解，在 Kuikly 里应该用 @KComponent 或者对应的 Kuikly 注解。第二是 remember { mutableStateOf("") }，这也是 Compose 的 API 体系，Kuikly 有自己对应的状态声明方式。

这恰恰印证了我前面说的：Trae 不是不能用，是它默认会往自己最熟悉的 Compose 语法上靠。处理方式很简单，不是让它整段重写，而是让它做局部替换。我会在后面接一句：

text复制把 @Composable 替换成 Kuikly 的组件声明注解，remember { mutableStateOf("") } 替换成 Kuikly 的状态声明方式。保持 UI 布局逻辑不变。

它会基于当前上下文做适配，而不是重新生成一个可能更跑偏的版本。这个“少量迭代”的工作方式，比一次生成不满意再重来一遍靠谱得多。

最终改完的代码编译通过之后，我会把它放到工程对应目录。这里注意，Kuikly 工程的 shared 模块下一般有 commonMain 这个 source set，跨端共享代码都放这里，如果你的工程结构不支持，得先去看一下脚手架生成的目录约定。

3.3 编译、预览与真机验证

代码写完之后，验证环节是最容易翻车的。很多人以为 AI 生成的代码放到工程里就能跑，不是的，你要把它当实习生写的代码来审。

先在 DevEco Studio 里跑一次 OpenHarmony 的编译。如果你的工程是命令行打开的，也可以用 hvigor 直接构建，命令大体是：

bash复制hvigorw assembleHap --mode module -p product=default

编不过的，仔细看报错。在我多次实测中，常见的问题是 import 路径不对，还有 Kotlin 版本和 Kuikly 要求的版本不匹配。Trae 生成的代码可能会引用一些它自己记忆里 kuikly 的包名，但实际仓库里类名略有差异。遇到这种情况，直接去本地 Gradle 缓存里翻 Kuikly 的 jar 包，看看真实的类名是什么，然后让 Trae 按照真实类名重新生成。

编译通过之后，用 DevEco 自带的 Previewer 看一下 UI 效果。这里要提醒一句，Previewer 对 Kuikly 这种自绘 UI 的支持没有那么完美，有时候显示会错乱，不要慌，优先以真机为准。我自己的习惯是模拟器上看布局结构，真机上检查交互和状态变化。

把 HAP 包安装到模拟器或真机上，命令是：

bash复制hvigorw install --mode module -p product=default

装完打开应用，逐个验证三个核心交互：输入内容添加待办，点击完成切换删除线，删除待办项。我实测发现，LazyColumn 的滚动和列表项更新在 OpenHarmony 上的表现有时会卡一下，这通常是因为没有给列表项设置稳定的 key。Kuikly 的 LazyColumn 支持 key 函数，就是把 items 的 key = { it.id } 这个参数用上，生成代码里已经有了，所以表现还算理想。

3.4 用 Trae 做代码重构和问题诊断

页面跑通之后，Trae 的价值还远没发挥完。它不只是生成页面，更像一个随叫随到的结对程序员。

比如我想把这个 TODO 应用的本地持久化加上，不用自己翻 Kuikly 的存储 API，直接把诉求扔给它：

text复制在当前 shared 模块中，新增一个 TodoStorage 类，负责把 todos 列表持久化到本地。
优先选择 Kuikly 支持的跨端存储方案。如果 Kuikly 没有现成的跨端存储封装，
请调研一下 currentTarget 这种多平台条件 API 的用法，分别对接 OpenHarmony 和 Android 的本地存储能力。
实现完成后，把 TodoViewModel 的 addTodo、toggleTodo、removeTodo 操作都接入持久化逻辑。

它会给出一套方案，可能是用 Kuikly 内部封装的多平台存储，也可能需要你手动添加依赖。这都没关系，重要的是它能基于整个工程上下文去分析，而不是孤立地写两个函数。它甚至会主动提示你，修改涉及到了哪些文件、需要同步改哪些测试。

遇到报错的时候，我现在的习惯是把完整报错信息复制给 Trae，它会结合代码上下文分析可能的原因，给出修复建议。这个比搜索引擎高效得多，因为很多报错是工程特有的，搜索引擎里根本没有一模一样的答案。

4. 踩坑实录与排查技巧

4.1 典型问题速查表

用了这么久，我把最高频的问题整理成了一张表，方便你快速对照排查。这些都是实际踩过的，不是网上抄来的。

4.2 Trae 使用过程中的五个坑

先说 Trae 本身的坑。第一个坑是模型“一本正经地胡说八道”，尤其是在 Kuikly 这种相对小众的框架上。它会编出一个看起来很像回事的 API，但你一编译，根本不存在。我在没有项目规则文件的时候，让它生成状态管理代码，它给我用了 rememberKuiklyState 这种 API，听名字很合理，但实际库里根本没有。解决办法就是前面说的，查真实 jar 包，或者直接在官方文档里搜索确认。

第二个坑是代码格式化。Trae 自动保存或者 AI 生成代码之后，偶尔会把格式化搞乱，缩进错乱，甚至自动删除某些字符。这大概率是 IDE 的格式化工具和 Trae 的代码编辑产生了竞争关系。解决办法是在 Trae 的设置里关掉自动格式化，或者统一用同一个格式化配置。我自己始终保持手动触发的格式化习惯，反而更稳定。

第三个坑是方法跳转失效。网上很多人抱怨 C++ 方法跳不了、Java 方法跳不了，这通常不是代码写错了，而是索引没有建立完整。Trae 是 AI IDE，它的语义索引和语言服务器是两套体系，有时候语言服务器没启动，就没有跳转。重启 IDE 是最高效的解决办法，别反复折腾设置。

第四个坑是“违反社区规范”之类的误报。我在提问一些涉及代码边界、权限申请的内容时，偶尔会触发它的安全策略，整个会话直接被拦截。如果你遇到了，先检查是不是提问里有比较敏感的词，换个更中性的说法重试通常能解决。如果提示“风险账户”并被登出，过一段时间再试，或者检查账户登录状态。

第五个坑是积分配额。Trae 虽然提供免费额度，但高强度使用之后会用完。我的建议是不要在一个会话里让 AI 干太多事，它是按轮次计费的，一次把需求说清楚，比来回拉扯十个来回省得多。日常写代码用轻量模型，遇到复杂逻辑再切换到更聪明的模型，这是我的真香配置。

4.3 Kuikly-OH 调试阶段的三个坑

跨端调试比普通应用调试多了一层复杂度。先讲网络问题。OpenHarmony 模拟器里访问本地服务，是不能直接用 localhost 的，要用 10.0.2.2 这类模拟器映射地址。我第一次调试跨端网络请求的时候，在模拟器上死活连不上本地的 Mock 服务，一开始还以为是 Kuikly 的网络 API 有问题，折腾了半个下午，最后才发现是地址写错了。这个坑对没做过 Android 模拟器调试的人来说极其隐蔽。

然后是日志过滤。DevEco Studio 的日志面板输出很乱，hvigor 的构建日志、系统日志、业务日志混在一坨，用 HiLog 打出来的日志会被淹没。我的做法是在日志面板里加一个关键字过滤，只保留我自己的 TAG，比如 Kuikly-Todo。这样调试效率直接翻倍。

还有一个隐蔽问题是 ArkTS 和 Kotlin 的数据桥接。Kuikly 的 shared 模块通过某种桥接机制和 OpenHarmony 壳工程通信，如果你在壳工程里手动改了一些数据，回过头发现 shared 模块里的状态不同步了，别慌，先确认你改的是不是壳工程和 shared 模块之间正常的通信通道。如果是，很可能你把桥接代码破坏了。这种情况我没有特别好的排查捷径，最稳妥的办法是从脚手架模板里重新拷贝一份桥接文件覆盖回来。

4.4 性能调优的一个思路

最后分享一个性能调优的心得。跨端框架最常见的质疑就是“性能不如原生”，虽然 Kuikly 是自绘渲染，但它毕竟隔了一层。我实际测试下来，普通页面的流畅度完全能接受，跟 ArkUI 原生写的差距感知不明显。但如果列表数据量大了，比如一次性渲染几百条待办，就需要注意几个点。

第一个是列表项尽量保持轻量，不要在 item 里套太多嵌套组件。第二个是状态更新尽量局部化，不要动不动把整个列表都刷新。第三是图片资源要注意按需加载，Kuikly 的做法跟原生一致，用懒加载机制，不要在列表 item 里一次性加载高清图。用 Trae 做性能优化的时候，我会给它描述清楚卡顿的具体表现，比如“滚动时掉帧”“添加待办时界面卡住”，它会先分析可能瓶颈，再给我修改建议。实测最有用的建议之一就是把 LazyColumn 的 key 设置为唯一的稳定 id，这个改完，列表滚动明显顺滑了不少。

5. 把 Trae 变成团队的“跨端开发教练”

如果只是自己一个人用，那 Trae 的作用主要是提效。但如果你和我一样，需要带一个小组一起做开源鸿蒙的跨端应用，它还能扮演另一个角色：团队的“跨端开发教练”。

新同学刚接手 Kuikly 工程时，最大的问题是不知道代码该往哪里放，也不理解壳工程和 shared 模块之间的关系。我会把 Trae 的项目规则文件写得尽量完整，然后让新同学直接通过对话向 Trae 提问，比如“新增一个设置页面应该改哪些文件”“怎么在 shared 模块里调用 OpenHarmony 的震动能力”。Trae 会结合规则文件和工程结构给出引导。这种方式比看文档高效，也比问我要省时间。

这里我要强调一点，项目规则文件不是写一次就够的。工程结构变了、依赖换了、甚至代码风格统一做了调整，都要先更新规则文件，再让队员依赖它。否则 Trae 给出的建议就会基于过时的上下文，反而误导新人。

另外一个用法是让 Trae 生成代码审查清单。每次合入代码之前，我让它基于工程现有代码风格生成一份审查要点，比如“检查是否在 shared 模块中混入了平台私有 API”“检查是否缺少横竖屏适配”“检查列表是否设置了唯一 key”。这份清单不一定全，但能帮新人避开大部分低级问题。我自己复核的时候，再补上一些性能和安全相关的点就够了。

我现在的工作流已经变成了：需求拆解靠脑子和白板，模板代码和页面布局交给 Trae 生成，核心业务逻辑自己动手写，单元测试和代码审查同步推进。这套流程跑下来，一个中等复杂度的跨端页面，从需求到能跑起来，差不多半天就能搞定，比纯手工写快了一倍还不止。而且因为 Trae 一直在监督 API 边界，跨端代码踩到平台差异坑的几率也明显降低了。