你的文档，AI根本看不懂：Rspress 2.0撕开了技术写作的遮羞布
你的技术文档正在被GPT-4、Claude 3.5 Sonnet疯狂"阅读"。
但说实话，它们看懂了吗？
别急着杠。你把一个渲染好的HTML页面丢给AI，就像把一本精装书的扫描件发给一个需要纯文本的盲人——花里胡哨的CSS、交互式组件、动态路由，对AI来说全是噪音。Rspress 2.0这次干了一件事，直接把遮羞布扯了：文档不仅要为人类可读，更要为机器可解。
HTML转Markdown？这是2025年最愚蠢的技术债
说白了，现在绝大多数"AI-friendly"的文档方案，都是在偷懒。
Docusaurus、VitePress、甚至Next.js的文档模板，默认的逻辑是：先为人类渲染好看的页面，等AI来了，再把HTML反向解析成Markdown。这操作有多蠢？就像把红烧肉打成肉泥，然后试图让AI还原出猪肉的口感。
问题在于，现代文档早就不是静态Markdown了。MDX里的React组件、动态的Tab切换、代码预览沙盒、甚至是根据API状态实时生成的表格——这些东西转成HTML后，对AI来说就是一堆无意义的div嵌套。你把这坨东西喂给RAG系统， retrieval出来的都是CSS类名和JavaScript事件绑定，真正的语义信息早丢了。
Rspress 1.x也这毛病。但2.0版本他们醒悟了：既然AI迟早要读，为什么不从一开始就为它写？
SSG-MD：这次是真·AI原生
Rspress 2.0搞了个叫SSG-MD（Static Site Generation to Markdown）的东西。别被名字骗了，这不是简单的"静态生成Markdown"，而是一次文档构建流程的范式强奸。
传统SSG（静态站点生成）的思路是：构建时把React组件渲染成HTML，浏览器看HTML，人类爽了。SSG-MD的逻辑是：构建时同时生成两份产物——一份HTML给人类，一份纯净Markdown给AI。
关键在这里：它不是在HTML生成后再转换，而是在React虚拟DOM层面就直接提取语义。你的自定义组件可以通过import.meta.env.SSG_MD判断当前是给人看还是给AI看，然后输出不同的内容。给人看是交互式Tab，给AI看是结构化的**Tab: ${label}**标记。
这他妈才是AI-native的正确打开方式。不是事后补救，而是原生支持。就像给AI专门写了一个"盲文版本"，而不是让它在视觉设计的废墟里考古。
llms.txt：给AI的README，不是给人类的
Rspress 2.0还内置了llms.txt生成。很多人不懂这玩意儿的杀伤力，以为就是另一个sitemap.xml。
错得离谱。
sitemap是给搜索引擎爬虫的，llms.txt是给大语言模型的。它不只是URL列表，而是结构化的问题-答案对。Rspress在构建时自动提取文档的层级结构、关键段落、甚至代码示例的上下文，生成一份AI可以直接消费的"知识地图"。
这意味着什么？意味着以后Claude Code读你的文档库，不需要再瞎猜哪个页面包含useDark hook的用法。它直接看llms.txt，精准定位到API参考章节，甚至能拿到相关的类型定义和示例代码。
你的文档从"网页"变成了"数据库"。
开发者们，该重新学写文档了
这事没那么复杂，但影响很深远。
Rspress 2.0释放了一个信号：技术文档正在从UI层下沉到数据层。以后区分初级和高级开发者的标准，可能不再是LeetCode刷得怎么样，而是你的文档GPT能不能秒懂。
别小看这个转变。当文档开始为AI优化，内容生产本身就会变异。你会开始考虑：
- 这个组件在SSG-MD模式下该暴露什么语义？
- 我的文档结构对RAG系统的向量切分友好吗？
- llms.txt里的上下文窗口怎么分配最合理？
写文档从"排版美化"变成了"知识工程"。
写在最后
Rspress 2.0可能没意识到，他们开启了一个潘多拉魔盒。当文档开始原生支持AI消费，那些还在用传统Markdown+HTML转译方案的框架，看起来就像在用算盘对抗计算器。
但这里有个残酷的问题：如果AI能直接读结构化的llms.txt和SSG-MD产物，那人类还需要看那些花里胡哨的文档网站吗？还是说，未来的技术文档本质上就是一份给AI的数据集，而人类只是在偶尔翻阅AI生成的摘要？
说实话，当你的文档主要是写给GPT看的，你其实已经在训练下一个取代你的模型了。
芝士AI吃鱼
下次写文档前，先问问GPT：这段你能看懂吗？
