HDC大会AI 分论坛回顾|仓颉AI Coding赋能携程,鸿蒙端开发效率跃升

AI分论坛嘉宾与参会开发者合影

分享嘉宾：江守亭｜携程旅行软件专家

携程于2024年6月上架鸿蒙应用商店，11月正式Release，目前已稳步迭代近百个版本，实现三端业务功能基本对齐。然而，在鸿蒙化进程中，团队首先面临的是三端同步开发人效低的结构性难题：Native模块需在iOS、Android、HarmonyOS三端独立开发，各端基础框架与代码差异显著，统一能力标准的对齐损耗了大量开发成本。

团队曾尝试KMP（Kotlin Multiplatform）跨端方案，但很快遇到瓶颈：现有基础库需全部重新KMP开发，工作量巨大；KN在iOS与HarmonyOS上的垃圾回收性能表现不佳；调试与Trace配套不如原生易用；且KMP并非官方支持语言，长期维护存在不确定性。

针对上述痛点，江守亭团队与仓颉AI Coding工具链深度协作，形成了"骨架先行、函数级增量、AST驱动、UT校验"的四层方法论：

1. 骨架先行，保证工程可编译

基于源工程解析结构信息，生成目标语言代码骨架，并通过编译修复确保骨架工程可编译通过。这一步将"能不能跑"的问题在工程层面先行解决，避免后续在不可编译的废墟上修修补补。

2. 函数级增量转换，控制模型上下文

在可编译骨架基础上，逐个Function替换实现。每次仅输入当前函数相关上下文，大幅降低Token消耗，使大模型更聚焦、输出更稳定。

3. 单函数编译修复，问题局部收敛

每个Function转换后独立编译检查与修复，将问题严格限制在当前函数范围内，避免错误跨函数扩散，显著降低定位与修正成本。

4. UT行为校验，提升结果可信度

通过函数级单元测试对比转换前后的输入输出一致性，验证迁移结果的行为等价性，确保AI生成的代码不仅"能编译"，更"逻辑正确"。

5. AST驱动知识推荐，精准匹配转换规则

基于AST（抽象语法树）分析识别代码中的类/方法结构、API调用、类型使用和语法模式，根据当前代码片段的AST特征精准匹配转换规则，减少无关知识占用上下文，进一步提升模型转换的聚焦度与准确率。

本场分论坛的完整回放将于近期在官方视频号放出，敬请关注，不错过每一个技术细节。