即览：手机端Markdown与HTML阅读器

Article

即览：手机上看 Markdown 和 HTML，怎么就这么难？

之前预告过的那个「手机上的 Markdown / HTML 阅读器」做完了，叫 即览。

它解决的是一个很小、但最近越来越烦的问题：

别人从微信、文件 App 或群里发你一份 AI 报告、网页 PPT、Markdown 文档，手机上点开不是空白，就是源码，要么样式全坏，要么根本不知道该用什么打开。

.md、.markdown、.html、.htm、.txt，还有打包好的网页 ZIP，都可以直接用即览在 iPhone 和 iPad 上打开。

本地渲染，本地保存，不需要上传，也不需要注册账号。

文末有 TestFlight，想试可以直接申请，我开了 8000 个名额。

但我做即览，不只是因为缺一个阅读器。

更直接的原因是：这段时间我越来越明显地感觉到，在 AI 参与内容生产之后，我们交换内容的格式正在变。

很多文本内容开始落到 Markdown，很多展示内容开始落到 HTML。

即览只是这个变化走到手机端时，掉出来的一个小工具。

前几天看到 Obsidian 作者的一句话，我觉得很准：.md 正在成为 AI 文件交互里的一个 Schelling point。

Schelling point 可以翻译成“谢林点”，意思是没有人强制规定，但大家会自然聚到同一个选择上。

Markdown 现在就有点像这样。

没人规定 AI 应该用 Markdown，标准委员会也没有出来宣布过什么。

但在真实使用里，不管是人写给 AI，还是 AI 写给人，最后经常都会落到 .md 文件上。

原因也很朴素。

它是纯文本，模型读写都轻。

它有足够的结构，标题、列表、表格、代码块、链接都能表达。

它又不会像 .docx 那样被包进一层复杂格式里。

人可以直接打开，AI 也可以直接处理，版本管理和 diff 都干净。

但我觉得更重要的是，Markdown 不能再只被理解成“编辑器里的文本”。

它更像是 AI 工作流里的底层数据。

我在 CodePilot 里就是这么用的。

它没有特别复杂的 memory 机制，很多记忆其实就是一组 Markdown 文件。

AI 往里写，AI 从里读，我自己也能打开改。

更进一步，CodePilot 里的 widget 也可以把这些本地 Markdown 和 memory 当作数据来源。

文件变了，组件展示也跟着变。

这时候 Markdown 就不只是“拿来读的一篇文章”了。

它变成了一种很轻的本地数据层：人能看，AI 能读，工具也能基于它生成新的界面和交互。

这也是为什么我觉得，最近很多人继续卷 Markdown 编辑器，方向可能有点窄。

真正有意思的不是再做一个更漂亮的编辑框，而是把 Markdown 当成数据，去构建新的阅读、管理和人机交互方式。

另一端是 HTML。这个趋势最近也越来越明显。

上个月我开源了一个 PPT Skill，生成的就是网页形式的演示文稿。

它 25 天到 1 万 star，后来我在线下答辩、展会和分享里，也反复见到有人用它做出来的 PPT。

这件事让我确认了一点：

很多场景里，大家要的并不是一个标准的 .pptx 文件，而是一个能拿上去讲、能被人看懂、能快速分享的展示物。

刚好 Claude Code 团队最近也在讲同一件事。

他们有篇文章专门写为什么越来越多输出开始用 HTML，而不是 Markdown。

理由很直接：HTML 信息密度更高，更容易做视觉层级，更适合展示图表、布局、交互，也更容易被别人打开和阅读。

这跟我自己的体验很接近。

Markdown 适合沉淀内容，但它一长就难读。几千字、几万字的报告堆在一个 .md 文件里，哪怕结构是对的，人也很难真的读进去。

HTML 反过来。它可以用排版、空间、颜色、图表和交互，把信息组织得更像一个“可以被消费的东西”。它不是更适合存事实，而是更适合让人理解事实。

所以我现在越来越倾向于把这两件事分开看：

Markdown 是数据层，HTML 是展示层。

底层内容用 Markdown 留着，干净、可读、可版本管理。

需要给人看、给人讲、对外分享时，再渲染成 HTML。

这不是某种宏大的新标准，更像是 AI 工作流里自然长出来的一种分工。

内容有了，文件也发出来了，问题出在最后一步：人经常是在手机上打开它。

桌面端还好。你有浏览器，有编辑器，实在不行还有 VS Code。

但手机不是这样。

尤其是你在微信里收到一份 AI 生成的报告、一个网页 PPT、一个 Markdown 文档时，常见体验就是点不开、显示源码、样式坏掉，或者要在几个 App 之间来回跳。这件事很小，但非常烦。

微信这种 IM，本质上不是文件阅读器。

它的优先级是聊天、预览和转发，不是认真打开一个 Markdown 或 HTML 文件。

浏览器也不是为这个场景设计的。

浏览器默认处理的是“你给我一个链接，我帮你打开网页”。

但别人发给你的往往是一个本地文件，不是一个链接。你当然可以绕来绕去把 HTML 丢给浏览器，但整个链路又长又别扭。

很多 Markdown 工具也偏编辑、偏笔记，不一定适合临时打开别人发来的文件。

更不用说有些工具会要求你导入、同步、建库、注册账号。

HTML 还多一层安全问题：一个陌生文件里可能带脚本，你不一定希望它默认执行。

所以我一直觉得这里缺了一个很简单的东西：

在手机上，把 AI 工作流里常见的这些文件，安全、顺手地打开。

这就是即览。

即览没有做成编辑器，也没有接 AI，顺便我必须得吹一下 CodeX 画的这个 App 图标，太可爱了。

我一开始就想得很清楚，它只做三件事：打开、读、收着。

收到文件时，从微信、文件 App 或系统分享面板里选择即览，就能打开。支持 .md、.markdown、.html、.htm、.txt，也支持网页资源打包成的 .zip。

所有文件都在本地处理，不上传，不注册账号。

读 Markdown 的时候，我主要按长文阅读去调。

字号、行距、背景可以改；长表格可以横向滚动；有标题结构的文档可以用目录跳转。

常见的 Obsidian 写法，比如任务列表、Callout、脚注、Frontmatter、标签，也尽量兼容。

也支持夜间模式和颜色主题的切换。

读 HTML 的时候，我更在意“可控”。

它用系统 WebView 本地渲染，支持缩放、横竖屏切换，也可以在手机模式和桌面模式之间切。

动态脚本默认关闭。陌生 HTML 里到底有没有脚本，你通常是不知道的。

所以即览默认不把执行脚本作为前提；遇到确实需要 JS 才能看的页面，再手动打开。

ZIP 也是为真实场景做的。

很多 AI 导出的网页不是单个 HTML，而是 index.html 加一个 assets 文件夹。

即览会解压后自动找入口，本地图片和 CSS 也能正常加载，不至于样式全丢、图片全裂。

打开过的文件会自动留在本地历史里。下次想回看，进 App 就能找到。

重复导入同一个文件不会堆出两份，重要的也可以收藏。

这就是它现在的边界。

它不做云同步，不做账号，不做编辑，也不接 AI。

不是因为这些功能不重要，而是因为一个查看器先应该把“打开并读完”这件事做干净。

现在回头看，即览不是一个孤立的小工具。

上个月我做 PPT Skill，是因为我相信 HTML 会成为 AI 生成演示内容时很自然的一种形态。

它不一定取代 PowerPoint，但在“快速生成一个能讲的东西”这件事上，HTML 足够轻、足够开放，也足够适合模型直接生成。

我做 CodePilot，是因为我相信 Markdown 会成为 AI 协作里很自然的数据和记忆载体。

它不是最漂亮的格式，但它最容易被人、模型和工具同时使用。

即览接的是第三步：

这些格式不能只停在“生成出来”那里，还得让人真的能打开、能读、能收起来。

前两件事偏生产，即览偏消费。

AI 已经能生成 Markdown，也能生成 HTML。

但如果这些文件一到手机上就断掉，那前面的生成体验再顺，也没有真正落到人手里。

即览补的就是这个最后一公里。

即览现在补的只是最浅的一层：收到一个文件，把它打开。

再往后，其实还有几个问题没有解决。

比如管理。

很多人的手机、网盘、聊天记录和各种 App 缓存里，已经散落着大量 Markdown 和 HTML 文件。

它们不是没有价值，只是太分散，找不到，也管不起来。

比如分享。

即览解决的是“别人发给我，我怎么看”。

但反过来，“我做了一份 HTML，怎么让别人顺手打开”，仍然麻烦。

发文件，对方未必打得开；发链接，又需要自己找地方部署。

比如跨设备。

手机上读了一半，回电脑接着看；电脑上生成了一份报告，推到手机上读，这都很自然。

但一旦做同步，就会碰到账号、云端、隐私和复杂度。

即览现在还很小，小到我不太想把它包装成一个大产品。

但它正好卡在我自己每天都会遇到的缝里：

AI 把内容生成出来了，可我只是想在手机上好好看一眼。

你也经常被 Markdown、HTML、网页 PPT 这些文件硌到的话，可以试试。

TestFlight：

也欢迎聊聊你们怎么看这件事：在 AI 参与之后，文档、展示和阅读到底会变成什么样。