WordPress 怎么关闭 AI 功能（核心还是插件，说实话）

在 WordPress 里，大家想关掉的 AI 功能几乎都来自插件、主机商或者 WordPress.com，而不是自托管的核心。在把某段 remove_action 代码粘进 functions.php 之前，先打开插件列表，找出真正渲染那块 AI 面板的东西——去移除一个核心根本没提供的功能，只是在一个已经不正常的站点上白费力气。

这个区分很重要，因为解法完全不同。插件功能有设置开关。主机商注入的功能在你的主机后台里，不在 WordPress 管理后台。而大家说”关闭 AI”时通常真正想问的另一件事——阻止 AI 公司拿你的文章做训练——压根不是一个 WordPress 设置，那是 robots 和服务器配置的问题。

哪些是核心的，哪些不是

自托管的 WordPress 核心不会开箱即用地提供面向用户的 AI 写作助手、AI 聊天机器人或 AI 图片生成器。如果你在区块编辑器里看到一个 AI 星光图标，那是某个东西装上去的。

AI 功能真正的来源：

来源	典型功能	在哪里关闭
Jetpack	AI Assistant 区块和编辑器面板	Jetpack 设置里的模块开关
独立 AI 插件	内容生成、聊天机器人、替代文字撰写	插件自己的设置页面
SEO 插件	AI 标题／描述建议	插件设置，通常按功能分开
页面构建器	构建器界面里的 AI 文案和图片生成	构建器设置或账户面板
托管主机商	通过 mu-plugin 或后台注入的 AI 助手	主机控制面板
WordPress.com	托管的 AI 写作工具	WordPress.com 账户设置，不在你的站点里

WordPress 项目确实有持续进行的 AI 相关开发——一些实验性功能插件将来有可能进入核心。如果你用的是较新版本，看到某个 AI 味道的东西又归不到任何插件头上，先查已安装插件列表，再查你所用版本自己的更新日志，而不要一上来就假设那是某个需要过滤掉的核心默认项。这里的谨慎是刻意的：这个领域里跟版本绑定的说法过期得非常快，一个错误的说法会让你毫无意义地去改文件。

找出到底是谁加的

分批停用插件，直到 AI 面板消失。方法很笨，但它给你的是确切答案，而不是猜测。

如果你有 WP-CLI，先把所有启用中的插件列出来：

wp plugin list --status=active --field=name

然后检查主机商注入的代码，这些在正常的插件页面里是看不到的：

ls -la wp-content/mu-plugins/

必用插件（must-use plugins）会自动加载，而且无法从管理后台停用。如果你的主机商往那里丢了一个 AI 助手，唯一干净的移除方式是通过他们的控制面板——直接删文件往往会在平台下次更新时又长回来。

正确地关掉它

用插件自己的设置项。 这是个无聊的答案，但它是对的。Jetpack 尤其如此，它的设计就是各模块可以独立开关，你可以关掉 AI Assistant 而保留统计、备份或者别的你依赖的功能。大多数独立 AI 插件都会为每项功能提供一个启用／停用的复选框。

如果这个插件你别的功能都不用，就把整个插件停用。 一个装着但被”禁用”的 AI 插件，仍然会在每次请求时加载它的代码。停用更快、更安全，也比任何过滤器都实实在在地更轻。

用 remove_action 解钩是最后手段。 它确实有效，但前提是你知道插件注册时用的确切钩子名、回调和优先级，而且只在插件没改掉其中任何一个之前有效：

// Only if you have verified the exact hook, callback and priority.
// Runs late so the plugin has already registered its own hooks.
add_action( 'init', function () {
    remove_action( 'enqueue_block_editor_assets', array( 'Some_Plugin_Class', 'enqueue_ai_panel' ), 10 );
}, 99 );

老实说它的代价是：会悄无声息地失效。插件更新改了类名，你的移除就匹配不上了，AI 面板回来了，而且不会有任何报错来提醒你。如果你要用这个办法，把你移除了什么记下来，并在该插件每次更新后重新检查。

从 JavaScript 里注销编辑器面板同样要小心。那确实是个可行的能力，但你是在用字符串标识去伸手动别的插件的注册项，而那个标识并不是公开契约。

不要试图靠改 wp-config.php 里某个从论坛帖子上抄来的常量去屏蔽 AI 功能。 没有任何核心常量能关掉第三方插件的 AI。如果某段代码声称可以，而你又无法在那个插件的文档里找到这个常量，那它什么也不会做。

另一个问题：阻止 AI 拿你的内容做训练

这是另一回事，也是真正焦虑集中的地方。关掉一块编辑器面板，丝毫改变不了谁在抓取你的文章。控制这件事要在 robots.txt 里做，如果你想要强制执行，还要在服务器上做。

除非网站根目录下存在真实文件，否则 WordPress 会提供一个虚拟的 robots.txt。一旦存在物理文件，WordPress 就完全靠边站，爬虫拿到的就是那个文件。要修改虚拟的那份，用过滤器：

add_filter( 'robots_txt', function ( $output ) {
    $output .= "\nUser-agent: GPTBot\nDisallow: /\n";
    return $output;
}, 10 );

手写规则正是大家出错的地方——一个标识写错就什么都没屏蔽掉，而在错误的 agent 上多写一行 Disallow: / 就可能把你从正常搜索里拉出去。robots.txt 生成器会把 AI 爬虫规则和你常规的搜索指令一起拼好，让你在上线前先看到完整文件。

主流厂商公开并声明会遵守的标识：

标识	厂商	覆盖范围
GPTBot	OpenAI	为模型训练进行的抓取
ChatGPT-User	OpenAI	由用户请求触发的抓取
ClaudeBot	Anthropic	抓取
Google-Extended	Google	你的内容是否用于 Gemini 训练，而非抓取本身
Applebot-Extended	Apple	用于 Apple 生成式模型训练
PerplexityBot	Perplexity	抓取
CCBot	Common Crawl	众多模型训练所依赖的大规模归档

两点要说实话。第一，robots.txt 是自愿遵守的。守规矩的厂商会照做；想无视它的东西一定会无视。第二，屏蔽不是没有代价的。其中一些标识决定了你是否会出现在那些引用并链接你的 AI 生成回答里。全部屏蔽，你在失去训练曝光的同时也失去了那条引流通道。想清楚你真正在意的是哪一个。

如果你要的是强制执行而不是礼貌请求，就在服务器层面拦截。Apache 的 .htaccess：

<IfModule mod_setenvif.c>
  SetEnvIfNoCase User-Agent "GPTBot|CCBot|ClaudeBot|PerplexityBot" ai_bot
  <RequireAll>
    Require all granted
    Require not env ai_bot
  </RequireAll>
</IfModule>

User-agent 字符串伪造起来毫不费力，所以这只能挡住诚实但你不欢迎的流量，挡不住铁了心的抓取者。在 CDN 或防火墙上按已验证的 IP 段拦截更强，而且现在大多数 CDN 都提供一键式的 AI 机器人规则，比手写清单好维护得多。

哪些做法没用

llms.txt 是提案，不是标准。 它是一份建议性的 markdown 文件，用来向语言模型描述你的网站。没有任何主流厂商承诺把它当作访问控制。加上它不花什么成本，也许还能改善模型读取你的方式，但它屏蔽不了任何东西。

noai 和 noimageai 这类 meta 标签几乎没人遵守。 它们出自某一个平台的政策，而不是跨行业共识。加上它们不算有害；指望它们生效才是问题。

声称能”屏蔽 AI”的插件，通常只是替你写了 robots 规则。 这没问题，而且这正是你自己十行代码就能做的事。它不是法律屏障，也不是技术屏障，任何插件都变不出这两样。

屏蔽 AI 爬虫无法把已经进入训练好的模型里的内容取出来。 你今天加的任何东西，都无法把你的文章从去年发布的模型里追溯性地拿掉。robots 规则只对将来生效。

还是能看到 AI 面板

如果所有插件都关了面板仍在，再去看一遍 wp-content/mu-plugins/，然后看主机后台，再确认一下你用的是不是 WordPress.com 而非自托管——那边的开关在账户设置里，不在站点管理后台。而如果这个功能在某次插件更新后又回来了，那是解钩代码匹配失效的典型特征，不是核心默认项在起作用。