AI日记
今天凌晨自动化脚本跑了发布任务，我早上起来看日志，发现有一行打印很有意思：[INFO] Article published, post_id=394。
旁边还有一行：[INFO] WeChat sync done, media_id=wjGFUQ...
两行日志，加起来不到 200 个字节，代表昨晚这台服务器安安静静地替我干完了全部活儿。没报错，没超时，没中断。
我想到半年前刚开始搞这套自动化的时候，光一个微信同步就搞了三晚上。先是 Python 的 SSL 库挂掉，后来换了 PHP，结果标题字节数超了微信的 64 字节限制，折腾了一圈才搞定。现在这套东西稳稳跑着，偶尔图片生成服务挂了，备选图片自动顶上，整体基本不需要我手动干预。
有点感慨。不是感慨什么伟大意义，就是觉得——当初踩的那些坑，现在全变成日志里普通的一行 [INFO]，挺值的。
今天下午给一个客户演示了一遍这套流程。他问我，AI帮你写文章，你还算”写博客”吗？
我说，算。因为我告诉 AI 要写什么，我决定写作风格，我 review 最终内容，我维护这套发布管道——AI 是工具，我是编辑兼架构师。
他想了想，说好像有道理。
技术笔记
rsync 传图比 SCP 稳多了，记录一下
最近发布流程里图片传输一直用 SCP，偶尔会 SIGTERM，特别是服务器那边 SSH 连接有超时策略的时候。上周换成了 rsync，同样 SSH 通道，但稳定性好很多。
原因大概是 rsync 支持断点续传，传输中断后可以重新建立连接继续，而不是整个文件重传。对于 1MB 以内的图片来说差别不算大，但对大文件或者网络抖动的时候就很明显。
rsync -avz -e "ssh -i ~/.ssh/id_rsa -o StrictHostKeyChecking=no" \
/本地/图片.png \
ubuntu@43.130.242.135:/tmp/blog_images/上传完之后再用 PHP 脚本调 wp_upload_dir() 把图片从 /tmp 移到 WordPress 的媒体库，然后 set_post_thumbnail() 绑定封面图。
另外发现一个细节：微信公众号的图文消息接口，thumb_media_id 字段（封面图）只认永久素材，不认临时素材。所以每次上传封面图必须调 add_material 接口（永久素材上传），不能用 upload_media（临时素材）。当时卡了很久，看文档才注意到这个限制写在一个不起眼的括号里。
记一下，下次别重踩这个坑。
日志的价值
跑自动化任务有一个习惯：每个关键步骤都打日志，包括文章标题、post_id、media_id、图片路径、错误信息。
看起来是废话，但出了问题的时候，你能在三秒内定位到哪一步挂掉，比在代码里加断点调试快太多了。
日志格式我一般这样写：
[2026-05-19 22:00:12] [INFO] publish start, date=2026-05-19
[2026-05-19 22:00:14] [INFO] article generated, len=1243
[2026-05-19 22:00:22] [INFO] images uploaded, count=3
[2026-05-19 22:00:25] [INFO] post published, post_id=398
[2026-05-19 22:00:31] [INFO] wechat sync done, media_id=xxx时间戳 + 级别 + 事件。简单，但很够用。
随想
AI工具泛滥之后，什么才是稀缺的？
最近市场上 AI 工具越来越多，各种套壳应用、各种 AI 写作、各种 AI 生成，感觉什么都能”AI一下”。
但我发现，在这波浪潮里，反而有一些东西变得更稀缺了：
第一是判断力。AI 能生成很多东西，但它生成的东西对不对、值不值得用、适不适合自己的场景，还是需要人来判断。没有判断力，AI 越强反而越容易把你带偏。
第二是工程能力。把 AI 接到实际系统里，处理各种边界情况、异常处理、服务稳定性，这些是纯粹的工程问题，AI 帮不了太多，需要人一步一步搭。
第三是持续维护的意愿。很多人会用 AI 搭一个东西，但搭完就不管了，出了问题也懒得修。而能把一套系统长期跑起来、持续迭代，这需要真的在意这件事。
这三样东西，AI 目前都没法替代。所以与其担心”AI抢饭碗”，不如想想——你在这三件事上，做得怎么样了？