WeChat Article Quality Gate
把公众号文章从“内容正确”推进到“手机上好读、重点清楚、没有编辑痕迹、可以放心发布”。不同内容可选择不同叙事风格,但必须共享同一套事实与审美底线。
Required references
开始审稿前读取:
references/style-benchmarks.md:选择最适合内容的叙事风格。references/quality-checklist.md:执行统一事实、文字、排版、媒体和发布检查。
参考文章只用于抽象结构和视觉规律。不得复制其句子、段落、标题公式或装饰模板。
Route the task before applying the gate
先根据用户要求的最终结果选择一个模式,不得把低风险任务自动升级成发布流程:
| 模式 | 触发条件 | 本次交付 |
|---|---|---|
WRITE |
起草、改写、润色、排版文案,但没有要求判断能否发布 | 直接交付成稿;不输出 PASS/BLOCK、脚本状态或发布清单 |
REVIEW |
审查、纠错、事实核对、去 AI 味 | 输出问题、修订稿和已实际完成的检查;不声称已通过手机预览 |
PREFLIGHT |
判断是否可发、上传草稿、检查预览 | 执行完整门禁,结论为 READY_FOR_PREVIEW 或 BLOCK |
PUBLISH |
明确要求在公众号后台发布 | 执行完整门禁和平台操作;只有取得平台成功回执后才能写“已发布” |
用户意图不明确时选择影响更小的模式。文章“准备以后发公众号”不等于已经授权上传或发布。
WRITE 模式必须保护原稿尺度与声音:除非用户要求扩写,成稿长度不得明显超过素材,短手记不强加编号章节,不附流程化核对表。
Workflow
1. Establish the working truth
先确认文章的受众、目的、最新口径、发布时间和已有媒体素材。以用户最后一次明确修改为最高优先级,旧稿、旧表格和历史数字只能作为待核对材料。
建立一张简短事实表,至少覆盖:人名与角色名、日期、数量、比例、目标与现状、地点、待遇、链接、行动入口。遇到来源冲突时暂停发布结论,明确列出冲突,不自行拼接口径。
涉及“第 N 天”、周年、倒计时或连续记录时,单独登记事件日期/系列起算日、目标事件日期(如适用)、时区和拟发布日期。系列天数按事件日期计算:包含起算日时使用事件日期与起算日的日历日差 + 1;不得默认用写稿日、上传日或发布日期代替事件日期。任一必要日期、起算规则或总天数未确认时保留明确占位并在 PREFLIGHT/PUBLISH 阻断,不猜测“第几天”。
2. Run the static audit when evidence exists
REVIEW、PREFLIGHT、PUBLISH 模式下,如果存在可读取的本地 Markdown 或 HTML,运行:
python3 scripts/audit_article.py /absolute/path/to/article.md --json
脚本的 blocker 必须全部清零。warning 需要人工判断并在交付中说明处理结果。没有文件或没有实际执行命令时,检查状态只能写“未运行”;脚本通过不等于文章已经通过事实审查。WRITE 模式不为展示流程而强行运行或汇报脚本。
🔴 CHECKPOINT · Evidence before claims
写出“无 blocker”“预览通过”或“已发布”前,必须分别持有真实脚本输出、手机预览证据或平台成功回执;缺一项就 🛑 STOP,不得用推测补齐。
| 触发条件 | 一线修复 | 仍失败时 |
|---|---|---|
| 无本地稿或脚本报错 | 基于现有文字人工审查并标记“脚本未运行” | 不得声称静态检查通过 |
| 日期、数字、名称或目标状态冲突 | 列出冲突并回到用户最新明确口径 | 保持 BLOCK,不拼接答案 |
| 视频卡片或手机预览不可验证 | 在真实编辑器重新插入并预览 | 最高只到 READY_FOR_PREVIEW |
| 未登录、无发布工具或无成功回执 | 只交付待发稿并说明缺失条件 | 不得声称已保存、上传或发布 |
3. Choose one primary style
根据内容选一个主风格,最多混入另一个风格的局部手法:
- 行业判断:冲突开场 + 多方证据 + 结构化拆解。
- 经营方法:真实实验/现场 + 问题递进 + 数字验证 + 行动清单。
- 风险科普:事件切入 + 类比解释 + 证据来源 + 边界结论。
- 个人经验:第一人称习惯/经历 + 具体细节 + 轻判断 + 当天可行动建议。
铁头彬/HAVO 内容默认优先“真实现场 + 数字证据 + 轻判断 + 具体行动”,保持说人话,不写成咨询报告。
4. Rewrite for mobile reading
先重构信息层级,再处理字体颜色。推荐骨架:
- 标题:具体对象、冲突或结果,避免空泛口号。
- 开头:150 字内交代现场、反差或最关键问题。
- 正文:每节只回答一个问题;每段一个意思。
- 证据:数字、人物、动作、对话或案例紧跟判断。
- 收束:给出作者判断、明确行动或唯一入口。
正文以 16–17px、1.75–2.0 行高、0.5–1px 字距为稳定基线。正文色用近黑或深灰,只保留一个主强调色;整篇最多再加一个辅助色。减少卡片、粗体、底色和居中句的数量,让重点真正稀缺。
5. Apply hard gates
REVIEW、PREFLIGHT、PUBLISH 必须执行 references/quality-checklist.md 的一票否决项;命中即 BLOCK。WRITE 在成稿中直接修正,不输出门禁状态。
Red-light anti-patterns
- 禁止未运行脚本却写“无 blocker”;只能写“未运行”。
- 禁止把
WRITE升级成发布审查,或附加BLOCK、核对表和流程元信息。 - 禁止把短素材擅自扩成长文、强套编号章节或改成咨询报告。
- 禁止把裸链接当成已嵌入的视频号卡片,把本地改稿当成线上已更新。
- 禁止猜测日期、名称、数字和状态,或把目标、要求写成已实现结果。
- 禁止用发布日期或当前日期替代事件日期计算“第 N 天”;起算日、时区或计算规则不清时必须阻断发布。
- 禁止在没有明确授权和平台成功回执时声称已保存、上传或发布。
6. Preview before publish
任何上传或发布动作前都要检查手机预览,而不只看 Markdown/HTML:
- 首屏能否在 5 秒内看懂文章讲什么。
- 每屏是否只有一个视觉重点。
- 视频号卡片是否真实出现且可点击,不是裸链接或错误占位图。
- 图片是否清晰、比例统一、前后留白一致。
- 目录、编号、引用、列表在微信编辑器中是否变形。
- 文末入口是否唯一、准确、可执行。
用户只要求审查时,不上传、不保存平台草稿、不发布。PUBLISH 模式必须先满足 PASS,再执行已授权的发布步骤。已经发布的文章不能被当作已通过本地改稿自动回写;需明确说明平台可用的更正方式。
7. Run the audit again
修改后再次运行脚本,并按 references/quality-checklist.md 人工复核。只有“无 blocker + 总分至少 85 + 手机预览通过”才给出 PASS。
Output contract by mode
WRITE:只交付成稿;用户要求时再附标题、摘要或简短风格说明。
REVIEW:交付问题清单、修订稿、已完成检查及仍待核对项。没有发布请求时不判定发布 BLOCK。
PREFLIGHT、PUBLISH 至少交付:
结论:PREFLIGHT使用READY_FOR_PREVIEW/BLOCK;PUBLISH使用PASS/BLOCK。阻断问题:按事实、文字、排版、媒体分类;无则写“无”。风格选择:说明主风格及为什么适合本文。修订稿:可以直接进入公众号编辑器的完整版本。排版规格:正文、标题、强调色、图片/视频卡片位置。核对表:关键数字、名称、链接、预览状态和脚本结果。
不要只给泛泛建议。只要用户授权“修改”,就直接修订本地稿并验证;发布权限仍以用户明确授权为准。