
别让引用只挂在段尾:先做一张「主张—来源账本」再写成稿
用主张—来源账本把每句事实绑定到可读原文,先核对再成稿,减少引用找不到依据和表达越界。
很多 AI 生成的文章,段尾挂着一个链接,看起来像有依据,打开链接却找不到这句话从哪里来的。问题通常出在引用粒度太大:一整篇文档被当成一句话的依据,读者只能自己翻。
写需要核验的通知、产品更新、研究摘要或帮助文档时,可以先让 AI 做一张主张—来源账本,再让 AI 写正文。账本把每个准备写出的事实拆成一行,记录它对应的来源区块、原文依据和允许表达;成稿后,每句事实都要回到账本检查。找不到依据的句子直接撤回,保留为“待确认”或删掉。
先把引用对象缩小到一条主张
引用有三个常见粒度:
- 文档级:只能说明“答案来自这份文档”,适合读者只关心出处的场景。
- 区块级:指向文档中的一段、一个条款或一个检索片段,既方便模型处理,也能让读者看到足够上下文。
- 行级:指向精确的行号范围,核验最细,整理成本也更高。
对大多数写作任务,区块级是实用的起点。每个区块先有一个稳定 ID,例如
S1、S2;同一来源的 ID 在同一份材料里保持不变。区块还要带上可读原文,标题、链接和更新时间可以作为辅助信息。| 来源区块 | 放什么 | 作用 |
|---|---|---|
S1 | 一段已经确认的产品公告原文 | 支持发布日期、功能范围等主张 |
S2 | 帮助文档中的一个操作段落 | 支持入口、步骤和权限主张 |
S3 | 会议记录中的一个决定段落 | 支持决定、负责人和后续动作 |
主张账本则把“准备写什么”单独列出来。最低字段可以这样设置:
| 字段 | 填写规则 |
|---|---|
| 主张 ID | 每条可核验事实一个编号,例如 C1 |
| 准备写出的主张 | 用一句完整的话写清事实,不写“相关内容” |
| 支持区块 | 填 S1、S2 等来源 ID,可填多个 |
| 原文依据 | 摘出能直接支撑主张的短句,保留限定词 |
| 允许表达 | 说明成稿能说到什么程度 |
| 状态 | 已支持、部分支持、缺少依据、存在冲突 |
“允许表达”这一列很重要。原文写着“计划在下季度开放”,成稿就只能写“计划在下季度开放”;它不能被改成“下季度一定开放”。账本把事实和表达强度放在同一行,改写时更容易守住边界。
可直接复制的两轮 Prompt
把下面的 Prompt 整段复制。第一轮只做账本,第二轮在你确认账本后才写正文。
S1、S2 等 ID 由你在材料里预先填写,模型负责沿用。你是一名负责来源核验的中文写作编辑。你的任务分两轮完成:
第一轮建立“主张—来源账本”;第二轮只根据已确认的账本写正文。
<writing_task>
[写清任务,例如:把产品更新材料整理成一则面向普通成员的通知。]
</writing_task>
<audience_and_action>
目标读者:[谁会读]
读者读完要完成的动作或判断:[例如:知道何时生效,以及是否需要调整设置]
</audience_and_action>
<source_material>
[S1]
标题:[来源标题]
链接:[来源链接;没有链接就写“未提供”]
原文:
[粘贴一段完整、可读的来源原文]
[S2]
标题:[来源标题]
链接:[来源链接]
原文:
[粘贴下一段来源原文]
[继续添加 S3、S4……]
</source_material>
<ledger_rules>
1. 只使用 source_material 中的文字。材料没有写出的事实、数字、日期、因果关系和承诺都保持缺失。
2. 先把材料分成能独立阅读的来源区块。沿用我提供的来源 ID,不要自行改名或新增虚构来源。
3. 把准备写入正文的每一条可核验事实拆成一条主张。一个主张只表达一个主要事实。
4. 对每条主张填写:主张 ID、准备写出的主张、支持区块、原文依据、允许表达、状态。
5. 原文中的“计划、预计、可能、建议、截至某日”等限定词必须保留在原文依据和允许表达中。
6. 只有原文能直接支撑的内容才标为“已支持”。依据只支持部分内容时标为“部分支持”。找不到依据时标为“缺少依据”。来源说法互相矛盾时标为“存在冲突”。
7. “缺少依据”和“存在冲突”的主张不得进入第二轮正文,除非我补充材料并确认账本状态。
8. 第一轮只输出账本和待确认项,不写标题、正文或改写建议。
</ledger_rules>
<ledger_output>
## 来源区块 {#来源区块}
| 来源 ID | 标题 | 原文范围 | 链接 |
| --- | --- | --- | --- |
## 主张账本 {#主张账本}
| 主张 ID | 准备写出的主张 | 支持区块 | 原文依据 | 允许表达 | 状态 |
| --- | --- | --- | --- | --- | --- |
## 待确认项 {#待确认项}
- 只列出会改变事实、对象、时间、范围、权限或读者动作的缺口与冲突。
</ledger_output>
收到我对账本的确认后,执行第二轮:
1. 只使用状态为“已支持”的主张,以及我明确确认过的“部分支持”主张。
2. 每个事实句末尾标出对应的主张 ID,例如 `[C1]`;一句包含多个主张时,分别标出对应 ID。
3. 主张 ID 必须来自账本。禁止编造来源 ID、链接、行号或原文引述。
4. 把“允许表达”中的限定词保留在正文里。不要把“可能”改成“一定”,不要把“计划”改成“已经”。
5. 缺少依据或存在冲突的内容写入“待确认”,不要放进正文主张里。
6. 输出顺序为:标题、正文、待确认、发布前核对。
7. 发布前核对只输出四列:正文句子、对应主张 ID、支持区块、处理结果。处理结果只能是“保留”或“撤回”。
8. 完成核对后停止,不生成第二版正文。实际使用时,第一轮与第二轮最好是两次独立对话调用。你可以在第一轮把账本复制到团队文档里,补充“已确认”或改正来源区块,然后把确认后的账本和原任务一起交给第二轮。
用一份产品更新材料走一遍
下面的材料和输出都是虚构示例,只用来展示流程。材料包含三个来源区块:
[S1]
标题:团队知识库搜索更新公告
链接:https://example.com/release/search-filter
原文:9 月 15 日起,团队知识库搜索结果页新增“按来源筛选”。该功能对所有团队成员开放。
[S2]
标题:搜索筛选帮助文档
链接:https://example.com/help/search-filter
原文:成员打开搜索结果页后,可以在筛选栏选择来源。已保存的搜索条件保持不变。
[S3]
标题:访客权限讨论记录
链接:未提供
原文:产品团队正在讨论是否向外部访客开放来源筛选,当前方案尚未确认。第一轮账本可以这样写:
| 主张 ID | 准备写出的主张 | 支持区块 | 原文依据 | 允许表达 | 状态 |
|---|---|---|---|---|---|
C1 | 9 月 15 日起新增“按来源筛选” | S1 | “9 月 15 日起……新增” | 可以写“9 月 15 日起新增” | 已支持 |
C2 | 所有团队成员都可以使用 | S1 | “对所有团队成员开放” | 可以写“对所有团队成员开放” | 已支持 |
C3 | 筛选入口在搜索结果页的筛选栏 | S2 | “打开搜索结果页后,可以在筛选栏选择来源” | 可以写成操作提示 | 已支持 |
C4 | 已保存的搜索条件保持不变 | S2 | “已保存的搜索条件保持不变” | 可以原样表达 | 已支持 |
C5 | 外部访客可以使用该功能 | S3 | 原文只说“是否开放”且“尚未确认” | 只能写成待确认,不得写成开放事实 | 缺少依据 |
确认账本后,第二轮可以得到这样的正文:
搜索结果页新增按来源筛选9 月 15 日起,团队知识库搜索结果页新增“按来源筛选”,该功能对所有团队成员开放。[C1][C2]使用时打开搜索结果页,在筛选栏选择来源。已保存的搜索条件保持不变。[C3][C4]外部访客是否可以使用该功能仍待确认。[C5]
如果发布版本要求把来源 ID 换成真正的链接,系统或编辑可以根据来源区块表,把
[C1] 映射到 S1 的链接,把 [C3] 映射到 S2 的链接。模型负责输出稳定的主张和来源标记,展示层负责把标记解析成链接;两件事分开,改链接格式时也不会要求模型重新判断事实。成稿后怎么处理一条“看起来合理”的句子
假设模型在正文里多写了一句:“外部访客可以在访客设置中开启按来源筛选。”这句话听起来像完整的操作说明,账本里却没有对应主张。
发布前核对表应当把它记成:
| 正文句子 | 对应主张 ID | 支持区块 | 处理结果 |
|---|---|---|---|
| 外部访客可以在访客设置中开启按来源筛选。 | 无 | 无 | 撤回 |
模型可以把句子撤回,或者改写为“外部访客的开放范围仍待确认”,前提是
S3 的原文确实支持这句话。账本让“这句很像常识”失去发布资格,来源依据才有资格决定句子能否留下。什么时候值得用这套方法
这套账本适合下面几类文字:
- 产品更新、服务通知和帮助文档:日期、权限、入口和影响范围需要逐句核对。
- 研究摘要和调研报告:每个数字、结论和限定条件都需要回到原文。
- 对外邮件和项目汇报:一句过强的承诺可能改变读者对范围和责任的理解。
- 多份材料合并后的说明:每个主张可以保留自己的来源,后续修改更容易追踪。
普通的语句润色可以直接从“锁定不可改字段”开始。已经知道问题是空话或重复时,可以直接做定点改写。主张—来源账本处理的是依据是否足够、表达是否越界,它不会替你判断原始来源本身是否真实,也不会解决两份来源之间的审批冲突。
为什么这条规则有用
OpenAI 的引用格式指南把引用系统拆成几个环节:先确定哪些材料可以被引用,再用清晰结构表示材料,规定引用格式,告诉模型何时引用,最后解析和校验模型输出。指南把区块级引用列为多数系统的实用默认值,并建议来源 ID 保持稳定、原文保持可读。1
同一份指南还区分了来源 ID 与精确定位符:模型先输出稳定的来源 ID,系统再解析成行号或界面高亮。把两者过早混在一起,会增加格式错误。这个区分正好对应 Prompt 里的
S1、S2 和主张 ID:模型处理关系,展示层处理链接与定位。1Anthropic 的减少幻觉指南建议,处理长文档时先抽取逐字引文,再完成后续任务;它还建议让每个主张带上引文和来源,并在生成后逐条寻找支持引文,找不到时撤回主张。主张账本把这条建议变成了一个可见的中间结果。2
Google 的提示设计指南建议用一致的结构分隔任务、上下文和输出要求,并把生成后的检查列入流程。指南给出的顺序是计划、执行、验证、格式化;本期 Prompt 采用了更适合写作的对应顺序:登记主张、生成正文、核对支持、整理引用。3
发布前检查
把下面四项交给人或另一个独立的检查步骤:
- 每个外部事实是否都有主张 ID?没有主张 ID 的事实句撤回。
- 每个主张是否至少对应一个来源区块?来源区块里的原文是否真的支撑完整句意?
- 成稿是否保留了“可能、计划、截至某日”等限定词?表达强度是否超过原文?
- 缺少依据或存在冲突的内容是否单独列为待确认?链接、来源 ID 和定位信息是否能由区块表解析出来?
主张—来源账本的最小动作只有两步:先登记每句准备说出的事实,再逐句核对它能否回到原文。 当一条句子找不到对应区块时,删掉它通常比给它补一个看似相关的链接更可靠。
Fuentes de referencia
- 1Citation Formatting \| OpenAI API
developers.openai.com
- 2Reduce hallucinations - Claude Platform Docs
docs.anthropic.com
- 3
Este contenido lo produjo un canal automáticamente. Con una sola frase, Neodrop puede seguir produciendo para ti.
