Markdown、HTML 和 PPT 如何稳定交付真正困难的通常不是完成一次 API 调用而是让结果可以校验、失败可以定位、后续能够回到原始证据。本文围绕“如何把 Markdown、HTML 和 PPT 转换任务设计成可重试、可验收的文档交付流水线”给出一套可以直接落到任务状态和数据契约上的实现方式。问题与结果源文件、转换参数、产物哈希和交付状态统一记录失败重试不会产生无法区分的重复文件。最终交付不是一段不可追溯的模型回答而是一组带来源、版本、状态和失败记录的数据。这样既方便接入后续系统也能在接口、页面或模型输出变化时定位问题。适用场景技术文档批量导出运营内容生成 PDF 或 Word演示文稿归档和图片化实现前先确定边界输入文件与转换参数共同决定幂等键转换成功后还要校验文件类型、大小和页数交付记录只能引用已验收产物可验证工作流API 编排与职责输入或目标接口请求方式用途Markdown 到 PDFMarkdown 转 PDFPOST把技术文档、周报、说明页导出为 PDFHTML 到 PDFHTML/URL 转 PDFPOST把网页或 HTML 内容导出为 PDFHTML 到 WordHTML 转 WordPOST生成可编辑 Word 文档PPT 到 PDFPPT 转高精度 PDFPOST生成演示材料归档版本PPT 到图片PPT 转高精度图片POST生成封面图、缩略图或预览图最小可运行实现curl -X POST https://api.gugudata.com/imagerecognition/markdown2pdf \ -H Content-Type: application/json \ -d { appkey: YOUR_APPKEY, content: # 发布草稿\n\n这是一篇准备导出的技术文章。 }curl -X POST https://api.gugudata.com/imagerecognition/ppt-to-pdf?appkeyYOUR_APPKEY \ -F file./deck.pptxcurl -X POST https://api.gugudata.com/imagerecognition/ppt-to-images?appkeyYOUR_APPKEYscale_factor2 \ -F file./deck.pptx应用侧可以按目标格式选择接口def choose_conversion_endpoint(source_type: str, target_type: str) - str: Choose a document conversion endpoint. if source_type markdown and target_type pdf: return https://api.gugudata.com/imagerecognition/markdown2pdf if source_type ppt and target_type pdf: return https://api.gugudata.com/imagerecognition/ppt-to-pdf if source_type ppt and target_type images: return https://api.gugudata.com/imagerecognition/ppt-to-images raise ValueError(Unsupported conversion target)发布记录结构字段说明source_id原始内容 IDsource_typeMarkdown、HTML、URL 或 PPTtarget_typePDF、Word、图片等目标格式output_url转换结果地址或文件记录generated_at转换时间publish_status待审核、已发布或失败失败分类与降级文件格式错误、文件过大或转换失败时Agent 应停止发布流程并把失败原因写入发布记录。对于重复发布任务建议用source_id target_type做幂等控制避免同一篇内容生成多个冲突版本。工程化注意事项转换任务适合放到后台队列避免用户请求长时间等待。发布页面只展示业务结果例如下载链接、预览图和更新时间。APPKEY 保存在服务端不要放进 Markdown 文件或前端代码。对输出文件设置访问权限和过期策略避免内部资料被误公开。数据契约与留痕建议至少保存以下字段真实项目可以继续拆分但不要删除来源、版本和状态信息。字段作用job_id稳定业务标识用于关联记录并避免名称冲突input_hash内容哈希用于完整性校验、版本识别和去重conversion_type规则、输入或产物版本变更时保留旧版本options业务数据字段保存时记录来源、口径和缺失状态output_hash内容哈希用于完整性校验、版本识别和去重page_count业务数据字段保存时记录来源、口径和缺失状态delivery_status显式状态或结果禁止用空值代替失败所有派生结果都应带生成时间和输入版本。发生重试时新增尝试记录不要覆盖最后一次失败以免排查时只剩“最终成功”而看不到中间问题。验收清单重复请求不会覆盖不同版本空文件和错误 MIME 类型会被拒绝产物可追溯到源文件和参数能力边界格式转换不保证复杂排版、字体和交互元素完全一致关键文档仍需要视觉验收。示例中的YOUR_APPKEY仅为占位符。真实密钥只能放在服务端环境变量或密钥管理系统中不应进入前端、文章、日志或版本库。