如何清理 AI 输出中的 Markdown，又不破坏正文结构

AI 回答为什么会带客套话与格式噪音

聊天助手面向对话优化，因此常在回答前确认需求，并在结尾主动提供下一步帮助。Prompt 示例可能要求标题或 Markdown 围栏，一些界面也会为了方便复制，把整份文档包进代码块，即使目标位置真正需要的是普通富文本。

“噪音”取决于场景。“当然可以，以下是结果”放在正式文章中多余，但在客服回复里可能合理。包住整篇 Markdown 的三反引号可能只是传输外壳，而围住 JavaScript 示例的反引号却是正文的一部分。因此规则应当保守，并且必须提供清理前后预览。

先区分哪些该删，哪些应该保留

可以先把格式分为四组：对话包装、整篇容器围栏、空白噪音和有意义的正文结构。前三类通常可以自动规范，第四类默认应保留，除非目标系统明确只接受纯文本。

保守的五步清理流程

第一，保留原文，不要直接覆盖唯一副本。第二，统一换行符，让 Windows 与 Unix 文本按同一规则处理。第三，只在文档边界删除已知的开场和收尾客套话。第四，仅当代码围栏包住整份回答时移除外层围栏。第五，压缩连续空行，并在复制前对照结果。

转换顺序应保持可预测。先 trim 再判断边界可以简化匹配；但还没理解文档结构就删除全部三反引号，会破坏正文中的真实代码。如果目标要求 JSON，应把 JSON 字符串转义作为独立的最后一步，而不是把它混同为 Markdown 清理。

• 结果确认前始终保留原始输入。
• 把 CRLF 和 CR 换行统一为 LF。
• 只匹配文档边界的保守短语，不删除正文中所有礼貌用语。
• 区分整篇外壳与正文内部代码围栏。
• 复制前检查标题、列表、链接和代码。

清理前后示例应该怎么看

一篇被包装的文章可能以“当然可以，以下是你需要的指南”开头，下一行是 ```markdown，之后才是 H1 与各个章节，末尾再出现结束围栏和“希望对你有帮助”。保守清理只删除首尾客套行与最外层两个围栏，H1、段落、列表和链接保持原样。

编程教程则不同。正文里如果存在 ```js、可执行代码和结束围栏，这些标记用于表达语法与边界。“删除所有围栏”会把示例抹平。只有目标是纯文本字段，或者已经确认所有围栏都只是外层包装时，才应启用这种更强的选项。

根据目标位置选择清理规则

Markdown CMS 通常应该保留标题、链接、列表和代码围栏。富文本编辑器可能把 Markdown 当作普通字符，此时使用纯文本粘贴或编辑器自己的转换功能更合适。表格单元格常需要压缩换行，而 JSON 字段则必须正确处理引号、反斜杠和控制字符。

邮件、客服系统、社交平台和代码仓库的限制各不相同，不要把一个激进预设用于所有位置。为每种目标定义一个小型预设，记录它会改变什么，并用嵌套列表、URL、表格、中文和代码样本测试。

让自动清理可以测试和撤销

删除客套话、移除围栏、压缩空行和 JSON 转义应做成互相独立的开关，每个开关只完成一件容易理解的事情。预览让用户及时发现结构丢失。批量流程还应准备干净文本、外层包装 Markdown、真实代码块、多语言内容以及正文中刻意使用礼貌表达的测试样本。

避免使用“删除第一个标题之前全部内容”或“删除最后一句之后全部内容”这类宽泛规则，它们可能误删合法导语、引用与结论。锚定文档边界的模式和小型已知短语列表更容易验证。规则无法确定时，默认保留原文，把决定交给用户。

• 每个选项只执行一种清晰转换。
• 对已清理结果再次执行时不应持续改变内容。
• 无法识别的内容默认保留。
• 测试必须包含多语言和代码密集样本。
• 本地处理足够时，不要为了格式清理上传敏感草稿。

发布前的最终质量检查

阅读首尾段落，扫描所有标题层级，检查列表展开、重要链接和代码缩进，确认引号和撇号没有意外改变。结构化数据应实际解析，不能只靠肉眼；文章发布则应检查最终渲染页面，而不只是编辑器源码。

RunAIToolkit 在浏览器本地完成转换，并排展示输入和结果。先使用保守选项，观察差异，只有目标位置明确要求时再启用破坏性更强的规则。本地处理也避免为了简单格式任务上传尚未发布的草稿。

常见问题