风格指南¶

概述¶

本文档旨在对于少数派上发表文章的语言、版式、内容元素等方面提出可执行的要求，以便维持和改进文章的整体水平与可读性，并作为筛选高质量文章的参考标准。

本文档可被引称为《少数派风格指南》。

本文档适用于在少数派发表的下列内容：

各个版块的科技、技术主题文章；或
少数派正式的文档和公告、在少数派首页主时间线展示的文章，以及需要付费阅览的文章。

其他版块或其他主题的文章在可行范围内参照适用。

本文档未涉及的风格问题，应参考中文互联网一般实践，以及中文出版物的行业标准和国家标准；仍然不能得出结论的，可依兼顾严谨与开明的方针自行判断。

本文档中各条目包含的关键词具有如下含义和效力：

应或不应：表示相关要求是规范性的，须在各种情况下被遵守。投稿文章符合该等要求的情况将很大程度上影响编辑部的处理决定；任何在少数派首页展示的文章都将受到修订以满足该等要求。
宜：表示相关要求是推荐性的，如无充分理由采取相反行动，须被采纳。投稿文章符合该等要求的情况将在一定程度上影响编辑部的处理决定；任何在少数派首页展示的文章都将在考虑作者意见的基础上，受到修订以满足该等要求。
可以：表示相关要求是选择性的，作者须在予以充分考虑的基础上决定采纳或不采纳。

用词和措辞¶

规范文字¶

行文中使用的中文应为规范的简化字，符合现代标准汉语语法规范；非中文应符合相应语言主流和通行的字形、拼写和语法规范。

参阅

要了解中国对于社会一般应用领域的汉字使用规范，参阅《通用规范汉字表》。

得体语言¶

除非为实现特殊表达效果有必要或根据上下文另有需要，文中不应出现下列内容：

歧视性内容，包括但不限于基于地域、民族、国籍、宗教、年龄、性别或性别认同、性倾向、婚姻状况、肢体或精神伤残、疾病等的歧视；
未被公众广泛熟知的流行语、缩略语、简称、俚语、文化引用；
反语、隐喻、讽刺、影射等容易导致读者误解实际观点或立场的表述或修辞；
在内容主题和上下文不涉及对比的情况下，为突出描述对象的优点，以其竞争产品或实体的缺点作为衬托；
虚设无证据表明实际存在的现象或观点，作为内容立论依据；
其他对于表达内容主题和传递信息无实际作用，或具有明显逻辑谬误的表述。

专有名词¶

如果使用的专有名词或术语存在多种写法，按照如下优先顺序选用：

该名词或术语对应的实体，或该名词或术语所描述事物的权利人、提出者专门规定或一贯采用的写法；
在中国大陆或简体中文语境下权威或公认的写法；
其他作者认为合理的写法。

对于非中文专有名词或术语，应按下列方式处理：

如存在正式或通用的中文译名，优先使用中文；
如中文译名不够为人所知或存在多种版本，在第一次出现位置以「[中文译名]（[原名] [其他常见译名（如有）]）」的体例标注。

参阅

关于常见科技类名词的正式名称以及在少数派的可接受用法，参阅附录。

关于信息技术领域术语在不同地域的表述对照，参阅维基百科公共转换组「信息技术」。

缩略语和缩写¶

缩略语和缩写在文中第一次出现时，应在其后以括号加注全称，英文缩写还应注明中文译文，除非该缩写已经广为人知且被广泛使用。

引用内容¶

引用的一般要求¶

引用观点、数据、材料时，应尽合理努力采纳较可靠的来源，并优先使用一手来源。

应避免在文中长篇或全文引用。如果引文内容对于文章论述具有重要作用，应在文中引用关键部分，提供引文概述，然后提供指向引文全文的链接。

标注来源¶

引用观点、数据、材料应注明来源。

标注来源时，可以根据文章主题、风格、引用材料性质、对读者产生影响程度等因素，选择下列标注方式之一：

以文献参考格式在脚注中标注；
参照文献参考格式在引用位置后以括号夹注；
在引文的上下文中说明来源，并在适当位置添加指向来源的链接。

引注格式不作统一要求，但作仍应在可行范围内采取较高标准要求标注来源。

参阅

关于参考文献的列举规范，可参见中国国家标准 GB/T 7714-2005《文后参考文献著录规则》；也可参考维基百科关于文献参考格式的规定。

关于如何筛选来源，以及了解常见来源的可靠程度，参见维基百科指引词条「可靠来源」及辅助说明词条「常见有争议来源列表」。

受版权保护的材料¶

在文中引用他人创作的图片、视频、音频等受著作权保护的多媒体材料，应在题注、后续段落等紧邻的位置注明权利人的姓名或者名称、作品名称，以及任何关于获权利人授权的事实。

在不过分影响文意传达和文章质量的前提下，宜优先使用自行创作的作品、公有领域作品，或使用开放许可证传播的作品。

引用非中文内容¶

文中引用非中文整句、段落时，除非根据上下文另有需要，宜翻译为中文，并以括号注明系作者自行翻译（或译者姓名）。

译文应遵循中文文法和惯用表达，为实现此目的，应对句式结构、具体用词做灵活调整。

参阅

关于因照搬英文表述习惯导致的生硬表述（俗称「翻译腔」或「西化中文」）及处理方法，参见：

维基百科帮助词条「翻译腔」；
余光中文章《中文的常态与变态》；
Microsoft 的《简体中文本地化规范》。

引用翻译内容，可以不包含原文。但是如果存在下列情况，宜包含原文：

原文的特定表述具有较高认知度；
原文有翻译不易传达的表达效果；或
包含原文有助于避免歧义。

标点符号¶

中英文字符间的空格¶

汉字与英文字母、数字间应手动追加一个空格。但是，如英文部分之前或之后有中文标点符号，则英文部分与中文标点之间不设空格。

说明

依通说，中英文之间加入空隙，是为了实现视觉上的区隔，更加美观和易读。理想情况下，这种「空隙」应由排版引擎自动加入，宽度宜为 ¼ 个全角空格（em）。但由于数字排版环境复杂多变，在大多数时候（包括最常见的网页环境）不能指望排版引擎有这种能力，因此只能退而求其次，手动插入一个半角空格（因其宽度通常接近于 ¼ em），达到类似效果。

关于本规定的进一步讨论，参见知乎讨论「中英文混排时中文与英文之间是否要有空格？」，W3C 标准草案《中文排版需求》§ 3.2.2，以及《字谈字畅》播客第 14 期。

要自动在中英文之间添加空格可以使用 AutoCorrect、pangu.js 等工具。具体方法可参阅少数派文章《Markdown 语法检查器入门与进阶》。

标点符号的形态¶

应按照下表所示的用途和形态选用标点符号：

用途	形态
引用（中文）	单直角引号 `「`（U+300C）和 `」`（U+300D）引号中再次使用引号时，用双直角引号 `『`（U+300E）和 `』`（U+300F）
引用（英文）	半角双引号 `“`（U+201C）和 `”`（U+201D）引号中再次使用引号时，用半角单引号 `‘`（U+2018）和 `’`（U+2019）不使用直引号 `"`（U+0022）和 `'`（U+0027）
所有格、缩略（英文）	撇号（半角右侧单引号）`’` 不使用直引号 `'`
折行分词（英文）	连字符 `-`（U+002D）
编号、复合名词、型号、复姓时间、地域、数字的起止（英文）	短横线 `–`（U+2013）
说明、列举、插入、中断、间隔（英文）时间、地域、数字的起止（中文）	长连接号 `—`（U+2014）
说明、列举、插入、中断、间隔（中文）	两个长连接号（`——`）
省略	两个半角省略号 `……`（U+2026）不使用中英文句号代替省略号
中译人名间隔	`•`（U+2022）不使用 `●`（U+25CF）、`·`（U+00B7）等

说明

鼓励使用直角引号，是因为在中英文混排的场合，弯引号常常套用英文字体而显示为半角宽度，与汉字和其他中文标点差异很大，从而对排版效果产生不利影响。我们承认并尊重就此存在的不同审美判断，仅出于统一风格目的对首页文章做此要求。

要输入中文直角引号：

macOS 自带中文输入法：按 Shift+[ / ]。
iOS 自带中文输入法：长按引号键，在弹出的浮条中选择直角引号。
Windows 自带中文输入法：按 Win+.，切换到「Ω」标签页，选择直角引号。
其他中文输入法：在设置中开启「使用直角引号」或类似选项（如提供）；或配置用户词典。

参阅

关于更详细的标点符号规范用法，参阅中国国家标准 GB/T 15834—2011《标点符号用法》。

中英文并存时的标点符号¶

中文句内夹用英文句子，该句子应用中文标点结尾。夹用的英文句子用中文引号标示，英文句子内部用英文标点符号，除此以外用中文标点符号。英文引文中的问号、叹号应保留。

在中文技术名词后标注英文名称，英文全称与其缩略形式放在中文括号之内，使用英文逗号隔开。如果英文原文自带逗号，则使用英文分号隔开。

中文句子内夹有英文书籍名、报刊名时，不应借用中文书名号，应以英文斜体表示。夹有英文文章的标题时，该标题使用英文正体字，用中文引号标示。

举例

歌词中那句「Are we a nation of states? What’s the state of our nation?」颇有力度。

这款应用适用于 macOS、iOS、iPadOS 和 tvOS。

脱氧核糖核酸（deoxyribonucleic acid, DNA）是生物细胞内携带有合成 RNA 和蛋白质所必需的遗传信息的一种核酸。

这篇博客文章最初发表在本月的 MacWorld 杂志上。

畅销书 World of Tomorrow 中第七篇文章「Will Human Be Joyfully Enslaved by Cellphone?」在读者中成为热门话题。

参阅

更详细的中文文章夹用英文编辑规范，参阅中国新闻出版行业标准 CY/T 154—2017《中文出版物夹用英文的编辑规范》（PDF）。

避免滥用标点符号¶

不应以下列方式使用标点符号：

将引号用于强调或装饰目的；
用间隔号或其他点状符号标示列表项目；或
使用斜线表示并列的可选项，或在表格中表示「无」或「不适用」等含义。

文本样式¶

标题¶

标题的层级和内容应逻辑清晰、长短适宜。

相邻的标题应使用相同或连续的层级；不应跳跃层级创建标题。

不应仅出于放大字体、突出重点或强调的目的而使用标题样式。

粗体¶

粗体部分结尾的逗号、句号等点号不宜设为粗体，但整句设为粗体的除外。粗体部分包含引文、书名、篇名时，两端的引号、书名号应一并设为粗体。

不应以下列方式使用粗体样式：

频繁、连续、大面积地设置粗体；或
以粗体样式代替标题样式。

斜体¶

不应在任何情况下将中文设置为斜体。

非中文部分使用斜体样式，应遵循通行的风格规范。

段落¶

除非为实现表达效果另有需要，段落应长短适中，逻辑上自成一体；除非有充分理由，不应使用只有一句话的段落。

相邻段落之间应仅使用一个换行符隔开。

说明

段落对应的标准 HTML 元素是 <p>。少数派的样式会自动为相邻的 <p> 元素添加空隙，因此无需手动增加额外的空行。

请注意本规定适用于富文本形式，即在少数派编辑器中呈现的结果。在标准 Markdown 语法中，连续两个换行符方会创建一个新段落。

大小写¶

中文句子内夹用普通英文单词或词组，无论其位于中文句子的开头、中间还是末尾，首字母一律小写。但是，首字母必须大写的专名，该单词或词组应保留其首字母大写形式。

举例

paper 可以构成合成词，如 paperboard（纸板）、notepaper（便笺）等。

「长江」过去常译作 the Yangtze River。

项目列表和数字列表¶

项目列表和数字列表内部的各项宜长度相近、句式相似。

不应以下列方式使用项目列表或数字列表样式：

列举词语等过短的内容；
列举逻辑上没有并列或接续关系的内容；或
代替标题样式使用。

块引用¶

块引用样式内部的引文两端不加引号；引文内部再有引用的，中文首先使用单层直角引号，英文首先使用双引号。

不应仅出于任何强调、装饰目的而使用块引用样式。

链接¶

链接文本¶

添加超链接时，链接文本应能说明被链接资源的内容。具体而言：

如果被链接资源是具体的章节或词句，宜使用该等章节标题或词句原文作为链接文本；
如果该等内容不适宜直接作为链接文本，或没有可直接跳转的链接，宜在上下文中加入方便读者定位的描述。

链接部分结尾的逗号、句号等点号，不宜纳入链接文本，但整句作为链接文本的情况除外。链接部分系引文、书名、篇名时，两端的引号、书名号不宜纳入链接文本。

举例

Apple 有一篇题为《减少磁盘写入》的开发者文档，其中就建议尽量使用缓存创建临时文件，从而减少写入、优化性能。

以下内容不应作为链接文本：

用户行为：如「点击」「下载」「阅读」等；
指示代词：如「这里」「这篇」等；
链接地址，但根据上下文需要展示的除外；或
其他不能说明被链接资源的内容。

链接文本不应用于代替必要的注释、脚注和参考文献。

不应为链接文本与其前后文之间添加额外空格，但为满足中英文字符间留空要求而添加的除外。

链接地址¶

如遇下列情况，应避免使用原始链接地址，以列示的方法予以处理：

情形	举例	处理方式
短网址服务生成的，或其他在访问时会发生网址重定向的链接	`t.co`、`t.cn` 等	改用直接指向最终目标的链接
链接地址包含功能为广告分析、推广返利参数或其他对于定位资源无直接作用，且可能导致用户信息被收集的参数	以 `utm_`、`fb_`、`ga_` 开头的参数	从链接中移除该等参数，可以使用 URL Clean 等在线工具或 ClearURLs 等浏览器插件。
具有临时性质的、有较大可能失效或发生变动的链接	带有 `signature` 参数的微信公众号预览链接	应改用等效的固定链接（permalink），并补充使用 Internet Archive 服务或 PDF 格式等归档的版本。

被链接资源¶

如果链接文本所描述的人物、实体、作品有正式网站，链接应指向该正式网站。

如遇下列情况，应以列示的方法在链接文本后以括号形式提示和标注：

情形	处理方式	举例
被链接资源是独立的文件，可能需要额外的软件才能阅览	标注文件格式	1991 年 8 月 6 日，蒂姆·伯纳斯-李在 alt.hypertext 新闻组上发帖介绍了万维网项目（存档链接）。
被链接资源需要登录或付费才能阅读	标注「需登录」「需付费」，或「付费墙」等	《华尔街日报》刊发了一篇 Apple 硬件科技部门高级副总裁 Johny Srouji 的专访报道（需付费）。
被链接资源已经失效或内容可能已发生变化	提供使用 Internet Archive 服务或 PDF 格式等归档的版本，并标注「原始内容存档于 [ 日期 ]」

行内代码¶

下列内容应设置为行内代码样式：

终端命令的名称或简短片段；
软件包的名称；
文件名、扩展名和文件路径；
URL（如用于程序输入和输出）、IP 地址和端口，HTTP 协议的状态码、动词；
上下文讨论程序语言或标记语言时，句子中的属性、元素、类、数据类型、常量、变量、关键词、方法、函数、名称空间的名称及其值（如有）。

举例

使用 cd 切换到用户主目录，然后用 ls -a 显示全部文件的清单。

本项目依赖于 moment.js。

已知主机的列表位于 ~/.ssh/known_hosts。

使用 GET 方法访问 127.0.0.1:8080，返回 404。

不应将行内代码样式用于表示强调。

代码块¶

代码块的用途¶

下列内容应使用代码块样式：

为完成操作所需执行的命令；
脚本文件和配置文件的内容；
终端输出样例。

不应使用图片展示代码块。

代码块的格式¶

使用代码块样式，应选择正确的高亮语言。所使用的语言不在编辑器支持范围内的，应选择「文本」。

如果代码块中的语言有通行的风格规范，应从其规范。

代码块的内容¶

代码块应包含必要的注释，且应置于被注释的片段之前。使用注释应克制和精简，不应以注释代替正文中的解释。

代码块的执行结果应另起一个代码块来放置。

如果代码块很长，应予以适当删减，突出重要或相关的部分。如果有必要提供代码块的完整内容，应通过外部链接形式提供。

举例

配置该服务使用的 Dockerfile 如下所示（完整内容存放在 GitHub Gist 上）：

services:
frontend:
    image: awesome/webapp
    ports:
    - "443:8043"
    networks:
    - front-tier
    - back-tier
    ...
volumes:
db-data:
    driver: flocker
    driver_opts:
    size: "10GiB"
...

日期和时区¶

在完整的句子中，除非根据上下文另有需要，应使用汉字表达日期中的单位，且不使用前置零，即 yyyy 年 M 月 d 日 h 时 m 分 s 秒，不应使用横线、冒号、英文等。

如果提及国外发生事件的时间，应选择下列方式之一处理：

说明是「当地时间」，然后用括号标注对应的国内时间；或者
换算为国内时间，然后用括号标注对应的当地时间。

单位¶

文中提及单位时，应使用国际单位制。有必要使用非国际单位制时（例如因引用原文），宜在其后以括号加注换算为国际单位制下的对应数值。

阿拉伯数字与计量单位字母符号之间应添加一个半角空格。

说明

依最佳实践，数字与单位之间应使用无中断空格（U+00A0），以避免数字和单位在换行处被断开。由于无中断空格输入较为困难，一般仅要求使用普通半角空格代替。

货币¶

文中提及货币金额时，应使用「[数值] [中文货币单位名称]」的样式，但用于指界面上显示的金额或操作中的输入值除外。

举例

100 美元

$100、USD 100、100 刀

货币为外币时，宜在外币金额后以「（合人民币 [换算金额] 元）」的样式，注明按写作时公开汇率换算的人民币金额。

描述用户界面¶

按键¶

提及单个按键¶

按键名称应当只大写第一个字母（sentence case）；除非会与上下文混淆，宜省略「键」字。

除方向键、空格键、菜单键外，按键名称不应翻译为中文。

如果提及特殊符号按键，应采用「[符号名称] ([符号])」体例，即将符号夹注在半角括号内，在符号名称后一并列出。

举例

右箭头
逗号 (,)
Page up

提及键盘组合键¶

组合键的各按键之间应以加号（+）或连字符（-）连接，内部可以不额外添加空格。

说明

Windows 和 Linux 正式文档中常用加号连接，macOS 正式文档中常用连字符连接；实践中，连接符号与按键之间有无空格均为常见用法。作者可依偏好任选，惟应保持前后一致。

如果组合键中的修饰键包含 Shift，且非修饰键印有超过一个符号，应以印在高位的符号称呼该键。但所描述软件对该组合键的描述另有惯例的，从其惯例。

举例

在 Word 中，按 Ctrl+Shift+星号 (*) 可以显示隐藏字符。

（因为修饰键包含 Shift，非修饰键记作印在高位的星号 (*) 而非印在低位的 8。）

在 macOS 中，按 Shift-Command-3 可以截取全屏幕。

（尽管修饰键包含 Shift，但依 macOS 平台惯例，非修饰键中的数字键通常始终以数字称呼，以便记忆。）

提及修饰键¶

组合键中，修饰键的名称及出现顺序应遵循所描述软件的惯例。特别地：

Windows 中，修饰键名称及出现顺序一般为 Win、Ctrl、Alt、Shift；
macOS 中，修饰键名称及出现顺序一般为 Ctrl、Option、Shift、Cmd；

不应使用 Ctl、Opt、Cmd 等缩写提及修饰键，或使用修饰键符号代替提及修饰键名称，以免读者因不熟悉产生困惑，或无法正常显示。

按键名称不应设置为粗体样式，但可以设置为行内代码样式。

说明

描述键盘输入的标准 HTML 元素为 <kbd>。

由于少数派目前未对 <kbd> 标签提供专门样式和功能支持，我们允许使用行内代码样式作为替代。

例外情况¶

文章描述的软件对按键、组合键的名称、样式和格式另有惯例的，从其惯例。

举例

在 Emacs 中，按 C-x C-s 将缓冲区保存到文件。

安装 Vim 文件浏览插件 NERDTree 后，按 <leader> n 即可在侧边窗口中显示。

界面元素¶

除非容易产生混淆，宜在描述界面元素时省略其类型名称，直接以文本标签称呼。

举例

打开「系统偏好设置」，选择「声音」，然后选择「输入」。

打开「系统偏好设置」，点击「声音」按钮，然后切换到「输入」面板。

说明

一些界面元素的名称较为生涩；近年一些设计范式中，界面元素的类型亦难以凭外观识别（例如无边框按钮与链接）。因此，在描述时提及可能引起非专业读者的困惑。

确需保留界面元素类型名称时，应注意遵循各平台或 UI 框架的惯例。

界面元素应与恰当的动词搭配，并考虑不同输入方式和不同人群中的通用性。特别地：

描述桌面端界面元素，宜使用下列动词之一：点击或单击（click）、双击（double-click）、右键单击（right-click；macOS 称「辅助点按」，Control-click）、拖动和拖放（drag and drop）、按住（press）和滚动（scroll）；
描述移动端界面元素，宜使用下列动词之一：轻点或轻按（tap）、按住（tap and hold）、用力点按（适用于 Apple 妙控板，force click）、轻扫（swipe）、滚动（scroll）、张开和捏合（pinch）；
描述跨平台软件的界面元素，宜用「选择」（select）代替「点击」「单击」「轻点」或「轻按」。

操作步骤¶

描述具体操作步骤之前，宜首先介绍该系列步骤要达成的目的。

举例

刷新页面。

点击「刷新」按钮。

描述一组连续操作时，宜使用额外的样式或符号（如粗体或引号）突出界面元素的名称，并使用大于号（ >）或连接号（–）来连接各步骤界面元素。

举例

「第一步」>「第二步」；或 第一步 > 第二步

「第一步 > 第二步」

如果操作步骤中涉及界面内容切换，应以切换时点为界拆分步骤描述。

举例

选择「Apple 菜单」>「系统偏好设置」，点击「通用」，然后从窗口顶部的「外观选项」中选择「深色模式」。

终端环境¶

文中提及终端环境下的操作时，宜同时提及如下相关信息：

所使用命令行程序的主要功能和用法，以及所使用各个选项或参数的含义；
所提供命令的潜在风险及其避免方式（如果有）；以及
所提供命令的撤销方法（如果有）。

提及终端命令时，命令开头不应添加提示符 $ 或 >。

参阅

要检查文章中终端脚本或命令的语法问题，可以使用 ShellCheck。该工具同时也会检查命令误用、类型错误、平台通用性等常见问题。

要快速查阅一条命令各个部分的含义及相关手册页面，可以使用 explainshell。

待定内容¶

如果文中出现待定内容，宜将待定内容的描述语放在一对半角方括号之间。

举例

文中第一次出现中文译名，可以使用「[中文译名]（[原名] [其他常见译名（如有）]）的格式。

特殊地，如果待定内容是代码和命令中的占位符，宜按下列方式处理：

将待定内容的描述语设置为行内代码样式；
如果待定内容是选填的，放置在一对半角方括号之间；如果待定内容是必填的，不使用方括号；
描述语宜用简明的英文，需要包含多个单词的，以下划线 _ 代替单词之间的空格。

但是，如果描述的软件或语言对于表示待定内容另有惯例，从其惯例。

举例

统一资源定位符的标准格式是 [协议类型]://[服务器地址]:[端口号]/[资源层级UNIX文件路径][文件名]?[查询]#[片段ID]。

grep 命令可以从外部文件读取匹配内容，语法为 grep [OPTION...] -f PATTERN_FILE ... [FILE...]，其中 PATTERN_FILE 为存放匹配规则的外部文件路径。

虚构内容¶

虚构人名、用户名、公司等组织的名称时，除非有合理理由，应避免与现实中知名的人或实体相同或相似，且应避免隐含的假定或偏见。

虚构普通文本内容时，宜使用与文章主题契合且不包含真实信息的素材；不容易找到合适素材的，可以使用 Lorem ipsum 等随机生成的文本。

说明

可以使用以下工具帮助生成随机文本：

Lipsum generator（英文）
乱数假文生成器（繁体中文，需自行转为简体）

虚构 IP 地址时，宜使用以下地址段之一：192.0.2.0/24、198.51.100.0/24 和 203.0.113.0/24。

虚构域名时，宜使用 example.com 及其子域名。

参阅

要了解关于虚构 IP 地址和域名的细节规范，参阅 RFC6890 (Special-Purpose IP Address Registries) 和 RFC 6761 (Special-Use Domain Names)。

图片¶

图片的一般要求¶

文中插入图片，应遵循有节制、图文对应的原则。

使用他人图片，或在图片中使用来自他人的素材，应尊重版权并标注来源。

图片中的文本标注应使用具有适当授权的字体。

说明

一般而言，操作系统内置的字体允许用于制作图片用途，例如参见 Font redistribution FAQ for Windows，Software License Agreement for macOS Monterey (§ 2E)。一个例外是 Apple 的系统默认字体 San Francisco，其授权要求仅限开发者用于创建 Apple 平台软件的演示图片。

我们建议使用开放许可证或者明确可免费商用的字体来标注截图。这类字体可以从 Google Fonts（西文字体为主）、猫啃网（中文字体为主）等站点下载。

尺寸和形态¶

选择图片尺寸和压缩比，应兼顾平衡清晰度和文件体积。

纵向像素多于横向像素的图片，宜采用下列方式之一做额外处理：

裁剪图片或添加背景色，使其纵向像素不多于横向像素；
使用少数派编辑器的拼图功能，使组合后的纵向像素不多于横向像素；
使用少数派编辑器的缩放功能，将图片占用的纵向空间控制在合理、美观范围内。

说明

少数派编辑器有 2MB 的图片尺寸限制。要压缩图片体积，可以选择 TinyPNG、PP 鸭等工具；有技术能力的作者也可以选择 imagemagick（参考）、optipng 等命令行工具。

图片标注¶

为图片添加标注，包括但不限于文本、图形、遮罩、设备边框，应遵循有节制的原则。添加的标注应尺寸适宜、风格一致。

图片中的个人信息、敏感信息等部分应予以遮挡。除非为实现表达效果另有需要，遮挡部分宜使用尺寸适当、边缘规则纯色色块，不宜使用马赛克、模糊效果，不应使用表情符号、装饰性图片。

说明

多项安全研究表明，马赛克、模糊等图片效果是可逆的（可逆程度取决于算法、清晰度等），因此不适合用作遮挡信息的方式。

题注文本¶

文章插入图片，宜同时填写题注文本。

除引注来源外，不应通过题注文本表达正文中未包含的信息。

动态图片¶

除非为实现文章目的所必需，宜避免使用动态图片。

说明

GIF 格式动图在实践中标准较为混乱，不同软件所创建的 GIF 效果差异巨大；体积过大的动图对于服务器和用户网络都是负担。此外，过多动态元素也会对读者构成干扰。因此，我们要求只在静态图片不足以传达信息的情况下使用 GIF 图片。

题图¶

文章宜有题图。题图的标准尺寸为：

普通样式：1420 × 708 像素，关键内容应放置在中央 708 × 708 像素的区域；
醒目样式：708 × 708 像素，关键内容应放置在中央 615 × 615 像素的区域；该区域内的内容会在用户鼠标指向时放大占据整个 708 × 708 像素的区域。

说明

少数派首页发布的文章均配有题图（题图）。尽管我们鼓励作者自行提供题图，题图的有无及质量并不作为评审文章的标准。如果我们计划将你的文章在首页展示，会在届时为你补充配图或协商调整。你也可以下载题图的 Figma 模板以便制作。

附录¶

常用技术领域风格指南¶

常见科技类名词列表¶

正式名称（英）	正式名称（中）	可接受用法	避免使用	附注
Adobe	奥多比	无	无	官方大中华部门偶用「奥多比」，但一般使用中过于少见，不建议使用
Amazon	亚马逊	无	amazon、亚麻	无
AMD	超微 [半导体]	无	按摩店、A 厂、红厂	官方中文名在一般交流中罕见，建议使用英文原文
Android	无	安卓	无	无官方中文名，因「安卓」在中文讨论中过于常见，可以接受，但应尽量使用英文名；指代第三方厂商基于 AOSP 二次开发的系统时，保留其官方名称中的「OS」「UI」等后缀，但不要单独以该等后缀称呼
app	应用	[移动] [互联网] 应用 [程序]	App、APP	不要使用任何大写；主要指给智能手机、平板电脑等移动设备运行的应用程序，但近年也普遍用于指桌面端、网页端应用，特别是其中直接面向最终用户的应用程序
Apple	无	苹果	水果、苹果标志（，U+F8FF）	中国境内注册的主体多使用「苹果」商号，但官方中文对外宣传中仍使用 Apple；称呼其产品时，注意遵守官方的大小写和空格规则
GitHub	无	无	Github、Gayhub	注意 H 为大写
Google	谷歌	无	无	在中国运营期间偶用过「谷歌」，但目前产品名称和对外沟通中全部使用英文原文；由于中文名在一般交流中非常常见，可以接受；只在明确需指代其母公司时使用 Alphabet（无官方中文名）
LinkedIn	领英	无	无	无
Meta（原 Facebook）	无	脸书	脸谱网、fb	「脸书」并非官方中文名称，但在中国官方媒体报道和一般讨论中常用，可以采纳；应在指代运营主体时，使用新名称 Meta 并注明「（原 Facebook）」；指代社交平台产品时，仍然使用 Facebook
Microsoft	微软	无	巨硬	官方宣传中多使用英文原名，但产品名称和一般讨论中「微软」极为常见
Netflix	无	网飞、奈飞	NETFLIX	全大写 NETFLIX 仅在商标中使用，对外宣传中仍使用首字母大写的形式；无官方中文名，但「网飞」为一般讨论中常用，且为该公司在台湾主体注册的商号，「奈飞」曾在部分中国官方媒体报道中使用，均具有一定认知度，但仍应尽量使用英文原名
Nintendo	任天堂	无	老任	无
NVIDIA	英伟达	无	N 厂	官方对外宣传中使用全大写，应以此为准
Sony	索尼	无	大法	全大写的 SONY 为其商号中使用，官方文件和一般交流仍以首字母大写形式居多
tablet	平板电脑	平板	pad、PAD	无
Tesla	特斯拉	无	无	无
Twitter	推特	无	无	「推特」因曾被官方中文账号使用而可采纳；用户在该平台上发表的更新称「推文（tweet）」