鸿蒙 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 文档标题运行时文本中英文都保留 MarkdownHTML 导出无标题回退安全文本芯笺 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 采用实际几何路径而不是字体字符避免不同设备字体替换导致形状变化rectwidth1024height1024rx216fill#075E50/pathdM280 178h310l154 154v514H280zfill#F7FAF8/pathdM590 178v154h154zfill#FFB15B/pathdM354 454h78l80 106 80-106h78v214h-70V558l-88 108-88-108v110h-70zfill#123B35/pathdM476 688h72v64h74L512 848 402 752h74zfill#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 自己还有 HTMLtitle与运行时语言切换后的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.htmlfunctionsetLocale(locale:string):void{editorLocalelocale.toLowerCase().startsWith(zh)?zh-CN:en;document.documentElement.langeditorLocale;document.titleeditorLocalezh-CN?芯笺 Markdown 编辑器:芯笺 Markdown Editor;// 后续继续同步命令、占位符和可访问名称。}HTML 导出也有无标题回退值。它必须经过既有escapeHtmlText品牌替换不能绕开安全编码constsafeTitleescapeHtmlText(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 为dcfdee814a781e55ce2515119a16ed927eade2998c095e259583ef1112d36cbaDebug HAP 为 8,719,158 字节SHA-256 为5d521a0f21c3aeb69494e94b05fc5ac192caa71246b887b99d5de589efc6c500。随后运行 Playwright 全量测试59/59通过。测试覆盖源码、即时、分栏和预览模式GFM、KaTeX、Mermaid、代码高亮多文档会话、查找替换、图片 Bridge、导出、快捷键、链接助手、无障碍焦点和 RTL/Unicode。品牌替换没有改变这些逻辑但完整回归能证明重新生成的 Web 单文件仍然可用。ArkTSUnitTestBuild同样BUILD SUCCESSFUL资源字符串和工程编译没有引入错误。最后执行git diff --check排除文档和代码中的空白格式问题。这里没有为了品牌改动新增“永远通过”的单元测试例如断言字符串等于某个品牌名。品牌内容以后仍可能调整这类测试只会制造维护噪音。真正需要保留的是构建门禁、运行时截图和品牌资产说明前者证明应用没有坏后两者证明这次设计满足识别目标。八、模拟器验收看到的不是设计稿品牌图标在 SVG 预览器中好看不等于进入 HAP 后一定正确。最终调试包通过 HDC 安装到 DevEco Studio 的 MateBook Pro 2in1 模拟器目标为127.0.0.1:5555hdc-t127.0.0.1:5555install-r\entry/build/default/outputs/default/entry-default-unsigned.hap hdc-t127.0.0.1:5555 shell aa start\-aEntryAbility-bcom.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.svgxinjian-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 标题由一次提交统一管理。最终自动化结果为 Playwright59/59、Debug HAP 构建成功、ArkTSUnitTestBuild成功MateBook Pro 2in1 模拟器完成覆盖安装和实际启动。模拟器截图证明新名称与新图标已经进入真实应用窗口而不是停留在设计稿。接下来仍需真机、多显示器、应用市场与正式法律检索但至少从现在开始用户看到名称或图标时不必先读产品介绍就能知道这是一款面向鸿蒙 PC 的 Markdown 编辑器。