同一则传闻，不要问“是不是真的”。让 Grok 专门检索官方澄清、更正和反证，按澄清、反证、支持、未见分栏并附可点链接。你点开后再判断。官方没有传闻核查按钮。
要点
- 消费端可以在 grok.com 或官方 App 里用 Search：实时检索网页和 𝕏，并给出一手来源的即时引用。产品页写过，提问时可切换 search 等模式，具体按钮以现页为准。开发者文档里的
web_search／x_search用来说明能力上有这两条通道，不等于消费端按钮就叫这个名字。（Grok 产品页；Web Search；X Search） - 官方没有“传闻核查”或“专门找反证”的模式。你要的是输出纪律：先复述这则传闻的原话和出处，再分栏列出澄清、反证、支持和未见，每条附可点链接。打不开的来源不要写进结论。（用法建议，不是官方模板）
- 官方 cookbook《𝕏 Post to Fact-Check》是 API 侧的研究范式，不是 grok.com 上的按钮。它的纪律值得借：只信任检索真正返回的引用；没有来源支撑的结论写成证据不足；缺少上下文或存在矛盾时单独标出，而不是硬判真假。（𝕏 Post to Fact-Check）
- 消费端法律 FAQ 写过：Grok 偶尔会给出不准确或不合适的信息，也可能出现幻觉，用前须仔细核验。引用列表不等于终审，你仍要点开原页。（Consumer FAQs）
- 用实时检索给已有草稿做事实核对，是另一件事，见站内旧文。突发新闻怎么立时间窗，也不在本篇展开。本篇只谈：面对同一则传闻，怎么让它专门去找澄清和反证，而不是只替你找“像是真的”的旁证。（Grok：用实时检索给已有草稿做事实核对的步骤）
正文
场景
群里有人丢来一句话：某工作室已经内部砍掉下一部作品，还附了一张截图。你把它转给 Grok，随口问：“这是真的吗？”
回来的往往是三条转发和一篇标题很满的二手稿。官方账号有没有澄清，当事人有没有更正，对立的报道在哪里，这些可能根本没出现。
这是场景示意，不是某次逐字实测。
Search 本来就能实时检索网页和 𝕏，并带上引用。它不会自动改成“专门找澄清和反证”。你要把这个目标写进提示。官方没有这个按钮。
可跟做步骤／可抄工作流
下面是用法建议。官方没有传闻核查模式。
1. 先把传闻写成一条可核对的主张
开检索前，自己先写下四项：原话或尽量接近的转述，是谁在何时何地说的，你现在看到的出处链接或截图说明，以及这一条主张到底在说什么。
主张要写成能被证实或推翻的句子。例如：“某工作室已取消尚未公布的项目 X，依据是某日某账号的截图。”不要只丢一句“好像要黄了”。
截图可以一起上传。图里的字，仍要回到可打开的原帖或原页去对。不要让模型只根据图来下判断。
2. 不要问“是不是真的”，要它去找澄清和反证
“是不是真的”很容易把检索带去寻找支持项。你要明确写：先找当事方、官方账号、监管或交易所披露里的澄清、更正和否认；再找与主张直接矛盾的报道或原始材料；支持项可以列，但只当线索。
多代理适合更难、要并行查的问题。产品页写过，多个代理会分头查、再合并成一份带引用的回答。是否对你的账号开放，以及界面里叫什么，以现页为准。本篇不把某一档套餐写成门槛。
可抄提示，按你的题目改括号：
【任务】针对下面这一则传闻，专门检索澄清与反证。不要先给“是真的／是假的”的结论。
【传闻原话】（尽量逐字）
【出处】谁、何时、在何处说的；链接或截图说明：
【主张】把传闻压成一句可核对的话：
【必须检索】
1. 当事方、官方账号、官网或公开披露里的澄清、更正、否认、补充说明
2. 与主张直接矛盾的报道、原始文件或数据
3. 若存在支持项，只作为线索列出，不得单独写成已证实
【输出格式】
- 先用一两句话复述主张，不要改写成更满的版本
- 然后分四栏：澄清／更正、反证、支持（仅线索）、未见
- 每一条都写：来源标题、可点链接、该来源实际说了什么（尽量贴近原句）、它和主张的关系
- 没有检索到的，写进“未见”，不要用训练记忆补一条看起来很像的官方声明
- 打不开的链接删掉
【禁止】
- 不要编造未出现的链接、发言人或时间
- 不要把转发、二手综述或情绪化评论写成官方澄清
- 不要在来源不足时给出确定性结论3. 你要点开链接，再决定怎么用
模型给的分栏是工作底稿。法律 FAQ 已经提醒过，输出可能不准确，也可能出现幻觉。引用列表只说明它声称检索过，不证明那一页真的写了那句话。
点开时重点看：是不是当事方自己的页或账号，发布时间是否对得上，原句是否被写满或写反，以及“澄清”到底是否认、部分更正，还是尚未置评。
只有“未见”，就保持未见。不要为了交差，改口去问“那你觉得像不像真的”。
用检索给已有草稿做对核，是另一条工作流：那篇面对的是待发稿件里的主张。本篇面对的是同一则传闻，重点是把澄清和反证找全。两条可以衔接，但不要混成一次“帮我看看”。
真实用户诀窍／反例
- 诀窍：先写主张，再开检索。 主张含糊，分栏也会含糊。
- 诀窍：把“澄清”和“反证”写成必须完成的检索任务。 只问真假，支持项会先占满回答。
- 诀窍：转发不算澄清。 官方账号的原帖、官网声明或披露文件，优先于自媒体综述。
- 反例：让它直接下判词。 来源不足时，硬判真假比分栏更危险。
- 反例：把 cookbook 里的 Fact-check 当成 grok.com 的按钮。 那是 API 示例。消费端要靠提示把纪律写进去。
- 反例：只用 𝕏 上的热帖做结论。 网页和 𝕏 都要查；相互矛盾时写入分栏，由你判断，而不是让模型选一条更顺的。
适用边界
- 本篇只谈：对同一则公开传闻，用 Grok 的实时检索去找澄清和反证。不覆盖已有草稿的逐句对核，也不展开新闻时间窗怎么立。
- 官方没有传闻核查按钮，也没有“保证找得到反证”的承诺。提示可以要求它去找，不能要求它必须找到。
- 消费端按钮名称、是否默认开检索、多代理是否对你的账号开放，以登录后现页为准。
- 涉及未公开信息、隐私或尚未证实的指控时，检索结果只能当线索，不适合直接转发成“已经核实”。