AI 时代，内容生产方式和软件架构正在变化。传统富文本编辑器把内容与展示绑定，Markdown 更适合 AI 生成、理解、存储和多端渲染。
如果今天让我重新设计一个内容管理系统，我可能会直接取消传统富文本编辑器。
不是换一个更好用的编辑器，也不是在原来的编辑器里增加一个 AI 助手，而是从架构上重新思考：我们真的还需要富文本编辑器吗？
过去十几年，只要涉及文章、新闻、产品介绍、技术文档，我们的第一反应就是引入一个富文本编辑器。
UEditor、TinyMCE、CKEditor、Quill……
标题、字体、颜色、段落、图片、表格，各种工具栏一应俱全。
因为过去内容是人写的，人需要通过鼠标和键盘完成输入、排版和格式调整。
但 AI 的出现，正在改变这一切。
当 AI 已经能够直接生成内容、组织结构、完成排版，我们为什么还要保留一套为人工操作设计的复杂工具？
我认为，传统富文本编辑器正在成为 AI 时代的软件遗留物，而 Markdown 正在成为新的内容基础设施。
一、传统富文本编辑器，正在成为技术债
传统富文本编辑器最大的问题，不是不好用，而是它把内容和展示混在了一起。
我们来看一段典型的富文本 HTML：
<span style="color:#333;font-size:14px;
margin-left:10px;font-weight:bold;">
产品核心优势
</span>我们真正想表达的内容其实只有一句：
产品核心优势。
但存储的数据却包含了大量字体、颜色、边距等展示信息。
这些信息对 AI 理解内容没有任何帮助。
当这些内容进入 RAG 知识库、向量检索系统或者 AI Agent 时，还需要额外处理 HTML 标签、样式噪声和各种历史遗留格式。
不仅增加了数据处理成本，也增加了内容解析的不确定性。
更麻烦的是，不同编辑器生成的 HTML 往往并不完全兼容。
换一个编辑器，可能就要重新处理历史数据；换一个前端框架，又可能需要重新适配渲染逻辑。
我们原本只是想存一篇文章，最后却维护了一套复杂的 HTML 格式体系。
这不是内容管理，而是在维护格式。
过去我们为了让人方便地排版，把内容和样式绑在了一起；现在 AI 已经可以直接生产内容，这种设计反而成了负担。
二、AI 生成内容，天然更适合 Markdown
富文本编辑器诞生的逻辑，是让人通过可视化工具生产内容。
但 AI 的内容生产逻辑完全不同。
我们只需要告诉 AI：
写一篇产品介绍，包含产品背景、核心功能、技术优势和参数对比。
AI 就可以直接生成：
# 产品介绍
## 产品背景
这是一款面向企业用户的智能管理产品。
## 核心功能
- 自动化数据采集
- 智能分析与处理
- 多端协同管理
## 技术优势
| 维度 | 优势 |
|---|---|
| 效率 | 自动化处理 |
| 成本 | 降低人工投入 |
| 扩展性 | 支持模块化扩展 |这就是 Markdown。
它本身就是一种简洁的结构化表达方式。
标题就是标题，列表就是列表，表格就是表格。
AI 可以直接生成，人可以直接阅读，程序可以直接解析。
Markdown 在 AI 时代有几个天然优势：
第一，生成成本低。
大语言模型非常擅长生成 Markdown，不需要操作复杂的编辑器 API，也不需要生成冗长的 HTML。
第二，理解成本低。
Markdown 的结构清晰，AI 可以直接理解标题、段落、列表和代码块，不必先处理大量与内容无关的样式信息。
第三，版本管理简单。
它本质上是纯文本，可以直接进入 Git，进行版本对比、差异分析和历史追踪。
第四，跨平台能力强。
同一份 Markdown 内容，可以渲染成网页、技术文档、知识库，甚至进一步转换成 PDF、Word 和 PPT。
内容本身不再依赖某一个编辑器。
既然 AI 天然能够生产 Markdown，我们为什么还要强行把它转换成富文本，再存入数据库？
这本身就是一条多余的数据转换链路。
三、人类需要漂亮的页面，但不需要在存储阶段完成排版
有人可能会反问：
不用富文本编辑器，文章怎么排版？用户看到的内容怎么保证美观？
我认为这是把两个完全不同的问题混在了一起。
内容存储和内容展示，本来就应该分离。
我们可以把整个内容系统拆成三个部分。
第一层：内容存储。
统一使用 Markdown 保存文章、新闻、产品说明和技术文档。
对于复杂业务数据，使用 JSON 或 YAML 保存结构化元数据。
不把字体、颜色、边距等展示属性混入内容本身。
第二层：内容渲染。
前端通过 Markdown 渲染引擎，将内容转换成 HTML。
再通过统一的 CSS 设计系统，控制标题、段落、图片、表格、引用和代码块的展示效果。
不同终端可以使用不同的排版模板。
手机、平板、桌面端，各自适配自己的展示规则。
第三层：内容消费。
同一份内容，可以服务于不同的消费者：
- 人类用户：看到经过精美排版的网页。
- AI Agent：直接读取原始 Markdown。
- 搜索引擎：读取语义清晰的 HTML 页面。
- 其他业务系统：通过 API 获取 Markdown 和结构化元数据。
一份内容，多种呈现。
不需要为不同终端重复维护多套内容。
这才是内容与展示分离真正的价值。
四、网站 SEO 不会消失，但规则正在发生变化
如果网站全面采用 Markdown 作为内容源，搜索引擎怎么办？
这个问题必须回答。
因为过去我们建设网站，SEO 几乎是内容架构中最重要的考虑因素之一。
但这里需要明确一个概念：
Markdown 是内容源，HTML 是网页交付格式，两者并不冲突。
我们没有必要为了 SEO 而把 HTML 当成内容的唯一存储格式。
正确的方式应该是：
- 后台以 Markdown 保存内容。
- 发布时自动编译成语义化 HTML。
- 使用 SSR（服务端渲染）或 SSG（静态生成），确保搜索引擎能够获取完整正文。
- 自动生成 Title、Description、Canonical、Open Graph 等元信息。
- 根据业务内容生成 Schema.org 结构化数据。
- 自动维护 Sitemap 和内部链接。
这样既保留 Markdown 的简洁性，也不牺牲传统 SEO。
但更值得关注的是，SEO 本身也在发生变化。
过去我们主要考虑搜索引擎能不能找到网站、页面能不能获得关键词排名。
现在，随着生成式 AI 搜索和问答产品的发展，我们还需要考虑：
- AI 能不能准确理解企业提供什么产品和服务？
- 能不能找到对应的产品参数、技术说明和案例？
- 内容是否有明确的事实依据和来源？
- AI 在回答用户问题时，是否有理由引用这个网站？
这就是大家正在讨论的 GEO（Generative Engine Optimization）。
传统 SEO 关注搜索结果中的可见性，而面向 AI 的内容优化，还需要关注内容能否被理解、提取和引用。
网站不再只是关键词的集合，而应该成为一个结构清晰、可信、可验证的知识体系。
五、llms.txt：给 AI 一张网站内容地图
这里就不得不提到一个新的技术概念：llms.txt。
如果说 robots.txt 是告诉爬虫哪些地方可以访问，sitemap.xml 是告诉搜索引擎网站有哪些页面，那么 llms.txt 的设计目标，就是告诉 AI：
这个网站是什么，哪些内容最重要，应该优先阅读哪些页面。
例如：
# Example Technology
> 企业级 AI 与数字化解决方案服务商。
## 产品
- [产品中心](https://example.com/products)
产品体系与核心能力介绍。
- [解决方案](https://example.com/solutions)
面向不同行业的业务解决方案。
## 技术内容
- [技术架构](https://example.com/architecture)
产品技术架构与设计理念。
- [技术博客](https://example.com/blog)
AI、软件工程与数字化技术文章。它本质上是一份 Markdown 格式的网站内容索引。
进一步，我们还可以为重要网页提供对应的 Markdown 版本。
例如：
https://example.com/about
https://example.com/about.md人类访问正常网页，AI 在支持相应内容入口的情况下，可以直接获取更干净的 Markdown 内容。
不需要解析导航栏、广告、脚本和复杂 HTML，就能获得核心信息。
当然，这里需要保持技术上的严谨：llms.txt 目前仍是社区提出的探索性规范，并不是 Google 等主流搜索引擎承诺支持的排名标准，也不能保证 AI 平台一定会读取它。
但它代表了一个值得关注的方向：
网站应该主动为 AI 提供更容易发现和理解的内容入口。
与其让 AI 每次都从复杂网页中提取信息，不如主动提供结构清晰的内容。
六、别再给新系统默认安装富文本编辑器了
如果把前面的思路整合起来，我认为未来的网站和内容管理系统应该采用一套新的架构。
过去：
人工输入
↓
富文本编辑器
↓
HTML
↓
数据库存储
↓
前端展示未来：
自然语言需求
↓
AI Agent
↓
Markdown + JSON
↓
统一内容存储
↓
多端渲染与业务消费具体可以分成几个层次：
内容生产层：AI Agent + 自然语言。
用户通过自然语言描述需求，AI 负责内容生成、修改、补充和维护。
内容资产层：Markdown + JSON。
Markdown 负责文章、新闻、知识库和技术文档；JSON / Schema 负责业务数据、结构化信息和复杂组件。
内容渲染层：HTML + CSS。
根据不同业务场景，生成网页、移动端页面、PDF、Word 等不同形式。
内容分发层：SEO + GEO。
传统搜索引擎通过 HTML、Sitemap 和结构化数据发现网站；AI 内容消费则可以通过 Markdown、API 和 llms.txt 等入口获得内容。
对于新系统，我更倾向于采用这样的原则：
- 文章、新闻、知识库：Markdown。
- 产品资料、业务数据：JSON / Schema。
- 图片、视频、附件：独立资产管理。
- 内容展示：统一渲染引擎。
- 内容生产：AI Agent + 自然语言。
- 人工干预：轻量 Markdown 编辑与预览。
- 网站分发：SEO 基础设施 + AI 内容入口。
不要再把一个复杂的富文本编辑器，当成所有内容系统的默认基础设施。
七、内容生产方式变了，软件设计也应该改变
我觉得，AI 时代的软件架构正在经历一个很有意思的变化。
过去，我们围绕用户操作设计软件。
用户打开什么页面，点击什么按钮，填写什么表单，使用什么编辑器，最后完成什么业务。
现在，我们应该反过来思考。
用户表达业务意图，AI 理解任务，调用业务能力，生成或修改结构化内容，最后由系统完成展示和交付。
富文本编辑器只是其中一个典型例子。
它曾经是互联网内容生产的重要基础设施，但当 AI 可以直接生成、理解和修改内容时，我们就没有必要再把一个复杂的可视化编辑器作为所有内容系统的默认配置。
当然，复杂的动态表单、交互式图表、业务组件，依然需要 JSON、Schema 和专门的可视化编辑能力。
但这些应该作为独立的业务能力存在，而不是全部塞进一个富文本编辑器。
我甚至认为，对于新项目，应该改变一个默认习惯：
不要一开始就想着引入富文本编辑器。
先考虑内容是否可以用 Markdown 表达，业务数据是否应该使用 JSON，复杂组件是否应该独立建模。
只有当人工可视化编辑确实有价值时，再引入相应的编辑器。
过去，我们围绕编辑器组织内容，围绕 HTML 构建页面，围绕 SEO 争夺搜索流量。
未来，我们应该围绕内容模型组织系统，让内容同时服务人类、搜索引擎和 AI。
富文本编辑器解决的是过去人如何生产内容的问题。
Markdown 代表的，则是 AI 时代内容如何生产、理解和流动的新方式。
AI 时代，Markdown 彻底杀死富文本编辑器。