Wechat Writer

WeChat Writer

目标

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

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

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

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

场景路由

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

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