Markdown零基础入门：纯文本写作、语法与编辑器全指南

第一次被人安利用 Markdown 写作的时候,我心里是有点抗拒的:一个连加粗都要手打星号的玩意儿,凭什么比得上点一下工具栏就完事的富文本编辑器?直到我把同一份文档在三个设备上打开、发现字号行距全乱、复制到别处又带出一堆莫名其妙的样式之后,我才认真回头研究这套看起来"返祖"的纯文本写作方式。用了几年下来,我的结论很直接:Markdown 不是什么高级技巧,它是一套把"内容"和"样式"彻底分开的写作纪律,学会它花费不到一小时,省下的时间是以年为单位的。这篇就按我自己踩过的顺序讲,从它到底解决什么问题、语法怎么记、编辑器怎么配、完整流程怎么走,到那些文档里不会写、只有真写过几万字才会遇到的坑,一次性摊开。零基础也能跟着操作,已经会写的人可以直接跳到第五节的排查表。

1. Markdown 到底解决了什么问题,为什么值得现在开始用

1.1 内容和样式分家,是这件事的全部起点

理解 Markdown 只需要抓住一句话:你只管写"这是一级标题""这是一段引用""这是一段代码",至于标题用多大字号、引用左边那条竖线什么颜色,交给最后渲染的那一步去决定。这个思路听起来朴素,但它把写作过程中最消耗注意力的事情剥离出去了。

传统富文本编辑器的逻辑是所见即所得:你选中一段文字,点一下加粗按钮,编辑器立刻把这段文字包上一层格式信息存进文件。问题在于,这层格式信息和你写的字是混在一起存的,文件里既有文字,也有一堆描述"这段字是 14 号、加粗、段后 6 磅"的指令。你写得越多,这些指令越臃肿,而它们中的绝大多数你根本不关心,只是某次从网页复制粘贴时被顺手带进来的。

Markdown 走的是另一条路:文件里只有纯文字和极少几个标记符号。#开头表示标题,**包住表示强调,>开头表示引用。这些符号本身就带语义,任何文本编辑器都能看懂,任何一个 Markdown 解析器都能把它们翻译成对应的排版。你在写作阶段不再需要关心任何视觉细节,注意力全部留在文字本身。

我自己最直观的感受是写作速度的变化。以前写一篇长文,写三段就忍不住去调一下标题样式、拉一下行距,一天下来文字没写多少,格式倒是调得很熟练。换成 Markdown 之后,键盘上几乎不用离开主键区,写的时候眼睛盯着的是句子顺不顺,而不是字号大小。这种"先写完、再管好看"的顺序,是它真正值钱的地方。

1.2 纯文本带来的四个实际好处,不是情怀

很多人把"纯文本"当成一种情怀来讲,说什么复古、极简。我不太认同这种说法。纯文本是实打实的工程优势,随便列几条都是能立刻感知到的。

第一,任何设备、任何系统、任何年代都能打开。一个.md文件本质就是文本文件,手机自带备忘录能读,服务器命令行能读,十年前的老电脑也能读。你不会遇到"这份文档是用某版本软件做的,新版本打不开"这种事。我手上有一批五年前写的笔记,当时用的编辑器早就不维护了,但文件本身照样能打开、能搜索、能继续改。

第二,文件体积极小,传输和同步几乎无感。同样一篇五千字的文章,富文本格式存下来动辄几百 KB 到几 MB,纯文本通常只有十几 KB。差别不在于省那点硬盘,而在于同步、备份、邮件附件、批量处理这些操作的成本完全不一样。几十篇笔记打成压缩包也就一个附件的大小。

第三,内容可以被程序直接处理。这一点在长期使用中价值最大。因为文件是结构化的纯文本,你可以用脚本批量统计字数、批量替换术语、批量提取所有标题生成目录、把所有文档里的链接检查一遍。富文本文件要做这些事,得先解析一堆复杂的格式描述,成本高得多。我现在给一批文档生成总目录,就是几十行脚本的事。

第四,差异可比较。同一份文稿改了两版,纯文本可以逐行对比出到底改了哪几个字,富文本格式对比出来的往往是一堆格式描述的变化,混着真正的文字改动,根本看不清。这个特性在需要反复修改的长文档上几乎是决定性的。

1.3 什么人现在就该切换,什么人可以先等等

我不觉得 Markdown 是万能格式,有必要把适用边界说清楚,免得新手一头扎进去发现不合适又退回来。

适合的人群包括:经常写技术文档、接口说明、项目文档的;写学习笔记、读书笔记、素材库的;要写长文但不想被排版打断思路的;需要把内容发布到多个平台、反复复制粘贴的;以及任何需要长期积累文本资产的人。这几类人的共同点是:文字量大、修改频繁、需要在不同工具之间流转。

可以先等等的场景也很明确:需要精确控制版面、做印刷级排版的;文档里大量依赖复杂图表、公式、批注协作的;以及团队里所有人都不愿意学任何新东西的。最后这条听起来像玩笑,实际上是很多项目落地失败的真实原因——不是工具不好,是协作链条上有人不配合,你一个人用 Markdown,交出去还得转成别的格式,反而多一道工序。

提示:切换不必一刀切。我的做法是"新文档全部用 Markdown,旧文档不动",需要的时候再转。这样没有任何迁移成本,也不会因为一次大搬家而放弃。

2. 只学两成语法就能覆盖九成写作:一份能直接抄的速查表

2.1 块级元素:标题、段落、列表、引用

Markdown 的语法可以粗暴地分成两类:块级元素和行内元素。块级元素决定"这一块是什么",行内元素决定"这几个字怎么强调"。先把块级搞清楚,日常写作的八成需求就解决了。

标题用#开头,几个#就是几级标题。这里有个硬性细节:井号后面必须跟一个空格。#标题在很多解析器里不会被识别成标题,而是原样输出。这是新手第一个高频翻车点,我见过不止一个人写完整篇文档发现标题全是纯文字,原因就是漏了那个空格。层级上建议从##开始用,把#留给文档大标题,这样结构更清晰。

段落是最简单的:一段话写在一起,中间空一行就是新段落。这里要专门说一下换行,因为这是中文用户最容易困惑的地方。在 Markdown 里,单纯敲一次回车不会产生换行,渲染出来还是同一段;要在段内换行,得在行尾留两个空格再回车,或者干脆空一行分成两个段落。前一种做法在很多编辑器里会被自动清理行尾空格的功能破坏掉,所以我一般建议直接用空行分段,省心。

无序列表用-或*开头加空格,有序列表用1.开头加空格。有序列表有个贴心设计:你全写1.也可以,渲染时会自动编号成 1、2、3。这个特性在插入或删除条目时特别省事,不用手动重排序号。

引用用>开头,可以嵌套,>>就是二层引用。引用块适合放提示、注意事项、原文摘录。我写文档时习惯把所有"警告类"内容都放进引用块,这样读者扫一眼就能看到重点在哪里,比加粗一整段话要克制得多。

2.2 行内元素:加粗、斜体、行内代码、链接与图片

行内元素就那么几个,记住之后基本不会忘。

**文字**是加粗,*文字*是斜体,***文字***是加粗加斜。这里唯一的坑是符号和文字之间不要留空格,** 加粗 **在部分解析器里不生效。另外一个坑是中文标点紧邻星号时偶尔会失效,遇到这种情况,在星号内侧补一个空格或者调整标点位置就能解决。

行内代码用反引号包住,像`code`。这个元素在技术写作里用得极多,作用是明确告诉读者"这是一段代码或命令,不是普通文字"。它的另一个好处是:被反引号包住的内容里,所有 Markdown 符号都失效,你可以放心地在里面写星号、下划线、井号,不会被误解析。这一点在写正则表达式或者命令行参数时非常关键。

链接的写法是[显示文字](地址),图片的写法是![替代文字](图片地址),区别就是前面多一个感叹号。图片的替代文字别省略,它有两个作用:图片加载失败时显示出来告诉读者这里本来是什么,以及在无障碍阅读场景下被读出来。我早期写文档图省事全写![](),后来整理旧稿时发现根本不知道哪张图对应哪个位置,只能一张张点开看,那叫一个痛苦。

还有一个小技巧值得单独说:引用式链接。当同一个地址在文中出现多次,或者地址特别长影响阅读时,可以写成[文字][id],然后在文末统一写[id]: 地址。这样正文里干干净净,改地址也只需要改一处。

2.3 代码块、表格与分隔线:三个最容易写崩的地方

这三样是新手翻车率最高的,单独拎出来讲。

代码块用三个反引号包住,开头那行反引号后面跟上语言名,渲染时会自动做语法高亮。比如写```python,里面的内容就按 Python 的规则上色。语言名写错或者不写,通常会退化成无高亮的等宽块,不影响阅读但不好看。这里最隐蔽的坑是:代码块内部如果本身包含三个反引号,会提前终止代码块。解决办法是用四个反引号包裹外层,或者把内容里的反引号减少一个。

表格的语法用竖线分隔单元格,第二行是分隔行,用---表示,并且通过冒号控制对齐::---左对齐、:---:居中、---:右对齐。这里有两个必须知道的限制:第一,表格的每一行列数必须一致,少一个竖线整张表就塌了;第二,单元格里不能直接写竖线,要写成\|转义,否则会被当成列分隔符。我见过最典型的事故是表格里放了一段带管道符的命令,结果整张表错位成鬼样子。

分隔线是单独一行写三个或更多的-、*、_。这个元素看起来无害,但它和"二级标题的另一种写法"冲突:如果上一行是文字,下一行是一串---,很多解析器会把它理解成"把上一行变成二级标题",而不是分隔线。所以用分隔线时,前面一定要空一行,避免歧义。

2.4 一份能贴在显示器边上的速查表

把这张表放在手边,前三天可能需要瞄几眼,一周之后基本就是肌肉记忆了。我的建议是不要一开始就去背扩展语法,比如脚注、任务列表、定义列表、流程图这些,它们在不同平台上的支持程度差异很大,等你真的需要了再查,五分钟就能学会。

3. 编辑器怎么选:按场景配工具,而不是找一个万能软件

3.1 三类工具的差异,先搞清楚自己要什么

市面上的 Markdown 工具大致分三类,选错类型比选错品牌更耽误事。

第一类是带实时预览的桌面编辑器。左边写右边看,所见接近所得。优点是心理门槛最低,新手能立刻看到效果,不容易有"我写的到底对不对"的焦虑。缺点也很明显:分屏会压缩写作区,长时间写作时眼睛容易在两侧来回跳;另外,预览效果取决于它内置的解析器,你在编辑器里看到的样子,发布到别处未必一样。

第二类是"纯文本编辑器 + 命令行渲染"。写作时就是一个朴素的文本界面,写完了跑一条命令转成 HTML 或 PDF。优点是极致轻快,几万字的长文档也不卡,而且你能精确控制最终的输出样式。缺点是需要一点命令行基础,预览不是实时的,改完得重新跑一次。这类方案适合文档量大、需要统一排版风格的人。

第三类是网页版编辑器。打开浏览器就能写,多设备天然同步,适合临时记录和跨设备接续。缺点是依赖网络、数据在别人服务器上、导出功能往往受限。我的态度很明确:长期积累的内容不要只存在网页端,一定要有一份本地纯文本备份。

3.2 我的三套组合,按场景分开用

用了几年,我最后固定下来的是三套组合,按场景切换,而不是硬找一个"最好的编辑器"。

快速记录场景:手机备忘录直接写。灵感来的时候不挑工具,备忘录里写纯文本,格式符号手打。事后整理时复制到电脑上,补上标题层级和代码块。这个流程的好处是零等待,坏处是手机上打符号很烦,所以只用于短内容。

中长文写作场景:带实时预览的桌面编辑器。写教程、写文档、写这篇这样的长文,我会用分屏预览,主要是为了随时检查表格和代码块有没有崩。写作时把预览窗口调窄一点,视觉干扰会小很多。

批量处理场景:纯文本编辑器加命令行。需要一次性把几十篇文档转成网页、批量替换某个术语、合并成一本书的时候,图形界面反而慢,命令行一条指令搞定。

值得强调的是同一批文件在不同工具间可以无缝切换。因为它们本质是纯文本,你今天用这个编辑器,明天换那个,文件照样能开。这种不绑定,是我愿意长期投入 Markdown 的最重要原因之一。相比之下,把多年笔记存在某个专有格式里,一旦那个软件停止维护,迁移成本高得吓人。

3.3 解析器差异:为什么同一个文件在两处长得不一样

这一节偏技术,但非常值得新手了解,因为它能解释你后面遇到的绝大多数"玄学问题"。

Markdown 最初是一份非正式的语法说明,后来出现了多个实现,各家对边缘情况的处理并不统一。为了解决这个问题,社区整理出了一份标准化规范,业内通常称为 CommonMark,把标题、列表、强调、代码块这些核心语法的行为固定下来。但各家编辑器为了好用,又在这份规范之上加了自己的扩展:表格、任务列表、脚注、删除线、数学公式、目录生成……这些扩展并没有统一标准。

结果就是:同一个.md文件,在 A 编辑器里表格显示正常,在 B 平台上传后表格变成了一堆竖线;在本地写的好好的代码块,发布后高亮没了。这不是文件写错了,是两边的解析器支持的语法集不一样。

应对策略有三条,实操性都很强。第一,核心语法只用标准部分,标题、段落、列表、引用、代码块、链接、图片这几样,几乎所有解析器都认。第二,扩展语法用之前先在目标平台试一遍,拿一小段测试内容发出去看效果,别等写完五千字才发现表格不支持。第三,表格这类高风险元素,提前准备降级方案,比如发布不了表格就改成列表,内容不丢,只是形式上退一步。

注意:如果你的文档要发布到多个平台,最稳妥的做法是先写一份"核心语法版",再针对每个平台做少量适配。反过来,先按某个平台的扩展语法写满,再往别处搬,基本上等于重写。

4. 一次完整的写作流程实录:从建目录到发布

4.1 目录结构与文件命名,一开始就定规矩

很多人写 Markdown 是从"新建一个文件"开始的,写了几十篇之后发现文件散落各处、名字五花八门、找起来全靠搜索。我的建议是第一天就把规矩定下来,后面省无数事。

目录我通常按"领域 / 主题 / 具体文档"三层来分,层级不要超过三层,再深就记不住了。比如按大类建几个文件夹,每个大类下按主题分,主题文件夹里直接放文档。这样在文件管理器里点两下就能定位。

文件命名我坚持三条:全小写、用连字符或下划线分隔、名字里带日期前缀。日期用20240315这种格式,好处是按名称排序就是按时间排序,写日志、写周报、写系列文章的时候一目了然。名字本身用英文或拼音,避免中文文件名在某些同步工具和网页服务上出现编码问题,这个坑我踩过,文件传到服务器上变成一串乱码,排查了半天。

还有一条容易被忽略的:一篇文章一个文件。不要把所有内容塞进一个大文件,写到最后几万字的时候,打开慢、搜索慢、改一处要滚动半天。拆成小文件,再用一个索引文件把它们串起来,维护成本低得多。

4.2 草稿阶段:先写完,再管好看

这一节讲的是写作节奏,我觉得比语法本身更重要。

我的流程是两遍走。第一遍只写内容,不管格式。所有标题先统一写成##,想到什么写什么,顺序乱了也不要紧,先把脑子里那点东西倒出来。这个阶段最忌讳的就是边写边调格式,一旦开始纠结"这个该用二级还是三级",思路就断了。写技术文档时尤其如此,思路断一次,重新捡起来要花五分钟。

第二遍才做结构化处理:通读一遍,把该升的升、该降的降,把并列的内容整理成列表,把需要强调的句子放进引用块,把代码和命令用反引号包起来。这一遍的重点是让文档"能被扫读"——读者往往不是从头读到尾,而是先扫标题找到自己关心的部分,所以标题写得清楚比段落写得漂亮更重要。

有个具体技巧我在用:在草稿顶部留一个临时区块,写上"待补充""待验证""这里数据没确认"之类的标记,写完主体再回头一条条清掉。比在脑子里记着要可靠得多,尤其是写长文档写了两三天的时候。

4.3 导出与发布:HTML、PDF、图片怎么转

写完之后通常要变成别的形式。三种最常见的输出,处理方式不太一样。

转 HTML是最省事的,大部分编辑器和命令行工具都直接支持。转换时唯一需要注意的是样式从哪来:Markdown 只定义结构,好看与否全靠一份样式表。我一般准备一份自己常用的样式表,里面定好正文字号、行高、代码块背景、表格边框,所有文档共用,输出风格统一。命令行工具通常支持指定样式表参数,写一次记下来就行。

转 PDF稍微麻烦一点,因为 PDF 是排版结果,中文字体、分页、代码块换行都会影响观感。最常见的三个问题是:中文变成方块(字体没嵌入)、长代码行被截断(没开自动换行)、表格跨页断裂。前两个在转换参数里指定字体和换行选项就能解决,第三个需要调样式表里的分页控制。

转图片一般用在社交平台分享长文摘要的场景,通常是先把 Markdown 转成 HTML,再用工具截长图,或者直接按固定宽度渲染。这一步没什么技术含量,注意输出宽度别设太窄,手机上看会糊。

说一句实在话:导出这一步,能自动化就别手动。如果某个文档要定期更新发布,把转换命令写成一个脚本,下次改完直接跑一遍,比每次手动点菜单可靠得多,也不容易漏步骤。

4.4 用版本管理工具管理文字稿,是最被低估的习惯

写代码的人用版本管理工具是常识,写文字的人用的不多,但我觉得这是 Markdown 相对富文本最大的一个隐性优势。

原理很简单:因为文件是纯文本,版本管理工具能逐行比较出你每次改了什么。它的实际价值体现在三个场景。第一,改错了能回退。删掉一整段之后后悔了,不用去回收站翻,直接看历史版本。第二,能看到自己怎么改的。一篇文档改了五稿,回头对比第一稿和第五稿的差异,能清楚看到思路是怎么演进的,这个过程对写作能力的提升比看十本写作书都实在。第三,多设备协作不会互相覆盖。家里写一半,公司接着写,同步时如果冲突了,工具会把两边的差异标出来让你选,而不是简单粗暴地用"最后修改的那份"覆盖掉另一份。

具体操作门槛很低,只需要记住三件事:先建一个仓库目录,把文档放进去;写完一段之后提交一次,提交说明写清楚这次改了什么;需要看历史的时候查提交记录。命令就那么几条,花二十分钟学完,收益是长期的。

提示:提交的粒度不要太细也不要太粗。我的习惯是"一个完整的小节写完就提交一次",这样每次提交都有明确意义,回退时也更容易定位。

5. 常见问题排查实录

5.1 本地好看,发布就乱:渲染不一致的排查顺序

这是被问得最多的一类问题,我总结了一个固定的排查顺序,按这个顺序走,九成问题能定位。

第一步,确认符号和文字之间有没有空格。井号、减号、大于号、数字加点,这些块级标记后面都必须跟一个空格。缺空格是最常见的原因,而且因为有些编辑器会自动修正,你在本地看不出来,一发布就露馅。

第二步,确认有没有空行分隔。Markdown 里,不同块级元素之间通常需要一个空行来分隔。标题紧跟上一段文字、列表紧跟上一段文字、代码块紧跟上一段文字,如果中间没空行,很多解析器会把它们当成同一块内容处理,导致标题不生效、列表不渲染。

第三步,确认目标平台支持哪些语法。表格、任务列表、脚注、删除线,这些都属于扩展语法,支持情况差异很大。测试方法很简单:拿一小段包含所有你想用的语法的内容,发一篇测试文,看哪些生效哪些失效,把结果记下来。

第四步,检查有没有不可见字符。从网页或聊天软件复制过来的内容,经常夹带零宽空格、不换行空格这些看不见的东西,它们会让原本正确的语法失效。排查方法是用编辑器的"显示不可见字符"功能看一眼,或者干脆把那几行删掉重打一遍。

第五步,才是怀疑解析器版本。前面四条都排除了,再去看是不是工具本身的问题。

5.2 中文排版细节:那些让文档看起来"专业"的小事

语法全对,文档也可能看起来不舒服,差别往往在这些细节上。

中英文之间加空格。中文和英文、中文和数字之间留一个半角空格,阅读体验差别很明显。我一开始觉得这是强迫症,后来对比了一下加与不加的两个版本,确实加了更透气。这件事可以手动做,也可以用工具批量处理,后者更省事。

标点用全角,代码里用半角。正文里的逗号句号用中文全角标点,代码块和行内代码里的符号一律用半角英文标点。混用会让代码复制出去直接报错,这个坑非常隐蔽——看起来一样,实际字符不同。

一行不要写太长。源文件里每行控制在几十个字符以内,回车换行不会影响渲染结果(渲染时会被当成同一段),但对你自己的修改和版本对比友好得多。一整段写成一行,以后想改中间一句,对比记录里显示的就是"整段被替换",完全看不出改了什么。

标题层级不要跳。从二级直接跳到四级,结构上就断了。渲染出来字号可能看着还行,但生成目录、导出大纲的时候会出问题。

列表项内容长的时候,后续行要缩进。一个列表项写了好几行,后面的行需要缩进对齐到文字起始位置,否则会被当成新的段落跳出列表。这个细节在写长条目时特别容易忘。

5.3 表格与代码块:两个高危元素的专项处理

表格的四个典型故障。

还有一个隐藏问题:表格里放代码或链接,某些解析器处理不好,可能整行渲染异常。遇到这种情况,我的做法是把表格降级成列表,信息不丢,兼容性最好。

代码块的三个典型故障。一是内容里含三个反引号导致提前结束,外层改用四个反引号。二是语言名写错导致没有高亮,不影响内容但观感差。三是代码块里带超长行,转 PDF 时被截断,需要在样式里开自动换行或者手动折行。第三条在导出场景里特别常见,写脚本的时候顺手把长行折一下,能省掉后面一堆麻烦。

5.4 一份可以随时查的问题速查表

6. 把 Markdown 用出复利的几个习惯

6.1 把重复结构沉淀成模板

写得多了一定会发现,很多文档的结构是重复的:周报永远是"本周完成/遇到问题/下周计划",读书笔记永远是"核心观点/摘录/我的思考",技术文档永远是"背景/方案/步骤/注意事项"。这些重复结构不要每次手打,做成模板。

做法很朴素:建一个模板文件夹,每个模板就是一份空壳的 Markdown 文件,标题层级和占位文字都写好了。需要写新文档时复制一份,改个名字,往里填内容。省下的不只是打字时间,更重要的是它逼着你想清楚这类文档应该包含哪些部分,不会写着写着漏掉关键环节。

模板还可以再进一步:把常用的段落片段单独存成小文件,比如一段标准的免责声明、一段标准的参数说明表头、一段常见的警告引用块,需要的时候直接复制粘贴。我自己的片段库积累了两三年,现在写大部分文档基本是"拼装 + 填内容",效率比从零开始高太多。

6.2 和其它格式之间的互转,别把自己锁死

纯文本的好处之一是进出都方便,但具体怎么转要心里有数。

从别的格式进来:网页内容、富文本文档、表格数据,大多可以通过转换工具或者手工整理成 Markdown。转换工具处理不了的部分,通常是复杂表格和嵌套列表,需要手工修一下。我的经验是转完一定要通读一遍,自动转换出来的东西经常有奇怪的缩进和多余空行,不清理会影响后续渲染。

往别的格式出去:网页、文档、演示文稿、电子书,主流格式基本都有对应的转换路径。这里的关键不是会不会转,而是样式表要提前准备。同一套内容,配不同的样式表,出来的观感天差地别。花半天时间调一份自己满意的样式表,之后所有输出都受益。

还有一点值得提醒:不要把 Markdown 当成最终交付格式。给不熟悉这套语法的人看,对方打开文件看到一堆星号和井号,第一反应是"这是什么乱码"。该转成通用格式的时候果断转,Markdown 是你的工作格式,不是交付格式。

6.3 长期主义:文本资产为什么更保值

最后说一个更大的视角。

我们每天产出的文字,大部分都留不住:发在某个平台上的内容,平台改版就没了;存在某个软件里的笔记,软件停更就打不开了;用某个在线服务写的文档,服务关停就取不出来了。这些不是危言耸听,是这些年反复发生的事。

纯文本在这件事上有天然优势:它不依赖任何特定软件,不依赖任何在线服务,不依赖任何特定版本的解析器。十年后你打开一个.md文件,哪怕所有编辑器都不认这些符号了,内容本身还是完整可读的。这个特性在短期看不出价值,时间拉长了就是决定性的。

所以我的建议是:把你真正在意的东西,用 Markdown 存一份本地副本。不一定要放弃现有工具,但一定要有一份自己能完全掌控的文本。这个习惯坚持几年,你手上会积累出一批真正属于自己的文字资产,而不是散落在各个平台、随时可能消失的碎片。

提示:本地副本记得做备份,至少两份、放在不同的物理位置。纯文本备份成本极低,压缩打包几十 MB 就能装下好几年的产出。

我用这套方式整理文档大概有几年了,最大的体会不是"快了多少",而是写作这件事变得没有摩擦力了。打开一个空白文件就能开始写,不用担心格式,不用担心这个软件明天还在不在,不用担心换个设备就打不开。工具该做的就是把路铺平,让注意力全部回到文字本身——Markdown 在这件事上做得足够好,而且学它的成本,真的只有一个午休的时间。