少数派风格指南

导言#

范围#

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

2. 本文档适用于——

   1. 在少数派发表的科技或技术主题作品；
   2. 在少数派首页展示的作品；
   3. 由少数派发布的文档和公告；及
   4. 需要付费阅览的作品。

3. 其他版块或其他主题的作品，在可行范围内参照适用本指南。

表示效力的字词#

在本指南中——

1. 应或不应指——

   1. 其后接的要求是规范性的，须在各种情况下被遵守；
   2. 投稿作品符合该等要求的情况将很大程度上影响编辑部的处理决定；及
   3. 如作品获首页展示，将受到修订以满足该等要求。

2. 宜指——

   1. 其后接的要求是推荐性的，如无充分理由采取相反行动，须被采纳；
   2. 投稿作品符合该等要求的情况将在一定程度上影响编辑部的处理决定；及
   3. 如作品获首页展示，将在考虑作者意见的基础上，受到修订以满足该等要求。

3. 可以指——

   1. 其后接的要求是选择性的，作者须在予以充分考虑的基础上决定采纳或不采纳；及
   2. 投稿作品符合该等要求的情况一般不会影响编辑部的处理决定。

未尽事宜的处理#

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

用词和措辞#

规范文字#

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

参阅

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

得体语言#

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

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

专有名词#

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

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

2. 非中文专有名词或术语的处理方式如下——

   1. 如存在正式或通用的中文译名，优先使用该译名；

   2. 如中文译名不够为人所知或存在多种版本，在第一次出现的位置按以下体例标注——

      中文译名（Original Term，另译为…（如有））

参阅

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

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

缩略语和缩写#

除非一个缩略语或缩写已经广为人知且被广泛使用，其在文中第一次出现时，应——

1. 在其后以括号加注全称；及
2. 为非中文缩写注明中文译文。

引用内容#

引用的一般要求#

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

2. 应避免长篇或全文引用。引文内容对于文章论述具有重要作用的，应——

   1. 在文中引用关键部分；
   2. 提供引文概述；及
   3. 提供指向引文全文的链接。

标注来源#

1. 引用观点、数据或材料，应注明来源。

2. 标注来源时，可以根据文章主题、风格、引用材料的性质，以及对读者的影响程度等因素，选择——

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

3. 可以自行选择适当的引注格式，但应在可行范围内采用最规范的标准。

参阅

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

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

受版权保护的材料#

1. 在文中引用他人创作的图片、视频或音频等受著作权保护的多媒体材料，应在题注、后续段落等紧邻的位置注明——

   1. 权利人的姓名或名称；
   2. 作品名称；及
   3. 获权利人授权的事实（如有）。

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

引用非中文内容#

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

2. 译文应遵循中文文法和惯用表达。为此，应对句式结构和具体用词作灵活调整。

参阅

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

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

1. 引用翻译内容可以不包含原文，但下列情况除外——

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

标点符号#

中英文字符间的空格#

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

说明

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

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

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

标点符号的形态#

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

说明

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

要输入中文直角引号——

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

参阅

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

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

1. 中文句内夹用英文句子时——

   1. 该句子应用中文标点结尾；
   2. 夹用的英文句子应用中文引号标示；
   3. 英文句子内部应用英文标点符号，除此以外应用中文标点符号；及
   4. 英文引文中的问号和叹号应予保留。

2. 在中文技术名词后标注英文名称时——

   1. 英文全称及其缩略形式应置于中文括号内，并以英文逗号分隔；及
   2. 英文原文自带逗号，应以英文分号分隔。

3. 中文句子内夹用英文名称时——

   1. 英文书籍名或报刊名不应使用中文书名号，而应以英文斜体表示；及
   2. 英文文章标题应使用英文正体字，并以中文引号标示。

举例

歌词中那句「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）。

避免滥用标点符号#

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

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

文本样式#

标题#

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

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

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

粗体#

1. 粗体部分结尾的逗号、句号等点号不宜设为粗体，但整句设为粗体的除外。

2. 粗体部分包含引文、书名或篇名时，两端的引号或书名号应一并设为粗体。

3. 不应以下列方式使用粗体样式——

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

斜体#

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

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

段落#

1. 除非为实现表达效果另有需要，段落应长短适中，并在逻辑上自成一体。

2. 除非有充分理由，不应使用只有一句话的段落。

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

说明

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

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

大小写#

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

举例

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

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

项目列表和数字列表#

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

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

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

块引用#

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

2. 不应仅出于强调或装饰目的而使用块引用样式。

链接文本#

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

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

2. 链接部分结尾的逗号、句号等点号，不宜纳入链接文本，但整句作为链接文本的情况除外。

3. 链接部分是引文、书名或篇名时，两端的引号或书名号不宜纳入链接文本。

举例

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

4. 以下内容不应作为链接文本——

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

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

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

链接地址#

如遇下列情况，应避免使用原始链接地址，并按表中列示的方法处理——

被链接资源#

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

2. 如遇下列情况，应按表中列示的方法，在链接文本后以括号形式提示和标注——

行内代码#

1. 下列内容应设置为行内代码样式——

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

举例

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

本项目依赖于 moment.js。

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

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

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

代码块的用途#

1. 下列内容应使用代码块样式——

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

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

代码块的格式#

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

2. 如果代码块中的语言有通行的风格规范，应遵循该规范。

代码块的内容#

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

2. 代码块的执行结果应另置于一个代码块中。

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

举例

配置该服务使用的 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"

日期和时区#

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

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

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

单位#

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

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

说明

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

货币#

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

举例

✓ 100 美元

✗ $100、USD 100、100 刀

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

描述用户界面#

提及单个按键#

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

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

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

举例

1. 右箭头
2. 逗号 (,)
3. Page up

提及键盘组合键#

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

说明

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

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

举例

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

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

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

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

提及修饰键#

1. 组合键中，修饰键的名称及出现顺序应遵循所描述软件的惯例，特别是——

   1. Windows 中，修饰键名称及出现顺序一般为 Windows、Ctrl、Alt、Shift；及
   2. macOS 中，修饰键名称及出现顺序一般为 Control、Option、Shift、Command。

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

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

说明

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

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

按键名称和格式的例外#

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

举例

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

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

界面元素#

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

举例

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

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

说明

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

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

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

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

操作步骤#

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

举例

✓ 刷新页面。

✗ 点击「刷新」按钮。

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

举例

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

✗ 「第一步 > 第二步」

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

举例

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

终端环境#

1. 文中提及终端环境下的操作时，宜同时提及下列相关信息——

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

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

参阅

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

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

待定内容#

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

举例

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

2. 如果待定内容是代码或命令中的占位符，宜按下列方式处理——

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

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

举例

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

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

虚构内容#

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

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

说明

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

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

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

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

参阅

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

图片#

图片的一般要求#

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

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

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

说明

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

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

尺寸和形态#

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

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

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

说明

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

图片标注#

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

2. 图片中的个人信息或敏感信息等部分应予以遮挡。

3. 除非为实现表达效果另有需要，遮挡部分——

   1. 宜使用尺寸适当、边缘规则的纯色色块；
   2. 不宜使用马赛克或模糊效果；及
   3. 不应使用表情符号或装饰性图片。

说明

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

题注文本#

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

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

动态图片#

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

说明

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

题图#

1. 文章宜有题图。

2. 题图的标准尺寸为——

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

说明

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

附录#

常用技术领域风格指南#

• Apple Style Guide
• Google Developer Documentation Style Guide
• Microsoft Style Guide
• Red Hat Technical Writing Style Guide

常见科技类名词列表#