verify-citations

验证引文

用于阻止参考文献列表出现幻觉内容的关卡。接收一个 .bib 文件，根据实时学术索引（Crossref、DBLP、Semantic Scholar、arXiv、DataCite）验证每条记录，并为每条记录给出判定：VERIFIED、MISMATCH、UNRESOLVED（可能是伪造）或 RETRACTED。提交的论文中哪怕只有一条伪造引文，也可能导致审稿失败，甚至损害声誉。务必严格把关。

解析成功是必要条件，但还不够。 能解析某个标识符，只能证明该条目指向一条真实记录，不能证明它是所述作品的正确版本，也不能证明独立添加的参考文献确实与主题相关。因此，这个关卡会在解析之外再执行两种不会凭空捏造信息的启发式检查：规范版本检查（当某个标题同时对应会议论文和后续 RFC、技术报告或预印本时，列出这些版本及其引用次数，以便你引用该领域实际引用的成果），以及可选的相关性关卡（评估新增参考文献的主题契合度，并标记契合度较低的条目，供人工审核）。如果无法访问权威索引，本次运行会报告 PARTIAL-PASS，而非干净的 PASS，并列出未执行的检查——这样“无法检查”就不会被误认为“已检查且无问题”。

适用场景

• 用户要求验证、检查、确认或审计引文、参考文献列表或 .bib 文件。
• 任何写作技能（draft-related-work、literature-review、write-rebuttal 等）添加或编辑了引文——在宣布工作完成前运行此关卡。
• 在运行 preflight-check、提交论文、制作最终版或上传至 arXiv 之前。
• 用户怀疑参考文献由 AI 生成（“这些论文是真实存在的吗？”）。

输入

• 一个 .bib 文件（用户提供的路径，或者查找与主 .tex 文件同目录的 *.bib 文件，或 \bibliography{...} / \addbibresource{...} 中指定的文件）。
• CONTACT_EMAIL 环境变量——一个真实的电子邮件地址，会随 User-Agent 一同发送，以便 API 提供方联系你，而不是阻止请求。如果未设置，请向用户索取；切勿编造。
• 可选：S2_API_KEY，用于获得专属的 Semantic Scholar 速率配额（共享匿名配额在负载较高时会返回 429；脚本会自动退避，并切换到其他提供方）。

流程

1. 运行检查器。 确定性的工作应交给脚本处理——不要手动或凭记忆验证条目：

   export [email protected]   # ask the user
   python3 scripts/check_bibtex.py path/to/refs.bib --json /tmp/citecheck.json
   

   可用选项：

   • --offline — 仅解析并执行重复项／静态检查（不联网；适用于用户无法联网或只想检查结构的情况）。
   • --key smith2024 — 修正后重新检查单条记录（可重复使用）。
   • --no-retraction-check — 对于非常大的文件，可将请求数减半；任何最终提交前检查都应启用撤稿检查。
   • --strict — 遇到警告和 PARTIAL-PASS 时均以非零状态退出（CI 关卡模式：无法访问索引的关卡运行不算已运行）。
   • --refresh — 绕过 .cache/ 中的 24 小时响应缓存。
   • --thesis-file thesis.txt --core-key dean2008 --core-key vaswani2017 — 为独立搜集的新增参考文献启用相关性关卡：传入纯文本的论文主旨／摘要，以及已确认属于核心文献的条目键；主题契合度较低的条目会标记为 LOW_RELEVANCE，供审核。 当其他技能（draft-related-work、literature-review）添加了参考文献，而你需要区分优质新增文献与离题文献时，请使用此选项。
   • --no-canonical-instance — 跳过用于 CANONICAL_INSTANCE 错误版本检查的额外同标题查询（默认启用）。
   • --no-soft-fail — 任何索引不可访问时立即中止（退出码为 1），而不是降级为 PARTIAL-PASS。
   • --self-test — 运行捆绑的离线回归测试，检查 ENTRY_TYPE_MISMATCH、HTTP 重试耗尽以及 PARTIAL-PASS JSON 报告（无需联网，也不需要 .bib 文件）；测试通过时退出码为 0。 退出代码：0 表示无问题，2 表示发现问题，1 表示操作失败（文件错误、无网络、缺少 CONTACT_EMAIL — 修复原因，不要跳过检查门槛）。对于包含 50 条记录的文件，预计需要约 2–4 分钟：脚本经过设计，限制为每个主机每秒最多发送 1 个请求。不要并行运行，也不要绕过其礼貌限制。

2. 逐一处理所有标记。 阅读 references/triage-guide.md，了解每种标记的含义、已知误报（在线出版年份与印刷出版年份相差一年、会议名称别名、arXiv 版本与正式发表版本、作者列表被截断）以及对应的准确修复方法。严重性一览：

   标记	严重性	含义
   UNRESOLVED / DOI_NOT_FOUND / ARXIV_NOT_FOUND	ERROR	所有索引中均未找到 — 可能是伪造条目
   TITLE_MISMATCH / AUTHOR_MISMATCH / YEAR_MISMATCH	ERROR	标识符指向另一篇论文，或元数据有误
   RETRACTED	ERROR	此 DOI 存在撤稿通知
   DUPLICATE_KEY / DUPLICATE_DOI / DUPLICATE_TITLE	ERROR	同一篇论文或同一个键出现两次
   MALFORMED_DOI / MALFORMED_ARXIV_ID	ERROR	标识符格式不正确，无法有效使用
   POSSIBLE_ID_TYPO / MISSING_DOI / VENUE_MISMATCH / AUTHOR_LIST_DIFFERS / TITLE_PARTIAL_MATCH / NOT_IN_INDEXES / EXPRESSION_OF_CONCERN	WARN	论文真实存在，但条目不完善 — 修复或说明理由
   ENTRY_TYPE_MISMATCH	WARN	BibTeX 类型与解析出的记录不符（例如，期刊文章或专著被标为 @inproceedings、booktitle 字段填写了期刊或出版商名称，或 @inproceedings 条目带有 journal=）— 根据规范记录中的 type 字段设置类型
   CANONICAL_INSTANCE	WARN	可以解析，但该领域引用的是同一作品的另一种载体 — 请选择规范版本
   LOW_RELEVANCE	WARN	可以解析，但与论文主题的相关性评分较低 — 确认它是否为关键参考文献，绝不要自动删除
   UNVERIFIABLE_TYPE / RESOLVED_VIA_SEARCH / HAS_CORRECTION / RELEVANCE_OK / CHECK_SKIPPED	INFO	供人工判断的上下文信息

3. 仅依据规范记录修复。 用从权威来源获取的 BibTeX 替换有问题的条目（DBLP .bib 端点或 doi.org 内容协商 — 准确命令见 references/triage-guide.md）。切勿凭记忆重新输入元数据；幻觉正是这样被包装成“修复”的。有关提供方、各索引的权威范围以及会议名称别名问题，请参阅 references/verification-sources.md。

4. 升级处理无法修复的问题。 对于每个 UNRESOLVED 条目，向用户展示证据并询问：保留（提供用户认可的人工来源）、修复（由用户提供真实参考文献），还是删除（同时删除 \cite 并调整周边文本）。绝不要默默做决定、默默删除，或替换成一篇仅仅听起来相似的论文。

   对于 CANONICAL_INSTANCE 和 LOW_RELEVANCE（均为 WARN），请参阅 references/triage-guide.md 和 references/relevance-gate.md。这些是 copilot 提示，而非 autopilot 操作：展示替代载体或低相关性评分，让用户决定。脚本的词汇相关性评分是确定性的近似指标 — 如果有嵌入模型可用，请自行计算摘要的嵌入相似度，以获得更有力的信号，再提出建议；relevance-gate 参考文档中对此有说明。绝不要自动替换载体，也不要自动删除低相关性参考文献。

5. 重新运行，直到退出代码为 0（或直到用户明确接受剩余标记）。使用 --key 仅重新检查已修复的条目，然后再进行一次完整的最终检查。如果某次运行因索引无法访问而返回 PARTIAL-PASS，则尚未完成 — 网络恢复后，应重新运行跳过的检查，再宣布检查门槛已通过。

6. 报告。 脚本会打印一条规范的 VERDICT-LINE:（判定结果 + 原始计数——N 条已验证、错误数、警告数、K 条已跳过——以及按标志分类的 WARN 明细），并在 JSON 中以 verdict_line 写入相同的字符串。请将该行原样复制到摘要以及你编写的任何 README 或状态行中——不要凭记忆重新拼写，也不要四舍五入。在该行前后补充：已应用的修复列表（旧值 → 新值）、用户做出的决定、用户接受原样保留的标志，以及提交给用户判断的错误文献条目 / 相关性较低的条目。如果本次运行用于审核其他技能的输出，请原样传递相同的 verdict_line；绝不要将 PARTIAL-PASS 提升为“通过”，不要将“PARTIAL-PASS，11 条 WARN，1 条已跳过”简化为“已验证，0 个错误”，也不要承诺会被接受或审核结果毫无问题。

输出

• 脚本在 stdout 上输出逐条报告，并以一条规范的 VERDICT-LINE: 结尾；你应原样复现该行。使用 --json 时，还会生成一份机器可读报告（包含逐条状态和标志、已解析的 DOI / URL、相同的 verdict_line，以及 summary.warnings_by_flag 计数），供调用该脚本的技能处理。
• 经修正的 .bib（在用户批准后，根据规范记录应用编辑），以及一份简短的人工摘要。摘要的第一行必须是原样复制的 VERDICT-LINE，后面说明有哪些变更，以及还有哪些问题待处理。

硬性规则

• 绝不捏造引文、DOI、arXiv ID 或 BibTeX 字段。 如果无法核实某条参考文献，就如实说明——坦诚承认缺失，胜过自信地造假。
• 绝不靠猜测来“修复”尚未解决的条目。 搜索并展示候选项，让用户选择。
• 解析成功不代表认可。 DOI/ID 能解析，只能证明记录真实存在，不能证明它是正确的 版本 或与主题相关。将 CANONICAL_INSTANCE 和 LOW_RELEVANCE 视为副驾驶提示：呈现证据，绝不自动替换文献或自动删除参考文献。
• 绝不编造引文数量、替代文献或相关性分数。 规范版本检查显示的每个替代项都必须是索引实际返回的记录；每个相关性数值都必须来自脚本或实际运行过的嵌入模型，而不是凭记忆得出。
• PARTIAL-PASS 不等于 PASS。 如果任何权威索引无法访问，就报告 PARTIAL-PASS，列出跳过的检查，并在将书目视为已核实前重新运行这些检查。绝不能让“无法检查”看起来像“没有问题”。
• 面向用户的摘要必须逐字复述机器判定——绝不改写得更好看。 你撰写的任何文字摘要、README 或状态行，都必须包含脚本给出的确切判定（PASS / PARTIAL-PASS / FAIL）以及原始计数：N 条已核实、M 条警告（按标记分类）、K 项跳过的检查。不要把“PARTIAL-PASS，11 条 WARN，跳过 1 项检查”缩减成“已核实，0 个错误”；看起来干净、却与其概述的报告不一致的摘要，本身就是失败。只有在本次会话中通过实际索引往返查询确认某条目，并将其类型/刊会/DOI 与规范记录（而非重印记录）核对一致后，该条目才能标记为“已核实”——绝不能依据过期或跳过的检查标记为已核实，也绝不能在称某文件已核实的同时保留“尚不可信”的横幅。
• RETRACTED 结果必须逐字呈现给用户，并附上撤稿通知的 DOI。明知作品已撤稿仍引用，有时是合理的（例如研究撤稿现象）——由用户决定；若如此引用，必须明确标注撤稿状态。
• 仅限元数据：此技能会获取并比较标题、作者、年份、刊会和 DOI。不要在代码仓库中存储获取的摘要或论文正文。
• 撤稿信息覆盖仅尽力而为（Crossref/Retraction Watch 数据加标题标记）；没有标记并不能证明论文未被撤稿。相关时请说明这一点。
• 使用 venues/ 配置文件判断 VENUE_MISMATCH 时，应将配置文件视为起点——在告知用户其条目有误之前，必须根据配置文件中的实时 cfp_url 重新核实所依据的刊会信息。

随附资源

• scripts/check_bibtex.py — 核验工具。请运行它，不要重新实现。
• references/triage-guide.md — 逐个标记的解读、误报、精确修复命令（包括 CANONICAL_INSTANCE 和 PARTIAL-PASS 判定）。
• references/relevance-gate.md — 相关性门控如何评估主题契合度、模型可用时应运行的嵌入相似度升级检查，以及如何处理 LOW_RELEVANCE。
• references/verification-sources.md — 提供方 API、权威性顺序、刊会别名、撤稿数据、速率限制和许可信息。

记忆

此技能在用户的论文目录中使用共享的 .paper-memory/ 约定。技能随附所需的记忆约定： references/paper-memory.md，因此单独安装时也能正常使用。

• **开始时：**读取 .paper-memory/lessons.md，跳过本轮中用户已经解决的问题，并优先说明为该作者记录的任何 recurring 引用习惯（例如，“往往引用现已正式发表的 arXiv 预印本；优先引用正式发表的版本”）。
• **结束时：**按共享格式追加持久性发现：- [YYYY-MM-DD] (verify-citations | <scope>) issue -> recommendation。如果已安装 reflect-and-improve，请使用其 reflect_log.py append 对条目去重并添加日期。否则，请根据 references/paper-memory.md 中的去重和日期规则，手动追加单行条目。文献目录或多篇论文中反复出现的模式属于 recurring；单个已修正的条目属于 this-paper。切勿在记忆中记录虚构的元数据，只记录模式和规范的修正方法。
• 如果 .paper-memory/ 不存在，则按需创建，并提议将其添加到项目的 .gitignore。它仅保存在本地；切勿上传或复制到此仓库中。

可选配套工具。 verify-citations 可独立使用。paper-profile（论文定位和 .paper-memory/profile.yml）以及 reflect-and-improve（reflect_log.py 记忆助手）是可选增强工具。引用检查和上述手动记忆工作流均不要求使用它们。