飞书终于支持Markdown 最弱格式赢下AI时代
近日,飞书一项看似细微的更新在用户社群中引发了广泛关注。

事情本身并不复杂:飞书云文档终于原生支持直接下载为Markdown格式了。

这虽然只是一个细节功能,但对于经常使用飞书并深度依赖AI助手的用户而言,能立刻感知到使用体验的显著提升。社区中用户们呼吁已久,如今官方终于响应了大家的期盼。
过去,若想将飞书文档导出为Markdown格式(.md文件),过程相当繁琐——要么自行编写插件,要么依赖第三方开源工具。如今,官方已将此选项直接集成至菜单中,甚至文档中的图片也能被完整保留:飞书会将图片保存至自有服务器,并生成公网链接,确保任何AI工具都能顺利读取MD文件中的图片内容。

实际体验远优于自制的插件——毕竟个人开发的插件往往只能处理纯文本,图片信息会全部丢失。这种处理方式确实颇具巧思。
或许有些读者会心存疑虑:Markdown究竟是什么?难道只是支持了一种新格式?这到底能带来什么实际价值?
事实上,只要你在使用AI产品,几乎每天都会接触它,只不过可能未曾留意其名称。例如,在Claude中渲染的回复文本——那些带有加粗、标题、代码块以及列表的内容,排版整洁且层次分明。

这种分层显示的背后,正是Markdown在发挥作用。AI输出的原始内容本质上是一堆纯文本配合简单的符号标记:两个星号包裹代表加粗,井号开头表示标题,三个反引号包裹则为代码块。浏览器或应用程序将这些符号渲染为我们看到的最终样式。

当前各类AI产品的结构化输出、Deep Research报告等,底层几乎都采用Markdown格式。那些层次分明、篇幅冗长的报告,拉到底层查看,几乎都是一个.md文件。
因此,Markdown并非什么高深莫测的技术,它只是一套极为简单的纯文本标记规则,让你无需学习HTML或打开Word,仅凭几个符号就能为文章赋予清晰的结构。
说到这儿,我也曾为Chrome开发过一个小插件,其核心功能正是强行将各类文档保存为MD格式。

已经记不清从何时起,我不再使用PDF,也告别了Word。电脑中所存储的文本文件,几乎全部是MD格式。身边许多深度使用AI的朋友也是如此——AI用得越多,电脑里.md文件的比例就越高,这甚至成了一种衡量“AI使用浓度”的有趣指标。
Markdown似乎在不经意间,已然成为整个数字世界的一种通用语言。而它背后的诞生故事,也同样值得我们回味。
要追溯这段历史,得回到2004年。
那一年,一位名叫John Gruber的博主遇到了一件令他倍感困扰的事情:他想在自己的博客上撰写结构清晰的内容,却又不想编写HTML。当时的博客环境仍需手动处理样式结构。为了实现理想的排版效果,他不得不使用HTML,但HTML的代码通常长这样:

即便是最简单的操作——写个加粗要输入,写个标题要输入。一篇文章写下来,一半时间都耗费在标签上,写作思路屡屡中断。如果用Word撰写,又无法直接在网页博客上渲染,最终还是得转换成HTML,而导出的HTML代码往往十分杂乱,充斥着多余的标签和样式。
Gruber开始思考:是否存在一种方法,让我能够使用纯文本进行写作,但输出的内容看起来富有结构,同时又能轻松地转换为HTML?
他当时注意到一个非常有趣的现象:2004年人们在撰写邮件时,已经自发形成了一套排版习惯。想要强调某个词语,就在两边加上星号;想要列出几个要点,就用短横线开头;想要写标题,就在前面加上几个井号。这些做法成为了许多人默认遵守的纯文本“民间约定”。
Gruber灵机一动,将这些散落在邮件中的习惯整理成了一套统一的语法,并编写了一个Perl脚本,能够自动将该语法转换为HTML。他将这个成果命名为——Markdown。
这个名字本身就很有意思。HTML的全称是HyperText Markup Language,即标记语言。Gruber为自己的发明取了一个反义词:Mark-down,寓意“把标记放下来”,听起来有些抽象,但其精髓在于——完全不想被标记束缚,只想专注于文字本身。
2004年3月,Gruber在他的博客Daring Fireball上正式发布了Markdown的第一版规范。

但这里有一个许多人可能不知道的细节:Markdown并非Gruber一人的成果,他有一位合作者——当时年仅17岁的天才少年,Aaron Swartz。

这是一位极具影响力的人物。如果你对互联网历史感兴趣,Aaron Swartz这个名字想必不会陌生。14岁时他便参与了RSS 1.0的开发,随后又参与创建了Creative Commons(知识共享协议),后来还联合创办了Reddit——没错,正是如今知名的Reddit社区。

在Markdown项目中,Swartz负责了语法设计中非常核心的部分。例如我们今天广泛使用的井号标题语法——#、##、###,这一设计就源自Swartz此前开发的另一款标记语言atx。Gruber自己也曾坦言,正是因为Aaron的想法、反馈和测试,Markdown才得以变得如此出色。

一位科技博主,一位17岁的天才少年。背后没有任何机构支持,也不涉及商业模式,纯粹出于觉得写HTML太过繁琐,想让写作这件事变得更为纯粹——无需在意格式和样式,只需聚焦于内容本身。
就这样,Markdown在安静中走过了二十年的发展历程。
最初面世时,使用者寥寥无几,仅限于一小部分博客作者。真正的转折点出现在2008年——那一年,GitHub正式上线。

GitHub选择将Markdown作为README、Issue、Pull Request、Wiki的默认格式。这一决定使得全世界的开发者每天都在读写Markdown,大多数人甚至没有将其视为一种标记语言,只觉得这是GitHub上一种非常自然的书写方式。
随后,Reddit、Slack、Discord纷纷跟进,再后来是Notion、Obsidian、Typora。Markdown从一个小小的脚本,逐渐演变为数字世界的基础设施。
但真正让Markdown登上巅峰的,是它自己可能都未曾预料到的事件——AI时代的到来。
它是纯文本,因此大模型易于生成;它具有结构,因此人类便于阅读;它能够被渲染,因此界面看起来如同富文本;它足够灵活,即便模型输出偶尔缺少一个空格、遗漏一个标签,也不会导致整体崩溃。
因为它足够“薄弱”——没有字体、没有颜色、没有排版、没有分栏、没有页眉页脚、没有批注修订、没有宏、没有嵌入对象。正因如此,它能够在任何平台上得到兼容。
Markdown直接成为了与大模型交互的“天选语言”。大模型持续输出Markdown格式的内容,人类也发现,使用结构化的语言撰写Prompt,效果往往更佳。


这便形成了一个极为有趣的闭环。到了Agent时代,各类Agent产品更是通过实际行动做出了选择——所有的规范文档、约束文档、记忆存储,全部采用.md文件。这些内容,相信大家已经相当熟悉了。

人类与AI之间那个最奇妙的连接点,竟然就是Markdown。
而且,Markdown对AI而言还有一个特别实惠的好处——节省Token。同样的内容,使用HTML表达的Token数量远多于Markdown。与标题
##标题的信息量完全相同,但后者的Token消耗却大幅减少。在大模型时代,Token就是成本。
前阵子出现了一场颇具争议的讨论。Claude Code的Thariq发表了一篇题为《The Unreasonable Effectiveness of HTML》的文章,大意是:Markdown已经过时,在AI时代应该全面转向HTML——因为HTML能承载更丰富的信息,能够嵌入样式、交互和可视化,AI生成HTML后人类可以直接在浏览器中看到最终效果,无需再进行一次渲染。

这篇文章迅速引爆了社区,评论区争论不休。坦率地说,他的观点有没有道理?确实有道理。HTML所能表达的内容远远超过Markdown——用Markdown无法画出一个交互式的diff对比视图,也无法制作一份带颜色标注的代码审查报告。
但这个观点混淆了两件事:信息的展示与信息的流转——尤其是在AI与人类之间的展示与流转。
HTML是一种极佳的展示格式,其核心能力是“这个东西在屏幕上长什么样”。如果你想要制作漂亮的报告、可交互的mockup、带配色的设计稿,毋庸置疑,HTML是最强的选择。
但Markdown是一种更优秀的流转格式,其核心能力始终是“这段信息的结构是什么样的”。在人类与AI协作的过程中,信息大部分时间处于流转状态,而非展示状态。撰写一份需求文档交给AI,AI阅读后生成代码,代码又传递给另一个Agent进行审查,审查结果再反馈回用户。在整个过程中,信息在不同主体之间流动,每个主体都需要快速理解内容的结构和含义。在此场景下,HTML的丰富性反而成为负担——一个中真正有用的信息可能只有一句话,但AI却要花费大量Token去解析那堆CSS类名和嵌套标签。
Markdown则完全不同:##标题,三个字符,AI立刻就能识别出这是一个二级标题。没有噪音,没有冗余,信息密度达到最大化。
因此,HTML和Markdown从来就不是替代关系,而是分工关系。Markdown是信息的底层载体,负责在人类与AI之间高效流转;HTML是信息的最终呈现层,负责在展示给人类时美观易读。换一种说法:Markdown是数据层,HTML是视图层。你不会用视图层来存储数据,对吧?
这就是Markdown的力量所在。
最有意思的是,虽然Thariq在那篇文章中大力推崇HTML,但他自己的文章,却是用Markdown撰写的。

无他,因为Markdown的流通性实在太高了——不依赖任何软件、任何公司、任何平台,你的内容就是你自己的内容,永远可读,永远可以迁移。
这种哲学,其实与Aaron Swartz一生所追求的理念完全一致:信息的自由流动。Swartz帮助开发了RSS,使信息能够自由地在不同平台之间流动;帮助创建了Creative Commons,让创作者能够自由选择如何分享自己的作品;帮助创造了Markdown,让写作能够自由地不被任何格式所束缚。
2013年1月,Aaron Swartz在纽约的公寓中自杀身亡。那时他只有26岁。

在他离世后的十几年里,他所参与创造的这些事物——RSS、Creative Commons、Markdown、Reddit——全都成长为互联网的基础设施。
在AI时代,或许我们真的可以彻底告别Word、PDF之类的格式。因为Word和PDF是为打印时代设计的格式,而Markdown与HTML一起,是为屏幕时代设计的格式——一个负责存储与流转,一个负责展示。
所以如果有人问,AI时代应该用什么格式保存文件?答案只有两个字:.md。
说真的,如果你还在用Word撰写日常文档,不妨尝试换成Markdown。找一个顺手的编辑器——Obsidian也好,飞书云文档也罢。你会发现,当文件变成纯文本的那一刻,你获得了一种非常奇妙的自由感:你的文字,就是你的文字。纯粹的,干净的,自由的。
就像2004年,那位博主和那位少年,最初所期望的那样。
游乐网为非赢利性网站,所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系youleyoucom@outlook.com。
同类文章
修Bug被Gemini追删代码致宕机修复报告现编
最近,一起堪称“教科书级别”的AI Agent IDE翻车事件在开发者社区引发热议。这起事故值得所有依赖AI编程工具的开发者,尤其是那些已经在生产环境中对AI Agent 授予较高权限的团队,进行深刻反思。 简单回顾:5月26日,一位开发者要求Gemini 3 5(运行在Agent IDE环境中)修
Notion AI运营指南:自动归纳用户反馈
其实,想在 Notion 中高效搞定用户反馈的自动归纳,并不复杂。下面这四种 AI 方法,基本覆盖了从单条处理到全局分析的常见场景。 如果你也在用 Notion 收集用户反馈——无论是问卷、邮件、客服记录,还是社群发言——但总觉得信息碎片化严重,难以提炼共性问题和核心诉求,那很可能是因为缺少一套结构
AI给出的答案为何总不符期望?原因解析
大模型能力强大,但提问方式不当会导致结果不理想。核心在于精准提问,通过角色设定、背景介绍、明确任务、实现路径和输出要求这五个关键步骤逐步细化问题,才能大幅提升AI回答的质量和精准度。
Anthropic新AI聊天机器人模型声称在多项测试中击败OpenAI GPT-4
2024年3月5日,人工智能领域迎来了一位重要参与者——由OpenAI前员工创立的Anthropic公司正式推出了Claude 3系列模型。这次发布极具分量:新模型不仅在性能上与Google和OpenAI的顶级产品并驾齐驱,部分指标甚至实现超越。要理解此次升级的真正价值,先关注几个关键变化。首先是多
Trae对Deno与Bun运行时的AI代码补全支持程度全面详解
如果你在使用 Trae 进行 AI 代码补全时发现,它对 Deno 或 Bun 运行时的提示不够精准——例如类型定义缺失、API 无法正确识别——那很可能不是代码本身有误,而是 Trae 的底层配置尚未适配。简而言之,Trae 对于非 Node js 运行时的标准库支持尚未实现“开箱即用”。下面我们
- 日榜
- 周榜
- 月榜
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10
相关攻略
2015-03-10 11:25
2015-03-10 11:05
2021-08-04 13:30
2015-03-10 11:22
2015-03-10 12:39
2022-05-16 18:57
2025-05-23 13:43
2025-05-23 14:01
热门教程
- 游戏攻略
- 安卓教程
- 苹果教程
- 电脑教程
热门话题

