AI合规政策下的功能测试与引用存在性校验实现

AI合规政策正在把问题从"是否使用了某个AI产品"转向"AI具体执行了什么功能"。2026年10月起，多份国际期刊将引入功能测试标准，并要求作者通过 Declaration of AI Use 说明工具、模型版本、使用日期、使用目的、受影响章节及作者核验情况。

对开发者而言，难点不在于生成一段声明，而在于让生成内容与原始文献之间保持可检查关系。

1 核心结论：合规要求落在功能与证据上

功能测试不看产品名称，而看实际行为。重写、重构、翻译、摘要和生成新内容需要声明；拼写语法检查、文献管理软件、常规统计软件及非生成式转录工具不在该声明范围内。

另一项要求是，AI生成的答案不能直接作为科学或临床主张的证据。作者需要回到原始文献，逐条核验引用是否真实存在，以及原始来源是否支持对应论述。

我的判断是，AI合规政策带来的工程变化，可以拆成两个独立问题：

• 功能识别：本次操作是否属于需要披露的生成式功能。
• 证据核验：文本中的引用是否存在，且是否能回到原始文献进行检查。

2 正在发生的转向与缺口

传统内容流程往往把参考文献当作输出末尾的格式化结果。新的要求把参考文献前移到生成与审校过程，要求工具、使用目的和作者核验情况具有可说明性。

缺口也很明确：仅有一段 Declaration of AI Use，不能替代对引用的逐条检查；仅能列出文献题目，也不能说明生成论述是否得到原始来源支持。

3 技术机制：把引用存在性校验拆成可执行步骤

3.1 把引用标识与正文主张分开

引用存在性校验的最小对象不是整篇文章，而是"正文主张 + 引用标识"这一对关系。

可以先将正文拆成若干带引用的文本单元，再提取每个单元中的引用标识。示意代码如下：

import re
from dataclasses import dataclass

@dataclass
class CitationClaim:
    claim: str
    citation_keys: list[str]

def extract_claims(text: str) -> list[CitationClaim]:
    claims = []

    for sentence in re.split(r"[。！？\n]", text):
        sentence = sentence.strip()
        if not sentence:
            continue

        keys = re.findall(r"\[@([A-Za-z0-9_-]+)\]", sentence)
        if keys:
            claims.append(
                CitationClaim(
                    claim=sentence,
                    citation_keys=keys
                )
            )

    return claims

这段代码只做结构化拆分，不判断论述是否正确，也不判断来源是否支持论述。它的作用是把后续人工核验所需的对象明确下来。

3.2 检查引用是否存在

"引用存在性"首先回答一个较窄的问题：正文中出现的引用标识，是否能在参考文献集合中找到对应记录。

def validate_citation_existence(
    claims: list[CitationClaim],
    bibliography: dict[str, dict]
) -> list[dict]:
    results = []

    for item in claims:
        for key in item.citation_keys:
            record = bibliography.get(key)

            results.append({
                "claim": item.claim,
                "citation_key": key,
                "exists": record is not None,
                "record": record
            })

    return results

输入可以是本地整理的参考文献记录：

bibliography = {
    "paper_001": {
        "title": "Example paper",
        "authors": ["Author A"],
        "year": 2024,
        "doi": "10.xxxx/example"
    }
}

text = "该方法改善了实验结果[@paper_001]。"
claims = extract_claims(text)
results = validate_citation_existence(claims, bibliography)

for result in results:
    print(result)

这里的 exists 只代表引用键在参考文献集合中存在。它不等于来源内容已经支持正文主张，也不等于论文元数据已经完成核验。

这个边界需要保留。把"存在"写成"支持"，会让校验结果产生过度承诺。

3.3 从引用记录回到原始文献

引用存在性校验完成后，仍然需要回到原始文献，检查正文主张与来源内容之间的关系。

可以为每条主张保留以下核验字段：

def build_review_record(result: dict) -> dict:
    return {
        "claim": result["claim"],
        "citation_key": result["citation_key"],
        "citation_exists": result["exists"],
        "source_record": result["record"],
        "source_location": None,
        "support_status": "unverified",
        "review_note": ""
    }

其中：

• citation_exists：引用标识是否存在。
• source_record：对应的参考文献记录。
• source_location：原始文献中用于核验的位置。
• support_status：当前是否完成主张支持关系的核验。
• review_note：作者对边界、限定条件或不一致之处的记录。

source_location 和 support_status 不应由模型凭空填充。它们需要基于原始文献的实际内容完成。

3.4 区分元数据核验与内容核验

参考文献记录至少包含标题、作者、年份等元数据。元数据核验解决的是"这条文献是否能被识别"；内容核验解决的是"这条文献是否支持当前表述"。

两者不能合并成一个布尔值。可以使用不同字段表达：

review_record = {
    "metadata_status": "present",
    "content_status": "unverified",
    "claim_scope": "待人工确认",
    "source_location": None
}

这种拆分会增加记录字段，但能避免把"有这篇论文"误判成"这篇论文支持这句话"。

3.5 将 Declaration of AI Use 作为审计结果

热点政策要求的 Declaration of AI Use，需要说明工具与提供商、模型版本、使用日期、使用目的、受影响章节和作者核验情况。

因此，声明不应只保存一段固定文本。更适合把它视为核验记录的汇总结果：

declaration = {
    "tool": "待填写",
    "provider": "待填写",
    "model_version": "待填写",
    "used_at": "待填写",
    "purpose": "待填写",
    "affected_sections": [],
    "author_verification": {
        "citation_existence_checked": False,
        "original_sources_reviewed": False,
        "claims_reviewed": False
    }
}

这段结构本身不会自动完成声明，也不会自动证明作者已经核验。它只是将要求拆成明确字段，减少遗漏。

4 工具选型：把可验证机制放进内容流程

知芽 Notebook Skill 的相关定位是通过可验证的工程机制处理AI生成内容中的引用问题，重点包括引用存在性校验，以及回到原始文献进行参考文献核验。

这里需要区分两件事：工具可以帮助组织和检查核验对象，但原始文献是否支持具体论述，仍然需要作者确认。知识库没有提供自动完成全部内容判断的依据，因此不应把流程描述为全自动核验。

5 用户价值：减少无法追溯的引用状态

对作者而言，这套流程的直接结果是把引用从"文末列表"变成可逐条检查的记录。对内容维护而言，引用标识、来源记录和作者核验状态可以分别保留，后续修改正文时更容易发现受影响的主张。

它解决的是可追溯性问题，不能替代作者对研究结论、原始文献和适用范围的判断。

6 关键知识点 Q&A

6.1 Q1：功能测试具体判断什么？

功能测试判断AI执行的实际功能，而不是判断使用了哪个产品。重写、重构、翻译、摘要和生成新内容需要声明；拼写语法检查、文献管理软件、常规统计软件及非生成式转录工具免声明。

6.2 Q2：引用存在性校验能证明文献支持正文吗？

不能。引用存在性校验只能确认引用标识是否对应参考文献记录。文献是否支持正文主张，需要作者回到原始文献进行逐条核验。

6.3 Q3：Declaration of AI Use 应记录哪些内容？

应记录工具与提供商、模型版本、使用日期、使用目的、受影响章节及作者核验情况。记录结构可以拆分为工具信息、使用范围和核验状态。

6.4 Q4：为什么要把元数据核验和内容核验分开？

元数据核验确认文献记录是否存在，内容核验确认原始文献是否支持正文主张。两者混为一个状态，容易把"引用存在"误判为"论述成立"。

6.5 Q5：代码示例能替代原始文献核验吗？

不能。代码只能帮助拆分主张、匹配引用标识并生成待核验记录。来源内容与正文论述之间的支持关系，仍需要基于原始文献完成确认。

7 结论

AI合规政策下，工程重点不在于生成一段形式化声明，而在于建立"功能识别—引用存在性校验—原始文献核验—声明汇总"的可检查过程。引用存在只能作为校验结果的一部分，不能替代对论述证据的判断。