CLI Printing Press：AI 时代 API 的「印刷机」

图 1：CLI Printing Press 工作流程演示

一款让 AI 代理用上本地最强 CLI 的「印刷工厂」

想象这样一个场景：你让 AI 代理去查「今天 NBA 季后赛的对阵情况，包括比分、球星数据和伤病动态」，它不需要翻文档、不需要一步步试错，直接调一个本地命令就能把所有信息抓回来——这就是 CLI Printing Press 正在做的事。

作者 Matt Van Horn 在 AI Agent 爆发的浪潮中，敏锐地捕捉到了一个核心痛点：AI 代理和 CLI 工具之间，存在一层巨大的摩擦。Agent 每次调用外部 API 都要浪费大量 token 读文档、试参数，而人类开发者早就积累了大量高效的命令行工具。Printing Press 的使命，就是把这层摩擦彻底抹掉。

技术出身：从 discrawl 到 Printing Press

Matt Van Horn 并非突然冒出的新面孔。他此前开源的 discrawl 和 gogcli 两个项目，就已经在 CLI 领域小有名气。discrawl 是一个 API 嗅探工具，能够「逆向工程」那些没有公开文档的网页端 API（典型如 Google Flights、Dominons）；gogcli 则是针对特定场景的 CLI 封装。这两个项目的核心设计哲学——本地 SQLite 缓存、复合查询命令、离线优先——在 Printing Press 中得到了全面继承和升级。

Printing Press 本身是一个 Go 语言开发的项目，要求 Go 1.26.4 以上版本，这保证了二进制产出的高性能和跨平台兼容能力。项目采用模块化架构，核心生成器位于 internal/generator/，解析层分 openapi/、graphql/、docspec/ 等多个子模块，形成了清晰的前后端分离。

图 2：Printing Press 项目结构与生成产物

核心机制：读文档、出 CLI、出 MCP Server

Printing Press 的输入是一个 API 规范（OpenAPI 或 GraphQL），输出是三件套：一个 Go 语言编写的本地 CLI 工具、一个 Claude Code Skill、一个 MCP Server。整个过程大致分为三个阶段：

第一阶段：API 分析与领域识别。 系统会解析 API 文档，并尝试嗅探那些没有公开 API 的网页端接口（如 ESPN、Google Flights）。它还会识别 API 所属的领域类型（通讯、支付、项目管理等），从而决定该生成哪些「高级命令」。

第二阶段：生成代码。 基于 internal/generator/ 中的模板和解析逻辑，生成 Go CLI 代码。生成的 CLI 不是简单的 endpoint 包装，而是包含 sync、search、stale、health 等领域特定的高级命令。生成的产物带有 -pp- 中缀（如 linear-pp-cli），避免与官方 CLI 命名冲突。

第三阶段：构建与验证。 调用 go build 编译二进制，通过 dogfood 和 verify 脚本进行自测，跑 scorecard 打质量分。

生成后的 CLI 可以独立使用，也可以通过 Claude Code Skill 驱动（输入 /printing-press <API名>），还可以作为 MCP Server 接入 Claude Code 的 Agent 循环。项目已预置了一些现成的打印 CLIs，如 ESPN（体育数据）、flight-goat（航班搜索）、linear-pp-cli（项目管理），均可在 printingpress.dev 上找到。

图 3：打印后的 CLI 在终端中的使用效果

技术栈：Go 为核，chromedp 嗅探，SQLite 本地缓存

项目使用纯 Go 开发，核心依赖包括：

• spf13/cobra：CLI 框架，负责命令注册和参数解析
• chromedp/chromedp：无头浏览器，用于嗅探无文档的网页端 API
• getkin/kin-openapi：OpenAPI 规范解析
• dave/dst：Go 代码的 AST 操作，用于代码生成
• golang.org/x/*：网络、并发、文本处理等标准扩展

生成的 CLI 内置 SQLite 本地数据库，所有查询结果会被缓存，支持离线搜索。查询命令会先读本地缓存（延迟可达 50ms），只在缓存失效时才调远程 API，大幅节省 token 消耗。

Claude Code Skill：Agent 原生交互范式

Printing Press 真正的杀手级功能是它配套的 Claude Code Skill。用户只需在 Claude Code 中输入 /printing-press <API名>，Skill 就会驱动整个生成流程：分析 API → 生成代码 → 构建测试 → 输出使用指南。这是一个为 AI 原生设计的交互协议——不是让人去读文档，而是让 AI 自己读文档然后造工具。

生成的 CLI 名称带有 -pp- 中缀（如 linear-pp-cli），避免与官方 CLI 冲突。Skill 会自动处理认证（通过 press-auth 子命令），并告诉用户什么场景该用 CLI、什么场景该用 MCP Server。

上手门槛：有门槛，但回报丰厚

部署安装非常简单（go install 或 install.sh），但使用门槛在于：用户需要理解 API 规范（OpenAPI/GraphQL）才能作为输入。项目文档相当完善，包含 ONBOARDING.md（上手指南）、CONCEPTS.md（核心概念）、AGENTS.md（Agent 操作手册）和 GLOSSARY.md（术语表），适合有技术背景的开发者深入研究。

对于普通用户，现成的打印 CLI（如 ESPN、flight-goat）可以零门槛直接使用，查询体育数据、航班信息等。

局限与争议

1. 仅支持 REST（OpenAPI）和 GraphQL：不支持 gRPC、WebSocket 等其他协议
2. 生成质量依赖 API 文档质量：文档不规范，生成结果也会打折扣
3. Go 强依赖：必须在有 Go 环境的机器上编译，对于纯 Python/JS 项目来说增加了一层工具链复杂度
4. 作者知名度：Matt Van Horn 是独立开发者，社区支持不如大型框架

行业意义：重新定义 Agent 工具调用范式

CLI Printing Press 代表了一种新兴的 AI 工程实践：不让 Agent 调 API，而是让 Agent 造工具再调工具。通过将 API 封装成本地二进制，它将 token 消耗从「每次查文档」降到「本地缓存命中」，将响应延迟从网络延迟降到 SQLite 读取延迟（50ms 级别）。

随着 AI Agent 在编程、运维、数据分析等领域全面渗透，这类「API → 本地工具」的自动化生成工具将变得越来越重要。Printing Press 目前已生成并维护了数十个常用 API 的 CLI，形成了 Printing Press Library 社区生态，未来有望成为 AI Agent 工具链的标准组件之一。

图 4：作者 Matt Van Horn

一句话评价：如果你的 AI 代理还在一次次调远程 API、一次次浪费 token 读文档，CLI Printing Press 就是那个帮你把工具先造好、再高效使用的「工厂」。