![]()
之前预告过的那个「手机上的 Markdown / HTML 阅读器」做完了,叫 即览。
它解决的是一个很小、但最近越来越烦的问题
别人从微信、文件 App 或群里发你一份 AI 报告、网页 PPT、Markdown 文档,手机上点开不是空白,就是源码,要么样式全坏,要么根本不知道该用什么打开。
.md、.markdown、.html、.htm、.txt,还有打包好的网页 ZIP,都可以直接用即览在 iPhone 和 iPad 上打开。
本地渲染,本地保存,不需要上传,也不需要注册账号
文末有 TestFlight,想试可以直接申请,我开了 8000 个名额。
![]()
但我做即览,不只是因为缺一个阅读器。
更直接的原因是:这段时间我越来越明显地感觉到,在 AI 参与内容生产之后,我们交换内容的格式正在变。
很多文本内容开始落到 Markdown,很多展示内容开始落到 HTML。
即览只是这个变化走到手机端时,掉出来的一个小工具。
Markdown 不只是文本格式,它正在变成 AI 的数据层
前几天看到 Obsidian 作者的一句话,我觉得很准:.md 正在成为 AI 文件交互里的一个 Schelling point。
Schelling point:可以翻译成"谢林点",意思是没有人强制规定,但大家会自然聚到同一个选择上。
Markdown 现在就有点像这样。
没人规定 AI 应该用 Markdown,标准委员会也没有出来宣布过什么。
但在真实使用里,不管是人写给 AI,还是 AI 写给人,最后经常都会落到 .md 文件上。
![]()
原因也很朴素。
轻量:它是纯文本,模型读写都轻。
结构:它有足够的结构,标题、列表、表格、代码块、链接都能表达。
开放:它又不会像 .docx 那样被包进一层复杂格式里。人可以直接打开,AI 也可以直接处理,版本管理和 diff 都干净。
它更像是 AI 工作流里的底层数据
![]()
我在 CodePilot 里就是这么用的。
它没有特别复杂的 memory 机制,很多记忆其实就是一组 Markdown 文件。
AI 往里写,AI 从里读,我自己也能打开改。
![]()
更进一步,CodePilot 里的 widget 也可以把这些本地 Markdown 和 memory 当作数据来源。
文件变了,组件展示也跟着变。
这时候 Markdown 就不只是"拿来读的一篇文章"了。它变成了一种很轻的本地数据层:人能看,AI 能读,工具也能基于它生成新的界面和交互。
![]()
这也是为什么我觉得,最近很多人继续卷 Markdown 编辑器,方向可能有点窄。
真正有意思的不是再做一个更漂亮的编辑框,而是把 Markdown 当成数据,去构建新的阅读、管理和人机交互方式。
HTML 正在变成 AI 内容的展示层
另一端是 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 的时候,我主要按长文阅读去调。
1字号、行距、背景可以改
2长表格可以横向滚动
3有标题结构的文档可以用目录跳转
4常见的 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:https://testflight.apple.com/join/sv7KTqn9
也欢迎聊聊你们怎么看这件事:在 AI 参与之后,文档、展示和阅读到底会变成什么样。
文章来自于"歸藏的AI工具箱",作者 "歸藏的AI工具箱"。