技能介绍

解决什么问题

把库和框架的官方文档喂给 LLM 时，常见做法是直接丢一个网页 URL 或整站爬取。前者上下文太碎，模型只能看到当前页面；后者容易拉进大量导航、页脚和版本切换脚本，真正有效的正文被噪声淹没。Atlas Docs 的做法是：由服务端先把官方文档处理成适合 LLM 阅读的 Markdown 版本，再通过 MCP 工具按需取回，省掉你自己写爬虫和正文抽取逻辑的功夫。

它的工作方式

这个技能的定位是路由层：大模型负责理解意图、选择工具、提取参数，代码只负责调用 API。完整流程是先确认密钥，再按意图挑工具，用关键字参数调用 scripts.tools 下的函数，最后把返回的 result['raw'] 整理后展示。

list_docs：列出全部可用文档集，返回名称、描述与来源 URL。后续工具都需要 docName，所以这步通常是起点。
search_docs：在某个文档集内按关键词检索，返回按相关性排序的页面路径与摘要，适合先缩小范围。
get_docs_index：取一份精简的页面索引，用 Markdown 列出该文档集覆盖了哪些页面，便于快速判断该读哪一篇。
get_docs_page：按相对路径（如 /guides/getting-started）取单页完整内容，是日常最常用的入口。
get_docs_full：一次性取回整个文档集的合并文本，只在需要通读全文或做整体分析时才值得用，返回体量很大。

参数缺失时，技能要求用 AskUserQuestion 向用户追问，而不是猜一个默认值。

适用边界与注意点

API 密钥是硬性前提。 首次使用时若 .env 中没有 XBY_APIKEY，必须先询问用户，拿到后再调用 scripts.config.set_api_key(key) 保存；密钥本身需要自行到官方站点获取。缺少密钥时不允许自行搜索文档或编造内容——文档集列表只能来自该服务，本地没法兜底。

适用场景是库和框架的技术文档检索与阅读，面向 MCP 兼容客户端（如 Cursor、Cline、Windsurf）。它不负责通用网页抓取，也不对文档内容做改写或总结，拿到的是处理后的原文，后续怎么用仍取决于你的提示词和客户端上下文窗口。取整份文档前建议先走 get_docs_index 或 search_docs，避免无谓地把大量文本塞进上下文。

截图预览

使用场景

在 Cursor 里写业务代码时卡在某个库的 API 参数用法，先用 get_docs_index 浏览文档集页面结构，再用 get_docs_page 按路径取回对应指南页。
想让 LLM 解释某个框架的配置项含义，先用 search_docs 在文档集内检索关键词，拿到相关页面路径与摘要后再让模型读取该页完整内容作答。
做第三方库选型调研时，需要通盘理解整个框架的能力范围，用 get_docs_full 一次性取回合并后的文档全文交给模型做横向分析。
新接入 Windsurf 或 Cline 时不确定能查哪些库的文档，先调用 list_docs 获取全部文档集的名称、描述与来源 URL，再决定检索目标。

适合人员

日常在 Cursor、Cline 等 MCP 客户端里写代码、需要频繁查阅库和框架官方文档的工程师。
负责把第三方库文档接入内部 LLM 工具链、需要理解工具调用与密钥配置流程的技术架构师。
需要从海量框架文档中按关键词快速定位特定页面并提取原文的技术写作与布道人员。
正在为团队搭建 MCP 文档查询能力、关注参数约定与返回值处理的工具链开发者。

Atlas 文档服务