功能预览
稿件发出去才发现用词违规,问题在于把合规检查全押在发布之后。敏感词过滤在写入时生效,内容审核在发布前生效,关键词替换与全站替换用于批量改掉既有表述。三道防线各自拦在不同步骤,配合草稿、待发布、回收站的状态流转,才能保证违规词不上线、上线了也能退回来。
稿件发出去才发现用词违规,根本原因通常不是没做检查,而是把检查全押在最后那一步。AnQiCMS 的内容安全设置里,敏感词过滤在写入环节生效,内容审核在发布之前生效,关键词替换与全站替换则负责把已经存在的表述批量改掉。三道防线拦在不同的步骤上,配合文档的草稿、待发布、回收站状态流转,违规词才有机会在上线前被截住,已经上线的也能退回来处理。
第一道在保存动作里。写稿提交时,敏感词过滤按规则命中并处理,这一步能挡住的是词表里已经明确列出的表述。它的局限也很清楚:词表之外的、组合起来才违规的、以及换了说法的同义表述,机器判不出来。
第二道在发布动作之前。内容审核是发布前的一道复核,可以是规则复核,也可以是人工复核,处理的是机器判断不了的边界情况,比如绝对化表述与语境相关的宣传口径。第三道是事后批量修正。关键词替换处理既有内容的表述,全站替换则用于跨页面批量改关键词或链接,适合口径变化之后一次性清理历史稿。
| 环节 | 生效动作 | 拦截时机 | 出错后怎么退 |
|---|---|---|---|
| 写入保存 | 敏感词过滤、关键词替换规则 | 内容进库之前 | 保存失败提示,改词后重存 |
| 发布之前 | 内容审核复核 | 页面对外可见之前 | 退回草稿继续修改 |
| 定时发布 | 时间因子排期 | 计划时间点之前 | 取消排期,改回草稿 |
| 已上线 | 全站替换批量修正 | 上线之后 | 改后重新生成页面,错稿移入回收站 |
两者常被混为一谈,实际分工不同。敏感词过滤是拦截:命中就不让过,适合处理明确不能出现的词。关键词替换是改写:把 A 表述换成 B 表述,适合处理合规但不利索、或者口径统一类的修改。前者保护上线质量,后者降低批量返工成本。词表要有人维护,新的宣传口径、行业禁语变化,都落在词表与替换规则上,而不是靠写手记住。
正式文档删除并不是物理删除,而是移入回收站,可以恢复,这给批量处置留了余地。发现违规先改状态:把稿件退回草稿继续修改,改完再走一次发布前的内容审核。需要按排期统一上线修正版时,用定时发布控制放出时间,避免深夜改完立刻放出、第二天出问题没人看。处理完成的旧版本从回收站清空,未确认的先留着。
只做敏感词过滤够不够? 不够。绝对化表述往往依赖语境,要靠发布前的内容审核补上机器判不出来的部分。
历史稿件要一篇篇改吗? 不必。口径类问题用全站替换批量处理,个案再单独退回草稿修。
怎么确认拦截真的生效? 上线前拿一条命中规则的测试稿走一遍流程,看它停在哪一步,比看配置项更可靠。
预览
AI 辅助编辑模板能改的是页面结构与样式,它通过可视化模板编辑直接修改模板代码,而不是替你做设计。改样式、调布局、换板块顺序可以自己描述需求完成;涉及数据结构、接口字段与业务规则的部分仍需人来定。改版前先备份模板,改坏了才有回退路径。
预览
表单被机器人灌水时,验证码应加在公开入口的提交那一层,而不是只加在登录页。留言、注册、搜索等能被外部直接提交的表单都要单独核一遍防护。验证码只处理是不是真人,提交之后的敏感词过滤、关键词替换与内容审核构成第二道防线,负责拦下已经通过校验的垃圾内容。
预览
自定义内容模型加新字段,影响的只是字段层,老文章的正文不会被读不出来:新字段在既有文档上是空的,模板读到空值而不是报错。真正会出问题的是模板里把空值当成必取项、以及批量导入时列名与新字段没对齐。改前先备份,按分类分批迁移,出错还能退回。