cnki-deepsearch

# CNKI 中文学术检索：有头浏览器 + 三层渐进式发现 ## 本技能做什么 替代体验糟糕的知网内置检索，用本机有头浏览器做可复核的中文学术检索：先广泛发现概念与文献，再按证据价值决定是否升级到正文，最后沉淀为可追溯的检索档案。核心方法论是"三层渐进式关键词发现 + 逐篇关联判定"，并自主判断何时只需详情页信息、何时必须下载 PDF 解析正文。 ## 启动引导：调用即开始配置 **本技能被调用后，不要等待用户进一步指令，立即按下面的流程带用户完成接入。** 知网检索依赖本机有头浏览器——用户需要亲自登录或走校外访问才能拿到全文权限，所以先打通浏览器，再谈检索。整个引导大约一分钟。 ### 第 1 步 · 开场（一句话） 告知用户：这个技能需要本机有头浏览器才能上知网并拿到全文权限，接下来我会带你完成配置，然后开始检索。（用一句自然的话说，不必念脚本。） ### 第 2 步 · 环境自诊 检查本会话可用的浏览器控制能力，判定属于哪一类： - **A. 已有有头浏览器工具**：例如 Trae 通过插件直接控制本机有头浏览器的 `browser_*` 工具。本就可见、可交互 → 跳到第 4 步登录。 - **B. 已有 `cnki-browser` 之类指向本地有头浏览器的 MCP** → 跳到第 4 步登录。 - **C. 默认是无头方式**：只有 WebFetch、无头浏览器或纯检索接口，没有可见浏览器 → 进入第 3 步接入引导。 判定方法见下方"环境识别与有头浏览器接入"的细节说明。若一眼能确认（如本就是 Trae 且 `browser_*` 可用），直接归类，不必逐条排查。 ### 第 3 步 · 情况 C：引导接入有头浏览器 MCP 向用户说明：知网需要人工登录或校外访问才能拿全文，无头方式完成不了，需要配置一个"调用本机有头浏览器"的 MCP。然后**请用户二选一**： - **选项一 · 自动配置（需你明确授权）**：你授权后，我自动探测本机默认浏览器路径——macOS：`/Applications/Google Chrome.app/Contents/MacOS/Google Chrome`；Windows：`C:\Program Files\Google\Chrome\Application\chrome.exe`；Linux：`google-chrome` 或 `chromium`。把 `cnki-browser` 服务端写入**当前 AI 宿主的 MCP 配置**（多数工具是一个 `mcp.json` 或设置面板的 MCP 项，新增 `cnki-browser` 条目、不覆盖已有），再按宿主要求完成信任 / 重载，然后提示你在打开的浏览器里登录。 - **选项二 · 手动配置**：我把配置 JSON 和分步说明发给你，你配好后告诉我，我确认 MCP 连接成功再继续。 无论哪种，都必须满足：`--headless=false`（有头、可见）、`--userDataDir` 用独立目录、MCP 名称建议 `cnki-browser`。配置模板与细节见下方"环境识别与有头浏览器接入"。 ### 第 4 步 · 登录引导 配置就绪后，引导用户在可见浏览器中：个人账号登录，或通过机构 / 校外访问（CARSI、图书馆入口）进入。确认已进入可检索、可下载状态（右上角登录态、能打开全文 / 下载按钮可用）后，再进入检索。 ### 引导完成后 进入下方的"三层渐进式关键词发现"与"全文获取决策"主体流程。 --- ## 0. 为什么一定要用有头浏览器 知网检索的终点不是"搜到题录"，而是**拿到可分析的全文**。全文（尤其是 PDF）通常需要登录或机构/校外访问权限才能下载。无头方式（纯 HTTP、WebFetch、无头浏览器）无法让用户在界面上手动登录，也走不了校外访问拿权限，因此本技能默认使用**本机有头浏览器**：用户看得见界面，亲自完成登录或校外访问授权；此后 AI 才能一条线做完——搜索 → 进入详情/正文 → 下载 PDF → 解析正文 → 分析。 ### 0.1 操作策略：引导，或拿权限自助 本技能面向不同 AI 宿主（Trae、Codex、HanaAgent、WorkBuddy 等）广泛适配，不绑定某一家的工具名或配置文件路径。执行中遵循一条总则： - **需要用户动手的环节（登录、过验证、授权配置），就清晰地引导用户去操作**，不在背后替用户做有风险或需担责的事； - **只要用户明确授权，就自己把事情解决到底**——探测浏览器、写好 MCP 配置、完成接入，不半途甩回给用户。 换言之：要么把用户该做的说清楚让他做，要么拿到许可后一口气自动化到底，避免"做一半卡住等你"。 ## 1. 环境识别与有头浏览器接入 动手检索前，先确定当前环境能用的浏览器控制能力，按情形接入有头浏览器。这一步决定了后续所有操作是否在"用户可见"的前提下进行。 ### 1.1 识别当前环境 确认本会话可用的工具属于哪一类： - **A. 已有有头浏览器工具**：例如 Trae 通过插件直接控制本机有头浏览器的 `browser_*` 工具（browser_navigate / browser_snapshot / browser_click / browser_type / browser_scroll / browser_take_screenshot）。本就可见、可交互，直接使用，并确认窗口可见（headful）。 - **B. 已存在指向本地有头浏览器的 MCP**：例如已配置好的 `cnki-browser`（chrome-devtools-mcp 之类），直接调用即可。 - **C. 默认是无头方式**：只有 WebFetch、无头浏览器或纯检索接口，没有可见浏览器。这种情况必须先接入有头浏览器，否则会卡在登录/权限这一步。 ### 1.2 情况 C：接入有头浏览器 MCP 先告诉用户：知网需要人工登录或校外访问才能拿全文，无头方式完成不了，需要配置一个"调用本机有头浏览器"的 MCP（Chrome 为主，Edge / Chromium / Firefox 等也可）。 提供配置模板（以 Chrome 为例，使用 chrome-devtools-mcp）： ```json { "mcpServers": { "cnki-browser": { "command": "npx", "args": [ "-y", "chrome-devtools-mcp@latest", "--executablePath=<本机浏览器可执行文件路径>", "--headless=false", "--userDataDir=<独立缓存目录，不要与默认浏览器或其他 MCP 共享>" ] } } } ``` 然后二选一推进： - **自动配置（需用户明确授权）**：用户同意后，自动探测本机默认浏览器路径——macOS：`/Applications/Google Chrome.app/Contents/MacOS/Google Chrome`；Windows：`C:\Program Files\Google\Chrome\Application\chrome.exe`；Linux：`google-chrome` 或 `chromium`。把上面的 `cnki-browser` 服务端写入**当前 AI 宿主的 MCP 配置**：多数工具是一个 `mcp.json`（或设置面板里的 MCP 项），把 `mcpServers` 下新增 `cnki-browser` 这个条目、不要覆盖已有条目即可。写入后按宿主要求完成信任 / 重载（例如重启宿主或点击信任），再提示用户在打开的浏览器中完成登录。 - **手动配置**：把上面的 JSON 片段交给用户，给出分步说明，等待其配置完成、MCP 连接成功后再继续。 无论哪种方式，都必须满足：**`--headless=false`（有头、可见）**；`--userDataDir` 用独立目录，避免污染默认浏览器或其他自动化配置；MCP 名称建议 `cnki-browser`，不要覆盖环境默认的 chrome-devtools。 ### 1.3 运行时规则 - 登录由用户在可见浏览器中自行完成，不得记录、保存或复述账号凭据。 - 页面快照可能含预加载或离屏的验证码组件；以用户可见界面和搜索框实际可操作状态判断是否存在验证阻塞，不凭可访问性树中的验证码文本判定。 - 出现滑块 / 点选验证时暂停，交用户在可见浏览器手动完成，再从原会话恢复；不自动破解或规避验证。 - 下载 PDF / CAJ、批量操作或可能产生费用的操作，先征求用户确认。 ## 2. 登录与权限获取 打开知网后，提示用户在可见浏览器中： - 个人账号登录；或 - 通过机构 / 校外访问（CARSI、图书馆入口）进入。 确认已进入可检索、可下载状态（右上角登录态、能打开全文 / 下载按钮可用）后，再开始检索。这一步是后续"搜索 → 正文 → 下载 PDF → 分析"全链路的前提。 ## 3. 三层渐进式关键词发现 ### 第一步：构建概念树 为每个上位概念（研究对象的核心维度）建立子关键词树。子词应包括具体技术术语、相近概念、不同表述和常见翻译。每个维度独立建树。 示例（数字媒介维度）：虚拟现实、VR、增强现实、AR、扩展现实、XR、交互技术、数字场景、全息影像、数字孪生、人工智能、社交媒体、短视频等。 ### 第二步：三层渐进式关键词发现 **第一层**：使用单一的初步核心关键词宽检。禁止将多个关键词用空格拼入同一搜索框，这会过度限制检索广度。记录宽检结果的总量、文献类型和学科分布。 **第二层**：从第一层结果中进入重点关注论文，读取摘要、关键词、目录和参考文献，从中发现新的关键词和术语。每个新关键词分别独立检索，不与其他关键词组合约束。 **第三层**：进入第二层确定的关键论文，发现第三层术语、理论来源和引文，继续独立检索和回溯。完整执行 3 层。 ### 第三步：子关键词独立宽检与关联判定 每个子关键词独立执行宽检： - 从结果题名、摘要、关键词和学科分类中识别与研究对象实质相关的论文 - 不以论文是否出现上位词为唯一关联判定标准 - 对每篇进入论文，区分处理深度：metadata only（仅阅元数据）、abstract only（仅阅摘要）、full text read（完整阅读） ### 第四步：合并去重与关联编码 将各子词命中的相关文献取并集并去重。按关联类型编码归类，例如：技术应用、理论框架、实证研究、观众体验、产业背景等。 ### 第五步：交叉验证（仅用于查漏） 只有在子词宽检并集建立后，才使用"对象词 × 子词"交叉搜索做查漏验证： - 直接交叉命中量只能说明字面词组在主题字段中的共同出现量，不代表概念层面的研究覆盖率 - 严禁使用单一上位词交叉命中量估算整个概念簇的关联规模 - 严禁根据上位词交叉命中的低比例得出"相关研究稀少"或"交叉空白"等结论 ### 学科口径控制 检索与综述必须保持目标学科的口径。其他学科（如传播学、营销学、旅游管理）的文献只用于补充机制解释或产业背景，不得主导学术史叙述。 ### 学术史梳理规范 在综述中串联学术史时： 1. 明确代表性学者提出了什么关键观点、得到什么研究发现 2. 呈现这些观点之间如何承接、补充、分化或推进 3. 呈现研究问题的学术演进路径 4. 在演进链条中准确定位现有研究的解释边界与本课题的新进展 5. 不按主题分类罗列文献，不只写"某某研究了什么" ## 4. 全文获取决策：详情页信息 vs 下载 PDF 解析 检索到候选文献后，按"信息需求深度"自主判定证据获取方式——不要一概下载，也不要一概止步于题录。 ### 4.1 仅访问详情页即可（不下载 PDF 解析） 满足以下任一情况时，读取详情页的题名、作者、年份、摘要、关键词、基金、来源、被引等元数据层信息就够用： - 该文献只是背景或旁证，用于判断相关性、绘制文献地图； - 主张已由摘要支撑，且不是核心代表文献； - 只需题录级信息做归类、去重或交叉查漏； - 知网仅提供题录、无可读全文。 ### 4.2 需要下载 PDF 再解析拿正文 满足以下任一情况时，必须拿到正文（优先知网 HTML 阅读，不可得再下载 PDF 解析）： - 是核心代表文献，主张涉及具体方法、变量、机制、数据或论证链条； - 摘要歧义或信息不足，需正文确认； - 要做引文回溯、发现第三层术语 / 理论来源（需读参考文献列表）； - 要做内容编码、观点提取、跨文献对比——这些只能基于正文，不能基于摘要。 ### 4.3 获取与解析流程 1. 优先尝试知网「HTML 阅读」：定位主容器 / iframe，滚动触发懒加载，分别提取题名、作者、摘要、关键词、章节、正文、注释、参考文献；检查首尾、章节连续性、截断和参考文献完整性后再标记"全文已读"。 2. HTML 不可得或提取失败时，下载 PDF，用 PDF 解析能力提取正文文本；批量或付费下载前先征求用户确认。 3. 解析后记录证据状态： - `metadata_only`：仅元数据 - `abstract_only`：已读摘要 - `html_fulltext_complete` / `html_fulltext_partial`：HTML 正文完整 / 部分 - `pdf_fulltext_complete` / `pdf_fulltext_partial`：PDF 正文完整 / 部分 - `verification_required`：需人工验证 - `access_failed`：权限 / 访问失败 4. 下载或解析受验证阻塞时，暂停交用户在可见浏览器手动完成，再恢复。 ## 5. 收尾与沉淀 每批检索结束后： - 输出本批检索报告（命中规模、学科分布、代表文献与观点）； - 将结果与证据状态追加到本地累计 Markdown 档案，便于后续检索复用与追溯。 若宿主环境提供了记忆 / 知识库能力，可将本批发现同步沉淀，以便跨会话延续；此步骤为可选增强，不影响上面的核心检索流程。