技能介绍

它解决的问题

鸿蒙原生开发的资料分散在官方文档、Kit 参考、示例仓库和 IDE 私有接口里，普通搜索要么给出行版本不匹配的答案，要么只覆盖单个 API 点。同时 ArkTS 的严格模式规则（禁用 any 滥用、禁用 as 断言、显式返回类型）与 ArkUI 的状态管理、路由、列表性能等约束散落各处，容易在编译期和运行时反复踩坑。此外，从 ohpm install 到设备安装启动的链路涉及 hvigor、hdc、bm 等多个工具，手动操作步骤繁琐且容易出错。

技能如何工作

离线路由检索。 技能包把知识拆成可按路径命中的 Markdown 文件：references/KITS.md 按 Kit 导航、references/TASK_MAP.md 按任务反查、references/INDEX.md 是全库文件索引。使用时先对请求分类，命中路径后只读 1-3 个目标文件，避免把整个知识库塞进上下文。

构建部署自动化。 scripts/harmony-deploy.sh（macOS/Linux）和 scripts/harmony-deploy.ps1（Windows）封装完整工作流：环境与版本检测、ohpm install、按 oh-package.json5 拓扑排序分模块编译（HAR → HSP → HAP）、收集签名产物、安装前 force-stop、hdc 推送加 bm install -p 原子安装，可选 --launch 启动或 --app 打包。

知识沉淀。 内含 ArkTS 严格模式规则与 13 条性能编码规则、ArkUI 组件生命周期与容器性能对比、V2 状态装饰器优先级、Navigation + NavPathStack 路由方案、7 大类 60+ Kit 的 import key 速查、数据持久化与 TaskPool/Worker 并发选型等，覆盖开发全流程。

适用边界与注意点

API 版本策略是硬约束：生产环境用 API 24 Release，存量设备用 API 23，API 26 Beta1 仅用于 HarmonyOS 7 预览适配。Router 在 API 12 后已弃用，新项目必须用 Navigation + NavPathStack；FA 模型同样是 legacy，新应用一律用 Stage 模型。V1 状态装饰器只用于维护老项目或 API < 23 的场景。

涉及 DevEco Studio 模拟器、IDE 私有接口、CodeGenie、MCP、ArkUI Inspector 等操作前，必须先读 references/ideGuides/ 下的私有接口文档，默认只做静态只读分析。Release 真机安装必须配置 build-profile.json5 中的签名证书；调试签名可由 DevEco Studio 自动生成。

截图预览

使用场景

刚拿到 DevEco Studio 新建项目时，需要一套符合 ArkTS 严格模式的最小工程模板和冒烟测试 fixture。
应用从 API 23 迁到 API 24 时，要确认哪些状态装饰器改 V2、路由是否还在用已弃用的 Router。
长列表出现滚动卡顿，需要把 ForEach 改成 LazyForEach + IDataSource 并配好 cachedCount。
每天要反复编译装到真机调试，想用 harmony-deploy 一条命令串起清理、编译、安装和启动。

适合人员

正在把 Android 或 iOS 应用重写成 HarmonyOS NEXT 原生应用的客户端工程师，需要 ArkTS 严格模式规则和 ArkUI 组件选型速查。
维护存量 HarmonyOS 项目的前端工程师，要在 API 12 后弃用 Router 和 FA 模型的迁移窗口里完成路由和状态装饰器改造。
负责 DevEco Studio 工程化的构建工程师，想把 hvigor、ohpm、hdc、bm 的手动步骤固化成可重复执行的部署脚本。
做 Kit 能力接入的移动端工程师，需要按场景反查 @kit.* import key、权限申请流程和数据持久化方案。