第一章:像写作一样使用 Typora 与 Markdown
3585 字约 12 分钟
本章你会学到什么
- 理解 Markdown 的设计哲学:为什么它追求"内容优先"
- 理解为什么同一份 Markdown 在不同平台上显示效果可能不同
- 理解 Typora 在 Markdown 生态中的定位
- 建立文档结构意识:标题是骨架,不是字号
- 掌握结构元素(标题、段落、列表、引用、代码块)和行内元素(粗体、斜体、代码、链接、图片)的正确用法
- 理解图片路径管理的重要性
Markdown 的设计哲学
很多人第一次接触 Markdown 时会问:既然 Word 已经能写文章,为什么还要学一套看起来像代码的写法?这个问题很合理——如果一开始没想清楚 Markdown 到底解决了什么问题,后面的语法学习就很容易变成机械记忆。
Markdown 出现的初衷,是把写作重新拉回"内容优先"的状态。John Gruber 在最早的语法说明中强调,Markdown 的核心追求是"易读、易写"——一个 Markdown 文本即使还没被渲染,单看纯文本本身也应该足够清楚、自然。这意味着 Markdown 不是为了取代排版工具,而是为了让你在写作时尽量少被排版动作打断。
在传统富文本编辑器里,写作者经常会一边思考内容一边处理样式:字号是不是太大了,表格线是不是歪了,图片是不是应该再往左一点。Markdown 的思路相反——它鼓励你先把结构写清楚,再让软件根据结构去呈现样式。你先关心"这是一段标题""这是一条列表""这是一段引用",然后才关心这些东西最终显示成什么样子。
也正因为如此,Markdown 特别适合知识笔记、技术文档、课程讲义和长期积累型写作。当你的材料越来越多时,你会发现真正难管理的不是"怎么把某一页排得很好看",而是"怎么让几十篇、几百篇文档都保持清晰、稳定、可迁移"。Markdown 在这件事上非常强,因为它的底层是普通文本文件——可搜索、可版本管理、可迁移、不会被某个软件的私有格式绑住。
为什么同一份 Markdown 在不同地方显示得不一样
这是一个常见且正常的现象:同一份 .md 文件,在 Typora 里看着很好,放到 GitHub 上某些细节却不完全一样;换一个静态站点生成器后,换行、表格、脚注的表现又可能变化。
这不意味着 Markdown 本身"不稳定"。原因是 Markdown 的原始定义过于简短,很多边界情况没有被完全说死——子列表到底需要多少缩进,标题前是否必须空行,列表中的空行会不会改变结构,这些在不同实现里都曾出现过差异。CommonMark 规范的出现就是为了解决这个问题,它把这些细节写成了机器可验证的规则。
Typora 倾向于支持接近 GitHub Flavored Markdown 的常见扩展;GitHub 自己有一套面向仓库协作的渲染规则;CommonMark 则是为这些行为提供更严格的共同地基。
因此,正确的学习方式是:先掌握最稳的基础写法(标题前后留空行、井号后面加空格、列表缩进清楚、图片用相对路径),再逐渐理解平台差异。这种保守写法不仅让文档更稳定,也让源文本本身更整洁。
Typora 的定位
理论上你可以用记事本、VS Code、Vim 任何能保存纯文本的编辑器写 Markdown。但 Typora 把"源文本写作"和"所见即所得预览"结合得非常自然——你输入 # 标题,它直接渲染成标题效果,而不是左边给你看代码、右边单独给你看预览。
这并不意味着 Typora 隐藏了 Markdown。你在 Typora 中写的内容,底层仍然是标准 Markdown 源码。Typora 只是让写作过程更流畅,帮你逐步意识到:这个标题背后是 #,这个复选框背后是 - [ ],这个表格背后是竖线和短横线。
Typora 支持的扩展包括任务列表、围栏代码块、表格、删除线、脚注、YAML Front Matter、目录和数学公式。它还提供大纲视图、字数统计、主题切换、图片管理、导出 PDF/HTML 等功能。这些能力组合在一起,使它既适合做 Markdown 学习工具,也适合做长期写作工作台。
需要提前了解的是:Typora 从 1.0 版本起不再是免费 Beta,正式使用需要购买授权。
文档结构意识
很多入门教程喜欢先列一串语法清单,但读完以后新手常常并没有真正掌握写作。原因是 Markdown 最核心的能力不是"会多少招",而是"能不能把一篇内容写得结构分明"。最先掌握的应该是标题、段落、列表、引用和代码块——这些元素决定了文档的基本骨架。
标题:不是字号,而是层级
一级标题对应整篇文档的主题,二级标题对应主要章节,三级标题对应章节中的小节。在 Typora 的大纲面板中,标题层级会自动生成导航树——层级越清晰,大纲越有用。
# Typora 入门
## 安装与界面
### 文件树与大纲你应该看到的是它们之间的结构关系,而不只是"大字"和"小字"。如果标题只被当成放大字体的工具,很容易出现层级混乱——比如一个三级标题前面没有二级标题,或者同一层标题承担完全不同粒度的内容。
一个兼容性习惯:井号和标题文字之间留一个空格,标题上下留空行。
段落:学会"空一行"比学会回车更重要
在 Word 里,很多人对段落的理解是"按一下回车就换行"。但在 Markdown 里,段落与换行不是同一个概念。段落是由连续文本构成的,不同段落之间靠空行分隔。
如果你只是普通换行但没有留空行,很多 Markdown 解析器会把它仍然当作同一段的一部分。Typora 会帮你更自然地处理输入动作,所以新手在 Typora 里常常意识不到这个规则的重要性。但如果你把文档放到 GitHub 或其他解析器里,规范的段落写法就会变得非常关键。
原则:如果你希望读者感受到"这里开始说另一层意思了",那就用空行分段。段落的节奏,本质上是在安排思路的呼吸。
行内换行(不开始新段落)用 Shift + Enter。
列表:表达并列与顺序
无序列表适合表达并列项,有序列表适合表达步骤和流程:
- 安装 Typora
- 创建第一篇文档
- 学会标题和段落1. 打开 Typora
2. 新建文档
3. 输入一级标题
4. 保存为 .md 文件日常正文统一用 - 作为无序列表符号,最稳定也最清爽。
列表真正难的地方是嵌套。在列表中继续插入段落、引用或代码块时,需要四个空格或一个 Tab 的缩进。缩进代表层级,这件事没有真正吃透,一碰到复杂列表就会乱。
引用:借用另一层声音
引用块用 > 开头。它的真正意义是为正文引入一种"非主叙述"的声音——你可以用它放提示、定义、原文摘录、警告或补充说明。
> Markdown 的设计重点不是排版特效,而是可读性与可写性。引用块只在"这里需要一种次级语气"时使用,而不是为了让页面看起来丰富就到处套框。
代码块:该块则块,该行内则行内
Typora 支持 GitHub Flavored Markdown 风格的围栏代码块——三个反引号开始,三个反引号结束:
```bash
mkdir notes
cd notes
```加上语言标识(bash、python、javascript 等)可以启用语法高亮。
代码块的价值在于把"需要按原样保留的文本"从普通叙述中剥离出来——命令、配置、程序片段、JSON、YAML、日志样例都属于这种情况。如果只是在一句话里提到一个命令名或变量名,用行内代码(反引号包裹)就够了。好的文档写作不是代码块越多越专业,而是该块则块、该行内则行内。
行内语法:精确强调,不是到处涂颜色
行内语法的作用是让句子内部产生轻重、区分与提示。
粗体与斜体
粗体强调关键概念,斜体用于轻度强调、术语或语气变化。优先用星号写法,兼容性最好。
这是 **重点概念**。
这是 *轻度强调*。粗体一旦过量,就会失去强调效果。把它理解为"给读者目光打一个聚焦点",而不是"每一句都刷存在感"。
行内代码
行内代码用单个反引号包裹:`mkdir`、`README.md`、`Ctrl + Shift + P`。它告诉读者"这部分内容不要当普通语义理解,要当作一个需要精确识别的字符串"。在技术写作里,命令名、文件名、参数、路径用行内代码包裹,能大幅降低误读概率。
链接
行内链接的写法是 [显示文字](URL):
[Typora 官方支持文档](https://support.typora.io/)链接不只是"放一个网址"——它是文档建立外部连接的方式。Typora 也支持引用式链接,适合长文档中多次复用同一 URL。
图片
图片语法和链接很像,前面多一个感叹号:
但真正重要的不是这行语法本身,而是理解 Markdown 中的图片不是"嵌入文件内部的数据",而是"对一个图片文件的引用"。Markdown 文件本身是纯文本,图片通过路径被引用进来。
图片路径管理
很多人学 Markdown 时把注意力全放在语法上,却把图片路径当成小问题。等文档数量一多,或者换电脑、同步到 GitHub、导出到别的地方时,问题就会集中爆发:图片找不到、路径全断、配图一片红叉。
这类问题频繁出现,是因为很多人没有真正理解 Markdown 文件和资源文件之间的关系。Markdown 文档不是封闭盒子,图片、附件通常在外部文件里,通过路径被引用进来。文档写得稳不稳,不只取决于语法会不会写,还取决于文件系统是否有秩序。
一个适合长期维护的目录结构:
books/
└── typora-and-markdown/
├── chapters/
│ └── 01-typora-and-markdown.md
└── images/
├── chapter-01-figure-01.png
└── chapter-01-figure-02.png采用这种结构时,文档中的图片引用可以写成相对路径。相对路径的价值不只在于"看起来简洁",更在于它会跟着整个目录一起移动——复制到另一台电脑、推到 GitHub、发给别人,图片都能正常显示。
建议尽早养成的习惯:
- 每个项目目录里都建立固定的图片文件夹(如
images/) - 让 Typora 在插入图片时复制到指定目录,并使用相对路径
- 图片文件名和章节建立对应关系(如
chapter-01-figure-01.png)
GitHub 官方文档也强调:仓库内部引用文件和图片时,优先使用相对链接。绝对路径的文档只能在你自己的当前机器上正常工作。
常见误区
把 Markdown 当成"轻量版 Word":Markdown 的价值在结构化表达与长期可维护性,不在像素级排版自由。如果你追求杂志级排版控制,Markdown 不是为那个目标设计的。
把 Typora 当成"不用学语法的编辑器":短期看很舒服,长期会让你卡住——离开 Typora 以后你不懂源文本,不知道为什么换个平台样式不同。正确的方式是借 Typora 的所见即所得体验进入 Markdown,但最终仍然理解 Markdown 的基础规则。
过早追求高级功能:脚注、公式、YAML、主题 CSS、图床上传,这些在没有把标题、段落、列表、代码块和图片路径写稳之前,只会增加噪声。
忽略文件系统:Markdown 文档和文件名、目录、图片路径、导出位置紧密相关。如果不把 Markdown 当成"文件系统中的文档",而只当成"编辑器里的一页纸",迁移和发布时一定会吃苦头。
本章小结
Markdown 的核心设计哲学是"内容优先"——先写清楚结构,再让软件呈现样式。这种思路让 Markdown 特别适合需要长期维护、多次迁移的知识类写作。
同一份 Markdown 在不同平台显示可能不同,原因是历史规范对边界情况定义不够严格。CommonMark 规范正在解决这个问题。掌握保守写法(空行、空格、相对路径)能最大程度避免跨平台问题。
Typora 是一个让 Markdown 写作更流畅的编辑器——它不隐藏 Markdown,而是帮你逐步理解它。
文档写作最核心的能力是结构意识:标题是骨架(不是字号),段落靠空行分隔,列表靠缩进表达层级,引用是借用另一种声音,代码块用来隔离需要原样保留的文本。
图片路径管理是从"会写语法"到"会管理文档"的关键一步。从一开始就用固定目录、相对路径和统一命名来管理图片,能避免后期大量的路径断裂问题。
下一步
下一章会深入文档的长期维护:如何组织目录结构、管理图片与附件的路径、命名文件、以及让整个文档体系经得起时间考验。