已有待发草稿，不要让 Grok 重写全文。用实时检索把数字、引语、日期、职务与链接抽成清单，逐条对上官方来源。分栏写确认、矛盾、未见，你点开后只改对不上的句子。
要点
- 2026 年 11 月消费端产品页把 Search 写成：实时搜索网页和 𝕏，回答跟的是正在发生的事，不以一年前的训练数据为准。产品页还写，引用来自网上的一手来源，并与 𝕏 做实时整合。聊天里怎么打开检索、按钮叫什么，以你登录后的现页为准。（Grok 产品页）
- 官方 Consumer FAQs 的 “Does Grok make mistakes?” 写过：Grok 偶尔会给出不准确或不合适的信息，也可能出现幻觉，用前须仔细核验。打开实时检索不会取消这条提醒。（Consumer FAQs）
- docs.x.ai 把 Web Search 写成可实时搜索并浏览网页；Citations 文档则区分全部来源列表和文内引用。
citations默认返回智能体过程中遇到的全部 URL，不保证每一条都出现在终稿里。打开 inline citations，也不保证模型每句都标来源。（Web Search、Citations） - 本篇的做法是：先从已有草稿抽出主张清单，开检索但明确要求不要重写草稿，输出按确认、矛盾、未见分栏并附可点链接。你点开核对后，只改正文里对不上的句子。
- 官方 Cookbook 有过“𝕏 Post to Fact-Check”的例子：把一条 X 帖拆成主张，再用网页和 X 检索对核，并且只信任检索真正返回的引用；没有来源支撑时写 not enough evidence。这只是 API 工作流的类比。grok.com 现页并没有把它写成已有的“核对已有草稿”功能。（𝕏 Post to Fact-Check）
- 草稿如果涉及突发或带明确时间点的新闻，先把检索时间窗写死。具体怎么立时间窗，见站内另一篇，这里不重讲。（Grok：新闻／突发检索的时间窗纪律）用 Claude 做数字和引语核对，或把引用角标当线索，也另有专文，本篇不重开。（Claude：幻觉校验清单、Claude：引用角标只当线索，不当终审）
正文
场景
编辑手里已经有一篇待发草稿。有人把全文丢给 Grok，附加一句“核对事实，顺手把导语改顺”。
检索是开了。合成稿看起来更顺，导语也被重写，上一版已经钉死的限定词没了。官方价和论坛传闻写进了同一段。发布日期差了一天，职务来自一篇转述，和官方页上的写法对不上。链接有的能打开，有的对不上原句。
这是捆包风险的示意，不是某次逐字实测。实时检索能帮你对已有草稿做对核，但不能把“核对”和“重写”捆在一次请求里。从零扫描竞品的公开情报，见站内《Grok：竞品／公开情报检索的可复现流程》。那是另一件事。本篇假定稿已经写成，你只需要对上出处。
可跟做步骤／可抄工作流
先抽主张清单，再开检索
不要把整篇草稿丢进去，只说“帮我核对”。先自己把需要核对的句子抽成清单。每条只保留一件事：一个数字，一句引语，一个发布日期，一个职务，或一个链接。能指向草稿里的原句更好。
清单写不出来，通常说明你还没决定要核什么。这时先别开检索。
打开实时检索，但不要让它重写草稿
打开 Grok 产品页 上称为 Search 的能力：实时搜索网页和 𝕏，并带来自一手来源的引用。产品页“开始使用”里写过，提问时可以切换 search、reasoning，以及 voice 或 imagery 等模式。聊天界面里的按钮文案、入口位置，以及你的套餐能不能用，以登录后现页为准。不要靠猜测对号。
这一步只要求核对，不要求改稿。提示里把这句话写死。深度检索何时开，以及检索怎么少幻觉、多代理适不适合拆题，站内各有专文。对一篇已有草稿做逐条对核，不必先开多代理；对同一份文档做精确引用终审，多代理篇已经把这类任务排除在外。
如果草稿里的事实带明确时间点，先在提示里写死时间窗，再检索。怎么设 from_date 一类参数，见时间窗那一篇，这里不展开。
要求按确认、矛盾、未见分栏，并附可点链接
把主张清单交给 Grok 时，可以抄下面这类提示，按你的稿件改括号。对不上就写“未见”“不确定”或“对不上”，不要另造编辑室标签。
下面是一篇已经写好的草稿里需要核对的主张。请只做事实核对，不要重写草稿，不要改导语或口吻。
时间范围（如适用）：【例如 2026-11-01 至 2026-11-11，时区 Asia/Shanghai】
优先来源：【官方站点、官方公告、官方账号；社区讨论请单独分栏】
主张清单：
1) 【原句】｜需核对项：【数字／引语／日期／职务／链接】
2) 【原句】｜需核对项：【……】
3) 【原句】｜需核对项：【……】
输出要求：
- 按主张分条，不要合成一篇新稿。
- 每一条分成三栏：确认／矛盾／未见（或不确定、对不上）。
- 每一栏附可点开的来源链接；官方材料和社区材料分开写，不要揉成一句。
- 引语须尽量对上原文用词；对不上就标“对不上”，不要改写成更顺的句子充作原话。
- 打不开、对不上或找不到一手来源的，写“未见”或“不确定”，不要补齐。
- 最后列一张只含“矛盾”和“未见”的短表，不要私自改我的草稿。提示里的“需核对项”只用来标明这一条要核什么。模型的对外输出仍应写成确认、矛盾、未见，不要让它另造一套编辑室标签。
官方 Citations 文档提醒过：全部来源列表里会出现过程中看过、但终稿并未引用的 URL；打开文内引用，也不保证每句都有出处。cookbook 里的做法是只信任检索真正返回的引用，没有来源支撑就承认证据不够。那只是 API 示例里的类比，不能当成消费端已经内置的核对按钮。你仍要自己点开链接。
你点开核对，只改对不上的句子
模型回来的分栏表不是终审。至少做这三步：
- 逐条点开链接。打不开的、和原句对不上的，按“未见”或“对不上”处理，不要因为旁边有引用标记就放行。
- 官方材料和社区讨论仍分栏。传闻写进了“确认”，或官方口径和论坛说法揉在同一句里，都要拆开。
- 只改正文里对不上的那些句子。导语、口吻和未点名的段落，不要一并交给它改。需要润色时另开一轮，只带已经核对过的事实，不再打开一次“顺便改稿”的检索。
Consumer FAQs 的提醒仍然有效：输出可能不准确，用前须核验。实时检索能提供更新的来源，不会把核对义务转走。
真实用户诀窍／反例
- 诀窍：先写主张清单，再开检索。 一条主张只核一件事，回来才对得上。
- 诀窍：提示里写死“不要重写草稿”。 核对和润色捆在一起，限定词最容易丢。
- 诀窍：确认、矛盾、未见必须分栏，官方和社区必须分开。 对核的价值是把对不上的地方摆出来。写成更顺的一段话，这步就做歪了。
- 诀窍：链接要你自己点开。 来源列表可能包含未被终稿引用的页面，文内引用也不保证句句有出处。
- 反例：把整篇草稿丢进去，要求“核对并改顺”。 这是场景里那种翻车的常见写法。
- 反例：看见引用标记就当已经核对。 官方文档没有把引用写成终审开关。
- 反例：把 Cookbook 里的 𝕏 帖核对示例，写成 grok.com 已有的“草稿核对”功能。 那只是可借鉴的拆主张工作流。
- 反例：为了对一篇已有草稿做逐条对核，先开多代理或深度检索。 这类选型见站内专文，不是本篇的步骤。
适用边界
- 本稿覆盖：已有一篇待发草稿时，用消费端 Grok 的实时网页或 X 检索，对数字和引语，以及发布日期、职务与链接做对核。重点是步骤和提示，不是检索入门，也不是多代理选型。
- 不覆盖：从零做竞品公开情报扫描；新闻突发检索的时间窗怎么立；用 Claude 做幻觉校验或引用角标终审。那些题目只需在用到时点进站内旧文。
- 聊天里的模式名、检索开关和套餐限额，以登录后现页为准。本稿不重算档位账，也不把某个未登录时见到的模式名写成固定按钮。
- API 的 Web Search、X Search 和 Citations 能说明引用如何产生，不能直接等同于 grok.com 的按钮布局。Cookbook 的 𝕏 帖核对示例只作流程类比。
- 打开实时检索，不会让答案自动更准。可能出错，官方已经写过。终审仍是你点开链接、只改对不上的句子。