Tony Bai - 一个程序员的心路历程

Anthropic 工程师发文：别用 Markdown 了，HTML 才是 AI 的终极语言！

五月 9, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/05/09/anthropic-engineer-say-html-is-the-ultimate-language-for-ai

大家好，我是Tony Bai。

在这个大模型（LLM）席卷一切的时代，如果说有什么东西是全体程序员的“共识”，那绝对是 Markdown。

无论是写 Prompt，定义 Agent Skill，还是阅读大模型吐出的漫长代码审查报告，Markdown 凭借其极简的纯文本特性，几乎成了人类与 AI 沟通的“普通话（Lingua Franca）”。

但就在近日，这个牢不可破的共识，被大模型领域的绝对王者——Anthropic（Claude 的母公司）自己人给掀翻了。

Claude Code 团队的核心工程师 Thariq，在 X (Twitter) 平台上抛出了一篇长文：《使用 Claude Code：HTML 不讲理的有效性（The Unreasonable Effectiveness of HTML）》。

在这篇获得了上百万阅读量、上千次转发的神贴中，他毫不客气地宣称：

“我已经彻底停止使用 Markdown 了。对于智能体（Agent）时代来说，HTML 才是更完美的通信格式。”

这篇文章瞬间在技术圈引发了一场大地震。有人拍案叫绝，直呼“Game Changer（游戏规则改变者）”；也有人愤怒反驳，认为这简直是历史的倒车。

今天，我们也来解读一下这场顶级社区的论战，看看为什么连最懂大模型的人，都要抛弃我们最爱的 Markdown？而在 AI 时代，我们又该如何重新定义“代码的可读性”？

原罪暴露：当 Markdown 遇上“超级智能体”

一直以来，我们喜欢 Markdown，是因为它“简单”。

在那个我们只让 AI 帮我们写两个小函数、查一个 Bug 的“手工作坊”时代，Markdown 是完美的。

但现在的 Agent 变了。它们太强大了。

正如 Thariq 在文章中指出的：

“随着 Agent 变得越来越强大，我开始觉得 Markdown 变成了一种限制性格式。当我面对一个超过 100 行的 Markdown 文件时，阅读它变得极其困难。我想要更丰富的可视化、颜色、图表，我想要能够轻松地分享它们。”

这精准地戳中了当前所有高级 AI 开发者的痛点：信息密度的坍塌。

当你让 Agent 去审查一个包含 5 个文件、上百行改动的复杂 PR（Pull Request）时，如果用 Markdown 输出，你只会得到一面密密麻麻的“文本墙（Wall of text）”。

你无法高亮关键的代码行，无法并排对比修改前后的差异，更无法画出一个交互式的调用链路图。

在这个时候，Markdown 的“极简”，反而成了人类理解 AI 复杂输出的最大障碍。

降维打击：HTML 的“不讲理有效性”

面对信息密度的瓶颈，Thariq 给出了一剂猛药：彻底转向 HTML。

他惊奇地发现，现代的大模型（尤其是 Claude Sonnet 4.x 版本），在处理和生成 HTML 方面的能力，已经到了令人发指的地步。

他总结了 HTML 在 AI 交互中的四大降维打击能力：

1. 恐怖的“信息密度（Information Density）”

HTML 不仅能表达简单的标题和格式，它还能通过 \<svg> 直接内联生成精美的流程图，通过 CSS 生成带颜色的代码差异对比（Diff），甚至可以利用绝对定位（Canvas）来表达空间数据。

“可以说，Claude 几乎没有什么是不能用 HTML 高效表示的。”

2. 极佳的“视觉清晰度与可读性”

当 AI 帮你完成了一个宏大的架构设计，与其看几百行的纯文本，不如让 Claude 直接生成一个带有选项卡（Tabs）、插图、侧边栏导航的完整 HTML 网页。

Thariq 提到：“在实践中，我发现自己几乎不会去读超过 100 行的 Markdown，我也绝对无法让组织里的其他人去读它。但 HTML 文档就容易阅读得多。”

3. “双向交互（Two-way Interaction）”的魔法

这是最让人拍案叫绝的一点！

你可以让 Claude 生成一个带有滑块（Sliders）或按钮的 HTML 原型。你在浏览器里拖动滑块调整参数，觉得满意后，直接点击“复制为 JSON（Copy as JSON）”，然后再把这串参数喂回给 Claude Code 继续开发。

UI 变成了你和 AI 之间最直观的“调试器”。

4. 完美的分享体验

Markdown 极难分享，大多数人的浏览器直接打开是一片乱码。但 HTML，你只需要把它扔进 S3 或者发给同事，任何人在任何设备上双击就能看，甚至还能做响应式适配。

实战演练：从“提示词写手”到“数字导演”

这套理论绝不仅仅停留在纸面上。评论区里，无数被点醒的开发者开始疯狂晒出他们的实战案例。

重塑 Code Review：不再看黑底白字的文本，直接让 Claude 生成一个带有内联边距注释、按严重程度着色的精美 HTML 审查报告。
A/B 测试方案对比：不知道产品该用哪种设计？让 AI 生成一个包含 6 种不同方案的网格布局 HTML 页面，把所有的优缺点并排陈列在眼前，一目了然。
动态交互式报告：让 AI 去抓取 Git 提交历史、Slack 聊天记录，然后生成一份极度精美的周报网页，里面甚至包含了可交互的 SVG 图表。

正如一位开发者在评论中所说：

“所以你的意思是，我不应该要求一个 ASCII 字符画的草图，而是应该直接要求一个 HTML 的设计模型？？我得去试试这个。用 Markdown 做计划，用 HTML 做设计。”

社区撕裂：一场关于“认知负荷”的哲学博弈

当然，如此颠覆性的观点，必然会引发强烈的抵触。

在推特的评论区，一场关于“效率 vs 消耗”的论战正在上演。

反对派（Markdown 死忠党）的核心论点极其犀利：Token 成本与编辑摩擦。

“HTML 在命令行里根本没法读，而且极其容易因为缺少闭合标签而崩溃。大多数 LLM 在长上下文中处理 HTML 会非常吃力。”

“HTML 确实在视觉上提供了更高的信息密度。但为了这点视觉信号，你要多花 2-4 倍的 Token 成本！这让我感觉非常糟糕。”

“Markdown 最大的优势是‘可编辑性’。如果我们不再亲手编辑文件，那么格式的选择就从‘什么最容易写’变成了‘什么最容易检查、微调并反馈给 Agent’。”

这是一场深刻的哲学博弈。

Markdown 代表的是“以人类编写为中心”的过去；而 HTML 代表的，则是“以 AI 生成、人类消费为中心”的未来。

当我们不再亲手敲击每一行代码，而是扮演“审查员”和“导演”的角色时，我们真的还需要在乎生成过程消耗了多少个

div> 标签吗？

小结：工具的终局，是顺应生产关系

Thariq 的这篇文章，之所以能引发如此巨大的反响，是因为它极其敏锐地捕捉到了 AI 时代生产关系的变化。

在过去，程序员是“工人”，我们需要 Markdown 这样轻巧的工具来减轻手腕的负担。
在未来，程序员是“厂长”，我们需要 HTML 这样丰富的看板，来快速审阅成千上万个 AI Agent 提交的工作报告。

“Markdown 适合思考（Planning），HTML 适合展示（Acting）。”

或许，正如评论区的一位老哥半开玩笑的预言：“XML 才是最后的赢家。立帖为证。”

在 AI 这个不知疲倦的“超级打字员”面前，所有曾经因为“太啰嗦”而被人类抛弃的富文本标记语言，都可能迎来一场轰轰烈烈的文艺复兴。

资料链接：https://x.com/trq212/status/2052809885763747935

今日互动探讨：

在日常使用大模型时，你更倾向于让它输出极简的 Markdown，还是信息量爆炸但耗费 Token 的 HTML？你觉得在 AI 时代，“代码的可读性”定义是否已经被彻底改写了？

欢迎在评论区分享你的实战心得！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
构建坚不可摧的 Safety Middleware 与飞书人工审批防线
在底层实现 Token 成本审计、链路追踪与自动化跑分评估
从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

img{512x368}

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

火爆外网的 Go 开源神器 CLI Printing Press：一键生成 Agent 专属 CLI 工具

五月 9, 2026
0 条评论

本文永久链接 – 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，就是一台把这种洞察自动化的“机器”。

AI Agent 的”工具饥渴”时代

在聊这个工具之前，我们需要先理解 2026 年的 AI 开发现状。

Claude Code、Codex、OpenClaw、Gemini CLI等 AI Agent 的能力已经突飞猛进。它们可以写代码、查数据、做分析、自主决策。但有一个瓶颈正在成为所有人的噩梦：现有的 CLI 工具，根本不是为 Agent 设计的。

想象一下 Agent 在调用一个普通 CLI 时会遇到什么：

输出格式不稳定，有时是表格，有时是纯文本，Agent 根本无法可靠地解析；
没有类型化退出码，出了错要去解析 stderr 的文字才能知道是认证失败还是网络超时；
每次查询都要远程 API 调用，一个复合问题需要十几次 round-trip，token 哗哗地烧；
遇到没有公开 API 文档的网站（比如 ESPN、Google Flights），完全束手无策。

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 文档

为什么选 Go？

这是一个值得细聊的设计决策。

在这个 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 处理起来得心应手。

核心机制：它如何做到的？

每个 API 都有非显见身份（Non-Obvious Insight）

这是整个项目最有哲学深度的设计。

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，都带有一套完整的本地数据层：

领域特定的 SQLite 表（不是 JSON blob，是真正的关系型结构）
FTS5 全文搜索索引
带游标追踪的增量同步
直接 SQL 查询接口

这意味着什么？看一个 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 无法回答这个问题。

Agent-Native 设计哲学

这是 Printing Press 和普通 CLI 生成工具最根本的区别。每一个生成出来的 CLI，都内置了以下设计：

自动 JSON 输出：终端里显示人性化表格，管道传输时自动切换为 JSON，无需 –json 标志。
–compact 模式：只返回高重力字段（id、name、status、时间戳），减少 60-80% 的 token 消耗。
–dry-run 安全探索：让 Agent 在不执行副作用的情况下验证命令逻辑。
类型化退出码：

- 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 设计的结果。”

无 API 文档？浏览器嗅探搞定

ESPN 没有官方 API。Google Flights 没有公开文档。Dominos 也没有。

Printing Press 的解法：启动一个浏览器，你正常点击浏览，它在后台抓取所有 HTTP 流量，逆向工程出 API 结构，自动生成 OpenAPI spec，然后继续走后面的生成流程。

三种输入模式，覆盖所有场景：

–spec：直接提供 OpenAPI spec 文件
–har：DevTools 导出的 HAR 流量包
直接 URL：交给浏览器嗅探

工厂流水线，一次生成，双接口输出

每次运行 Printing Press，整个流程分阶段进行：

Phase 0：解析 & 复用（1-3 分钟）
Phase 1：研究简报 — API 身份、竞争对手、数据层、产品论点（5-10 分钟）
Phase 1.5：生态吸收门 — 目录化每个 MCP/skill/CLI 的功能，生成吸收清单（5-10 分钟）
Phase 1.7：浏览器嗅探门（2-5 分钟）
Phase 2：生成 Go CLI + MCP 服务器（1-2 分钟）
Phase 3：构建 GOAT — 吸收所有功能 + 超越命令（10-20 分钟）
Phase 4：发货检查 — Dogfood + 验证 + 质量评分（3-8 分钟）
Phase 5：Live Smoke Test（可选）（2-5 分钟）

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）：

路径证明：所有生成的命令 URL 都存在于 OpenAPI spec
标志证明：所有注册的 flag 都被至少一个命令引用
管道证明：每个 SQLite 表都有 WRITE 路径（sync）和 READ 路径（search/query）
认证证明：认证头格式和 spec 的 securitySchemes 匹配

任何一项证明失败，会触发自动修复流程，重新验证。

已打印的 CLI 库：45 个开箱即用

不想自己生成？官方已经打印好了 45 个 CLI，覆盖主流场景：

旅行：flight-goat（Kayak + Google Flights 双数据源，一条命令搞定长途航班搜索）
体育：espn-pp-cli（17 个体育项目，实时比分、系列赛状态、伤病报告）
生产力：linear-pp-cli（50ms 复合查询）、slack-pp-cli、cal-com-pp-cli
电商：ebay-pp-cli（真正的狙击竞价）、craigslist-pp-cli（历史价格对比、骗局评分）
房产：redfin-pp-cli（内部 Stingray API 嗅探，$/sqft 净 HOA 排名）
美食：dominos-pp-cli（本地最优套餐叠加，这是 Dominos 官网没有的功能）

安装方式同样极简：

# 一键安装入门四件套
npx -y @mvanhorn/printing-press install starter-pack

# 安装指定工具
npx -y @mvanhorn/printing-press install espn sentry linear

两个 CLI 协同工作的真实场景

Printing Press 最打动人的地方，是多个 CLI 可以在同一个 Claude 对话中协同工作。

场景：我想去看 OKC 的季后赛，怎么买最便宜的机票？

$ /pp-espn nba okc round 2 game 1 + /pp-flightgoat sea-okc, fly-in same day

两个 CLI，一次对话：

espn-pp-cli 拉取实时数据：OKC 刚以 131-122 赢了凤凰城，第二轮第一场预计在 5 月 9 日或 10 日
flightgoat-pp-cli 立刻查询：西雅图飞俄克拉荷马城，当天往返
结果：西南航空 $437 往返，推荐 Wanna Get Away+ 可退款票，Frontier 的那班到得太晚，跳过

这不是 Demo，这是真实运行的输出。两个工具各司其职，一个 Agent 对话完成端到端决策。

写在最后：Go 为什么在 AI 时代逆袭

CLI Printing Press 的出现和走红，其实折射出一个更大的趋势。

Rust 以性能和安全著称，Python 以生态和易用性著称，但在 AI Agent 工具这个细分赛道，Go 正在悄悄胜出。原因很简单：

分发成本最低：单一静态二进制，go install 一行，Agent 可以动态自安装。
并发模型刚好够用：协程 + channel 处理并发 sync 任务，不过度设计。
SQLite 生态成熟：go-sqlite3、modernc/sqlite，本地优先架构的标准搭档。
工程师接受度高：Agent 调用的工具，背后的人类也要维护，Go 的可读性是优势。

更深层的洞察是：AI Agent 需要的不是最强的工具，而是最可靠、更好用的工具。 打 5 分的输出稳定输出，胜过偶尔打 9 分但不可预测的输出。Go 的 CLI 恰恰提供了这种可靠性。

而 CLI Printing Press，把这套哲学变成了一条流水线。

如果你也在构建 AI Agent，或者正在为 Agent 寻找合适的工具层，这个项目值得花半小时认真研究一下。它解决的问题，可能比你意识到的还要根本。

参考资料

项目地址：github.com/mvanhorn/cli-printing-press
官网：printingpress.dev
CLI 库仓库：github.com/mvanhorn/printing-press-library
X热搜：https://x.com/i/trending/2052445800421015770