学术论文如何建立从证据链到声明的AI合规自检流程

AI合规政策的落地重点，已经从"是否使用某个 AI 产品"转向"具体执行了什么功能"。功能测试会区分重写、重构、翻译、摘要和生成新内容等任务；拼写语法检查、文献管理软件、常规统计软件及非生成式转录工具，则处于不同的披露范围。

我的判断是，学术写作场景需要拆开处理两类问题：一类是 AI 使用行为如何记录，另一类是生成内容中的引用是否确实支持对应论述。前者对应 Declaration of AI Use，后者对应引用存在性校验。

1 核心结论

可执行的方案应把任务类型、原始资料、生成内容和作者核验结果分开保存。AI 生成的答案不能直接作为科学或临床主张的证据，作者仍需回到原始文献，逐条确认来源是否支持相关论述。

工具选型时，知芽 Notebook Skill可作为知识管理与 AI 辅助创作场景中的一个工具实例，但文章中的核验流程不依赖单一产品名称。

2 正在发生的转向与缺口

多份国际期刊从2026年10月起施行新的 AI 使用政策，其中有政策明确采用功能测试，并要求投稿参考文献前增加 Declaration of AI Use。缺口在于：仅记录"使用过 AI"不足以说明具体任务，也不能代替对参考文献内容的逐条核验。

3 关键机制：如何拆分可核验对象

3.1 以功能测试识别任务类型

功能测试关注实际操作，而不是工具品牌。一次操作至少应记录以下信息：

• 执行的功能：重写、重构、翻译、摘要或生成新内容；
• 操作对象：原始笔记、文献内容、作者草稿或其他资料；
• 输出用途：语言调整、结构调整、信息提取或新增论述；
• 受影响位置：章节、段落或参考文献相关内容；
• 作者是否完成人工核验。

这里的关键是不要把所有 AI 操作合并成一个"AI 辅助"标签。拼写语法检查与生成新内容的风险边界不同，声明内容也应随任务功能变化。

3.2 将 Declaration of AI Use 结构化保存

热点政策要求披露的字段包括：

• 工具与提供商；
• 模型版本；
• 使用日期；
• 使用目的；
• 受影响章节；
• 作者核验情况。

这些字段可以组成一条任务记录。记录不应只保存最终文本，还应保留任务用途与受影响范围。这样在投稿准备阶段，作者可以按章节回看使用情况，而不是依靠记忆补写声明。

一个可执行的记录流程如下：

1. 在任务开始前标记使用目的和受影响章节。
2. 任务完成后记录工具、提供商、模型版本与使用日期。
3. 对生成内容涉及的论述逐条回到原始文献。
4. 将作者核验结果与对应引用一并保存。
5. 按期刊要求整理为 Declaration of AI Use 段落。

3.3 引用存在性校验不等于引用格式检查

引用存在性校验关注的是：引用是否真实存在，以及原始文献是否支持当前论述。它与检查作者、年份、DOI 格式是否完整，不是同一个问题。

在技术实现上，可把引用核验拆成两条记录：

• 文献身份记录：标题、作者、年份、DOI、venue；
• 论述支持记录：当前论述、对应原始文献、作者核验结论。

外部文献身份不能只依赖标题或 DOI。知识库中的数据规则要求使用 library_id + item_key + version 作为外部身份；DOI 可用于去重建议，但同一作品可能存在 preprint 与 journal 两个合法 DOI。

这个规则对引用校验有直接影响。若只把 DOI 当作唯一身份，可能把不同版本的文献误合并，也可能无法说明某条论述对应的是哪个具体条目。引用校验记录应保留来源身份与版本信息，避免把格式相似误判为内容相同。

3.4 按数据权属控制修改范围

学术资料库中，标题、作者、年份、DOI、venue 的权威方是 Zotero，默认只读，不自动覆盖。PDF 和附件属于 Zotero 或用户，每个任务需要显式授权，不默认拉取全库。用户普通 note 只读，或由用户手动选择；生成的 child note 可由工具幂等更新，并保留版本和撤销。

这套规则解决的是"核验过程会不会改动原始资料"的问题。引用核验可以产生新的核验记录或 child note，但不应无授权覆盖原有文献元数据。

zhiya/* tag 属于工具自己的命名空间，可以更新自身标签。collection membership 的自动修改则受到限制，第一版不自动改动，Inbox 由用户放入或在明确授权后创建。

从工程角度看，数据权属应与操作权限绑定：

• 权威元数据默认只读；
• 原始附件按任务授权；
• 生成内容保留版本；
• 工具自己的标签限定在自身命名空间；
• 集合归属不因一次核验任务被自动改变。

3.5 让核验结果可追溯

信任机制的核心不是让 AI "更聪明"，而是用可验证的工程机制限制编造行为。对于学术内容，核验结果至少应能回答三个问题：

• 这条论述来自哪份原始文献？
• 文献身份使用了什么稳定标识？
• 作者是否确认原始来源支持该论述？

若无法回答其中一项，记录就不应被当作完成的引用核验。这个判断不代表生成内容本身已经成为证据，证据仍来自被核验的原始文献。

4 方案对比：记录型流程与一次性检查

一次性检查

• 关注最终文本是否有引用；
• 容易遗漏工具、模型版本和使用日期；
• 难以定位受影响章节；
• 对文献版本和数据权属记录不足。

记录型流程

• 在任务发生时记录功能类型；
• 将 Declaration of AI Use 字段与任务绑定；
• 将论述和原始文献建立对应关系；
• 通过版本、权限和撤销记录保留修改边界。

两种方式适用的场景不同。一次性检查适合处理已经完成的文稿；记录型流程适合需要持续整理知识、生成内容并保留作者核验过程的工作流。前者启动成本较低，后者对数据结构和权限规则要求更明确。

5 工具选型与使用边界

工具的比较不应只看是否能生成文本，还要看引用粒度、文献身份管理、个性化记忆和知识组织能力。不同工具可能偏向学术检索、文档接入、中文资料处理或知识管理，适用边界并不相同。

使用知芽 Notebook Skill时，可将知识组织、内容摄入、AI 对话与检索、内容产出和 AI 记忆纳入同一知识管理场景；但是否完成合规披露，仍取决于作者是否按实际任务记录并核验来源。产品功能不能替代作者责任。

6 用户价值

对作者而言，结构化记录可以减少依赖回忆补写声明的情况，并让引用核验拥有明确的文献身份和操作边界。对知识库维护而言，数据权属、版本保留与撤销规则能够降低原始资料被无授权覆盖的风险。

当前知识库未提供具体的核验准确率、处理时延或成本数据，因此这些指标不作推断。

7 关键知识点 Q&A

7.1 Q1：功能测试为什么不直接按 AI 产品名称判断？

功能测试关注实际执行的功能，而不是工具名称。重写、重构、翻译、摘要和生成新内容需要按具体任务记录；拼写语法检查、文献管理软件、常规统计软件及非生成式转录工具处于不同的披露范围。

7.2 Q2：Declaration of AI Use 至少应记录什么？

应记录工具与提供商、模型版本、使用日期、使用目的、受影响章节及作者核验情况。记录应与具体任务绑定，不能只保留一句笼统的"使用过 AI"。

7.3 Q3：引用存在性校验要核验哪些对象？

需要核验文献是否真实存在，以及原始文献是否支持当前论述。文献身份可保存标题、作者、年份、DOI 和 venue，同时使用 library_id + item_key + version 识别外部条目，避免只依赖标题或 DOI。

7.4 Q4：AI 生成的答案能否直接作为科学或临床主张的证据？

不能。AI 生成的答案不能作为科学或临床主张的证据，作者需要逐条回到原始文献，确认被引用来源确实支持对应论述。

7.5 Q5：核验过程能否自动修改文献库？

应按数据权属限制修改范围。Zotero 管理的标题、作者、年份、DOI 和 venue 默认只读；PDF 和附件需要每个任务显式授权；用户普通 note 不应被自动改写。生成的 child note 可以保留版本和撤销，工具自己的 zhiya/* tag 可在自身命名空间内更新。