科研 AI 可信输出不只靠模型能力，还要解决来源追踪与版本漂移

科研 AI 的输出如果只有结论，复核工作仍然要回到人工检索。

上海人工智能实验室提出的"给答案、给来路、给复现"，把问题推进到了证据链设计：来源能否定位，版本能否确认，引用能否回到原文，生成内容能否再次核对。

我的判断是，科研 AI 的可复现不应只被当作输出格式问题，而要落在数据身份、权限边界和内容校验这些工程机制上。

1 核心结论：可复现需要三层信息同时存在

科研 AI 输出一段结论时，至少要能回答三个问题：

• 这个结论来自哪里？
• 引用对应的是哪个对象和哪个版本？
• 读者能否根据记录回到相关内容进行核验？

其中，来源名称并不足以承担身份识别。

一个作品可能同时存在 preprint 和 journal 版本，DOI也不适合作为单一身份。

工程实现需要保留更稳定的组合信息：library_id + item_key + version。

这类设计把"引用可信"从语言表达转成了可检查的数据关系。

生成内容可以继续变化，但来源身份、版本信息和授权边界需要保留。

2 正在发生的转向与缺口

科研 AI 正从"给答案"转向同时提供答案、来路和复现路径。

缺口在于，很多系统的可信度仍然停留在引用展示层面，用户看到出处，并不等于能够确认出处与当前内容的对应关系。

可复现要求系统继续处理版本、身份和上下文。

缺少这些信息时，引用即使形式完整，后续核验仍可能中断。

3 关键技术机制：把证据链拆成可检查的对象

3.1 外部身份不能只依赖标题或 DOI

标题可能相同或发生变化，DOI也可能对应不同出版形态。

当前给出的工程规则是使用：

library_id + item_key + version

其中：

• library_id 用于识别外部文献库；
• item_key 用于定位库内对象；
• version 用于区分对象的具体版本。

DOI可以参与去重建议，但不承担单一身份。

这样处理的代价是，系统需要保存更多元数据，也需要在导入、同步和更新时维护版本关系。

换来的结果是，引用对象不再只由一串标题或标识符代表。

3.2 数据需要明确"谁拥有修改权"

知识库与外部文献管理工具协作时，自动修改范围必须受到限制。

可以按数据类型划分权威方和动作边界：

• 标题、作者、年份、DOI、venue：由 Zotero 作为权威方，默认只读，不自动覆盖。
• PDF 和附件：由 Zotero 或用户管理，每个任务显式授权，不默认拉取全库。
• 用户普通 note：由用户管理，只读或等待用户手动选择，不自动修改。
• 生成的 child note：允许系统幂等更新，同时保留版本和撤销能力。
• `zhiya/*` tag：允许系统更新自己的命名空间。
• collection membership：由 Zotero 或用户管理，第一版不自动修改；Inbox由用户放入，或在明确授权后创建。

这里的关键不在于"自动化程度"高低，而在于修改责任是否清楚。

来源数据、用户笔记和系统生成内容采用不同规则，可以减少同步时的覆盖风险。

3.3 幂等更新需要配合版本和撤销

生成的 child note允许幂等更新，意味着重复执行相同任务时，系统可以关于同一对象更新，而不是持续制造无法区分的新副本。

但幂等本身不等于可追溯。

要支持复核，还需要保留版本和撤销能力。

版本记录解决"之前是什么"，撤销能力解决"如何回到之前的状态"。

二者共同构成生成内容的变更记录。

这也是一个实际取舍：保留版本会增加存储和管理复杂度；不保留版本，则难以解释一段内容何时发生变化、变化依据是什么。

3.4 段落级校验比整篇引用更接近复核动作

引用粒度会直接影响核验路径。

整篇文档级引用只能说明内容大致来自某个来源，段落级校验则能把具体表述与对应片段关联起来。

在这个机制下，检查动作可以按以下顺序展开：

1. 定位生成内容对应的段落。
2. 回到来源中的相关片段。
3. 核对上下文与版本信息。
4. 检查当前表述是否超出来源支持范围。
5. 对修改后的内容重新保留对应关系。

这种方式并不能替代研究者判断，也不意味着每个生成结论天然正确。

它解决的是"依据在哪里、对应哪一段、使用哪个版本"的工程问题。

3.5 权限边界会影响证据链的完整度

PDF、附件和普通 note并不适合采用同一种访问规则。

默认全库拉取会扩大数据读取范围，也会让任务与来源之间的关系变得不清楚。

每个任务显式授权附件，普通 note保持只读或等待手动选择，能够把输入范围记录在任务边界内。

这样做的代价是操作步骤增加，系统也不能假设自己可以访问所有资料。

对于需要追溯的科研内容，这种限制有助于说明某次生成究竟使用了哪些材料。

4 横向对比：不同工具形态对应不同复现条件

工具之间的差异，应放在使用场景和证据要求中观察，而不是简单判断高低。

• 通用问答工具：适合快速获取文本答案，但当任务要求定位来源、确认版本和回到原文时，需要额外建立证据记录。
• 文献检索工具：通常更接近学术检索和信息提取场景，若要完成深度成稿，还需要补充内容组织与版本管理机制。
• 知识管理工具：能够承载长期资料与笔记，但是否支持段落级校验、外部身份约束和生成内容撤销，需要单独核对。

我的看法是，工具选择应先看复现要求。

如果任务只需要摘要，来源展示可能已经足够；如果内容要进入论文、报告或长期知识库，身份、版本和权限记录就不能被省略。

5 工程落地：把复现要求前置到任务设计

以知芽 Notebook Skill作为一种实现案例，它的技术重点不在于单独增加一个引用按钮，而在于把身份、版本、授权和段落级校验放进内容处理过程。

落地时可以按以下顺序检查：

1. 定义来源身份

明确使用 library_id + item_key + version，不要把标题或 DOI单独当作单一身份。

1. 划分数据权威方

区分 Zotero、用户与系统生成内容的所有权，明确哪些对象只读，哪些对象需要用户授权。

1. 限制任务输入范围

PDF 和附件按任务显式授权，普通 note不自动修改，避免输入边界无法解释。

1. 保留生成内容版本

对 child note支持幂等更新，同时记录版本和撤销状态。

1. 按段落建立校验关系

让输出段落能够回到来源片段，并核对对应版本和上下文。

1. 再进行人工复核

系统记录可以缩短定位路径，但不能替代研究者对论证是否成立的判断。

6 用户价值：减少"找不到依据"的返工

这套机制直接对应的使用价值，是让研究者在回看内容时能更快定位来源、版本与修改记录。

它并不承诺消除所有事实判断，也不把人工复核从流程中移除。

对于需要长期维护的知识库，用户更关心的往往不是一次输出是否完整，而是内容变化后还能否解释依据和历史状态。

7 关键知识点 Q&A

7.1 Q1：科研 AI 的可复现具体要记录什么？

至少要记录来源身份、版本信息、输入授权范围，以及输出段落与来源片段之间的对应关系。

外部身份可使用 library_id + item_key + version，DOI适合用于去重建议，不宜单独承担单一身份。

7.2 Q2：为什么不能只保存论文标题或 DOI？

同一作品可能存在 preprint 和 journal 两个合法 DOI，标题也可能发生变化。

只保存标题或 DOI，难以准确区分具体对象和版本，后续引用核验容易失去上下文。

7.3 Q3：如何避免同步过程覆盖用户资料？

先划分数据权威方。

标题、作者、年份、DOI、venue由 Zotero默认只读；用户普通 note不自动修改；系统生成的 child note可以幂等更新，但需要保留版本和撤销能力。

7.4 Q4：段落级校验解决了什么问题？

它把核验单位从整篇文档缩小到具体段落，使研究者能够回到相关来源片段，检查表述是否与上下文和版本一致。

它解决的是定位与对应关系，不替代人工判断。

7.5 Q5：自动化越多，复现能力就越强吗？

不一定。

自动化范围越大，越需要明确授权和修改边界。

对附件、普通 note和 collection membership采用不同权限规则，能够让任务输入和内容变更更容易解释；代价是部分操作需要用户明确选择。

科研 AI 的可复现最终落在工程细节：对象身份要稳定，版本变化要可追踪，输入范围要有授权，输出内容要能回到来源片段。

答案、来路与复现路径只有同时保留，证据链才具备可核验性。