2GB的LaTeX被1个Python工具干翻，开发者集体破防

GitHub上有个README.md想转成PDF，你的第一反应是什么？装LaTeX？那套2GB的环境够你喝一壶咖啡。写配置文件？500行代码还没开始写文档就已经累了。这是Leonardo Salas去年面对的真实场景，然后他做了一个让Typst社区都愣住的选择。

他用Python写了个零配置的命令行工具，把Markdown直接喂给Typst编译器，整个过程不需要HTML中间层，也不需要你碰任何排版代码。

这个叫doc-engine-cli的项目，核心逻辑简单到有点粗暴：mistune解析Markdown的抽象语法树（AST，一种树状的数据结构，描述文档的层级关系），Python绑定直接把解析后的块塞进Typst。没有浏览器引擎，没有CSS折腾，页边距和分页由Typst的编译器原生处理。

为什么跳过HTML这一步很关键

传统的Markdown转PDF路径通常是：Markdown → HTML → 浏览器渲染 → PDF。这个链条上每个环节都在制造麻烦。HTML转PDF引擎对分页的控制很粗糙，代码块经常被拦腰截断，表格跨页就变形。

Leonardo的选择是绕过整个浏览器层。Typst作为新兴排版系统，编译速度比LaTeX快一个数量级，而且原生支持现代字体和编程语法高亮。doc-engine-cli把AST节点直接映射到Typst的标记语言，相当于让Markdown和排版引擎说同一种方言，省去了翻译损耗。

工具内置了两套字体：Inter用于正文，Cascadia Code用于代码块。都是开源字体，但组合起来的视觉效果很接近付费学术模板的水准。封面页自动抓取本地git config的user.name，这个细节说明作者自己就是目标用户——他知道开发者懒得填元数据。

安装路径的设计藏着产品思维

Python生态的命令行工具安装是个经典痛点。Leonardo给了两条路：pipx安装，或者直接用GHCR的容器镜像。后者甚至不需要本地有Python环境，docker run一行命令搞定。

这个设计对应两种真实场景：想快速试用的路人用户，和在CI/CD流水线里需要稳定环境的团队用户。容器镜像的版本锁定在main标签，目前看是跟随GitHub主分支自动构建。

功能清单很克制：动态目录、语法高亮、智能分页。没有主题系统，没有插件机制，没有LaTeX那种宏包地狱。README.md放进去，PDF拿出来，中间发生的事情用户不需要知道。

Typst的Python绑定是这个方案的技术支点。Typst本身用Rust编写，官方提供WASM和CLI接口，社区维护的Python绑定让跨语言调用成为可能。Leonardo在GitHub的README里专门留了反馈入口，问的就是"你觉得Typst集成怎么样"——这个提问方式暗示他可能还在评估其他后端，或者收集足够反馈后往更深度的定制方向走。

文档工具的"足够好"哲学

LaTeX的问题从来不是功能不够，而是功能太多。写篇论文要先学一套排版语言，调个页边距要翻宏包文档，编译报错信息像密码学挑战。Pandoc试图解决这个问题，但配置复杂度只是把LaTeX的麻烦转移到了YAML文件里。

doc-engine-cli的激进之处在于：它不做通用解决方案，只解决"README转漂亮PDF"这一个场景。场景边界清晰，功能就可以做减法。自动检测README.md、自动提取git用户名、预设字体组合——这些不是偷懒，是对目标用户行为的精确建模。

技术选型上也有意思。mistune是Python里偏冷门的Markdown解析器，相比markdown-it或Python-Markdown，它的AST输出更干净，而且纯Python实现没有C扩展依赖。Typst的编译速度让实时预览成为可能，虽然doc-engine-cli目前没做这个功能，但架构上留了口子。

容器化的选择值得多说一句。把CLI工具打包成Docker镜像在开发者工具里不算主流，通常只有涉及复杂系统依赖（比如Chromium headless）才会这么做。Leonardo反其道而行，用容器解决Python版本和依赖管理的麻烦，这个决策可能和他想覆盖"不想装Python"的用户群体有关。

社区反馈里的信号

项目在GitHub的issue区目前主要是功能请求：支持自定义CSS主题、添加页眉页脚模板、批量处理多个文件。没有关于安装失败的抱怨，说明pipx和Docker的双轨策略确实覆盖了大多数环境。

有个细节是用户反复提到的：转换后的PDF在代码块换行处理上比Pandoc干净。这是因为Typst对等宽字体的断行规则有原生优化，而不是像wkhtmltopdf那样把代码当普通文本渲染。

Leonardo在DEV.to的原文结尾放了一句："Let me know what you think of the Typst integration!" 这个问法很有意思——他没问工具好不好用，而是问集成方案本身。可能是在验证一个假设：Typst作为LaTeX替代品的开发者工具链地位，是不是已经成熟到可以成为默认选项。

如果文档生成工具的演进方向是"隐形的基础设施"，doc-engine-cli算是个不错的样本。它不试图教育用户理解排版，只是把转换这件事的摩擦系数降到接近零。下次你需要交一份带代码的PDF报告时，会愿意把2GB的LaTeX换成一个pip install吗？