Content Factory：一个人的本地 AI 内容工厂

我第一次介绍 Content Factory 时，说得太像一个按钮

“一篇文章自动生成公众号、小红书、抖音和博客”，这句话很容易听懂，我也用过。可它恰好藏掉了系统里最难的部分。

同一份材料可以共用事实，却不能把同一段正文复制到四个平台；本地生成文件不代表排版能看；接口返回成功也不代表目标账号已经出现内容。更现实的问题是，三个月后回头更新文章时，还能不能找到当时的来源和版本。

Content Factory 不是为了把一篇变成四篇。它处理的是一个人长期做内容时最容易失控的几件事：材料散落、事实与推断混在一起、平台版本互相抄、发布状态只靠记忆。

所以我现在把它称为生产线。每一站留下东西，也留下责任。

一条内容在工厂里的最小单位

系统里的基本单位不是“文章”，而是一次带身份的内容运行。一次运行至少包含：

• 原始来源。
• 可引用事实。
• 未确认问题。
• 目标读者与搜索意图。
• Kenton 的主判断。
• 平台原生草稿。
• 封面与步骤素材。
• 质检结果。
• 授权记录。
• 平台回读。

这些对象不必都存成同一种格式，但必须能彼此对应。否则正文更新后，系统可能继续使用旧封面；平台出现草稿后，本地又不知道对应哪个版本。

当前结构：六层，而不是六个大模型

来源层

来源层保存链接、字幕、文档、截图、抓取时间和许可信息。原始材料尽量不被覆盖，后续生成的是派生文件。

这里的规则很简单：页面读不到，就记录读不到；只有搜索摘要，就标记为线索；没有日期，就不替来源补日期。

事实与判断层

这一层把信息拆成四种：

• 来源直接支持的事实。
• 多个事实组合出的推断。
• Kenton 的经验与选择。
• 仍需实测的问题。

平台 Writer 只能消费被允许的部分。涉及版本、价格、账号规则和软件入口时，还要记录最后核验时间。

选题层

选题不是“哪个词热就写哪个”。我同时看：

• 读者现在要解决什么问题。
• 这个问题是否有稳定搜索意图。
• 我是否具备验证条件。
• 制作截图和实测需要多少成本。
• 它与 AI、自动化和内容生产主线是否相关。
• 写完以后，读者自然应该去哪里。

如果一篇内容只有流量、没有验证条件或长期价值，它可以进入库存，但不必立刻生产。

平台生产层

公众号、博客、小红书和抖音拥有不同 Writer。它们共享事实包，不共享最终成品。

博客负责完整解释与搜索入口；公众号适合连续阅读；小红书需要图文节点；抖音要按真实画面动作组织旁白。

系统不追求“一次生成四份”，而是追求“四份不会互相矛盾”。

质量与授权层

质量检查至少包括来源、原创、时效、小白可读性、图片和商业路径。不同问题回到不同工位修复。

生成完成、排版完成、保存草稿和正式发布是四种状态。正式外部动作始终需要独立授权，不由前一步自动触发。

回读层

回读层保存平台真实状态、文章 URL、草稿标识、发布时间和必要反馈。

只有从目标系统读回，内容才从“本地完成”升级为“外部已确认”。超时或无法确认时，状态保留 unknown，不盲目重复提交。

数据怎样在层之间流动

逻辑链路可以压缩成下面这张图：

source evidence
  -> claims and unknowns
  -> topic decision
  -> platform package
  -> layout and editorial gates
  -> explicit authorization
  -> platform action
  -> external read-back

每个箭头都代表一次合同。上一步交付什么、下一步需要什么、缺失时停在哪，都要明确。

这也是本地优先的意义：不是所有事情都离线，而是重要中间资产先落在自己可管理的位置，不把平台后台当作唯一内容仓库。

用一条公开链接跑一次最小闭环

假设我发现一篇官方产品更新，想写成博客教程。

1. 保存来源

记录官方 URL、发布日期、更新日期和原始页面快照。第三方转述可以作为线索，但事实优先回到官方页面。

2. 建立事实表

把产品新增能力、适用版本、限制和未说明的问题分开。没有本地验证的能力不能写成“我已经使用”。

3. 决定读者问题

不是写“某产品重大更新”，而是选择一个用户会实际搜索的问题，例如“升级后原配置是否还能用”。

4. 在真实环境验证

保存操作步骤、版本、成功画面和失败信息。无法验证时，文章可以改成概念解释或暂缓，不用硬写实操。

5. 生成博客包

博客包包含正文、标题型封面、必要截图、摘要、标签、来源和唯一 CTA。封面围绕标题创作，不下载参考站图片。

6. 通过质量门

检查术语、步骤、成功标准、风险、来源与移动端。没有增量、只有换说法的文章不发布。

7. 人工决定发布

本地构建通过不等于线上已发布。获得授权后执行部署，再从公开 URL 读取实际页面。

8. 更新回读

记录公开地址、发布时间和后续需要更新的版本条件。未来产品变化时，能找到受影响文章。

这条闭环跑通以后，再考虑扩展到第二个平台。反过来先搭一个巨型看板，通常只会把未定义的问题可视化。

我怎样区分“已实现”和“想实现”

内容系统最容易出现产品幻觉：架构图里画出来的模块被当成已经可用。

我用三种标签约束自己：

已验证：在当前环境走过完整路径，并有对应文件或平台回读。

局部可用：某个环节能够工作，但前后仍需人工连接。

规划中：只有设计和接口设想，没有真实运行证据。

例如本地生成文章、创建封面和静态构建可以各自成立，但没有生产 URL 回读时，不能写成“已经上线”。同样，本地发布包准备好，也不等于平台草稿已存在。

衡量工厂，不看每天生成多少篇

生成数量很容易被模型放大，却不代表内容资产增长。我更关注这些指标：

• 找回一条原始来源需要多久。
• 一项事实被复用时，是否仍带着证据和日期。
• 一次失败能否定位到具体工位。
• 不同平台是否出现事实冲突。
• 平台状态是否有真实回读。
• 一篇文章过期时，能否知道受哪个版本影响。
• 读者是否沿学习路径继续阅读或进入相关服务。

如果每天生成十篇，但来源、版本和状态都找不到，工厂只是更快制造库存。

本地优先不等于完全不使用云

模型调用、平台接口、图片服务和部署都可能发生在外部。关键问题是：发送了什么，谁授权，返回了什么，结果是否保存。

敏感素材、账号凭据和未公开内容不应因为“自动化需要”就默认进入所有模型。可以使用脱敏样本、临时凭证和最小权限完成验证。

本地优先是一种控制策略，不是一种技术宗教。

商业路径应该在解决问题之后出现

Content Factory 最终会承接工作流咨询与内容生产需求，但每篇文章不能同时要求读者关注、加群、订阅、购买和提交表单。

通用教程先带读者走下一篇；自动化文章可以展示现成工作流；真实案例再邀请读者提交自己的流程。每篇只保留一个与问题相关的动作。

这样商业感来自“这套方法确实能工作”，而不是来自更大的按钮。

一个人怎样开始

不要先支持全部平台。选一条已经公开过的真实内容，补齐四个节点：

1. 原始来源。
2. 可核验事实和自己的判断。
3. 当前平台成品。
4. 真实发布证据。

再补一个失败出口：如果平台状态不明，流程怎样停。

先把一条真实内容的来源、判断、平台成品和发布证据对齐。做到这里，它才从一次输出变成可更新的资产。至于大看板和全平台自动化，都可以往后排。