很多人做内容自动化，第一反应是让 AI 多写几版：公众号版，X 一版，即刻一版，小红书一版。

我之前的系统也接近这个状态：每天收集活动，整理会话，总结内容机会，再生成一组多平台草稿。这个流程能跑，但问题也很明显。

长内容和短内容没有独立计划。
固定文件名只能支持每天每平台一份草稿。
同一天重复运行时，旧机会、旧草稿和人工修改都有被覆盖的风险。
内容机会没有状态，无法表达新发现、已采用、待补证据、已发布、可 follow-up。

这些问题不解决，生成能力越强，系统越危险。

因为它会把“更多草稿”伪装成“更好的内容运营”。

我这次评审和推进的设计，把内容系统从简单的“机会 -> 多平台草稿”，改成了更接近真实运营的结构：

真实活动证据
-> 内容机会池
-> 内容计划
-> 分渠道草稿
-> 发布项和发布记录

这里最重要的变化，不是多了几个 JSON 文件，而是内容开始有生命周期。

一条机会不再只是“今天可以写什么”。它需要知道自己来自哪里，为什么值得讲，适合长文还是短帖，已经被采用还是还缺证据，是否已经发布，新增证据应该修订原稿还是生成 follow-up。

这和个人 IP 的真实工作方式更接近。

一个独立开发者、创作者或小团队，并不是每天都从零开始找灵感。更多时候，内容来自真实工作：一次设计评审、一次失败的自动化、一个店铺观察、一次发布链路修复、一个外部产品信号。

这些素材如果只进入“一次性草稿”，很快就会丢。
如果进入机会池，它们才可能被反复筛选、组合、追踪和复用。

这次设计评审里，我重点看的不是“AI 能不能写”，而是几个更具体的问题：

重复运行是否安全？
refresh 会不会删除当天目录？
rebuild 是否应该先归档？
已发布内容能不能被静默覆盖？
发布 receipt 是否能保护已有产物？
旧的 drafts/site.md、drafts/x.md 是否还能兼容？
长内容和短内容是否有不同策略？

这些听起来不像内容创作，但它们决定了内容自动化能不能长期用。

我越来越明确一个判断：内容自动化的第一阶段不是追求完全自动发布，而是保护人工劳动。

人工改过的稿子不能被覆盖。
已经发布的内容不能被系统当成草稿重写。
同一个机会不能被机械改写后铺到所有平台。
新证据来了，应该补充、修订或 follow-up，而不是污染旧记录。

目前这套系统还在工程实现和 review 中，不能说已经完整上线。。

这些问题反而说明，这不是一个 prompt demo，而是一个真实产品系统正在补课。

我觉得最可复用的不是具体文件名，而是这个判断：

如果你想做内容自动化，不要从“让 AI 写多少篇”开始。
先设计内容的生命周期。

一条内容从哪里来，什么时候被采用，发布后如何保护，新增证据如何处理，失败时如何回滚。

这些问题想清楚了，AI 写作才有意义。

否则，你得到的只是更多不可追溯、不可维护、不可放心发布的草稿。