引用元数据变化时如何用 Academic Research Skills 失效验证缓存条目并强制重新核对-编程实验室

引用元数据变化时如何用 Academic Research Skills 失效验证缓存条目并强制重新核对

【免费下载链接】academic-research-skillsAcademic Research Skills for Claude Code: research → write → review → revise → finalize项目地址: https://gitcode.com/GitHub_Trending/ac/academic-research-skills

在 Academic Research Skills（ARS）中跑论文引用存在性核对时，四个 resolver（Crossref、OpenAlex、Semantic Scholar、arXiv）的验证结果会被写入本地 SQLite 缓存，默认 90 天 TTL。如果你的某条引用在缓存命中之后发生了元数据变化——最典型的例子是预印本后来获得了正式发表的 DOI——或者你怀疑上一次验证结论本身有误，缓存会继续返回旧判定，直到过期或手动失效为止。本文的操作路径是：定位缓存 → 用/ars-cache-invalidate <citation_key>失效指定引用 → 让下一次 gate 运行对该引用强制做在线重新核对。

缓存在哪里、按什么键存

动手前先确认你要失效的对象在缓存中的位置，这决定了命令参数和可选的重定位方式：

默认缓存文件是~/.cache/ars/verification.db，首次使用时自动创建，无需额外初始化（docs/SETUP.md § Citation verification cache）。
缓存主键是(citation_key, resolver_name, query_form)，其中resolver_name取crossref/openalex/semantic_scholar/arxiv，query_form是 resolver 当时使用的 DOI、arXiv ID 或题名查询串（scripts/verification_cache.py）。
每条记录 90 天 TTL：过期只意味着按 miss 处理（触发在线重查并回填），行本身仍留在磁盘上，直到被后来的重验覆盖、被失效命令删除，或整个文件被删除（docs/DATA_FLOWS.md）。
如果你用ARS_VERIFICATION_CACHE_PATH环境变量把缓存挪到了别处（例如跨项目共享一个缓存或放到更快的磁盘），失效命令操作的就是那个路径——CLI 内部通过同一个VerificationCache解析路径，显式路径 > 环境变量 > 默认路径。
缓存是单进程设计（SQLite WAL 模式），多用户共享同一个缓存文件不在支持范围内。

失效单个引用的缓存条目

在 ARS 会话中执行 slash 命令（<citation_key>换成你要重新核对的引用键，例如你 bib 文件里给该文献起的 key）：

/ars-cache-invalidate <citation_key>

该命令的实现是 commands/ars-cache-invalidate.md 中声明的：

python3 scripts/ars_cache_invalidate.py <citation_key>

两条等价的执行方式，在 Claude Code 会话里用 slash 命令，在仓库目录内直接跑脚本也一样。执行成功时，脚本会输出一行（见 scripts/ars_cache_invalidate.py）：

[ars-cache-invalidate] cleared cache for '<citation_key>'

命令的删除范围是精确的：该 citation key 下的全部缓存行——四个 resolver、所有 query form——其余引用完全不受影响。它是幂等的：对一个没有任何缓存行的 key 执行，也会以 no-op 成功结束，不会报错，所以不用担心"这条引用到底有没有进过缓存"。

失效之后发生了什么：级联重验

失效本身只是删行。真正让重新核对发生的是后续的验证 gate（#541 定义的无条件失效级联，见 commands/ars-cache-invalidate.md 与 docs/design/2026-05-21-v3.10-182-promote-citation-gate-spec.md §2 Delta 2）：

下一次 pipeline 运行到达 citation gate 时，该引用的缓存全部为 miss，resolver 会在线重查 Crossref / OpenAlex / Semantic Scholar / arXiv，而不是返回旧判定；
gate 重新生成该引用的 verification summary 行，并对引用了它的 claim 重新执行 Phase E audit verdicts——这一步是无条件的（不保留旧基线做 diff），覆盖存在性状态、元数据和已取回的证据三类内容。

也就是说，你不需要手工指定"重新查哪个 resolver"，删掉缓存行后在线重查和下游 verdict 重算会自动发生。

可选分支：不手动失效也能让旧缓存被重验

如果你面对的不是"某一条引用变了"，而是"缓存整体偏旧"，文档给了两条机制，可以替代或补充手动失效：

陈旧告警（默认开启）：缓存命中的行超过ARS_CACHE_STALE_ADVISORY_DAYS天（默认 30，设0关闭）时，仍按命中服务，但会在 Integrity Report 的 advisory 表里以ADV-CACHE-<n>行标出（引用键、缓存年龄、阈值、是否已在线重验）。注意它只是告警，永不参与 gate 判定（academic-pipeline/agents/integrity_verification_agent.md § A0.5）。
在线重验（需显式开启）：会话中设置ARS_CACHE_REVALIDATE=1后，gate 遇到超过陈旧阈值的缓存行会按行旁路缓存、在线重验并回填，而不是直接服务旧值；成本随过期行数增长。默认关闭，默认行为就是上面的告警模式（docs/SETUP.md § Optional environment flags）。

告警机制的价值在于它把"哪条引用的缓存旧了"直接展示在 checkpoint 上，你可以据此只对确有必要的那几条执行/ars-cache-invalidate，而不是无差别清缓存。

整库失效：仅限 resolver 系统性出错的场景

文档明确给出的另一条路径是删除整个数据库文件，适用于"resolver 系统性故障导致大量假阴性被缓存"这类情形：

rm ~/.cache/ars/verification.db

副作用必须清楚：这会删除所有引用的全部缓存行（包括那些结论完全正确的），下一次运行时文件会被以空库重建，所有引用都要重新走在线核对。如果你的缓存挪到了ARS_VERIFICATION_CACHE_PATH指向的位置，删的应该是那个文件，而不是默认路径。引用只有一两条需要重验时，优先用上面的单 key 失效命令。

验证与已知限制

完成操作后，按文档给出的行为核对以下几点：

命令输出应出现cleared cache for '<citation_key>'；对未进缓存的 key 执行同样返回成功（no-op），这是预期行为而非失败。
下一次 pipeline 运行时，该引用不再返回缓存判定，而是在线重验；ARS_CACHE_REVALIDATE=1模式下，超过阈值的行也会显示为"已在线重验"而非缓存服务。
其他引用的缓存行仍在，不受单 key 失效影响。

适用限制：该缓存服务于 citation 存在性核对（#182 gate）这一个场景，retraction_status.py的撤稿状态缓存是另一个独立的存储（调用方自行提供路径），本文的失效命令不作用于它（docs/DATA_FLOWS.md）。90 天 TTL 本身是规格中列为待经验调参的值（OQ-1），当前以文档给出的 90 天为准。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考