企业官网建设流程全解析

写巡察报告、督查通报这类材料，最怕的不是文笔不好，是结论和证据对不上号：结论说问题突出，底稿里支撑就两行；或者证据写了一大段，结论却轻轻带过。这类材料要经得起被检查单位的申辩，每一条结论背后都得站得住证据。参与过几轮之后，我整理了一套核对思路，配合 WPS 里的察元加载项用（模型走本地端点，材料不出域），核心思想一句话：把"结论—证据"当成一组勾稽关系来核。

被抽调参加巡察、督查借调写材料的同志，建议把这套思路收好。

第一步：长报告先分块

巡察报告动辄几十页，整改台账更长。整篇读容易顾此失彼，先分块再核对。用 Claude Code 这类外部智能体连察元 MCP 的，可以按块拉取原文——文档超过约 80k 字符本来也建议分块处理；直接用加载项的话，按章节选中处理就行。分块的目的不是偷懒，是让每一段的核对都有始有终。

第二步：提取结论清单，逐条挂证据

先把报告里的结论性表述提出来。加载项里有现成的"提取结论与风险"助手，我在提示词里加了一个限定：

提取本报告中的结论与风险表述，逐条列出；每条结论下方标注其在文中对应的证据段落，找不到对应证据的单独标注"证据待补"

“证据待补"这个标注是整套思路的抓手。跑完这一遍，报告哪里结实、哪里悬空，一张清单看明白。悬空的条目无非两种处理：补证据，或者降调门——把"普遍存在"改成"部分单位存在”，让表述回到证据能撑住的位置。

第三步：定位核对，防止"看起来有证据"

有些结论后面跟着大段叙述，看着有证据，细看是背景介绍。对拿不准的条目，用定位能力回到底稿原文：报告里引用的每个事实，回到底稿里找到原段落，核对表述有没有走样——数字有没有抄错、时间有没有对上、主体有没有张冠李戴。这一步最枯燥，也最出活。我核过一份报告，引用底稿的一处"3 月开展检查"，原文实际是"开展检查至 3 月"，一字之差，问题的时间跨度就变了。

定位偶尔会报 LOCATE_NOT_FOUND，多数情况是报告表述和底稿措辞差得太多，锚点对不上——这本身就是个信号：引用已经走样到对不回原文了，必须人工重核。

第四步：底稿与报告交叉核

报告从底稿浓缩而来，浓缩过程就是风险过程。用多文档交叉的思路：

打开目录下这几份文档，交叉检查错别字与术语是否一致

术语这条在巡察材料里有特殊意义：问题定性用语是有讲究的，“违规"与"不规范”、“明知"与"应当知道”，分量不同，前后不一致就是给申辩留口子。交叉核出来的术语差异，逐条确认是不是口径差异，是就统一，不是就往深里追。

底稿多的组还有一个进阶用法：把历年底稿放进察元的知识库做 RAG 检索（对接察元桌面版或网络版），查同类问题的历史定性表述，比在文件夹里翻快得多，对保持"同类问题同类表述"的连续性很有用。

第五步：差异全部批注留痕

核对发现的出入，一律写成批注钉在原处——结论悬空的、证据走样的、定性用语不一的，批注写清"与底稿不一致，请复核"。写回有确认机制，批注必须显式确认才会写进文档，核对过程中不会误操作污染原稿；批注多的话可以攒一批一次写回，单次批量写回的上限是 200 条操作，正常核对远用不满，但心里有个数。这一步的价值在于留痕：谁核的、核出什么、怎么处理的，后续组内研究时都有据可查。

边界话放在最后

这套思路核的是"结论与证据对没对上"，不核"定性定得对不对"。问题的定性、条款的适用，是巡察组和督查组集体研究的职责范围，AI 碰不得也不该碰。工具把勾稽关系理清楚，判断留给该判断的人——这个分工守住了，工具才敢往深了用。