Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。
文章代表作者个人观点，少数派仅对标题和排版略作修改。
最开始写作时，我也经常去尝试大家所喜闻乐见的一些 Markdown 文本编辑器，比如：Typora、Ulysses、Bear、iA Writer、纯纯写作 等。
在这些编辑器中，有的最初都是只有在手机端上才能使用，所以我在通勤过程中也尝试在手机上写下一二文字，但都苦于屏幕太小且嘈杂的环境对我造成干扰，使我没办法很好地专注于内容构思上最终而放弃。
于是后面我干脆将创作都放到了电脑上。
但在电脑写作时，作为程序员的我又感觉使用桌面端的文本编辑器往往很难让人有敲代码的那种操作感，每次碰上需要将大段内容调整、批量的文本替换等操作时，需要额外的鼠标操作从而打断写作的连贯性。
所以我盯上了 VS Code，一款由微软开发的、目前被程序员广泛使用的跨平台编辑器。
但最开始我使用 VS Code 时并没有将其作为一个文本编辑器来使用，而是将其作为一个编写代码的 IDE（Integrated Development Environment，即集成开发环境）来使用。但它本质上还是属于文本编辑器，只不过借助了社区丰富的插件才拥有了一些能和真正意义上的 IDE 相比肩的功能。
从我开始尝试使用 VS Code 来进行写作至今，粗略统计，我已经写了包括技术文档、少数派文章以及教程等在内的文字大约 30 万余；随着写作次数的增多，我发现 VS Code 在某些层面上很满足我这种有着技术背景且在桌面端进行创作的作者的需要。
除了像 Typora 这样目前完全免费的文本编辑器之外，前面提到的像 Bear、Ulysses、纯纯写作等 App 虽然基础版本都是免费的，但你需要额外付费解锁更多功能，如：同步、主题等，可这些功能对我来说要么感觉不能随心所欲地做到跨平台管理，要么就是很少用到。
而且有些 App 甚至还是平台独占，比如在 iOS 端上有，在 Android 端或 Windows 端上又没有，完全将写作体验限定在了系统平台上。直到有一天我的 iPhone 6 寿终正寝之后，我发现我已经无法再拥有平台独占编辑器的写作体验了，我必须重新找个机会将以前所写的内容导出并重新寻找下一个编辑器。
在这个过程中，数据迁移和挑选编辑器是十分消磨个人精力的事情。以至于后续无论是移动端上的 App 还是 PC 端上的应用程序或软件，能让我考虑长期使用它的一个原因首先就是跨平台。
跨平台的意义在于无论你是移动端的 iOS、Android，还是客户端的 Windows、macOS、Linux 等 OS 操作系统，甚至除了两端之外还包括 Web 网页端，你都可以拥有统一、相对一致的使用体验。当然不管是哪个为了适配哪个平台，都需要花费大量的人力物力，因此通常基本只要能满足移动端或客户端的跨平台就足够了。
而 VS Code 本身就满足跨平台的条件，即是客户端或桌面端层面的跨平台。
如果从编辑器的本质功能「编辑」上来说，VS Code 其实和其他文本编辑器其实并没有什么区别。然而仅具备的是简单的写作编辑功能，那么它相比于其他文本编辑器所拥有的同步、主题同功能来说，毫无疑问是个「缺胳膊少腿」的玩具。
但好就好在，VS Code 的设计者们从一些 IDE 前辈们中学习并汲取到了有益部分，并赋予到了 VS Code 中，而这有益的部分那就是——插件机制（Plugins）。正是这个核心的功能填补了 VS Code 一些缺失的方面。
VS Code 之所以能作为被人们青睐，除了免费开源之外，还是归功于它有着庞大且丰富的插件社区，让开发者能够二次开发或是实现其他功能。
也正是多亏了 VS Code 有着丰富的插件生态，才让我摸索出了「WVG」这么一条适合我个人的写作流程。其中：
借助插件我们除了弥补部分缺失的功能之外，还拥有了一些文本编辑器所不具备的功能，甚至对于开发人员尤其是前端开发人员来说，妥妥地算是个前端利器。
所以为了让我的写作体验能够更好，我需要使用到其他开发者开发的插件。下文所有插件均可在 VS Code 右侧的插件模块中被搜索到并直接安装使用。
Vim 是一个可高度配置的文本编辑器，它可以让使用者摆脱鼠标的束缚，而通过键盘来完成对可编辑内容的操作，如全选、复制、粘贴、删除等。
VS Code 本身自己有一套支持对可编辑内容操作的快捷键，但因为我本身就习惯了借助 Vim 用键盘来操作的方式，因此就没有打算增加额外的学习成本，选择了目前下载人数最多且同名的 Vim 插件来进行操作。
选择 Vim 操作的原因在于减少因需要调整内容而打断我写作时的专注过程，当然如果习惯了 VS Code 的快捷键，也能够一定程度上帮助达到和 Vim 类似的效果。
但 Vim 操作的学习成本会比较高，如果对此感兴趣的高阶玩家可以自行进一步了解。但对于大多数人非技术背景的作者来说，使用 VS Code 的快捷键和鼠标操作也就足够了。
Markdown 对很多少数派的作者来说是再熟悉不过的东西了。它是一种能让我们专注于内容而不需要太注重于排版样式的轻量标记语法。
很多人选择 Markdown 的原因在于减少人为排版的操作，通过简单的符号对内容进行标识后，由程序后期帮我们自动完成诸如一级标题、超链接、引用等样式排版工作，而我们专心管理文字内容即可。
VS Code 上有着丰富的 Markdown 插件，而当中的 Markdown All in One 是让我体验较好的一款。通过它我们能在 VS Code 上能享受相对完整的 Markdown 体验，包括 Markdown 语法、代码块、数学公式等等。
参考阅读：
最初我以为只有代码才会存在格式化一说，没想到文本内容也有「格式化」，当然把这叫排版或许更为大家所熟悉。
以前没有在少数派上发文章时，我从来也没有注意对通常的文本进行简单的排版，比如：穿插在中文中的英文和数字需要左右加空格。
而经过少数派的编辑们几次帮我调整之后，我才发现对文字进行适当的排版可以提升内容的视觉感受并让人拥有良好的阅读体验。好在已经有开发者曾开发过一个名为 pangu（盘古）的格式化程序，虽然它是基于正则来实现的，但也能很好地帮助我们对文字内容进行排版。
原生的 pangu 并非是 VS Code 插件，而是需要每次运行程序才会对目标文档进行格式化。所以目前我使用的是名为 Pangu-Markdown 的 VS Code 插件。
每次当我写作保存后，我就会下意识地通过该插件来对我的内容进行必要排版，这当然也在某些程度上能减轻编辑们的工作量（没准这是给编辑们留下必要的印象分，有助于帮你争取更高的稿酬）。
参考阅读：
因为我们在 VS Code 使用 Markdown 都是以原生语法的形式来书写内容，若想要查看渲染排版后的内容，需要进行预览。前面提到的 Markdown All in One 插件本身也提供了预览功能，但是比较简陋。所以我就额外使用了另外一款名为 Markdown Preview Enhanced 的 Markdown 内容预览的增强插件。
而借助 Markdown Preview Enhanced 我们除了能看到支持更好的渲染效果之外，它还为我们提供了其他额外的导出操作、CSS 样式调整等。
VS Code 不像其他文本编辑器一样会有关于文章内容字数统计的功能，所以需要借助插件来额外辅助。
Word Count CJK 是一个专门用于中文字数统计的 VS Code 插件，装上了它之后无论我们是在普通文本格式还是 Markdown 格式中写作，都能在 VS Code 底部的状态栏中帮我们很好地显示目前我们写作的篇幅字数是多少。
这款插件让我们能够以量化的方式让我们了解到目前创作内容的字数，方便我们更好地去把握整个创作的篇幅或对内容进行调整。
如果说 VS Code 的插件是为了让我们拥有更好的写作体验，那么使用 Git 和 Github 就是让我们有着更好的版本控制、历史追溯体验，并弥补同步功能的缺失。
Git 是一个免费的、开源的分布式版本控制系统（Version Control System，简称 VCS）。所以只要是个程序员，基本上都了解或使用 Git。但我平时除了用 Git 管理代码外，还会用它来管理我的文章内容。
可能有的朋友会疑惑为什么 Git 能管理文章内容？那是因为无论是代码还是文字，本质上它们都是一些字节序列，对机器来说都是别无二致的。于是只要我们将每次写作的内容保存并提交到 VCS 之后，Git 就会给当前提交版本留下特定的快照（Snapshot）。这个快照就相当于我们在 Word 或者是其他文本编辑器中的「历史版本」，我们可以根据自己的需要进行回溯。
这也是使用 Git 的另外一个好处：它能很方便地管理我们文章的版本。
通过 Git 我们可以随时在每次提交的快照中来去自如地穿梭，当然这并不是必须的，因为文字和源代码稍微有些差异的地方在于，修改文字内容的频率可能会往往低于修改代码的频率。
我在少数派上的《Python 自学手册》付费教程就是全程通过 Git 来完成版本的控制与内容的修改。
比如我已经完成了第一稿的内容创作，需要开始第二稿的初步构思或修改，尽管我们可以完全拷贝第一稿的内容，然后再拷贝的副本基础上进行修改；但当我们如果在第二稿的修改过程中，零零散散地改动了第一稿中的某些内容，那此时我想要将这些改动也同样同步到第二稿上时，可能需要人工复制粘贴并核对。
结合 Git 的分支（Branch）功能，能让我们拥有更好地版本管理控制体验，分支给我们提供了可以制造一个像超级英雄漫画里平行宇宙的能力，第一稿的修改丝毫不会影响到第二稿，除非我们手动将两个平行世界进行融合。虽然两个版本是处于并行写作的状态，但在适时的时候我们可以将它们合并成新的宇宙。
如果不是从事程序员的相关工作，那么大多数人通常不到 Git，但你一旦掌握了它，或许它能在某些程度上帮助你更好地解决文章多次修改却需要人为合并的问题。
注意！最好不要使用 Git 来管理体积较大的文件，否则可能会影响拉取、合并等过程的速度。
但为了能在 VS Code 中使用 Git，你仍首先需要在电脑中下载并安装 Git。
Git 本身只提供了 VCS 功能，但不提供保存代码（或内容）的服务。因此基于 Git 就会衍生出很多代码托管平台，其中最知名的当属 Github。Github 除了为使用者们提供了基本的代码托管服务之外，还围绕着代码提供了一系列的集成方法或应用服务，比如持续集成的 Github Actions、测试代码覆盖率的 Codecov 等。
但因为只是用于保存写作内容，因此这些服务通常很少用到。所以每当我写作暂告一段落或完成时，我会先将内容提交进 Git 的 VCS 中保存快照，然后再通过 VS Code 集成的 Git 命令推送至 Github 平台我个人的私有仓库中。
在微软收购了 Github 之后，Git 也被进一步地整合到了 VS Code 之中，换而言之 Git 的相关功能本身就已经集成而无需额外下载插件。
但由于 Github 是一个国外网站，如果个人访问存在一些网络阻碍时，那么国内的 码云 Gitee 也是一个很好的选择，而且它能够提供更快的同步速度。
在 Github 上你通常还能找到很多有意思的项目，不仅是个人还包括大厂都会在上面开源自己的项目，比如我之前关注的微软一个名为 Bringing Old Photo Back to Life 的项目，它通过主流的机器学习等算法能够将老照片变得更为高清，让尘封且模糊的画面变得那么真实可见。
又比如在 2018 至 2019 年时火热的 Dress 女装大佬项目，别以为程序员们都戴着黑框眼镜穿着格子衫战衣的理工男形象，谁想到一大批人实际上都是女装大佬呢？（也许，女装只有 0 次和无数次）
在程序员人群中，除了语言之争这样的话题以外，IDE 之争也是容易带起讨论和节奏的话题。但在少数派 Matrix 的作者群里偶尔也会看到一些作者们在讨论文本编辑器优劣的相关内容，可以看出并文本编辑器在作者的眼中和体验都不尽相同。
但无论是语言、IDE 还是文本编辑器，它们本质上都还是工具。这些被用以比较的工具永远都没有对错、好坏之分，只有适合和不适合一说，每个工具都有自己适合场景和人群，不一而足。
关联阅读
> 下载 少数派 2.0 客户端、关注 少数派公众号，解锁全新阅读体验 📰
> 实用、好用的 正版软件，少数派为你呈现 🚀
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。