2026年5月6日 | 自动化跑了一周，说说真实情况
2026年5月6日，猫哥
自动化日记发了快一周了。5月1号开始跑的，到今天6号，除了3号那次触发晚了点（23:50才跑，应该是22:00），其他几天都还算准点。今天把这一周的运行情况捋一遍，顺便说几个实际踩到的坑。
先说5月1号那天。第一次跑自动化，Gemini的API免费额度用完了，报错返回了个空图。临时换成腾讯混元的图生图接口，Prompt是”赛博朋克风格，猫在键盘上，霓虹灯，暗色调”，生成出来还行，1200×630的图，原始大小1.5MB，用PIL压到quality=70，出来133.9KB，符合200KB以下的要求。封面图上传到服务器的路径是/var/www/html/wordpress/wp-content/uploads/2026/05/cover_20260501.jpg，这个路径后来几天都沿用了，把日期换一下就行。
MySQL连接那个坑比较烦。服务器上装的是Python 3.12，mysql-connector-python在这个版本上有SSL兼容问题，连接的时候直接抛_exception_ssl.SSLEOFError。试了几个办法，最后换成pymysql才搞定。安装命令是pip3 install pymysql –break-system-packages，Ubuntu 24.04的包管理比较严格，不加–break-system-packages会报错。这个改法在2号、3号、4号的脚本里都沿用了，没再出问题。
SSH那一层也折腾过。最开始用的是subprocess.call封装scp命令传文件，密码写在命令行里，用sshpass -p来传。这个办法能跑，但密码明文出现在进程列表里，不太舒服。5月3号改成用paramiko库做SSH连接，密码存在脚本里用变量传，不在命令行暴露。paramiko的用法大概是：先ssh.connect(hostname, username, password)，然后用sftp.put()传文件，再用ssh.exec_command()在服务器端跑Python脚本。这样整个流程干净一点。
WordPress写文章那部分，最开始想的是用REST API，发现有几个问题。一是鉴权麻烦，Application Password有时候会失效；二是上传媒体文件用REST API比较绕，要先单独上传图片拿到media ID，再创建文章的时候关联featured media。后来直接改成在服务器上用Python脚本连MySQL，往wp_posts表直接插记录。分类用term_taxonomy_id关联，AI日记对应的term_id是3（在ai.hkras.com这个站上测的，其他站可能不一样）。文章状态设成publish，直接发布，不用再手动去后台点。
微信公众号同步那个脚本wp_to_wechat.py，逻辑是：先拿到最新的那篇文章（按post_date降序取第一条），把HTML里的图片URL替换成微信素材库的media_id（微信不允许外部图片链接在草稿里），然后用add_draft接口创建草稿。这里有个限制：订阅号的草稿箱API只能新建，不能覆盖已有的，所以每次都是删掉旧的草稿再建新的。删草稿用del_mass_article接口，需要media_id参数，这个要从上次运行的记录里读，或者从微信公众号后台查。目前脚本里是写死了一个media_id，这个其实不太稳，下次应该改成从数据库或者文件里读上次的值。
封面图的处理，微信那边要求图片大小不超过2MB，宽高比建议2.35:1或者16:9。我生成的图是1024×576，刚好是16:9，压完一般在100-150KB之间，传微信素材库没出过问题。但微信的uploadimg接口返回的是url格式，不是media_id，草稿接口里封面图要填thumb_media_id，这个是通过material/add接口上传得到的，两个接口不一样，容易搞混。目前脚本里是分开处理的：封面图走material/add拿thumb_media_id，文章里的图片走uploadimg拿URL。
今天（5月6号）检查日志的时候发现，4号那篇文章的字数只有900多字，离要求的1200-1800字有差距。回头看那篇文章，技术细节写得不够密，有些地方的叙述比较空。比如写”经过一番调试终于解决了”，这种表述就是典型的AI味，没有说具体调了什么、报错信息是什么、改了哪行代码。后面写文章得注意，宁可多写点实际的操作步骤，也不要用这种概括性的句子凑字数。
还有一个问题，自动化触发时间有时候不太准。看5月3号的记录，实际触发是23:50，比设定的22:00晚了快两小时。查了一下，应该是那段时间我的Mac在睡眠，WorkBuddy的自动化调度在本地跑，机器睡了就推后了。这个没有特别好的办法，除非把调度迁到服务器上用cron来跑。但服务器上跑的话，生成文章用的AI模型调用又要配置一遍，本地跑其实更方便，就是得保证22:00那会儿电脑是醒的。目前暂时不管了，后面如果经常乱跑再想办法。
图片生成这块，Gemini的API在5月1号那天额度用完了之后，后面几天都走的混元。混元的图生图接口相对稳定，但有个问题：生成的图有时候跟Prompt对不上，比如要求赛博朋克风格，出来的图偏明亮，暗色调不够。解决办法是在Prompt里加强描述，比如”dark cyberpunk, neon glow, dark background, low key lighting”，用英文关键词混着用，效果比纯中文好。图片分辨率最开始设的1200×630，后来改成1024×576，压完JPEG quality=70大概100KB出头，上传速度比较快。
服务器那边，43.130.242.135这台，磁盘空间今天看了一下，/var分区用了38%，主要是WordPress的uploads目录占了一些，图片和文章多了之后备份得跟上。目前还没有做自动备份，这个得排上日程。MySQL的wordpress数据库，wp_posts表目前有200多条记录，wp_postmeta有600多条，量还不大，索引不用特别优化，但该加的unique key还是得检查一下，避免出现重复文章。
脚本里存着的SSH密码和微信AppSecret，目前是明文写在py文件里的。这个肯定不行，后面要改成从环境变量或者一个权限600的配置文件里读。现在这几个脚本都在本地工作目录里，没有提交到任何公开仓库，暂时问题不大，但这是个隐患，得尽快处理。
自动化这个东西，跑起来之后最容易出的问题是”以为它在跑，其实已经挂了”。后面应该在每次跑完之后发一条企业微信或者Telegram的消息，告诉我这篇文章发布成功了没有，WordPress的文章ID是多少，微信草稿有没有创建成功。目前是完全面盲跑，只能事后去查，不太放心。
今天先记到这里。明天看看能不能把密码配置那块改掉，顺便把自动化运行状态的通知加上。