写巡察报告、督查通报这类材料最怕的不是文笔不好是结论和证据对不上号结论说问题突出底稿里支撑就两行或者证据写了一大段结论却轻轻带过。这类材料要经得起被检查单位的申辩每一条结论背后都得站得住证据。参与过几轮之后我整理了一套核对思路配合 WPS 里的察元加载项用模型走本地端点材料不出域核心思想一句话把结论—证据当成一组勾稽关系来核。被抽调参加巡察、督查借调写材料的同志建议把这套思路收好。第一步长报告先分块巡察报告动辄几十页整改台账更长。整篇读容易顾此失彼先分块再核对。用 Claude Code 这类外部智能体连察元 MCP 的可以按块拉取原文——文档超过约 80k 字符本来也建议分块处理直接用加载项的话按章节选中处理就行。分块的目的不是偷懒是让每一段的核对都有始有终。第二步提取结论清单逐条挂证据先把报告里的结论性表述提出来。加载项里有现成的提取结论与风险助手我在提示词里加了一个限定提取本报告中的结论与风险表述逐条列出每条结论下方标注其在文中对应的证据段落找不到对应证据的单独标注证据待补“证据待补这个标注是整套思路的抓手。跑完这一遍报告哪里结实、哪里悬空一张清单看明白。悬空的条目无非两种处理补证据或者降调门——把普遍存在改成部分单位存在”让表述回到证据能撑住的位置。第三步定位核对防止看起来有证据有些结论后面跟着大段叙述看着有证据细看是背景介绍。对拿不准的条目用定位能力回到底稿原文报告里引用的每个事实回到底稿里找到原段落核对表述有没有走样——数字有没有抄错、时间有没有对上、主体有没有张冠李戴。这一步最枯燥也最出活。我核过一份报告引用底稿的一处3 月开展检查原文实际是开展检查至 3 月一字之差问题的时间跨度就变了。定位偶尔会报 LOCATE_NOT_FOUND多数情况是报告表述和底稿措辞差得太多锚点对不上——这本身就是个信号引用已经走样到对不回原文了必须人工重核。第四步底稿与报告交叉核报告从底稿浓缩而来浓缩过程就是风险过程。用多文档交叉的思路打开目录下这几份文档交叉检查错别字与术语是否一致术语这条在巡察材料里有特殊意义问题定性用语是有讲究的“违规与不规范”、“明知与应当知道”分量不同前后不一致就是给申辩留口子。交叉核出来的术语差异逐条确认是不是口径差异是就统一不是就往深里追。底稿多的组还有一个进阶用法把历年底稿放进察元的知识库做 RAG 检索对接察元桌面版或网络版查同类问题的历史定性表述比在文件夹里翻快得多对保持同类问题同类表述的连续性很有用。第五步差异全部批注留痕核对发现的出入一律写成批注钉在原处——结论悬空的、证据走样的、定性用语不一的批注写清与底稿不一致请复核。写回有确认机制批注必须显式确认才会写进文档核对过程中不会误操作污染原稿批注多的话可以攒一批一次写回单次批量写回的上限是 200 条操作正常核对远用不满但心里有个数。这一步的价值在于留痕谁核的、核出什么、怎么处理的后续组内研究时都有据可查。边界话放在最后这套思路核的是结论与证据对没对上不核定性定得对不对。问题的定性、条款的适用是巡察组和督查组集体研究的职责范围AI 碰不得也不该碰。工具把勾稽关系理清楚判断留给该判断的人——这个分工守住了工具才敢往深了用。