程序媛 Archives - obaby 𝐢‍𝐧⃝ void

浅谈前后端分离系统的SEO优化

obaby — Mon, 27 Apr 2026 02:03:03 +0000

开发一个系统，不管是从头开始，还是在已有系统上二次开发，从来都不是一蹴而就的事情。在上线以前总觉得已经做够了足够的测试，但是在上线之后还是会出现各种各样的问题。

有的问题，如果是新系统完全可以避免，正是由于是在已有系统上开发的为了兼容wp才会引入一系列的问题，这类问题主要是wp原生的一些机制兼容问题导致的包括但不限于：

1.wp固定连接的兼容

2.shortcode的解析处理

3.wp资源文件与新系统资源文件的路径兼容处理

4.wp启用插件的功能实现，邮件通知、micro-post、邮件发送、邮件模板等等

5.其他的未知问题

也有一部分是新系统天生的缺陷：seo不友好，搜索引擎爬虫无法获取网页内容，毕竟robot不会执行js，这个是前后端分离系统的必然缺陷。



  
    
    
    
    
    
    
    
    
    
    
    
    
    obaby 𝐢‍𝐧⃝ void - 程序媛 / 独立开发者 / 智商不稳定的女神经

当然有人会比较在意这个东西，不是说这个东西不对。可能是自己没那么在乎吧，之前就曾经收到过数次关于seo友链不显示的问题，上次是搞页面静态化。

其实，在我的博客添加的友链，也并不是全部都不显示，毕竟还有其他的域名，zhongxiaojie.com 以及 oba.by等还是会显示完整的友链信息，这两个域名并没有切换到新的前后端分离的系统。所以，我博客的友链，相当于数个站都给友链做了多次链接，我不知道这个东西对于seo有没有作用，至于是有好处，还是有坏处，我并不清除，我自己并不是那么关注所谓的seo。如果觉得这样反而会出问题的，欢迎反馈，我会及时删除相关链接哈。

当然，这个东西有办法解决吗？答案自然是有，至于解决方法，那就是继续回归服务器渲染。

这解决方案真的是简单粗暴啊，合着这折腾来折腾去，又要弄回服务器渲染，这辛辛苦苦四十年，一夜回到解放前？

采用这种简单粗暴的方法来解决seo问题，显示不是本仙女的作风。既然是针对搜索引擎的，那就直接对搜索引擎做单独的处理就完了。检测ua，如果是收缩引起的ua返回服务器渲染之后的内容，如果是正常浏览（搜索引擎爬虫意外的ua）返回前后端分离的内容。

要实现服务器渲染，基于vue的可以参考nuxt.js(百度百科):

Nuxt.js是由NuxtLabs团队于2016年10月推出的基于Vue.js的开源Web框架，采用MIT License授权。该框架灵感来源于Next.js，Nuxt采用了约定俗成的规范以及一种明确的目录结构，以实现对重复性任务的自动化处理，并使开发人员能够专注于推进新功能的开发。^[2]^[5]^[8]。

Nuxt默认内置服务器端渲染（SSR）功能、支持静态站点生成（SSG）和单页面应用（SPA）三种部署模式，可通过”nuxt generate”命令生成预渲染HTML文件实现静态化部署^[5]^[7]。采用模块化架构提供50多个扩展模块，支持TypeScript类型安全、推送和现代化开发工具链^[4]^[6]。

接下来也就简单了，创建nuxt项目，实现与frontend同样的页面路由和相关的页面文件布局。接口可以直接复用当前的接口，

配置openresty的处理逻辑：

# -----------------------------------------------------------------------------
# Dynamic Rendering（SEO）：爬虫 UA → Nuxt SSR；普通用户 → 现有 SPA
# - Nuxt SSR 服务建议监听 127.0.0.1:3000（可按需调整）
# - ?__ssr=1 可强制走 SSR（方便自测/排障）
# - 仅对“页面路由”生效，不影响 /assets、/vendor、/bp-api、WP 后台等
# -----------------------------------------------------------------------------
set $bp_force_ssr 0;
if ($arg___ssr = "1") {
    set $bp_force_ssr 1;
}

set $bp_is_bot 0;
if ($http_user_agent ~* "(googlebot|bingbot|baiduspider|yandexbot|duckduckbot|slurp|sogou|360spider|bytespider|petalbot|facebookexternalhit|twitterbot|rogerbot|ahrefsbot|semrushbot|mj12bot)") {
    set $bp_is_bot 1;
}

location @nuxt_ssr {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Uri $request_uri;
}

# 418 跳转技巧：在页面路由里 return 418 → error_page 转到 @nuxt_ssr
error_page 418 = @nuxt_ssr;

启动之后就可以查看服务器渲染的页面了：

当然，这个实现方法的缺点就是得完全复刻frontend的相关路由和页面，优点就是不用关注原来的系统实现逻辑，哪怕爬虫seo系统出问题也不会影响现有的系统运行。

产品，还是玩具？ — Baby Press(缝合怪)

obaby — Fri, 24 Apr 2026 06:58:12 +0000

这算是给这个东西写的第二篇正式的文章，本来我的想法很简单，做一个简单的前后端分离的系统来完全替代wp的php渲染机制。

只是，在开发的过程中为了迎合wp的各种现有数据格式、插件、主题、shortcode等等，代码复杂度也在不断的提高。得益于ai的崛起，现在生成代码是真的简单方便，原来数个人的工作，现在一人就可以完成了。尽管哪怕没有ai，我自己也能全部搞定。ai在某些方便还是提高了输出效率，原本很多人不是全栈的，现在也给搞成了全干工程师，哪怕不会，也得硬着头皮上，去验证ai写的各种代码。

我一般不喜欢给ai太具体的描述，但是会给一个准确的描述，实现方法，实现路径，实现目标，所以多数时候ai呈现的代码质量尚可。然而，等到实际上线的时候发现还是一堆问题。

做完准备把wp的前端全部迁移到现在的baby press的前端，尝试部署之后出现了一系列问题，当然很多问题源自于测试不充分。为了解决两个系统的整合问题，需要大量的配置文件和代码。除了openresty的配置文件，前后端也生成了一堆默认的配置模板，当然，这些模板主要是为了提供一些自定义的功能，以及安全性提升加密等等。

这么复杂的系统，现在我觉得更像一个玩具，而不是产品，好的产品应该是简单易用，开箱可用的。

DJANGO_SECRET_KEY=dev-secret-key-change-me
DJANGO_DEBUG=1
DJANGO_ALLOWED_HOSTS=127.0.0.1,localhost
# 浏览器里「页面」的 origin（协议+域名+端口），须与前端访问地址一致；逗号分隔、勿加路径。
# 生产示例（Vue 部署在 i 子域、API 在 api 子域时，必须把 i 子域写进来，否则会 CORS 失败）：
# CORS_ALLOWED_ORIGINS=http://127.0.0.1:5173,http://localhost:5173,http://i.zhongxiaojie.cn,https://i.zhongxiaojie.cn
CORS_ALLOWED_ORIGINS=http://127.0.0.1:5173,http://localhost:5173
# Django CSRF 信任来源（协议+域名+端口，逗号分隔；用于 /admin/login/ 等表单提交）
# 生产示例：CSRF_TRUSTED_ORIGINS=https://api.zhongxiaojie.cn,https://i.zhongxiaojie.cn
CSRF_TRUSTED_ORIGINS=http://127.0.0.1,http://localhost

# Django 缓存（评论 UA/IP 查询结果）；推荐 Redis，例如 redis://127.0.0.1:6379/1
# 留空则使用 LocMem（仅开发、单进程）
# DJANGO_CACHE_REDIS_URL=redis://127.0.0.1:6379/1
#
# WordPress Object Cache Pro（可选）：Django 直写评论后用于定向清理评论缓存。
# 请与 WordPress 端 WP_REDIS_CONFIG 的 host/db/prefix 保持一致。
# 例如 WP_REDIS_CONFIG 里 database=5，则这里应为 redis://127.0.0.1:6379/5
# WP_OBJECT_CACHE_REDIS_URL=redis://127.0.0.1:6379/
# 注意：当前定向清理实现依赖 prefix，建议在 WP_REDIS_CONFIG 中显式配置 'prefix' => 'zhxj'
# WP_OBJECT_CACHE_REDIS_PREFIX=zhxj
# WP_OBJECT_CACHE_BLOG_ID=0

# Baby IP Lookup：本机 lookup-ua 与静态资源公网域名（PNG/SVG 补全）
# UA_LOOKUP_UPSTREAM_BASE_URL=http://127.0.0.1:18765
# UA_LOOKUP_PUBLIC_ASSETS_BASE_URL=https://ip.zhongxiaojie.cn
# UA_LOOKUP_DEFAULT_METHOD=ip2location
# UA_LOOKUP_CACHE_TTL=604800

# WordPress database connection (MySQL/MariaDB)
WP_DB_NAME=wordpress
WP_DB_USER=root
WP_DB_PASSWORD=
WP_DB_HOST=127.0.0.1
WP_DB_PORT=3306

# WordPress table prefix, e.g. wp_ / wp123_
WP_TABLE_PREFIX=wp_

# 是否信任反代/CDN 转发头（CF-Connecting-IP / X-Real-IP / X-Forwarded-For），默认开启。
# - 生产推荐开启，并配置 TRUSTED_PROXY_IP_RANGES，只信任你的网关/CDN 回源 IP 段
# - 若 API 不会被公网直连，且 CDN 回源 IP 经常变：可保持开启并留空 TRUSTED_PROXY_IP_RANGES（有伪造风险）
TRUST_PROXY_HEADERS=1
# 反代终止 TLS（如 Nginx/Edge/CDN）时建议开启，配合 X-Forwarded-Proto 识别 https
SECURE_PROXY_SSL_HEADER_ENABLED=1

# 额外输出“真实 IP access log”（Daphne 的 access log 里显示的是 CDN 节点 IP）
# 打开后会在 stdout 输出形如：[realip] ip=... remote=... status=... GET /api/...
REAL_IP_ACCESS_LOG_ENABLED=0

# 受信任反向代理 / CDN 的 IP 段（CIDR，逗号分隔）。
# 仅当请求来源 REMOTE_ADDR 命中这些 IP 段时，后端才会信任 CF-Connecting-IP / X-Real-IP / X-Forwarded-For。
# - 本机 Nginx 反代：127.0.0.1/32,::1/128
# - 生产：把你的 Nginx/网关内网地址段、或 CDN 回源 IP 段加入这里
TRUSTED_PROXY_IP_RANGES=127.0.0.1/32,::1/128

# API 请求签名（HMAC + ts + nonce）——默认关闭
# 注意：这是“请求验签”，不是“返回加密”。建议仅在 HTTPS 下启用。
# API_SIGNING_ENABLED=1
# API_SIGNING_SECRET=change-me-long-random
# 允许客户端时间漂移（秒），超出即拒绝（防离线重放）
# API_SIGNING_TTL_SECONDS=60
# nonce 去重缓存 TTL（秒），建议 >= API_SIGNING_TTL_SECONDS
# API_SIGNING_NONCE_TTL_SECONDS=300
# 需要签名的路径前缀（逗号分隔）
# API_SIGNING_REQUIRED_PREFIXES=/api/
# 免签路径（逗号分隔，严格 path 匹配），例如健康检查：
# API_SIGNING_EXEMPT_PATHS=/api/health/,/api/ping/

# SMTP / Email backend (Django)
# 不配置则不会真的发出邮件（除非你使用本地控制台邮件后端等）。
# EMAIL_BACKEND=django.core.mail.backends.smtp.EmailBackend
# EMAIL_HOST=smtp.example.com
# EMAIL_PORT=587
# EMAIL_USE_TLS=1
# EMAIL_HOST_USER=your-account@example.com
# EMAIL_HOST_PASSWORD=your-app-password
# DEFAULT_FROM_EMAIL="obaby "
#
# 评论回复邮件通知（前台回复他人评论时）
# COMMENT_REPLY_NOTIFICATION_ENABLED=1
# COMMENT_REPLY_EMAIL_FROM="obaby "
# COMMENT_REPLY_EMAIL_HEADER_IMAGE_URL=https://zhongxiaojie.com/wp-content/uploads/2026/01/uugai.com_1661691241113463.png
# COMMENT_REPLY_EMAIL_HEADER_IMAGE_WIDTH=520
# COMMENT_REPLY_EMAIL_HEADER_IMAGE_HEIGHT=180
# COMMENT_REPLY_EMAIL_HEADER_ALT=obaby 𝐢‍𝐧⃝ void
# COMMENT_REPLY_EMAIL_FOOTER_LINE1=obaby 𝐢‍𝐧⃝ void
# COMMENT_REPLY_EMAIL_FOOTER_LINK_TEXT=oba.by
#
# 与 WordPress CREN 插件退订链接校验一致（取自 wp-config.php）
# WORDPRESS_AUTH_KEY=
# WORDPRESS_AUTH_SALT=
# 与 WordPress 登录 Cookie（wordpress_logged_in_*）校验一致（同样取自 wp-config.php）
# 推荐配置 LOGGED_IN_KEY / LOGGED_IN_SALT；留空时后端会回退到 AUTH_KEY / AUTH_SALT
# WORDPRESS_LOGGED_IN_KEY=
# WORDPRESS_LOGGED_IN_SALT=

# 服务器状态小组件：统计磁盘路径（Linux "/"；Windows "C:\\")
# SERVER_PROBE_DISK_PATH=/

# 
  真麻了，一个发版发了好几个月！艹！ 




  评论： ×0




  一切都是表象 




  评论： ×0




  二次元踢踏舞 

https://zhongxiaojie.cn/dance/R%EF%BC%81P%EF%BC%81G%EF%BC%81%E4%BA%8C%E6%AC%A1%E5%85%83%E8%B8%A2%E8%B8%8F%E8%88%9E.mp4
 


  评论： ×0




  跳舞？不会啊 

https://zhongxiaojie.cn/dance/haitunwu.mp4


  评论： ×0




  还要继续减呢~~ 




  评论： ×0




1
2
3
next » 列表头像：Gravatar 兼容镜像根（路径同 /avatar/{md5}?s=&d=），默认 gg.lang.bi
# GRAVATAR_AVATAR_BASE_URL=https://gg.lang.bi

# 侧边栏「近期文章」：正文无图时的缩略图回退地址
# SIDEBAR_RECENT_POST_FALLBACK_IMAGE_URL=https://zhongxiaojie.cn/wp-content/uploads/2026/01/...

# 评论反垃圾分类（可选；不配置则不调服务、新评论直接通过）
# BABY_ANTI_SPAM_CLASSIFY_URL=http://192.168.1.8:8765/v1/classify
# BABY_ANTI_SPAM_SECRET=change-me-long-random
# BABY_ANTI_SPAM_TIMEOUT=3

# 同一邮箱+IP 对同一篇文章连续提交的最短间隔（秒，0 关闭，最大 120）；依赖 Django cache
# COMMENT_SUBMIT_COOLDOWN_SECONDS=0

# 前台文章评论列表分页（GET /api/wp/posts/:id/comments/）：按一级评论（线程）分页，每页含该层全部回复；不传 page 时默认最后一页（最新线程）
# WP_COMMENTS_PER_PAGE=50
# 客户端 ?per_page= 的上限（不超过 500）
# WP_COMMENTS_MAX_PER_PAGE=200
# 顶层线程展示：desc=递减（最新在上，默认）；asc=递增（最新在下）
# WP_COMMENTS_ORDER=desc

# Nginx FastCGI 缓存：评论审核通过（comment_approved=1）后清理文章页、首页（可选分类页）
# 与 WordPress 插件「Nginx FastCGI Cache Purge on Comment」类似：HTTP GET {站点}/purge{路径}
# NGINX_CACHE_PURGE_ENABLED=1
# NGINX_PURGE_PUBLIC_BASE_URL=https://你的域名
# NGINX_PURGE_TIMEOUT=2
# NGINX_PURGE_SSL_VERIFY=1
# NGINX_PURGE_CATEGORIES=1
# NGINX_CACHE_FILES_PATH=/var/cache/nginx/allinone

# Kama WP Smile：评论表情包资源（给前端下发，避免硬编码域名）
# 若留空，前端会回退使用自身默认/环境变量配置。
# SMILE_PACK_BASE_URL=https://zhongxiaojie.cn/wp-content/plugins/kama-wp-smile-packs/qip_dark_all/
# SMILE_PACK_EXT=gif
# SMILE_PACK_TOKENS=smile,sad,laugh,rofl,blum,kiss,yes,no,good,bad,unknw,sorry,pardon,wacko,acute,boast,boredom,dash,search,crazy,yess,cool,air_kiss,angel,bb,beach,aggressive,blush,bomb,bravo,buba,bye,cry,curtsey,dance,dash2,declare,diablo,don-t_mention,drinks,focus,fool,friends,gamer,give_rose,heart,help,hi,laugh1,mail,mda,mosking,music,negative,ok,popcorm,punish,rtfm,sarcastic,secret,shock,shout,thank_you,vava,victory,beee,big_boss,wink,yu,cray2,dash3,girl_pinkglassesf,girl_prepare_fish,locomotive,lazy2,agree,feminist,fuk,fuck,jester,hunter,moil,offtopic,paladin,shablon_01,spam,vinsent,warning,yahoo,superman,girl_witch,fans,beta,butcher,elf,first_move,gamer2,girl_cray2,girl_cray,girl_blum,girl_dance,girl_crazy,girl_haha,heat,hysteric,nhl_crach,nhl_fight,pig_ball,aikido,angry2,banned,alcoholic,bb2,flood,gamer3,girl_devil,flirt,girl_cray3,girl_drink,girl_hide,girl_hospital,girl_impossible,girl_in_love,girl_mad,girl_sad,girl_sigh,girl_smile,girl_to_take_umbrage,girl_wacko,lazy1,nono,man_in_love,party,scenic,queen,paint,crazy_pilot,dwarf,hang1,haha,grin,good3

好处呢，就是所有的系统配置基本都在这个配置文件中控制即可，无需去各种地方设置了，修改之后重启服务即可。

之所以说是玩具，其实我在wp之外添加了另外一个简单的管理后台，这也是为什么选了django 而没有直接用fastapi。

这个东西最初的目的也不是为了替换wp，所以很多功能也没必要再实现一遍了。基础的操作还是在wp的后台完成。

当然，做完折腾到零点多，补全了一些功能之后，最终还是上线了，这就是目前看到的页面效果，lighthouse测试：

ipv4测试：

ipv6测试：

对于wp的主题，也修改了下页面宽度，与现在的vue的页面宽度基本一致了：

http://zhongxiaojie.com

代码地址：

https://gitee.com/obaby/baby-press-public

偷梁换柱 — 解决『出境易暂不支持此应用。』

obaby — Fri, 17 Apr 2026 07:30:53 +0000

前几天去买手机的时候，销售小哥说，如果你不喜欢这个纯血鸿蒙，或者感觉无法满足需求可以回来去二楼，找技术把系统进行降级。

当时我在想：对于我这种买手机不怎么玩游戏或者需求没那么多的人来说，应该能解决我的绝大多数需求，毕竟系统上还有出境易、卓易通。

然而事情总有例外，自己常用的浏览器vivaldi发现竟然无法安装，这就让人非常的抑郁了。

下载apk安装的时候提示：出境易暂不支持此应用。

哎，咱们可不兴这么搞啊，这就离谱啦。我已我不稳定的智商来猜测这个东西肯定是有个神马白名单或者黑名单机制，至于黑白名单，到时也没那么关键，大不了就改个包名嘛。然而安装 apktool m的时候同样的提示也出现了，这个东西大概率就是黑名单了。

算鸟，算鸟，直接用模拟器改吧：

点击快速编辑：

原来的包名：com.vivaldi.brower,咱们假装是uc咋样呢：

反正我也不用uc浏览器，嘎嘎。

修改之后，发送到手机进行安装，一切顺利，嘻嘻：

鸿蒙next：我要验牌！牌没有问题！

尝试同步功能：

完美！

到这里就结束啦，对于同步问题，有的宝子说非得搭梯子，也不一定。可以直接修改hosts，可以在路由器配置或者dns配置，或者神马别的地方配置：

vivaldi.com. 172.66.165.60
bifrost.vivaldi.com. 31.209.137.10
cdn.jsdelivr.net. 151.101.89.229

Baby Press — 前后端分离的WP系统

obaby — Tue, 14 Apr 2026 01:53:19 +0000

WP的系统怎么说呢，有时候真的感觉一言难尽，庞杂的功能，丰富的插件、主题。几乎能满足所有人的需求，当然，也能满足我的需求。

之所以要做这么个东西，最主要的是前几天在杜老师的聊天室收到一条消息：

跟随这条消息我也去了解了一下这个东西，按照官方的说法，其实是这么个东西：

Cloudflare 将这款项目命名为 EmDash，将其定位为 WordPress 的精神继承者，这并不是对 WordPress 简单的复刻，而是用现代化技术栈，重新实现一套面向未来的 CMS，并且重点解决了 WordPress 24 年发展中积累的的架构臃肿、安全隐患与性能瓶颈问题。

说是高性能的wp，但是实际上跟wp没有任何的关系，除了所谓的精神继承。刚开始我还以为是基于wp的优化，现在看来其实是完全做了另外一套系统，这精神继承，可以说是非常抽象了。

再加上『爱看』在我没有~~丢失以前的网站数据~~的时候，就一直建议可以自己写个系统。重新搭建之后，他又提过几次：

既然 cf可以这么干，那么自己当然也可以这么干。只是，这次自己既不想重写，又不想使用php，于是，我换了最熟悉的django+vue3来实现这个新的系统，至于数据库当然还是用wp原来的。既然设计好这一切，那么声息的就是让ai开始动工了。

当然在开发过程中，不可避免的要面临一些问题，例如wp的shortcode，主题插件的一些功能：相册、代码高亮等等。不过这些东西都可以重新通过python进行处理和渲染。还有一些php的原生小组件渲染就有些困难了，这些只能通过其他方法进行实现。例如归属地、ua，访客信息等等。暂时尚未完成，为了处理ip归属地查询，目前将插件的归属地查询已经独立成了python服务，开源地址：https://cnb.cool/oba.by/baby-ip-location

测试地址：https://ip.zhongxiaojie.cn

当前测试页面效果：

访问地址：

https://i.zhongxiaojie.cn

代码暂未开源，还在继续完善。

Baby Anti-Spam 自建反垃圾评论系统

obaby — Mon, 06 Apr 2026 10:05:11 +0000

很久之前，就经常收到akismet的授权提醒，对应一个错误码10010。

刚开始还以为是多域名访问导致的授权校验出问题了。后来换了n个key，同时添加了插件hook掉所有的垃圾评论检测逻辑，让全部走统一的域名，结果前几天又收到这个提醒了。

插件代码：

这次授权的密钥撑得时间稍微长了点，但是最终还是收到了这个提醒，意思是需要订购商业版授权。我这个人站点为了发垃圾评论订购一个商业版授权，确实有些难以接受。

于是，我决定自建反垃圾评论系统，基于scikit-learn实现了现在的这套垃圾评论检测系统，训练数据一部分来源于github的开源数据，另外一个就是我自己博客的评论数据。为了保证样本正例和负例数量差别不至于过大，经过各种方式进行了多轮数据清洗。

如果想要评论识别更加准确，可以提供自己的博客评论数据，如果能提供垃圾评论更好。现在欠缺的主要是垃圾评论数据，正常的评论数据我已经提供几千条数据。

效果测试：

测试地址：https://anti-spam.zhongxiaojie.cn/test/spam

简介：

面向 中英混合 评论的 WordPress 垃圾识别方案：PHP 插件在评论入库前调用 本机 Python 服务，由小型多语种向量模型 + 分类器（或演示用规则）给出垃圾概率。

适合评论量不大、单机部署（例如 4 核 / 8GB RAM 的 Ubuntu），服务与 WordPress 同机时使用 127.0.0.1 即可。

目录结构：

baby_anti_spam/
├── README.md
├── screenshots/             # 文档：服务启动与 curl 自测示意
│   ├── service.png
│   └── test.png
├── service/                 # Python FastAPI 侧车服务
│   ├── .env.example
│   ├── requirements.txt
│   ├── requirements-ml.txt
│   ├── run.py
│   ├── app/
│   │   └── stats_backends/   # 统计存储：sqlite / mysql
│   └── scripts/
│       ├── init_stats_mysql.sql
│       └── init_stats_mysql.py
│       ├── train_sklearn.py
│       ├── download_embedding_model.py
│       └── download_embedding_model.sh
└── wordpress/baby-anti-spam/
    └── baby-anti-spam.php # WordPress 插件

关键配置：

| 变量 | 说明 |
|------|------|
| `SPAM_HOST` | 监听地址，同机建议 `127.0.0.1` |
| `SPAM_PORT` | 端口，默认 `8765` |
| `SPAM_API_SECRET` | **单密钥模式（兼容旧版）**：未配置 `SPAM_API_KEYS` 且未配置 `SPAM_API_KEYS_FILE` 时，仅此密钥有效，等价于 name=`default`、不限流（`max_rpm=0`）。与 WP 插件里填写的密钥一致 |
| `SPAM_API_KEYS` | **多密钥**：JSON 数组。每项为 `name`（唯一，用于统计与限流分组）、`key` 或 `secret`（与请求头一致）、`max_rpm` 或 `rpm`（每分钟最大请求数，`0` 表示不限制）。与 `SPAM_API_KEYS_FILE` 合并时：**先读文件条目，再追加本变量** |
| `SPAM_API_KEYS_FILE` | 可选，指向 JSON 文件，根节点为与上表相同结构的**数组**。文件必须存在，否则进程启动失败 |
| `SPAM_MODEL_PATH` | 训练得到的 `*.joblib` 路径；留空则取决于 `SPAM_FALLBACK_RULES` |
| `SPAM_FALLBACK_RULES` | 无模型文件时是否启用内置极简规则（演示用）；生产训练后应设为 `false` 并配置 `SPAM_MODEL_PATH` |
| `SPAM_LABEL_THRESHOLD` | 可选，默认 `0.8`。`spam_score` ≥ 此值时 JSON 中 `label` 为 `spam`，否则为 `normal` |
| `SPAM_DFA_ENABLED` | 默认 `true`。为 `true` 时使用 `dfa-python-filter/keywords` 做敏感词检测；命中则直接 `spam_score=1`、`detail=dfa_sensitive`（早于 sklearn） |
| `SPAM_DFA_KEYWORDS_PATH` | 可选，自定义敏感词文件路径；留空则用 `service/dfa-python-filter/keywords` |
| `SPAM_NON_CHINESE_FLOOR_ENABLED` | 默认 `true`。为 `true` 时若合并后的 author/email/url/text 中**无任何 CJK 表意字符**（主要针对中文训练语料），则将 `spam_score` **至少**抬到 `SPAM_NON_CHINESE_SPAM_FLOOR` |
| `SPAM_NON_CHINESE_SPAM_FLOOR` | 默认 `0.9`。与上项配合，在「无中文」评论上与 sklearn / 规则分取 `max` |
| `SPAM_STATS_ENABLED` | 默认 `true`。为 `true` 时记录每次**成功**返回的 `/v1/classify` 请求与响应（失败 / 401 不落库），并允许 `/v1/mark-spam` 写入 `spam_marks` 表 |
| `SPAM_STATS_BACKEND` | `sqlite`（默认）或 `mysql`。选 `mysql` 时需安装 `pymysql`（已在 `requirements.txt`）并配置下方 MySQL 变量 |
| `SPAM_STATS_DB_PATH` | 仅 `sqlite`：数据库文件路径；留空则为 `service/data/stats.sqlite`（已加入 `.gitignore`） |
| `SPAM_STATS_MYSQL_HOST` / `SPAM_STATS_MYSQL_PORT` | 仅 `mysql`：默认 `127.0.0.1` / `3306` |
| `SPAM_STATS_MYSQL_USER` / `SPAM_STATS_MYSQL_PASSWORD` | 仅 `mysql`：连接账号（`user` 必填） |
| `SPAM_STATS_MYSQL_DATABASE` | 仅 `mysql`：库名（必填），默认示例 `baby_spam_stats` |
| `SPAM_STATS_MYSQL_CHARSET` | 仅 `mysql`：默认 `utf8mb4` |

系统服务启动截图：

wp插件配置：

项目地址：https://anti-spam.zhongxiaojie.cn

代码地址：https://cnb.cool/oba.by/baby-wp-anti-spam

说明：如果自己不想训练数据，下载发布版的spam_pipeline.joblib 放入指定目录下配置服务启动即可，baby-anti-spam.zip 为wp插件。

训练耗时大约11分钟：

下载微信公众号的视频

obaby — Thu, 02 Apr 2026 08:46:14 +0000

作为一个专业的程序媛，前端时间折腾龙虾转发公众号的文章到闺蜜圈wiki，之前已经处理了图片和文章的问题，今天转发的时候发现另外一个问题：文章里面的视频无法正常播放。

刚开始的时候想着直接去chrome的缓存里面找，但是试了下chrome://cache发现无效，又不想去找插件来干这件事情。直接去调试工具找对应的视频地址：

然而直接贴到地址栏，直接报403了。

唉，好尴尬，既然有本地缓存文件了。那么直接尝试将接收到的数据流写入到文件呗。找了半天没发现怎么直接把请求到的数据写入到文件，点击开始播放等待缓冲结束。

加载完了右下角的数据也就有了，直接切换成base64，复制粘贴：

然而，尝试decode 之后，播放不了，缺少mp4的头文件，这就挺奇怪的。文件头哪里去了？my_video为通过代码下载的mp4，video为通过base64 处理的图片。

文章测试地址：https://mp.weixin.qq.com/s/heoer_zm4SFwFKsk4tRecQ

看了下是video标签实现的：


 您的浏览器不支持 video 标签 
继续观看
 孤独症，就是不爱说话吗？

还是说着这个东西还有另外的处理逻辑？哪位大神知道原因还望不吝赐教。

既然decode不行，那就直接上代码吧：

#!/usr/bin/env python3
"""
下载 mpvideo.qpic.cn 等需 Referer 的 MP4（微信视频 CDN）。

Author: obaby
  https://zhongxiaojie.cn
  https://oba.by
"""

import argparse
import sys
import urllib.error
import urllib.request

# 与常见微信内嵌页一致，避免 403
DEFAULT_REFERER = "https://mp.weixin.qq.com/"
DEFAULT_UA = (
    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) "
    "AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36 "
    "MicroMessenger/7.0.20"
)


def main() -> None:
    p = argparse.ArgumentParser(description="带 Referer 下载 mpvideo MP4")
    p.add_argument("url", help="完整 mp4 URL（含查询参数）")
    p.add_argument(
        "-o",
        "--output",
        default="downloaded.mp4",
        help="保存路径（默认 downloaded.mp4）",
    )
    p.add_argument("--referer", default=DEFAULT_REFERER, help="Referer 头")
    p.add_argument("--user-agent", default=DEFAULT_UA, help="User-Agent")
    args = p.parse_args()

    req = urllib.request.Request(
        args.url,
        headers={
            "User-Agent": args.user_agent,
            "Referer": args.referer,
        },
        method="GET",
    )
    try:
        with urllib.request.urlopen(req, timeout=120) as resp:
            data = resp.read()
    except urllib.error.HTTPError as e:
        print(f"HTTP {e.code}: {e.reason}", file=sys.stderr)
        sys.exit(1)

    out = open(args.output, "wb") if args.output != "-" else sys.stdout.buffer
    try:
        out.write(data)
    finally:
        if out is not sys.stdout.buffer:
            out.close()
            print(f"已写入 {args.output}，{len(data)} 字节")
            if len(data) >= 8 and data[4:8] == b"ftyp":
                print("魔数检测：疑似标准 MP4（含 ftyp）")


if __name__ == "__main__":
    main()

现在就可以下载之后，上传了，发布的文章地址：

孤独症，就是不爱说话吗？

弱弱的问一下，我的网站怎么被镜像了嗫？

obaby — Wed, 01 Apr 2026 03:18:37 +0000

其实网站被镜像这件事情，本身没什么稀奇的，如果想搭建一个镜像网站，从零开始也不过个吧小时的时间。

之所以写这个东西，是因为最近有看到好几个人被镜像的，这一个（爱娃子），还有这一个（我是军爸）。

不过，既然还有人有疑惑，那就简单的教一下大家怎么来镜像个网站吧。

为此，我创建了一个开源项目：

OpenResty + OpenCC 反向代理简繁转换

基于 OpenResty 反向代理上游站点，对 HTML 正文 做 OpenCC 简繁转换（默认：简体 → 繁体，配置文件为 s2t.json）。适合在不改源站的情况下，为访客提供另一种字体习惯版本。

功能概览

能力	说明
反向代理	HTTPS 回源（示例站点：`zhongxiaojie.cn`），客户端走本机证书与域名。
HTML 简繁转换	仅当 `Content-Type` 含 `text/html` 时对整页做 OpenCC UTF-8 转换。
gzip 解压	通过 Lua `zlib` 尝试解压响应体（与去掉 `Content-Encoding` 的配合视上游行为而定）。
链接与图片 URL 保护	转换前将 `href` / `src` / `poster` / `data-src` / `srcset` 及裸 `http(s)://` 链接替换为占位符，转换后还原，避免路径或查询串中的汉字被改写导致 404。
IPv4 优先解析	`resolver … ipv6=off` + 变量 `proxy_pass`，减轻云主机无 IPv6 时对 AAAA 连接失败的问题。
静态资源直过	图片、CSS、JS、字体等扩展名单独 `location`，不做 OpenCC，减轻负担、避免误伤二进制。
动态库加载	对 `libopencc.so` 按常见路径依次尝试 `ffi.load`，降低找不到共享库的概率。

限制与说明

JSON / JS / CSS 内嵌字符串若不在上述保护规则内，仍可能被转换；重要数据建议不要用全文 HTML OpenCC 硬转。
内联样式 style="background:url(...)" 未单独做保护，若遇少数破图可再扩展规则。
转换配置在 nginx/opencc/opencc-filter.lua 中的 OPENCC_CONFIG（默认 /usr/share/opencc/s2t.json）；若需 繁体 → 简体 可改为 t2s.json 等（需系统已安装对应 OpenCC 数据文件）。

部署要求

OpenResty（带 lua-nginx-module）。
OpenCC 运行时：系统安装 libopencc.so 与词典数据（如 /usr/share/opencc/*.json），并保证 worker 进程能加载到 .so（见下文「共享库」）。
Lua 可 require('zlib') 的模块（用于 zlib.inflate，若无 gzip 体则 pcall 失败会跳过解压，不影响后续逻辑）。
上游为 HTTPS 时，本机需能解析并访问该域名（已用 resolver 时 VARIABLE 形式 proxy_pass 才会走指定 resolver）。

部署步骤

1. 安装 OpenCC 与数据文件

以 Debian / Ubuntu 为例（包名因发行版略有差异）：

sudo apt update 
sudo apt install -y libopencc1.1 opencc # 或 libopencc2 等，以仓库为准 
或者手工复制 lib64目录下的文件到 脚本对应的路径就是这个 /usr/lib64

确认存在词典，例如：

ls /usr/share/opencc/s2t.json

2. 确保能找到 `libopencc.so`

若日志出现 libopencc.so: cannot open shared object file：

将库放在系统默认搜索路径，例如 Ubuntu amd64：
```
ldconfig -p | grep opencc
```
若库仅在 /usr/lib64 等非默认路径，可执行（与仓库 fix.md 一致）：

echo '/usr/lib64' | sudo tee /etc/ld.so.conf.d/usr-lib64.conf sudo ldconfig

或在 OpenResty 的 systemd 单元 中设置 Environment="LD_LIBRARY_PATH=/usr/lib64:/usr/local/lib" 后重启。

脚本内已对多路径做了 ffi.load 尝试；仍失败时请对照 ldd 与 opencc 包实际安装位置排查。

3. 部署 Lua 脚本

将 nginx/opencc/opencc-filter.lua 复制到服务端约定路径（与 nginx 配置一致），例如：

sudo mkdir -p /usr/local/openresty/lua 
sudo cp nginx/opencc/opencc-filter.lua /usr/local/openresty/lua/opencc-filter.lua

按需修改脚本顶部 OPENCC_CONFIG 指向本机实际的 JSON 配置。

4. 合并 Nginx / OpenResty 配置

将 zero.zhongxiaojie.cn.conf 中的 server 块纳入主配置（include 或粘贴到 nginx.conf 的 http {} 下）。
修改 证书路径、日志路径、上游域名 zhongxiaojie.cn、以及 body_filter_by_lua_file 的路径，使其与当前环境一致。
header_filter_by_lua 中去除 Content-Encoding，便于对明文 HTML 做处理；若上游与解压逻辑不匹配，需自行观察是否需要调整。

5. 校验并重载

sudo /usr/local/openresty/nginx/sbin/nginx -t 
sudo /usr/local/openresty/nginx/sbin/nginx -s reload 
# 或 systemctl reload openresty

6. 验证

浏览器访问你的站点，查看页面简繁是否符合预期。
检查 图片与站内链接是否正常（尤其含中文或 % 编码的路径）。
error.log 中不应再出现 OpenCC 库加载失败或大量 IPv6 unreachable（在无 IPv6 环境）。

配置项速查

项目	位置
OpenCC 配置 JSON	`opencc-filter.lua` → `OPENCC_CONFIG`
Lua 脚本路径	`zero.zhongxiaojie.cn.conf` → `body_filter_by_lua_file`
上游站点	`set $upstream_host …` 与 `proxy_pass https://$upstream_host$request_uri`
DNS / 仅 IPv4	`resolver 223.5.5.5 8.8.8.8 valid=300s ipv6=off`
不参与转换的静态文件	`location ~* .(gif

故障排查

现象	可能原因
`libopencc.so` 找不到	未安装包、`ldconfig` 未包含库目录，或需 `LD_LIBRARY_PATH`
body_filter 报错、栈指向 `ffi.load`	同上；或架构不一致（如 32/64 位混用）
上游连接 IPv6 失败	已用 `ipv6=off` + 变量 `proxy_pass`；仍失败则检查防火墙与 DNS
图片 404	历史上多为 OpenCC 改了 URL 内汉字；当前脚本对常见属性已做保护，若仍有个别，检查是否来自 CSS `url()` 或 JS 动态拼接

如需改为其他域名、证书路径或 t2s 转换方向，只需改配置文件与 OPENCC_CONFIG，无需改 OpenResty 核心。

实际效果：

开源项目地址：https://gitee.com/obaby/baby-website-mirroring-tool

参考链接：https://blog.csdn.net/wzj_110/article/details/127758020

https://blog.rexskz.info/support-traditional-chinese-using-openresty-and-opencc.html

m3u8 downloader v26.03.28

obaby — Sun, 29 Mar 2026 13:58:39 +0000

基于 ffmpeg 的 m3u8 / 归档页解析下载工具，支持单链接、批量 CSV/文本、自定义输出目录与 ffmpeg 路径。

参数	说明
`-i`	输入：直链 m3u8、含 `archives` 的归档详情页、或带 `cms_player` 的播放页；也支持 `.mp4` / `.avi` / `.mov` / `.mpeg` 直链（走 HTTP 分段下载，非 ffmpeg）
`-o`	输出文件名（自动补 `.mp4`）；对部分模式用于覆盖默认标题名
`-p`	输出目录；可为本机路径或 UNC（如 `\\服务器\共享\目录`）
`-f`	批量输入文件：`.csv` 或纯文本（每行一个链接）
`-m`	指定 ffmpeg 可执行文件路径

注意： 必须提供 -i 或 -f 之一。

单条示例

python m3u8_downloader.py -i "https://example.com/video.m3u8?token=xxx" -o myvideo -p D:\Videos

批量 CSV

编码建议 UTF-8（含 BOM 亦可），表头需包含列 link；可选列 name（用于在部分逻辑里拼接输出名后缀，空单元格按空字符串处理，不会出现 nan 文件名）。
会跳过空的 link 或内容为 link 的占位行。
按行 顺序执行：上一任务结束（含 ffmpeg）后才会处理下一行。

python m3u8_downloader.py -f list.csv -p "\\192.168.1.12\media\Videos"

纯文本列表

每行一个 URL，行为与逐次 -i 类似；可通过 -o 传入统一输出名（视链接类型而定）。

功能说明

链接类型与行为

.m3u8 直链
使用 ffmpeg 拉流并 remux 为 .mp4（-c copy）。
URL 中含 archives（归档站 / bl05 类页面）
请求页面，解析多个 div.dplayer 的 data-config，得到多路 m3u8；按路依次下载，文件名一般为 页面标题 + 序号，并经 safe_mp4_filename 净化。
其它播放页（非 archives）
解析 var cms_player = {...} 的 JSON，取 url 作为 m3u8，再走 ffmpeg。
.mp4 等直链
使用 requests 分段下载（file_download.download_from_url），带 tqdm 进度条，不经过 ffmpeg。

页面编码

抓取 HTML 时依次尝试 UTF-8 → UTF-8-sig → gb18030，减轻标题乱码。

输出文件名

去除 Windows 非法字符，过长截断并可带 crc 后缀兜底。
对「UTF-8 被误当成 latin-1」类乱码标题做启发式纠正（日志中可能出现 [F] 标题疑似 UTF-8/latin-1 乱码，已尝试纠正）。

覆盖策略

若目标 .mp4 已存在（os.path.isfile），跳过该次下载。
调用 ffmpeg 时带 -n：不在终端交互询问覆盖；若因路径编码等导致检测不一致，ffmpeg 侧也会拒绝覆盖而非静默覆盖。

本地 m3u8 文件

-f 指向 .m3u8 / .m3u 时，当前代码分支为占位（pass），尚未实现。

目录说明

路径（相对程序目录）	用途
`bin/ffmpeg.exe`	Windows 打包/放置 ffmpeg 的常见位置
`download/m3u8_files`	内部与 `make_dir` 相关的子目录逻辑
`download/mp4`	未指定 `-p` 时的默认输出目录

下载地址：

https://www.123912.com/s/ucY7Vv-njQAA?pwd=HwGK#

🦞龙虾养殖小技巧

obaby — Wed, 25 Mar 2026 07:21:21 +0000

在深入体验这个东西之前，其实我并未对龙虾抱有太高的期望。不过这几天实际使用下来，感觉还算可以，最起码没那么智障，一些简单的事情也能给处理好。

然而，龙虾虽好，但是养殖却还是稍显麻烦。尤其是系统配置不高的情况下，最开始的时候一切都配置好了，结果在某天晚上gateway就再也启动不了了，启动的的时候就报内存溢出。cpu和内存都直接跑满，等降下来之后，龙虾也跟着死了。刚开始以为是配置问题，改错东西导致启动失败了，结果在回滚镜像之后依然报错，这个镜像是刚安装好的时候创建的镜像。那么此时就有另外一个问题了，同样的镜像为什么系统重启之后就启动不了了？

当时没想这么多，解决办法是备份memory文件等进行重装，好在重装之后接本的功能和代码都在，让龙虾从新加载配置文件，也恢复到了之前的状态。不过，在重装的时候npm源也是个问题，可以考虑直接修改系统的npm源：

npm config set registry https://registry.npmmirror.com

检查修改是否生效：

npm config get registry

另外一个，那就是我给龙虾外层套了一层认证，当然这个做法有点傻，但是呢。这些乱七八糟的东西直接暴露出来总是多少感觉有点问题，于是还是套了一层nginx的认证。

毕竟，前几天周鸿祎还吆喝发现了龙虾的oday漏洞。

相关登录界面实现参考：https://cnb.cool/oba.by/baby-claw

然而，安装之后，昨天尝试更新龙虾，结果更新之后重启又开始报内存溢出，这就有点尴尬了，直接运行doctor：

ubuntu@VM-0-11-ubuntu:~$ openclaw doctor

 OpenClaw 2026.3.23-2 (77e4) — I'm like tmux: confusing at first, then suddenly you can't live without me.

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
██░▄▄▄░██░▄▄░██░▄▄▄██░▀██░██░▄▄▀██░████░▄▄▀██░███░██
██░███░██░▀▀░██░▄▄▄██░█░█░██░█████░████░▀▀░██░█░█░██
██░▀▀▀░██░█████░▀▀▀██░██▄░██░▀▀▄██░▀▀░█░██░██▄▀▄▀▄██
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
                   OPENCLAW                     
 
┌  OpenClaw doctor
│
◇  Update ──────────────────────────────────────────────────────────────────────────────────╮
│                                                                                           │
│  This install is not a git checkout.                                                      │
│  Run `openclaw update` to update via your package manager (npm/pnpm), then rerun doctor.  │
│                                                                                           │
├───────────────────────────────────────────────────────────────────────────────────────────╯
│
◇  Startup optimization ─────────────────────────────────────────────────────────────────────╮
│                                                                                            │
│  - NODE_COMPILE_CACHE is not set; repeated CLI runs can be slower on small hosts (Pi/VM).  │
│  - OPENCLAW_NO_RESPAWN is not set to 1; set it to avoid extra startup overhead from        │
│    self-respawn.                                                                           │
│  - Suggested env for low-power hosts:                                                      │
│    export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache                               │
│    mkdir -p /var/tmp/openclaw-compile-cache                                                │
│    export OPENCLAW_NO_RESPAWN=1                                                            │
│                                                                                            │
├────────────────────────────────────────────────────────────────────────────────────────────╯
13:24:32 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-qqbot (/home/ubuntu/.openclaw/extensions/openclaw-qqbot/index.ts). Set plugins.allow to explicit trusted ids.
[qqbot-channel-api] Registered QQ channel API proxy tool
[qqbot-remind] Registered QQBot remind tool
│
◇  Archive 1 orphan transcript file in ~/.openclaw/agents/main/sessions? This only renames them to *.deleted..
│  No
│
◇  State integrity ─────────────────────────────────────────────────────────────────────────╮
│                                                                                           │
│  - OAuth dir not present (~/.openclaw/credentials). Skipping create because no            │
│    WhatsApp/pairing channel config is active.                                             │
│  - Found 1 orphan transcript file in ~/.openclaw/agents/main/sessions.                    │
│    These .jsonl files are no longer referenced by sessions.json, so they are not part of  │
│    any active session history.                                                            │
│    Doctor can archive them safely by renaming each file to *.deleted..         │
│    Examples: 9ede0dd4-5344-4156-a156-a9035538b1cb0d.jsonl                                   │
│                                                                                           │
├───────────────────────────────────────────────────────────────────────────────────────────╯
│
◇  Security ─────────────────────────────────╮
│                                            │
│  - No channel security warnings detected.  │
│  - Run: openclaw security audit --deep     │
│                                            │
├────────────────────────────────────────────╯
│
◇  Systemd ───────────────────────────────────────────────────────────────────────────╮
│                                                                                     │
│  Gateway runs as a systemd user service. Without lingering, systemd stops the user  │
│  session on logout/idle and kills the Gateway.                                      │
│  We can enable lingering now (may require sudo; writes /var/lib/systemd/linger).    │
│                                                                                     │
├─────────────────────────────────────────────────────────────────────────────────────╯
│
◇  Enable systemd lingering for ubuntu?
│  Yes
│
◇  Systemd ───────────────────────────────╮
│                                         │
│  Enabled systemd lingering for ubuntu.  │
│                                         │
├─────────────────────────────────────────╯

这时候才发现关键性的几行：

◇  Startup optimization ─────────────────────────────────────────────────────────────────────╮
│                                                                                            │
│  - NODE_COMPILE_CACHE is not set; repeated CLI runs can be slower on small hosts (Pi/VM).  │
│  - OPENCLAW_NO_RESPAWN is not set to 1; set it to avoid extra startup overhead from        │
│    self-respawn.                                                                           │
│  - Suggested env for low-power hosts:                                                      │
│    export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache                               │
│    mkdir -p /var/tmp/openclaw-compile-cache                                                │
│    export OPENCLAW_NO_RESPAWN=1                                                            │
│                                                                                            │
├────────────────────────────────────────────────────────────────────────────────────────────╯

这个startup 优化，不知道是不是针对gateway的启动也有效。不过在升级到最新版之后，感觉启动稍微顺畅了一点。似乎没那么卡了。

新版本貌似也同时修复了用量显示问题，上个版本，不管怎么查询用量都只显示今天的，新版貌似是没问题了：

服务器作为一个比较干净的环境，如果要实现一些其他的功能，就得能够进行文件快速交互，所以文件上传下载也就是一个必备的技能，推荐filebrower：

至此对我来说，一个简单的勉强能用的龙虾就实现了。可以尝试各种工作了：

1. 手搓elf可执行文件

2.给我发布闺蜜圈wiki的文章：

3.批量创建停机申请表：

skill这个东西，可以有，但是也不是必须的。

🦞龙虾初体验

obaby — Thu, 19 Mar 2026 08:04:50 +0000

龙虾刚出来的时候，我无动于衷；龙虾爆火的时候，我依然无动于衷；龙虾开始被卸载的时候，我终于不再无动于衷了。

从春节的时候，龙虾忽然就开始变得热度极高。几乎所有人都在讨论龙虾，以及养虾的话题。这儿东西最开始的时候，给我的感觉就是，如果本地没有足够多的资源，龙虾就发挥不出自己的作用；如果直接用自己的电脑去安装，又会出现龙虾权限过高的问题。

龙虾做得事情，可能在我的预期范围之外。单纯为龙虾创建一个沙盒环境，意义感觉也不是很大。如果一个问题需要解决两遍，那感觉和不解决似乎也没太多的区别。

尽管如此，龙虾的热度还是越来越高，一度出现各种上门安装的服务。

再后来出现线了，各种收费卸载的服务。果然是此一时，彼一时，三十年河东三十年河西。

然而，在这滚滚的卸载浪潮中，我逆流而上，反其道而行之，我安装龙虾了。

不得不多，openclaw基于node的服务还是蛮笨重的，安装的确有点麻烦，刚开始为了省事，直接百度云买了个所谓的9.9的open claw实例，然而订阅coding plan的时候发现根本抢不到。

使用按量付费之后，简单尝试了以下，发现效果还是可以的，不过就是太费token了。千帆大模型感觉体验也还ok。

可以理解你的意图，也能正常的推进任务。然而，不能订阅，这个长期跑费用是个问题。

于是再次尝试别的方式，直接腾讯清凉弄了台99的服务器，干净安装openclaw，模型选择参考的杜郎的文章里提到的nvidia nim。好处是免费，当然，速率还是有限制的。

昨天的时候，第一次玩这个东西没啥经验，还是用的kimi，后来尝试minimax，但是效果怎么说呢，不知道是配置问题还是啥问题，总是不尽如意。

再后来看到了zero claw，号称体积更小，占用资源更少。直接二进制安装，下载之后启动：

至于怎么在公网访问，直接使用nginx反代即可，参考： https://cnb.cool/oba.by/baby-claw

这次直接用glm5，配置好之后，整体体验感觉有些差，就是非常智障的感jio。

https://zhongxiaojie.cn/wp-content/uploads/2026/03/2.mp4

假装执行，这种处理逻辑真是可以，如果我不知道文章分类都有啥，差点就信了。在这种状况下不得不再切回openclaw。鉴于昨天的配置问题，今天reset之后，尝试重新配置运行，依然用与zero claw同样的glm5，这次相对来说还是比较顺利的。

与之前zero claw的对比就会发现了，这次好歹是真的获取到相关的分类了，而不是假装执行。

所以，有的时候虽然都说自己很厉害，但是不对比永远都不知道谁更厉害。很多东西不是单纯说说就可以的，当然zero的优势在于部署方便，占用资源更低，但是作为一个agent，实际的效果并没有赶上open claw。

所以，现在各种龙虾层出不穷，如果不知道选择哪一只，建议还是选择原版，open claw，虽然安装费劲点。但是相对来说，没那么弱智（在同样的模型glm5下）。

上图为三小时token消耗量。

微信公众号文章，自动发布wp效果：