HarmonyOS鸿蒙Next关于提升OpenHarmony开发效率的思考：AI Agent工具链与本地知识库构建分享 大家好，

最近在深入研究OpenHarmony开发的过程中，我探索了一套利用AI Agent提升效率的工作流，希望能与大家分享和交流。

现状与痛点：

官方提供的AI工具在某些场景下体验不尽如人意。相比之下，社区和商业领域涌现了许多优秀的AI Agent工具，它们不仅功能强大，并且对MCP（Multi-modal Conversational Platform）服务器的支持也相当出色。看到类似腾讯发布的小程序知识库等产品，我深受启发，相信将强大的AI能力与我们的开发工具链结合，能够显著提升开发效率。

日常知识检索：

为了解决文档检索效率低下的问题，我搭建了一套本地化的AI知识库：

1. 核心工具： Cherry Studio 客户端。

2. 知识来源： 我将OpenHarmony的官方文档完整克隆到本地。

3. 处理方式： 利用嵌入模型（Embedding Model）对所有文档进行向量化处理。

4. 最终效果： 当遇到问题时，可以直接通过AI进行自然语言查询。与在官方文档网站上手动搜索相比，这种方式的响应速度和信息定位精准度都有了质的飞跃。

开发流程优化：

在编码阶段，我的组合是 DevEco Studio + Augment。

让我惊喜的是，尽管是一些国外的模型，Augment(Claude Sonnet 4)对ArkTS的理解程度相当高，代码生成和补全能力很不错。为了让它更好地融入我的开发环境，我做了一些优化：

• 拷贝文档目录副本： 我将一份文档副本放置在项目目录下。

• Prompt工程： 在与Augment交互时，我会明确告知它这些本地文档的路径，引导它在生成代码或提供建议时，主动查询这些规范，从而确保产出更符合项目要求。

开发成果与实践：Speak 项目

最近，我将这套方法论应用在了一个名为“Speak”的AI语音对话项目中。为了让AI助手的输出更精准可控，我为其设定了一套非常严格的“记忆”或“核心指令” (Project Memory)。

Project Memory: Speak (ArkTS)

PRIMARY_DIRECTIVE: SOURCE_OF_TRUTH (核心指令：唯一的真相来源)

• My ONLY source for all code, APIs, components, and implementation patterns is the local project documentation: c:\Users\10423\Code\Speak\application-dev\.
• I MUST NOT use external knowledge, general programming habits, or undocumented features. All actions must be validated against the local docs first.

PROJECT_SPECIFICATIONS (项目规格)

• Project: Speak
• Technology: ArkTS (API 5.0.5(17)), ArkUI (Declarative)
• Objective: An AI voice dialogue app with four main modules (Free Conversation, Scenario Conversation, Vocabulary Learning, Essay Correction).
• Key Requirement: Achieve “iOS-level” fluid animations and transitions for all UI interactions.

CODING_RULES (NON-NEGOTIABLE) (编码硬性规则)

• NO any TYPE: All type declarations must be explicit and strongly typed.
• NO ES6+ SYNTAX: Use only the TypeScript-like syntax compatible with the specified API version.
• NO NODE.JS/NPM: The Node.js ecosystem is incompatible and strictly prohibited.
• LANGUAGE: All code comments and user-facing UI text must be in Chinese (zh-CN).

IMPLEMENTATION_PATTERNS (实施模式)

• Resource-Driven UI: All strings, colors, and dimensions must be referenced from .json resource files (e.g., $r('app.string.app_name'), $r('app.color.primary_accent')).
• Navigation: The core app structure is built around the Navigation component. Use NavPathStack and NavDestination as per the docs.
• File Structure: Adhere to the established structure, including using the config and constants directories for their intended purposes.
• Componentization: Break down complex views into smaller, reusable custom components.

### **多模型协作的必要性**

在实践中我发现，**直接让AI生成最终的ArkTS代码，尤其是复杂的UI界面，效果往往不理想。** 这似乎考验的是模型的跨模态、开放性和抽象思维能力，而大多数模型难以一步到位生成一个功能完备且可用的UI。

因此，我采用了“两步走”的策略：

1.  **高层设计 (UI/UX -> HTML原型):** 我使用一个更高级的模型，例如 **Gemini 2.5 Pro**。我会向它详细描述我的项目简介和UI/UX设计构想，让它先生成HTML/CSS的**静态原型稿**。这个阶段不追求功能，只追求视觉和布局的准确性。

2.  **底层实现 (HTML原型 -> ArkTS代码):** 接下来，在与Augment协作时，通过Prompt来告知Agent原型稿存放的位置和涉及思路，以及一些响应式的设计。

通过这种方式，我们将一个复杂的抽象任务，拆解成了“设计”和“翻译”两个步骤。第一步将模糊的构想具象化为清晰的HTML结构，第二步则让擅长代码转换的AI来完成精准的翻译工作，成功率和代码质量都大大提升。最后，只需要和AI Talk就生成了以下UI设计。

![](https://alliance-communityfile-drcn.dbankcdn.com/FileServer/getFile/cmtybbs/708/136/510/0030086000708136510.20250817175702.58294419330377741683463656133937:50001231000000:2800:86D9C7B362283C9548894BB1745F73E09F1B30F1141DABBD93377A764BD5D62C.png)

![](https://alliance-communityfile-drcn.dbankcdn.com/FileServer/getFile/cmtybbs/708/136/510/0030086000708136510.20250817175702.21456707748857634633144737263703:50001231000000:2800:6F33ECE599B20BDBC249950593BF0CA904AEC6D55B5EAE53EFB2725191649637.jpg)

## **呼吁与展望**

我的这些探索虽然取得了一些成效，但本质上还是基于个人开发者环境的“小作坊”模式。如果每一位开发者都需要自行搭建本地知识库、配置复杂的AI Agent工具链，无疑会增加大家的使用门槛。

因此，在这里也想**呼吁一下华为官方**，能否考虑为广大OpenHarmony开发者提供官方的MCP服务器支持？

如果能有一个官方的、深度整合了OpenHarmony和ArkTS知识体系的AI平台，让我们可以通过标准的API或插件方式接入，将极大地赋能整个开发者社区。这不仅能统一和提升AI辅助开发的体验，也能让开发者们从繁琐的配置中解放出来，更专注于业务逻辑与创新本身。

## **总结**

通过 **本地知识库 + 严格的Prompt指令 + 多模型分工协作** 的组合，我个人的OpenHarmony开发体验得到了显著改善。这套流程不仅提高了信息检索的效率，也让从UI/UX设计到最终代码实现的整个链路更加流畅和可控。

不知道社区里各位开发者是否有类似的探索？欢迎大家分享自己的经验，或者对我的方案提出宝贵的建议。期待与大家一同探讨如何更高效、更智能地进行OpenHarmony开发。