gs-skills：用 Claude Code 操控 Google Scholar 的学术检索工程
> GitHub: cookjohn/gs-skills | 317 stars | MIT | Chrome DevTools MCP 驱动 > > 作者: cookjohn（学术工具生态构建者，另维护 cnki-skills / pm-skills / wos-skills / zotero-mcp-plugin）
---
一、Google Scholar 的结构性矛盾
做学术研究的人离不开 Google Scholar，但它有一个根本性的矛盾：它是学术检索的基础设施，却没有任何公开 API。
这意味着什么？
- 想批量导出参考文献？只能手动翻页、逐条复制
- 想追踪某篇论文的引用网络？要点开 "Cited by"，再一页页翻
- 想按作者/期刊/时间过滤？高级搜索的界面在浏览器里，不在你的脚本里
- 想用 Zotero 管理？中间的格式转换和去重，全靠人肉
cookjohn 的 gs-skills 走了第三条路：让 Claude Code 直接操控 Chrome 的 DevTools Protocol，用 DOM 解析做精确提取，用 SKILL 文件做意图封装。
---
二、架构拆解：为什么是 Chrome DevTools MCP？
2.1 技术选型：不截图，不 OCR，纯 evaluate_script
传统的浏览器自动化（Selenium/Playwright）通常走这条路：
导航 → 截图 → 视觉识别/OCR → 点击 → 等待加载 → 再截图
这条链的问题是慢、 fragile、容易被反爬检测。gs-skills 完全不同：
导航 → evaluate_script 执行 JS → 用 CSS 选择器提取结构化数据 → 返回 JSON
Chrome DevTools MCP 提供了 evaluate_script 能力，让 Claude 直接在目标页面执行任意 JavaScript。Google Scholar 的搜索结果页有清晰的 DOM 结构——每篇论文的标题、作者、摘要、引用数、PDF 链接都有稳定的 CSS 类名。gs-skills 用一套精心编写的选择器，把页面内容转成结构化 JSON，一次调用完成提取。
每个技能仅需 1-2 次工具调用（一次 navigate 到目标页，一次 evaluate_script 提取数据）。这比 Playwright MCP 的快照→分析→点击→等待模式快一个数量级。
2.2 data-cid：Google Scholar 的隐藏主键
Google Scholar 的搜索结果中，每篇论文有一个 data-cid 属性（cluster ID），这是 Google 内部的聚类标识符。同一个论文在不同搜索结果中出现的 data-cid 是一致的。
gs-skills 把这个隐藏属性挖掘出来，作为所有技能之间的主键：
gs-search返回的每条结果都带 data-cidgs-cited-by用 data-cid 直接打开引用页面gs-fulltext用 data-cid 定位论文获取全文链接gs-export用 data-cid 导出 BibTeX
2.3 CORS 绕过：BibTeX 的巧妙获取
Google Scholar 的 BibTeX 导出功能有一个坑：BibTeX 文件托管在 scholar.googleusercontent.com，直接 fetch 会触发 CORS 限制。gs-skills 的解法是用 navigate_page 直接打开 BibTeX 的 URL（而不是在 JS 里 fetch），然后在新页面执行 evaluate_script 读取响应文本。这样绕过了同源策略，获取到原始 BibTeX 字符串。
2.4 CAPTCHA 感知：承认现实的设计
Google Scholar 对自动化请求有反爬机制，最典型的是验证码。gs-skills 没有试图用打码平台绕过（这既不道德也不可持续），而是检测验证码 DOM 元素的存在，一旦触发就暂停并提示用户手动完成。这是一种务实的"人机协作"设计——让 AI 处理 95% 的重复劳动，把 5% 的反爬关卡留给人类。
---
三、技能矩阵：六个原子操作
| 技能 | 功能 | 调用示例 |
|---|---|---|
| gs-search | 关键词搜索，返回结构化结果 | /gs-search "attention mechanism" |
| gs-advanced-search | 高级过滤（作者/期刊/时间/精确短语） | /gs-advanced-search author:Hinton after:2020 |
| gs-cited-by | 追踪某篇论文的引用文献 | /gs-cited-by 0qfs6zbVakoJ |
| gs-fulltext | 获取全文链接（PDF/DOI/Sci-Hub/出版商） | /gs-fulltext 0qfs6zbVakoJ |
| gs-navigate-pages | 搜索结果翻页 | /gs-navigate-pages next |
| gs-export | 导出 BibTeX 到 Zotero | /gs-export 0qfs6zbVakoJ |
data-cid 把它们串成一张网。gs-researcher：复合工作流编排
除了六个原子技能，还有一个 gs-researcher Agent，负责把技能组合成复杂工作流。例如：
用户说："搜索深度学习论文，找被引最多的，追踪引用，全部导出到 Zotero"
gs-researcher 的推理链：
1. gs-search "deep learning" --sort citations
2. gs-navigate-pages（遍历前 3 页）
3. 对每篇论文：gs-cited-by → 收集引用文献
4. 对目标论文：gs-export → 推送到 Zotero
5. 遇到 CAPTCHA → 暂停，提示用户
这个 Agent 不是用复杂的 DAG 引擎实现的，而是靠 SKILL 文件里的 prompt 工程——Claude 根据任务描述自己推理该调用哪些技能、按什么顺序。这种"prompt 驱动的编排"在 skill 数量不多的场景下非常高效。
---
四、cookjohn 的学术工具生态
gs-skills 不是孤立项目。作者 cookjohn 构建了一个完整的学术检索技能矩阵：
| 项目 | 数据源 | Stars | 协议 |
|---|---|---|---|
| gs-skills | Google Scholar | 317 | MIT |
| cnki-skills | 中国知网 | 453 | MIT |
| pm-skills | PubMed (NCBI API) | - | MIT |
| wos-skills | Web of Science | 70 | MIT |
| sci-skills | ScienceDirect | 37 | MIT |
| zotero-mcp-plugin | Zotero 集成插件 | 808 | - |
1. 中英文双轨并行
cnki-skills 的 stars 甚至超过 gs-skills（453 vs 317），说明中国学术用户的需求被严重低估了。CNKI 的验证码机制和反爬比 Google Scholar 更复杂，cnki-skills 还要处理 CAJ 格式下载和 GB/T 7714 引用格式导出，工程难度不低。
2. PubMed 用 API 而非 DOM
pm-skills 不走 Chrome DevTools，而是直接用 PubMed E-utilities API（esearch/esummary/efetch）。这是因为 PubMed 提供了结构化的 JSON 接口，不需要 scraping。当数据源有 API 时，cookjohn 毫不犹豫地用 API——只在没有 API 时才 fallback 到 DOM 解析。
3. Zotero 是数据出口的统一节点
所有技能集都支持导出到 Zotero，而且不是简单的文件导入，是用 Zotero Connector API 直接推送。cookjohn 甚至专门做了一个 zotero-mcp-plugin（808 stars），让 Zotero 本身也变成 MCP 服务器，可以被 AI 双向操控。
---
五、安装与使用：四步启动
# 1. 安装 Chrome DevTools MCP
claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest
# 2. 安装 gs-skills
git clone https://github.com/cookjohn/gs-skills.git
cd gs-skills
cp -r skills/ agents/ .claude/
# 3. 启动 Chrome 远程调试
google-chrome --remote-debugging-port=9222
# 4. 启动 Claude Code
claude
然后在 Claude Code 里打 /gs-search deep learning 即可验证。
这套安装的门槛在于需要本地 Chrome + 远程调试端口。不能 headless，因为 Google Scholar 的反爬会检测 headless 指纹。这意味着它不适合纯服务器部署，但非常适合个人工作站场景——研究者本来就有浏览器开着。
---
六、局限与追问
第一，DOM 的脆弱性
Google Scholar 的页面结构不是 API 合约，Google 随时可能改 CSS 类名。一旦改动，所有 CSS 选择器都失效。相比之下，PubMed 的 E-utilities API 是稳定的契约。gs-skills 的长期维护成本比 pm-skills 高一个数量级。
第二，验证码的人机协作还不够丝滑
CAPTCHA 检测能暂停并提示用户，但用户需要手动切到浏览器窗口、完成验证码、再切回终端。这个上下文切换的体验不够流畅。有没有可能用"浏览器内弹窗"或"终端内嵌浏览器截图"来减少切换？
第三，数据-cid 的稳定性边界
data-cid 是 Google 内部的聚类 ID，理论上同一个论文应该一致。但如果 Google 的聚类算法调整，data-cid 可能变化。这意味着技能之间的关联可能断裂。目前没有持久化层来缓存或映射 data-cid，每次会话都是重新获取。
第四，与其他工具的互操作
gs-skills 目前只输出到 Zotero。如果用户的文献管理工作流是 EndNote、Mendeley、或自定义 Notion 数据库，导出链路就断了。BibTeX 是通用格式，但不同工具对字段的解析有差异。
第五，批量操作的原子性
如果用户让 gs-researcher 搜索 100 篇论文并全部导出，过程中途遇到 CAPTCHA 中断，已经导出的部分不会回滚。没有事务机制，没有断点续传。大规模批处理场景下这是个隐患。
---
七、结语
gs-skills 的价值不在于"让 AI 能搜 Google Scholar"——这个能力用脚本也能实现。它的真正价值在于把学术检索的工作流封装成了可组合、可编排、可复用的 SKILL 单元，让 Claude Code 这样的 AI 编程助手能够理解"搜索→过滤→追踪→导出"这种多步意图，并自主执行。
cookjohn 更大的野心是那个生态矩阵：Google Scholar + 知网 + PubMed + Web of Science + ScienceDirect + Zotero，几乎覆盖了学术检索的完整链路。这不是一个工具，是一整套学术工作流的 AI 化改造。
如果你每天花 30 分钟在 Google Scholar 上手动翻页、复制、导入，这套技能集能把 30 分钟压缩到 30 秒。省下来的时间，去看论文本身。
---
参考
- GitHub: https://github.com/cookjohn/gs-skills
- Chrome DevTools MCP: https://github.com/anthropics/chrome-devtools-mcp
- Zotero MCP Plugin: https://github.com/cookjohn/zotero-mcp-plugin
- CNKI Skills: https://github.com/cookjohn/cnki-skills
- PubMed Skills: https://github.com/cookjohn/pm-skills
🌟 智谱 GLM-5 已上线
我正在智谱大模型开放平台 BigModel.cn 上打造 AI 应用，智谱新一代旗舰模型 GLM-5 已上线，在推理、代码、智能体综合能力达到开源模型 SOTA 水平。
🎁 领取 2000万 Tokens