从选题到上线都自动：我用扣子项目空间搭了一个多角色内容生产流水线

一、为什么我开始把内容生产拆成流水线做内容这件事最怕的不是“不会写”而是流程不稳定。很多团队一开始都会这样选题先由一个人拍脑袋决定写作交给另一个人写完以后再找人看一遍看完之后再来改改完之后才发布表面上看所有环节都有人在做。但实际问题是选题经常偏写作风格不统一审核标准不一致发布前还要反复确认一篇内容来回折腾效率很低所以我后来做内容自动化时第一件事不是“让模型直接写文章”而是先把整个过程拆成一个多角色流水线。这条流水线大概是这样主编负责出题写手负责生成初稿质检负责检查问题修订负责补强内容发布负责整理格式并上线这样拆开的好处很明显每个节点只做一件事流程就会稳定很多。 关于作者米核AI易山专注AI自动化和智能体搭建。官网miheaii.com本文部分内容由 AI 辅助完成。二、为什么我选扣子项目空间来做这件事要做多角色协作最怕的就是流程散。如果所有节点都堆在一个工作流里你会很快遇到这些问题变量越来越多分支越来越复杂子任务不好拆每改一个地方都怕影响全局扣子项目空间比较适合做这件事是因为它天然更适合组织多个工作流、多个任务、多个角色。我理解它更像一个“项目容器”里面可以放主流程里面可以拆子工作流里面可以保存统一的项目状态里面可以围绕同一个主题反复协作这就很适合内容生产这种“有明确步骤、但又需要多人接力”的场景。我这次搭建的思路我没有直接把所有步骤做成一个超长工作流而是拆成了 4 层主流程控制整体节奏选题子流程负责出题和确认方向写作子流程负责写初稿质检子流程负责查错和修订建议发布子流程负责整理成最终可发版本这样做的核心价值是每个子工作流都能独立调试出问题也更容易定位。三、我怎么设计这条多角色流水线1主编节点先把方向定住内容生产最怕一开始方向就错了。所以我先让主编节点负责三件事明确主题明确受众明确内容边界比如这次我做的是“扣子项目空间内容生产流水线”那主编节点就要输出主题多角色协作目标自动化内容生产风格实战型、流程型约束不能太泛、不能空讲概念主编节点的作用不是写文章而是把整条流水线锁定在正确方向上。2写手节点只负责把内容写出来很多人写工作流会犯一个错在一个节点里既想控制方向又想生成内容还想自动润色。这样节点会变得非常重。我的做法是让写手节点只做一件事根据主编确认的主题生成初稿写手节点输入通常包含主题目标读者文章风格结构要求字数范围输出只保留初稿正文不额外塞太多解释。3质检节点负责挑问题不负责重写全文质检节点的职责非常重要。它不是来“重新写一遍文章”的而是来判断这篇内容有没有问题。质检节点重点检查标题是否明确开头有没有痛点内容有没有具体场景结构是不是清晰是否有可执行步骤是否存在明显空话我建议质检输出直接分三类通过需要修改不通过这样主流程可以根据结果自动决定直接进入发布回到写作子流程重写终止并提示人工介入4发布节点负责把结果变成可发稿很多人会忽略最后一步但其实最后一步很关键。发布节点主要做这些事统一标题格式生成摘要生成标签整理图片位置输出最终 Markdown这一步的目标不是再“创造内容”而是把所有内容整理成可以直接发布的形式。四、变量怎么传流程才不会乱多角色协作最容易出问题的地方其实不是模型能力而是变量传递。如果变量没设计好整个流水线就会出现这种情况主编节点输出了一套结构写手节点没读对字段质检节点拿到的是空值发布节点又重新猜了一遍最后就会变成“每个节点都像在工作但实际上没接上”。我建议的变量设计方式我会把变量分成三层1. 项目级变量用来记录整条流水线的全局状态比如主题当前阶段最终目标是否通过质检2. 节点级变量只用于单个节点内部比如写手初稿质检结果修改建议3. 输出级变量用于最终交付比如标题摘要正文标签图片位置说明这样分层后变量就不会互相污染。一个很实用的字段结构我建议你至少保留这些核心字段{ topic: 内容主题, target: 目标读者, tone: 文章风格, draft: 初稿正文, qc_status: 质检结果, final_title: 最终标题, summary: 摘要, tags: [标签1, 标签2], image_positions: [封面后, 第二节后, 结尾前] }这种结构的好处是每个阶段都知道自己该读什么每个节点的输出都能被下一步接住最后发布时不会乱五、子工作流怎么拆才不会越来越乱我一开始尝试把所有逻辑都塞在一个工作流里结果很快就发现排错困难逻辑臃肿改一个节点会牵一大片不方便复用所以后来我把它拆成了几个子工作流。我的拆法子工作流 1选题确认输入主题方向输出候选选题、推荐选题、待确认项子工作流 2初稿写作输入确认后的选题输出正文初稿子工作流 3内容质检输入初稿正文输出质检结果 修改建议子工作流 4最终整理输入通过质检后的内容输出标题、摘要、标签、正文、图片位置说明这样拆的好处每个子工作流都能单独测试以后换文章主题时不用重做全部流程质检失败时只回滚到对应步骤不影响整体项目这就是我觉得项目空间真正有价值的地方它不是把东西堆起来而是把复杂协作拆成可管理的模块。六、我在这条流水线里最重视的不是“生成”而是“回写”很多人做工作流只关注“模型能不能生成内容”。但真正要把流程跑起来回写状态非常重要。比如主编确认了选题是否写回项目状态写手出了初稿是否标记为“待质检”质检通过了没有是否自动切到发布阶段修改过后是不是能自动回到写作节点继续循环如果没有回写项目空间就会变成“大家都在忙但没人知道现在到哪一步了”。我建议的状态流转我一般会设计成这样的状态idea选题中drafting写作中checking质检中revise待修改ready可发布published已发布这样项目空间里任何人一看状态就知道内容走到哪一步了。七、这套流水线最容易踩的 3 个坑坑 1把所有节点都写得太大一个节点里塞太多逻辑后面会越来越难调。坑 2变量命名不统一今天叫topic明天叫title后面就没人知道哪个是哪个。坑 3质检只看结果不看结构如果只判断“字数够不够”而不判断“结构清不清晰”那质检就没有意义。我的解决方法一个节点只做一件事所有字段统一命名质检必须包含结构判断每一步都能回看上一步输出八、我最后得到的结论扣子项目空间真正适合的不是“一个超级长工作流”而是一条分工明确、状态清晰、可反复迭代的生产流水线。如果你把主编、写手、质检、发布拆开再用子工作流串起来整件事会轻很多方向更稳排错更快协作更顺以后复用也更方便对内容生产来说最值钱的不是一次写完而是下次还能用。而项目空间 子工作流恰好就是解决“可复用”这件事的。