DevEco Code使用的几点心得体会
DevEco Code使用的几点心得体会 我是个独立开发者，最近几天上手体验了deveco code，有一些心得。
deveco code在项目之间的相互模块迁移上有着巨大的优势，例如项目a的模块，打算在项目b复用时会很方便尤其是不熟悉的部分。我最近在做一个陪伴类的APP，需要用到live2d，但官方提供的demo和依赖文件相当复杂，依靠deveco code，在一小时内就帮我完成了迁移和渲染线程竞态的问题。
还有关于知识库方面，它很好的解决了目前大模型缺少arkts训练的问题（就我个人体验而言claude opus和gemini Pro表现的比国产模型出色的多，但相关数据比较旧，模型认知API版本停留在harmony next初期）。但是就我个人体验而言，在arkui方面表现的一般甚至比较差，例如我提出一个对齐要求，生成的代码试图用column的heght和width来实现效果，而不是aligin。当我明确提出使用hdsnavigation组件时却使用的是普通的navigation。还有就是一些kit的掌握似乎也不足，我要求通过sharekit做一个系统级分享功能，却拉起了选择软件打开文件的面板
关于使用流程上我个人倾向于先用plan，让模型审视原有的项目，然后是讨论和提出需求，充分讨论后切换到build模式。对于goal，似乎对提示词质量和目标清晰度要求很高，不然我认为缺少上述plan加build的流程的掌握感，生成质量也相对更加随机。
总之这个工具表现相当不错，稍微也有点小问题。很适合做一些复杂程度中等的项目或者是模块，能给开发者节省精力，但在具体代码层面掌控感不足也是难以避免的
DevEco Code基于ArkTS的声明式UI开发效率高，状态管理清晰，实时预览与热重载提升调试体验。多设备适配模拟方便，代码提示补全流畅，配合端云一体化开发，显著减少跨端工作量。
您的体会很真实。DevEco Code在跨项目模块迁移和依赖处理上的效率确实突出，尤其对复杂demo的整合能省下大量排查时间，这种“开箱即用”的体验对独立开发者很友好。
关于知识库的短板，您指出的ArkUI布局理解偏差和Kit调用混淆确实存在，比如对齐问题容易被拆成宽高计算、HDS导航被替换为普通Navigation、ShareKit拉起文件选择面板等，说明模型对HarmonyOS NEXT新组件和系统服务的语义把握还不够精准，更多依赖历史API模式。
您提到的“先Plan后Build”的流程很务实，先让模型理解项目再分步实现，能显著减少生成随机性。Goal模式对意图拆解要求高，更适合目标非常明确的小任务，否则容易失控。
整体来看，这个工具在“中大型模块的脚手架搭建”和“跨项目资产复用”上价值明显，但细节控制仍需开发者人工把关，尤其涉及ArkUI新特性或系统Kit时，建议以“辅助生成+手动修正”的心态使用，而不是完全信任输出。
