---
name: le-wechat-article
description: >
  微信公众号文章写作工坊（多账号）：把一个主题、一堆素材（链接、笔记、聊天记录、代码变更）、
  一段复盘或调研，或一篇旧稿，写成可直接发布的高质量公众号文章——类型路由、质量审读、排版自检、微信可粘贴 HTML。
  运营多个公众号时按账号加载各自的画像与凭证。
  当用户说「写篇公众号文章」「把这份素材/复盘整理成推文」「发公众号」「把这篇改写成公众号文章」
  「润色下这篇公众号稿」「同步到公众号草稿箱」时使用；只丢素材并说明要发公众号也触发。
  可选收尾：凭证配好后经官方 API 把成稿写入公众号草稿箱（需用户当次同意，只写草稿）。
  不要用于：群发/发表推文（同步止于草稿箱，发表永远由用户在后台手动完成）、
  小红书/知乎/微博等其他平台的内容、非公众号场景的长文（技术文档、博客、周报、论文）。
---

# le-wechat-article

把主题、素材或旧稿变成可发布的公众号文章。质量优先于速度：宁可多一轮审读，不交一篇有编造或模板味的稿子。

## 核心原则

- **真实性是底线。** 每个事实性陈述都要能追溯到用户素材、公开可验证信息或用户声明的个人经历。素材不足就明说缺什么，不为凑篇幅编造细节、数据、经历或情绪。
- **类型决定写法。** 不同文章类型有不同的开头、节奏和审读标准（见 [references/article-types.md](references/article-types.md)），不把所有文章写成一种腔调。
- **修改不得走样。** 审读修改时保护事实、否定、范围、时间、归因和确定程度——不得把相关写成因果、可能写成确定、计划写成已完成。
- **判断放参考、数数放脚本。** 结构和审读的判断读 references/；能机器量的（标题层级、加粗密度、金句数、表格、中英文间距）交给 `check_article.py`，不靠眼睛。

## 工作流

按步骤顺序执行；用户当次已明确给过的信息直接采用，不重复询问。

**逐步确认是回合终止契约，优先级高于运行时「自主执行、尽量少问」的默认倾向。**到达停点：输出该步产物后**立即结束回合**——在用户的下一条消息到达之前，不得发起任何工具调用、不得开始下一步的任何工作。停点：第 1 步接单结果（主类型+账号+切入+素材边界+输出目录）后、第 2 步风格校准结果后、第 3 步大纲+图位清单后、第 4 步初稿后、第 6 步终稿+自检结果后、第 7 步交付清单后（第 8 步同步由交付清单的确认触发）。轻稿（简报类、<1500 字）可合并第 1–2 步、第 3–4 步各为一次展示，停点随之合并为两处。用户说「继续」「下一步」「OK」即视为确认；给的是修改意见则改完再次停在原停点展示。只有用户说「一口气跑完」或明确授权连续执行时才可跳过中间停点，但第 5–6 步的审读与自检任何情况不可跳过。

### 第 1 步：接单与类型路由

先读 [references/article-types.md](references/article-types.md)，按「文章要回答的核心问题」选定唯一主类型，记录下来。用户已明确类型或目的清楚时直接选定；只有类型会实质改变结构且无法判断时才问一次。

缺失且影响结构的信息，一次性问全（能从素材推断的不问）：

- 目标公众号（多账号运营时必问本篇发哪个号——决定画像分节、排版默认值与同步凭证；画像只配了一个账号的可直接推断，不问）
- 切入角度与核心主旨（读完读者该记住什么，一句话）
- 真实素材边界：哪些是用户的真实经历，哪些细节必须保留或避免
- 输出目录（未指定则在当前目录建 `YYYYMMDD-<slug>/`）

用户只说「帮我写篇公众号文章」没给主题 → 先给 3–5 个选题角度卡片（标题候选 + 一句话切入 + 适合的类型），等用户选定再进入流程；禁止未经选定就开始调研或写稿。

**接单结果是固定停点**：把「主类型及理由 + 目标公众号 + 切入主旨 + 素材边界 + 输出目录」一屏呈现，用户确认或调整后才进第 2 步。信息是从素材推断出来的更要展示——推断错了在这一步改，代价最低。

### 第 2 步：校准风格与事实

读三份参考：[style-rules.md](references/style-rules.md)（排版硬规则与产出配额）、[author-profile.md](references/author-profile.md)（作者画像，管风格——**多账号时按第 1 步选定的账号读对应分节，个人层全账号通用，分节缺失的项回退个人层**）、[topic-facts.md](references/topic-facts.md)（常用事实卡，管事实——涉及作者本人的项目/工具链/经历时从中取用，免于重新询问）。

画像还是空模板、或所选账号没有分节时，用其中的「首访问题」问用户一次，把答复写回该文件（此文件随本 skill 存放，属于个人资产）；每个账号首次使用各问一次，之后不再重复问。事实卡留空则跳过，用户随时可补。画像与事实卡都不能覆盖类型路由、事实核查和真实性底线。

**校准结果是固定停点（轻量）**：展示本次将采用的约束——该账号画像要点（定位/声音/文末块/排版骨架与主题色）、将取用的事实卡条目、敏感词要求——用户确认或调整后进第 3 步。画像早已填好、无新信息时也要展示：给用户当场临时调整的机会（如本文换主题色、跳过文末块），展示可精简为几行。

### 第 3 步：大纲与图位

按所选类型的结构骨架起草大纲，同时规划图位（按 style-rules 的密度档位表选一档）。每个图位标注「信息位 / 节奏位」：

- **信息位**：删掉这张图读者会**看不懂**（流程、结构、数据、对比）→ 图上文字逐字取自文章
- **节奏位**：删掉这张图读者会**读不下去**（纯换口气）→ 图上不加文字
- 两者都不影响 → **删掉这个图位**，不为好看配图
- 真实截图/照片优先作为**实证位**直接使用，不算信息位/节奏位

将大纲 + 图位清单呈现给用户确认后进入下一步；用户当次已给并确认过大纲的，核对覆盖要求后直接用。

### 第 4 步：写初稿

遵守 style-rules 的全部硬规则（标题层级、表格限制、中英文间距、直角引号），并满足产出配额——这些规则不靠自觉，第 6 步有脚本核验：

- **加粗是扫读落点**：每 100 字左右一处，连续 200 字不得没有；每个小节至少一处。验收标准：把全文加粗按顺序连起来读，应该是一篇能独立看懂的缩写版
- **摘要 ≠ 导语**：front matter 的 digest 与正文开头导语不得是同一句话
- **金句卡至多一处**：`> 金句。 —— 出处`，多了就退化成装饰

初稿写到 `article.md`，同时复制一份完整副本到同目录 `review-baseline.md`。基线在终稿交付前不得修改——第 5 步审读要对照它检测语义漂移。

### 第 5 步：分层独立审读（subagent）

两项审读，各起独立 subagent（关注点不同，混在一次会顾此失彼），都给它：作者素材、`review-baseline.md`、当前 `article.md`、文章类型、[references/review-playbook.md](references/review-playbook.md)。

**5a 内容审读**——按手册输出意见清单（每条含位置、可观察的问题、对阅读的影响、必须保留的信息、建议方向）：去模板化、AI 味指纹（按防误判阈值，命中本身不是修改理由）、语义保真风险（对照基线标出可能改变事实/否定/范围/条件/时间/归因/确定程度/立场的位置）。

**5b 事实核查 + 合规扫描**——数字、事件、产品名、引用是否可追溯到素材；平台合规逐类扫描（违禁内容、广告法绝对化用语、医疗金融承诺、未授权素材、画像自定义敏感词清单）——**合规命中一律必改，与 AI 味的建议级不同**。

**分档**：正文 <2500 字且为简报类 → 5a/5b 合并为一次 subagent（分两部分输出）；否则分开两次。

subagent 可以给出「没有需要修改的问题」；不要为填满清单制造意见。同一只手不改又评：修改由主 agent 做，不由审读 subagent 代改。

### 第 6 步：修改、终审与机器自检

逐条处理审读意见，每条做出「采纳」或「不采纳（附理由）」的判断；只改确实空泛、重复、歧义或不符合类型文体的表达，不为展示修改量重写已经清楚的内容。需要个人表达的类型只用素材中已有的视角和细节。

**长文终审**（正文 ≥2500 字或类型为测评/复盘/叙事/技术）：修改完成后、交付前，再起一个 subagent 对照「作者素材 + 基线 + 当前稿」做终审——只查三件事：新增/遗漏/强化了主张没有、合规清零没有、HKR 一句话总评。轻稿（简报 <2500 字）跳过终审，主 agent 自查即可。

然后跑自检直到退出码为 0：

```bash
python3 scripts/check_article.py <文章目录>/article.md --type <主类型>
```

脚本输出加粗串读提要——自己读一遍那一串，像词云或像把段落重念一遍都是挑错了落点，这要人来判断，脚本量不了。

**改稿后复核规则**：终审通过后，凡又修改了标题或正文含义的，先做一次限定范围的语义保真核对（对照基线，只查被改的部分——长文用 subagent，轻稿主 agent 自查），通过才能交付；纯排版、图片路径、front matter 状态更新不需要复核。

### 第 7 步：交付

0. **图片生产（默认执行，用户明确不要图时才跳过）**：正文图位与封面按 [visual-production.md](references/visual-production.md) 生产——交给 ckm-banner-design，或 SVG 自绘 + 浏览器截图均可，满足 brief 验收点即可。信息位图上的文字**逐字取自文章**，主题色与排版骨架一致；可编辑源文件（SVG/HTML）随 PNG 一起保留在 `imgs/src/`。生成后把正文图位占位替换为 `imgs/<文件名>.png` 真实路径——**终稿不得残留 placeholder**（此时 check_article 不再加 `--allow-placeholder`）。

1. 排版转换（纯本地，零依赖）。骨架按文章类型选：工程（技术/教程）、杂志（叙事/访谈）、简报（更新/快讯）；骨架与色板以**该账号**画像的「排版偏好」为默认：

   ```bash
   python3 scripts/md2wechat.py <文章目录>/article.md --skeleton <工程|杂志|简报> --palette <靛蓝|松绿|黛紫|绛红> -o <文章目录>/article.html
   # 不确定选哪个时先看对照页：--preview 生成三骨架 375px 样张，让用户挑
   ```

   输出的 HTML 全内联样式，全文复制粘贴进公众号编辑器即可用。

2. 交付清单（一次给全）：
   - `article.md`（终稿）+ `article.html`（粘贴用）+ 审读报告摘要（采纳/驳回计数 + 合规清零 + 遗留风险）
   - **3 个标题候选**（混两种以上风格，注明各自打法，避开 style-rules 的禁用套路）+ digest 摘要（80–120 字）
   - **封面 brief**：按 [visual-production.md](references/visual-production.md) 七步推导产出——2.35:1 规格、主标题 4–7 字且在中央 1:1 安全区、短标题（分享卡用）、张力一句话、形态与媒介、避雷项。需要直接出图时把 brief 交给 ckm-banner-design 执行，产出按「345px 缩略回看」验收
   - 图片状态：信息位/节奏位/实证位图是否就位；未生成的列出建议
3. 提醒用户：标题填在公众号后台（正文不含大标题）；图片需在编辑器中手动上传（走第 8 步草稿箱同步则自动上传）。

### 第 8 步：同步到公众号草稿箱（默认执行）

交付确认后**直接同步**——凭证配置完成即视为持续授权（用户说过「先审再同步」的，按其要求先展示等待确认）。用户明确说不不同步时才跳过。封面必须就位（草稿接口必填封面），正文图未全部就位时同步前说明。

前提：已认证公众号 + 环境变量凭证（后台「设置与开发 → 基本配置」获取，放 shell 环境变量，不进任何 git 文件）+ 调用方公网 IP 已加入**该账号**后台的 IP 白名单。**多账号**：默认账号配 `WECHAT_APP_ID` / `WECHAT_APP_SECRET`；每个号另配 `WECHAT_<账号key>_APP_ID` / `WECHAT_<账号key>_APP_SECRET`（key 用大写字母数字，如 `WECHAT_TECH_APP_ID`），同步时 `--account <key>` 选择——各账号的凭证、认证状态与 IP 白名单相互独立。

```bash
# 首次使用或怀疑凭证/IP 问题时先验证（只调 token 接口，不写内容）
python3 scripts/publish_draft.py . --check
# 多账号：验证/同步指定账号（读 WECHAT_<KEY>_APP_ID / WECHAT_<KEY>_APP_SECRET）
python3 scripts/publish_draft.py . --check --account <key>
# 确认执行计划（不联网）
python3 scripts/publish_draft.py <文章目录> --title "标题" --dry-run
# 正式同步：上传封面与正文图 → 替换为微信域名地址 → 写入草稿箱
python3 scripts/publish_draft.py <文章目录> --title "标题" --digest "摘要" --account <key>
```

同步成功即止：提示用户到「内容与互动 → 草稿」人工预览，**发表永远由用户手动完成**。脚本默认随草稿提交 2.35:1 与 1:1 两个封面裁剪框（居中最大区域，防标题被默认裁掉；封面设计满足中央安全区时效果最佳），`--no-crop` 可跳过。脚本已内置错误码翻译（48001 = 账号未认证无 API 权限；40164 = IP 不在白名单；40113 = 图片编码被素材接口拒，转 jpg 重试）；失败时保留本地文件原状，把错误提示给用户，不盲目重试超过一次。封面图缺失时先按封面 brief 生成（交给 ckm-banner-design）再同步。

## 失败模式与停手点

- **素材不足以支撑所选类型** → 停下来列出缺什么，让用户补素材或换类型；不编造垫稿。
- **审读意见互相冲突**（如保真要求与去模板化要求打架）→ 按手册判断顺序裁决：保信息 > 保类型 > 保作者声音 > 改表达；裁决不了的带两案问用户。
- **用户要「直接发表/群发」** → 拒绝：同步止于草稿箱，发表由用户在公众号后台手动完成；凭证缺失时给配置指引并停，不代填。
- `check_article.py` 跑不过且原因不明 → 先修硬规则项；脚本本身出错时报告错误，改为人工对照 style-rules 逐项检查，不假装通过。

## 反例黑名单

- 不把一次性总结、标题党、凑字注水当交付；篇幅区间是参考，结构完整优先。
- 不在简报类文章里强加个人故事、情绪曲线或价值升华；不为提高「共鸣」编造经历。
- 不用「随着 AI 的发展」「综上所述」这类零信息套话开头收尾；连接词只在承担真实顺序、转折、总结功能时保留。
- 不把技术术语当 AI 味删掉；技术解析保持应有正式度，不统一改成聊天语气。
- 不在没跑 check_article.py 的情况下宣称「自检通过」。
- 不把作者画像、素材中的私人内容复制进交付物或对外文件。
- 未获「一口气跑完」授权时，不把停点之间的多个步骤合并进同一回合执行。
- 不把「在回复中展示了产物」当作「已获得确认」——确认只能来自停点之后用户的下一条消息。

## Reference Map

- 五类型路由与各类型结构：[article-types.md](references/article-types.md)
- 公众号排版硬规则、标点规范、产出配额、标题规范：[style-rules.md](references/style-rules.md)
- 审读手册（去模板化 + AI 味指纹 + 平台合规 + 语义保真）：[review-playbook.md](references/review-playbook.md)
- 作者画像（风格；个人层 + 分账号层，渐进填充）：[author-profile.md](references/author-profile.md)
- 常用事实卡（作者本人事实，渐进填充）：[topic-facts.md](references/topic-facts.md)
- 封面与插图生产方法（七步推导 + ckm-banner-design 联动）：[visual-production.md](references/visual-production.md)