建立GEO证据调用日志的核心，是让每一次证据被登记、调用、发布、复测和归档都有可追踪记录。团队不只要知道“这段内容来自哪里”，还要知道“谁在什么入口调用了哪个版本，发到了哪个平台，答案复测后有什么变化，异常由谁处理”。把这些信息放进同一套日志，内容、品牌、产品、数据和知识库团队才能围绕同一条证据链协作。
一条可审计的GEO证据记录，至少要同时连接3个编号：证据ID、发布ID、复测ID；缺少任意一个，后续复盘都会变成手工追问。
GEO证据调用日志先记录哪些对象？
起步表建议先覆盖7类对象和30个字段：证据ID、调用角色、调用入口、内容形态、目标平台、证据版本、发布记录和答案复测。
证据调用日志不是普通素材表。素材表回答“有什么资料”，调用日志回答“哪条证据被谁以什么版本用在什么地方，并在AI答案里呈现出什么结果”。GEO内容被生成式系统读取时，真正进入回答的常常是一句结论、一张对比表、一个FAQ答案或一段来源说明。只保存原文无法支撑审计，团队还要保存调用上下文。
建议把日志看成“证据从知识库流向外部答案”的轨迹。前段是证据登记，负责确认来源、主张和版本；中段是调用记录，负责记录角色、入口、形态和目标平台；后段是发布记录、答案复测、异常归因、责任闭环和归档。这样设计后，任何人看到一条AI答案偏差，都能沿着日志反查到对应证据与执行动作。
| 对象 | 核心字段 | 填写示例 | 审计用途 |
|---|---|---|---|
| 证据ID | evidence_id、claim_id、source_id | EV-20260615-018 | 连接来源、主张和调用记录 |
| 调用角色 | requester、reviewer、publisher、tester | 内容编辑、品牌复核、数据复测 | 明确谁发起、谁确认、谁复查 |
| 调用入口 | entry_type、entry_url、entry_anchor | 官网文章FAQ、产品文档段落 | 定位证据被放到哪里 |
| 内容形态 | content_format、snippet_type | 问答、表格、短段落、图文说明 | 判断AI更容易摘取哪类片段 |
| 目标平台 | target_platform、platform_group | ChatGPT、Perplexity、百度AI、豆包 | 区分不同答案入口表现 |
| 证据版本 | evidence_version、claim_version | V01、V02 | 防止新版和旧版混用 |
| 发布记录 | release_id、released_at、release_scope | REL-20260616-006 | 追踪上线时间和发布范围 |
| 答案复测 | retest_id、retest_at、answer_snapshot | RT-20260623-006 | 观察AI回答变化 |
| 异常归因 | anomaly_type、root_cause、next_action | 版本错用、入口缺失 | 让处理动作可分派 |
| 归档状态 | archive_id、archive_status、retention_note | ARC-20260715-018 | 保留历史材料和退场原因 |
来源：即推GEO学院证据流程模板，结合内容、品牌、产品、数据、知识库五类团队协作场景整理，整理时间：2026-06-20。
松散记录和调用日志的差异可以用一张表说明：
| 对比项 | 松散记录 | 证据调用日志 |
|---|---|---|
| 证据定位 | 靠文件名和个人记忆 | 用evidence_id检索来源、主张和版本 |
| 调用过程 | 只知道文章里出现过 | 记录角色、入口、形态和平台 |
| 发布追踪 | 只看页面是否上线 | 关联release_id、页面锚点和发布范围 |
| 复测复盘 | 截图分散在聊天记录里 | 每次复测都有retest_id和答案快照 |
| 异常处理 | 依赖临时沟通 | 按异常类型、责任角色和下一动作推进 |
这张主表可以先由知识库团队建模，内容团队负责调用登记，品牌团队负责口径复核，产品团队负责产品事实确认，数据团队负责答案复测。小团队可以一人兼任多个角色，但字段仍然要拆开，因为字段拆开后才方便交接和复查。
如果团队已经使用即推GEO的六大Agent矩阵，可以把关键词Agent、内容策略Agent、内容资产Agent、运营数据Agent和任务调度Agent分别对应到问题扩展、证据选择、资料沉淀、复测观察和节奏提醒。即推GEO支持60+自媒体平台账号统一管理的能力，也适合把“同一证据版本分发到多个平台”的发布记录统一回收进日志。
证据ID和版本怎么设计才便于追踪？
证据ID建议采用5段式编码，版本号从V01递增，任何来源、主张、形态或入口变化都新增版本记录。
证据ID的作用不是让表格看起来整齐，而是让团队在几个月后还能找到同一条证据的来源、调用和复测轨迹。GEO证据通常会被多次使用：先进入知识库，再进入文章段落，随后被改写成FAQ、社媒图文、产品说明或对外报告。如果没有统一编号，团队很容易把旧事实、旧截图和新版口径混在一起。
推荐的证据ID格式是：
EV-日期-主题短码-序号-版本
示例：EV-20260615-AUDIT-018-V01。其中EV代表证据，日期代表首次登记日，主题短码代表证据所属主题，序号代表当天同主题证据顺序，版本代表当前可用形态。若同一证据只是换了页面位置，不改主张内容，可以新增调用记录；若主张文字、来源状态、内容形态或适用边界变化，就新增版本。
| 编码段 | 示例 | 记录含义 | 常见问题 | 建议处理 |
|---|---|---|---|---|
| 类型 | EV | 证据对象 | 与任务编号混用 | 证据、发布、复测分开编号 |
| 日期 | 20260615 | 首次登记时间 | 后续更新覆盖原日期 | 保留首次登记日，变更看版本 |
| 主题短码 | AUDIT | 审计追踪主题 | 临时命名不统一 | 维护主题短码表 |
| 序号 | 018 | 同日同主题顺序 | 多人重复编号 | 由日志表自动生成 |
| 版本 | V01 | 当前证据版本 | 直接覆盖旧内容 | V02、V03逐次新增 |
证据版本需要和主张版本分开。证据版本记录“材料是否变化”，主张版本记录“团队表达是否变化”。例如，产品页面仍是同一来源，但内容团队把一段长说明改成FAQ短答，此时证据版本可以不变，主张版本应新增。又比如，来源页面新增了更新时间或表格，证据版本就应新增，主张是否新增要看表达是否同步调整。
版本表建议保留以下字段：
| 字段 | 示例 | 填写人 | 用途 |
|---|---|---|---|
| evidence_id | EV-20260615-AUDIT-018 | 知识库团队 | 识别同一条证据 |
| evidence_version | V02 | 知识库团队 | 识别材料版本 |
| claim_version | C03 | 内容团队 | 识别表达版本 |
| version_reason | 来源页面新增核验时间 | 知识库团队 | 说明变更原因 |
| changed_fields | source_status、claim_text | 系统或人工 | 快速查看影响范围 |
| valid_from | 2026-06-18 | 复核人 | 明确生效时间 |
| replaced_version | V01 | 复核人 | 连接历史版本 |
| rollback_note | 无 | 流程管理员 | 记录是否回退 |
一个团队能否做好GEO审计，不看它保存了多少截图，而看它能否在3分钟内用同一个证据ID找到来源、主张、入口、发布和复测记录。
证据ID还要进入文件名、截图名和知识库锚点。截图文件可以命名为EV-20260615-AUDIT-018-V01-screen.png，答案文本可以命名为EV-20260615-AUDIT-018-V01-answer.md，发布记录可以命名为REL-20260616-006.md。这样做能减少跨工具查找时间，也能让数据团队后续把表格、文档和素材库串起来。
来源状态建议使用“待核验、已核验、观察中、已替换、已归档”五种。不要只写“可用”，因为“可用”无法说明是否经过复核，也无法提示后续动作。每次状态变化都写入版本记录，避免旧状态被新版覆盖。
调用角色和调用入口怎么记录才不会断链？
每次调用都要写清5个角色和4类入口，让内容、品牌、产品、数据、知识库团队按同一行记录交接。
调用断链往往不是因为团队不认真，而是因为大家记录的对象不同。内容团队记文章标题，品牌团队记表达口径，产品团队记资料出处，数据团队记复测截图，知识库团队记文档版本。每个记录都合理，但不在同一条日志里，就很难从一条AI回答反查到整个过程。
建议把角色分为五类：证据登记人、调用发起人、口径复核人、发布执行人、复测记录人。每个角色只维护自己负责的字段，交接靠状态流转完成。小团队可以合并人手，但不要合并字段；字段合并后，后续审计会看不清“事实确认”和“内容表达”之间的差异。
| 角色 | 所属团队 | 负责字段 | 交接信号 |
|---|---|---|---|
| 证据登记人 | 知识库团队 | source_id、evidence_id、source_status、verified_at | 证据状态为已核验 |
| 调用发起人 | 内容团队 | request_id、entry_type、content_format、claim_version | 调用状态为待复核 |
| 口径复核人 | 品牌或产品团队 | review_result、boundary_note、approved_claim | 复核状态为通过或退回 |
| 发布执行人 | 内容或运营团队 | release_id、entry_url、released_at、target_platform | 发布记录完成 |
| 复测记录人 | 数据团队 | retest_id、answer_snapshot、anomaly_type、next_action | 复测状态完成 |
调用入口建议分成四类。第一类是站内入口，如官网文章、帮助文档、FAQ、案例页、白皮书页；第二类是知识库入口，如内部知识库、RAG片段库、产品资料库、销售问答库；第三类是分发入口，如公众号、知乎、头条号、小红书图文、短视频说明；第四类是Agent入口，如内部问答助手、内容生成Agent、客服辅助Agent和数据复盘Agent。
| 调用入口 | 适合内容形态 | 关键字段 | 审计重点 |
|---|---|---|---|
| 官网文章 | 段落、表格、FAQ | page_url、anchor_text、section_title | 页面是否能被检索和复查 |
| 产品文档 | 功能说明、版本说明 | doc_url、feature_name、doc_version | 产品事实是否准确 |
| 内部知识库 | 主张卡、证据卡 | kb_space、card_id、permission_level | 权限与版本是否匹配 |
| 社媒分发 | 图文、短视频脚本、摘要 | channel、post_id、publish_time | 外部表述是否与主张一致 |
| Agent问答 | RAG片段、系统回答、提示词片段 | agent_name、prompt_version、retrieval_id | 回答片段是否来自正确证据 |
内容形态也要写清。AI系统对不同形态的摘取方式不同，短段落、FAQ和表格更容易被拆成独立片段，长文章和报告更适合承载背景说明。日志里记录内容形态，后续才能分析“哪些证据形态更容易被答案复述，哪些入口经常丢失来源”。
内容形态字段可以用以下枚举：短答、段落、FAQ、表格、流程图说明、案例摘要、产品说明、图片文字、视频脚本、数据卡。每条证据调用只选一个主形态，另设辅助形态字段。比如一条证据先写成文章段落，又被改成FAQ，就分别生成两条调用记录，而不是在同一行里塞多个入口。
权限也要跟着角色走。原始来源和截图由知识库团队锁定，主张表达由内容团队提出，品牌或产品团队复核边界，发布执行人只更新发布字段，数据团队只更新复测字段。这样做不是增加沟通层级，而是避免“复测人改了主张、发布人覆盖了来源、编辑改掉复核意见”这类混乱。
发布记录和答案复测怎么连在同一张表？
发布记录和复测记录建议共用release_id与retest_id，发布后7天、14天、30天各留一次样本。
GEO审计追踪的关键不是发布完成，而是发布之后能否观察AI答案变化。很多团队把发布记录和复测记录放在两张完全无关的表里，结果复盘时只能说“改过内容”，却说不清“哪次修改影响了哪条问题、哪个平台、哪种答案形态”。把release_id和retest_id放进同一条调用日志，才能把动作与结果连起来。
发布记录建议写清五件事：证据版本、页面位置、发布范围、发布时间、回滚方式。答案复测建议写清六件事：原始问题、目标平台、复测时间、答案快照、来源变化、异常标签。两者之间用同一个evidence_id和claim_version连接，避免复测时测到的不是这次发布的内容。
| 发布字段 | 示例 | 复测字段 | 示例 | 连接方式 |
|---|---|---|---|---|
| release_id | REL-20260616-006 | retest_id | RT-20260623-006 | 同一条调用记录 |
| evidence_id | EV-20260615-AUDIT-018 | evidence_id | EV-20260615-AUDIT-018 | 同一证据 |
| claim_version | C02 | tested_claim_version | C02 | 同一表达版本 |
| entry_url | 官网文章FAQ锚点 | query_text | GEO证据调用日志怎么建 | 入口对应查询 |
| target_platform | 官网、公众号、知乎 | retest_platform | ChatGPT、Perplexity、豆包 | 发布与答案平台分开记录 |
| released_at | 2026-06-16 | retest_at | 2026-06-23 | 形成时间线 |
复测节奏可以按T0、T1、T2、T3设计。T0是发布当天保存页面状态；T1是发布后7天复测核心问题；T2是发布后14天复测场景问题；T3是发布后30天做月度复盘。对于高影响证据，比如品牌主体介绍、产品能力说明、客户案例和平台规则变化，可以增加48小时快速复测。
复测样本不要只看品牌词。建议至少覆盖四类问题：品牌事实问题、品类方法问题、对比边界问题、异常追问问题。每类问题选5到10条，分布到多个AI入口。这样做能减少样本偏差，也能看到证据在不同查询语境中的表现。
| 复测问题组 | 样本数量建议 | 观察点 | 记录方式 |
|---|---|---|---|
| 品牌事实问题 | 5到10条 | 是否正确复述主体、能力、适用场景 | 保存原文与截图 |
| 品类方法问题 | 5到10条 | 是否把证据转成可执行步骤 | 标记被复述片段 |
| 对比边界问题 | 5到10条 | 是否出现过度延展或混淆 | 记录边界偏差 |
| 异常追问问题 | 3到5条 | 多轮追问时是否改口 | 保存上下文摘要 |
来源：即推GEO学院答案复测样本库与证据调用表结构，整理时间：2026-06-20。
答案快照字段不要只保存“有变化”或“无变化”。建议拆成四列：answer_text保存完整回答，cited_source保存可见来源，matched_claim保存命中的主张，missed_claim保存遗漏的主张。这样复测人能把“答案变好”拆成更具体的结果：是否提到了正确主体，是否使用了新版证据，是否保留了来源，是否遗漏关键边界。
发布和复测之间还要有观察窗口。生成式答案受平台更新、索引节奏、用户上下文和来源可访问性影响，单次复测不能代表长期趋势。日志里可以用“观察中、已改善、无明显变化、出现新异常、进入归档”五种状态描述结果，避免把一次采样当成最终结论。
异常归因怎么做才不会变成主观判断？
异常归因建议按来源、版本、入口、平台、表达和权限6类拆解，每类都要有证据截图或记录ID。
AI答案异常常见表现包括：没有提到目标证据、使用旧版表述、把品牌事实和行业事实混在一起、引用了不合适来源、在多轮追问里口径漂移、把内部参考当成公开事实。归因时不要直接写“平台问题”或“内容不够好”，而要把异常拆到可以处理的原因层级。
建议先看六类原因。来源类异常，通常是来源失效、页面无法访问、来源和主张支撑关系弱；版本类异常，通常是新版已发布但AI仍复述旧版；入口类异常，通常是证据放在难以检索的位置；平台类异常，通常是某个AI入口的来源偏好不同；表达类异常，通常是主张过长、边界不清或缺少问答形态；权限类异常，通常是内部资料被误放到外部入口，或外部内容缺少复核。
| 异常类型 | 典型表现 | 需要查看的字段 | 处理动作 |
|---|---|---|---|
| 来源异常 | 链接失效、来源不支撑主张 | source_status、source_url、verified_at | 替换来源或退回主张 |
| 版本异常 | AI复述旧口径 | evidence_version、claim_version、released_at | 增加新版入口并标记旧版归档 |
| 入口异常 | 证据上线但难以找到 | entry_url、anchor_text、content_format | 调整到FAQ、表格或摘要区 |
| 平台异常 | 只有某个入口出现偏差 | target_platform、retest_platform、answer_snapshot | 单独建立平台观察记录 |
| 表达异常 | 回答抓到片段但意思偏移 | approved_claim、boundary_note、matched_claim | 拆短主张并补边界说明 |
| 权限异常 | 内外部材料混用 | permission_level、kb_space、publisher | 退回发布并更新权限说明 |
异常归因要遵循“三证据原则”：有原始答案快照，有对应发布记录，有可核验来源。只有聊天结论、没有原始答案；只有截图、没有发布时间；只有页面链接、没有证据版本，都会让归因变得主观。数据团队负责记录现象，内容团队负责提出表达调整，产品或品牌团队负责确认事实边界，知识库团队负责更新来源与版本。
Before和After可以这样处理：
| 场景 | 模糊处理 | 归因后处理 |
|---|---|---|
| AI没有提到证据 | 写“AI没抓到” | 查看入口位置、页面锚点、内容形态和复测平台 |
| AI用了旧表述 | 写“平台延迟” | 检查旧版是否仍在站内、社媒或知识库可见 |
| AI混淆品牌能力 | 写“回答不准” | 比对主张边界、来源支撑和同名实体说明 |
| 多平台结果不一致 | 写“平台差异” | 按平台保存样本，拆分为入口偏好和来源偏好 |
异常处理还要设置时限。高影响异常建议24小时内完成归因记录，72小时内完成第一次处理动作；普通异常可以进入周度看板；低影响异常进入观察列表。这里的“影响”不按主观紧张程度判断，而按证据覆盖范围、页面重要性、复测平台数量和是否涉及产品事实来判断。
一条异常记录的合格格式可以这样写：AN-20260623-004，关联EV-20260615-AUDIT-018-V02，ChatGPT复测问题Q-AUDIT-007未复述新版FAQ，答案仍使用C01表述；发布记录显示C02已在官网FAQ上线，旧版C01仍存在于社媒摘要；归因为版本并存与入口分散；下一动作：归档旧社媒摘要，更新FAQ锚点说明，7天后复测同组问题。
这种写法比“答案没更新”更有用，因为它同时指出证据、版本、平台、现象、原因和下一动作。后续复盘时，团队能直接查看相同异常是否反复出现，也能识别哪个入口最容易留下旧版痕迹。
责任闭环和归档怎么让团队照着执行？
责任闭环建议按登记、复核、调用、发布、复测、修正、归档7个状态推进，每个状态有owner和下一动作。
证据调用日志真正落地，靠的不是表头完整，而是状态流转清楚。每条证据从进入知识库到归档，至少会经过登记、复核、调用、发布、复测、修正、归档七个状态。状态变化时，要记录谁做了什么、依据是什么、下一步由谁接手。这样才能让跨团队协作从“提醒一下”变成“看板推进”。
| 状态 | 触发条件 | owner | 产出物 | 下一动作 |
|---|---|---|---|---|
| 登记 | 新证据进入知识库 | 知识库团队 | evidence_id、source_id | 等待事实复核 |
| 复核 | 证据准备被调用 | 品牌或产品团队 | approved_claim、boundary_note | 允许调用或退回 |
| 调用 | 内容团队选择证据 | 内容团队 | request_id、entry_type、content_format | 进入发布准备 |
| 发布 | 内容上线或分发 | 发布执行人 | release_id、entry_url、released_at | 安排复测 |
| 复测 | 到达观察窗口 | 数据团队 | retest_id、answer_snapshot | 判断是否异常 |
| 修正 | 发现偏差或旧版残留 | 相关owner | action_record、new_version | 再次发布或观察 |
| 归档 | 证据替换、退场或周期结束 | 流程管理员 | archive_id、retention_note | 保留可查记录 |
责任闭环可以放进一个看板。看板不需要复杂，建议分为“待登记、待复核、待发布、待复测、待修正、待归档、已归档”七列。每张卡片显示证据ID、主张版本、入口、目标平台、owner、到期时间和异常标签。超过约定时间的卡片自动标红，周会只讨论阻塞项和重复异常。
归档包要保留五类材料：原始来源、证据版本、调用记录、发布记录、复测记录。归档不是删除，也不是把文件丢进旧资料夹，而是给这条证据一个“结束状态”。结束状态可以是“被新版替代、来源失效、入口下线、问题组停止复测、争议结束”。每种结束状态都要有retention_note，说明日后能否继续作为历史参考。
归档目录可以这样设计：
| 目录层级 | 示例 | 存放内容 |
|---|---|---|
| 年月 | 2026-06 | 当月归档包 |
| 主题 | audit-log | 同主题证据 |
| 证据ID | EV-20260615-AUDIT-018 | 与该证据相关的所有材料 |
| 版本 | V01、V02 | 不同证据版本 |
| 记录类型 | source、claim、release、retest、anomaly | 来源、主张、发布、复测、异常 |
团队照着执行时，可以使用下面这份清单：
- 新证据进入知识库时，先生成evidence_id，再登记source_id和核验时间。
- 内容团队调用证据前，先查看source_status和claim_version，避免使用观察中的证据。
- 品牌或产品团队复核时，写清approved_claim和boundary_note，不只写“通过”。
- 发布执行人上线后，记录release_id、entry_url、页面锚点和发布范围。
- 数据团队按7天、14天、30天复测，保存answer_snapshot和matched_claim。
- 出现异常时，先关联evidence_id、release_id、retest_id，再填写anomaly_type。
- 证据退场时，生成archive_id，保留旧版材料和替代证据说明。
这份清单让五类团队都有明确动作。内容团队不再独自承担事实核验，品牌团队不再只在最后审稿，产品团队可以维护事实边界，数据团队可以把复测结果接回发布动作，知识库团队可以用版本和归档保持长期一致。
常见问题
Q：GEO证据调用日志和普通内容台账有什么区别？
A： 普通内容台账通常记录文章或素材，证据调用日志至少记录7类对象和30个字段。 它关注证据从来源、版本、入口、发布到复测的完整轨迹。普通台账适合排期，调用日志适合审计追踪、异常归因和跨团队责任闭环。
Q：证据调用日志需要哪些团队一起维护？
A： 建议由5类团队共同维护：内容、品牌、产品、数据和知识库团队。 内容团队发起调用，品牌团队复核表达，产品团队确认事实边界，数据团队执行答案复测，知识库团队维护证据ID、来源状态、版本和归档记录。
Q：答案复测没有明显变化时怎么办？
A： 先保留至少3次同问题复测样本，再判断是观察窗口不足、入口不清、旧版残留还是平台差异。 不要用单次结果结束流程。日志里应记录T1、T2、T3样本，并把无变化状态接回异常归因表。
Q：证据版本很多时怎么避免混乱？
A： 用evidence_version管理材料变化，用claim_version管理表达变化，并让每次发布绑定同一组版本号。 证据版本和主张版本分开后，团队能看清是来源变化、表达变化，还是发布入口变化，归档时也更容易保留历史脉络。
Q：哪些证据适合进入长期归档？
A： 凡是被发布、被复测、出现异常或被多次调用的证据，都建议进入长期归档。 只作为灵感参考的材料可以放在临时区；一旦证据支撑了公开内容、FAQ、产品说明或AI答案复测，就应保留来源、版本、发布和复测记录。
