OpenClaw 公众号工作流

解决什么问题

给公众号写稿时，从一堆链接、会议纪要或 GitHub 仓库到真正可用的图文草稿，中间至少要做五件事：判断选题能不能写、核实外部事实、按合适的结构成稿、规划配图位置、再调用微信公众平台的草稿接口把成品送进去。这套 OpenClaw 公众号工作流把这五件事串成一条流水线，让 agent 在最少的配置下跑完整个流程，而不是只交付一份 Markdown 就结束。

它尤其针对两类反复出现的问题：一是写作前没有事实核查环节，GitHub star 数、产品价格、模型名称全靠转述；二是发布环节的凭据和白名单配置靠记忆，换台机器就掉链子。

核心能力与关键步骤

输入处理

• 接受话题、链接、笔记、PDF、GitHub 仓库、产品简介或已有草稿；只有信息不足以判断时才追问缺失项。
• 明确输出形态：只要草稿、只要最终 Markdown，或两者都要。
• 写作深度分三档：direct/practical、normal commentary、deep reflective essay。工具或项目推荐类默认走直接实用路线，不强行加行业反思。

选题与结构

• 用 HKR 给选题打分：H（好奇/张力/点击欲）、K（新信息/有用洞察）、R（情感共鸣）。三个维度里少于两个强，就先提更尖锐的角度，不急着开写。
• 选定一篇的主原型：调查、产品体验、现象分析、工具分享、方法论。原型决定结构和需要的证据。

事实核查

• GitHub 项目用 API 拿 stars、forks 和元数据，不依赖渲染后的页面数字。
• 产品名、价格、日期、政策优先找一手来源，查不到就标注不确定，不编造。

写作与配图

• 风格是"一个懂行的人认真聊一件打动他的事"：短段落、长短句交替、口语化过渡、有真实细节和个人判断。
• 明确禁止"本质上""综上所述""首先/其次/最后"这类空话，禁止标题 emoji、结尾引用堆砌、虚构第一人称经历。
• 图片在写作时同步规划，只使用相对路径；概览图放产品介绍后，功能图贴功能段，配置图贴安装步骤，CLI 图贴命令说明。

发布与交付

• 使用 scripts/publish_wechat_draft.py：先走 cgi-bin/stable_token 拿 access_token，仅在稳定端点因非 IP 原因失败时才回落到旧 cgi-bin/token。
• 脚本负责 Markdown 转 HTML、通过 media/uploadimg 上传正文图、把本地路径替换成 mmbiz.qpic.cn 链接、上传封面拿新的 thumb_media_id、调用 draft/add，并把返回的 media_id 写进 article.meta.json。
• 交付物固定四件：article.md、imgs/、article.meta.json（标题、摘要、作者、封面、来源 URL、发布状态）、quality-report.md。

适用边界与注意点

• 不适用于只写作不发布的场景。 首次发布且本地没有有效 .env 时，必须先走配置流程拿 WECHAT_APP_ID 和 WECHAT_APP_SECRET（后台也叫"开发密钥 / AppSecret"，有人会说成"密码"，一律当密钥处理）。
• IP 白名单是硬约束。 发布前要把 agent 当前对外公网 IPv4 加进公众平台后台的白名单。返回 40164 时以微信错误信息里显示的 IP 为准——代理、运营商、VPN、NAT 或平台路由都可能让通用 IP 查询结果与 API 观测结果不一致。
• 凭据不放代码里。 用 .env.example 做模板复制成 .env，不要硬编码在技能目录或文章文件里。
• 本地 dry-run 只校验文件。 真正的 API 检查发生在发布时，所以第一次跑完 dry-run 后建议用一篇小测试文章确认草稿箱里能收到。
• 换机器要重做白名单。 AppID/AppSecret 可以不变，但放行 IP 必须匹配实际调用 API 的那台机器。
• 常见错误码对应不同原因。 40164 是白名单或旧 token 端点问题；40013 是无效 AppID；40001/token 错误多为 AppSecret 错、凭据过期或账号不匹配；40007 是封面 thumb_media_id 过期，需重新上传。正文图发布后空白，通常是用了 media/upload 或外部 URL 而不是 media/uploadimg。