wechat-writer

微信公众号文章的选题、研究、写作、改稿、审稿与交付工作流。Use when creating, outlining, researching, rewriting, auditing, or packaging Chinese WeChat Official Account articles, 微信文章, 公众号推文, 公众号长文, 热点解读, 干货教程, 观点文, 故事文, 对比测评, 复盘文,

SKILL.md

GitHub

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 分开,图片版不覆盖原始成稿。
  • 没有明确授权时,没有上传敏感内容或执行外部发布。