Markdown 还是纯文本：如何选择交接格式

模型输出是 Markdown，但它要落到的那个位置 —— 一封邮件、一个表单、一个工单系统 —— 通常只吃纯文本。反过来，你自己的文档是 Markdown，却要粘进一个只认 HTML 的 CMS。两个方向都不该需要一个构建步骤。

Markdown 转纯文本比看起来难

直觉上这是「去掉几个符号」，实际上难点在链接。

一段 **重要** 去掉星号就完事了，但 [文档](https://example.com) 的两种天真处理都不对：只留标签会丢掉信息，整段保留又会把 URL 和括号一起塞进正文。合理的做法是保留标签、丢弃地址 —— 因为纯文本的读者没法点击，而地址在句式里通常很碍事。

同样容易出错的还有列表：把 - 去掉之后，列表看起来变成了段落，但如果保留缩进与前缀，读者仍能一眼看出这是列表。纯文本并不意味着放弃结构，而是用字符而不是样式来表达结构。

转 HTML 的风险在另一侧

反方向的问题不是丢失，而是注入。把原始 HTML 直接透传给一个 Markdown 转换器，是众所周知的风险点：源文本里的 <script> 会被原样输出到目标页面。

所以转 HTML 的正确默认值是转义行内 HTML，只输出转换器自己生成的标签。这样得到的产物应该被当作文本输入，而不是可信标记 —— 这条边界要在工具说明里写清楚，而不是靠使用者猜。

表格是两边的试金石

如果只想验证一个转换器值不值得用，拿表格试就够了。Markdown 转换器是个可参考的实现：转义竖线和两个输出方向都覆盖到了。

Markdown 表格的分隔行是一串 - 与 |，而单元格内容里也可能出现 |。天真的实现会按 | 切分整行，于是内容里的竖线把表切歪。稳妥的做法是逐字符判断分隔行，并在切分时跳过转义过的竖线。

纯文本方向同理：是把表格拆成段落，还是保留为对齐的文本块，取决于下游读者是谁。

别让格式变成一个决策点

最后一个建议与工具无关：不要让「该用哪种格式」每次都成为一次判断。

给流程定一条默认规则 —— 面向机器的一律纯文本，面向渲染页面的一律 HTML —— 然后让转换工具去承担中间的搬运。格式选择一旦变成每次都要重新决定的事，它就会在某个忙碌的日子被跳过，而代价通常是一个星期后才发现。

选格式的标准是「下游能不能直接吃」。往下游的能力靠，而不是往上游的偏好靠 —— 剩下的转换交给工具，不要让格式成为流程里的一个决策点。