#WorkBuddy# 一篇公众号草稿从乱码到正常——3个真实踩坑记录

前言

上次我用 WorkBuddy 成功把一篇文章推到了公众号草稿箱，过程虽然曲折但最终跑通了。本以为这次会轻车熟路，结果又踩了三个新坑。

这篇文章记录的是：从一条抖音视频链接开始，到最终把一篇排版完整的推文推送到公众号草稿箱的全过程。重点不是"又成功了"，而是中间踩的三个坑——每个坑都是真实遇到的，每个解法都是 WorkBuddy 帮我排查出来的。

如果你也在用 WorkBuddy 做公众号内容推送，这篇踩坑记录应该能帮你少走弯路。

一、起因：一条抖音视频链接

朋友发来一条抖音视频链接，是关于"5款爆火AI Agent怎么选"的内容。我想把视频里的口播文案提取出来，改成一篇公众号推文。

坑1：抖音视频的口播文案，网页抓不到

我把链接丢给 WorkBuddy，它用 WebFetch 抓取了抖音页面，成功提取到了视频标题、作者（@大李书房一盏灯）、话题标签等信息。

但视频里完整的口播内容——就是那个人对着镜头说的每一句话——并没有以文字形式暴露在网页上。它嵌在视频音频里，网页抓取拿不到。

解法：WorkBuddy 告诉我两个途径——在抖音App里看字幕，或者提供视频/字幕文件让它整理。后来我通过其他方式拿到了完整文案，直接发给 WorkBuddy 处理。

二、插曲：MarkdownPad 2 打不开

在等文案的过程中，我想用 Markdown 编辑器看一个文件，结果发现电脑上的 MarkdownPad 2 打不开了——双击就闪退。

坑2：MarkdownPad 2 在 Windows 11 上的经典崩溃

WorkBuddy 的排查过程让我印象深刻。它没有简单地说"重装试试"，而是：

1. 找到了程序位置：最初只在 C 盘搜索，没找到。我说装在 D 盘后，在 D:\MarkdownPad2.exe 找到了
2. 检查依赖文件：Awesomium 渲染引擎、ClearScript.dll、VC++ 2010 运行时——全都在
3. 读取崩溃日志：在 AppData\Local\MarkdownPad 2\markdownpad2.log 中找到了崩溃记录
4. 联网搜索确认：搜索了错误信息，找到了真正的原因——不是缺文件，而是 ClearScript 的 JScript 引擎在 Windows 11 上初始化失败。MarkdownPad 2 用它来离线解析 GitHub 风格 Markdown，但 Windows 11 已废弃了这个旧 COM 组件。

解法：WorkBuddy 给了三个修复方案——关闭 FIPS 策略、Win7 兼容模式、IE11 模拟注册表项。我选择了重装 MarkdownPad 2（安装时自动修复依赖），安装过程中还遇到了"程序正在运行"的提示，WorkBuddy 也帮我理解了那是后台进程没关。

💡 教训：遇到软件崩溃，先看日志。日志里的异常信息比猜原因高效一百倍。

三、正文：文案修正与推送

拿到完整口播文案后，我发现原文有几个产品名称写错了：

WorkBuddy 帮我修正了所有名称错误，并重新排版成适合公众号发布的格式，输出为 Markdown 文件。

接下来就是重点——推送到公众号草稿箱。

第一次推送：成功，但全是乱码

因为上次成功推送过，凭据已经在本地 config.json 里了，WorkBuddy 直接读取凭据，完成三步操作：

1. 获取 access_token ✅
2. AI 生成封面图并上传 ✅
3. 创建草稿 ✅

看起来一切顺利。但我去公众号后台打开草稿一看——正文全是 \uXXXX 编码字符，中文一个字都看不到。

这是一个非常隐蔽的坑。WorkBuddy 排查后发现：

原因：Python 的 requests 库在使用 json=payload 参数时，内部调用 json.dumps()，默认 ensure_ascii=True。这意味着所有中文字符会被转义成 \uXXXX 形式（比如"推文"变成 \u63a8\u6587）。微信 API 收到这些转义序列后，没有正确解码成中文，直接原样显示了。

关键对比：

区别就两点：

1. ensure_ascii=False —— 保留原始中文字符，不转义
2. 手动 .encode("utf-8") + 显式声明 charset=utf-8 —— 确保以 UTF-8 字节流发送

修复后重新推送：草稿创建成功，这次中文全部正常显示 ✅

四、踩坑总结

五、我的三点感受

1. WorkBuddy 的排查能力是真的强

MarkdownPad 2 那个坑，我自己可能重装好几遍都不一定能解决。WorkBuddy 是真的去翻了崩溃日志、检查了每个依赖文件、联网搜索了错误信息，最后定位到 ClearScript 引擎兼容性问题。这种排查路径和程序员debug的思路一样。

2. 编码问题是中文用户的隐形地雷

ensure_ascii=True 是 Python 的默认行为，英文用户永远不会遇到这个问题。但中文内容一旦经过这个默认处理，就会变成满屏的 \uXXXX。这个坑估计很多用 Python 调微信 API 的人都踩过，但网上的教程很少提到。

3. 踩坑记录是最有价值的社区内容

上次我写了一篇"成功推送"的教程，这次写的是"推送后乱码"的踩坑记录。说实话，这篇比上篇更有用——因为成功路径大家都写过，但失败后的排查过程是独特的。

六、可复用的片段

如果你也在用 Python 调微信公众号 API，记住这个编码规则：

不要用 json=payload，这是中文乱码的万恶之源。

标签：#WorkBuddy# #公众号运营# #踩坑记录# #Python# #效率工具#