即览：手机上看 Markdown 和 HTML，怎么就这么难？ · AI HOT
歸藏(guizang.ai)@op741867
2026-06-04 10:31·29天前
AI 摘要即览是一款iOS/iPad应用，解决手机端无法正常打开AI生成的.md、.html等文件的问题。它本地渲染，无需上传或注册，有8000个TestFlight名额。作者引用Obsidian观点：.md正成为AI文件交互的“谢林点”；Claude Code团队认为HTML更适合展示层。即览定位纯粹：仅打开、阅读和收藏，不编辑、不云同步、不接AI。支持.md/.html/.txt及.zip网页文件，动态脚本默认关闭以确保安全。
歸藏(guizang.ai)@op7418 · X 2026-06-04 10:31·29天前
在 X 看原推· x.comAI 摘要即览是一款iOS/iPad应用，解决手机端无法正常打开AI生成的.md、.html等文件的问题。它本地渲染，无需上传或注册，有8000个TestFlight名额。作者引用Obsidian观点：.md正成为AI文件交互的“谢林点”；Claude Code团队认为HTML更适合展示层。即览定位纯粹：仅打开、阅读和收藏，不编辑、不云同步、不接AI。支持.md/.html/.txt及.zip网页文件，动态脚本默认关闭以确保安全。
这也是为什么我觉得，最近很多人继续卷 Markdown 编辑器，方向可能有点窄。
真正有意思的不是再做一个更漂亮的编辑框，而是把 Markdown 当成数据，去构建新的阅读、管理和人机交互方式。
HTML 正在变成 AI 内容的展示层
上个月我开源了一个 PPT Skill，生成的就是网页形式的演示文稿。
它 25 天到 1 万 star，后来我在线下答辩、展会和分享里，也反复见到有人用它做出来的 PPT。
很多场景里，大家要的并不是一个标准的 .pptx 文件，而是一个能拿上去讲、能被人看懂、能快速分享的展示物。
刚好 Claude Code 团队最近也在讲同一件事。
他们有篇文章专门写为什么越来越多输出开始用 HTML，而不是 Markdown。
理由很直接：HTML 信息密度更高，更容易做视觉层级，更适合展示图表、布局、交互，也更容易被别人打开和阅读。
Markdown 适合沉淀内容，但它一长就难读。几千字、几万字的报告堆在一个 .md 文件里，哪怕结构是对的，人也很难真的读进去。
HTML 反过来。它可以用排版、空间、颜色、图表和交互，把信息组织得更像一个"可以被消费的东西"。它不是更适合存事实，而是更适合让人理解事实。
底层内容用 Markdown 留着，干净、可读、可版本管理。
需要给人看、给人讲、对外分享时，再渲染成 HTML。
这不是某种宏大的新标准，更像是 AI 工作流里自然长出来的一种分工。
但这条链路在手机上断了
内容有了，文件也发出来了，问题出在最后一步：人经常是在手机上打开它。
桌面端还好。你有浏览器，有编辑器，实在不行还有 VS Code。
尤其是你在微信里收到一份 AI 生成的报告、一个网页 PPT、一个 Markdown 文档时，常见体验就是点不开、显示源码、样式坏掉，或者要在几个 App 之间来回跳。这件事很小，但非常烦。
它的优先级是聊天、预览和转发，不是认真打开一个 Markdown 或 HTML 文件。
浏览器默认处理的是"你给我一个链接，我帮你打开网页"。
但别人发给你的往往是一个本地文件，不是一个链接。你当然可以绕来绕去把 HTML 丢给浏览器，但整个链路又长又别扭。
很多 Markdown 工具也偏编辑、偏笔记，不一定适合临时打开别人发来的文件。
更不用说有些工具会要求你导入、同步、建库、注册账号。
HTML 还多一层安全问题：一个陌生文件里可能带脚本，你不一定希望它默认执行。
在手机上，把 AI 工作流里常见的这些文件，安全、顺手地打开。
即览做得很窄：打开、读、收着
即览没有做成编辑器，也没有接 AI，顺便我必须得吹一下 CodeX 画的这个 App 图标，太可爱了。
我一开始就想得很清楚，它只做三件事：打开、读、收着。
收到文件时，从微信、文件 App 或系统分享面板里选择即览，就能打开。支持 .md、.markdown、.html、.htm、.txt，也支持网页资源打包成的 .zip。
读 Markdown 的时候，我主要按长文阅读去调。
字号、行距、背景可以改；长表格可以横向滚动；有标题结构的文档可以用目录跳转。
常见的 Obsidian 写法，比如任务列表、Callout、脚注、Frontmatter、标签，也尽量兼容。
它用系统 WebView 本地渲染，支持缩放、横竖屏切换，也可以在手机模式和桌面模式之间切。
动态脚本默认关闭。陌生 HTML 里到底有没有脚本，你通常是不知道的。
所以即览默认不把执行脚本作为前提；遇到确实需要 JS 才能看的页面，再手动打开。
很多 AI 导出的网页不是单个 HTML，而是 index.html 加一个 assets 文件夹。
即览会解压后自动找入口，本地图片和 CSS 也能正常加载，不至于样式全丢、图片全裂。
打开过的文件会自动留在本地历史里。下次想回看，进 App 就能找到。
重复导入同一个文件不会堆出两份，重要的也可以收藏。
不是因为这些功能不重要，而是因为一个查看器先应该把"打开并读完"这件事做干净。
即览接在前两件事后面
上个月我做 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 参与之后，文档、展示和阅读到底会变成什么样。
即览只是这个变化走到手机端时，掉出来的一个小工具。
Markdown 不只是文本格式，它正在变成 AI 的数据层
前几天看到 Obsidian 作者的一句话，我觉得很准：.md 正在成为 AI 文件交互里的一个 Schelling point。
Schelling point 可以翻译成"谢林点"，意思是没有人强制规定，但大家会自然聚到同一个选择上。
没人规定 AI 应该用 Markdown，标准委员会也没有出来宣布过什么。
但在真实使用里，不管是人写给 AI，还是 AI 写给人，最后经常都会落到 .md 文件上。
它有足够的结构，标题、列表、表格、代码块、链接都能表达。
它又不会像 .docx 那样被包进一层复杂格式里。
人可以直接打开，AI 也可以直接处理，版本管理和 diff 都干净。
但我觉得更重要的是，Markdown 不能再只被理解成"编辑器里的文本"。
它没有特别复杂的 memory 机制，很多记忆其实就是一组 Markdown 文件。
更进一步，CodePilot 里的 widget 也可以把这些本地 Markdown 和 memory 当作数据来源。
这时候 Markdown 就不只是"拿来读的一篇文章"了。
它变成了一种很轻的本地数据层：人能看，AI 能读，工具也能基于它生成新的界面和交互。
这也是为什么我觉得，最近很多人继续卷 Markdown 编辑器，方向可能有点窄。
真正有意思的不是再做一个更漂亮的编辑框，而是把 Markdown 当成数据，去构建新的阅读、管理和人机交互方式。
HTML 正在变成 AI 内容的展示层
上个月我开源了一个 PPT Skill，生成的就是网页形式的演示文稿。
它 25 天到 1 万 star，后来我在线下答辩、展会和分享里，也反复见到有人用它做出来的 PPT。
很多场景里，大家要的并不是一个标准的 .pptx 文件，而是一个能拿上去讲、能被人看懂、能快速分享的展示物。
刚好 Claude Code 团队最近也在讲同一件事。
他们有篇文章专门写为什么越来越多输出开始用 HTML，而不是 Markdown。
理由很直接：HTML 信息密度更高，更容易做视觉层级，更适合展示图表、布局、交互，也更容易被别人打开和阅读。
Markdown 适合沉淀内容，但它一长就难读。几千字、几万字的报告堆在一个 .md 文件里，哪怕结构是对的，人也很难真的读进去。
HTML 反过来。它可以用排版、空间、颜色、图表和交互，把信息组织得更像一个"可以被消费的东西"。它不是更适合存事实，而是更适合让人理解事实。
底层内容用 Markdown 留着，干净、可读、可版本管理。
需要给人看、给人讲、对外分享时，再渲染成 HTML。
这不是某种宏大的新标准，更像是 AI 工作流里自然长出来的一种分工。
但这条链路在手机上断了
内容有了，文件也发出来了，问题出在最后一步：人经常是在手机上打开它。
桌面端还好。你有浏览器，有编辑器，实在不行还有 VS Code。
尤其是你在微信里收到一份 AI 生成的报告、一个网页 PPT、一个 Markdown 文档时，常见体验就是点不开、显示源码、样式坏掉，或者要在几个 App 之间来回跳。这件事很小，但非常烦。
它的优先级是聊天、预览和转发，不是认真打开一个 Markdown 或 HTML 文件。
浏览器默认处理的是"你给我一个链接，我帮你打开网页"。
但别人发给你的往往是一个本地文件，不是一个链接。你当然可以绕来绕去把 HTML 丢给浏览器，但整个链路又长又别扭。
很多 Markdown 工具也偏编辑、偏笔记，不一定适合临时打开别人发来的文件。
更不用说有些工具会要求你导入、同步、建库、注册账号。
HTML 还多一层安全问题：一个陌生文件里可能带脚本，你不一定希望它默认执行。
在手机上，把 AI 工作流里常见的这些文件，安全、顺手地打开。
即览做得很窄：打开、读、收着
即览没有做成编辑器，也没有接 AI，顺便我必须得吹一下 CodeX 画的这个 App 图标，太可爱了。
我一开始就想得很清楚，它只做三件事：打开、读、收着。
收到文件时，从微信、文件 App 或系统分享面板里选择即览，就能打开。支持 .md、.markdown、.html、.htm、.txt，也支持网页资源打包成的 .zip。
读 Markdown 的时候，我主要按长文阅读去调。
字号、行距、背景可以改；长表格可以横向滚动；有标题结构的文档可以用目录跳转。
常见的 Obsidian 写法，比如任务列表、Callout、脚注、Frontmatter、标签，也尽量兼容。
它用系统 WebView 本地渲染，支持缩放、横竖屏切换，也可以在手机模式和桌面模式之间切。
动态脚本默认关闭。陌生 HTML 里到底有没有脚本，你通常是不知道的。
所以即览默认不把执行脚本作为前提；遇到确实需要 JS 才能看的页面，再手动打开。
很多 AI 导出的网页不是单个 HTML，而是 index.html 加一个 assets 文件夹。
即览会解压后自动找入口，本地图片和 CSS 也能正常加载，不至于样式全丢、图片全裂。
打开过的文件会自动留在本地历史里。下次想回看，进 App 就能找到。
重复导入同一个文件不会堆出两份，重要的也可以收藏。
不是因为这些功能不重要，而是因为一个查看器先应该把"打开并读完"这件事做干净。
即览接在前两件事后面
上个月我做 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 参与之后，文档、展示和阅读到底会变成什么样。