鸿蒙 PC Markdown 编辑器品牌工程：从命名到分层应用图标

摘要

桌面软件的名称和图标不是开发完成后补上的包装，它们是用户第一次判断“这是什么软件、能不能解决我的问题”的界面。对于 Markdown 编辑器，这个判断尤其苛刻：图标如果只做成抽象字母，用户可能把它认成笔记、写作或办公软件；名称如果只追求古典感，用户又无法在应用市场、任务栏和窗口标题里迅速确认产品类别。本次为 HarmonyOS PC / 2in1 优先的本地 Markdown 编辑器建立正式品牌“芯笺 Markdown”，同时设计一套由文稿、字母 M 与向下箭头组成的分层应用图标。目标不是制造复杂视觉，而是在 16 像素级标题栏、48 像素级任务栏和 1024 像素级市场素材之间保持同一识别语义。

本文独立讲解一次真实的鸿蒙 PC 应用品牌工程：怎样把命名约束转成可验证条件，怎样按 HarmonyOS 分层资源组织前景与背景，怎样避免图标在系统遮罩和小尺寸缩放后失去含义，怎样同步 AppScope、EntryAbility、ArkWeb 与导出文档中的名称，以及怎样通过自动化构建和模拟器截图证明品牌替换没有破坏编辑器。对应仓库为 https://gitcode.com/VON-/codex_md_oh，最终名称功能提交为 a6e98dc。

一、先把“醒目”改写为工程约束

“起一个醒目点的名字”和“做一个一眼可见的 Logo”看似是主观需求，直接画图很容易得到无法验收的结果。工程上需要先把它们转成约束。第一条约束是品类可见：正式名称必须出现 Markdown，不能要求用户先理解一个新造中文词再猜产品用途。第二条是图形冗余：图标至少用两种互相独立的线索表达编辑器品类，本项目选择文稿轮廓与 Markdown 的 M/向下箭头。第三条是桌面尺寸：标志不能只在宣传海报上成立，缩小到窗口标题栏后仍应看见主要轮廓。第四条是系统适配：HarmonyOS 分层图标的背景和前景会被系统分别处理，因此关键语义不能画在安全区之外。第五条是一致性：窗口标题、应用标签、恢复提示、Web 文档标题和导出默认标题不得继续混用旧名称。

这些约束形成一个简单的验收矩阵：

场景	用户看到的内容	必须保留的语义
应用市场或项目主页	横向组合标志	芯笺、Markdown、HarmonyOS PC 编辑器
桌面应用图标	方形分层图标	文稿、M、向下箭头
窗口标题栏	16 至 24 像素图标与名称	芯笺 Markdown
任务栏或 Dock	小尺寸方形图标	高对比文稿与 Markdown 记号
ArkWeb 文档标题	运行时文本	中英文都保留 Markdown
HTML 导出无标题回退	安全文本	芯笺 Markdown document

这里有一个重要取舍：醒目不等于使用更多颜色、渐变或装饰。桌面生产力软件需要在长时间工作中保持安静，而图标只承担定位和品类识别。因此品牌色控制为深绿、纸白、墨绿、朱砂和折角暖橙五种，编辑器既有主操作绿也能继续延用，不必为了换标志重写整个界面主题。

二、名称为什么是“芯笺 Markdown”

中文短名称需要可读、可记，也需要与软件的工作方式一致。“芯”对应数字内核、端侧能力和技术感，适合表达编辑器在鸿蒙 PC 上运行的本地内核；“笺”是一页承载文字的轻量文稿，比“平台”“空间”更接近写作对象。“芯笺”因此不是只谈速度，也不是只谈文艺感，而是把软件内核与数字文稿放进同一个名字。正式名称继续保留英文 Markdown，所以即使用户第一次接触“芯笺”，也不会把软件错认成普通便签或芯片工具。

命名过程中还必须区分三类标识。第一类是用户品牌，即“芯笺 Markdown”；第二类是工程兼容标识，例如包名 com.example.ohmarkdown；第三类是运行时协议，例如 window.OhMarkdownEditor。本次只替换第一类，不在品牌任务中强行重命名包名和 Bridge。原因很实际：包名影响安装覆盖、数据目录、系统关联和未来升级；Bridge 名称影响 ArkUI 与 ArkWeb 的既有协议和全部测试。把三类标识一起替换，看起来“干净”，实际上会把低风险视觉任务扩大成数据迁移任务。

因此 README 中明确写出“原工程代号 OhMarkdown，仅保留在兼容 API、历史提交和内部技术标识中”。这种做法并不矛盾。用户界面已经使用新品牌，而工程内部仍能保持提交历史、包升级和协议稳定。等正式发布包名确定后，再通过独立 ADR 和迁移测试处理，而不是在设计 Logo 时顺便改掉。

命名还进行了公开网络快速重名检索，用于排除明显冲突。检索能找到“芯笺”作为非产品活动用语的个别用例，暂未发现准确同名的在营 Markdown 编辑器；这仍不能代替商标法律意见。公开发行前必须继续查询应用市场、域名、企业名称以及相关商标类别。把边界写进品牌说明，是为了避免团队在后续宣传中把“快速搜索未发现软件同名”误写成“名称已经获得法律保护”。

三、为什么必须保留 Markdown 的视觉语法

Markdown 社区常见标志由字母 M 与向下箭头构成：M 表示 Markdown，箭头同时呼应 “down”。Dustin Curtis 发布的 Markdown Mark 使用 CC0，允许在品牌设计中重新构造适合应用图标的几何形式。本项目没有直接把原图塞入图标，而是保留识别语义后重新绘制，因为原始横向标志的比例不适合系统方形安全区，细线也会在标题栏尺寸上损失。

重绘时使用三个层次。最外层是深绿色背景，用于在浅色 HarmonyOS 桌面和白色窗口标题栏上形成轮廓。中间层是纸白文稿，顶部右侧折角用暖橙区分普通白色方块。最内层是墨绿色 M 和朱砂向下箭头，二者共享稳定的视觉中心。箭头采用不同色，不是为了装饰，而是防止小尺寸下箭杆和 M 的竖笔粘连。

核心 SVG 采用实际几何路径而不是字体字符，避免不同设备字体替换导致形状变化：

<rect width="1024" height="1024" rx="216" fill="#075E50"/>
<path d="M280 178h310l154 154v514H280z" fill="#F7FAF8"/>
<path d="M590 178v154h154z" fill="#FFB15B"/>
<path
  d="M354 454h78l80 106 80-106h78v214h-70V558l-88 108-88-108v110h-70z"
  fill="#123B35"
/>
<path d="M476 688h72v64h74L512 848 402 752h74z" fill="#E46F4C"/>

真实仓库中的 docs/brand/xinjian-mark.svg 还包含安全区和边缘调整，但结构就是以上四层。路径不用滤镜、阴影和外部字体，也没有位图嵌入，因此能直接审查颜色与坐标，后续生成不同分辨率时不会产生来源不明的像素差异。

四、HarmonyOS 分层图标不是一张 PNG

鸿蒙应用图标资源使用 layered image 描述前景和背景。系统可能根据设备形态、主题和视觉规范对图层应用裁剪或位移，因此不能把最终合成图同时放进前景和背景。这个项目原先已经存在 $media:background 与 $media:foreground 引用，本次沿用现有结构，只替换对应运行时资源。

背景源 icon-background.svg 负责稳定铺满主色，不承载必须识别的文字；前景源 icon-foreground.svg 使用透明画布，只放文稿、折角、M 和箭头。配置仍然由既有 layered image JSON 引用：

{
  "layered-image": {
    "background": "$media:background",
    "foreground": "$media:foreground"
  }
}

这里需要处理两个常见错误。第一个错误是把圆角画进背景后又让系统施加圆角遮罩，结果形成双重边界或过大的空白。本项目的运行时背景保持 1024 x 1024 完整颜色，由系统决定最终外轮廓；文档主体放在中心安全区。第二个错误是前景占满画布，系统产生视差或裁剪时关键箭头被切掉。本项目把所有识别元素限制在中心区域，折角也不触碰边缘。

运行时资源在 AppScope 与 entry 中各有一份。重复文件不是理想抽象，但这是现有工程和 HarmonyOS 资源编译的实际边界。本次以 docs/brand/ 中 SVG 作为唯一设计源，再一次性生成：

AppScope/resources/base/media/background.png
AppScope/resources/base/media/foreground.png
entry/src/main/resources/base/media/background.png
entry/src/main/resources/base/media/foreground.png
entry/src/main/resources/base/media/startIcon.png

设计源和运行时产物分离后，后续改色只需要修改 SVG 并重新生成，不允许分别在五张 PNG 上手工涂改。这样可以避免 AppScope 图标已经更新，而启动窗口仍显示旧图的品牌漂移。

五、小尺寸可读性要靠删减而不是缩放

1024 像素标志缩成 16 像素时，真实可用细节非常少。直接等比缩放一张带品牌文字的横向 Logo，会让汉字和副标题全部变成灰色噪点。因此本项目准备两套组合：独立方形标志用于应用图标、标题栏和任务栏；横向组合标志用于 README、媒体资料和产品页面。它们共享颜色与图形，但不强求在每个尺寸显示相同信息。

标题栏启动图标单独生成 144 x 144 的 startIcon.png。它没有副标题，也没有细边框，文稿和 M/箭头的面积比 1024 像素宣传标志更集中。实际模拟器截图中，窗口左上角图标虽然只有很小面积，白色文稿轮廓仍可见，内部深色 M 与朱砂箭头没有完全糊成一个点。配合紧邻的“芯笺 Markdown”窗口标题，品类识别不依赖用户放大查看图标。

横向组合标志则保留正式名称和英文品类说明：

芯笺 Markdown
MARKDOWN EDITOR FOR HARMONYOS PC

这种双轨输出也降低了本地化压力。应用图标不含语言文字，可以在中文和英文系统中复用；正式名称保留 Markdown，中文品牌不影响海外用户判断类别；英文副标题只出现在空间足够的品牌板中，不会挤压 PC 工作台工具栏。

六、名称替换必须穿过四层运行时

HarmonyOS 混合应用的可见名称并不只在一个配置文件里。AppScope 的 app_name 决定应用级标签；entry 的 EntryAbility_label 参与能力和窗口显示；ArkUI 资源包含中英文描述和恢复提示；ArkWeb 自己还有 HTML <title> 与运行时语言切换后的 document.title。只改其中一个，用户就会在不同位置看到两套品牌。

应用级资源修改如下：

{
  "string": [
    {
      "name": "app_name",
      "value": "芯笺 Markdown"
    }
  ]
}

中文 EntryAbility 资源同时使用完整名称：

{ "name": "module_desc", "value": "芯笺 Markdown 编辑器" },
{ "name": "EntryAbility_desc", "value": "芯笺 Markdown 编辑器" },
{ "name": "EntryAbility_label", "value": "芯笺 Markdown" }

Web 编辑器在设置语言时动态写标题，不能只修改静态 index.html：

function setLocale(locale: string): void {
  editorLocale = locale.toLowerCase().startsWith('zh') ? 'zh-CN' : 'en';
  document.documentElement.lang = editorLocale;
  document.title = editorLocale === 'zh-CN'
    ? '芯笺 Markdown 编辑器'
    : '芯笺 Markdown Editor';
  // 后续继续同步命令、占位符和可访问名称。
}

HTML 导出也有无标题回退值。它必须经过既有 escapeHtmlText，品牌替换不能绕开安全编码：

const safeTitle = escapeHtmlText(
  title.trim() || '芯笺 Markdown document'
);

恢复提示、模拟器启动脚本以及独立分享接收测试应用也同步更新。后者虽然不进入正式包，却会出现在团队验收截图和技术文档中；继续显示旧名称会让测试证据难以判断属于哪个版本。相反，包名与 window.OhMarkdownEditor 保持不动，因为它们不是用户文案。

七、品牌改动同样需要完整回归

“只换字符串和图片”并不代表不需要测试。资源编译可能因为中文、JSON 格式或图片通道失败；新图标可能超出 HAP 资源限制；Web 标题修改会触发单文件重新打包；重新构建的 rawfile/editor/index.html 可能意外引用外部资源。更重要的是，本项目的品牌调整发生在已经进入 G4 的复杂编辑器上，任何构建链变化都不能用肉眼截图代替回归。

本次先执行 ./scripts/build-debug.sh。脚本运行 TypeScript 类型检查、Vite 单文件构建和 Hvigor Debug HAP 构建。生产 ArkWeb 单 HTML 为 7,690,548 字节，SHA-256 为 dcfdee814a781e55ce2515119a16ed927eade2998c095e259583ef1112d36cba；Debug HAP 为 8,719,158 字节，SHA-256 为 5d521a0f21c3aeb69494e94b05fc5ac192caa71246b887b99d5de589efc6c500。

随后运行 Playwright 全量测试，59/59 通过。测试覆盖源码、即时、分栏和预览模式，GFM、KaTeX、Mermaid、代码高亮，多文档会话、查找替换、图片 Bridge、导出、快捷键、链接助手、无障碍焦点和 RTL/Unicode。品牌替换没有改变这些逻辑，但完整回归能证明重新生成的 Web 单文件仍然可用。ArkTS UnitTestBuild 同样 BUILD SUCCESSFUL，资源字符串和工程编译没有引入错误。最后执行 git diff --check，排除文档和代码中的空白格式问题。

这里没有为了品牌改动新增“永远通过”的单元测试，例如断言字符串等于某个品牌名。品牌内容以后仍可能调整，这类测试只会制造维护噪音。真正需要保留的是构建门禁、运行时截图和品牌资产说明：前者证明应用没有坏，后两者证明这次设计满足识别目标。

八、模拟器验收看到的不是设计稿

品牌图标在 SVG 预览器中好看，不等于进入 HAP 后一定正确。最终调试包通过 HDC 安装到 DevEco Studio 的 MateBook Pro 2in1 模拟器，目标为 127.0.0.1:5555：

hdc -t 127.0.0.1:5555 install -r \
  entry/build/default/outputs/default/entry-default-unsigned.hap

hdc -t 127.0.0.1:5555 shell aa start \
  -a EntryAbility -b com.example.ohmarkdown

安装返回 install bundle successfully，启动返回 start ability successfully。模拟器中的窗口标题显示“芯笺 Markdown”，左上角使用新文稿/Markdown 图标。编辑器文件活动栏、侧栏、标签栏、源码工具栏、外部修改横幅、正文与状态栏都正常显示。截图来自模拟器显示缓冲区，再裁取当前前台窗口，不是把 Logo 合成到旧界面上。

截图还揭示一个品牌工程容易忽略的事实：标题栏可用面积很有限，名称不能长到挤压窗口控制区。“芯笺 Markdown”比描述型长名称更适合这里；“鸿蒙 PC 本地专业 Markdown 编辑器”可以作为渠道副标题，却不应该成为应用标签。短品牌与明确品类的组合，在真实窗口中比单纯追求中文意境更稳定。

模拟器也存在边界。它能证明资源进入最终 HAP、窗口标题生效、图标由系统渲染，并能观察当前分辨率下的小尺寸效果；它不能替代鸿蒙 PC 真机的开始菜单、桌面快捷方式、高 DPI 多显示器、系统主题、厂商图标遮罩和应用市场素材验收。因此本轮结论是“模拟器品牌路径通过”，不是“所有真实设备完成发布验收”。

九、颜色系统必须服务编辑器而不是支配编辑器

品牌主色为澄绿 #075E50，与编辑器既有的绿色活动状态和主按钮相容。墨绿 #123B35 用于 M 和主要文字；朱砂 #E46F4C 只给向下箭头和少量强调；笺橙 #FFB15B 用于折角；纸白 #F7FAF8 表达文稿。五个颜色不是五种同等权重的主题色，而是明确层级：深绿提供外轮廓，纸白提供最大对比，墨绿负责核心字形，朱砂负责箭头识别，暖橙只做文稿折角。

这种设计避免一套 Logo 反过来要求整个编辑器变成单一绿色。PC Markdown 编辑器的主体仍然是大面积中性纸面、灰色分隔、黑色正文和少量绿色操作状态；错误、警告和冲突继续使用自己的语义色。品牌色不能覆盖系统警告，也不能把所有按钮都改成绿色，否则用户会失去主次判断。Logo 在桌面上负责找到应用，进入应用后界面应把注意力交还给 Markdown 文档。

深色模式以后如果需要专用渠道标志，也应保持同一图形语义，只调整外部承载底和文字颜色，不改变 M/箭头结构。应用图标本身已经有深绿底和纸白文稿，在浅色与深色桌面都具备轮廓，因此不需要为追求动态效果增加难以验证的渐变或光泽。

十、源文件治理决定品牌能否长期一致

最终品牌目录不是只有一张 PNG，而是一套职责清晰的源文件：

docs/brand/
├── README.md
├── xinjian-logo.svg
├── xinjian-mark.svg
├── xinjian-mark.png
├── icon-background.svg
├── icon-foreground.svg
└── start-icon.svg

xinjian-mark.svg 是独立品牌标志，xinjian-logo.svg 是带正式名称与品类说明的横向组合，icon-background.svg 和 icon-foreground.svg 是 HarmonyOS 分层运行时源，start-icon.svg 针对小尺寸启动窗口，PNG 只用于渠道预览。README 记录名称含义、颜色、文件职责、Markdown 标志来源、重名检索边界和生成原则。

把资产说明纳入仓库有两个好处。其一，后续开发者不会从 HAP 里的 1024 PNG 反向猜测设计参数；其二，媒体材料与应用运行时有同一事实来源。任何改版都应该同时检查六项：独立标志、横向组合、分层前景、分层背景、启动图标和模拟器截图。只提交一张“新 Logo.png”而不更新运行时资源，不算完成品牌改版。

本次最终名称功能提交 a6e98dc 将源文件、运行时 PNG、名称资源、Web 标题和 README 放在同一个可追踪变更中。测试报告另行记录 HAP 哈希、模拟器命令和截图。技术文章与图片按项目约定保存在本地 technical-articles/，不推送远程仓库；品牌资产和验收报告属于产品工程事实，所以进入 GitCode 主仓库。

十一、这套标志怎样做到“一眼看出 Markdown 编辑器”

最终答案不是某一个图形细节，而是三层冗余。第一层是名称，“芯笺 Markdown”在任何文本列表里都直接出现品类；第二层是应用图标，纸张说明这是文档工具，M 和向下箭头说明是 Markdown；第三层是应用工作台，启动后立即出现文件侧栏、.md 标签、源码/即时/分栏/预览模式和状态栏 Markdown。用户不需要依赖品牌故事才能理解产品。

如果只使用羽毛、钢笔、墨滴或书页，这些符号最多能表达“写作”，无法区分 Markdown、富文本、笔记和 PDF 阅读器。如果只使用字母 M，它可能代表任何以 M 开头的软件。如果只在名称里写 Markdown 而图标完全抽象，任务栏折叠后又失去识别。把文稿与 Markdown 记号组合，才适合 PC 多窗口环境下的快速定位。

这也解释了为什么正式名称不是单独的“芯笺”。短名称可以出现在口头传播和有限空间中，但应用市场、README 首标题和窗口标签使用“芯笺 Markdown”。文化感负责记忆，技术品类负责理解，两者不互相替代。

十二、发布前还需要做什么

品牌工程完成不等于品牌发布完成。第一，必须进行正式商标与应用市场清查，决定是否注册中文、英文和图形标。第二，生产包名不能继续停留在示例命名，迁移时要验证已有测试安装、数据目录、文件关联与升级策略。第三，需要在鸿蒙 PC 真机检查桌面、开始菜单、任务栏、小窗口、多显示器和深浅主题。第四，应用市场需要准备不同尺寸截图、隐私政策、支持入口和能力描述，所有文案必须与当前真实功能一致。第五，若后续加入英文品牌名，应避免覆盖中文短名称，也不能移除 Markdown 品类词。

性能与兼容性阶段还应把图标资源纳入发布检查：确认 PNG 色彩通道、透明区域、分层安全区、不同缩放档位和 HAP 资源大小；确认截图没有旧名称、测试数据或用户路径；确认导出的 HTML 标题和系统分享来源都使用正式名称。品牌资源虽然不参与编辑算法，却会穿过构建、安装、窗口、分享和渠道多个边界，应该与代码一样接受版本控制和发布门禁。

结语

鸿蒙 PC Markdown 编辑器的品牌设计，真正难点不在于画出一张好看的方形图，而在于让名称、图标、分层资源、混合运行时和模拟器证据形成闭环。“芯笺 Markdown”保留了可记忆的中文短名，也把 Markdown 品类放在用户第一眼能看到的位置；文稿、M 和向下箭头在不同尺寸上重复表达同一用途；SVG 设计源、HarmonyOS 前后景 PNG、启动图标和 Web 标题由一次提交统一管理。

最终自动化结果为 Playwright 59/59、Debug HAP 构建成功、ArkTS UnitTestBuild 成功，MateBook Pro 2in1 模拟器完成覆盖安装和实际启动。模拟器截图证明新名称与新图标已经进入真实应用窗口，而不是停留在设计稿。接下来仍需真机、多显示器、应用市场与正式法律检索，但至少从现在开始，用户看到名称或图标时，不必先读产品介绍，就能知道这是一款面向鸿蒙 PC 的 Markdown 编辑器。