这是审稿交付流程，还是内容提取请求？
如果目标是抽取正文或清洗任意 HTML 以便复用，应改走 `html-content-extraction-cleanup-and-delivery`。只有结果必须是审稿件或邮件交付工件时，才留在这里。
Elysia Tools
导航
Workflow Playbook
HTML 邮件审稿与 PDF 交付
检查 HTML 邮件元标签、关键属性和图片引用，在需要时生成便于审稿的简化副本，并输出可分享的 PDF 校样。
专题
Elysia Tools
导航
Workflow Playbook
检查 HTML 邮件元标签、关键属性和图片引用，在需要时生成便于审稿的简化副本，并输出可分享的 PDF 校样。
专题
如果把 html-convert 写成泛化的 HTML 转换，它就会与现有的通用提取和清洗流程重叠。这个 slug 真正还能成立的前提，是只服务于审稿和交付场景：拿到利益相关方要审批的 HTML 邮件或活动片段，检查会影响审批的元数据和脆弱属性，再把它转成可携带、可归档、可跨团队传阅的校样工件。
很多问题不会出现在静态截图里。元标签能暴露标题、预览文案、社交分享文本甚至 canonical 假设；属性提取能帮助发现跳转目标、图片替代文本、尺寸、跟踪钩子等细节，这些内容常常决定合规、品牌或 QA 是否放行。图片来源提取同样重要，因为校样 PDF 看起来正确，不代表底层引用资源就指向了正确环境。
营销邮件经常带有表格布局、内联样式和供应商模板片段，直接审读很痛苦。这时可以先转成 Markdown，把真正的文案结构和 CTA 关系抽出来，再按需要回生成为简化 HTML 审稿副本。这样做的目的是降低阅读成本，而不是把原始复杂性“洗掉”后声称源文件本来就清晰。
最后一步不是机械导出 PDF，而是按审批问题选择渲染路径。若设计保真最关键，就用更接近浏览器排版的 html-to-pdf-precise；若组织长期用办公软件链路归档 HTML 邮件校样，就走 libreoffice-html-mail-to-pdf 并明确标注。最终交付包应让审稿人一眼看明白：哪些内容来自原始 HTML，哪些被简化过，以及哪些风险仍需在真实收件箱测试里继续验证。
工作流指南
先提取标题、类似摘要的元信息、canonical 提示、社交标签以及关键元素属性，让审稿依据来自真实文档信号，而不只是截图。
列出所有图片来源，再单独做一次非关键标签剥离，观察邮件在去掉噪声后是否仍保留合规文案、CTA 文案和审稿所需层次。
当原始邮件 HTML 过于脆弱或模板噪声过重时，先转成 Markdown 供编辑审读，再回生成为简化 HTML 校样，帮助非技术审稿人确认内容。
根据验收目标输出可分享的 PDF 校样，并清楚标注该文件更接近浏览器保真渲染，还是办公软件式的邮件转档结果。
如果目标是抽取正文或清洗任意 HTML 以便复用，应改走 `html-content-extraction-cleanup-and-delivery`。只有结果必须是审稿件或邮件交付工件时，才留在这里。
当间距、首图和页脚位置影响审批时，优先走 PDF 校样；只有在原始 HTML 过于噪杂、但允许以可读性优先时，才使用 Markdown 往返生成简化副本。
如果更在意浏览器式布局保真，用 `html-to-pdf-precise`；如果团队的归档或交接更偏向办公软件的邮件转档路径，用 `libreoffice-html-mail-to-pdf`。