本文永久链接 – https://tonybai.com/2026/05/09/cli-printing-press-intro
大家好，我是Tony Bai。
近日，一个名叫 cli-printing-press 的开源项目冲上了 X.com 热搜。它用 Go 写成，解决的是 AI Agent 时代最隐秘、也最致命的痛点——工具不够用，更不好用。
Discord 有 300 多个官方 API 端点。
按常理，一个覆盖所有端点的 CLI 工具，应该是最好用的那个。但事实恰恰相反。
OpenClaw 之父 Peter Steinberger 用 Go 写了一个叫 discrawl 的工具，只提供 11 个命令：sync、search、sql、tail、mentions、members……就这些。结果？700多 颗 GitHub Star，社区口口相传，被无数 AI Agent 开发者列为必装工具。
为什么一个”阉割版”打败了”全功能版”？
因为 Steinberger 看到了 Discord API 设计者自己都没意识到的东西：聊天记录不只是聊天，它是一个组织的知识库。
每一条消息线程，本质上都是一份可以被归档、被索引、被本地全文搜索的文档。那 11 个命令，围绕的就是这个洞察。300 个端点包装器，做不到这一点。
CLI Printing Press，就是一台把这种洞察自动化的“机器”。
在聊这个工具之前，我们需要先理解 2026 年的 AI 开发现状。
Claude Code、Codex、OpenClaw、Gemini CLI等 AI Agent 的能力已经突飞猛进。它们可以写代码、查数据、做分析、自主决策。但有一个瓶颈正在成为所有人的噩梦：现有的 CLI 工具，根本不是为 Agent 设计的。
想象一下 Agent 在调用一个普通 CLI 时会遇到什么：
CLI Printing Press 项目 README 开篇就把这个痛点说得很直白：“在 AI Agent 的世界里，没有什么比时间和金钱更宝贵——落到工程层面，就是速度和 token 消耗。一个设计优良的 CLI 是 Agent 的肌肉记忆：不用翻文档，不走弯路，不浪费 token。”
CLI Printing Press，就是为了解决这个问题而生的。
用一句话描述：
CLI Printing Press 是一台 CLI 工厂。给它一个 API 地址（或者任意一个网站），它输出一个专门为 AI Agent 设计的 Go CLI 工具 + MCP 服务器 + Claude Code Skill。
安装方式极其简单（Go需要>=1.26版本）：
# 安装工厂本体
go install github.com/mvanhorn/cli-printing-press/v4/cmd/printing-press@latest
# 克隆技能文件（配合 Claude Code 使用）
git clone https://github.com/mvanhorn/cli-printing-press.git
# 在 Claude Code 中启动，直接加载skill
claude --plugin-dir .
然后在 Claude Code 中，一条命令就能启动生产流程：
/printing-press Notion # 给 Notion API 生成 CLI
/printing-press https://espn.com/nba # 直接指向网站，无需 API 文档
这是一个值得细聊的设计决策。
在这个 TypeScript、Python 等生产力语言大行其道的时代，CLI Printing Press 选择了 Go，并且坚定地把 Go 作为所有生成产物的语言。原因很现实：
第一，分发极其简单。 go install 一行命令，跨平台，无依赖。Agent 在运行时动态安装工具，最怕的就是依赖地狱。Go 的静态编译二进制文件是最优解。
第二，Go 已经被实践证明。 Peter Steinberger 用 Go 写的 gogcli（Google Workspace CLI）拥有 7000+ Star，而 Google 官方之后推出的 Rust 版本，一周冲到 1 万 Star，却在社区中败给了前者。一个用户的评价是：”我 100% 偏好 gogcli，因为它就是能让 Agent 做到它需要做的事。”广度没能打败深度，Rust 没能打败 Go。
第三，Go 的并发模型非常适合 Agent 的使用场景。 SQLite 批量事务、并发 sync worker、FTS5 全文索引……这些都是 Agent 高频调用场景下的性能关键路径，Go 处理起来得心应手。
这是整个项目最有哲学深度的设计。
Printing Press 在生成任何 CLI 之前，都要先找到这个 API 的”非显见洞察”（NOI），一句话的格式：
“[API] 不只是 [显而易见的功能]。它是 [非显见的东西]。每个 [数据点] 都是关于 [隐藏真相] 的信号。”
几个例子，读完你可能会有点震撼：
这个 NOI 是整个 CLI 的创意 DNA。如果 AI 在研究阶段写不出一个 NOI，说明研究深度不够，Phase 0 不会放行。
大多数工具停在第 1 层。Printing Press 直接爬到第 5 层。
第 1 层：API 端点包装命令 ← 99% 的生成工具止步于此
第 2 层：输出格式 (--json, --csv)
第 3 层：本地持久化 (sync, search, SQLite)
第 4 层：领域分析 (stale, orphans, load) ← discrawl 的水准
第 5 层：行为洞察 (health 综合评分, similar 重复检测) ← 目前无人到达
第 3 层以上，才是真正的价值所在。一旦数据落在本地 SQLite，compound 查询就成为可能——这是任何无状态 API 包装器永远做不到的事情。
Printing Press 生成的每个高质量 CLI，都带有一套完整的本地数据层：
这意味着什么？看一个 Linear 的真实 Demo：
$ /pp-linear sql 'blocked issues whose blocker hasn't moved in 7 days'
背后执行的是：
SELECT i.identifier, i.title, age(now(), b.updated_at) AS stuck
FROM issues i
JOIN issue_relations r ON r.issue_id = i.id
JOIN issues b ON b.id = r.related_issue_id
WHERE r.type = 'blocked_by'
AND b.state = 'in_progress'
AND b.updated_at < now() - interval '7 days';
结果：
ENG-412 Crash on cold-start blocked 11d
ENG-388 Reconnect dropped sockets blocked 9d
ENG-301 Backfill missing rows blocked 8d
50 毫秒。本地完成。关键是 Linear 的官方 API 无法回答这个问题。
这是 Printing Press 和普通 CLI 生成工具最根本的区别。每一个生成出来的 CLI，都内置了以下设计：
- 0 = 成功
- 2 = 用法错误
- 3 = 资源未找到
- 4 = 认证失败
- 5 = API 错误
- 7 = 速率限制
Agent 读一个退出码就知道下一步怎么做，不需要解析错误文字，自我纠正只需一次重试。
为什么 CLI 比 MCP 更适合 Agent？
CLI 的 token 消耗比 MCP tool definition 少 100 倍。LLM 本来就在 shell 交互上训练过。退出码 0 = 完成。–json | jq 是一流的组合模式。
这套设计哲学有一句精辟的总结：“Agent-native 设计，就是认真对待 CLI 设计 的结果。”
ESPN 没有官方 API。Google Flights 没有公开文档。Dominos 也没有。
Printing Press 的解法：启动一个浏览器，你正常点击浏览，它在后台抓取所有 HTTP 流量，逆向工程出 API 结构，自动生成 OpenAPI spec，然后继续走后面的生成流程。
三种输入模式，覆盖所有场景：
每次运行 Printing Press，整个流程分阶段进行：
Printing Press产出的不是一个，而是两个可用工具：
一个 spec 进去
→ <api>-pp-cli Cobra CLI，供 Claude Code / Codex / shell 调用
→ <api>-pp-mcp MCP 服务器，供 Claude Desktop / Cursor / Windsurf 使用
两者共享同一个 internal/client、同一个 internal/store、同一套认证逻辑。零代码重复，一套实现，双场景覆盖。
生成出来的 CLI 质量如何保证？Printing Press 用了一套两层 100 分制评分系统，加四项机械化验证。
第一层（基础设施，50分）：检查骨架是否正确——输出模式、认证流程、错误处理、Agent-Native 标志、终端 UX、README、Doctor 命令、本地缓存。
第二层（领域正确性，50分）：检查代码是否真的能跑——生成的 URL 路径是否存在于 OpenAPI spec、认证格式是否和 spec 一致、SQLite 数据管道是否正确连通、是否有死代码和悬挂函数。
Grade A = 85 分以上。两层都过，才算合格。
四项行为证明（Proof of Behavior）：
任何一项证明失败，会触发自动修复流程，重新验证。
不想自己生成？官方已经打印好了 45 个 CLI，覆盖主流场景：
安装方式同样极简：
# 一键安装入门四件套
npx -y @mvanhorn/printing-press install starter-pack
# 安装指定工具
npx -y @mvanhorn/printing-press install espn sentry linear
Printing Press 最打动人的地方，是多个 CLI 可以在同一个 Claude 对话中协同工作。
场景：我想去看 OKC 的季后赛，怎么买最便宜的机票？
$ /pp-espn nba okc round 2 game 1 + /pp-flightgoat sea-okc, fly-in same day
两个 CLI，一次对话：
这不是 Demo，这是真实运行的输出。两个工具各司其职，一个 Agent 对话完成端到端决策。
CLI Printing Press 的出现和走红，其实折射出一个更大的趋势。
Rust 以性能和安全著称，Python 以生态和易用性著称，但在 AI Agent 工具这个细分赛道，Go 正在悄悄胜出。原因很简单：
更深层的洞察是：AI Agent 需要的不是最强的工具，而是最可靠、更好用的工具。 打 5 分的输出稳定输出，胜过偶尔打 9 分但不可预测的输出。Go 的 CLI 恰恰提供了这种可靠性。
而 CLI Printing Press，把这套哲学变成了一条流水线。
如果你也在构建 AI Agent，或者正在为 Agent 寻找合适的工具层，这个项目值得花半小时认真研究一下。它解决的问题，可能比你意识到的还要根本。
今日互动探讨：
看完这款“CLI 印刷机”，你觉得在 AI 时代，传统的 RESTful API 是否已经走到了尽头？你最想为哪个原本没有 API 的网站“打印”一个专属工具
？
欢迎在评论区分享你的脑洞！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
Related posts:
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。