AI 技能【免费下载链接】anydocConvert Word, PowerPoint, Excel, OpenDocument, RTF, EPUB, CSV, and PDF to clean Markdown. Built in Rust, with Node.js and Python bindings.项目地址https://gitcode.com/gh_mirrors/any/anydoc点击查看免费下载本指南以 anydoc 官方 Agent Skillskills/convert-documents-to-markdown/SKILL.md为骨架系统讲解如何用anydocCLI 将 Word、PowerPoint、Excel、OpenDocument、RTF、EPUB、CSV 与 PDF 一键转换为 GitHub Flavored Markdown并深入源码层剖析格式内容识别、退出码约定、错误模型与 Node/Python/Rust 库 API。读完你将掌握在 Agent 工作流、批处理脚本与编程项目中稳定调用 anydoc 的完整方法并理解其按内容识别格式、统一渲染模型的底层设计。一、Skill 是什么让 Agent 直接读懂任何文档anydoc 以 Agent Skill 形式随仓库发布即 skills/convert-documents-to-markdown/SKILL.md。它的定位非常明确当任务需要读取一个无法直接阅读的办公文档、电子表格、演示文稿、电子书或 PDF 的内容时Agent 应运行 anydoc CLI 完成转换。该 Skill 的 frontmatter 声明了触发条件description字段输入范围Word.doc、.docx、PowerPoint.ppt、.pptx、Excel.xls、.xlsx、OpenDocument.odt、.ods、.odp、RTF、EPUB、CSV、PDF输出格式GitHub-Flavored MarkdownGFM适用场景Agent 无法直接读取二进制文档内容的任何任务。在 README.md 的 Agent skill 一节中安装方式只需一条命令npx skills add firecrawl/anydoc安装后即可用于 Claude Code、Codex、Cursor、OpenCode 等兼容 Agent。Skill 的存在意味着Agent 不需要额外配置环境——CLI 通过npx按需运行首次使用自动下载预编译二进制无需手动安装。二、CLI 快速上手三种调用形态Skill 给出的核心调用方式共有三种对应 node/cli.js 中的参数解析逻辑npx -y firecrawl/anydoc file # Markdown 输出到 stdout npx -y firecrawl/anydoc file -o out.md # 写入文件 npx -y firecrawl/anydoc - --format csv f # 从 stdin 读取三种形态分别解决三类需求形态命令适用场景标准输出npx -y firecrawl/anydoc report.docx快速预览、管道处理写入文件npx -y firecrawl/anydoc slides.pptx -o slides.md大文档、需要落盘标准输入npx -y firecrawl/anydoc - --format csv data.csv流式处理、无临时文件环境前提CLI 需要 Node 20无需安装npx -y自动拉取。这一约束在 node/package.json 的engines字段中明确写死为node: 20且bin字段将anydoc命令映射到 node/cli.js。-y参数用于跳过 npx 的交互确认这也与 Skill 中CLI 永不提示The CLI never prompts的约定一致——它天然适合无人值守的 Agent 调用。2.1 完整命令行选项从 node/cli.js 的HELP文本可以看出CLI 共支持四个选项Usage: anydoc file [options] anydoc - [options] file Options: -o, --output path Write the Markdown to path instead of stdout -f, --format format Name the input format instead of detecting it: doc, docx, odt, pdf, ppt, pptx, rtf, epub, xlsx, ods, odp, csv (extension aliases like xls, docm, ppsx resolve to these) -h, --help Print this help and exit -V, --version Print the version and exit几个值得注意的细节--format接受 12 个基准格式名但扩展名别名如xls、docm、ppsx会被解析到对应基准格式。在源码中这通过formatFromExtension实现见 src/lib.rs 的Format::from_extensiondocx/docm归入Docxppt/pps/pot归入Pptpptx/pptm/ppsx/ppsm归入Pptxxlsx/xlsm/xlsb/xls统一归入Excel-作为输入表示从 stdin 读取。若 stdin 是终端TTYCLI 会直接以用法错误退出stdin is a terminal; pipe or redirect a document into anydoc -每次调用只能转换一个文档传入第二个输入会报错 one document per invocation管道下游提前关闭如anydoc big.xlsx | head触发EPIPE时按成功处理不算转换失败——这是批处理管道设计上的贴心细节。2.2 一个文档、一次调用SKILL 明确每次调用只处理一个文件。批量场景如一个目录下 100 个文档应在外层循环中逐次调用而非试图一次传入多个文件。这符合 CLI 简单、可预测、永不提示的设计哲学。三、六大规则逐条精解Skill 的规则部分是整个文档的核心下面逐条展开并结合源码验证。规则 1支持的输入格式支持的扩展名全集如下与 README.md 的 Supported formats 表格一致格式族扩展名Word.doc、.docx、.docmPowerPoint.ppt、.pps、.pot、.pptx、.pptm、.ppsx、.ppsmExcel.xls、.xlsx、.xlsm、.xlsbOpenDocument.odt、.ods、.odpRich Text Format.rtfEPUB.epubCSV.csvPDF.pdf注意这里的两点细节其一Format枚举src/lib.rs实际只有 11 个成员多个容器变体共享同一个解析器——例如.docm与.docx都走Docx解析器.xlsb与.xls都走Excelcalamine解析器其二.docm、.xlsm、.pptm等宏启用格式同样支持因为检测基于内容而非扩展名。规则 2格式从文件内容识别而非扩展名这是 anydoc 最核心的设计。SKILL 原文The format is detected from the file content. Pass--format nameonly when detection cannot work: CSV from stdin, or a missing or wrong extension.即默认不传--format格式由内容自动识别只有两种例外才需要显式指定CSV 来自 stdinstdin 没有扩展名而 CSV 本身没有签名见下扩展名缺失或错误作为兜底手段。内容识别的完整实现位于 src/formats/detect.rs其from_bytes函数按签名逐级判断pub(crate) fn from_bytes(bytes: [u8]) - OptionFormat { if bytes.starts_with(b{\\rtf) { return Some(Format::Rtf); } if bytes.starts_with(OLE_MAGIC) { // 0xD0 0xCF 0x11 0xE0 0xA1 0xB1 0x1A 0xE1 return detect_ole(bytes); } if bytes.starts_with(bPK\x03\x04) { // ZIP 本地文件头 return detect_zip(bytes); } if bytes[..bytes.len().min(1024)].windows(5).any(|w| w b%PDF-) { return Some(Format::Pdf); } None }识别依据是各规范自身指定的容器标识而非对文档内容的启发式猜测PDF%PDF-头ISO 32000。实现上允许头部前有最多 1024 字节的前导垃圾部分生产者的做法并有对应测试signatures验证RTF每个 RTF 文件必须由{\rtf开组起始OLE 复合文件二进制 Office先匹配 CFB 签名再按 [MS-DOC]WordDocument、[MS-PPT]PowerPoint Document、[MS-XLS]Workbook/Book等强制流名区分.doc/.ppt/.xls。流名比较不区分大小写兼容WORKBOOK、BOOK等生产者变体测试ole_streams_designate_the_binary_format验证了这一点值得注意的是加密的 OOXML 包含EncryptedPackage流会返回None让上层精确报告EncryptedZIP 包OOXML/ODF/EPUB先看mimetype部件ODF/EPUB 的身份标识再看 OPC 的officeDocument关系指向的主部件内容类型内容类型失效时退回主部件强制根元素w:document、p:presentation、workbook再退回约定俗成的路径word/document.xml等最后退回 ODF 的META-INF/manifest.xml与 EPUB 的META-INF/container.xml。测试opc_stale_content_types_defer_to_the_root_element专门验证了内容类型过时场景下根元素的裁决权CSV纯文本、无签名永远不会被内容识别必须靠扩展名或显式--format。这套签名优先、层层回退的策略带来一个实际收益扩展名写错的文档依然能正确转换只要内容完好README 中将其表述为 mislabeled files still convert correctly。检测永不报错无法识别或含混的容器一律返回None由调用方回退到扩展名Format::from_extension再不行就报Unsupported。三个 API 面Rust/Node/Python均暴露了from_bytes/from_extension/from_path三个检测函数。规则 3退出码约定——批处理脚本的契约SKILL 定义了三个退出码退出码含义0成功1文档无法转换读取或转换失败2用法错误未知选项、缺少输入、非法--format失败时向stderr打印恰好一行anydoc: messagenode/cli.js 的fail函数process.stderr.write(\anydoc: ${message}\n)。CLI 永不提示never prompts因此完全适合在无人值守的 Agent 或 CI 管道中调用脚本只需检查退出码即可区分文档有问题与命令用错了。规则 4大文档务必用-o写文件SKILL 原文For a large document, write to a file with-oand read the parts you need instead of streaming everything into context.对于数百页的文档直接把全部 Markdown 灌进 LLM 上下文既不经济也不必要。正确姿势是npx -y firecrawl/anydoc big-report.docx -o big-report.md # 然后按需读取 big-report.md 的特定章节这对 Agent 尤其重要转换结果落盘后可以分段读取、按标题定位、只取需要的部分避免上下文爆炸。这也是 node/cli.js 中-o/--output选项存在的意义。规则 5扫描版 PDF 需要 OCR——anydoc 不做SKILL 原文Scanned and image-only PDFs need OCR, which anydoc does not do; they fail as unsupported.这是需要明确认知的能力边界anydoc 内置的 PDF 支持通过 pdf-inspector 转换只覆盖文本型 PDF纯扫描件/纯图片 PDF 会以Unsupported错误失败src/lib.rs 中Format::Pdf的文档注释明确指出 Scanned/image-only PDFs (needing OCR) error as unsupported且to_document对 PDF 不支持——PDF 直接产 Markdown不经文档模型。此类文件需要交给托管服务如 Firecrawl Parse 的 OCR 模型处理README 对此有明确说明。规则 6代码库内优先用库 API而非 shell 调用在 Node、Python 或 Rust 代码库中应优先使用库 API 而不是 shell out语言包名APINode.jsfirecrawl/anydocnpmtoMarkdown/toDocument/toMarkdownBytesPythonfirecrawl-anydocPyPI导入名anydocto_markdown/to_document/to_markdown_bytesRustanydoccrates.ioto_markdown/to_document/to_markdown_bytes三语言暴露同一套to_markdown/toMarkdown语义。详细用法见 node/README.md 与 python/README.md。四、三种语言库 API 详解4.1 Node.jsnpm install firecrawl/anydocimport { toDocument, toMarkdown, toMarkdownBytes } from firecrawl/anydoc; // 从文件路径格式自动从内容检测扩展名兜底 const markdown await toMarkdown(report.docx); // 从字节格式从内容检测 const fromBytes await toMarkdownBytes(bytes); // 或显式指定格式无签名的 CSV 必须如此 const fromCsv await toMarkdownBytes(bytes, csv); // 或停在文档模型携带内嵌资源 const document await toDocument(bytes);三个 API 的分工很清晰toMarkdown(path)面向文件路径toMarkdownBytes(bytes, format?)面向内存字节toDocument(bytes)停在共享文档模型——除 Markdown 外还能拿到内嵌资源document.assets带媒体类型与来源部件。转换在 libuv 线程池执行不会阻塞事件循环见 node/README.md且包内附带 TypeScript 类型node/index.d.ts。4.2 Pythonpip install firecrawl-anydocimport anydoc # 从文件路径 markdown anydoc.to_markdown(report.docx) # 从字节格式自动检测 markdown anydoc.to_markdown_bytes(data) # 或显式指定格式CSV 需要 markdown anydoc.to_markdown_bytes(data, csv) # 或停在文档模型 document anydoc.to_document(data)Python 侧转换期间释放 GIL其他线程可继续运行包附带类型桩python/anydoc/_anydoc.pyi。安装包名为firecrawl-anydoc导入名却是anydoc两者不要混淆。4.3 Rustcargo add anydoc// 从文件路径 let markdown anydoc::to_markdown(report.docx)?; // 从字节格式自动检测None 表示按内容检测 let markdown anydoc::to_markdown_bytes(bytes, None)?; // 或显式指定格式CSV 需要 let markdown anydoc::to_markdown_bytes(bytes, anydoc::Format::Csv)?; // 或停在文档模型 let document anydoc::to_document(bytes, None)?;Rust 侧Format枚举与检测函数直接对应 src/lib.rs 中的实现to_markdown内部先std::fs::read读文件再Format::from_bytes检测、Format::from_path兜底最后走to_markdown_bytes。4.4 格式检测三函数三语言同名无论哪门语言都暴露内容检测的三个函数RustFormat::from_bytes/from_extension/from_pathNodeformatFromBytes/ ...Pythonanydoc.format_from_bytes/ ...Format::from_bytes(bytes); // Some(Format::Docx)无匹配则为 None Format::from_extension(pptm); // Some(Format::Pptx) Format::from_path(Path::new(report.odt)); // Some(Format::Odt)其中from_extension大小写不敏感、不带点号from_path取路径扩展名后委托from_extension。五、错误模型何时报错、报什么错只有产不出任何有意义的 Markdown时才报错。可恢复的生产者怪癖不会浮出表面——它们被恢复或跳过通过logfacade 以 debug/warn 级别记录转换继续。这一设计在 src/error.rs 的模块注释中写得非常明确。ConvertError共六个变体src/error.rs变体含义Nodeerror.codePython 异常Unsupported未知格式或无法转换如纯图片 PDFunsupportedUnsupportedErrorMalformed结构不可用提取不到有意义内容malformedMalformedErrorEncrypted加密或密码保护encryptedEncryptedErrorResourceLimit越过固定安全上限解压、嵌套、节点数resourceLimitResourceLimitErrorMissingPart缺少产出所必需的部件missingPartMissingPartErrorIo文件读不了仅to_markdownioOSError三种绑定层的对应方式Node/wasm 把变体名发布到error.codePython 为每个变体抛一个anydoc.ConvertError子类读文件失败抛OSError。code()方法被测试codes_name_every_variant锁定为稳定契约——bindings publish these verbatim aserror.code, so changing one breaks every caller that branches on it。ResourceLimit是硬错误is_fatal()返回 true即便出现在可选部件中也绝不吞掉——这对应仓库tests/fixtures/abuse/下的 zipbomb、imagebomb、hugespan 等安全测试夹具。批量处理的推荐写法README 与各语言 README 一致try { return await toMarkdown(path); } catch (error) { // 这两种情况没有文档产出记录下来继续下一个文件。 if (error.code encrypted || error.code unsupported) { unconverted.push({ path, reason: error.code }); return null; } throw error; }六、底层原理共享文档模型 单一 GFM 序列化器Skill 虽未展开但理解转换管线的收益巨大。README 的 How it works 给出了整体架构document bytes │ ├─► format detection → content markers, not the extension │ ├─► format parser → one per format (doc, docx, ppt, pptx, xls, │ xlsx, odt/ods/odp, rtf, epub, csv) │ │ │ └─► Document → shared model: blocks, inlines, tables, │ footnotes, assets │ │ │ └─► GFM serializer → Markdown │ └─► PDF → pdf-inspector → Markdown directly要点有三每个格式一个解析器但都汇入同一个共享文档模型Document包含 blocks、inlines、tables、footnotes、assets对应 src/model/ 目录block.rs、inline.rs、table.rs、list.rs、style.rs、link.rs、asset.rs 等GFM 序列化器只有一个src/render/markdown/mod.rs负责锚点anchors.rs、转义escape.rs、行内元素inline.rs、表格table.rs的渲染。因此一个格式的转义修复自动惠及所有格式——这正是 SKILL 承诺one consistent output no matter which format goes in的实现基础PDF 是唯一特例不经过共享模型由 pdf-inspector 直接产出 Markdown因此to_document对 PDF 不可用。每个格式的解析器位于 src/formats/docx、doc、ppt、pptx、xls/xlsxsheet、odf、rtf、epub、csv 各司其职。仓库tests/fixtures/下保存了各格式的实物夹具并做快照测试tests/snapshots.rstests/robustness.rs对每个夹具做变异测试fuzz/为每个格式提供 cargo-fuzz 目标——质量保障层层叠加。七、实战Agent 与批处理中的最佳实践综合 SKILL 规则与源码行为推荐以下工作流单文档快速转换npx -y firecrawl/anydoc report.docx从 stdout 直接读取大文档npx -y firecrawl/anydoc report.docx -o report.md随后按需分段读取规则 4无签名流curl -s url | npx -y firecrawl/anydoc - --format csv来自 node/cli.js 的示例管道输入必须显式命名 CSV批量处理外层循环逐文件调用检查退出码0成功、1记录失败原因继续、2修正命令失败诊断统一从 stderr 读取anydoc: ...行安全边界任何输入都可能被构造为 zipbomb 或深层嵌套见tests/fixtures/abuse/anydoc 以固定资源上限硬性拦截ResourceLimit批处理时应对其同样做记录处理代码库内集成优先 import 库 API规则 6避免进程开销Node 转换不阻塞事件循环Python 释放 GIL适合嵌入服务端管道。八、能力边界与适用前提OCR 缺失扫描版/纯图片 PDF 无法转换报Unsupported需要 OCR 的托管服务如 Firecrawl Parse承担此职责Node 20CLI 运行前提node/package.json 的engines一次一文档CLI 每次调用只接受一个输入文件PDF 不经文档模型to_document不适用于 PDFCSV 无签名内容检测无法识别 CSV必须靠扩展名或显式--format。这些边界在 Skill、README 与源码注释src/lib.rs、src/formats/detect.rs、src/error.rs中均有明确记载规划方案时应纳入考量。延伸阅读三语言完整 API 参考见 node/README.md、python/README.md、wasm/README.md转换质量与速度基准见 bench/README.md格式解析、渲染与检测的源码位于 src/formats/、src/render/、src/formats/detect.rs。赞分享AI 技能【免费下载链接】anydocConvert Word, PowerPoint, Excel, OpenDocument, RTF, EPUB, CSV, and PDF to clean Markdown. Built in Rust, with Node.js and Python bindings.项目地址https://gitcode.com/gh_mirrors/any/anydoc点击查看免费下载相关推荐anydoc Python 绑定指南用 firecrawl-anydoc 把 Office 文档转换为 GFM Markdownanydoc Python 绑定指南用 firecrawl anydoc 把 Office 文档转换为 GFM Markdown firecrawl anydAI 技能使用spf13/cobra生成Markdown格式命令文档指南使用spf13/cobra生成Markdown格式命令文档指南 前言 在开发命令行工具时良好的文档是不可或缺的。spf13/cobra作为Go语言中最流行的命CLI开发工具docling CLI工具实战命令行快速转换文档到Markdown/HTMLdocling CLI工具实战命令行快速转换文档到Markdown/HTML 还在为文档格式转换而烦恼面对PDF、DOCX、PPTX等各种格式的文档想要快AI 应用计算机视觉OCR上一篇BunkerWeb安全事件响应从检测到修复的应急处理流程下一篇NapCatQQ与主流LLM框架集成打造智能对话机器人终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考