把公众号写作做成一条不会偷跑的流水线

那个最诱人的按钮，我暂时没有做

内容流水线最容易演示的画面，是输入一个选题，几分钟后页面跳出“发布成功”。这个画面很好卖，但我不敢把真实公众号交给它。

一篇文章从来源到群发，中间至少会经过事实、正文、排版、素材、账号和平台状态。任何一层猜错，最后那个绿色提示都可能只是把错误推得更远。

最开始我想做的是加速，实际先做的却是刹车：每一步都能停，停下以后还能说清楚卡在哪里。因为下面四种情况，绝不能被同一个“成功”盖过去：

• 来源可能不可靠。
• 模型可能补出没有发生的案例。
• 排版成功不等于移动端可读。
• 接口收到请求不等于目标账号里已有正确草稿。

所以生成、排版、存草稿和群发没有共用一个按钮。速度可以晚一点补，失控之后的重复群发很难补救。

一条内容在系统里不是一篇文章，而是一次运行

我把每次生产看作一个独立 run。它至少要回答这些问题：

• 输入来自哪里。
• 哪些说法已经核验。
• 当前正文是哪一个版本。
• 排版文件由哪个版本生成。
• 准备进入哪个账号。
• 平台是否已经读回。
• 下一步是否获得授权。

具体文件名可以因项目而变，但内容合同不应该缺。一个最小运行目录可以表达为：

run/
  sources/          原始链接、文档与截图
  claims.json       可引用事实、限制与待核验项
  article.md        当前正文
  rendered.html     排版后的平台版本
  assets/           自制封面与正文图片
  receipt.json      本地动作与平台回读

这不是要求所有人照抄目录，而是提醒自己：来源、事实、正文、视觉和平台状态不能混在一个文件里。

六个工位，各自只做一件事

来源工位：保留原文，不急着写观点

这里保存原始 URL、作者、发布日期、更新时间和许可信息。搜索摘要只负责发现线索，不能直接进入事实表。

页面读不到时，状态是“来源缺失”，不是让模型根据标题补齐正文。

事实工位：把四种句子分开

文章里的句子至少分成四类：

• 来源直接支持的事实。
• 根据多个事实作出的推断。
• Kenton 的经验与判断。
• 尚未完成的验证。

这一步很重要，因为模型最擅长把四类句子写成同一种肯定语气。事实表保留来源和支持程度，Writer 才知道哪些能写，哪些要留白。

成稿工位：围绕一个读者问题组织

成稿不是把事实表扩写得更顺，而是给一个明确读者设计理解顺序。技术教程要有前置条件、动作、成功标志和失败出口；案例复盘要交代背景、证据、选择和代价。

模型可以组织表达，但不能凭空补本地测试、用户反馈、平台权限和业务结果。

排版工位：转换，不改结论

排版器只处理标题层级、段落、列表、代码、图片与平台 HTML。它不能以“增强传播力”为理由添加金句、夸张承诺或固定广告尾巴。

转换后至少要留下 Markdown 和 HTML 两个版本。页面出错时，才能知道问题来自正文还是转换。

草稿工位：提交之后必须回读

本地生成出 HTML，只能说明“本地成品存在”。

平台接口返回标识，只能说明“请求被受理”。

从目标账号读回标题、正文、封面和草稿标识，才可以标记为“草稿已确认”。

这三个状态不能用同一个“成功”代替。

群发工位：使用一次性授权

群发与存草稿是两种不同风险的动作。群发授权只对当前账号、当前文章版本和当前时间窗口有效。

正文或封面发生变化后，旧授权失效。上一次允许发布，也不代表下一篇自动获得权限。

状态名必须让人看得出证据在哪

我避免使用含糊的 done，而是保留证据层级：

collected
claims_ready
drafted
layout_checked
draft_submitted
draft_confirmed
publish_authorized
published_confirmed
unknown

其中最关键的是 unknown。

接口超时、页面断开或回读失败时，系统不知道平台有没有接收。unknown 既不是失败，也不是成功。此时自动重试可能制造重复草稿，继续发布则可能造成重复群发。

正确动作是冻结当前 run，先从平台读取列表、标识或页面状态。没有新证据前，状态保持 unknown。

一次真实失败应该怎样定位

假设保存草稿后，后台没有立即显示新文章。

不要从找资料重新跑一遍。按证据逐层检查：

1. article.md 是否冻结：确认本次提交对应哪个正文版本。
2. rendered.html 是否完整：标题、图片引用和正文是否存在。
3. 请求是否发出：查看时间、目标账号和平台返回标识。
4. 平台是否可回读：用草稿读取接口或当前后台查询。
5. 是否已有同标题草稿：比较标识与创建时间，不凭标题直接删除。
6. 仍无法确认：保留 unknown，停止盲目重试。

这样做看起来比“再点一次”慢，但它避免了最难处理的错误：系统制造了重复结果，却没有记录哪一个才是真的。

我给自动化设置的三条硬边界

第一条：写作权限不能自然升级为发布权限。

负责研究和写稿的工具不需要持有群发能力。即使使用同一个程序，动作入口也要独立。

第二条：高风险动作默认失败关闭。

缺账号、缺授权、缺素材或缺回读时，流程停下，而不是猜一个默认值继续。

第三条：平台状态只由平台证据升级。

本地文件、HTTP 状态码和界面提示都有价值，但各自只能证明有限事实。必须拿到目标系统的回读，才能声称外部动作完成。

最小版本不需要大后台

如果你现在完全靠手工，不要先造一个全功能控制台。用一篇真实文章跑通下面的闭环就够了：

1. 保存两个可靠来源。
2. 写一张事实表。
3. 生成一份 Markdown。
4. 手工检查排版后的 HTML。
5. 只保存到草稿。
6. 从目标账号读回草稿。
7. 人工确认后再决定是否群发。

这七步里，每一步都要能指出输入、输出和通过条件。等它连续稳定，再把机械步骤自动化。

我现在判断一条流水线是否成熟，不看它少点了几次按钮，而看出错时能否停在正确工位。拿一篇已经发过的文章倒推一遍，逐站写下“缺什么证据就停”。这张纸通常比再装一个一键发布工具更有用。