多平台内容工作流

把调研、写作、审校、标题、视觉、打包和验收编排成一次可追溯的本地运行。

什么时候用它

从简述开始

我只有一句创作方向，希望流程自动选择可行题目、完成调研，并继续推进所有生产阶段。

使用明确题目

我已经确定主题，需要两份母稿，以及公众号、小红书、知乎、微博和头条号的完整成稿。

使用已有大纲

我有一份 Markdown 大纲，希望先核实并规范结构，再生成标题、配图、公众号封面和干净的 HTML。

不接

它不适合快速润色、只起一个标题、只做一张图、只排版、内容发布、排期或发布后分析。

它会产出什么

终点是通过核验的本地交付包，不是已经发布的内容或平台草稿。

• 写作产物：生成两份平台中立母稿和十份经过审校的平台成稿
• 标题产物：生成精确的 34 个候选，并为每个平台选出一个标题
• 视觉产物：生成五套正文配图和一张固定尺寸的公众号封面
• 发布材料：组装平台目录、优化图片、公众号干净 HTML 和浏览器预览
• 过程记录：在 runs/<run-id>/ 保存版本、哈希、门禁、验收与恢复状态
• 外部动作：可能调研公开来源并调用通过校验的本地能力，所有交付物仍留在本地
• 绝不会做：登录平台、创建平台草稿、排期、发布或读取运营数据

Visual V3 将正文配图和公众号封面拆成两个独立生命周期。正文先通过五平台 Canary 屏障，再按 固定并发逐图生成、定向重试并复用哈希匹配的 PASS 原图；封面失败不会让已完成正文失效。所有 持久化产物只使用 run-relative 路径或 PortablePathRef，不保存解析后的本机用户路径或凭证。

前置条件与边界

前置条件

必须只提供一种入口：一句简述、一个明确题目、Markdown 大纲路径或粘贴的大纲。所需的本地能力及其对应协议必须可用。

相邻能力分工

需求	交给
只做调研	collect-sources
只做写作	draft-content
只做配图	post-illustration-images

不接的场景

• 轻量修改或单平台写作
• 只需要标题、图片、排版或审校
• 任何发布、排期、账号登录或发布后操作

容易混淆的边界

• 自主模式只按固定规则记录并通过门禁，不会冒充用户批准
• 审阅模式只在规定的决策点暂停
• 本地能力协议不匹配时会阻断初始化，不会悄悄换成通用处理