运营内容型 WordPress 站点时，风险词检查很容易变成一项重复劳动：发布前靠人工搜索，改完正文还要确认标题、摘要、SEO 文案和分类归档页有没有遗漏。内容一多，单靠记忆和抽查并不可靠。
我做了 WP Risk Scanner，把风险词表、内容扫描、保存拦截、定时任务和通知放进同一个 WordPress 后台。它不是替代人工判断的“自动审核器”，而是先把可能有问题的位置找出来，让维护人员更快完成复核。
一、先维护一份可复用的风险词表
插件在后台增加“风险词管理”菜单，可以为每个风险词填写推荐替换词和处理说明。词表支持新增、编辑、删除、搜索和分页，也支持 CSV 导入导出。
导入时可以选择合并或替换全部。合并会更新同名词并追加新词；替换全部则需要勾选确认并再次确认，避免误操作清空现有数据。词表发生变化后，后台会提示重新执行全量扫描，因为旧结果已经不能代表当前规则。
二、扫描范围不只是一篇文章的正文
默认扫描已发布的文章和页面，具体文章类型可以在设置中调整。一次扫描会检查标题、正文和摘要，同时兼顾 Elementor 数据以及 Yoast 的标题、描述等 SEO 字段；没有安装 Elementor 或 Yoast 时，核心扫描仍然可以独立工作。
全站扫描采用 AJAX 分批执行，并显示进度，避免一次请求处理大量内容。扫描结果会保留命中的风险词、来源和上下文片段，可以按资源类型、状态、文章类型、标题或风险词筛选。确认属于合理用词时，也可以将它加入当前内容的白名单，而不是从全局词表里删除。
三、分类和标签归档页也能单独检查
一些站点会为分类、标签或自定义 taxonomy 编写独立介绍，页面上还可能出现主题模板渲染出来的额外文案。只扫文章正文，会漏掉这些公开可见内容。
开启归档页扫描后，可以指定要检查的 taxonomy。插件会采集 term 名称、描述、字符串 meta、Yoast taxonomy SEO 文案，并请求前台归档页提取可见文本。归档结果与文章结果分表保存，也有独立白名单，日常筛选和处理时仍可在同一风险列表中查看。
四、在发布前拦截，或在发布后持续巡检
保存拦截默认关闭，启用后会在 Gutenberg REST 保存和 Elementor 保存流程中检查风险词，只对目标状态为“已发布”的内容执行拦截。这样草稿阶段可以继续整理内容，真正发布时再做最后一道检查。保存成功后，插件还会在请求结束阶段延迟重扫当前文章，让后台风险列表及时更新。
对于持续运营的站点，可以配置每天多个扫描时间。默认使用 WP-Cron，也可以通过带密钥的 URL 接入系统 Cron、宝塔或外部定时服务。正常情况下执行增量扫描；词表变更后，则会自动切换为全量扫描。扫描日志保留约 15 天，便于确认任务是否运行、耗时多久以及是否发生错误。
五、发现问题后把结果送到现有工作流
通知同样默认关闭。开启后，扫描发现风险内容时可以发送到通用 Webhook，或使用飞书机器人预设；飞书通道支持可选签名校验。通知里会区分文章与归档页的违规数量，并附上近期命中项目和后台处理入口。
这里我刻意保留了“安全默认”：插件刚启用时不会拦截保存、不会扫描归档页、不会发送通知，卸载时也默认保留数据。管理员可以先导入词表并运行一次手动扫描，确认规则和误报情况，再逐步开启拦截、定时任务和通知。
六、适合什么场景
- 内容较多，需要定期排查风险词的企业站或资讯站。
- 同时使用 Gutenberg、Elementor 和 Yoast，希望统一检查公开文案的站点。
- 已经有飞书或自建 Webhook，希望把扫描结果接入现有运营流程的团队。
WP Risk Scanner 目前要求 WordPress 6.0+、PHP 7.4+。安装后，在“风险词管理”中导入词表、选择扫描范围，再从手动全站扫描开始即可。代码已放在 GitHub，后续遇到问题也可以通过仓库 Issue 反馈。
