内容元素

项目列表

【规则】无序列表统一使用破折号（-）并紧跟一个空格，有序列表统一使用数字并紧跟一个英文句点和一个空格。

【规则】列表项采用相似结构、统一句式，例如，全部采用短语或句子。

【规则】当项目列表项是术语、短语时，句末统一不加标点符号；当项目列表项是句子时，句末统一加句号。

【建议】一个项目列表的列表项建议为2～9项。

【建议】只有一项的列表和前后上下文的内容合并，采用正文样式。

【建议】列表的层级不超过2层，包括有序列表和无序列表的组合。

表格

【规则】表格至少为两行两列。

【规则】表格行数（Rows）应≤9行，列数（Columns）应≤4列，推荐2～3列。大于4列的表格需要拆分或将列内容合并，以减少列数；也可采用项目列表等形式改写。每个单元格中，内容所占行数不宜超过5行。

【规则】Markdown中，如果表格预览效果不佳，请采用减少列数、减少单元格内容中单个英文字符串长度、或将表格改写为项目列表等方式调整，以免影响可读性。

【规则】相同类型的表标题、表头，风格保持一致，采用名词或名词词组的形式。

同样对参数进行说明的表，不应出现“参数说明”、“参数解释”、“参数含义”、“参数意义”等不同的表头内容，需要全文保持统一。

【规则】同一列信息的表达方式一致，句末的标点符号要保持一致。

• 如果表格一列全部为短语，句末不加句号。

• 如果表格一列全是句子或同时存在句子和短语，句末统一加句号。

【规则】不出现空白的单元格，无内容单元区分“无”和“不涉及”。如果大量的“不涉及”导致表格中重要信息不突出，则采用“－”表示“不涉及”。

【规则】Markdown语法不支持合并单元格，遇到对应场景需要进行表格拆分或将行内容直接合并。

【规则】表格内容默认使用左对齐。

【建议】如果表格的列数太多而行数较少，建议把表格的列转换成行。

图片

图片总体要求

【规则】严禁使用无版权图片。如无法确认是否拥有某图片的永久版权，请不要使用，改用自行绘制、拍摄的图片。

【规则】图片应清晰展示目标信息，避免使用人工合成或像素低的图片。

【规则】图片尺寸不能过大，在页面放大比例为100%的情况下，不能大于一屏。

【规则】图片禁止通过URL地址引用，需要存放到本地引用。

【规则】图片命名规范：

• 由字母、数字、中划线“-”组成。

• 语义化，图片名能体现图片展示内容的核心名词/动词，可从图标题、上下文、展示内容或目的等维度获取，原则上不超过4个英文单词。例如：typical-service-view.png。

• 同一文件夹下，图片名不允许重复。

【建议】为避免图片过大或过小，影响文档阅读体验，建议的图片宽度为：大图600磅（约800px）、中图360磅（约480px）、小图200磅（约260px）。

绘图

【规则】绘图中出现的英文单词大小写规则：术语、缩略语、专有名词（如开发板名称、设备名称）遵循术语及缩略语的要求，全文统一大小写；其它英文单词遵循Sentence caps样式，即首个单词首字母大写。

【建议】字号：中英文正常字号均采用10.5pt（14px）。中文字号下限为9pt（12px），英文字号下限为8pt（11px）。

【建议】优先使用灰色、蓝色两套配色，一张图建议不超过3套配色。

建议配色如下：

截图

【规则】界面截图边缘应完整、清晰。没有明显边界的，应手动添加浅灰色外边框（RGB：217/217/217）。

【规则】截图中，不要截取非必要信息，如桌面上的其他图标、工具栏等。

【规则】截图中，不能包含敏感信息，如私人邮箱、公网IP地址等。

【建议】截图中需要突出显示的关键信息，统一使用1px的蓝色（RGB：37/79/247）线框框选。框选时，应使关键信息位于框线中心位置，且框线尽量贴近关键信息边缘。

提示与说明

【规则】当需要向用户提供区别于正文的重要提示或补充说明信息时，请使用以下信息标识符，以示强调。

【规则】使用Markdown的引用语法“>”对提示或补充信息进行描述。

> 说明：

> 该接口从API Version 7 开始不再维护，建议使用newMethod替代。

【规则】提示或补充信息中不能包含表格和图片（图标除外）。

【规则】提示或补充信息内容不能过长，建议内容在一个段落范围内。

【规则】“注意”及更高级别的提示信息统一放在正文或步骤之前，用来提前警示相关事项，提醒用户避免损失。

【规则】禁止滥用“说明”。如果Web页面中一屏幕“说明”的数目超过2个，请考虑将其改为正文信息。

链接

链接规则

当需要参考其他手册内容、本手册中其他章节内容时，可添加到对应内容的链接。

【规则】跨文档或跨章节的链接，采用统一表达“请参见xxx”。

【规则】使用动词“单击”表示对网页类链接的操作。

【建议】对于内容很少（小于100字）但必须参考的内容，建议直接重述该内容；对于参考内容很多且不便重述的内容，添加链接。

【建议】一篇文档中应避免出现过多的交叉引用和外部链接。

链接样式

【规则】将链接URL写入内容，而不是直接在页面中暴露URL地址。

• 链接到其他手册、页面内容：[术语](glossary/glossary.md)

• 链接到本页面内其他内容段落：[FAQ](#faq)

• 链接到其他站点：[示例](www.example.com)

术语及缩略语

【规则】术语/缩略语名称要同“OpenHarmony术语表”保持一致，且全文统一。

【规则】对于“OpenHarmony术语表”中未涵盖的行业通用术语/缩略语（如IP，MAC等），要同国际、国家、行业标准中的名称保持一致。

【规则】禁止随意缩写英文单词，自创缩略语。

【规则】除行业通用术语/缩略语外，正文中出现的所有术语/缩略语都需要在术语表中给出解释。

【规则】中文文档中，缩略语全称中对应的字母大写。

【规则】“OpenHarmony术语表”中，术语名以“英文全称 (缩略语)；中文全称”的形式写作；术语解释直接陈述术语内涵，不需要重复术语名。

【建议】一篇文档中某缩略语首次出现的位置（标题和表头除外），提供英文全称，可选提供中文全称。

【建议】开发板名称、设备名称等不作为术语或缩略语，不在术语表中体现。建议在文档中单独以表格或其他形式介绍。

单位符号

【规则】用单位符号代替汉字名称。例如：mm代替毫米。

【规则】不能在组合单位中同时使用中文符号和单位符号。

【规则】词头不得孤立使用。

【规则】常用单位符号请参考下表。

标点符号

【规则】逗号：不可滥用，不可“一逗到底”。

【规则】句号：

• 在正文描述下紧接图或表时，句子说明已完整，以句号结束。

• 当一个句子包含在另一个句子中，并且前者属于后者的一部分时，前者句末不加句号。

• 括号中的内容不属于前一个句子，而是作为一个独立句子并且需要带括号时，句尾加句号。

【规则】冒号：不能在一个句子中连续使用冒号，避免导致冒号所提示的范围模糊。

【规则】圆括号：

• 中文文档中默认使用全角括号（代码块等特殊位置除外）。

• 不要在括号中出现太长的说明文字。如果有较长的说明信息，建议作为一个单独的“说明”。

【规则】句号、问号、叹号、逗号、顿号、分号和冒号不出现在一行之首。

【规则】引号、括号、书名号的前一半不出现在一行之末，后一半不出现在一行之首。

【规则】破折号和省略号都占两个字的位置，中间不能断开。

【规则】引号：中文文档中默认使用全角引号（代码块等特殊位置除外）。

【建议】问号：界面提示、CLI操作提示、语音提示、FAQ中可以使用问号。其他场景限制使用问号。

【建议】感叹号：任何场景下，不建议使用感叹号。

【建议】省略号：为使文档中描述的信息准确、全面，应尽量少用省略号或“等”。

【建议】其他：谨慎使用“√”“×”，在不同国家对这两个符号的理解可能正好相反。

字符转义

【规则】要显示原本用于格式化Markdown文档的字符，请在字符前添加反斜杠\进行转义，确保显示正常。

常见的可用于转义的字符有：“\”、“、”、“*”、“_”、“{}”、“[]”、“（）”、“#”、“+”、“-”、“.”、“！”、“|”等。

【规则】对于特殊字符需使用特定的转义符号：

• “<”使用“&lt”转义。

• “>”使用“&gt”转义。

• “&”使用“&amp”转义。

文件路径

文件路径指文件在计算机上的位置。

【规则】涉及电脑分区的文件，文件路径需包含明确的根目录。

【建议】文件路径尽量使用斜杠“/”来作为文件夹之间的分隔符。

【建议】尽量避免文件路径过长的情况。

代码与注释

请参见示例代码风格。

IP及MAC地址

【规则】IP地址举例只能使用私网IP，禁止使用公网IP（严禁使用实际现网数据）。私网IP地址范围如下。

【规则】表示具体组网和路由信息时，IP地址和掩码必须同时出现。

• 图片和表格中可以使用如“x.x.x.x/24”的方式，“24”表示掩码长度。

• 正文中必须使用255.255.255.0格式表示掩码，如“IP地址为10.10.10.1，子网掩码为255.255.255.252”。

【规则】涉及域名示例时，使用开源网址：www.example.com。

【规则】涉及MAC地址示例时，在保持格式正确的情况下，使用“X”进行模糊处理。

个人信息

【规则】严禁使用真实的个人信息。

【规则】涉及个人电话号码示例时，在保持格式正确的情况下，使用“*”进行模糊处理。

【规则】国际电话号码前添加国家码和地区码，并分别用括号括起，如(86) (755) ******** [Shenzhen, China]。

【规则】涉及个人身份证号、帐号名示例时，在保证格式正确的情况下，使用“*”进行模糊处理。

【规则】涉及邮箱示例时，在保证格式正确的情况下，进行模糊处理，例如：***@example.com。

【建议】涉及个人姓名示例时，尽可能使用通用名。