【红豆智能文献】V1.2.8 更新啦！新增Obsidian插件

stanley

pengchy 发表于 2026-9-18 10:14
开发团队辛苦了，我提个开发需求：
1.  条目类型增加“微信公众号”，通过网页解析，辨识出：作者/发表时间 ...

条目方面，nehermes 的建议如下：

不用新增，需求已被覆盖；而且"新增条目类型"不只是工程量大，会直接打断引文链路。

一、已有类型就够用。
40 个条目类型里已有「网页」「博客帖文」「论坛帖文」。关键证据：本机 841 个翻译器中已有官方 Weixin.js（inRepository: true），抓取 mp.weixin.qq.com 时：

条目类型 = blogPost
blogTitle = 公众号名，websiteType = "微信公众号"（翻译器里写死的）
date = 发布时间，url、作者齐全
引用侧同样通：blogPost → CSL post-weblog；中文法学引注手册样式里 post post-weblog webpage 是同一分支；BibLaTeX 导出 blogPost → @online。存和引这条链现在是通的，只是类型名显示「博客帖文」。

stanley

pengchy 发表于 2026-9-18 15:42
提一个开发需求：
1. 期刊文章条目，请增加“作者单位”属性，这个数据在pubmed数据库中是有的，Author aff ...

nehermes 拿到了代码，给开发者的建议：

可以做，成本比"新增条目类型"低一个量级——但它是"小改动 + 三个必须一并解决的坑"，不是纯加个字段。而且用户真正要的是"筛选"，这件事今天就能用更省的方式做到。

关键区别：加字段不需要 CSL 映射（未映射只是不进引文，不报错）；加条目类型缺 CSL 映射会直接抛错（utilities_item.js:62-65）。所以别拿上一个需求的结论套这个需求。

一、现状（代码级）
单位来自自研的条目自动更新 onlineSearch/qingti/metadataUpdater.js：:34-43 一次写入 8 个「青提」键*（影响因子/收录/大类/小类/第一作者/作者地址/数据源/Hash ID）→ 这就是"混在'其他'里不好筛"的根因；:527-542 单位格式是 作者1;作者2:单位名，多条用 ;; 连在一行。
现有字段承载不了：journalArticle 31 个字段里没有单位类字段；institution 只对 manuscript/report 有效、organization 只对 standard 有效（DB 实测）。
同一产品里已有第二种存法：arXiv 路径把单位写进子笔记（arxiv/search.js:403）——存法本身就不统一。
检索侧已经支持按单位查（pubmed/search.js:216,233 有 [Affiliation]），缺的只是本地库筛选。
今天就能用：保存搜索「其他」包含关键词。
二、为什么是"小改动"
UI 是 0 成本——信息面板、列选择器、搜索条件、附件重命名占位符全按类型动态生成（itemBox.js:566、renameFiles.mjs:256）；DB 也不用写迁移，全局 schema 更新会自动重建 itemTypeFields。

三、三个必须一并解决的坑
schema 分叉：字段定义在 resource/schema/global/schema.json（zotero/zotero-schema 子模块，随包内置，实测 version 44，journalArticle.fields 31 项，csl.fields.text 无 affiliation）。要加字段就得改这个文件并提 version，之后每次跟上游都要 merge。别手改 DB——schema 更新会 DELETE FROM itemTypeFields 重建，手改会被抹掉。现成的 customFields 机制也走不通：schema.js:1122-1161 显示自定义字段只能挂在自定义条目类型下，挂不到内置 journalArticle。
历史数据不会自动迁移：Zotero 自带的 Extra→字段提升机制（utilities_internal.js:1150+）行正则 ^([a-z][a-z -_]+): 只认 ASCII 键，中文键「青提作者地址」永远解析不到（官方文档约定也是 CSL Variable: Value）。必须写一次性迁移，或把 updater 键改成 affiliation + 迁移老数据，否则"新数据进字段、老数据留其他"。
同步/多端：未知字段在非冲突路径优雅降级进 Extra（item.js:5852-5868），但冲突解决路径用严格校验（syncLocal.js:1163-1175 fromJSON(...,{strict:true})）会抛错、该条目同步失败。服务端对未知字段是否白名单校验，需实测。
四、建议
先做方案 A（无数据模型改动，老库立即生效）：把「青提作者地址」从"其他"里单独渲染成一组行（作者 : 单位）；侧栏加「作者单位」facet——聚合单位名、去重、点选即筛。用户诉求是筛选，facet 比字段更好用，顺带把影响因子/分区也做成 facet。

要做正式字段就按方案 B 走完整：字段名 affiliation、标签「作者单位」、分叉 schema、改 updater 键 + 一次性迁移、同步实测、导出补映射（BibTeX/RIS 不认这个字段会丢）。注意 affiliation 没有对应 CSL 变量，不会进引文，它只是可筛选元数据。

口径：作者的机构信息在 CSL/Zotero 里本就是依附作者的多值结构（PubMed 的 AffiliationInfo 挂每个 Author 下），压成一个文本字段会丢对应关系；作为筛选用元数据合理，作为引用字段无处可用。

pengchy

stanley 发表于 2026-9-18 16:40
条目方面，nehermes 的建议如下：

不用新增，需求已被覆盖；而且"新增条目类型"不只是工程量大，会直接 ...

确实如此，这个方案可以落地。看是否可以增加一个“公众号”的解析模块，把几个关键字段自动提取出来。

pengchy

stanley 发表于 2026-9-18 16:51
nehermes 拿到了代码，给开发者的建议：

可以做，成本比"新增条目类型"低一个量级——但它是"小改动 +  ...

感谢快速响应。

pengchy

有一篇专利，cnki在线可以检索到，但是通过红豆的在线检索工具却查不到，请确认。通过专利文献直接导入，也错误的识别成期刊文章文献了，而且内容完全是错的。

申请(专利)号：        CN202411452365.8

stanley

pengchy 发表于 2026-9-19 18:19
有一篇专利，cnki在线可以检索到，但是通过红豆的在线检索工具却查不到，请确认。通过专利文献直接导入，也 ...

感谢告知，我联系同事尽快排查。

stanley

让neclaw 破案了：
你说得对，我之前用自由词去查是错的检索姿势。你这张图正好把根因钉死了：CNKI 网页版是**选"申请号"字段 + 检索范围限定"专利"**才命中的，而红豆的在线检索根本没有这两个能力。

对照证据：

CNKI 网页版：字段=申请号，值=CN202411452365.8，范围=专利 → 命中。说明数据在库里，只要字段和范围选对就能查到。
红豆在线检索（源码 cnki/search.js）：查询构造写死 Field: "SU"（主题）+ Operator: "TOPRANK"，buildAdvancedQuery 的字段表只有 all→SU / title→TI / author→AU / keyword→KY / abstract→AB / source→JN / identifier→DOI / affiliation→AF / classification→CLC，没有"申请号/专利号"字段；跨库 KuaKuCode 白名单也不含中国专利(OORPU5FE)、海外专利(U8J8LYLV)。所以无论用 CN 号还是纯数字，它都只会拿申请号去撞"主题"，撞不到，再叠加"空结果被误判成 Cookie 失效 → 抛'已放弃 CNKI 检索'"。
我这边的 chinese_literature 工具同样只能传 field∈{subject,title,keyword,title_keyword_abstract,abstract}、scope∈{all_literature,journals}——没有"申请号"字段，也没有"专利"范围，所以复现不了你截图里的检索。这本身就是佐证：缺的正是"申请号字段 + 专利范围"。
一句话修正之前的结论：不是数据不在 CNKI，而是红豆的检索构造缺了"申请号字段"和"专利库范围"这两个维度；给账号密码、换关键词都绕不过去。

修复方向（给开发）

KuaKuCode 补入 OORPU5FE,U8J8LYLV（专利库）。
检索字段表新增"申请号/专利号"（CNKI 专业检索里对应 AN / 申请号），并支持把范围切到"专利"。
cnki/parser.js 的 _getItemType 给 _typeMap 补 7/8→patent，并覆盖专利导出的 NoteExpress 键（Title-专利名称、Code-申请号、Author-发明人 等），避免回落 journalArticle。
空结果不要误判为 Cookie 失效，别再把"查无此词"报成"已放弃检索"。

stanley

# 红豆（Hongdou）知网（CNKI）检索问题审计报告

- 审计对象：Hongdou.app（基于 Zotero 的 Firefox XUL 应用，v10.0 内核；在线检索模块 `onlineSearch/cnki/*` 与 MCP 服务 `127.0.0.1:18500/mcp`）
- 触发案例：申请号 `CN202411452365.8`（CNKI 网页版可查，红豆在线检索查不到；直接导入被识别成期刊且内容错误）
- 审计方式：内置源码静态审计 + 本机 MCP 实测
- 证据标注：`[源码]` 读自 app 内置 `omni.ja`；`[实测]` 本次现场跑出；`[推断]` 待进一步确认
- 日期：2026-09-19

---

## 一、复现申请号查不到的步骤

1. 打开红豆「在线检索」。
2. 数据源勾选「中国知网」，检索框输入 `CN202411452365.8`（或纯数字 `202411452365`）。
3. 结果：**查不到**；匿名/无头环境下还会弹出 CNKI 登录框，最终报「在线搜索失败：已放弃 CNKI 检索」。
4. 对照：换任意普通词（如「锂电池 热管理」「热管理」「量子计算」）可以正常返回结果；纯数字申请号则返回一堆与申请号无关的「热管理」文献。
5. 对照 CNKI 网页版：字段选「申请号」、检索范围限定「专利」，即可命中该专利。

结论：**数据在 CNKI，红豆检索构造缺「申请号字段」与「专利范围」两个维度，且把「查无此词」误报成「已放弃检索」。**

---

## 二、问题清单（按严重度）

| # | 级别 | 问题 | 证据 |
|---|------|------|------|
| 1 | 致命 | 无「申请号/专利号」检索字段 | `[源码]` |
| 2 | 致命 | 跨库检索范围不含专利库 | `[源码]` |
| 3 | 致命 | 专利导出类型判定缺映射，默认回退期刊 | `[源码]` |
| 4 | 严重 | 空结果被误判为 Cookie 失效，报「已放弃检索」 | `[源码]`+`[实测]` |
| 5 | 严重 | MCP 通道下正常中文检索挂起超时（>200s） | `[实测]` |
| 6 | 中 | `identifier` 字段硬映射为 DOI，申请号/ISBN 必查空 | `[源码]` |
| 7 | 中 | UI 无子库/范围选择，`dbCode` 写死跨库 | `[源码]` |
| 8 | 中 | 字段标签与实际映射不符 | `[源码]` |
| 9 | 轻 | 作者/机构解析混入单位、creatorType 不一致 | `[源码]` |
| 10 | 轻 | 语种/来源硬编码，外文结果被标 zh-CN | `[源码]`+`[实测]` |

stanley

## 三、逐项根因与证据

### 检索构造层

1. **字段写死主题** `[源码 cnki/search.js]`
   普通检索请求体写死：

   ```
   QNode.QGroup[0].Items[0] = { Field: "SU", Value: 查询词, Operator: "TOPRANK" }
   ```

   申请号不是「主题」内容，必然匹配不到。

2. **字段映射表缺申请号** `[源码]`
   `buildAdvancedQuery` 的 `fieldMap` 仅：

   ```
   all→SU, title→TI, author→AU, subject→KY,
   abstract→AB, source→JN, identifier→DOI,
   affiliation→AF, classification→CLC
   ```

   没有申请号/专利号字段。

3. **跨库范围不含专利库** `[源码]`
   总库 `KuaKuCode` 写死为：

   ```
   YSTT4HG0,LSTPFY1C,JUP3MUPD,MPMFIG1A,WQ0UVIAA,
   BLZOG7CK,EMRPGLPA,PWFIRAGL,NLBO1Z6R,NN3FJMUV
   ```

   对照 `config.js`，中国专利 `OORPU5FE`、海外专利 `U8J8LYLV` 均不在内 → 跨库检索从不查专利。

4. **子库配置从未被使用** `[源码]`
   `config.js` 定义了中国专利/海外专利等 16 个子库，但调用链
   `_doSearch → _searchOneEngine → engine.search(query, options)`
   的 `options` 从不传 `db`/`subId`；`onlineSearch.xhtml` 中亦无任何子库/范围选择控件。仅单库时才会用到 `subId`，实际不可达。

5. **字段名实不符** `[源码]`
   UI 中 `identifier` 标签为「DOI/其他标识符」、`classification` 标签为「学科/分类」，
   但 CNKI 实际映射为 `DOI` 与 `CLC`（中图分类号）——把 ISBN/申请号粘进「其他标识符」必然查空。

stanley

### 结果解析/类型判定层

6. **专利类型判定缺失** `[源码 cnki/parser.js]`
   `_getItemType` 先看 `Reference Type`，再看 `DataType`，都对不上就：

   ```
   return 'journalArticle';
   ```

   而 `_typeMap` 仅 `{1:journalArticle,2:thesis,3:conferencePaper,4:newspaperArticle,5:book,6:standard,60:patent,61:document,62:standard}`——**没有 7/8（专利）**。专利若走「Reference Type 缺失」路径即落默认期刊。

7. **导出块按序号对齐，专利易串行** `[源码]`+`[推断]`
   `_getExportList` 用 `textData.split('\r\n\r\n')` 切块后**按序号**与 `resultMetadata[i]` 对齐。专利块结构与期刊不同，序号错位导致字段串行 → 与用户「内容完全是错的」吻合。需一份真实专利的 NoteExpress 导出文本坐实。

8. **作者/机构解析** `[源码]`
   `cnkiProvider._createItem` 中把 `publisher`、`authorAddress` 也塞进 `creators`（注释自承二者是单位信息）；同一产品内 `parser` 路径对专利用 `inventor`、provider 路径统一用 `author`，creatortype 不一致。

9. **语种/来源硬编码** `[源码]`+`[实测]`
   `_createItem` 硬设 `language='zh-CN'`；实测 `石墨烯电池` 返回大批英文文献，语种/来源标识失真。

### 认证/会话层

10. **空结果误判为 Cookie 失效** `[源码]`
    `_responseIndicatesInvalidCookies` 对「既非搜索结果、又非完整 HTML、又含 no-content」的响应判为 Cookie 失效；配合 `retryOnNoContentWithoutLoginCookie: page===1`，**首屏无结果会被当成登录失效**，弹登录 → 无头环境中止 → 抛 `已放弃 CNKI 检索`。

11. **实测：申请号 → 假报「已放弃」** `[实测]`
    MCP `hongdou_online_search(query="CN202411452365.8", database="cnki")` 约 16s 返回
    `在线搜索失败：已放弃 CNKI 检索`。真实原因（查无此词）被掩盖。

12. **实测：正常检索挂起** `[实测]`
    MCP `hongdou_online_search(query="锂电池 热管理", database="cnki")` **>200s 无返回**，CNKI 通道在 MCP 下基本阻塞。

### MCP 暴露层

13. **MCP 能力不足以复现网页版查法** `[源码]`
    - `hongdou_online_search`：仅 `query` + `database` 枚举，无法指定子库/字段；
    - `hongdou_fetch_metadata`：自动类型识别只认 doi/isbn/pmid/arxiv，粘申请号报「无法自动识别标识符类型」；
    - `hongdou_import_item`：`itemType` 默认 `journalArticle`。
    结论：红豆 MCP 对「用申请号查专利并正确落成专利条目」做不到——它只是同一套有缺陷引擎的包装。

---

## 四、待确认项

1. 审计工具自身无法用「申请号字段 + 专利范围」复现 CNKI 网页版结果（其可用字段为 `主题/题名/关键词/题名或关键词/摘要`，范围为 `全部文献/期刊`），故「CNKI 确有该专利、仅红豆查不到」以用户截图为准，未独立复现。
2. 现象 7（导出块错位）需真实专利导出文本坐实。