React AI 引用界面设计：把答案标记连接到可核验原文

引用界面的目标不是证明“模型搜过资料”，而是让用户能回答三个问题：这句话依据哪段证据，证据是否真的支持结论，来源是否适用于当前时间和场景。若系统只在答案末尾放三个裸链接，用户无法知道每个链接支持哪句话，也很难发现来源冲突、过期或只支持部分结论。

可靠体验从后端数据契约开始。前端不应从模型生成的 Markdown 中用正则猜链接关系，而应接收结构化的答案片段和引用对象。每条引用至少包含稳定 citationId、证据 ID、文档标题、来源类型、规范 URL、更新时间、定位信息以及允许展示的短摘录。答案片段只引用 citationId，由服务端确认该证据确实来自本次检索快照。

引用必须绑定具体主张

一段包含三个事实的文字，只在段尾放 [1] 会产生歧义。更好的粒度是把可核验主张表示为文本区间或结构化 segment，每个 segment 关联一个或多个引用。不要用生成结束后的字符偏移盲目定位：Markdown 渲染、Unicode 和后续编辑都会改变索引。可在生成协议里传输稳定片段 ID，渲染后让标记与片段一起组成 React 节点。

同一主张有多个证据时，标记显示合并数量，展开后分别列出；证据相互冲突时，不要把它们当成“更多来源”合并，而应呈现冲突状态、各自日期和适用范围。后端如何维持这种血缘，可参考 RAG 引用溯源设计 与 RAG 证据冲突处理。

引用编号应按首次出现顺序稳定分配。流式生成时先发送片段，再到达引用元数据是常见情况；界面可显示中性的加载占位，但不能暂时把未核验 URL 当正式引用。生成完成后若某个要求引用的主张仍没有证据，应显示“未找到可核验来源”，而不是悄悄移除标记，让无证据文字看起来同样可信。

让核验动作留在阅读上下文中

桌面端可用侧栏展示来源详情，移动端使用底部面板或导航到独立证据页。点击引用标记后，焦点进入对应来源标题，关闭面板则回到原标记；用户继续点击另一个标记时只替换详情，不重置正文滚动。来源详情先展示支持该主张的摘录与位置，再展示文档元数据和打开原文操作，避免用户被送到几十页文档首页自行搜索。

标记不能只有颜色区别，也不能只写“点击这里”。屏幕阅读器需要能听到“引用 2，某文档，第 4 页”等可理解名称。多个标记的 DOM ID 可通过 React useId 与业务引用 ID 组合，确保 aria-controls 唯一且服务端、客户端一致。交互若采用 disclosure，应遵循按钮展开状态、键盘操作与焦点规则；不要把不可聚焦的上标 span 绑定点击事件。

来源在新窗口打开时，应在可访问名称或邻近文本中说明；外链使用正确的安全属性。内部知识库链接不能因为出现在答案里就绕过权限检查，点击时仍由当前会话鉴权。更多组件基础可结合 React 组件可访问性 检查。

把来源内容继续当作不可信输入

标题、摘录和 URL 都可能来自用户上传文档或外部网页。React 默认文本转义应保留，不要为了高亮而直接插入来源 HTML。若必须渲染富文本，先在服务端使用严格白名单清洗，并禁止脚本、事件属性、危险协议和任意 iframe。外部 URL 经解析后仅允许 https 和批准的内部协议；展示域名从规范化 URL 计算，不接受模型单独提供的“可信域名”字符串。

摘录要有长度上限并避免泄露邻近敏感文本。检索层已经判定用户可以看到某个 chunk，也不代表可以返回整份文档或长期公开签名地址。引用接口只返回最小证据片段，下载原文时再次授权。流式引用的整体呈现还可参考 RAG 流式 UI，但引用状态应独立于答案文字状态，失败时不能拖垮整个回答。

测量用户能否完成核验

测试数据需要覆盖单一来源、多来源、同段多个主张、来源冲突、无来源、失效链接、超长标题、中文与英文混排、重复引用和权限撤销。视觉测试检查窄屏中上标不遮挡文字、侧栏不改变正文宽度到无法阅读；键盘测试检查按顺序打开、关闭及返回焦点；流式测试检查引用晚到和事件重放不会产生重复编号。

生产观测可以记录引用渲染完整率、无证据主张率、来源打开率、链接失败率、权限拒绝和用户从摘录跳到原文的比例。不要把“引用点击低”直接解释为质量差，因为清晰摘录可能已满足核验；更重要的是抽样检查主张与证据是否相符，并把用户报告的错引回流到评估集。

最终，引用标记、来源面板和后端证据必须共享同一稳定身份。只要其中一层靠文本猜测关联，界面再精致也可能指向错误证据。可信引用体验来自可追溯的数据链，而不是答案末尾的一排蓝色链接。