公众号文章自动更新全流程助手

Overview

把一篇公众号文章从「选题」做到「进草稿箱」的完整操作手册。覆盖选题、标题、写作、配图、发布五个环节，并沉淀了在受限运行环境（/tmp 只读、禁止 symlink、部分外网站点被屏蔽）下用 wenyan-cli 自动发草稿的可用路径与踩坑经验。

三块核心资产：
1. 写作资产——双风格范本（行业观察用商业分析体 / 运营者亲身实操用口语聊天体）、爆款标题对标方法、涉敏感题材的合规口径。
2. 配图资产——带中文标注的图一律用 SVG + resvg-wasm 生成，禁用 AI 生图（中文必乱）。
3. 发布资产——wenyan-cli 直调 + IP 白名单网段方案 + 长度硬上限规避，稳定把稿子送进草稿箱。

> 本 skill 的能力来自公众号「未迟AI笔记」的长期运营实践。文中出现的公众号名仅作示例，请替换为你自己的号名。

全链路 Skill 组合

以下 skill 可组成完整闭环（WorkBuddy 推荐市场可装）：
- wechat-viral-topic（选题策划）：基于热点产出爆款选题、切入角度、8 维打分。
- wechat-title（爆款标题）：生成并评估标题。注意：拉真实爆款数据评分需 REDFOX_API_KEY（第三方 redfox.hk 服务，非必需；无密钥时退回候选标题折中方案）。
- wechat-article-search（同类爆款检索）：按关键词搜公众号真实文章标题、来源、时间。写标题前用它找同类爆款的句式，比凭空想靠谱。
- wechat-article-pro（长文 + AI 封面 + 发草稿）：浏览器手动流程，且要求 3000-5000 字——与「1000-2000 字 + 自动发」需求通常不合，不作为自动发链路的一环。
- wechat-publisher / wenyan-cli（核心发布器）：用 AppID + AppSecret 走接口把 Markdown 发到草稿箱。这是自动发的关键工具。
- wechat-cover（专业封面）：基于 10w+ 数据生成高转化封面；可替代纯背景图。

推荐闭环：wechat-viral-topic 出选题 → wechat-article-search 找同类标题 → 写正文 → SVG 出封面与配图 → 发草稿箱。

协作规则（必守）

• 表述不清先反问，不确定不猜测执行：指令有歧义或缺关键信息时，先反问确认再动手。严禁臆测执行。
• 不得编造运营者本人实操：文章中凡涉「我自己 / 我们团队怎么做」等第一人称实操，若无真实依据，一律改写为「有博主 / 社区反馈 / 公开资料显示」等第三人称口径。
• 给无技术背景用户具体分步指引：需要用户操作（进公众号后台、配白名单等）时，给逐点可点击的步骤，而非技术术语。
• 对外动作先确认：发草稿箱、群发、删旧草稿等影响账号或对外可见的动作，执行前必须取得明确确认。
• 不要替用户做保守决定：涉及敏感词取舍、是否写商业变现内容时，给选项、讲清差异，让用户自己定；不要主动劝「低调一点」。

标题规范（每篇必做）

标题不是内容摘要——平铺直叙地概括全文就是失败。必须对标同类爆款来写。

流程：
1. 写稿前先搜同类爆款标题：用 wechat-article-search 或 WebSearch 搜同题材，看同行在用什么钩子。别凭感觉编。
2. 一次给 3-5 个备选供用户挑选，不要只给一个。
3. 爆款要素自检：
- 前 12-15 字必须放钩子：数字 / 权威信源 / 悬念 / 威胁感 / 利益点。
- 具体名词 > 抽象概括：XX 154 页报告 远胜「有份报告」；一个人就够了 远胜「门槛降低」。
- 权威机构名 + 具体数字天然抓眼且显可信。
- 留一点「没说完」的悬念，让人必须点进去才知道结论。
- 禁用「最好 / 第一 / 顶级」等违禁词。
4. 敏感词风险自检：武器、生化、国别冲突的强刺激词（导弹、病原体、病毒、具体国名）最抓眼，但在微信生态有被限流或拦截的概率。给选项时，同时给出「最抓眼版」和「同强度但无敏感词的替代版」并说明差异，由用户决定——不要替他做保守取舍。
5. 反例（真实踩坑）：《AI 干坏事，现在一个人就够了：154 页报告里普通人该注意什么》被评为「平平无奇」；后来改成《Anthropic 154 页报告：有人正拿 AI 设计导弹和病原体》，效果明显更好。差异就在权威信源 + 具体量级 + 刺眼的具体宾语。
6. 标题里尽量别写「直播」二字（读者在信息流里当成通知划走）；直播信息放到正文开头 50 字内。

写作风格范本（双风格，二选一，不要混用）

A. 行业观察 / 商业模式类 → 商业分析体

结构化的商业分析，但写得清楚、有信息量，不堆砌术语。标准结构：
1. 抛概念（用一个新词 / 新现象切入）
2. 拆定义（这个概念到底指什么）
3. 分领域案例（具名信源 + 具体数字）
4. 大厂动向（谁在抢入口）
5. 普通人的机会（机会一 / 二 / 三，每个配「实践案例」+「你可以做什么」）
6. 结语给行动建议（落到「现在能做什么」）

> 政策 / 报告类可换成四层结构：事实层（这份东西说了什么）→ 变化层（真正变的是什么）→ 关联层（哪几类跟普通人有关）→ 行动层（现在能做什么）。把「跟普通人无关的部分」明确写一句「这里不展开」，反而增强可信度与节奏感。

B. 运营者亲身经历的实操笔记 → 口语化聊天体

• 仅当写真实做过的事才用此风格。
• 像真人聊天：句子可短可碎、可省略主语，允许真实小插曲和情绪表达。
• 严禁规整报告体、过度结构化、堆砌术语。

铁律边界

• 行业观察文章不写「我」（除非引用公开观点并注明出处）；实操笔记才用第一人称。
• 凡涉及运营者本人「跑过某模型 / 固定组合 / 实操」等，无真实依据的一律改第三人称，或换能真实完成的选题——绝不编造。

写作禁忌（通用）

1. 禁止口水话 / 无信息量套话：如「这两天有个事儿」「先说个让你有体感的数字」「这件事为什么和你有关」「话说回来」等纯衔接、凑字数的句子，一律不写。允许保留真正有「人味」的解释与情绪，但无营养的套话必删。
2. 禁用「不是…而是…」铺垫句式：先否定再转折的结构非必要一律不用。想表达对比，直接把重点写出来，不必先立一个假想敌。
3. 不注水：同观点不重复，段落靠小标题承接，不靠过渡空话。

正文 Markdown 排版规范（让读者抓住重点）

公众号正文经 wenyan 渲染进草稿箱后，缺排版标记的纯段落会全篇一个样、读者抓不住重点。必须做层级与强调，这也是历史文章的统一做法：
1. 小标题用 ## 序号 标题 形式（如 ## 01 人工智能训练师到底是个啥？）。渲染后 ## 变成带颜色、加粗的标题，形成清晰层级；不要用平铺段落当小标题。
2. 关键数字与名词用 ** 加粗（230 名、500 万、16 周岁、8k–15k）。只加真正重要的词，不要满篇装饰性加粗——装饰性加粗既无重点效果，又加长 HTML、挤占 2400 字符额度。
3. 列举类内容用 - / 1. 有序列表，天然有项目符号、节奏清晰。
4. 文末「参考来源」用 ## 参考来源（复制链接到浏览器打开） 起头。
5. 配图视觉风格与历史一致：浅色底 #F4F6FA + 白卡片 + 科技蓝主色 #2E5BFF（不用 #7B5CFF 蓝紫，用户明确反感蓝紫渐变）；风险/警示用红 #E5533C。

敏感题材合规口径（涉境外报告 / 点名题材必守）

写境外机构报告（如安全威胁情报报告、各类政策报告）时，原文往往点名了国别、政府机构、地名，或涉及生物 / 武器的技术细节。落笔前先做口径裁剪，这是硬约束：
1. 不写国别归属、不写具体地名、不写政府机构名称——即使原报告写得很明确、外媒也照搬。
2. 不展开危险技术的实现细节（病原体名称与改造方向、武器制导路径、攻击工具链、可用攻击手法）。
3. 保留仍成立且可公开引用的结构性结论：核心指标定义、耗时 / 规模对比数据、纯粹的犯罪团伙案例（无国家归属的那种）。
4. 涉国别的危害类别，明确写一句「报告写得很细，但跟普通读者日常没有交集，这里不展开」——既交代信息完整性，又完成收束。
5. 落点必须回到普通读者的日常：诈骗防范、账号与 API Key 安全、内容鉴别、关键决策人工复核。
6. 标题不为冲击力踩红线（避免「某国用 AI 造导弹」这类写法）。

原则：合规优先于信息完整度。宁可少写一半案例细节，也不能出现国别指向。

写稿发布 SOP

1. 选题去重与序号

系列文章（如「第 N 篇」）落笔前先检索已发选题清单，确认最新篇数再写序号。
踩坑：曾凭印象写「第 28 篇」，实际应为第 29 篇，导致封面重做、重推一次、草稿箱多出一条待删稿。序号通常印在封面图里，写错就要重新渲染。

2. 长度硬上限（最容易踩的坑）

微信侧对正文长度有限制，超限发布直接报错（错误文案里可能出现「小绿书」等无关词，属翻译误导，不必据此排查图片数量或类型）。

硬指标：wc -m 文稿.md ≤ 2400（含 frontmatter 与文末来源区），超过几乎必被拦。
- 起稿就按正文 1300-1500 字写，不要写爽了再砍（曾有初稿 3501 字符，砍了五轮才到 2403）。
- 砍法优先级：删形容词 / 过渡句 → 合并次要案例细节 → 删纯装饰性加粗（** 渲染成 <strong> 反而加长 HTML）→ 最后才动核心数字与金句。
- 文末要放「参考来源」时，起稿就预留 200-300 字符。
- 发布前必跑一次 wc -m。

3. frontmatter

---
title: "文章标题"
cover: cover-<主题>.png
---

• cover 是发布必填项，指向本地封面图（与 md 同一目录）。
• 不设 cover 的致命后果：wenyan-cli 在没有 cover 字段时，会自动把正文第一张插图当封面（thumb_media_id 取正文首图）。所以草稿箱看到的封面就会是插图1，而不是独立封面图。每篇都必须显式写 cover: cover-xxx.png，不能依赖正文插图。
• cover 字段里的文件名必须是真正存在的独立封面文件（如 cover-aipay.png），不能是正文插图文件名（如 aipay-fig1.png）。
• 封面图文件名必须独立（cover-security.png、cover-topic.png…），严禁所有文章共用 cover.png——新文章生成封面会覆盖旧文件，回头补发旧稿必配错封面。
• 正文插图必须在正文里显式写 ![](图片名.png) 引用。只生成不引用，发布后正文里是空的（工具只处理 frontmatter 的 cover）。

4. 参考来源（涉及官方内容时必做）

凡文章涉及官方政策 / 国家标准 / 政府公告 / 监管通报、某产品的官方发布或新闻稿、行业机构报告数据，文末必须列出「参考来源」，给出官方原文链接。

规则：
1. 只用一手来源：政府门户（miit.gov.cn、gov.cn、court.gov.cn 等）、国家标准全文公开系统（std.samr.gov.cn / openstd.samr.gov.cn）、发布方官网（如中消协 cca.org.cn）、企业官方公告页。不用媒体转载替代官方原文；媒体可作补充，但官方那条必须有。
2. 文末格式（微信正文外链不可点击，必须写纯文本 URL + 提示复制到浏览器打开）：

## 参考来源（复制链接到浏览器打开）

1. 国家标准全文公开系统 · GB/T XXXXX—2026《标准名》
https://std.samr.gov.cn/gb/search/gbDetailed?id=xxxx

2. 发布方《报告名》（文中 X% 数据来源）
https://官方域名/路径

文中数据引自第 1 条官方页面，细节以原文为准。

3. 多个来源按重要性排序，注明「文中某数据引自第 N 条」。
4. 唯一最重要的官方原文可让用户放进编辑器的「阅读原文」位——公众号正文只有这一处能挂可点击外链。
5. 来源区计入 2400 字符上限，写稿时预留。
6. 用户自己给的参考链接，必须放进参考来源第 1 条。

5. 发布

见下方「微信草稿发布机制」。发布成功后输出报告：标题 / 字符数 / 封面说明 / 草稿 Media ID（或被拦截的 IP）/ 后台审核提示。

配图方案（SVG 矢量信息图，中文图禁用 AI 生图）

• 核心约束：ImageGen 等 AI 生图渲染中文必然乱码、出「豆腐块」，不能用于带中文标注的信息图 / 流程图 / 对比图。一律 SVG 矢量绘制。
• 工具链：@resvg/resvg-wasm（不是 @resvg/resvg-js——后者原生二进制在部分平台报 Unsupported OS）。
• 字体：/system/fonts/FZHeiT-SC-Regular.ttf / -Bold.ttf，family 名 FZHeiT-SC。渲染时用 font.fontBuffers 传 Uint8Array，并设 loadSystemFonts:false。
• 尺寸：正文图 1080×720，封面 1080×864。文件名用英文（中文名上传易失败）。
• 视觉风格：浅色底 #F4F6FA + 白卡片圆角 22 + 淡边框 + 阴影 + 科技蓝主色 #2E5BFF（不用 #7B5CFF 蓝紫，用户明确反感蓝紫渐变）；「风险 / 挑战」用红 #E5533C 区分。风险色克制使用，不要满屏红。
• 配图数量按需，不固定三张。只在「图能一眼看懂」处配（对比 / 分类 / 流程）。
• 模板脚本：scripts/gen_infographic_template.js（含 card 助手与 pic1/2/3 + cover，改数据即可出图）。完整配方见 references/infographic_reference.md。

渲染后必须校验（踩坑）

字体路径写错会「静默出废图」——不报错、文件也有十几 KB，但里面一个字都没有（曾因写成不存在的字体文件名，产出一张 11KB 的空白废图）。
- 渲染后务必确认文字真的出来了：能看图就直接查看；不能看图就程序校验（统计深色像素数 / 颜色数，为空即失败）。
- initWasm(require.resolve('@resvg/resvg-wasm'))（传字符串包路径）会报 ERR_INVALID_URL，必须传 wasm 二进制 buffer：
js await initWasm(fs.readFileSync(require.resolve('@resvg/resvg-wasm/index_bg.wasm')));
- text() 里除依赖 defaultFontFamily 外，再显式加 font-family="FZHeiT-SC" 属性，更稳。
- SVG 不自动换行：长文必须手动拆多行（多个 <text> 或 <tspan>），按字号估算宽度，别溢出卡片。

公众号后台操作（需人工完成的部分）

合集（群发后才进得去）

• 草稿进不了合集，只有群发后（或已发布）的文章才能加入。
• 首次使用：后台「内容管理 → 合集 → 创建合集」（选文章合集），填名称 + 简介 + 封面，发布。
• 群发前可在编辑器「更多设置 → 合集」里挂上，群发后自动入合集。
• 已发文章：在列表点「…」→ 添加合集。顺序调整只能电脑端。建议开启「连续阅读」。
• 合集名称建议带关键词，便于读者检索与平台归类。

草稿清理

重推会产生新草稿，旧草稿不会自动删除，需用户在后台手动删。重推后要明确告诉用户「删哪一条」——用「封面上的序号」「有无参考来源小节」这类可辨识特征描述，不要只给 Media ID。

微信草稿发布机制（wenyan-cli）

发布三前提：
1. 凭证：公众号 AppID + AppSecret（后台「开发 → 基本配置」获取）。AppSecret 只显示一次，务必妥善保存；绝不能写进任何要分享的文件、代码仓库或 skill 里。
2. 封面图必填：Markdown frontmatter 必须有 cover: 指向独立封面文件（建议 1080×864）。不设的代价：草稿箱封面会变成正文第一张插图（thumb_media_id 取首图）。每次发布前确认 cover: 已写且文件存在。
3. IP 白名单：见下节。

IP 白名单：动态出口 IP 用 /8 网段聚合

运行环境出口常是动态 NAT 池，会跨 A 段漂移。逐条补单 IP 永远追不上，会导致文稿反复卡在最后一步。

配置方法：
- 后台「开发 → 基本配置 → IP 白名单 → 修改」。
- 白名单原生支持 CIDR，只支持 /8 /16 /24 三种掩码，不支持 172.0.0.* 这类通配写法。
- 首选直接填 /8：先跑一次发布，微信会在错误里回显 invalid ip x.x.x.x，取该 IP 的第一段补一条 X.0.0.0/8，一次覆盖整段。同一环境可能漂到多个 A 段，每个 A 段补一条。
- /8 会放行约 1600 万 IP，/16 约 6.5 万。AppSecret 才是真正的钥匙，白名单只是第二道锁；若介意范围可退回逐 /16 补段，但大 NAT 池会持续漂，需长期维护。
- 判断是否该补段：连续两次报同一个 IP，说明该段已稳定，直接补段、不要反复重试；报错 IP 每次都不同，说明池子很大，直接上 /8。
- 这不是一次性配置：新 A 段出现就再补一条。被拦时本地文稿不丢，加完白名单原样重推即可，无需改稿。

给用户的傻瓜指引模板：
> 公众号后台 → 设置与开发 → 基本配置 → 找到「IP 白名单」→ 点「修改」→ 新增一行填 X.0.0.0/8 → 保存（管理员扫码确认）→ 回来告诉我，我重推。

通用教训

遇到「动态 IP vs 平台白名单」问题，第一步永远是查该平台白名单是否支持 CIDR 网段，而不是急着搭固定 IP 服务器或中转服务——后者成本高，且中转服务的出口往往同样不固定。

调用方式（已实测可用）

cd <工程目录>
export WECHAT_APP_ID=<你的AppID> WECHAT_APP_SECRET=<你的AppSecret>
export TMPDIR="$PWD/.tmp"   # 指向可写目录，避免 /tmp 只读
node "$PWD/wy/node_modules/@wenyan-md/cli/dist/cli.js" publish \
  -f "<文稿绝对路径>.md" -t lapis -h solarized-light

• 成功返回「发布成功，Media ID: ...」，文章进入草稿箱（非群发）。
• 只存草稿、不群发是默认安全策略。
• 用绝对路径调用 node 与文稿，可绕开 shell 的 getcwd 问题。

关键环境坑点（受限运行环境）

• /tmp 只读：npm 全局安装与写临时文件会失败。务必在工程目录内本地安装依赖，并设 export TMPDIR="$PWD/.tmp"。
• 文件系统禁止 symlink：npm 安装最后建 .bin/xxx 软链会 EACCES 失败。绕过：直接 node node_modules/<pkg>/dist/cli.js，不要依赖 npx / 全局命令。
• getcwd 报错无害：shell 回收临时目录时偶发 getcwd: cannot access parent directories，只要目标命令返回成功即可忽略。
• 外网部分站点被屏蔽：ifconfig.me / api.ipify.org 等 IP 查询站可能不通，不代表断网（npm 源、api.weixin.qq.com 均可达）。拿不到出口 IP 时直接调微信接口，白名单错误响应会回显真实出口 IP。
• shell 执行器卡死：偶发所有命令静默无输出（连 echo 都没回显），属执行子系统故障，非脚本问题。此时改用文件读写类工具继续工作；恢复需重启客户端并清理运行缓存。
• npm 卡死：若后台安装僵死（无输出、ENOTEMPTY），按 PID 精准 kill（ps -ef | grep <pkg> → kill -9），不要 pkill -f "npm install"（会误杀当前 shell）。

Word / docx 导出（环境无 pandoc / python-docx / pip）

• 用 Python 标准库手写合规 OOXML 包（zip + document.xml 等），把 Markdown 转 docx 并内嵌图片。模板：scripts/md2docx.py <md文件> [输出docx] [图片目录]（图片目录默认取 md 所在目录）。
• 映射：标题 → Title 样式；## → Heading2；### → Heading3；**x** → 加粗 <w:b/>；![alt](img.png) → 内嵌 <wp:inline>。
• 中文用宋体 / 黑体（eastAsia），Windows、Mac 的 Word 均能正常打开。
• 校验：zip 内各 XML 用 xml.dom.minidom 解析良构；抽查段落数 / 图片数 / 关键词确认内容齐全。

数据核对（发布前必做）

文中模型参数、价格、免费额度、上线日期等数字极易变动。发布（或重推）前，逐条用 WebSearch 多源交叉验证；发现硬错误直接改文稿并重新推送。
- 核对数字时同步把官方原文链接抄下来，直接写进文末「参考来源」，不要等写完再回头找。
- 重点盯：上下文窗口（token 数）、上线 / 开源日期（月份极易写错）、参数规模、价格与免费额度、API 单价。
- 无权威统一口径的数据，弱化为「有观点认为 / 数据显示 / 公开资料显示」，不当硬事实陈述。

协作场景 SOP：用户提供成稿 + 参考图

当用户贴出一篇成稿（或文件）并附参考图，说「配图 / 按这个风格」时：
1. 先确认 4 点（避免返工）：风格（照原文 / 改口语版）、配图数量、图片来源（AI 生图 / SVG 矢量，含中文必选 SVG）、标题（用原标题 / 另起）。
2. 数据核对：WebSearch 多源核对文中数字；硬错直接改稿，软数据加限定语。
3. 配图：SVG 矢量绘制，按参考图风格。
4. 插入配图：放到正文合适位置，并确认正文里有显式引用。
5. 发布到草稿箱（仅草稿）；被 IP 拦则提取出口 IP 告知用户加白名单，本地文件不丢。

> 案例替换铁律：若要把文中某个公司 / 产品案例换成另一个，必须联网查到真实数据后重写，不能只改名字硬套旧数字（那是编造）。

Resources

scripts/

• publish_draft.sh：一键发布 Markdown 到公众号草稿箱（封装环境坑点、长度与白名单校验、错误提示）。
• gen_infographic_template.js：SVG 信息图模板（resvg-wasm + 中文字体），改数据即可出 3 正文图 + 1 封面。
• md2docx.py：Markdown → docx（含内嵌图，无需 pandoc / python-docx）。

references/

• publish_reference.md：凭证获取、IP 白名单网段方案、wenyan 安装细节、常见错误码对照、数据核对清单。
• infographic_reference.md：配图方案完整配方（工具链、字体、视觉变量、渲染与校验脚本）。