一人媒体公司实操六个AI角色分工系统

一人媒体公司并不是"一个人加一个 AI 写文章"那么简单。真正的难点在于：持续找到值得写的选题、形成原创角度、并在多平台分发时不重复同一份内容。最近有一个圈内工程师把整套方案跑通了——用 6 个分工明确的 AI 角色 + 一个共享知识库,把人写媒体的全流程封装成一个闭环。整套系统的骨架很有意思,值得拆解。

大多数内容创作者用 AI 的方式是:打开对话框,给一个 prompt,得到一篇文章。看起来效率翻倍,但只要持续做三个月就会发现两个老问题:一是选题枯竭,二是多平台分发时同一份稿子被压成"小红书体"或"长贴文",结果哪边都不讨好。

这个工程师的解法绕开了"一个人"这个假设——它把内容生产拆成一个由 6 个角色组成的虚拟团队,每个角色只做一件事:Signal Scout 只找选题不写稿、Researcher 把选题变成有据可查的证据包、Content Strategist 出角度简报、Long-form Writer 写旗舰长文、Distribution Bot 按平台特性重构创意、Editor 跨平台审计。每一步交接都用结构化记录,机器人之间不能"合理猜测"补洞。

这套流程跑下来,选题环节的拒绝率反而变高了。Scout 的契约写得明确:"只评估不写作,且应否决远多于通过"。换句话说,大多数提交过来的选题想法都会被它打回,保护团队不为烂选题浪费时间。这与常见的"先写出来再说"的工作流完全相反。

二、四层基础设施,不是工具堆叠

把这套系统能跑起来的关键,不是 6 个机器人本身,而是底层的四层基建。

第一层是 Bot Mode——让团队可见、可对话。每个角色在协作面板里有独立头像和消息记录,不是埋在 prompt 里的隐形存在。第二层是 Profiles,每个角色有独立记忆/会话/技能,防止记忆互相污染。这点至关重要:如果让 Writer 读到 Scout 的会话历史,长文会本能地偏向 Scout 阶段的判断,角度就被锁死了。第三层是 Obsidian 知识库,存放共享的"编辑大脑"——声音、受众、论据、钩子、平台打法。所有机器人都从这里读,也向这里写。第四层是 Kanban 看板,任务在角色间持久流转,SQLite 支撑,可依赖、可评论、可重试、可人工介入。

这四层加在一起,本质上是把"团队"这个组织概念工程化了。6 个 AI 不再是 6 个工具,而是 6 个有边界、有记忆、有交接规范的角色。

三、三个关键机制决定系统能不能持续

第一个机制是可检查的结构化交接。每个 campaign 有一份贯穿全程的记录,从信号到研究、从角度到旗舰稿、从分发到数据。字段缺失就退回上一环节,不允许"合理猜测"补洞。这是防止多智能体系统质量滑坡的关键设计——没有结构化交接的协作,迟早会变成"所有人都在写、没有人负责"。

第二个机制是人守在编辑边界。第一版系统的设计哲学是"准备好一切,什么都不发"。人类保留批准权:核心角度、旗舰稿、重大事实声明、每条公开内容、以及任何打法规则的变更。每次批准或打回都成为训练系统的判断样本;当某类决策变得可预测,才把它下沉为规则。自动化消除的是重复决策,不是人类的品味。

第三个机制是数据反哺系统。系统每周围绕 Keep/Test/Stop 三个清单运转——Keep 是反复有效的打法、Test 值得再验证、Stop 是持续低效的规则。规则变更需人批准后才写入共享大脑;单次爆款只产生假设,不产生定律。

四、不追求一步到位的 MVP 路径

工程师明确给出落地建议:不要一上来就建 6 个角色。先建 Obsidian 大脑,只建 Scout/Researcher/Editor 三个角色,跑 3 个真实选题,再逐个加策略师、写手、分发,最后接数据闭环。

第一个可用版本只需交付三件东西:一个研究过的选题、一份角度简报、一条待批准的 X 帖子。这与"全自动 AI 媒体公司"听起来差得很远,但工程上更可靠——MVP 的目标不是炫技,而是验证闭环能转起来。可以沿用工程师分享的 Hermes Agent 方案,也可以用 Grok 等其他工具作为替代。

我的评价

这套系统的价值,不在于"AI 替代人写文章",而在于把"内容团队"这个概念拆解成可工程化的模块。这几年看过太多"全自动内容工厂"的失败案例,根因几乎都是同一件事:把所有判断压在一个大模型上,既当 Scout 又当 Writer 又当 Editor,最后输出要么是流水线上的标准废话,要么是某一环跑偏了整篇跟着歪。

把它拆成 6 个有契约的角色 + 共享知识库 + 结构化交接,等于把组织的核心机制用代码复刻了一遍。Obsidian 知识库本身就是组织内的"编辑大脑",Kanban 看板就是任务流转,人守在编辑边界就是"管理者的判断不可被自动化"。这套框架最值得借鉴的,是它承认了"判断"和"执行"是两个不同的东西,自动化只能接管后者。

不过要注意的是,这套系统的复杂度也不低。一个认真跑的 MVP 至少要花 2-4 周把 Obsidian 知识库初始化好、把 6 个角色的契约定义清楚、把看板和角色之间的握手跑通。对个人创作者来说,这套系统并不比"雇一个实习生 + 一个兼职编辑"更便宜——前提是你能找到愿意长期跟的实习生。

反面观点:六个角色真的有必要吗

必须承认,这六个角色分工对真正的一人创作者来说偏重。日常更新频率不高、平台单一、不需要复杂分发的创作者,根本不需要 Scout+Researcher+Strategist+Writer+Distribution+Editor 这条完整链路。对他们来说,一个能用的 Claude/GPT 写稿 prompt 加一个分发清单可能就够了。

更现实的判断是:这套系统的甜蜜点是"已经在多平台稳定产出、想从单兵作战升级为半团队作战"的创作者。一周产 1-2 篇稿、只发 1 个平台的人用这套系统属于过度工程化;但一周产 5+ 篇、覆盖 3 个以上平台、且对分发质量有要求的团队,这套框架能直接省下 1-2 个全职岗位的开支。

另一个潜在风险是知识库污染。Obsidian 大脑越积越多,角色之间的相互引用会逐渐模糊,这时就需要定期做"知识库瘦身"——把过时规则、失败案例、跨平台已经不适用的钩子全部归档。这部分工作目前还看不到成熟的自动化方案,依然依赖人工月度维护。