前几天小迪在水煮鱼一篇推广它自家知识星球订阅的文章看到下面评论,这马屁拍的,我鸡皮疙瘩都起来了。

小迪认可水煮鱼的能力,可是站在用户角度单从他的插件来看,他绝对不是WP最高的那座山。这个评论也让我想起以前琢磨WP建站,发现水煮鱼网站那段时光。
小迪也是从“看山是山”阶段过来,那个评论者大概在WP上面造诣不深,还在这个阶段。这也正常,国内WP建站新手一开始都会遇到水煮鱼这座山,觉得他很厉害,在这座山上耽误一些时间。
随着技术和认知提升,进入“看山不是山”的阶段,开始质疑水煮鱼。最后尊重实物多样性,不再纠结表象,“看山还是山” (山该是什么样还是什么样,不再执着它“必须是”什么,也不再恐惧它“其实不是”什么)。
现在小迪已经不用任何水煮鱼插件,也不续费他的知识星球,彻底脱“坑”。下面讲解下水煮鱼的插件有啥缺点,更好的替代品是什么。
以下仅为个人主观看法,只针对他写的插件使用体验,不针对他的技术和个人。
看山是山,水煮鱼插件/人很牛
先分享下小迪使用水煮鱼插件的过程,让大家明白小迪曾经也是资深用户,不是随便发表意见,也不是黑他。
小迪多年前想把网站链接微信公众号,在微信里面能分享和浏览网站,网上搜到水煮鱼的“微信机器人”插件,从此“入坑”。
了解之后发现水煮鱼是个WP开发大咖,做过很多厉害的项目,有一定知名度,有很多不错的免费插件,跟小迪一样在广州。
一开始对他挺有好感,所以后来有些小插曲小迪依然对他保持不错的看法,没粉转黑,只是粉转路人。
有段时间小迪搭建的所有外贸网站必安装他的WPJAM插件,用来优化、增强一些WP功能。后来还付费订阅他的知识星球,续费过1-2次,试用过他所有插件。
随着技术以及对WP的了解加深,同时接触到的国外插件越来越多,小迪逐渐发现水煮鱼的插件缺点,或者说不足之处。
我发现越来越多他插件给我带来的负面影响,有点要超过正面影响的样子。我开始质疑 (不是质疑他个人),WPJAM之类插件我还有必要使用吗?有没有更好的替代方案?
看山不是山,水煮鱼插件一言难尽
随着小迪对WP了解和建站技术提升,搭建网站手法越来越简单,要求也越来越高。长期使用WPJAM之类插件了解到一些它的Bug和局限性。
同时小迪也发现很多国外很牛逼的插件,全方面碾压WPJAM之类插件 (例如ASE插件),我开始弃用水煮鱼的插件,现在我们做的外贸网站水煮鱼含量为零。
水煮鱼插件有啥缺点?分享下个人使用体验和看法,不代表客观事实,仔细甄别,仅供参考。
缺点一:臃肿
虽然水煮鱼标榜速度快,性能好,可是它的插件并对我们使用者来说并不是那么极简,反而造成功能和代码上的臃肿。
功能上臃肿:水煮鱼自己在文章说,他的插件都是专门开发来给他自己项目。只不过顺便卖点钱,所以打包插件在知识星球会员付费订阅下载。
可能是小迪要求高或者个人需求不同吧,WPJAM等插件有很多功能用不上,而且有用上的功能在小迪使用的ASE、Perfmatters 等插件中已有同样功能。
这可能不算个缺点,毕竟不是每个人都使用ASE、Perfmatters 等插件,不过使用ASE等插件效果和功能更好。
代码上臃肿:上面说了水煮鱼的插件都是专门开发来给他自己项目/主题用的,这就导致他为了自己项目会添加很多无用代码进去。
在WPJAM更新日志中可以看到,每次更新添加一大堆函数和扩展,很多根本和我们正在使用的功能没关联,纯粹是为他自己项目/主题服务。
Changelog (我只放最近2个更新记录):
7.0
新增古腾堡编辑器组件渲染(侧边栏/弹窗)
去掉 jQuery UI Tab,使用 hashchange 实现 Tab 切换
WPJAM_Field 没有 options 的 checkbox 的类型统一为 toggle
WPJAM_Field 新增 cascade 多级联动组件
开启多语言和新增函数 wpjam_translate
新增函数 wpjam_register_widget 用于注册 Widget
新增函数 wpjam_compress 和 wpjam_uncompress 用于加密和解密数据
新增函数 wpjam_column 支持获取多列
新增函数 wpjam_entries 可以将关联数组转换成索引数组
增强函数 wpjam_chart 支持图表各种操作
新增函数 wpjam_formula 解析数学表达式
新增函数 wpjam_calc 计算数学表达式
其他优化和bug修复
6.9
新增函数 get_term_level
新增函数 get_term_depth
新增函数 wpjam_lines 处理文本转换成数组
新增函数 wpjam_hook,相比 add_filter 和 add_action 支持 check 和 nonce 参数
新增函数 wpjam_is,判断当前 query 是 is_main_query 并且还支持判断在哪些页面
新增函数 wpjam_matches,支持多条件匹配检测
新增函数 current_shortcode 和 doing_shortcode,用于 shortcode 获取和判断
新增 PHP 8.5 array_first 和 array_last 兼容
wpjam_try 和 wpjam_catch 函数新增 :: 和 -> 模式的支持
wpjam_value 函数新增 model 的支持
wpjam_set 函数支持 [] 模式新增元素
list_table_action 增加 update_setting 功能
WPJAM_DB 和 list_table 支持 search_column
WP_Query 新增 sticky_posts 参数支持
WPJAM_Args 新增 pick 方法
WPJAM_Taxonomy 和 WPJAM_Meta_Option 新增 show_in_posts_rest 属性
后台 JS 新增 list_table_load 事件
....
缺点二:Bug不断,修复慢
上面说了,水煮鱼的插件都是专门开发来给他自己项目/主题等用的,他几乎只用自己插件,不用Elementor、Woocommerce之类第三方插件。所以他也没怎么去测试插件跟一些知名第三方插件的兼容性,导致很多Bug。
尤其是跟Woocommerce兼容性很差,小迪在知识星球至少反馈过3个涉及Woocommerce的明显Bug↓。到后来我都麻了,懒得反馈。
水煮鱼后来使用AI改写插件,Bug更加频繁,有段时间连续3次版本更新都有明显Bug,我反馈到手酸,估计他也嫌我烦。
Bug多也就算了,还修复慢甚至不修复。一开始修复速度挺快,可是他上班后效率明显降低,6月11号反馈的微信机器人Bug,到今天23号也没修复。
可是他的公众号文章平均日更!这货把时间花在写文章上面也不愿意去修复Bug。他赚钱多了现在,看不上卖插件那三瓜两枣,加上他自己在文章说知识星球今年订阅/续费数下降了80%以上,估计他对插件爱理不理了。
下面放几个我们在水煮鱼知识星球提过的问题↓:
缺点三:不够强大,有更好替代品
水煮鱼的插件一开始就不是从用户需求出发,而是自用为主,够用就行,所以经常有人在知识星球说有些功能不够完善。
功能完善是主观看法,每个人需求不一样。可是如果有功能更加强大,效果更好的插件,干嘛不换呢?
例如 Admin and Site Enhancements (ASE) 插件,大家可以看下它的功能列表/介绍,功能多么强大全面,一个插件可以顶5-6个插件。
小迪建站使用这个ASE插件,速度各方面都很不错,稳定,客服支持好,修复Bug很快,定期更新实用新功能,功能可以按需开启。这才是一个插件该有的样子。
如果找不到更好的插件,按下面说的使用AI开发也很简单、快捷。
看山还是山,求人不如求AI
水煮鱼技术是牛,可是他不是一个面向大众的纯粹开发者,服务意识不够。卖插件只是他一个很小的副业,他自己都不重视这块,我怎么敢继续用他插件?
咱得承认,水煮鱼的技术和插件很不错,有值得学习的地方。不纠结他的缺点之类,也不强求他能满足我们要求。咱们尊重他,绕过这座山继续前进。
除了上面说的可以使用ASE等插件代替水煮鱼类插件,还可以使用AI开发相同功能插件。现在AI在插件开发方面非常牛,成熟,小白也可以使用AI开发出不输水煮鱼效果的插件。
小迪纯使用ChatGPT 5.5 基于EdgeOne Purger插件 原型开发了一个全新的CDN清理插件,速度和性能更好,更加简洁,安全性更高,修复了不少Bug,功能逻辑更好。
EdgeOne Purger插件是我朋友小李使用DeepSeek开发,功能都能用,略有瑕疵,有些地方没满足我需求。提要求多了,小李罢工不改了哈哈,那就我自己改。
我把插件ZIP安装包丢给 Codex 软件,让它帮按我要求完善功能以及调优。它自己解压,读取文件,修改文件,输出新ZIP安装包给我,直接上传安装就能使用。
对,就这么简单!就这么快速!只花了我几块钱 Token (买可靠中转站API)!求人不如求AI,AI时代不需要再依赖别人,自己动手吧!
建议使用Codex之类软件开发,可以读取本地ZIP安装包以及输出安装包,自己找下教程链接最新GPT或者Claude型号,花点时间学习下,3天你就能做出不输水煮鱼类插件的东西出来!
也可以基于水煮鱼的插件安装包修改或者制作新插件 (GPL授权, 以研究学习为目的,合法),把ZIP安装包丢给Codex,说清楚需求,它改好给你新安装包,上传安装就行。
后续不需要更新,安全性各方面已经不错。后续有Bug或者要调整功能之类,让AI优化就行。对话丢失就新建对话,重新上传安装包,写清楚需求。
山后还有山,别沉迷眼前的山停住自己的脚步,继续往前走吧,选择比努力重要。
再见了水煮鱼,那就好好道个别吧,(歌声响起) 时光的河入海流,终于我们分头走...






























