欢迎加入鸿蒙PC开发者社区，共同打造开发者工具生态：鸿蒙PC开发者社区 ：https://harmonypc.csdn.net/

项目开源地址：https://AtomGit.com/lqjmac/ele_mobanzhuangpin

这一篇我按说明书的方式写，因为模板管理本身就很像装配：先有模块，再有变量，再做检查，最后交付。

如果把模板管理只写成“新建、编辑、删除、导出”，文章会落回普通后台说明。所以这一篇从装配动作开始写。

这台工具适合谁

模板装配台适合三类人：

• 经常写重复文档的人，比如周报、发布说明、验收记录
• 经常整理固定话术的人，比如客服回复、项目通知、交付说明
• 经常维护组件化内容的人，比如页面段落、变量说明、清单模板

这些人真正需要的不是一个“模板仓库”，而是一张能说明模板如何组合、哪些变量要替换、发布前要检查什么的装配单。

先定义模板单

模板单不是一段固定文本。

它应该至少包含：

• 模块清单：这个模板由哪些部分组成
• 变量规则：哪些位置需要替换
• 装配流程：先填什么，再检查什么
• 发布参考：最终交付时看哪些例子

这就是页面里的分类：

const categoryLabelMap: Record<TemplateCategory, string> = {
  product: '模块清单',
  research: '变量规则',
  workflow: '装配流程',
  reference: '发布参考',
}

状态也换成模板语境：

const stateLabelMap: Record<TemplateState, string> = {
  draft: '待装配',
  stable: '已定版',
  watching: '待验证',
}

这两个映射决定了用户看到的是模板工作台，而不是普通文本列表。

页面不是展示模板，而是安排装配

模板装配台的页面有三个重点。

第一，左侧是控制台。它负责搜索、分类、新建模板单和查看统计。

第二，中间是装配台。它有顶部概览、工具栏、置顶模板和模板货架。

第三，右侧是洞察区。它放关键词、关键高亮和关联条目，帮助用户确认这张模板单还能和哪些模块组合。

这三个区域对应三种动作：

• 找到模板
• 修改模板
• 检查模板

如果一个模板工具只能保存正文，它很快会变成普通备忘录。装配台要多一步，让用户知道模板为什么可以复用。

视觉上更像一张工单

我让它更像一张工单：白底、深色标题条、橙色装配线、清楚的边框。

主题类名是 assembly-app：

<div class="template-app assembly-app">
  ...
</div>

相关样式：

.assembly-app .workspace-header {
  grid-template-columns: minmax(0, 1fr) 360px;
  background: #ffffff;
  color: #17212d;
  border: 1px solid #c8d2dc;
  border-left: 8px solid #d7822e;
}

.assembly-app .template-card::before {
  content: '';
  position: absolute;
  left: 0;
  top: 0;
  bottom: 0;
  width: 6px;
  background: #d7822e;
}

橙色竖线像一条装配标记，让列表里的每张模板单都更像待处理工单。

模板单编辑器要强调变量和检查点

模板装配台的编辑器并不只是写正文。

字段含义可以这样理解：

字段	模板语境里的含义
title	模板单名称
category	模块、变量、流程或参考
state	待装配、已定版或待验证
source	模板来源或使用场景
topic	模板主题
keywords	可检索变量
summary	模板用途摘要
highlights	关键变量和边界
related	相关模块或条目
content	完整装配说明

这种字段设计能避免模板只剩一段正文。

模板最重要的恰恰不是正文，而是哪些地方不能漏、哪些变量必须替换、哪些场景不适用。

复制摘要不是复制整张模板

模板装配台保留复制摘要按钮。

为什么不是直接复制全文？

因为很多时候用户只是要把模板单的结论发给别人，比如“这张模板已经定版”“变量规则还没确认”“发布前需要补一个检查项”。

const handleCopy = async () => {
  if (!currentNote.value) return
  const text = currentNote.value.summary || currentNote.value.highlights || currentNote.value.title
  const ok = await copyText(text)
  if (ok) {
    showFeedback('模板摘要已复制')
    await notify('模板装配台', '当前模板摘要已经复制到剪贴板')
  }
}

摘要优先、高亮兜底、标题保底。这条规则在模板场景里也成立。

导出内容要能交给别人继续装配

模板单导出时，我会保留完整上下文。

const exportTemplate = () => {
  if (!currentNote.value) return ''
  const note = currentNote.value
  return [
    `# ${note.title.trim() || '未命名模板单'}`,
    '',
    `- 类型：${categoryLabelMap[note.category]}`,
    `- 状态：${stateLabelMap[note.state]}`,
    `- 来源：${note.source || '未设置'}`,
    `- 主题：${note.topic || '未设置'}`,
    `- 关键词：${note.keywords || '未设置'}`,
    `- 下次复查：${note.nextReview || '未设置'}`,
    '',
    '## 摘要',
    '',
    note.summary.trim() || '暂无摘要',
    '',
    '## 关键高亮',
    '',
    note.highlights.trim() || '暂无高亮',
    '',
    '## 装配说明',
    '',
    note.content.trim() || '暂无正文',
  ].join('\n')
}

这份 Markdown 可以直接进入项目文档，也可以发给同事补变量和检查项。

桌面端要特别注意窗口和滚动

模板装配台的信息密度比较高。左侧控制台、中间装配台、右侧洞察区同时存在时，很容易超过窗口高度。

所以外层必须给内容区滚动能力：

.app-content {
  min-height: 0;
  overflow: auto;
}

.template-app {
  min-height: 100%;
  height: auto;
}

这里的 min-height: 0 很关键。桌面窗口里如果父级 Grid 或 Flex 没有放开高度，内部滚动会失效，用户会误以为页面卡住。

窗口控制也应该尽量交给鸿蒙 Electron 原生能力或原生窗口栏处理。业务页面不应该因为按钮实现不稳而影响应用可用性。

验收这台装配台

1. 页面标题是否是模板装配台
2. 分类是否围绕模块、变量、流程、参考
3. 状态是否围绕待装配、已定版、待验证
4. 视觉是否和第 23、24 篇明显不同
5. 页面内容是否可以滚动
6. 复制和导出是否走原生桥接
7. HAP 启动时是否没有 ERR_FILE_NOT_FOUND
8. 包内是否包含最新构建的 dist/index.html

最后：模板不是一段文本，而是一套装配关系

模板装配台的第一版没有做复杂模板变量渲染，也没有做模板市场。

它先把模板管理拆成模块、变量、流程和参考四件事，再让每张模板单有状态、有摘要、有检查点、能复制、能导出。

这就够支撑一个本地优先的桌面工具雏形。