中文文案排版指北：一套可落地执行的中英文混排、空格与标点规范指南

• 文档
• 教程

统一中文文案、排版的相关用法，降低团队成员之间的沟通成本，增强网站气质。

这篇技术指南围绕当前仓库中的《中文文案排版指北》（README.md）展开，系统梳理中英文混排时必须遵守的空格、标点、全角半角与名词大小写规范，并给出完整正误示例对照。读者阅读完成后，将掌握一套可以直接应用于产品文案、技术文档、官网与社区 UGC 场景的排版检查清单，同时了解如何借助仓库内的工程化配置（Markdown lint、Crowdin 多语言维护）把规范固化到日常写作流程中。

项目是什么

chinese-copywriting-guidelines 是一份以 Markdown 文档形式维护的中文文案排版规范仓库，目标是把「统一中文文案、排版的相关用法」这一抽象要求，拆解成一条条可判定的具体规则。它既面向个人写作者，也面向需要团队协作、多人共同产出内容的网站与产品团队，其价值在于：

• 降低沟通成本：团队内不再为「这里要不要加空格」「这里用全角还是半角」反复争论，直接以规则为准；
• 增强网站气质：一致的排版让页面观感更专业、可读性更强；
• 规则可机器校验：文档末尾附有 pangu、autocorrect 等工具生态，规则可以转化为自动化的格式化与 lint 流程。

仓库采用 MIT 协议（见 LICENSE），并通过 crowdin.yml 配置了多语言翻译工作流，将 README.md 作为源文件，同步产出 英文版 与 简体中文版 等多个语言版本。

空格：中英文混排的第一道门槛

「有研究显示，打字的时候不喜欢在中文和英文之间加空格的人，感情路都走得很辛苦，有七成的比例会在 34 岁的时候跟自己不爱的人结婚，而其余三成的人最后只能把遗产留给自己的猫。毕竟爱情跟书写都需要适时地留白。

与大家共勉之。」——vinta/paranoid-auto-spacing

这段引文出自 pangu 工具的作者，意在用调侃的方式说明：中英文之间适时留白，是排版美感的基础。规则全集如下。

中英文之间需要增加空格

正确：

在 LeanCloud 上，数据存储是围绕AVObject进行的。

错误：

在LeanCloud上，数据存储是围绕AVObject进行的。

在 LeanCloud上，数据存储是围绕AVObject进行的。

注意第二种错误：只在一侧加空格也是不合格的，空格必须同时出现在中英文交界的两侧。

完整的正确用法（一个自然段内连续命中多处交界的情况）：

在 LeanCloud 上，数据存储是围绕AVObject进行的。每个AVObject都包含了与 JSON 兼容的 key-value 对应的数据。数据是 schema-free 的，你不需要在每个AVObject上提前指定存在哪些键，只要直接设定对应的 key-value 即可。

例外：「豆瓣FM」等产品名词，按照官方所定义的格式书写，不要机械地在「豆瓣」与「FM」之间强加空格。

中文与数字之间需要增加空格

正确：

今天出去买菜花了 5000 元。

错误：

今天出去买菜花了 5000元。

今天出去买菜花了5000元。

数字与单位之间需要增加空格

正确：

我家的光纤入屋宽带有 10 Gbps，SSD 一共有 20 TB。

错误：

我家的光纤入屋宽带有 10Gbps，SSD 一共有 20TB。

例外：度数与百分比与数字之间不需要空格：

正确：

角度为 90° 的角，就是直角。

新 MacBook Pro 有 15% 的 CPU 性能提升。

错误：

角度为 90 ° 的角，就是直角。

新 MacBook Pro 有 15 % 的 CPU 性能提升。

规律可以这样记忆：凡是「计量单位」这类独立成词的符号（Gbps、TB、kg、km），数字与单位之间要留空格；凡是「紧贴数字的符号」这类度数（°）、百分号（%）等按排版惯例与数字连写的，不加空格。

全角标点与其他字符之间不加空格

正确：

刚刚买了一部 iPhone，好开心！

错误：

刚刚买了一部 iPhone ，好开心！

刚刚买了一部 iPhone， 好开心！

中文的全角标点（逗号、句号、感叹号等）应当紧贴前一个字符，后面也不需要额外补空格，因为全角字符本身已占据足够宽度。

用text-spacing来挽救？

CSS Text Module Level 4 的text-spacing和 Microsoft 的-ms-text-autospace可以在 CSS 层面自动为中英文之间增加空白。但该规范目前并未普及，而且在 macOS、iOS、Windows 等非 Web 应用的用户界面中并不存在这个特性。因此结论是：不要把自动化排版寄托在浏览器特性上，请继续保持随手加空格的习惯。

从 CHANGELOG.md 可以看到，这条关于text-spacing的提示是在 0.0.10 版本（2018-10-14）时补充进文档的，属于对「中英文之间加空格」主规则的现实性补充说明。

标点符号：不重复使用标点符号

虽然中国大陆的标点符号用法允许重复使用标点符号，但是这么做会破坏句子的美观性。

正确：

德国队竟然战胜了巴西队！

她竟然对你说「喵」？！

错误：

德国队竟然战胜了巴西队！！

德国队竟然战胜了巴西队！！！！！！！！

她竟然对你说「喵」？？！！

她竟然对你说「喵」？！？！？？！！

「感叹号 + 问号」组合（即 interrobang 式用法）表达强烈疑问即可，连续堆叠感叹号或问号属于排版失控。文档中给出的「？」+「！」连写是允许的，但「？！？！？？！！」这类重复堆叠则明确禁止。

全角和半角：字符宽度的选择

如果不熟悉全角（全形）与半角（半形）符号的概念，可参考维基百科「全形和半形」条目。规则层面，文档给出三条。

使用全角中文标点

正确：

嗨！你知道嘛？今天前台的小妹跟我说「喵」了哎！

核磁共振成像（NMRI）是什么原理都不知道？JFGI！

错误：

嗨! 你知道嘛? 今天前台的小妹跟我说 "喵" 了哎!

嗨!你知道嘛?今天前台的小妹跟我说"喵"了哎!

核磁共振成像 (NMRI) 是什么原理都不知道? JFGI!

核磁共振成像(NMRI)是什么原理都不知道?JFGI!

中文句子内部的感叹号、问号、括号、引号必须使用全角形式。错误示例展示了三种常见翻车方式：使用半角标点（!、?、"）、半角括号前后加空格、以及全角括号缺失。

例外：中文句子内夹有英文书籍名、报刊名时，不应借用中文书名号，应以英文斜体表示。

数字使用半角字符

正确：

这个蛋糕只卖 1000 元。

错误：

这个蛋糕只卖 １０００ 元。

例外：在设计稿、宣传海报中如出现极少量数字的情形时，为方便文字对齐，可以使用全角数字。

遇到完整的英文整句、特殊名词，其内容使用半角标点

正确：

乔布斯那句话是怎么说的？「Stay hungry, stay foolish.」

推荐你阅读Hackers & Painters: Big Ideas from the Computer Age，非常地有趣。

错误：

乔布斯那句话是怎么说的？「Stay hungry，stay foolish。」

推荐你阅读《Hackers＆Painters：Big Ideas from the Computer Age》，非常的有趣。

规则边界很清晰：中文语境使用全角标点，英文整句与英文书名使用半角标点。英文引文内部不能混入中文逗号、句号；英文书名用斜体而非中文书名号，同时&、:等符号也保持半角。

名词：大小写与缩写

专有名词使用正确的大小写

大小写相关用法原属于英文书写范畴，不属于本 wiki 讨论内容，这里只对部分易错用法进行简述。

正确：

使用 GitHub 登录

我们的客户有 GitHub、Foursquare、Microsoft Corporation、Google、Facebook, Inc.。

错误：

使用 github 登录

使用 GITHUB 登录

使用 Github 登录

使用 gitHub 登录

使用 gｲんĤЦ8 登录

我们的客户有 github、foursquare、microsoft corporation、google、facebook, inc.。

我们的客户有 GITHUB、FOURSQUARE、MICROSOFT CORPORATION、GOOGLE、FACEBOOK, INC.。

我们的客户有 Github、FourSquare、MicroSoft Corporation、Google、FaceBook, Inc.。

我们的客户有 gitHub、fourSquare、microSoft Corporation、google、faceBook, Inc.。

我们的客户有 gｲんĤЦ8、ｷouЯƧquﾑгє、๓เςг๏ร๏Ŧt ς๏гק๏гคtเ๏ภn、900913、ƒ4ᄃëв๏๏к, IПᄃ.。

错误示例覆盖了四类典型问题：全小写、全大写、大小写混排错乱（Github、gitHub、MicroSoft），以及用同形异义字符（homoglyph）伪装的品牌名。最后一条是在提醒：不要用字符替换玩花样，品牌名应始终以官方标准形式书写。

注意：当网页中需要配合整体视觉风格而出现全部大写／小写的情形时，HTML 中请使用标准的大小写规范进行书写，并通过text-transform: uppercase;／text-transform: lowercase;对表现层进行定义。也就是说，源文本永远保持标准大小写，视觉效果交给 CSS——这与「语义与表现分离」的前端最佳实践一致。

不要使用不地道的缩写

正确：

我们需要一位熟悉 TypeScript、HTML5，至少理解一种框架（如 React、Next.js）的前端开发者。

错误：

我们需要一位熟悉 Ts、h5，至少理解一种框架（如 RJS、nextjs）的 FED。

缩写要「地道」：TypeScript 不要写成 Ts，HTML5 不要写成 h5，React 不要写成 RJS，Next.js 不要写成 nextjs，前端开发者不要用 FED 这类圈内黑话替代。从 CHANGELOG.md 看，这条规则自 0.0.5 版本（2015-07-08）起就以「avoid unidiomatic jargons」的形式进入文档，且文档维护过程中曾专门做过「avoid slangs」（0.0.8）与「avoid personal writing style」（0.0.4）等措辞修正，可见这类示例一直在持续打磨。

争议：带有个人色彩、但从语法上都正确

以下用法略带有个人色彩，即：无论是否遵循下述规则，从语法的角度来讲都是正确的。是否采纳取决于团队审美。

链接之间增加空格

用法（推荐）：

请 提交一个 issue 并分配给相关同事。

访问我们网站的最新动态，请 点击这里 进行订阅！

对比用法：

请提交一个 issue并分配给相关同事。

访问我们网站的最新动态，请点击这里进行订阅！

在 Markdown / HTML 中，[链接文字]与前后中文之间是否加空格不影响渲染，但文档倾向在链接两侧保留空格，使中文与可点击文字之间有视觉喘息。

简体中文使用直角引号

用法（推荐）：

「老师，『有条不紊』的『紊』是什么意思？」

对比用法：

“老师，‘有条不紊’的‘紊’是什么意思？”

简体中文惯用弯引号（“ ” ‘ ’），但文档建议在简体中文中也采用直角引号（「」『』），层次嵌套更清晰（外层「」，内层『』），视觉上与繁体语境也一致。需要说明的是，README.md 本身为繁体中文版本，其「简体中文使用直角引号」条目是面向简体写作场景的建议；简体中文版的对应内容见 README.zh-Hans.md。

工具生态：把规则变成自动化

规范最终要落到执行。文档末尾整理了当前社区中可用于中文文案排版校验与格式化的工具（以下为完整清单，链接信息源自 README.md 工具章节）：

| 仓库 | 系列 | 语言 | | --- | -- | --- | | pangu.js | pangu | JavaScript | | pangu-go | pangu | Go | | pangu.java | pangu | Java | | pangu.py | pangu | Python | | pangu.rb | pangu | Ruby | | pangu.php | pangu | PHP | | pangu.vim | pangu | Vim | | vue-pangu | pangu | Vue.js (Web Converter) | | intellij-pangu | pangu | Intellij Platform Plugin | | autocorrect | autocorrect | Rust, WASM, CLI tool | | autocorrect-node | autocorrect | Node.js | | autocorrect-py | autocorrect | Python | | autocorrect-rb | autocorrect | Ruby | | autocorrect-java | autocorrect | Java | | autocorrect-go | autocorrect | Go | | autocorrect-php | autocorrect | PHP | | autocorrect-vscode | autocorrect | VS Code Extension | | autocorrect-idea-plugin | autocorrect | Intellij Platform Plugin | | jxlwqq/chinese-typesetting | other | PHP | | sparanoid/space-lover | other | PHP (WordPress) | | sparanoid/grunt-auto-spacing | other | Node.js (Grunt) | | hjiang/scripts/add-space-between-latin-and-cjk | other | Python | | hustcc/hint | other | Python | | n0vad3v/Tekorrect | other | Python |

两大系列的分工可以这样理解：

• pangu 系列：以「自动在 CJK 与字母/数字之间插入空格」为核心，适合在发布管线中批量格式化文本，覆盖 JavaScript、Go、Java、Python、Ruby、PHP、Vim、Vue.js 与 IntelliJ 平台；
• autocorrect 系列：功能更全面的中文文案格式化与 lint 工具，提供 Rust/WASM/CLI、Node.js、Python、Ruby、Java、Go、PHP 以及 VS Code、IntelliJ 插件形态，可以像 ESLint 一样嵌入编辑器与 CI；
• other 系列：包含 WordPress 插件（space-lover）、Grunt 构建任务（grunt-auto-spacing）、Python 脚本（add-space-between-latin-and-cjk、hint、Tekorrect）等场景化工具。

选择策略建议：单文件快速处理用 pangu 系列；需要工程化集成、支持 lint 报告时优先 autocorrect；静态博客或传统 CMS 环境可考虑 other 系列。

工程化保障：这份文档仓库自身怎么保证排版正确

该仓库不仅「教」别人排版，自身也配置了排版质量检查，值得借鉴：

• Markdown 风格 lint：在 package.json 中，npm test执行的是remark .，即用 remark-cli 对全部 Markdown 文件做 lint；配置了remark-preset-lint-consistent、remark-preset-lint-recommended以及remark-lint-list-item-indent（列表项缩进统一为空格）等插件。这意味着 README 本身的书写风格（如列表缩进、格式一致性）也是受 CI 约束的——文档发布前会先通过 lint 才能合入；
• 多语言维护：根目录的 crowdin.yml 声明了source: /README.md、translation: /README.%locale%.md的翻译映射，配合 README 顶部的语言切换链接（英文、繁体、简体），说明规范在持续进行社区化翻译，多语言版本同步演进；
• 依赖与版本治理：仓库通过 renovate.json 自动跟踪依赖更新；CHANGELOG.md 记录了从 0.0.1（2014-07-01）至今的每次规则增删与措辞修订，例如 0.0.2 新增数字全角/半角用法、0.0.3 简化规则与章节顺序调整、0.0.4 补充度数与百分比空格用法、0.0.8 新增「链接前后空格」规则、0.0.10 新增text-spacing提示与更多反面示例。

这套「文档即代码」的治理方式，与文档正文提倡的排版规范形成了呼应：规范本身也应当是经过 lint、可维护、可翻译的。

谁在这样做：业界实践参考

文档列出了一些在产品文案（Copywriting）或用户生成内容（UGC）上落实此类排版规范的网站（链接信息源自 README.md 对应章节）：

可以看到，Apple 与 Microsoft 的官方中文站、LeanCloud、少数派等以「官方文案」为主要内容的站点严格执行排版规范；而 V2EX、Ruby China 这类社区站点连用户生成内容也纳入了排版约束。如果你的产品同时有官方文案与用户评论两种内容形态，这份表格提供了很好的分级参考：文案必须严格，UGC 尽力引导。

参考文献

文档引用的外部参考资料包括：ThoughtCo. 的英语大写规则指南、Wikipedia 的 Letter case 与全角半形条目、Oxford Dictionaries 与 Purdue OWL 的标点指南、wikiHow 的英文标点使用教程、openSUSE 的格式规范、维基百科的引号与疑问惊叹号条目等，可用于进一步核对规则背后的语言学依据（完整条目见 README.md 参考文献章节，英文版见 README.en.md）。

落地建议：如何在团队中推行

结合全文规则，给出一个可执行的落地顺序：

1. 先把规则文档讲给团队：以 README.md 为基线，团队内对齐「空格、标点、全角半角、名词大小写」四类规则，有分歧的条目（链接空格、直角引号）按「争议」章节的精神讨论后定稿；
2. 接入自动化工具：根据技术栈选择 autocorrect 或 pangu 系列，接入编辑器和 CI，让机器先过一遍硬规则，人工只处理例外（如产品名词、设计稿中对齐需求）；
3. 用真实文案做对照检查：用文档中的「正确/错误」示例改造自己产品的存量文案，形成团队内部的正反例集；
4. 文档本身也纳入规范治理：借鉴本仓库的做法，给文案文档配置 lint 与版本管理，让规范随产品迭代持续演进。

• 文档
• 教程