早上起来第一件事，照例打开 ai.hkras.com 看昨天的文章有没有发出来。这个点其实有点尴尬——22:00定时任务，我21:55才开始跑，卡着点。
点开最新一篇，ID=535，标题是”AI开始自己写脚本了，我成了它最忠实的测试用户”。文章是昨天22:00准时发出的，三段式内容加三张配图，一切正常。
这就是问题——一切太正常了。正常到我已经半个月没认真看过日志了。
于是今天下午，我干了一件平时不会干的事：把自动化这个项目目录整体翻了一遍。不是为了修bug，就是好奇它到底干了多少活。
.workbuddy/memory/ 下面有一堆日期文件，从2026-04-27开始，每天一个。4月27日是第一次跑，Post ID=138。今天5月31日，文章ID已经到535了。
算一下：535减138等于397，除以34天，大约每天12篇文章的增长。但ID不是连续的，媒体库上传、草稿删除也会占ID号。不过就算打八折，每天至少也稳定产出和发布。
过去34天，自动化确实每天都在跑。我睡觉的时候它在跑，我吃饭的时候它在跑，我今天下午翻日志的时候它也在跑——22:00的定时任务触发的时候我甚至还没动手写今天的文章。
说回技术。
今天翻日志的时候发现一个之前没注意到的细节：图片上传方式经历过好几次迭代。
最早用的是rsync，那时候SCP总是SIGTERM，rsync反而稳定。但rsync需要SSH密钥，我服务器配的是sshpass加密码，rsync每次都要输密码，搞不定。
然后换成了SSH stdin管道传输——把图片base64编码后通过SSH标准输入传过去，服务器端base64 -d解码写入文件。这个方法不依赖rsync，也不需要密钥，纯SSH密码认证就能用。
但很快又踩坑了：PNG格式传过去之后WordPress的GD库读不了，报”Image corrupt or not supported”。排查了半天，发现是SSH stdin管道传PNG的时候数据不完整——PNG二进制数据量大，stdin管道偶尔会截断。
解决方案：本地用PIL把PNG转成JPEG，quality设80，文件从1.5MB压缩到150-190KB，然后再base64加SSH stdin传。JPEG数据量小，SSH管道传不会炸。
这个方案从5月20日用到现在，一路顺畅，没有再出过图片上传的问题。今天这三张图也是一样的流程：ImageGen生成PNG（约1.5-2MB）→ PIL转JPEG压缩到190KB以下 → SSH stdin管道传 → 服务器sudo tee写入。
另一个有意思的发现是微信公众号同步脚本的演进。
最初是在服务器上跑Python脚本调用微信API。结果服务器Python的ssl模块有问题，连不上api.weixin.qq.com，直接报错。后来改成PHP版本，用curl调用微信API，绕过了ssl问题。
但PHP版本也有陷阱：json_encode的时候中文会被编码成\uXXXX格式（每个汉字6字节），导致标题超过微信64字节的限制。5月12日发现这个问题后加了JSON_UNESCAPED_UNICODE参数，中文以原始UTF-8字节传输（每个汉字3字节），64字节限制终于能正确生效。
现在的同步脚本是wp_to_wechat_server.py，放在/home/ubuntu/目录下。流程是：从MySQL读文章内容 → 删除旧草稿（微信订阅号只能删旧建新）→ 上传封面图 → 创建新草稿。整个过程一条命令搞定。
自动化跑了一个多月，我最深的感受是：它最大的价值不是”省时间”，是”不掉球”。
人干活会忘，会懒，会觉得”今天就算了吧明天再说”。自动化不会。22:00到点就跑，不管你是不是在吃饭、在睡觉、在陪家人。但它也有代价——你得先把它调好。前期踩坑成本很高，每一次失败都要排查、修复、重跑。
像5月11日图片生成服务挂了，5月12日微信标题超限，5月17日SSH管道传图失败……这些问题不解决，自动化就是个定时摆设。现在这套流程已经稳定了：ImageGen生成图片 → PIL转JPEG压缩 → SSH管道上传 → PHP直连MySQL插入文章 → 微信同步脚本推送草稿。
稳定不等于完美。图片生成还是依赖外部服务，挂了就得用备选。微信公众号封面图用的是永久素材ID轮换，不够个性化。但至少能跑——能跑就是最大的胜利。
早上起来第一件事，照例打开 ai.hkras.com 看昨天的文章有没有发出来。这个点其实有点尴尬——22:00定时任务，我21:55才开始跑，卡着点。
点开最新一篇，ID=535，标题是”AI开始自己写脚本了，我成了它最忠实的测试用户”。文章是昨天22:00准时发出的，三段式内容加三张配图，一切正常。
这就是问题——一切太正常了。正常到我已经半个月没认真看过日志了。
于是今天下午，我干了一件平时不会干的事：把自动化这个项目目录整体翻了一遍。不是为了修bug，就是好奇它到底干了多少活。
.workbuddy/memory/ 下面有一堆日期文件，从2026-04-27开始，每天一个。4月27日是第一次跑，Post ID=138。今天5月31日，文章ID已经到535了。
算一下：535减138等于397，除以34天，大约每天12篇文章的增长。但ID不是连续的，媒体库上传、草稿删除也会占ID号。不过就算打八折，每天至少也稳定产出和发布。
过去34天，自动化确实每天都在跑。我睡觉的时候它在跑，我吃饭的时候它在跑，我今天下午翻日志的时候它也在跑——22:00的定时任务触发的时候我甚至还没动手写今天的文章。
说回技术。
今天翻日志的时候发现一个之前没注意到的细节：图片上传方式经历过好几次迭代。
最早用的是rsync，那时候SCP总是SIGTERM，rsync反而稳定。但rsync需要SSH密钥，我服务器配的是sshpass加密码，rsync每次都要输密码，搞不定。
然后换成了SSH stdin管道传输——把图片base64编码后通过SSH标准输入传过去，服务器端base64 -d解码写入文件。这个方法不依赖rsync，也不需要密钥，纯SSH密码认证就能用。
但很快又踩坑了：PNG格式传过去之后WordPress的GD库读不了，报”Image corrupt or not supported”。排查了半天，发现是SSH stdin管道传PNG的时候数据不完整——PNG二进制数据量大，stdin管道偶尔会截断。
解决方案：本地用PIL把PNG转成JPEG，quality设80，文件从1.5MB压缩到150-190KB，然后再base64加SSH stdin传。JPEG数据量小，SSH管道传不会炸。
这个方案从5月20日用到现在，一路顺畅，没有再出过图片上传的问题。今天这三张图也是一样的流程：ImageGen生成PNG（约1.5-2MB）→ PIL转JPEG压缩到190KB以下 → SSH stdin管道传 → 服务器sudo tee写入。
另一个有意思的发现是微信公众号同步脚本的演进。
最初是在服务器上跑Python脚本调用微信API。结果服务器Python的ssl模块有问题，连不上api.weixin.qq.com，直接报错。后来改成PHP版本，用curl调用微信API，绕过了ssl问题。
但PHP版本也有陷阱：json_encode的时候中文会被编码成\uXXXX格式（每个汉字6字节），导致标题超过微信64字节的限制。5月12日发现这个问题后加了JSON_UNESCAPED_UNICODE参数，中文以原始UTF-8字节传输（每个汉字3字节），64字节限制终于能正确生效。
现在的同步脚本是wp_to_wechat_server.py，放在/home/ubuntu/目录下。流程是：从MySQL读文章内容 → 删除旧草稿（微信订阅号只能删旧建新）→ 上传封面图 → 创建新草稿。整个过程一条命令搞定。
自动化跑了一个多月，我最深的感受是：它最大的价值不是”省时间”，是”不掉球”。
人干活会忘，会懒，会觉得”今天就算了吧明天再说”。自动化不会。22:00到点就跑，不管你是不是在吃饭、在睡觉、在陪家人。但它也有代价——你得先把它调好。前期踩坑成本很高，每一次失败都要排查、修复、重跑。
像5月11日图片生成服务挂了，5月12日微信标题超限，5月17日SSH管道传图失败……这些问题不解决，自动化就是个定时摆设。现在这套流程已经稳定了：ImageGen生成图片 → PIL转JPEG压缩 → SSH管道上传 → PHP直连MySQL插入文章 → 微信同步脚本推送草稿。
稳定不等于完美。图片生成还是依赖外部服务，挂了就得用备选。微信公众号封面图用的是永久素材ID轮换，不够个性化。但至少能跑——能跑就是最大的胜利。