代码看起来没错，却跑不起来：Context7 能帮你查哪一层

一个常见的修复循环是：模型给出新写法，编译器报“没有这个导出”，模型又换一个写法。问题有时不在语法，而在文档版本。项目使用的是旧版依赖，回答却按新版接口生成。

先看项目实际上装了什么

开始查资料前，记录依赖清单、锁文件、运行环境和准确报错。不要只写“我在用某框架”。主版本相同，也可能因为依赖组合、运行端不同而出现行为差异。

这一步无需安装新工具。把失败缩小到一个最小示例，通常已经能排除不少与模型无关的问题。

Context7 补的是文档信息

Context7 的官方 README 介绍了按库和版本获取文档的用法，提供 CLI + Skills 和 MCP 两种接入方式。MCP 工具包括查找库标识和查询文档；已经知道准确库 ID 时，可以减少名称匹配这一步的歧义。来源 1

比如“请按锁文件中的库版本，查这个函数的参数和迁移说明”，比“帮我修好”更容易得到有用资料。返回文档后，仍应对照来源页面、适用版本和调用位置，而不是把检索结果当成执行成功。

两种接入方式怎样选

已有 MCP 客户端并希望模型直接调用文档工具，可以按官方客户端说明配置 MCP。已有终端工作流，也可以评估 CLI + Skills。README 写明 ctx7 CLI 需要 Node.js 22.13 或更新版本；这个要求不应被随意套到所有远程 MCP 客户端。

初始化命令可能涉及登录、生成密钥和写入客户端配置。理解它会改哪些设置，再决定是否执行。本文只核对资料，没有在读者设备上安装或授权任何组件。

怎样确认这次确实查对了

保留三样东西：项目里的准确版本、检索到的出处、最小示例的运行结果。若文档只有新版本，先确认是否需要迁移，不要让模型假装旧版本也提供相同接口。

验收可以很小：只验证一个函数的参数、一个错误分支和一次正常返回。若通过，再把修改放回实际模块。这样失败时可以分清是资料选错、代码改错，还是项目环境另有约束。

README 也说明，并非所有库资料都由 Context7 自己维护，其支持的后台、解析和抓取组件并不全在这个仓库公开。使用时应保留来源判断；“接上文档工具”不会自动消除错误。