你写的中文为什么显得业余，多半差的是一个空格

上周帮一个朋友改技术文档。内容挺扎实的，架构图画得也清楚，但读起来就是不对劲。我盯着屏幕看了两分钟才反应过来，是排版。

满屏的 在LeanCloud上部署、花了5000元、10Gbps带宽，中文、英文、数字挤成一团。单看都是小事，连起来读就是一股粗糙感，像一件版型不错的西装，袖口上留着线头。

内容的质感，经常就是被这种细节拖垮的。

同一句话，排版前后放在一起看，差别一目了然。

左边的毛病没有一个是内容问题，全是空格和标点的事。右边没多一个字，读起来就是舒服。

今天拆的这个仓库，就是专门治这个病的。sparanoid 的 chinese-copywriting-guidelines，中文名叫「中文文案排版指北」，15.7k star，1.8k fork，从 2014 年 3 月活到现在，是中文排版领域引用率最高的一份规范，没有之一。

一份没有代码的仓库

说它是个项目，其实有点心虚。整个仓库 408 KB，翻遍所有文件，找不到一行逻辑代码。三个 README（繁体、简体、英文）、一坨配置文件、一份 CHANGELOG，就没了。

一份 11k 字符的 Markdown 文档，凭什么拿 15.7k star？

你想想看，程序员的日常输出里，代码大概只占一半，另一半是文档、注释、commit message、周报。而中文技术圈长期没有一个公认的标准来管「中英混排怎么写才好看」，学校不教，公司不管，全靠个人审美。这份指北干的事，就是把这块空白填上了。

它把规则收敛成 13 条，四类硬规则加一块争议区。我挑几条有意思的细节说说。

空格是重头戏，一家就占了 5 条。中英文之间加空格（在 LeanCloud 上），中文和数字之间加空格（花了 5000 元），数字和单位之间也加空格（20 TB）。但有两个例外，度数和百分比不加，90° 和 15% 是对的，90 ° 反而是错的。还有一个更容易踩的坑，全角标点和其他字符之间不加空格。「刚刚买了一部 iPhone，好开心！」这句里逗号后面补空格，是很多人从英文习惯带过来的毛病。产品名还有一层豁免，像「豆瓣 FM」这种官方定死的写法，你硬给它加空格反而是错的。

标点类只塞了一条进来，但杀伤力最大。不重复使用标点符号，！！！和 ？！？！都不行。大陆的标点规范其实允许叠用问号感叹号，但指北明确说不行，理由很直接，破坏美观。

全角半角管 3 条。中文语境用全角标点，数字用半角（1000 而不是１０００），完整的英文句子内部用半角标点。「Stay hungry, stay foolish.」里的逗号句号，不跟着中文语境变全角。

最后是名词，2 条，最实用的是专有名词大小写。GitHub 就是 GitHub，github、Github、GITHUB 都算错。需要视觉上全大写时，HTML 里照标准写，用 CSS 的 text-transform 去变形，不改文本本身。这条对写技术文档的人来说，是区分「随手抄」和「真的在意」的试金石。

还有一块争议区。链接前后要不要加空格、简体中文用直角引号「」还是弯引号“”，指北承认这些语法上都对，属于个人风格，只是给了自己的倾向。我个人觉得这份克制很难得，规范最忌讳的就是把手伸太长。

文档是入口，工具链才是本体

光有一份规范，其实改变不了什么。你说中英文要加空格，同事说我觉得不加也挺好，这架吵不出结果。

这份指北真正的影响力，在它末尾挂的那 26 个工具上。

最大的一族叫 pangu，中文名「盘古之白」，专管中英文之间加空格这一件事，JavaScript、Go、Java、Python、Ruby、PHP、Vim 全都有实现，还有 IntelliJ 插件。另一族是 huacnlee 的 autocorrect，Rust 写的，空格、标点、全半角一把梭，装上 VS Code 插件能在你敲字的时候实时改。

规范吵不出结果，linter 不会跟你吵架。

指北里还列了一个「谁在这样做」的名单，Apple 和微软在三地的中文官网、V2EX、Ruby China、少数派。我特意去 Apple 中文官网扒了一遍文案，「北京时间 9 月 10 日凌晨 1 点」「RMB 950 至 RMB 5250」，中英文和数字之间确实全部带空格，名单没吹牛。

不过也扒到一个边界情况。页脚的备案号 京ICP备10214630号，数字和中文之间没有空格。合规文本有法定格式，排版规范管不到那里。这条边界 README 里没写，是我实测出来的。

三年没动，还是事实标准

有个事实挺意外。这个仓库主分支的最后一次内容更新，停在 2023 年 8 月 9 日，到今天整整三年没动过。issue 区还躺着一些建议，比如 #58，有人建议补省略号的使用范例，2016 年提的，到现在还开着。

一份三年没更新的规范，凭什么还是事实标准？

我的判断是，它把能定的都定完了。中英混排的排版问题就那么几类，每类给出明确裁决和正反例，剩下的全是公说公有理的争议区，本来就不该由一份规范来裁决。310 个 commit、35 位贡献者、12 年时间，最后收敛成 13 条规则，这个密度本身就很说明问题。

顺带说个背景。CSS 一直有个 text-spacing 属性，理论上能让浏览器自动处理中西文间距，issue #211 里就在讨论它。但这么多年过去，浏览器支持和系统 UI 都没跟上，所以手动加空格（或者交给工具）在可见的未来仍然是唯一解。

拿它审计你自己的写作管线

这份指北对我最大的价值，不是读，是当检查清单用。

我自己博客的发布流程里有 4 个排版脚本，管中文标点、中英文空格、术语大小写、代码块语言标识。这次我把它们和指北的 13 条规则逐条对了一遍，结果有点扎心。

13 条规则，我的自动化管线只吃下了六七成。剩下那些缺口靠人眼是补不过来的，你会漏。

补法也简单，autocorrect 一条命令就能兜底。

# 检查并预览要修改的地方
autocorrect text.md

# 直接改写文件
autocorrect --fix text.md

我现在的做法是自己的脚本继续跑，它们懂我的自定义术语表，autocorrect 作为最后一道网，两边规则冲突时以自己的为准。

规范的尽头是 linter

回头看这个项目，我觉得它最值得学的地方不在那 13 条规则。

而在它把一个审美问题，做成了工程问题。

排版好不好看，本来是个人感受，吵不出对错。但一旦把审美写成明确的规则，规则变成 linter，linter 塞进管线，它就不再依赖任何人的自觉。前端圈早就走过一遍这条路，ESLint 统一了代码风格之争，Prettier 干脆不给争论留空间。中文排版这个圈子小得多，但逻辑一模一样。

你团队里要是也经常为「这里要不要加空格」来回改稿，别吵了，把指北的规则丢给工具，让 commit hook 去执行。

审美会有分歧，lint 是零分歧的。