AI知识问答要让人敢用，前提是每个结论都能回到具体来源。引用规范就是把这件要求写成团队可执行的规则：哪些回答必须带引用、引用精确到什么位置、由谁登记来源、由谁复核、失效后怎么处理。本文按“规则要素—操作步骤—角色分工—场景示例—验收检查”的顺序展开，帮助团队起草第一版规范并跑通闭环。知识来源登记与审核流转部分，会说明如何借助ONES的文档与工作项管理承载。
要点总览（TL;DR）
- 引用规范先定四件事：哪些问答必须带引用、引用到文档/章节/条目哪一级、来源名称与版本怎么标注、找不到可靠来源时怎么写。
- 执行链路拆成来源登记与版本标记、生成时挂接引用、发布前完整性检查、失效引用回收四步，每步留下可检查的完成标志。
- 知识维护者管来源与版本，问答运营者管引用挂接与格式，审核者管抽样复核与争议裁定，三者用统一状态标记交接。
- 验收按月或按季度抽样，看引用覆盖率、引用准确率、失效引用处理时效和无来源回答的说明质量，并给规范本身定复审周期。
- 高风险场景先跑通闭环再扩范围，阈值先测基线再逐步收紧，避免规则过严导致执行流于形式。
引用规范先定哪几件事：范围、颗粒度与标注格式
第一版规范不需要写得很厚，但必须把四件事定清楚，否则执行时每个人理解不同，复核也无从判断。建议用一张要素表把规则固化下来，作为后续步骤和角色分工的依据。
| 要素 | 需要回答的问题 | 建议写法 |
|---|---|---|
| 适用范围 | 哪些问答必须带引用？ | 按风险分级：涉及对外承诺、技术决策、合规与安全、需求与验收结论的问答强制引用；一般性背景介绍可只给来源提示。范围写成清单，避免“重要问题”这类模糊表述。 |
| 引用颗粒度 | 引用到文档、章节还是段落？ | 决策类回答引用到章节或条目，并注明版本；事实性数据引用到段落或表格行；概述类回答可到文档级。颗粒度与风险等级挂钩，高风险场景要求更细。 |
| 标注格式 | 来源信息怎么呈现？ | 统一字段：来源名称、位置（章节/段落/条目）、更新时间或版本号。格式固定后，人工复核和抽样统计才能对齐口径。 |
| 无可靠来源时 | 找不到依据怎么办？ | 明确写出“依据不足”，说明已检索的范围和缺失的信息，并给出下一步建议（如联系某文档负责人确认）。禁止用推测补全结论。 |
颗粒度的选择要结合知识形态。制度、规范类文档结构清晰，引用到章节即可定位；会议纪要和需求记录往往以条目为单位，引用到具体条目更可靠。标注格式中的更新时间尤其重要，同一份文档存在多个版本时，读者需要知道答案依据的是哪一版。
无来源处理规则是规范里最容易被忽略、却最影响可信度的部分。规则应要求回答者区分“没有检索到”和“检索到了但内容不支撑结论”两种情况，前者提示补充知识入库，后者提示修订文档。两种情况都应在回答中显式说明，而不是给出一个看似完整却无出处的答案。
从提问到复核：引用规范的操作步骤
规则定好后，要拆成一条可重复执行的链路。下面四步覆盖知识进入问答系统到引用失效处理的全过程，每步都明确输入、动作、输出和完成标志，便于交接和检查。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 来源登记与版本标记 | 待入库的文档、纪要、需求记录 | 登记来源名称、负责人、适用范围、版本号与更新时间；标注文档状态（草稿/生效/废止） | 带来源信息的知识条目 | 每条知识都能查到负责人和当前版本 |
| 2. 问答生成时挂接引用 | 用户提问、检索到的知识条目 | 按颗粒度规则把结论与来源位置对应；一条回答涉及多个来源时逐条标注 | 带引用的回答草稿 | 每个关键结论后都有对应来源，无孤立结论 |
| 3. 发布前完整性检查 | 回答草稿 | 核对引用字段是否齐全、位置是否可定位、版本是否为当前生效版本；检查无来源结论是否已说明依据不足 | 通过检查的回答 | 检查项全部通过，或例外项已记录原因 |
| 4. 失效引用回收与更新 | 来源变更通知、定期巡检结果 | 标记失效引用，通知知识维护者更新来源；无法更新的，在回答中标注“来源已废止”并给出替代来源 | 更新后的知识条目与回答 | 失效引用在约定时限内完成处理并留痕 |
第2步是日常执行中最容易走形的环节。建议把“结论—来源”对应关系作为回答的固定结构，而不是事后补注。当一条回答包含多个判断时，逐个判断挂来源，比在文末列一串参考文档更能支撑复核。
第4步需要触发机制。来源文档的修订、废止、负责人变更都应产生通知，巡检则作为兜底。处理时限按知识更新频率设定：高频变动的需求与接口文档可以按周巡检，制度类文档可按季度。时限写进规范，验收时才有依据。
在ONES中，知识来源可以登记在Wiki页面并保留版本与负责人信息，引用检查、失效处理和复核意见可以通过工作项流转并留下状态记录。ONES Assistant支持基于指定的Wiki页面组回答问题并附上引用来源，问答范围与团队知识边界一致，输出过程可追踪，便于把上述步骤落到同一套协作环境中。
角色与交付物：谁维护来源、谁审核引用
规范无人执行，通常是因为职责没有落到具体交付物上。建议至少区分三类角色，并用状态标记衔接，避免“大家都负责、结果没人管”。
| 角色 | 核心职责 | 交付物 | 交接状态标记 |
|---|---|---|---|
| 知识维护者 | 来源登记、版本更新、废止处理 | 来源登记表、版本变更记录、失效来源处理说明 | “来源已登记”“版本已更新”“来源已废止” |
| 问答运营者 | 引用挂接、格式检查、无来源说明撰写 | 带引用的回答、引用检查记录 | “待复核”“格式已校验” |
| 审核者 | 抽样复核、争议裁定、规则解释 | 复核记录、争议处理结论、规范修订建议 | “复核通过”“退回修改”“规则待修订” |
职责边界要写清两处容易冲突的地方。其一，知识维护者对来源内容的准确性负责，问答运营者对引用是否对应结论负责，两者不能互相替代。其二，审核者遇到来源本身有误的情况，应退回知识维护者修订，而不是在回答层面绕过问题。
交接物尽量用统一的状态字段承载，而不是散落在聊天记录里。状态变化本身就是审计线索：一条回答从“待复核”到“复核通过”，中间经过了谁、改了什么，都能回溯。ONES基于自身权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，适合把来源登记、引用检查和复核状态放在同一套权限与记录体系内管理。
一个示例：需求评审问答的引用落地
以下为演示情景，用于说明规范如何运行，不涉及真实团队数据。
提问：“支付模块的退款接口在需求评审中确定了哪些异常处理要求？”
检索与引用标注：问答运营者从需求文档和评审纪要中检索到两处依据，按规范标注为：
- 来源一：《支付模块需求说明书》第4.2节“退款异常处理”，版本V2.3，更新于评审后一周；
- 来源二：《支付模块需求评审纪要》条目“退款超时与重复提交”，版本V1.0。
回答草稿写明：退款接口需处理超时重试与重复提交两类异常，超时后进入人工复核队列，重复提交按幂等处理。两个结论分别挂到上述来源的对应位置。
审核发现的问题与修正：审核者复核时发现，需求说明书V2.3已修订了超时处理时限，而回答引用的是修订前表述；同时评审纪要中的幂等要求后来在技术方案中补充了实现约束，纪要本身未更新。处理方式：问答运营者按V2.3更新超时结论的引用位置；知识维护者在纪要中补充指向技术方案的说明，并标记该条目“部分内容已被后续文档覆盖”。
最终引用呈现：回答中每条结论后标注来源名称、章节或条目、版本与更新时间；对已被覆盖的内容注明“以技术方案为准”，并给出技术方案的来源位置。整条回答没有无出处的判断，复核状态记录为“复核通过”。
这个示例说明，引用规范真正起作用的地方往往在审核环节：它迫使团队发现来源版本不一致的问题，并把修订责任交回知识维护者，而不是让错误结论随回答扩散。
完成检查：规范是否真正生效
规范发布不等于生效。建议按月或按季度抽样，用下列检查表判断执行质量，并把结果反馈到规则修订中。
| 检查项 | 检查方法 | 判断标准 |
|---|---|---|
| 引用覆盖率 | 从强制引用范围内的问答中随机抽取样本，统计带完整引用的比例 | 覆盖率达到团队设定目标；未覆盖项均有依据不足说明 |
| 引用准确率 | 逐条核对引用位置是否真正支撑结论，版本是否为当前生效版本 | 错误引用可定位到具体环节（挂接错误或来源过期）并有整改记录 |
| 失效引用处理 | 统计巡检与变更通知发现的失效引用数量及处理时长 | 在约定时限内完成处理，超时项有原因说明 |
| 无来源回答质量 | 抽查无来源回答，检查是否说明检索范围、缺失信息与下一步建议 | 说明具体可操作，未出现推测性结论 |
| 规范复审 | 核对复审周期是否执行、责任人是否明确 | 按周期完成复审并留下修订记录 |
抽样时按风险分层：对外与决策类问答全量或高比例抽查，一般性问答低比例抽查。指标阈值结合团队问答量、知识更新频率和风险等级确定，先跑一个周期看基线，再逐步收紧，避免一开始设定过严导致执行流于形式。
规范本身也要有复审机制。当出现新的问答场景、来源类型变化或复核争议增多时，应触发规则修订。复审记录与修订说明同样是验收的一部分，它证明规范在被使用，而不是停留在文档里。
常见问题
哪些问答必须带引用，哪些可以只给来源提示？
建议按风险分级确定强制引用范围，而不是按问答类型一刀切。涉及对外承诺、技术决策、合规与安全、需求与验收结论的问答，应强制引用到章节或条目级别；一般性背景介绍、概念解释可以只给来源提示，甚至不挂具体位置。
范围要写成清单并定期更新。当出现新的高风险场景，比如新增对外接口说明或合规审查问答，应及时补进清单。清单之外的低风险问答仍建议保留来源提示，方便后续追溯。
引用到文档级和引用到段落级，怎么选？
颗粒度与风险等级和知识形态同时相关。制度、规范类文档结构清晰，引用到章节通常就能定位；会议纪要和需求记录以条目为单位，引用到具体条目更可靠；事实性数据最好落到段落或表格行。
高风险回答要求更细的颗粒度，并注明版本号或更新时间。同一份文档存在多个版本时，读者需要知道答案依据的是哪一版，这也是审核时最容易发现问题的环节。
找不到可靠来源时，回答应该怎么处理？
规范应要求区分两种情况：没有检索到相关知识，以及检索到了但内容不支撑结论。前者提示补充知识入库，后者提示修订文档，两种情况都要在回答中显式说明，并写清已检索的范围和缺失的信息。
可以给出下一步建议，比如联系某份文档的负责人确认。回答中避免用推测补全结论，也不要把无出处的判断包装成完整答案，否则复核时无法区分错误来源和缺失来源。
引用失效后由谁处理，处理时限怎么定？
失效引用通常由知识维护者负责更新来源，问答运营者负责在回答中标注“来源已废止”并给出替代来源，审核者确认处理结果。触发机制包括来源文档修订、废止、负责人变更的通知，定期巡检作为兜底。
处理时限按知识更新频率设定：高频变动的需求与接口文档可以按周巡检，制度类文档可按季度。时限写进规范，验收时才有判断依据；超时项应记录原因，便于发现流程堵点。
引用覆盖率设多少合适，一开始就定高目标吗？
建议先跑一个周期测基线，再逐步收紧。覆盖率目标要结合团队问答量、知识更新频率和风险等级确定，强制引用范围内可以设较高目标，一般性问答低比例抽查即可。
指标过严容易导致执行流于形式，比如为了凑覆盖率补上无法定位的引用。抽样时按风险分层：对外与决策类问答全量或高比例抽查，一般性问答低比例抽查，同时核对引用位置是否真正支撑结论。
