wechat-writer

name	wechat-writer
description	微信公众号文章的选题、研究、写作、改稿、审稿与交付工作流。Use when creating, outlining, researching, rewriting, auditing, or packaging Chinese WeChat Official Account articles, 微信文章, 公众号推文, 公众号长文, 热点解读, 干货教程, 观点文, 故事文, 对比测评, 复盘文, 标题摘要, 配图方案, or 微信移动端排版稿. 通用网站 SEO 文章优先使用 writer；LinkedIn 长文优先使用 linkedin-writer；Medium 或英文叙事长文优先使用 medium-writer。

WeChat Writer

目标

把一个主题、链接、素材包或旧稿，整理成一篇准确、有判断、对读者有用、符合账号声音、适合微信移动端阅读的公众号成稿。

本 Skill 复用 writer 已有的事实核查、SEO 审计、humanization、图片打包和可选 R2 能力，但采用公众号优先的写作逻辑：

• 先明确读者问题、核心判断和证据边界，再考虑标题吸引力。
• 把事实、推断、观点和作者亲历分开管理。
• 默认连续完成任务书、研究、提纲、初稿、改稿和审稿；用户说“交互模式”时才在选题或提纲处暂停。
• “写一篇”默认只生成审过的本地成稿。配图、公共图片 URL 和外部发布都是独立动作。
• 不把微信搜索优化等同于 Google SEO，不按关键词密度堆词。

默认使用简体中文；用户指定其他语言或账号语言时跟随用户。

场景路由

先判断用户真正需要什么：

用户意图	执行范围
“今天写什么”“给几个选题”	只做选题与评分，不写正文
“写一篇公众号文章”	完整执行到本地审过的 article.md
“完整制作一篇”	成稿 + 图片方案/图片 + 微信交付包，不自动发布
“检查/审一下这篇”	只审稿；用户说“优化/改好”时直接改稿并复审
“模仿这个风格”	先建立临时风格指纹，再写作；不复制原句或虚构原作者经历
“学习我的修改”	对比修改，输出候选风格规则；只有重复出现或用户确认后才写入稳定档案
“推到草稿箱/发布”	先完成并封存成稿；只有另有可用发布工具且用户明确授权时才能执行外部发布

如果内容主要面向 Google 搜索，使用 ../SKILL.md。如果主要面向 LinkedIn Article、LinkedIn newsletter 或 LinkedIn 长文，使用 ../linkedin-writer/SKILL.md。如果主要面向 Medium 或第三方英文长文平台，使用 ../medium-writer/SKILL.md。

按需加载参考资料

必须完整读取与任务有关的参考文件：

• 新文章、改写、事实型内容：references/wechat-brief-and-evidence.md
• 选题、标题、开头、结构选择：references/frameworks-and-hooks.md
• 公众号语言、移动端阅读、图片和文件交付：references/mobile-writing-and-packaging.md
• 审稿、评分、修改与通过门槛：references/wechat-review-rubric.md
• 事实密集、产品比较或当前信息：../references/fact-check-and-style.md
• 完成事实与结构修改后的自然化：../references/humanization.md
• 图片文件、相对路径和可选 R2：../references/output-packaging.md
• 使用 R2 时：../references/r2-image-upload.md 和 ../references/r2-security.md

如果 profile/style-profile.md 存在，写作前读取它。不存在时不要把缺少风格档案当作错误；使用清晰、克制、具体的默认编辑声音。创建档案时以 profile/style-profile.example.md 为模板。

不可妥协的边界

1. 不编造数据、研究、引语、案例、产品能力、价格、发布日期或“业内消息”。
2. 不把模型记忆、搜索摘要或第三方范文标成已核实来源。
3. 只有用户在当前任务明确提供的经历、观察、原话或材料，才能写成作者亲历。
4. 无个人材料时可以写第一人称判断，但不能虚构“我的朋友”“我测试了”“那天我在现场”等事件。
5. 第三方范文只能校准结构、节奏和抽象风格特征，不能提供可复用的观点、句子、人物、对话或经历。
6. 标题不能为了打开率添加正文无法兑现的数字、身份、结果、恐惧或保证。
7. Humanization 不是 AI 检测规避。不得承诺“检测不出”或故意加入错误、口癖和假故事。
8. 写作、配图、排版、上传和发布是不同权限层级。完成正文不代表获得外部发布权限。

公众号文章任务卡

写作前创建或推断一张不超过 12 行的任务卡，保存到 wechat-brief.md：

• 账号/栏目：账号定位或本次栏目；未知时写“未提供”。
• 目标读者：谁会在什么场景点开。
• 真正问题：读者此刻想解决、判断或理解什么。
• 读后交付：读完能知道、相信、比较或执行什么。
• 核心判断：全文必须证明的一句话。
• 新增价值：相对常见文章多提供什么证据、角度、条件或方法。
• 文章类型：痛点解法 / 故事 / 清单 / 对比 / 热点解读 / 观点 / 复盘。
• 证据要求：需要核实的 3-6 个核心主张。
• 个人材料：可用 / 不可用；列明可用材料范围。
• 反方与边界：最强反对意见、适用条件和不适用场景。
• 目标长度：默认 1500-3000 个中文字符，按题材调整。
• CTA：读者下一步；没有商业目标时使用自然行动建议。

关键信息缺失时做保守假设并写入任务卡。只有主题、受众或立场存在实质歧义，且不同选择会明显改变文章时，才向用户提问。

工作模式

连续模式（默认）

内部按“任务卡 → 证据 → 框架 → 初稿 → 审稿 → 改稿 → 成稿”执行，一次性交付。不要为每一步等待确认。

交互模式

只有用户明确说“交互模式”“先给我选题”“先看提纲”时，在相应节点暂停。已确认的内容写入任务目录，继续时不要重新开始。

审稿模式

用户只说“检查”时输出报告，不擅自覆盖原文。用户说“优化、改好、完善、重写”时保存原稿副本，再直接修改并复审。

完整工作流

1. 建立任务目录

每篇文章使用独立目录：

writer/output/<article-slug>/

中文标题使用简短、可读的英文或拼音主题 slug。不要覆盖其他文章，也不要把多篇文章混在一个目录。

推荐状态文件：

wechat-brief.md
source-ledger.md
outline.md
draft.md
article.md
wechat-audit.md
image-plan.md

只创建任务实际需要的文件。draft.md 与 article.md 分开，确保初稿和成稿可追溯。

2. 选题与角度

用户没有给出明确选题时，生成 5-10 个候选选题。每个选题按以下维度各评 1-5 分：

• 读者相关性：是否对应账号受众的真实问题。
• 新鲜度：是否有新事实、新冲突或新解释；时效性内容必须检索。
• 可交付性：能否提供明确判断、方法、清单或决策条件。
• 证据可得性：能否找到可靠材料，而不是只靠情绪和常识。
• 账号匹配：是否符合栏目、声音和长期定位。

说明每个高分选题的切入角度与风险。不得把搜索结果数量、平台热榜或同题文章数量伪装成真实阅读量。

3. 建立主张—证据账本

完整读取 references/wechat-brief-and-evidence.md，围绕核心判断列出 3-6 个必须证明的主张。

对于数字、日期、引语、研究结论、产品特性、政策、价格、排名和时效性事实：

1. 打开原始页面核对上下文。
2. 优先官方文档、原始报告、当事方声明、标准、政府或研究论文。
3. 立即把“来源支持哪条具体主张”记录到 source-ledger.md。
4. 标记为 verified、user_provided、needs_verification、softened、removed 或 unsupported。
5. unsupported 主张不得进入初稿。

事实、推断、观点、个人材料必须分开。搜索不可用时，删除无法核实的具体数字和引语，把结论缩小为有边界的分析，并在审计中记录降级。

4. 选择文章骨架

完整读取 references/frameworks-and-hooks.md，从七类骨架中选择最符合任务卡的一类。不要让所有文章都变成“问题—原因—方法—总结”。

输出 outline.md，至少包含：

• 选定标题方向和读者承诺。
• 开头钩子及其材料来源。
• 3-6 个主章节。
• 每节服务的主张、证据和读者问题。
• 反方、限制或适用条件放在哪一节。
• 结尾要交付的判断或行动。

如果用户要求完整文章，提纲作为内部产物继续执行，不额外等待批准。

5. 标题与摘要

先生成 6-10 个不同机制的标题候选，再选择最准确、具体、可兑现的一个。候选应覆盖：

• 直接利益或任务。
• 反常识判断。
• 明确对象与场景。
• 对比或选择。
• 真实数字（仅当正文有证据）。
• 新闻/变化及其影响。
• 问题或张力。

18-28 个中文字符是常见的编辑建议，不是平台硬限制；标题应服从清晰和信息完整。禁用无证据的“暴涨、封神、必看、内幕、颠覆、所有人都错了”。

摘要默认 60-100 个中文字符，直接说明对象、核心价值和适合谁。不得只重复标题或留下无意义悬念。生成 3-5 个内部标签，供运营管理使用，不塞入正文。

6. 写初稿

完整读取 references/mobile-writing-and-packaging.md。写作时：

• 开头在前 120-180 个中文字符内进入真实问题、冲突、事实或核心判断。
• 每节先给读者一个明确推进，不复述标题。
• 一段只处理一个重点；多数段落为 1-4 句，长段按语义拆分。
• 事实后给解释，解释后给行动、条件、例子或判断标准。
• 观点写出推理链和边界，不用“大家都知道”“业内普遍认为”代替证据。
• 教程给前置条件、步骤、验证方式和常见错误。
• 对比先定义标准，再按使用场景给条件式建议。
• 热点文区分“发生了什么”“为什么重要”“对谁有影响”“下一步看什么”。
• 故事文只使用已记录的真实材料；材料不足时换成观察、问题或判断开头。
• 结尾回收核心判断，并给一个具体行动、选择或继续观察的信号。

默认不强制 FAQ。只有教程、解释、产品或搜索需求明显时，才加入 3-5 个真正的后续问题。

7. 事实核查与来源整理

逐项对照 source-ledger.md：

• 任何具体数字、日期、引述和当前状态都必须能回到原始来源。
• 事实与编辑判断要用措辞区分。
• 关键来源放在文末“参考资料”中，正文使用简短上标式编号或自然归因。
• 微信内外链能力可能变化；不要依赖正文中的大量可点击外链才能理解文章。
• 引用第三方内容时以原创概括为主，不复制对方结构、例子和结论。

8. 审稿、改稿与 humanization

完整读取 references/wechat-review-rubric.md。按“准确、观点、实用、合声、好读”五项各评 1-5 分。

通过条件：

• 平均分至少 4；
• 任一单项不低于 3；
• 没有阻断问题；
• 任务卡、主张账本、正文和结尾一致。

阻断问题包括虚假或无法支持的核心事实、虚构亲历、标题无法兑现、错误归因、危险建议或关键链接/代码失效。

能在现有材料内修正的问题必须直接改稿，最多进行两轮。第二轮仍有风险时，删除不可靠内容、缩小承诺或换成条件式结论，不把未通过的稿件标成成稿。

事实和结构问题解决后，完整读取 ../references/humanization.md，执行自然化并再次核对：

• 事实、数字、确定性和来源没有变化。
• 标题、摘要、关键词、链接、代码和图片路径仍正确。
• 没有新增虚构经历、空泛金句、套话、整齐得不自然的节奏或促销腔。

然后运行机械审计：

node writer/wechat-writer/scripts/audit-wechat-markdown.mjs \
  writer/output/<article-slug>/article.md \
  --keyword "<核心主题>"

脚本结果只用于定位结构和可读性风险，不替代事实核查和编辑判断。修正高影响问题后，把结果与人工判断写入 wechat-audit.md。

9. 图片与视觉（按需）

“写一篇”不默认生成图片，但应在 image-plan.md 中给出必要图片建议。用户说“完整制作、配封面、完整配图”时再生成。

• 封面：为微信裁切预留安全区，主体居中，尽量少放文字；实际上传前以当前平台预览为准。
• 内文图：优先解释流程、对比、步骤、数据关系或关键场景，而不是装饰。
• 默认生成 1 张封面和 1-3 张必要内文图；数量服从信息需要。
• 内文图可使用 16:9；封面同时准备适合微信宽封面裁切的版本或清晰裁切说明。
• 不伪造产品 UI、品牌 Logo、奖项、测量数据和客户案例。
• 图片 alt 文本描述内容即可，不堆关键词。

图片先保存在文章目录并使用相对路径。只有用户需要公共 URL，且 writer/config/r2.config.json 有效时，才按共享 R2 参考执行上传。缺少配置不是错误。

10. 交付与封存

正常公众号文章包至少包含：

writer/output/<article-slug>/
├── article.md
├── wechat-brief.md
├── source-ledger.md
└── wechat-audit.md

按需增加：

outline.md
draft.md
image-plan.md
cover-wechat.png
hero-16x9.png
section-01-16x9.png
article-with-images.md
image-urls.json

article.md 是审过的原始正文。配图或排版版本写到独立文件，不覆盖它。

最终回复只需说明：

• 选定标题和文章角度。
• 成稿、任务卡、来源账本和审计文件路径。
• 已核实来源数量与仍存在的验证限制。
• 图片是已生成、仅有方案，还是已上传。
• 是否执行了外部发布；未明确授权时必须是“未发布”。

最终成稿结构

article.md 使用下列结构，按题材灵活调整：

# 主标题

> 摘要：60-100 字，说明对象、价值和适合谁。

开头钩子与核心问题。

## 具体、能推进论证的小标题

正文……

## 反方、边界或使用条件

正文……

## 结尾标题（可选）

回收核心判断，给出具体行动或观察信号。

---

## 参考资料

1. 来源名称：文章或页面标题，日期，URL

## 公众号发布包

- 备选标题：
- 摘要：
- 标签：
- 封面方向：
- 内文图建议：
- CTA：
- 事实核查说明：

发布包是运营附录，不属于对外正文；复制到公众号编辑器前可按需删除。

完成检查

• 任务卡明确读者、问题、核心判断、新增价值、反方和边界。
• 3-6 个核心主张已进入证据账本，状态清楚。
• 每个具体事实都已核实、弱化、标注待核实或删除。
• 所有第一人称事件都来自用户明确提供的个人材料。
• 标题准确、具体、可兑现，摘要不是标题复述。
• 文章骨架与题材匹配，不是通用模板硬套。
• 开头尽快进入问题，章节持续推进，结尾交付行动或判断。
• 手机端段落可读，粗体、列表、引用和图片使用克制。
• 五维审稿达到通过门槛，阻断问题为零。
• Humanization 后重新核对事实、来源、链接、代码和图片路径。
• article.md 与 draft.md 分开，图片版不覆盖原始成稿。
• 没有明确授权时，没有上传敏感内容或执行外部发布。