企业官网建设流程全解析

写 Markdown 用了这么多年，从最初的记事本、Typora、Obsidian，再到现在的 VS Code，我最终还是把这套“基于 VS Code 的 Markdown 编辑器部署方案”固定成了日常主力工作流。不是因为它最花哨，反而是因为它足够干净、足够可控，而且完全掌握在自己手里。网上聊 Markdown 编辑器的文章不少，但大多停留在“推荐几个插件”的层面，真正把从安装、配置到调试、导出的完整链路讲清楚的不多。这篇就从头到尾把我自己的部署方案掰开揉碎讲给你听，你可以直接照着抄。

如果你还在纠结“VS Code 到底能不能当好一个 Markdown 编辑器”“插件装了为啥不生效”“图片路径为什么总在预览里裂掉”“怎么优雅地导出 Word/PDF”，这篇文章就是为你准备的。我会把每一步操作、每一个配置项背后“为什么这么做”的逻辑都讲明白，不只是告诉你点哪里，而是让你理解这套方案为什么能跑得稳。

1. 项目核心思路：把 VS Code 改造成你的 Markdown 专属工作台

1.1 为什么放弃 Typora，转到 VS Code 写 Markdown

先说一个背景：我曾经是 Typora 的深度用户，它的所见即所得体验确实无话可说，那种“边写边排版”的沉浸感，其他工具很难替代。但用到后期，我遇到了几个绕不开的痛点。

第一是图片路径问题。Typora 的图片管理在“本地单篇文档”场景下很顺手，但一旦文档变多、目录层级变深，或者需要把 Markdown 文件放进 Git 仓库管理，图片路径就常常变成![](./image/xxx.png)和![](../../assets/xxx.png)的混乱战地。你永远不知道哪张图会在朋友打开你文档的时候裂掉。

第二是“所见即所得”本身的陷阱。Typora 把 Markdown 语法渲染得很漂亮，导致你在写|表格、代码块、嵌套列表的时候，反而不太关注原始语法结构。比如表格自动补全很智能，可一旦换行符、竖线对齐出问题，在 GitHub、GitLab 或者其他 Markdown 渲染器里打开就是一团糟。换句话说：你在 Typora 里看到的“排版正确”，换一个平台未必正确。

第三是扩展能力的边界。Typora 可以放宽心做“打字机”，但对于我这种需要同时处理代码片段、数学公式、Mermaid 图表、甚至文档版本管理的技术博主来说，编辑器必须和代码工作流打通，而 VS Code 本身就是干这个的。它不只可以写 Markdown，还能写 Python、写 Shell、写前端，甚至配合 Jupyter 做数据分析。一套工具打通所有工作场景，这个诱惑太大了。

所以我最终的结论是：Typora 适合“随手写”，VS Code 适合“正规化管理”。“随手写”的依赖感很强，但“正规化管理”自由度和可扩展性都是碾压级别的。而我这套部署方案，正是把 VS Code 从纯代码编辑器，调校成一个顺手、稳定、功能全面的 Markdown 写作工作台。

1.2 “部署方案”到底在部署什么

很多人以为“部署方案”是技术人写代码才会用的词，放到 Markdown 编辑器上有点用力过猛。但实际操作起来你会发现，把 VS Code 从“能打开 .md 文件”到“好用、稳定、可复用”，中间确实差着一整套配置和插件组合。

这套方案我最看重的四个维度分别是：

• 稳定性：预览渲染效果要准，和 GitHub、Typora 的渲染结果不能差得太离谱。
• 可迁移性：文档、图片路径、配置项都能跟仓库走，换一台电脑几分钟恢复环境。
• 可扩展性：既能写纯 Markdown，也能随时插入代码、数学公式、图表，不至于被单一工具锁死。
• 导出能力：Markdown 写成后能顺利导出 Word、PDF，交给同事、客户或发布到博客站。

围绕这四个维度，我给自己定了一个部署清单。这个清单在执行顺序上有讲究：先装基础插件，再调核心配置，然后解决图片路径的问题，最后打通导出与发布链路。每完成一步，我都会先实际验证效果，再进入下一步，避免问题堆积到最后一起爆发。

并且，这套方案有一个核心哲学：尽量少用“大而全”的插件，而是选用“小而精”的插件组合。因为同一功能的插件装得越多，冲突概率就越大。比如 Markdown 预览增强插件和 Markdown All in One 在快捷键、渲染器上就有部分重叠，配置不好容易互相干扰。我后面会讲清楚最终的选型逻辑和替代方案。

2. 从零开始搭建基础环境与安装核心插件

2.1 VS Code 安装与初始化那些容易被忽略的小事

VS Code 的安装本身没什么门槛，官网下载对应系统的安装包，一路 Next 就行。但我建议你注意两个细节，它们直接影响后续使用体验。

第一是安装时勾选“添加到 PATH”。这样你在 Windows Terminal、PowerShell 或者 WSL 里都能直接通过code命令启动 VS Code，配合命令行操作会方便非常多。很多教程不会提这个勾选项，但等你开始用code .打开当前目录的时候，就会回来感谢这个细节。

第二是不要一上来就装一堆插件。我见过太多人第一次打开 VS Code，就被“推荐扩展”界面吸引了，装了几十个插件，结果界面变得奇卡无比，快捷键冲突一堆，最后得出“VS Code 开 Markdown 太重”的结论。其实都是插件累赘惹的祸。我的原则是先留一个干净环境，用到哪个场景再补哪个插件。

基础配置上，我会在settings.json里固定几项（打开方式：Ctrl+Shift+P，输入Open User Settings (JSON)）：

{ "editor.fontSize": 15, "editor.lineHeight": 1.8, "editor.wordWrap": "on", "editor.renderWhitespace": "none", "files.autoSave": "afterDelay", "files.autoSaveDelay": 1000, "workbench.colorTheme": "One Dark Pro", "workbench.iconTheme": "material-icon-theme", "markdown.preview.lineHeight": 1.8 }

editor.wordWrap对 Markdown 写作来说太重要了，它决定长段落会不会软换行。Typora 用户切换到 VS Code 后最容易不习惯的就是默认不换行，整段文字横向拉成一条长龙，阅读体验很差，所以我把这个配置作为开篇第一个必须设置的项。

而"workbench.colorTheme"和"workbench.iconTheme"其实是锦上添花，只要选一个你自己看着舒服的主题就行。我习惯用深色主题写技术文档，长时间看屏幕没那么累。

2.2 核心插件全家桶：日常写作与增强预览

插件是 VS Code 写 Markdown 的灵魂。经过反复试用和踩坑，我最后保留的一套插件组合非常简单，但覆盖了所有刚需场景。每个插件我都会说明我为什么保留它，以及有哪些替代可以考虑。

首先是 Markdown All in One。它负责日常写作中的键盘级操作：自动补全闭合标签、快速插入表格、生成目录 TOC、列表缩进、任务列表勾选等。“表格自动格式化”和“生成目录”是我日常使用频率最高的两个功能。比如你写了一个 3 行 5 列的表格，列宽参差不齐，只需要打开命令面板执行Markdown: Format Table，它就能自动把表格对齐得漂漂亮亮。目录生成快捷键是Ctrl+Shift+P然后输入Markdown: Create Table of Contents，几秒钟就能生成带锚点的目录。它的核心价值不是渲染效果，而是“写”这个环节的流畅度提升。

接下来是 Markdown Preview Enhanced，这是整个方案里我最依赖的插件，简称为 MPE。它既是 Markdown 预览渲染器，也是高级语法支持中心。MPE 能直接渲染 LaTeX 数学公式、Mermaid 流程图、PlantUML 图，还支持在预览界面内直接导出 HTML、PDF 甚至电子书格式。你会发现，MPE 把 Typora 的所见即所得和代码编辑器的高自由度缝合了起来。

安装 MPE 后，我个人会直接在预览页面右键，把 “Open in Browser” 设为高频操作，配合热力图效果一样高效。它的渲染引擎支持 GitLab/GitHub 风格 Markdown，这意味着你在 VS Code 里写的效果，贴在 GitHub 上基本一致，这个一致性对我这种经常跨平台分享文档的人来说价值极高。

第三个是 Paste Image。它解决的是“截图自动粘贴成图片文件并插入引用”的需求。按Ctrl+Alt+V截图粘贴，插件会保存一张 PNG 到指定目录，并自动在 Markdown 里插入正确的图片引用语法。这个插件省掉了“先保存图片、再手动写引用、最后改相对路径”的三步操作，是写作流程中最提升幸福感的插件。

我搭建环境时，还顺手装了以下这些辅助插件：Code Spell Checker（拼写检查，写英文技术文档必备）、Word Count (VS Code)（实时统计字数）、Markdown Preview Mermaid Support（为官方预览增加 Mermaid 支持）。这几个都属于“有了更好、没有也不致命”的范畴，但对我来说配合起来效率提升非常明显。

2.3 官方预览和增强预览同时用，不冲突吗

这是一个很多人问过我的问题。默认情况下，VS Code 自带的 Markdown 预览（快捷键Ctrl+Shift+V）已经支持基础语法和部分 GitHub 风格渲染；而 Markdown Preview Enhanced 是独立于官方预览的一套增强引擎。两者同时安装并不会直接冲突，因为它们各自的预览命令是分开的。

我的建议是：日常编辑用 MPE，因为它能渲染更多高级语法；而你在不确定“GitHub 上是什么效果”时，再用官方预览做一次交叉验证，这样能避免“MPE 渲染正常但 GitHub 渲染异常”的情况。比如 GitHub 默认不支持 HTML 标签内嵌样式，但 MPE 能渲染，你如果只依赖 MPE，就会出现本地漂亮、上线崩掉的尴尬。所以两个预览保留反而是一种安全网。

3. 关键配置与实践细节：让 Markdown 真正“所见即所得”

3.1 换行、表格与任务列表：在 VS Code 和 GitHub 之间找平衡

Markdown 最大的坑不在语法本身，而在不同渲染器对“换行”的处理不同。比如：

• 一行文字后面加两个空格再回车，在标准 Markdown 中是“硬换行”（即另起一行的<br>）。
• 但在 Typora 和 VS Code 的预览中，这个规则表现可能并不直观。
• 而 GitHub 风格的 Markdown（GFM）则认为一个回车就等于换行，它更宽容。

这个差异曾经给我制造过不小的麻烦：本地预览中排版足够的文档，贴到 GitHub 上段落间距完全变了。为此，我在写作规范里给自己立了条规矩：段落间使用空行分隔，而不是依赖单回车。如果你想让某个句子在视觉上强制换行且不产生新段落，建议直接用<br>标签，而不是依赖空格回车。这套规范我写进了项目仓库的README里，团队协作时大家统一执行，很少再出现渲染不一致的问题。

表格的处理上，Markdown All in One 帮了大忙。原始 Markdown 表格写起来很痛苦，列多的时候，一个|没对齐，预览和源码都对不上。我会先快速写一个粗糙的表格，不需要管对齐，然后执行格式化表格命令，它会把竖线和空格全部对齐。这是我在 VS Code 里写表格的黄金姿势。

任务列表- [ ]/- [x]在日常工作中非常实用，MPE 和官方预览都能渲染成可勾选的 checkbox。我经常用它来做文章大纲管理：开头列几个待办项，边写边勾，一篇文章写完，任务也全部清零。

3.2 代码块与高亮配置：技术文档写作的刚需

如果只是写普通文章，Markdown 的代码块语法基本够用。但我是技术博主，文章里经常出现 Python、JavaScript、Shell 代码，代码高亮和行号显示就变成刚需。

在 VS Code 里，代码块语法不依赖插件，它直接用 PrismJS 或 highlight.js 做渲染。你只要在代码块围栏后面写上语言标识，预览就会自动高亮：

```python def hello(): print("Hello, Markdown")

MPE 还支持给代码块设置行号、高亮特定行，甚至通过 `{.line-numbers}` 这种参数控制展示效果。这个能力在做代码讲解类教程时非常受用，可以让读者按行阅读代码逻辑，而不是盯着整段代码发晕。 还有个小技巧，官方预览和 MPE 都支持内联代码 `code` 的语法高亮。我会在写作中刻意遵守“代码一律用反引号包裹”的规则，避免像 Word 那样把代码当普通文本贴上去。这种“代码可识别性”对后期转 PDF 或 HTML 发布都很关键。 ### 3.3 数学公式和 Mermaid 图表：让技术文档不再局限于文字 很多 Markdown 编辑器对数学公式的支持很弱，或者需要额外配置。而 MPE 内置了 MathJax 渲染，你只需要在设置里确认 `"markdown-preview-enhanced.math"` 对应的选项是 `"katex"` 或 `"mathjax"` 即可。 书写数学公式时直接使用 TeX 语法源自习惯。比如行内公式用 `$` 包裹，独立公式用 `$$` 包裹： $$ f(x)=ax^2+bx+c $$ MPE 可以实时渲染成漂亮的数学排版。这对理工科朋友来说几乎必不可少——毕业设计、课程论文、技术专利文档，都能直接在 VS Code 里写完并导出 Word 版本，不需要再经过公式编辑器二次加工。 再来说 Mermaid 图表。传统写作中，架构图、流程图、时序图都依赖 Visio 或 ProcessOn 绘图，然后截图贴进文档。一旦后续要修改，就得回到绘图工具里操作，麻烦至极。Mermaid 的优势是用文本定义图形，你可以像写代码一样描述节点和连线，随后在预览中渲染成清晰的图表。 比如一个最简单的流程：

graph LR A[本地写作] --> B[预览检查] B --> C[生成导出/发布]

在 MPE 中，这段代码会直接渲染成一张流程图。做系统架构讲解时，我会把 Mermaid 图放进 Markdown 文档，每次改架构只需要改两三行文字，重新渲染即可，这种“文档即图表”的工作方式，让我彻底摆脱了截图和绘图工具。 ## 4. 图片路径管理与粘贴工作流：彻底告别裂图 ### 4.1 三种图片方案对比：相对路径、绝对路径、图床 图片路径是 Markdown 使用过程中最容易出问题的环节，也是 Typora 与 VS Code 场景切换时最让人头大的地方。我用一张表格把这三种方案的管理逻辑讲清楚： | 图片方案 | 优点 | 缺点 | 适用场景 | | --- | --- | --- | --- | | 相对路径（推荐） | 仓库内自包含，移动整个目录图片不丢 | 目录层级深时引用路径冗长 | Git 仓库、本地文档、静态博客 | | 绝对路径（不推荐） | 本地加载最稳定，不依赖文档位置 | 换电脑路径失效，无法分享给他人 | 纯本机个人笔记 | | 图床/CDN | 分享方便，文档体积小 | 依赖外部网络、图床可能失联 | 线上发布、协作平台分享 | 我个人强烈建议：所有正式文档全部使用相对路径。具体做法是在每个项目目录里固定一个 `assets/images` 文件夹，所有文档引用的图片都从项目根目录出发找到这个文件夹。 举例，假设我的文档结构如下：

my-blog/ ├── docs/ │ ├── vscode-markdown.md │ └── assets/ │ └── images/ │ └── markdown-logic.png

在 `vscode-markdown.md` 里引用的图片路径不是 `assets/images/markdown-logic.png`，而应该写成 `assets/images/markdown-logic.png`（相对当前文档所在目录的路径）。如果文档换到更深目录，路径前缀再加 `../`。核心原则是：**引用路径始终以文档所在目录为基准，不要以项目根目录为基准**。这样整个仓库移动到任意位置、任何电脑，图片都不会裂掉。 ### 4.2 Paste Image 实战：一键粘贴与自定义保存目录 Paste Image 插件的配置非常关键。默认情况下，它会将截图保存到当前文档同目录下的 `images/` 文件夹，并且自动生成一个文件名。这倒没什么问题，但如果你希望图片都统一放到项目级的 `assets/images/` 下，就需要在 `settings.json` 里手动改一下配置。 我个人习惯这样配置： ```json { "pasteImage.path": "${currentFileDir}/assets/images", "pasteImage.basePath": "${currentFileDir}", "pasteImage.namePrefix": "${currentFileNameWithoutExt}_", "pasteImage.insertPattern": "![${imageFileNameWithoutExt}](${imageFilePath})" }

这些配置项的含义很简单：

• pasteImage.path控制保存目录。我使用${currentFileDir}作为基准，也就是当前编辑文档所在目录，这样不同项目的 Markdown 都会有对应的图片目录，不会一股脑塞进同一个全局目录。
• pasteImage.namePrefix给生成的图片名加前缀，比如vscode-markdown_20250101.png，这样同目录下有多个文档时，图片归属一目了然。
• insertPattern控制插入语句的格式，默认的插入格式已经很好用，你基本不用改。

实际操作流程是：截图放到剪贴板 → 在 VS Code 里按Ctrl+Alt+V→ 图片自动存入指定目录 → 文档里自动出现正确的 Markdown 引用语句。整个过程不到 3 秒。这套流程，已经成为我写作中离不开的高频动作。

最后提醒一句：如果在一个跨平台协作项目中，图片文件名尽量用英文，不要用中文，因为有些服务器或老旧系统在中文路径解析上会有坑。我在项目中吃过一次亏，后来默认图片名只用日期+英文组合，再没出过类似问题。

5. 从 Markdown 到 Word/PDF：导出链路的完整部署

5.1 Pandoc 安装与配置：Markdown 转 Word 的高级玩法

写作完成之后，导出几乎是必做的事情。我主要是把 Markdown 导出为 Word 或 PDF，整理成交付文档发给同事、客户或者学校导师。这一步我用的是 Pandoc，它是这个领域的瑞士军刀。

Pandoc 单独是命令行工具，安装很简单。Windows 上可以用 winget 装：

winget install --id JohnMacFarlane.Pandoc

macOS 上则是：

brew install pandoc

装好后，配合 VS Code 里的 Markdown PDF 插件或 Pandoc 插件，就可以实现一键导出。

我推荐的导出命令非常简单：

pandoc input.md -o output.docx --toc --highlight-style=tango

--toc表示自动生成目录，--highlight-style控制代码块高亮风格。因为有 Markdown All in One 生成的目录作为锚点，导出的 Word 版目录会自动变成可点击跳转的导航。

如果你要导出 PDF，Windows 上需要配合 LaTeX 引擎。事情就会复杂不少，所以我更推荐的方案是“先用 Markdown 转 HTML，再用浏览器打印成 PDF”。MPE 里右键预览 → “Export to PDF” 就是走这条路，它无需安装庞大的 LaTeX 环境，导出的 PDF 观感也不错。

5.2 结合 Hexo/GitHub Pages 的博客发布流程

Markdown 写作的另外一大场景是发布博客。无论是用 Hexo 还是 Hugo，Markdown 都是根源稿格式。VS Code 的 Markdown 写作工作流在这里顺理成章：本地写稿 → 预览检查 →git add .→ 提交推送 → Dify 自动部署到 Pages。前后端闭环非常流畅。

这套方案的特别之处在于，你用 VS Code 写 Markdown，就等于把你整个博客工程放到了一个统一的开发环境里。你不需要再打开另一个专用编辑器，也无需切换窗口，写文章的同时还能顺手改博客主题代码、调整样式文件、修改配置项——一个环境搞定所有事。

另一个比较重磅的用法，是配合 GitHub Actions 做自动化发布。你只需要在仓库里配置一个 workflow，当 Markdown 文件提交后自动触发构建与部署，整个“内容生产→线上展示”的链路就不需要手动干预了。这也是为什么我对“部署方案”这个词情有独钟——VS Code 在这里不仅是编辑器，更是你整个内容管线的生产端。

5.3 其他导出实用场景与格式选型

有一类文档需求是 Markdown 无法直接满足的：精美的封面页、页眉页脚、严格排版等。这种时候不需要硬刚 Markdown，更聪明的解法是：在 Markdown 里完成全部文字内容和逻辑，然后通过 Pandoc 转换 + Word 模板控制样式。Pandoc 支持--reference-doc参数，你只需要提供一个 Word 模板文件，导出时会自动套用模板的字体、标题样式和页边距。

pandoc input.md -o output.docx --reference-doc=my-reference.docx

这个方式是先准备好一次 word 模板，之后每次导出的格式风格都一致，不需要每次调字体、调字号。对需要频繁交付格式统一文档的人来说，这是提升效率的隐藏大招。

另外说一个处理技巧：表格特别多的文档从 Markdown 导出 Word 后，表格宽度可能不是 100%，看起来不美观。可以在 Pandoc 导出后用 Word 的“表格工具→自动调整→根据窗口调整表格”一次性修复。如果该类调整经常需要，也可以提前写好一个 Word 宏来处理，这个就不展开讲了。

6. VS Code Markdown 编辑器部署常见问题与排查实录

6.1 预览与 GitHub 渲染不一致怎么办

这是 Markdown 用户遇到最多的问题。同一份文档，VS Code 里看着排版完美，推到 GitHub 上突然表格错位、换行失效。原因通常是本地预览使用了 MPE，而 MPE 的渲染引擎对换行、空格等处理更宽容。

排查思路分两步。第一，我把预览模式切换到官方预览（Ctrl+Shift+V），因为官方预览的渲染逻辑和 GitHub 非常接近，如果官方预览表现正常，那么 GitHub 上大概率也正常。第二，检查文档中是否有依赖“单回车”产生换行的段落，尽量改为“空行分段”或显式<br>标签。

如果你有大量历史文档需要批量校正，可以写一个简单的正则替换：把段落之间单回车替换为空行回车。这个操作我用 Python 脚本批量处理过，处理后再用官方预览复查一遍。

6.2 图片路径显示成裂图怎么办

图片裂图是新手最常见的问题。我看到过太多“本地好好的，发给别人就裂了”的案例。排查路径很固定：

1. 检查引用语法是否规范：![描述](相对路径.png)。
2. 检查路径基准：务必是从当前文档所在目录出发的相对路径。
3. 检查文件名大小写：Linux 服务器对大小写敏感，而 Windows/macOS 本地可能不敏感。
4. 检查是否真的使用了图床外链，外部图床可能被防火墙拦截。

还有一种情况比较隐蔽：插入了图片，但图片文件尚未保存，或者被移动了。比如我用 Paste Image 之后，突然清理文件夹时把assets/images/误删，预览立刻崩。所以我会在项目根目录下养成长久习惯：图片一律按时归档，每次写文前先检查图片目录是否存在。

6.3 复制粘贴代码到预览里中文乱码

这个问题在导出 PDF 时特别明显。通常是因为代码块中混有中文字符，而导出的 PDF 字体不支持中文。解决方案有两个：

• 在使用 Pandoc 导出 PDF 时，指定支持中文字体，例如-V CJKmainfont="Noto Sans CJK SC"。
• 使用 MPE 浏览器导出方式时，在预览样式里增加font-family设置，推荐在 Custom CSS 中加入：

.markdown-preview-enhanced code { font-family: "Sarasa Mono SC", "JetBrains Mono", "Noto Sans Mono CJK SC", monospace; }

这种代码块中英混排时的字体适配问题，是所有 Markdown 编辑器都会遇到的，提前配置好可以避免很多返工。

6.4 Mermaid 图表不渲染的解决办法

MPE 通常能直接渲染 Mermaid，但如果你在“官方预览”中查看，图表不会渲染，只会看到一段代码。这是因为官方预览没有调用 Mermaid.js。解决办法是在官方预览中使用 Markdown Preview Mermaid Support 插件。该插件会在官方预览的 HTML 中注入 Mermaid 引擎，再刷新预览即可。

如果 MPE 和官方预览都不渲染，大概率是 Mermaid 语法错误。比如节点 ID 不能包含中文字符，连线语法必须严格使用-->或---。遇到这种问题时，我建议先去 Mermaid Live Editor 在线编辑器粘贴代码试渲染，等确认语法无误后，再回 VS Code 里看。这个方法能快速分离“插件问题”和“语法问题”。

6.5 插件冲突与快捷键失效的排查思路

VS Code 装了多个 Markdown 相关插件后，可能出现快捷键冲突或预览右键菜单被顶掉的情况。常见冲突对象包括 Markdown All in One、Markdown Preview Enhanced、Markdown Shortcuts 等。

排查快捷键问题很简单：打开Ctrl+Shift+P输入Preferences: Open Keyboard Shortcuts，在搜索框输入你期待的快捷键，比如markdown，就能看到当前有哪些命令占用和冲突。你可以直接用右上角的“编辑器”图标手动改键位，或关掉一个冲突插件的快捷键。

另外，有些旧版插件停止了维护，会和新版 VS Code 存在兼容问题。如果某个插件超过一年没有更新，请谨慎安装，这可能成为莫名其妙报错的源头。我通常只在 VS Code 扩展市场搜索插件时关注“下载量”和“最近更新日期”，双管齐下，基本不会踩雷。

7. 这套方案用起来到底什么体验

最后分享几个我实际使用这套方案时的真实体会。

这套由 VS Code 配合 Markdown All in One、Markdown Preview Enhanced、Paste Image 和 Pandoc 组成的部署方案，已经在我所有写作场景里稳定运行了大半年。无论是一两百字的朋友圈小记，还是上万字的系统设计文档，又或者需要频繁更新配图的博客草稿，我都用它完成。最大的感受是“不再有工具感”，你不会在写作过程中被“怎么插图片”“怎么调格式”“怎么导出”打断，写完了按一下快捷键，成果直接出来。

如果你是一个重度笔记用户，完全不考虑代码场景，那 Markdown All in One 和 MPE 这套组合可能对你来说还是稍微偏“极客”了，学习成本略高。但如果你本身是开发者、技术博主、论文写作者，或者日常就要跟 Git 和 CI/CD 打交道，那这套方案就是顺理成章的选择——把一个日常工具无缝嵌入你已经熟悉的工作流里，而不需要额外维护另一套软件生态。

最后再分享一个我优化过的小细节：在settings.json里把 MPE 预览的默认主题设为github-light.css。因为最终文档大多发布在 GitHub 或者类 GitHub 风格的平台上，提前在写作阶段就用目标平台的主题预览，基本可以保证“所见即所得”的最大化。这个小细节谁用谁知道，省掉了很多发布后修正排版的时间。