判断 Markdown 写作是否合格，优先看它在不渲染时是否仍然层次清楚、重点明确。渲染不是补救手段，纯文本可读性本身就是语法的一部分。Markdown 最适合技术文档、说明、笔记、评论和静态页面正文，不适合需要精确分页、复杂图文混排或法定公文格式的场景。写作时遵守两条底线：不要用连续空格或 Tab 模拟缩进；段落之间用空行分隔，不要依赖单次换行。以下按常用元素给出判断标准与写法建议。 一、标题与

用 Markdown 写 RP 类内容，核心不是“用什么符号最好看”，而是规则是否稳定。旁白、动作、对话只要各自固定写法，读者就能快速扫读；如果符号混用，标记越多反而越乱。建议在文档开头用一两行说明规则，之后不再改变。 一、先确定角色标识 多人 RP 或跑团日志中，角色标识必须全篇一致。推荐做法是：对话固定使用“角色名：”开头，角色名用粗体；动作固定使用方括号或斜体；旁白不使用任何前缀。 适合场景

判断一个文档是否适合用 Markdown，先看两个条件：内容是否以结构化文字为主，是否需要长期纯文本维护和版本对比。只要满足这两点，Markdown 通常比可视化排版更稳定；如果涉及严格分页、精确印刷或复杂批注，则应改用专用排版工具。 标题与段落 标题用 `#` 表示，数量对应级别：`#` 一级、`##` 二级、`###` 三级。一个文档通常只保留一个一级标题，正文分节从二级标题开始，层级不要跳跃

判断 Markdown 语法是否“能用”，先确认目标平台遵循 CommonMark 还是 GitHub Flavored Markdown（GFM）。日常写作优先掌握五类语法：块级结构、行内强调、列表与任务、链接图片、代码表格。其余扩展语法只应在平台支持时使用，否则宁可改写为普通段落或表格。 一、块级语法：先搭骨架，再填内容 块级语法决定文章结构和可扫读性。最常用的是标题、段落、引用、分隔线。标题

Markdown 没有单一“官方完整版”，实用中应以 CommonMark 作为兼容基线，把 GFM（GitHub Flavored Markdown）作为常用扩展。判断一份 Markdown 是否合格，先看三点：块级元素是否用空行分隔、行内与块级符号后是否留空格、扩展语法是否在目标平台受支持。满足这三条，即可避免大多数解析不一致问题。 一、块级结构：标题、段落、列表与引用 标题从 `#` 到 `

Markdown 的核心价值在于用最少标记表达结构化文本，适合文档、笔记、评论和 README。判断标准很直接：如果内容以标题、段落、列表、代码、链接和表格为主，且需要纯文本可读、版本可比较，优先使用 Markdown；如果需要精确分页、多栏排版或公文格式，应改用排版工具。 块级结构：标题、段落与引用 标题使用 `#` 至 `######`，一个文档通常只保留一个一级标题。建议从二级标题开始分节，

选择 Markdown 软件，优先确认三个硬指标：渲染是否遵循 CommonMark/GFM 标准、导出是否能直接用于最终交付、编辑过程是否减少格式打断。功能多但方言不一致的软件，最终会把时间花在修正渲染差异上。 一、先确认语法方言 Markdown 没有唯一标准。CommonMark 是基础规范，GFM（GitHub Flavored Markdown）在其上增加表格、任务列表、删除线、自动链接

判断标准：一份 Markdown 是否可维护，取决于是否区分 CommonMark 基础语法与 GFM 扩展语法。日常写作建议以 CommonMark 为底线，只有在 GitHub、GitLab、Notion 等明确支持 GFM 的环境，才使用表格、任务列表、删除线等扩展。 一、标题与段落 标题用 `#` 到 `######`。一篇文档通常只保留一个一级标题，正文内从二级标题开始，不要跳级。段落间

判断 Markdown 是否适合当前文档，可以看三个条件：内容是否以文本为主、是否需要长期可读、是否会被多人编辑或版本管理。只要满足其中两项，使用 Markdown 通常比二进制格式和排版工具更稳。Markdown 的价值不在视觉装饰，而在结构稳定、可转换、可 diff。 一、先确定方言：CommonMark 还是 GFM 写作前先明确渲染环境。GitHub、GitLab、多数代码托管平台和 VS

判断一份 Markdown 文档是否合格，可以看两条：在纯文本状态下是否易读；渲染后是否层次清楚、不产生歧义。日常写作优先使用 CommonMark 核心语法；需要表格、任务列表、删除线时，再使用 GitHub Flavored Markdown（GFM）扩展。以下按使用频率组织。 标题与段落 标题用 `#` 至 `######`，一级标题通常一个文档只出现一次。不要跳级：如果上一级是 `##`，