gs-skills 的追问：学术检索自动化的边界在哪里？

gs-skills 把 Google Scholar 的操作封装成了六个原子技能和一个编排 Agent，设计很精巧。但作为一个每天和论文打交道的人，几个更深层的问题浮现出来。

第一，DOM 解析的长期维护困境。

这是所有 scraping-based 项目的阿喀琉斯之踵。Google Scholar 的 HTML 结构不是 API 契约，Google 改一个 CSS 类名，所有选择器就全废。cookjohn 的 README 里写了"纯 DOM 解析"作为设计选择，但没有写应对页面结构变化的策略。pm-skills 用 PubMed E-utilities API 就没有这个问题——当数据源提供 API 时，DOM scraping 的维护成本显得很不划算。问题是 Google Scholar 永远不会提供 API，所以 gs-skills 的维护者需要持续监控页面结构变化，这本质上是一份"数字守夜"的工作。

第二，学术伦理的灰色地带。

gs-skills 的 gs-fulltext 技能会返回 Sci-Hub 链接。这很方便，但也很敏感。Google Scholar 本身不直接提供 Sci-Hub 链接，gs-skills 是怎么构造这些链接的？是通过 DOI 拼接 Sci-Hub 域名吗？这种自动化工具在学术伦理上的边界在哪里？cookjohn 的 MIT 许可证免责声明是否足够？对于需要遵循机构合规要求的用户，这可能是个 deal breaker。

第三，CAPTCHA 处理的 UX 断层。

cookjohn 对验证码的处理是务实的：检测到就暂停，等用户手动完成。但"暂停"在 Claude Code 的交互中意味着什么？用户是否能看到浏览器窗口？是否需要从终端切到 Chrome、完成验证、再切回来？这个上下文切换的体验可能很糟糕。更理想的做法也许是"在终端内显示浏览器截图 + 内嵌 CAPTCHA 输入"，但这需要更复杂的 UI 集成。

第四，data-cid 的跨会话稳定性。

data-cid 是 Google 内部的聚类 ID，理论上同一个论文在不同搜索结果中应该一致。但如果 Google 的聚类算法调整，data-cid 可能变化。这意味着今天保存的工作流，明天可能因为 data-cid 失效而跑不通。目前没有本地缓存层来建立 "data-cid → 元数据" 的持久化映射，每次会话都是重新获取。

第五，与现有文献管理生态的互操作性。

cookjohn 的矩阵里几乎所有项目都导出到 Zotero，但学术圈的文献管理工具并不只有 Zotero。EndNote、Mendeley、ReadCube Papers、Notion 数据库、自建 bib 文件——这些用户的导出链路在哪里？gs-export 输出 BibTeX 是通用格式，但不同工具对字段解析有差异。更根本的是，为什么不直接输出 CSL JSON 这种更现代的标准格式？

第六，批量操作的可靠性。

如果让 gs-researcher 搜索 100 篇论文并全部导出到 Zotero，中途遇到 CAPTCHA 或网络中断，已导出的部分不会回滚。没有事务机制，没有断点续传，没有进度持久化。大规模批处理场景下，一次中断可能导致部分结果丢失，或者重复导入。Zotero Connector API 的去重机制是否足够健壮？论文中没有验证。

gs-skills 解决了一个真实痛点，但它所处的生态位——在封闭平台和无 API 服务之间架桥——注定是 fragile 的。它的长期价值取决于 cookjohn 生态的维护力度，以及 Google Scholar 反爬策略的松紧变化。

---

> 千寻 | 基于 gs-skills 主文 (cookjohn/gs-skills) 的延伸追问