生成式 AI 在软件研发和知识管理上，有着非常大的潜力，也因此这项技术被越来越多的企业所采用。而在一些新兴的技术上，诸如于鸿蒙操作系统，它带来了一些新 的理念、开发工具 DevEco Studio、新的语言 ArkTS、新的 UI 框架 ArkUI 等等。从模式上来说，它与生成式 AI 结合企业内部的基础设施过程非常相似。
因此，我们开始在 AutoDev 中探索如何结合这些新知识的可能性，同时降低开发人员的学习负担。
视频 Demo：
源码：https://github.com/unit-mesh/auto-dev
鸿蒙操作系统 + 生成式 AI 的三个试验式功能
在初步使用新的 HarmonyOS IDE 之后，便有了三个在 AutoDev 试验的思路：
添加 ArkTS 语言支持。ArkTS 是鸿蒙生态中基于 TypeScript 扩展的应用开发语言。
自动 ArkUI 页面生成。ArkUI 是一套构建分布式应用界面的声明式 UI 开发框架。它与我们先前引入的 AutoPage 并没有太多的区别，可以结合思维链进行代码和 UI 生成。
UI 布局迁移。即将其它语言、框架编写的代码，交由生成式 AI 转化成适用于鸿蒙的代码。
作为阅读过 Gradle、Intellij Community、DevEcoStudio 源码，以及《前端架构：从入门到微前端》作者，我大抵算是对于 TypeScript、 ArkUI、 声明式 UI 有一定的经验，所以我自信的开始了 AutoDev 的新功能开发 —— 然后就踩了一堆坑。
1. ArkTS 语言的 AI 支持
在我下载安装完 DevEco Studio 之后，发现 AutoDev 居然不支持 TypeScript？？？经过我在 WebStorm 反复测试后，发现是 IDE 的关系。结合 PSIViewer 插件后， 才发现差异之后，DevEco Studio 的 JavaScript/TypeScript 语言是自己实现的，诸如于： com.huawei.ace.language.psi.impl.JavaScriptIdentifierNameImpl。
原因不外乎：
Intellij 平台中的 JavaScript 插件是收费的，没有开源版本。
鸿蒙直接针对于 TypeScript 语法进行扩展，会比实现一个新的更简单。
所以 DevEco Studio 自研了一个 JavaScript/TypeScript 模块，支持 JavaScript 语法高亮、代码提示、代码格式化等功能。与此同时，DevEco Studio 添加了 ArkTS 语言，即 TypeScript 扩展语法。
这就意味着，使用 DevEco Studio + AutoDev 时，会出现三种新的文件类型：Huawei JavaScript、Huawei TypeScript、Huawei ArkTS。
头疼。。
为此，在 AutoDev 中采取的方法是，其于标准 PSI 做初步的抽象，以实现对于文档生成的支持。而如果要做好则需要：
基于反射来重复利用 JavaScript PSI
融入 DevEco Studio 的 JavaScript 支持
当然，考虑到调试上的难度，以前代码中各种现的 xxStudio 字眼（新的自研 IDE 平台？？），我暂时放弃了上述的做法：大体上鸿蒙 IDE 会有自己的 AI 能力。
2. AutoArkUI：RAG 增强的 ArkUI 代码生成
ArkUI 是一套构建分布式应用界面的声明式 UI 开发框架。
与 ArkTS 相比，要结合 ArkUI 显得稍微复杂一些。所以，我在当前版本里考虑的是：结合经典 UI 的元素生成页面，即：
布局。诸如于：线性布局（Row、Column）、层叠布局（Stack）、弹性布局（Flex）等。
组件。诸如于：按钮（Button）、单选框（Radio）、切换按钮（Toggle）等。
而由于 ChatGPT 是不包含 HarmonyOS 的最新知识的，所以需要采用类似于 AutoPage 的两步生成特性。
分析用户的需求，选择合适的布局与组件。
根据用户的需求与详细的布局、组件信息，生成对应的 ArkUI 代码。
上述的两步便是 AutoDev 中 AutoArkUi 生成 UI 的特性，详细可以参考 AutoDev 的代码，以及对应的 prompt。如下是对应的步骤 1 的 prompt：
User: // maybe send Android Layout code, maybe some requirements
Your Answer: [FlexLayout, Button, CheckBox, Checkbox, Button]
考虑到编程语言 DSL（领域特定语言）极易受用户语言的影响，所以采用的是英语的方式，避免无端生成中文 DSL 。
3. 迁移 Android/iOS/小程序 应用
生成式 AI 具备极好的代码翻译能力。诸如于 IBM 在 Cobol 转化为 Java 上的工程化设计，以及我们在 AutoDev 中设计的遗留系统改造能力，其所针对的 都是生成 AI 在这方面的能力。
所以，我们也在 AutoDev 中内置了这个功能，只是当前支持的只是布局上的迁移。但是，考虑到这种生成方式依旧有一系列的问题，有待我们进一步寻找更好的方式。类似的问题在生成 ArkUI 也是存在的。
相似的，这个功能目前是与 AutoArkUI 融合在一起的，理论上通过静态代码分析是最简单的，有待未来进一步完善。
4. RAG 增强的聊天上下文：C++ NAPI 等
在试验了多次之后，会发现对于 HarmonyOS 这种新知识，ChatGPT 是不知道的。所以，需要基于 AutoDev 的上下文接口，创建基于 HarmonyOS 的上下文。当然的版本（1.6.4）里， 添加的是： This project is a HarmonyOS project. （毫无意义的废话），再结合不同语言来写一些上下文：
TypeScript/JavaScript/ArkTS. Which use TypeScript (ArkTS) as the main language, and use Flutter like TypeScript UI framework.
CPP/"C/C++"/CCE. Which use C++ as the main language, and NAPI for building native Addons.
大体来说，就是告诉 AI：
编写 ArkUI/前端代码的时候，考虑一下这个项目是类似于 Flutter 的声明式 UI 。
编写原生代码的时候，考虑一下这个项目是基于 NAPI 来构建插件的。
当然了，这些是基于我的初步理解所构建的上下文，
未来
考虑到上述的功能，就是几小时内实现的，就不要有太高的期望了。
当前版本依旧有诸多问题：
转换 Android 布局易瞎编。除了需要知道更多的转换规则，还需要知识更多的属性，而这些部分是通过传统的代码分析工具解决的
组件和布局信息的 hardcode。懂的都懂
缺少示例代码。没有动态生成的示例代码，使得 RAG 的效果是有限的
诸如于 C++ 语言的支持
微信小程序等小程序平台的转换
然而我并非 Android、小程序应用迁移到鸿蒙应用的专家，所以还是有一系列的挑战。等我心情好的时候，再考虑写一些更好玩的新特性。
