核验 Gemini 3.6 Flash（或同类型生成模型）的输出，不能停留在“再读一遍”的层面。生成模型的通顺度与事实正确性没有必然关系，核验工作应当围绕三件事展开：把输出拆成可独立验证的部分、给每个部分配上验证依据、再对未被验证覆盖的部分留出明确的风险标记。
核验生成结果，先拆成事实、推理、建议三层。事实靠来源核对，推理靠假设和边界检查，建议靠适用场景判断。模型输出的顺滑措辞不是正确性信号，任何事实性断言都需要落到可复现的输入来源上；无法回溯来源的部分，需要标注为待确认。
先限定输出结构，核验才有抓手
在让 Gemini 3.6 Flash 生成内容之前，先在提示词里要求模型区分“已确认事实、推断、建议”三类信息，并对每一类给出可回溯的依据。这样核验时能直接定位薄弱位置，而不是在整段文字里大海捞针。
请按以下结构输出，不要混写：
1. 已确认事实：只列有明确公开来源的内容，并在〔〕内标注来源类型（官方文档、行业通报、通用常识）。
2. 推断：明确写出“基于……推知”，并列出所做的假设。
3. 建议：说明适用于什么场景、什么条件下失效。
如果某条内容你无法确认来源，直接标注“无法确认来源”。这一步不改变模型的生成能力，但会改变结果的编排方式，让后续核对从“读全文”变为“逐条验证”。
逐层核验清单
对已生成的结果，建议按下列顺序做复核，每一条都要能回答“如何证伪”：
- 事实层：内容里是否有名称、日期、版本号、统计数字？如果有，找到对应来源页面确认原文，而不是依赖模型转述。
- 逻辑层：如果模型从前提推导出结论，前提是否成立？有没有把“推测”写成“专家共识”？
- 时效层：模型自身知识截止时间未知或版本升级后行为会变化，涉及最新政策、软件版本、价格的内容，必须回到官方页面或公告核对。
- 数据层：出现百分比、排名、性能指标时，确认统计口径和采样范围；没有给出口径的数字一律按不可用处理。
- 边界层：模型的建议是否默认了特定环境和资源？需要把场景限制补回原文，避免读者误读为通用方案。
用二次提示词做自检，但不能替代人工核验
可以先用疑问句向模型发起第二轮质询，让模型对同一份输出进行反向检查，这个动作能找出部分幻觉。推荐做法是：让模型扮演具备严格批判态度的审核者，针对“上一条回答中的事实、数字、日期、推论前提”逐项提出质疑。下面这个提示词模板可以直接使用，建议把模型上一次的输出追加在该提示词之后：
请重新检查我上一次给你的回答。逐项指出其中：
1. 哪些内容你没有可靠来源？请用〔存疑〕标记出来。
2. 哪些结论依赖于未被验证的假设？请写出这些假设。
3. 哪些表述存在范围过大、过于绝对，或把推测写成事实的问题？
只列问题，不需要修正后的版本。自检的价值在于暴露漏洞，但不代表输出从此可靠。模型的自检仍然建立在自身内部知识上，无法访问外部实时信息，所以以下人工动作不能省略：随机抽 3 处事实性断言回源核对；把数字和日期单独提取出来逐项对照；把建议部分放到真实工作场景里试跑一次，验证是否可执行、是否产生副作用。
高频易错点与边界确认
核验时最容易漏掉的是依赖“隐含假设”的内容。例如模型倾向把过去的答案直接应用到未来时间点，或者在缺少资料时用大概率猜测补全细节。处理建议是：时间敏感信息一律到原官网查看截止日期；代码片段需要直接执行，而不是目测；配置文件里的路径、端口、密钥占位符要逐个确认。版本相关行为——比如 Gemini 3.6 Flash 具备哪些能力、在什么情况下容易出错——需要结合自己实际使用的环境和模型反馈来确认，无法在文档之外提前做出保证。凡是模型自己没有明确给出置信度的输出，人工侧都要按最高风险等级处理。