模型输出的 Markdown 表格含竖线，怎样避免单元格被拆成多列

模型给出的字段值包含 A|B，直接拼进 Markdown 表格会被拆成两列。把它放进反引号也不能当然解决：表格扩展先识别列分隔，代码跨度内的竖线仍需按 GFM 规则处理。最稳的做法是保留结构化原数据，再用确定性函数生成展示。

数据层与显示层分开

附件原始 JSON 包含普通竖线、代码片段竖线和多行备注三种值。表格固定两列，第一列名称，第二列值。生成器对文本里的反斜杠和竖线按合同转义，代码单元格保留反引号包围但仍处理竖线；本例不允许输入自己携带任意 Markdown 结构。

多行备注采用可见分隔符“／”折叠到同一物理行，原始换行仍完整保留在 JSON。这个展示选择会改变视觉形式，因此不能把渲染文本重新当作事实数据存储。需要真实换行时可制定受控 HTML 或其他展示合同，再独立验证，不把物理换行直接塞进单行表格。

解析结果才知道列数

只数源文本竖线没有用，因为转义分隔符和真实分隔符不同。检查器使用 Markdown 解析器的 table 扩展，读取生成的表格节点，再核对每行单元格数量与文本。普通竖线显示为一个字符，代码内容保留原来的管道字符，多行备注显示为约定折叠结果。

附件还生成一个没有转义的反例，解析后值被拆分或截断，预期文本无法与参考结果一致。这能证明检查的不是“文件里有表格”而是原值正确呈现。所用解析器版本保存在运行结果，其他渲染器的行为仍应按目标环境补验。

转义函数也需要边界

如果单元格允许任意反引号、HTML、链接和复杂内联语法，就不能继续套一个只处理竖线的小函数。本例对代码样本使用固定无反引号内容，对普通文本中的特殊字符做受限处理。扩展输入范围时必须补充样本和解析断言，不能宣传为通用 Markdown 清洗器。

失败反例是先把模型输出的整张表格当字符串替换，无法知道哪些竖线原本是分隔符，哪些属于数据。应该从 JSON 单元格值出发生成，避免在混合语法里猜结构。表头与数据列数也应事先固定，缺值和多值应在生成前拒绝。

GFM 规范是表格分隔与转义规则的一手依据。本文没有调用模型，没有测试任意网页渲染器，也没有把表格显示正确当作内容真实。离线通过只表明这三个合成字段在指定解析器中保持两列和预期文本，原始 JSON 仍可用于后续导出与核查。

配套文件与依据

本文的合成输入和参考结果可下载独立样本 a044.json，离线检查器 a044.py与样本放在同一目录后运行。检查器不调用模型接口。 使用 Python 3.12 或兼容版本，将上述文件下载到同一目录，执行 python a044.py。 此项依赖 markdown-it-py，并启用其 table 扩展；本次实际版本记录在检查结果中。

一手资料1。资料核对日期：2026-10-24。