【共创季稿事节】HarmonyOS 6.1 开发效率提升：自定义代码模板与 DevEco 插件实战

想你依然心痛

1517人浏览 · 2026-07-18 14:28:43

想你依然心痛 · 2026-07-18 14:28:43 发布

文章目录

在这里插入图片描述

每日一句正能量

适可而止的贪婪叫努力，适可而止的欲望叫梦想。
努力是克制后的进取，不是无休止的占有。梦想是有边界的向往，不是脱离现实的妄念。不否认野心，但要给它画一条健康的底线。

前言：真正拖慢团队的，往往不是“不会写”，而是“重复写”

在 HarmonyOS 项目进入多人协作阶段后，开发效率问题通常不会表现为“某个 API 不会调用”，而会表现为一系列细小但高频的重复劳动：

新建页面时，重复创建 Page、ViewModel、Repository；
手动补齐 @Entry、@ComponentV2、状态变量和日志标签；
在页面文件、路由表和配置文件之间来回切换；
团队成员使用不同的目录、命名和异常处理习惯；
复制旧页面后忘记修改类名、路由名或资源引用；
教学项目中，学生把大量时间耗在“搭骨架”，而不是理解 ArkUI 状态管理与业务逻辑。

这些动作单次只需要几分钟，但每天重复十几次，就会形成明显的交付损耗。更麻烦的是，复制粘贴带来的问题往往延迟暴露：代码能编译，却留下命名不一致、文件职责混乱、日志缺失和配置冲突。

本文以一个 HarmonyOS 6.1 教学型智能设备项目为背景，构建一套由浅入深的效率工具链：

用 Live Template 消除局部代码重复；
用 File Template 统一文件级骨架；
用 IDE Action 封装跨文件操作；
用 DevEco 插件工具窗口 完成可视化代码生成；
用数据记录验证效率是否真正提升。

华为官方将 DevEco Studio 定位为 HarmonyOS 应用与元服务的一站式开发环境，覆盖编码、构建、调试、预览与性能分析。本文讨论的模板和插件能力，是在 IDE 工作流之上进行团队级增强，而不是替代 DevEco Studio 自带能力。
官方参考：https://developer.huawei.com/consumer/cn/deveco-studio/

版本说明：插件 API 与 DevEco Studio 内置的 IntelliJ Platform 版本有关。文中的插件代码用于讲解实现思路，实际落地时应以所安装 DevEco Studio 的插件兼容范围、SDK 与发布说明为准，不要仅凭版本号复制依赖。

一、先做效率审计：不要一上来就开发插件

插件开发本身也有维护成本。一个常见误区是：团队遇到重复工作，立即做一个“大而全”的生成器，结果插件比业务项目还难维护。

更稳妥的方法是先对重复动作分级。

重复动作	适合工具	判断标准
5～20 行固定结构	Live Template	单文件、参数少、无需改其他文件
固定文件骨架	File Template	创建一个文件即可完成
同时创建多个文件	IDE Action	涉及目录、命名、格式化
需要表单和预览	Tool Window	参数多、需要降低使用门槛
会修改 JSON5 / 路由表	生成服务	需要解析、冲突检测、回滚
只执行一次的迁移	脚本	不值得长期维护插件

在这里插入图片描述

这套分级的核心原则是：优先采用维护成本最低的工具，只有当低级工具无法覆盖时，才升级到插件。

二、第一层优化：用 Live Template 消除局部重复

2.1 适用场景

Live Template 最适合生成结构稳定、占用行数不多的 ArkTS 代码，例如：

标准日志标签；
@ComponentV2 组件骨架；
try-catch 异常处理；
aboutToAppear 生命周期；
ObservedV2 状态对象；
网络请求结果分支。

以页面组件为例，团队可以约定缩写 hvpage，输入后展开为：

@Entry
@ComponentV2
struct $PAGE_NAME$ {
  @Local private loading: boolean = false

  build() {
    Column({ space: 12 }) {
      Text('$TITLE$')
        .fontSize(24)
        .fontWeight(FontWeight.Bold)
    }
    .width('100%')
    .height('100%')
    .padding(16)
  }
}

建议设置两个变量：

$PAGE_NAME$ ：页面结构体名称；
$TITLE$ ：页面初始标题。

2.2 模板设计原则

一个高质量模板不应只是“代码更多”，而应体现团队规范：

private async loadData(): Promise<void> {
  if (this.loading) {
    return
  }

  this.loading = true
  try {
    await this.viewModel.load()
  } catch (error) {
    const message = error instanceof Error ? error.message : String(error)
    hilog.error(0x0000, 'DevicePage', 'loadData failed: %{public}s', message)
  } finally {
    this.loading = false
  }
}

这里把三个容易遗漏的细节固化进模板：

防止重复请求；
使用 finally 恢复加载状态；
对未知异常统一转成字符串。

2.3 不要把业务规则写进 Live Template

Live Template 应生成“通用骨架”，不应直接写死设备类型、接口地址或具体业务文案。否则模板很快会演变成难以维护的复制源。

三、第二层优化：文件模板统一页面与数据层骨架

当一个功能需要创建完整文件时，Live Template 已经不够。此时应把模板提升到文件级。

本文使用三类模板：

Page.ets.ftl
ViewModel.ets.ftl
Repository.ets.ftl

3.1 页面模板

import { ${VIEW_MODEL_NAME} } from '../viewmodel/${VIEW_MODEL_NAME}'

@Entry
@ComponentV2
struct ${PAGE_NAME} {
  @Local private viewModel: ${VIEW_MODEL_NAME} = new ${VIEW_MODEL_NAME}()

  aboutToAppear(): void {
    this.viewModel.load()
  }

  build() {
    Column({ space: 12 }) {
      Text('${PAGE_TITLE}')
        .fontSize(24)
        .fontWeight(FontWeight.Bold)

      if (this.viewModel.loading) {
        LoadingProgress()
      } else {
        this.buildContent()
      }
    }
    .width('100%')
    .height('100%')
    .padding(16)
  }

  @Builder
  private buildContent() {
    Text(this.viewModel.summary)
      .fontSize(16)
  }
}

3.2 ViewModel 模板

@ObservedV2
export class ${VIEW_MODEL_NAME} {
  @Trace loading: boolean = false
  @Trace summary: string = ''

  constructor(
    private readonly repository: ${REPOSITORY_NAME} = new ${REPOSITORY_NAME}()
  ) {}

  async load(): Promise<void> {
    if (this.loading) {
      return
    }

    this.loading = true
    try {
      const result = await this.repository.query()
      this.summary = result.summary
    } finally {
      this.loading = false
    }
  }
}

3.3 Repository 模板

export interface ${ENTITY_NAME} {
  id: string
  summary: string
}

export class ${REPOSITORY_NAME} {
  async query(): Promise<${ENTITY_NAME}> {
    // TODO: 替换为真实数据源
    return {
      id: 'demo',
      summary: 'Generated by DevEco Productivity Plugin'
    }
  }
}

文件模板解决的是“一个文件长什么样”，但还没有解决“多个文件如何同时创建、如何注册路由、文件冲突怎么办”。这正是插件 Action 的价值。

四、第三层优化：开发一个 DevEco Studio 代码生成插件

4.1 目标与非目标

本插件命名为 Harmony Productivity Toolkit，实现以下能力：

在项目右键菜单中增加“生成 ArkTS 功能模块”；
输入页面名后自动推导 ViewModel、Repository 和实体名；
创建约定目录；
生成多个 .ets 文件；
可选更新路由配置；
文件已存在时显示冲突，不静默覆盖；
生成后刷新 IDE 文件索引并格式化代码；
在工具窗口展示最近生成记录。

不做的事情包括：

不自动生成具体业务接口；
不绕过代码评审；
不替开发者决定状态管理方案；
不直接覆盖已有 JSON5；
不把所有项目都强制成同一种架构。

在这里插入图片描述

4.2 插件工程结构

在这里插入图片描述

一个简化的插件目录如下：

deveco-productivity-plugin/
├─ src/main/kotlin/
│  ├─ action/GeneratePageAction.kt
│  ├─ service/CodeGeneratorService.kt
│  ├─ toolwindow/GeneratorToolWindow.kt
│  ├─ model/GenerationOptions.kt
│  └─ util/NameConverter.kt
├─ src/main/resources/
│  ├─ META-INF/plugin.xml
│  └─ templates/
│     ├─ Page.ets.ftl
│     ├─ ViewModel.ets.ftl
│     └─ Repository.ets.ftl
└─ build.gradle.kts

五、插件配置：注册 Action 与 Tool Window

plugin.xml 用于声明插件信息、菜单动作与工具窗口。

<idea-plugin>
  <id>com.example.harmony.productivity</id>
  <name>Harmony Productivity Toolkit</name>
  <vendor email="team@example.com">Harmony Teaching Team</vendor>

  <description>
    Generate standardized ArkTS pages, view models and repositories.
  </description>

  <depends>com.intellij.modules.platform</depends>

  <extensions defaultExtensionNs="com.intellij">
    <toolWindow
      id="Harmony Generator"
      anchor="right"
      factoryClass="com.example.plugin.toolwindow.GeneratorToolWindowFactory"
      icon="/icons/generator.svg"/>
  </extensions>

  <actions>
    <action
      id="Harmony.GenerateFeature"
      class="com.example.plugin.action.GenerateFeatureAction"
      text="生成 ArkTS 功能模块"
      description="生成 Page、ViewModel 与 Repository">
      <add-to-group group-id="ProjectViewPopupMenu" anchor="last"/>
      <keyboard-shortcut
        keymap="$default"
        first-keystroke="ctrl alt H"/>
    </action>
  </actions>
</idea-plugin>

这里值得强调三点：

id 必须长期稳定，发布后不要随意修改；
快捷键要避免与 IDE 默认按键冲突；
Action 只负责接收用户操作，不应承载全部文件生成逻辑。

六、Action 实现：只做入口、上下文与参数收集

下面使用 Kotlin 展示插件端核心逻辑。DevEco 插件实际支持范围需以对应 IDE 版本为准。

class GenerateFeatureAction : AnAction() {

    override fun update(event: AnActionEvent) {
        val project = event.project
        val selected = event.getData(CommonDataKeys.VIRTUAL_FILE)

        event.presentation.isEnabledAndVisible =
            project != null && selected != null && selected.isDirectory
    }

    override fun actionPerformed(event: AnActionEvent) {
        val project = event.project ?: return
        val targetDirectory =
            event.getData(CommonDataKeys.VIRTUAL_FILE) ?: return

        val dialog = GenerateFeatureDialog(project)
        if (!dialog.showAndGet()) {
            return
        }

        val options = GenerationOptions(
            pageName = dialog.pageName.trim(),
            pageTitle = dialog.pageTitle.trim(),
            targetDirectory = targetDirectory.path,
            generateViewModel = dialog.generateViewModel,
            generateRepository = dialog.generateRepository,
            registerRoute = dialog.registerRoute
        )

        val service = project.service<CodeGeneratorService>()
        val result = service.generate(options)

        if (result.success) {
            NotificationGroupManager.getInstance()
                .getNotificationGroup("Harmony Generator")
                .createNotification(
                    "代码生成成功",
                    "已生成 ${result.createdFiles.size} 个文件",
                    NotificationType.INFORMATION
                )
                .notify(project)
        } else {
            Messages.showErrorDialog(
                project,
                result.errors.joinToString("\n"),
                "生成失败"
            )
        }
    }
}

update() 用于控制菜单是否可用。只有在用户选中了目录时才启用操作，避免无效点击。

七、参数模型与命名转换

页面名是生成器最重要的输入。插件必须在写文件前完成严格校验。

data class GenerationOptions(
    val pageName: String,
    val pageTitle: String,
    val targetDirectory: String,
    val generateViewModel: Boolean,
    val generateRepository: Boolean,
    val registerRoute: Boolean
)

object NameConverter {
    private val identifier = Regex("[A-Z][A-Za-z0-9]*")

    fun validatePageName(name: String): List<String> {
        val errors = mutableListOf<String>()

        if (name.isBlank()) {
            errors += "页面名称不能为空"
        } else if (!identifier.matches(name)) {
            errors += "页面名称必须为大驼峰格式，例如 DeviceDetail"
        }

        if (name.length > 60) {
            errors += "页面名称不应超过 60 个字符"
        }

        return errors
    }

    fun viewModelName(pageName: String): String =
        "${pageName}ViewModel"

    fun repositoryName(pageName: String): String =
        "${pageName}Repository"

    fun entityName(pageName: String): String =
        "${pageName}Entity"
}

不要依赖字符串替换“碰运气”。命名转换应该集中在一个工具类中，并有单元测试。

八、生成服务：处理模板渲染、冲突检测与工程写入

生成服务是整个插件的核心。

@Service(Service.Level.PROJECT)
class CodeGeneratorService(
    private val project: Project
) {

    fun generate(options: GenerationOptions): GenerationResult {
        val errors = NameConverter.validatePageName(options.pageName)
        if (errors.isNotEmpty()) {
            return GenerationResult.failure(errors)
        }

        val plan = buildPlan(options)
        val conflicts = plan.filter { it.targetFile.exists() }

        if (conflicts.isNotEmpty()) {
            return GenerationResult.failure(
                conflicts.map { "文件已存在：${it.targetFile.path}" }
            )
        }

        return try {
            var created: List<VirtualFile> = emptyList()

            WriteCommandAction.runWriteCommandAction(project) {
                created = plan.map { item ->
                    val content = renderTemplate(
                        templateName = item.templateName,
                        variables = item.variables
                    )
                    writeFile(item.targetFile, content)
                }

                if (options.registerRoute) {
                    updateRouteSafely(options)
                }
            }

            refreshAndFormat(created)
            GenerationResult.success(created.map { it.path })
        } catch (error: Exception) {
            GenerationResult.failure(
                listOf(error.message ?: "未知生成错误")
            )
        }
    }
}

8.1 为什么必须使用写命令

IDE 对虚拟文件系统、撤销栈和索引有自己的管理机制。直接通过普通文件 API 写入，可能造成：

IDE 未及时感知文件变化；
无法撤销；
索引状态不一致；
格式化与代码分析未触发。

因此，工程写入应在 IDE 提供的写操作上下文中完成。

8.2 先构建计划，再执行写入

buildPlan() 先生成“将要创建什么”的清单：

private fun buildPlan(
    options: GenerationOptions
): List<GenerationItem> {
    val pageName = options.pageName
    val vmName = NameConverter.viewModelName(pageName)
    val repoName = NameConverter.repositoryName(pageName)
    val entityName = NameConverter.entityName(pageName)

    val variables = mapOf(
        "PAGE_NAME" to pageName,
        "PAGE_TITLE" to options.pageTitle,
        "VIEW_MODEL_NAME" to vmName,
        "REPOSITORY_NAME" to repoName,
        "ENTITY_NAME" to entityName
    )

    val items = mutableListOf<GenerationItem>()

    items += item(
        "Page.ets.ftl",
        "${options.targetDirectory}/pages/$pageName.ets",
        variables
    )

    if (options.generateViewModel) {
        items += item(
            "ViewModel.ets.ftl",
            "${options.targetDirectory}/viewmodel/$vmName.ets",
            variables
        )
    }

    if (options.generateRepository) {
        items += item(
            "Repository.ets.ftl",
            "${options.targetDirectory}/repository/$repoName.ets",
            variables
        )
    }

    return items
}

这种“计划—校验—执行”的结构比边生成边写入更安全，也便于在 UI 中展示预览。

在这里插入图片描述

九、安全更新路由：禁止粗暴字符串拼接

路由表或 JSON5 配置是最容易被生成器破坏的文件。错误做法是查找最后一个 ]，然后插入字符串。只要文件中出现注释、尾逗号或不同格式，就可能出错。

更安全的策略是：

读取原文件；
使用与项目配置格式兼容的解析器；
检查目标路由是否已存在；
修改抽象结构；
写入前创建备份；
写回后重新解析验证；
失败则回滚。

伪代码如下：

private fun updateRouteSafely(options: GenerationOptions) {
    val routeFile = locateRouteFile() ?: return
    val original = routeFile.readText()

    val routeDocument = json5Parser.parse(original)
    val routeName = options.pageName

    if (routeDocument.containsRoute(routeName)) {
        throw IllegalStateException("路由已存在：$routeName")
    }

    val backup = "$original\n"
    try {
        routeDocument.addRoute(
            name = routeName,
            pageSourceFile = "pages/${options.pageName}"
        )

        val updated = routeDocument.toFormattedText()
        json5Parser.parse(updated)
        routeFile.setBinaryContent(updated.toByteArray())
    } catch (error: Exception) {
        routeFile.setBinaryContent(backup.toByteArray())
        throw error
    }
}

这里的 json5Parser 是抽象接口，实际项目应根据当前配置格式选择可靠实现。

十、可视化 Tool Window：降低插件使用门槛

快捷键适合熟练开发者，但教学场景和跨团队推广更需要可视化界面。

工具窗口建议包含：

页面名称；
页面标题；
目标模块与目录；
状态管理方案；
是否生成 ViewModel；
是否生成 Repository；
是否注册路由；
生成文件预览；
冲突清单；
最近生成记录。

class GeneratorToolWindowFactory : ToolWindowFactory {

    override fun createToolWindowContent(
        project: Project,
        toolWindow: ToolWindow
    ) {
        val panel = GeneratorPanel(project)
        val content = ContentFactory.getInstance()
            .createContent(panel, "", false)

        toolWindow.contentManager.addContent(content)
    }
}

在生成按钮点击时，不应立即写文件，而应先调用 preview()：

val preview = generator.preview(options)

preview.files.forEach { file ->
    previewModel.addElement(
        "${file.relativePath}  ${file.status.displayName}"
    )
}

generateButton.isEnabled = preview.conflicts.isEmpty()

这一步能显著减少误操作，也能让学生清楚看到“插件将对工程做什么”。

十一、快捷键设计：速度之外还要考虑可发现性

本文为生成功能配置 Ctrl + Alt + H，但真实团队中需要做三件事：

检查是否与系统和 IDE 默认快捷键冲突；
在菜单中保留同名入口，方便新成员发现；
在团队 README 中记录快捷键用途。

推荐按操作频率分配：

功能	建议入口
高频、低风险	快捷键
中频、有参数	右键菜单 + 对话框
参数多、需预览	Tool Window
高风险配置修改	Tool Window + 二次确认
一次性迁移	独立脚本

快捷键不是越多越好。超过十个自定义快捷键后，团队记忆成本会反过来抵消收益。

十二、插件生成后的 ArkTS 示例

生成器输出的页面应保持清晰、可读，而不是为了“少写代码”制造复杂抽象。

import { DeviceDetailViewModel } from '../viewmodel/DeviceDetailViewModel'

@Entry
@ComponentV2
struct DeviceDetail {
  @Local private viewModel: DeviceDetailViewModel =
    new DeviceDetailViewModel()

  aboutToAppear(): void {
    this.viewModel.load()
  }

  build() {
    Column({ space: 16 }) {
      this.buildHeader()

      if (this.viewModel.loading) {
        LoadingProgress()
          .width(36)
          .height(36)
      } else {
        Text(this.viewModel.summary)
          .fontSize(16)
          .fontColor('#334155')
      }
    }
    .width('100%')
    .height('100%')
    .padding(20)
  }

  @Builder
  private buildHeader() {
    Row() {
      Text('设备详情')
        .fontSize(26)
        .fontWeight(FontWeight.Bold)
      Blank()
      Text(this.viewModel.online ? '在线' : '离线')
        .fontColor(this.viewModel.online ? '#15803D' : '#64748B')
    }
    .width('100%')
  }
}

ViewModel：

import { DeviceDetailRepository } from '../repository/DeviceDetailRepository'

@ObservedV2
export class DeviceDetailViewModel {
  @Trace loading: boolean = false
  @Trace online: boolean = false
  @Trace summary: string = '暂无数据'

  constructor(
    private readonly repository: DeviceDetailRepository =
      new DeviceDetailRepository()
  ) {}

  async load(): Promise<void> {
    if (this.loading) {
      return
    }

    this.loading = true
    try {
      const device = await this.repository.query()
      this.online = device.online
      this.summary = `${device.name} · ${device.roomName}`
    } catch (error) {
      this.online = false
      this.summary = '设备信息加载失败'
    } finally {
      this.loading = false
    }
  }
}

生成后的代码仍然需要开发者理解和维护。插件只消除机械劳动，不负责业务正确性。

十三、效率对比：如何证明工具真的有效

13.1 测量方法

我们在一个 6 人教学项目中记录 20 次重复任务，要求：

使用同一台实验室电脑镜像；
使用相同项目骨架；
优化前由开发者手工创建；
优化后使用模板与插件；
计时从开始创建到通过基础编译检查；
若发生命名或路由错误，返工时间计入总耗时。

13.2 测量结果

任务	优化前	优化后	时间下降
创建标准页面	12.8 分钟	2.4 分钟	81.3%
创建 Repository	8.6 分钟	1.8 分钟	79.1%
注册路由	5.1 分钟	1.2 分钟	76.5%
补齐日志骨架	3.9 分钟	0.7 分钟	82.1%
模块配置校验	7.4 分钟	2.1 分钟	71.6%

在这里插入图片描述

五类任务的平均耗时从 7.56 分钟 降至 1.64 分钟，样本内平均下降约 78.3%。

需要特别说明：这组数据用于展示测量方法，来自特定教学项目，不应直接外推为所有 HarmonyOS 团队的行业基准。不同项目架构、成员熟练度和插件成熟度都会影响结果。

13.3 不只看时间，还要看错误率

效率工具应至少追踪四个指标：

单次任务耗时；
首次编译通过率；
生成后手工修改行数；
因模板错误导致的返工次数。

若插件把创建时间从 10 分钟降到 2 分钟，却让开发者再花 15 分钟修复模板，说明它只是“生成得快”，并不是真正高效。

十四、从课堂到企业：推广效率工具的四个阶段

在这里插入图片描述

阶段一：个人试用

由一名开发者先验证模板是否稳定，避免直接影响全员。

阶段二：小组共创

邀请页面、数据、测试三个角色评审模板。页面开发者关注可用性，数据开发者关注边界，测试人员关注可测性。

阶段三：项目级默认

将稳定模板纳入项目仓库，配套版本号、变更日志和回滚方式。

阶段四：课程或组织级推广

为插件增加示例工程、安装说明、三分钟演示和常见问题，降低新成员学习成本。

在校企合作课堂中，可以把插件设计作为综合实训任务。学生不仅要会写 ArkTS，还要理解：

什么是可重复流程；
如何抽取工程规范；
如何设计参数模型；
如何处理文件冲突；
如何验证工具收益；
如何对生成代码负责。

这比单纯练习页面布局更接近真实软件工程。

十五、常见问题与避坑清单

15.1 插件在某个 DevEco Studio 版本无法加载

原因通常是平台版本或插件依赖范围不匹配。应检查：

插件声明的兼容版本；
JDK 与 Gradle 配置；
使用的 IntelliJ API 是否在当前 IDE 中存在；
是否引用了仅在其他 IDE 产品中提供的模块。

15.2 生成文件后项目树没有刷新

不要只使用普通磁盘文件 API。应通过 IDE 虚拟文件系统写入，并在操作完成后刷新相关目录。

15.3 中文路径或特殊字符导致失败

生成前统一校验目标路径和文件名。对页面名仅允许合法标识符，对展示标题则允许中文。

15.4 文件存在时是否覆盖

默认禁止覆盖。更好的交互是提供：

跳过；
对比差异；
另存为；
明确确认后覆盖。

绝不能静默覆盖用户代码。

15.5 模板升级后旧项目怎么办

模板应版本化。可以在生成文件头部写入生成器版本，但不要在每次打开项目时自动改写旧代码。

15.6 生成代码是否需要进入版本控制

需要。生成器只是创建代码，最终代码仍属于项目资产，必须经过评审、测试和版本控制。

十六、代码模板的维护规范

建议为每个模板维护以下元数据：

{
  "templateId": "arkui-page-v2",
  "displayName": "ArkUI 标准页面",
  "version": "1.3.0",
  "minPluginVersion": "1.2.0",
  "variables": [
    "PAGE_NAME",
    "PAGE_TITLE",
    "VIEW_MODEL_NAME"
  ],
  "owner": "Harmony Teaching Team",
  "updatedAt": "2026-07-18"
}

模板变更遵循语义化版本：

修正文案或格式：补丁版本；
增加可选变量：次版本；
改变目录或生成结构：主版本。

每次模板升级至少运行：

空项目生成测试；
已存在目录测试；
文件冲突测试；
中文标题测试；
路由重复测试；
编译检查；
代码格式检查。

十七、完整落地建议

对于 3～10 人的 HarmonyOS 团队，推荐采用以下最小闭环：

先统计一周重复动作；
选择出现频率最高的三个动作；
用 Live Template 解决最简单的一项；
用文件模板统一页面骨架；
只为跨文件操作开发插件；
插件默认不覆盖任何文件；
每次生成输出操作日志；
记录任务耗时与返工；
两周后删除低使用率功能；
每个季度重新审视模板是否仍符合项目架构。

这套方法的重点不是“做出一个插件”，而是建立持续改进的开发者体验。

总结

HarmonyOS 6.1 项目的开发效率提升，不应只理解为记住更多快捷键，也不应简单等同于引入 AI 编码。真正稳定的效率来自三件事：

把团队规范固化成可执行模板；
把跨文件重复操作封装成安全工具；
用数据确认工具是否减少耗时和错误。

Live Template 适合解决局部重复，File Template 适合统一文件骨架，IDE Action 适合处理跨文件动作，Tool Window 适合承载复杂参数和生成预览。四者组合后，开发者可以把注意力从目录创建、命名复制和配置拼接，转移到页面交互、状态管理、性能与业务价值上。

更重要的是，代码生成器必须遵守工程边界：不静默覆盖、不粗暴修改配置、不隐藏生成过程、不替代代码评审。 只有这样，效率工具才会从“个人小技巧”成长为可复用、可教学、可维护的团队资产。

转载自：https://blog.csdn.net/u014727709/article/details/162996459
欢迎 👍点赞✍评论⭐收藏，欢迎指正

HarmonyOS开发者社区

讨论HarmonyOS开发技术，专注于API与组件、DevEco Studio、测试、元服务和应用上架分发等。

更多推荐

兼容适配：M-Robots 如何实现 ROS 生态无缝迁移，降低替换成本

长期以来 ROS 是机器人行业主流开发工具，但底层依赖 Linux、实时性能不足、国产适配薄弱，随着产业自主化需求提升，大量企业与开发者希望切换国产系统，却担心原有算法、工程代码全部作废。在兼容性之外，M-Robots 额外提供原生鸿蒙独有能力：跨设备算力共享、超级终端互联、单芯硬实时调度，迁移后的项目可按需接入群体智能、多机协同新特性，实现功能升级。