wechat-article-writer

name	wechat-article-writer
description	按 content-brief 写公众号完整文章。当用户说"写文章"、"按 brief 写"、"帮我写公众号"时使用。分两阶段：先出标题+确认大纲，再写全文。完稿后自动串联审稿。

WeChat Article Writer

母规则

创作是对话。 写每一个字之前，想清楚对面坐的是谁，他在想什么，他为什么要听你说下去。

没有观点的内容是信息搬运。 如果 brief 的核心判断站不住，先回去改 brief，不要硬写。

触发条件

• 用户说"写文章"、"按 brief 写"、"帮我写公众号"
• 用户提供了 content-brief.md，要求写正文
• 用户说"帮我从选题到成稿走一遍"（由 writing-hub 编排时触发）

不触发：

• "整理 brief" → content-brief-builder
• "改标题"、"去AI味" → content-polisher
• "发草稿箱" → wechat-draft-publisher

不做什么

• 不做选题、不做 brief
• 不做包装改稿（标题优化、开头重写等由 content-polisher 负责）
• 不做发布

执行模式

模式	触发方式	Step 2 行为
交互模式	直接对话调用	出标题+大纲，停下来等用户确认
自动模式	被 writing-hub 串联调用，或用户说"直接写"	跳过确认，用 brief 大纲 + 评分最高的标题

执行流程

Step 0: 读取定制配置

读取 _shared/extend-system.md，检查项目级和用户级 EXTEND.md 是否存在：

• 排版参数覆盖（字号、颜色等）
• 文章类型预设扩展
• 品牌信息

Step 0.5: 写前门控

读取 references/pre-write-checks.md 中的写前门控清单，检查 brief 的：

1. 核心判断：能不能一句话说清楚？够不够硬？
2. 读者定义：够不够具体？
3. 素材充足度：至少 3 条可用素材？

任何一项不通过 → 停下来告诉用户哪里不够，建议先改 brief。不硬写。

Step 1: 读取 Brief

读取用户指定的 content-brief.md 文件，提取：

• 目标读者、核心判断、切入角度
• SCQA 结构
• 推荐框架
• 素材清单
• 章节大纲（content-brief-builder 产出的 brief 通常已包含分章节大纲，含每章的目的、内容、素材、语气、字数）

Step 2: 阶段一——出标题 + 确认大纲

标题：读取 _shared/title-and-packaging.md，按标题 5 大原则生成 3 个候选标题。

大纲：

• 如果 brief 中包含章节大纲（通常如此）：直接呈现 brief 中的大纲给用户确认，不重新生成
• 如果 brief 中没有章节大纲：基于 SCQA 和推荐框架自动生成提纲，每个章节包含：

章节序号: number
章节标题: string
本节观点: string            # 这一节要传递的核心观点（一句话）
本节在整篇里的作用: string  # 为什么需要这一节
用哪条素材: string
大概字数: number

停下来等用户确认标题和大纲。 不要直接跳到写全文。

Step 3: 阶段二——写全文

用户确认标题和大纲后，按大纲逐章节写作。

读取 references/framework-selection.md，遵守：

• 根据文章类型预设对齐所有维度（框架 × 语调 × 配图风格 × 结尾模板）
• 分段写作法：每章独立交付价值
• 开头用 _shared/hook-and-ending.md 中的模板
• 结尾用同一文件中的模板
• 遵守去 AI 痕迹规则

读取 _shared/wechat-channel-profile.md，遵守排版规范。

Step 4: 自检

读取 references/pre-write-checks.md 中的写后自检清单，逐条自检。 不通过的项目先自行修复。

Step 5: 输出

读取 _shared/intermediate-format.md 中 article-draft.md 的格式规范，按格式输出。

article-draft.md 中只包含最终确认的标题（不是 3 个候选）。3 个候选标题是 Step 2 的交互状态，不写入最终产物。

在 article-draft.md 头部追加文章类型预设信息，供下游 wechat-draft-publisher 读取：

文章预设: deep-insight|story-time|hot-take|how-to|quick-list
主题色: default|warm|dark

输出到本地文件：article-draft-<选题关键词>.md

Step 6: 自动串联审稿

完稿后自动调用 adversarial-content-review Skill，将 article-draft.md 送去审稿。

审稿产物处理：

审稿结论	处理方式
通过（≥8分）	呈现 review-report.md 给用户，完成
需修改	按修改建议做针对性修复，覆盖 article-draft-<keyword>.md，呈现 review-report + 修订说明
需重写	呈现 review-report.md 给用户，不自动重写，建议用户考虑是否需要修改 brief

产物位置：

• review-report-<关键词>.md：与 article-draft 同目录
• 修订后的文章直接覆盖原 article-draft-<keyword>.md

Guardrails

• 必须先通过写前门控，核心判断不够硬时不硬写
• 交互模式下必须先出标题+确认大纲，用户确认后再写全文；自动模式下跳过确认
• brief 中已有章节大纲时，直接使用，不重新生成
• 优先使用 EXTEND.md 中的定制配置（排版参数、品牌信息、预设扩展）
• 正文每段不超过 5 行，每句不超过 25 字
• 标题 3 个候选必须符合 5 大原则之一
• 写完全文后做一遍去AI痕迹检查
• 如果 brief 中有明确的核心判断，正文不能跑偏
• 字数控制在 1500-3000 字
• 审稿结论为"需重写"时，不自动重写，交由用户决定