一份职务调整通知，和它背后的963篇文章

通知只有几百字，但它牵出的工作量，是963篇文章的逐一审查、判断和处理

周五傍晚，叶清妍看到通知的那一刻，脑子里只有一个念头：网站上的内容怎么办

周五下午五点零三分，叶清妍的手机弹出了推送。

集团接到上级党委紧急通知：因工作调整，赵承霖即日起不再担任集团董事长职务。

叶清妍是恒泽发展集团党委宣传部副部长，分管集团网站群的内容运营。看到通知的第三秒，她就意识到了问题的严重性——不是新闻本身，而是新闻背后那座冰山：赵承霖担任集团主要领导六年，集团网站群上涉及他的内容，少说也有几百篇。

果然，六点整，集团党委书记的电话就来了："宣传部牵头，信息中心配合，周一上班前，集团网站群上所有涉及赵承霖的内容，全部排查处理完毕。不能出错，更不能漏处理。"

周一上班前。也就是说，留给她的是一个周末。

一、963篇，每一篇都不能直接删

叶清妍立刻在网站后台搜索"赵承霖"。结果出来的时候，她的心沉了一下：963篇。

这些文章分布在集团主站和17个子站中，类型五花八门：有赵承霖带队调研的视察报道，有他在集团工作会议上的讲话稿，有他出席项目签约仪式的新闻，有他签发的工作通知和制度文件，还有大量会议纪要——他作为主要领导出现在标题、正文、签发人、领导班子介绍等各种位置。

集团党委的指示很明确："分类处理，不能简单粗暴。"具体来说，分四类：

第一类，必须下架。赵承霖个人的视察报道、讲话稿、专访文章——这些是以他为主角的内容，保留则职务信息已不准确，必须全部撤下。

第二类，删除名字。项目签约、工作会议等报道中，赵承霖只是出席者之一，事件本身有价值——这类文章保留，但要删掉他的名字和相关信息。

第三类，修改签发人。赵承霖签发的工作通知、制度文件——文件本身有效，但签发人不能再是他，需要改为现任领导或"集团办公室"。

第四类，可以保留。部分历史文章中只是在领导班子名单里并列提到，不构成单独宣传——经领导确认后，可以保留不动。

963篇文章，每一篇都要打开、查看、判断属于哪一类、执行对应操作。没有一篇可以跳过——因为漏掉一篇该下架的讲话稿，就是严重的工作失误。

二、试了三篇就知道，这个周末不够用

叶清妍叫上信息中心的小陈，两个人先试几篇摸摸底。

第一篇是一篇2023年的调研报道，标题就是"赵承霖带队赴某项目工地调研指导"。整篇文章2000多字，"赵承霖"出现了11次——标题、导语、正文每一个段落都有。叶清妍按Ctrl+F逐一查找，阅读上下文，确认这是第一类，必须下架。她执行取消发布，返回列表。这一篇用了6分钟。

第二篇是一篇项目签约报道，1500字，"赵承霖"出现了3次：一次在出席领导名单里，一次在签约仪式描述中，一次在结尾总结。叶清妍判断这是第二类，需要删掉名字但保留文章。她点击编辑，在编辑器里用Ctrl+F找到这3处，逐一删除或改写，保存，返回列表。这一篇用了9分钟。

第三篇是一份集团工作通知，签发人栏写着"赵承霖"。判断为第三类，修改签发人。但因为这篇通知还在执行期，她需要请示现任领导确认新的签发人是谁。等了15分钟才确认，修改保存。这一篇前后花了20分钟。

三篇平均12分钟。按这个速度，963篇需要11556分钟，约192个小时。

即使按最乐观的每篇3分钟算，也需要近48小时——两个人不吃不睡的48小时。而实际上，有些讲话稿长达5000字，"赵承霖"可能出现二三十次，光找完就要十几分钟。

更让人崩溃的是，手动操作时最大的敌人不是速度，而是疲劳后的失误：看漏一处该删的名字、改错一个不该改的段落、忘记哪篇已经处理过又重新打开——在几百篇文章的重复操作中，这些几乎不可避免。

三、关键不在"找"，在"找完之后怎么处理"

当晚九点，叶清妍给动易的技术支持工程师打了电话。工程师听完她的描述，说了一句让她重新审视整个事情的话：

这个工具就是WebFuture后台的批量综合处理。

叶清妍之前见过这个功能入口，但从没点开过。在她印象里，这不过是个批量搜索工具。工程师花了十分钟解释，她才明白：搜索只是第一步，这个功能真正的设计重心，全在搜索之后。

她立刻打开后台，进入批量综合处理。第一步，设置查询条件：选择所有内容模型的文本型字段，关键词设为"赵承霖"。点击查询。系统很快返回了963条记录，每条显示了标题、所属节点、匹配的字段名称。系统还自动通过站内短消息和邮件通知了她——这份清单已经缓存在系统里，即使关闭浏览器，下次回来还能继续，不会丢失进度。

批量综合处理的查询设置界面：输入关键词，勾选需要扫描的内容模型分类

她点开第一篇，立刻感受到了和手动操作的巨大差别。

四、三个细节，把每篇处理时间压缩到1分钟以内

细节一：查看页只显示匹配字段，关键词自动高亮。    

手动操作时，打开一篇文章，看到的是完整的几千字正文，要在里面找"赵承霖"出现的位置——用Ctrl+F搜索，找到一处，阅读上下文，再找下一处。有些讲话稿里"赵承霖"出现二三十次，光找完就要好几分钟。

修改页仅显示匹配字段操作

而在批量综合处理的查看页面，系统只显示包含关键词的匹配字段，"赵承霖"三个字已经被高亮标记。页面顶部有"上一处"和"下一处"按钮，点击就能在多个匹配位置之间快速跳转。叶清妍不用翻找，不用Ctrl+F——系统直接把每一个出现位置摆在她面前，她只需要读上下文、做判断。

那篇5000字的讲话稿，11处"赵承霖"，手动找要五六分钟；现在高亮定位加上下文判断，不到1分钟就处理完。

查看页面：只显示匹配字段，支持上一处/下一处快速定位

细节二：修改页只显示匹配字段，改完自动从清单排除。    

第二类和第三类文章需要修改内容。手动操作时，要进入完整的文章编辑器，在几千字里找到要改的位置，修改，保存，返回列表。而批量综合处理的修改页面精简到了极致——不显示整篇文章，只显示包含"赵承霖"的那个具体字段。叶清妍直接在这个字段里删掉名字或改写措辞，点击"保存修改结果并从清单排除"——修改完成，文章自动保存，这条记录自动从清单消失。整个过程不到40秒。

修改页提供"保存修改并从清单排除"操作

那篇需要改签发人的工作通知也是一样：修改页只显示签发人字段，她把"赵承霖"改成"集团办公室"，保存排除，30秒搞定。不需要请示等待的，处理速度极快。

细节三：不需要改的，3秒排除；需要下架的，留在清单最后批量执行。    

第四类文章经确认可以保留的，直接点击"从清单中移除"，3秒处理完。而第一类需要下架的文章，叶清妍在查看时已经判断完毕，不需要逐一执行下架操作——她只需把它留在清单里，继续处理下一篇。

三种处理方式，恰好对应了四类内容。而清单的设计让整个过程像流水线一样顺畅：每处理完一篇，它就从清单上消失，不会重复处理，也不会遗漏。叶清妍随时能看到清单剩余数量在递减——从963到800，到500，到200……

周日下午，清单归零，叶清妍完成了最后一轮复查

五、最后一步：批量收尾，十分钟清场

到周日下午，清单上只剩下最后一批文章——那些在查看时已经判断为"必须下架"的第一类内容。这些文章在前面逐一查看时已经审过，现在只需要执行操作。

叶清妍全选清单剩余记录，选择"批量取消发布"。一键执行，所有标记下架的文章同时从网站前台撤下。对于那些需要彻底从数据库清除的，她再执行一次"批量移到回收站"——日后如果需要恢复，还能从回收站找回。

整个批量操作不到10分钟。

最后，叶清妍打开了系统日志。批量综合处理功能自动记录了每一条操作的详细信息：处理的文章ID、标题、匹配字段、执行的操作、操作人和操作时间。她导出这份日志，作为排查处理的工作台账，提交给集团党委备查——这在后续上级单位检查时，是关键的合规凭证。

从周五晚九点到周日下午，4个人轮班，实际处理时间约14个小时。其中查看判断约11小时，批量收尾不到1小时，复查约2小时。比最初估算的192小时——或者说每人96小时不吃不睡——缩短了93%。

六、真正"救命"的，不是搜索，是搜索之后的每一步

事后复盘时，叶清妍在宣传部内部总结会上说了一段话：

更关键的是准确性。在这种政治任务中，漏处理一篇该下架的讲话稿，或者误删一篇不该删的会议纪要，后果都不堪设想。手动操作时，一个人连续处理几十篇后注意力必然下降，看漏、改错几乎不可避免。而批量综合处理通过高亮定位确保每个关键词都被看到，通过清单机制确保每篇文章只处理一次，通过日志记录确保每一步操作都可追溯——它不只是提升了效率，更是在效率和准确性之间找到了平衡点。

叶清妍后来在集团信息化的工作群里发了一条消息：