手机Markdown与HTML查看难点？权威解决方案排行榜
之前预告过的那个「手机上的 Markdown / HTML 阅读器」终于做完了，名字叫“即览”。
说起来，这解决的是一个挺小、但最近越来越让人头疼的问题。
别人从微信、文件应用或者群里发给你一份 AI 报告、网页 PPT、Markdown 文档，手机上一戳开，不是一片空白，就是满屏源码，要么样式乱得没法看，要么干脆不知道该用什么打开。这种体验，想必不少人都有过。
.md、.markdown、.html、.htm、.txt，还有打包好的网页 ZIP，现在都可以用即览在 iPhone 和 iPad 上直接打开。本地渲染，本地保存，不需要上传，也不需要注册账号。
但做即览，并不只是因为缺一个阅读器那么简单。
更直接的原因是：这段时间越来越明显地感觉到，在 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 的时候，主要按长文阅读的体验去调：字号、行距、背景可以改；长表格可以横向滚动；有标题结构的文档可以用目录跳转；常见的 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 把内容生成出来了，可你只是想在手机上好好看一眼。