AI 能否读取文档，关键在于普通链接能否直接返回正文。本文解析 JavaScript 渲染问题，以及 Markdown、llms.txt 和 MCP 的作用。
当用户把一篇产品文档的链接发给 AI，期望它总结内容或回答问题时，AI 能否顺利读取文章？
答案不一定取决于文档写得有多好，而可能取决于一个更基础的问题：打开普通链接时，服务器返回的究竟是文章正文，还是一个等待加载的空页面。
这个问题不仅影响 AI 问答，也关系到搜索抓取、社交平台链接预览，以及用户能否方便地获取信息。
一个测试：两个链接，两种读取过程
原文作者曾在 ChatGPT 桌面应用中测试两个文档链接，并分别提出相同的问题：
请查看这个链接，用几句话概括它的内容。
第一个链接来自采用新版阅读界面的文档门户。ChatGPT 用了约 13 秒完成回答，其中部分时间用于启动新对话。它直接获取页面，读到正文后，概括了文章主题。
第二个链接来自采用旧版阅读界面的测试门户。ChatGPT 最终也读出了文章内容，但整个过程用了约 1 分 24 秒。
差别不只是时间。新页面经过一次抓取就返回了正文；旧页面的首次抓取结果却只有“Loading…”（加载中）。
为了获取旧页面的内容，桌面应用进一步执行了搜索，使用内置浏览器打开页面，等待 JavaScript 完成渲染，再从生成的 HTML 中提取文章。换成常规的 ChatGPT 网页版时，同一旧链接没有经过这些额外步骤，因此未能读取正文。
这不是一项严格的性能基准测试。 两个链接来自不同门户，文章主题也不同，因此不能据此断言新版页面一定比旧版快多少倍。这个测试说明的是：即使链接在人类浏览器中可以正常打开，AI 也可能需要经过额外操作才能读到内容，甚至根本无法读取。
为什么人能看到文档，AI 却只能看到“加载中”？
问题出在旧版文档页面的加载方式。
旧版阅读界面的文章链接使用了
#!，例如：https://example.com/docs/#!article在 URL 中，
# 后面的内容称为片段标识符。浏览器向服务器发送请求时，这部分内容通常不会发送给服务器。因此，当工具请求上述链接时，服务器首先返回的可能只是一个通用的页面框架。之后，浏览器再运行 JavaScript，读取
# 后面的信息，并加载对应的文章。对于使用浏览器的人来说，这一过程通常自动完成，最终看到的是完整文档。但有些 AI 工具或文本抓取工具不会执行 JavaScript，只读取服务器最初返回的内容。它们看到的可能只是页面框架和“Loading…”，而不是文章正文。
这也解释了为什么同一个链接在人类用户面前表现正常，在 AI 工具面前却可能失效。
搜索引擎能处理，不代表所有工具都能处理
一些搜索引擎能够渲染 JavaScript 页面，例如 Googlebot 可以处理许多依赖 JavaScript 的内容。但这并不意味着所有抓取工具都有同样的能力，也不意味着渲染后的内容一定会被及时收录。
社交平台的链接预览也可能受到影响。原文提到，旧版文档门户中，不同文章分享到 Slack 或 LinkedIn 后，预览可能都显示为同一个通用标题，无法准确反映各篇文章的内容。
对于用户来说，预览不准确会降低链接的可读性和可信度；对于无法执行页面渲染的 AI 工具来说，问题更直接：如果它拿不到正文，就无法基于正文回答。
因此，在建设在线帮助中心时，除了检查页面在浏览器中的展示效果，也应测试搜索引擎、链接预览工具和 AI 是否能够获取有效内容。
有了 Markdown、llms.txt 和 MCP，为什么还要关注普通链接？
为了方便 AI 获取文档，企业可以提供多种内容访问方式，例如：
- Markdown 文档：以更简洁的文本格式提供文章内容，减少页面样式和脚本的干扰。
- llms.txt：为支持该文件的工具提供文档入口或内容索引。
- MCP：通过标准化方式，让兼容的 AI 工具连接相关服务或数据源。
这些方式各有用途，但它们通常不会在用户粘贴普通链接时自动生效。
例如，某些文档平台支持在文章地址后添加
.md，以获取 Markdown 版本；但通用聊天机器人未必知道这个规则，也未必会主动尝试。类似地，工具只有在支持并使用 llms.txt 时，才能利用其中提供的索引。MCP 则需要相应的连接或配置，不能假设每次打开链接时都会自动启用。原文中的测试正是如此：用户给 ChatGPT 的是普通页面链接，因此实际决定读取结果的，是这个链接首次返回了什么。
这些 AI 友好能力值得建设，但不能替代对普通文档链接的检查。如果用户最常做的事情是复制网址并发给 AI，那么网址本身是否容易被读取，就是文档体验的一部分。
如何检查文档是否方便 AI 读取？
可以从一篇真实、公开的文档开始，而不必先搭建复杂的测试流程。
将文章链接粘贴给常用的 AI 工具，请它概括内容或回答文中的一个具体问题。检查它是否真的读取了文章，是否能够准确引用关键信息，以及过程中是否出现“无法访问”“正在加载”等提示。
如果测试结果不理想，可以进一步排查：
- 首次请求是否返回正文。 如果返回内容只有页面框架或加载提示，依赖简单抓取的工具可能无法获取文章。
- 正文是否过度依赖 JavaScript 渲染。 可以考虑服务端渲染或静态生成等方式，让初始响应包含有效内容。
- 访问权限是否符合预期。 公开文档需要允许目标工具访问；内部文档则应保留必要的身份验证和权限控制，不应为了方便抓取而公开敏感信息。
- 页面信息是否清晰。 准确的标题、正文结构和页面描述，有助于用户及支持这些信息的工具理解页面。
- AI 是否能给出可靠来源。 对于知识库问答，除了检查答案，还应核对来源链接是否指向相关原文。
在实际建设中，企业可以使用 Baklib 知识库统一管理产品文档、操作指南和常见问题，再结合 Baklib AI 知识库提供基于知识内容的问答与原文溯源。无论采用哪种方案，都应使用真实文档链接和目标 AI 工具进行测试，验证内容能否按预期被访问和引用。
结语
文档是否适合 AI 使用，不只取决于是否提供了新的接口或文件格式，也取决于普通链接能否让工具顺利读到正文。
最简单的检查方法，是从自己的帮助文档中选取一个真实链接，发给常用的 AI 工具，并观察它是否准确理解了文章。如果 AI 能直接读取并回答，通常说明这条内容访问路径是顺畅的；如果它只能看到“加载中”，就值得进一步检查页面的渲染和访问方式。
提交反馈
