AI 浪潮奔涌而来，当所有人都在追逐大模型、Agent 和宏大叙事时，我却转过头，重新审视起自己几年前写下的一个、甚至谈不上起眼的“传统功能”：
企业资产标签打印。
最近，我把这个思考的产物开源了，它叫 DeepPrint Studio。
很多人看到这个项目后，问得最多的问题是：
为什么会想到在 AI 时代，去做一个看起来这么传统的打印平台？
其实我的答案恰恰相反：DeepPrint 并不是一个传统的打印平台。它是一个利用现代技术，为 AI-Native 准备的现代化打印中台。
它的诞生，源于我回过头看自己以前做过的功能时，产生的一个技术直觉：在 AI 已经能够重构软件交互的今天，企业级打印模板的生成和排版，也应该有一次彻底的范式革命。
传统企业打印方案的“死胡同”
几年前，在开发一套资产管理系统时，我需要支持资产标签打印：把资产编号、名称、条形码或二维码印出来，再贴到物理设备上。
当时业内最成熟的低成本选择是 Lodop 插件。功能顺利上线，用户也一直在正常使用。但整个开发过程让我觉得很不优雅。
因为传统打印方案本质上是命令式的。我们必须在代码里强行操控像素的绝对坐标：
LODOP.ADD_PRINT_TEXT(10, 20, 100, 20, "资产编号");
LODOP.ADD_PRINT_BARCODE(35, 20, 150, 40, "QRCode", asset_no);在这种模式下，所谓“排版”退化成了无休止的坐标微调。尺寸变了、二维码偏了、文字超长了，开发者就得一遍遍人工计算、修改坐标、测试输出。
当时我就在想：为什么我们必须关心这些具体的绝对坐标？难道就没有一种更自然、更符合直觉的方式，来描述“我想打印什么”吗？
当然，也有人会说：用拖拽式的可视化报表设计器不就行了？
在没有 AI 的时代，拖拽确实是一种现实解法。但当 AI 出现后，可视化拖拽方案反而暴露出了新的问题：拖拽设计器底层生成的，往往是极其冗余、缺少语义的巨大 JSON 或 XML。这样的文件，人类难读，AI 也难以精准理解和修改。
如果未来的模板设计希望交给大模型，底层格式就必须更简单、更语义化、更接近自然语言。
Typst：AI 时代的排版钥匙
带着“如何让 AI 介入打印排版”的问题，我开始寻找新的方案。直到我遇见了 Typst。
第一次接触 Typst 的时候，我脑海里瞬间亮起了一盏灯：
这就是通往 AI-Native 打印的钥匙。
Typst 本质上是一种现代文档排版语言。你可以把它理解为更现代、更简洁、更易用的 LaTeX。它最大的特点是：你只需要描述文档的语义和结构，排版和定位交给引擎自动完成。
比如，一个资产标签，在 Typst 里可以这样写：
#set page(
width: 50mm,
height: 30mm,
margin: (x: 5mm, y: 5mm)
)
= 资产标签
*资产编号*：#asset_no
*资产名称*：#asset_name它比传统的绝对坐标更优雅、更整洁。更重要的是：Typst 代码天然就是高度精简的纯文本。
而文本，正是大模型理解和生成这个世界最擅长的介质。
从 Template Designer 到 Prompt-to-Print
一旦打印模板变成干净、规整、无冗余的 Typst 文本，事情就变得很有意思了：
我们不一定还需要为打印系统开发复杂的拖拽编辑器。
因为 Typst 的简洁性和可读性，AI 可以很顺畅地理解、生成、修改它。这意味着在 DeepPrint 的后续规划中，我们可以实现一种更自然的交互：
帮我把标签尺寸改成 60x40mm，字体调大一号，并在右下角加上二维码。
LLM 直接生成几十行清晰的 Typst 模板代码。DeepPrint 将它渲染成 PDF，再通过 CUPS 提交给物理打印机，最终吐出纸张。
这不只是“打印”，而是在重新定义打印模板的创建方式。传统繁琐的排版工作，被压缩成了一条由大模型驱动的极简链路：
自然语言需求 -> Typst 模板 -> PDF 渲染 -> CUPS 打印 -> 物理纸张我把它称为 Prompt-to-Print。
于是，我动手写了 DeepPrint
为了验证这个想法，我利用业余时间开始动手。
老实说，在以前，想要凭一己之力手写一套这样的 Rust 底层服务，对我来说几乎是难以想象的。但这一次，借助 AI 编程辅助，我不仅高效跨过了 Rust 陡峭的学习曲线，也把很多以前很难独自完成的底层能力一点点拼出来，最终形成了现在的 DeepPrint Studio。
从技术架构上看，DeepPrint 是一个将 Rust Server + Typst 现代排版 + Linux CUPS 底层打印链路 融为一体的高性能打印平台。
业务系统(JSON 数据)
-> DeepPrint OpenAPI
-> Typst 渲染器(PDF)
-> Linux CUPS
-> 物理打印机目前 DeepPrint 已经实现了这些核心能力：
- 模板管理工作区：在线编辑 Typst，并实时预览渲染结果。
- 打印任务队列：基于状态机的异步排队、崩溃恢复和重试。
- 物理设备纳管：深度集成 Linux CUPS，自动发现并管理 USB/网络打印机。
- 外部 OpenAPI：标准 Bearer API 鉴权，支持业务方传入
request_id实现全链路幂等。
也就是说，不管是 WMS、ERP，还是资产管理系统，业务系统只需要把纯粹的 JSON 数据丢给 DeepPrint API。剩下的模板渲染、PDF 生成、任务排队和物理打印提交，都由 DeepPrint 在后台完成。
未来，模板设计本身也可以逐步交给大模型。
任何方案都有代价
作为开源项目的作者，我并不打算把 DeepPrint 吹成万能工具。探索这条新链路时，我也清楚地触碰到了它的边界。
1. CUPS 不适合极致小票场景
DeepPrint 深度依赖 CUPS 构建 IPP 通信链路，最终生成的是高质量矢量 PDF。
但在餐饮小票、便利店收银等热敏/针式小票机上，这条路并不总是合适。很多廉价小票打印机没有 Linux 下的标准驱动支持，而且通过 PDF 渲染再打印，对毫秒必争的收银前台来说也显得偏重。
对于纯小票打印，直接向打印机端口发送 ESC/POS 裸指令，往往才是最高效的解法。
2. 不适合工业级高速连打
Typst 的声明式排版需要经过引擎渲染，再格式化成 PDF 发送。
对于流水线上每秒需要连打几十张快递单、外箱标的工业级热敏打印机，更稳妥的方案依然是直接把 ZPL/TSPL 裸指令丢给打印机，让硬件芯片本地完成像素渲染。
在这种极致吞吐量场景里，DeepPrint 的 PDF 渲染链路并没有优势。
3. 私有化部署仍然有硬件成本
虽然 DeepPrint 用 Docker 封装了系统，但现实的私有化部署里，Linux 宿主机的 USB 设备，尤其是那些便宜、无驱动的国产打印机，要稳定映射进 CUPS 容器，并找到兼容的通用 PPD 驱动文件，对非技术背景的现场实施人员来说，仍然有配置成本。
这不是一行代码能抹平的问题。硬件世界，总会有它自己的粗糙边界。
为什么选择开源？
企业级打印是一个极其普遍，却又总是被嫌弃的痛点需求。
几乎每一个做 ERP、MES、WMS、电商订单、资产管理的团队，最后都逃不开和物理打印机打交道，也逃不开深夜里一遍又一遍重启服务、调试驱动、校准模板的痛苦。
既然如此，我选择把 DeepPrint 开源出来，采用友好的 Apache-2.0 协议。
我想让大家看到：哪怕是打印这种看起来非常传统的硬件领域，只要把 AI 的大模型理解力、Typst 的现代排版能力，以及 Rust 稳健的高性能基础设施结合在一起，也能碰撞出非常现代、优雅且性感的火花。
如果你也曾被打印模板繁琐的排版困扰过，或者对 Typst、Rust 以及 AI 智能生成模板感兴趣，欢迎一起探讨现代打印的更多可能。
项目地址：
https://github.com/boe1900/deepprint
如果这个项目对你有所启发，欢迎点个 Star 支持一下。