要在 OnSolo 上把文案、编辑、设计等角色组织成一条稳定的内容生产流水线，关键不是去找某个隐藏开关，而是先确认账号当前开放了哪些角色类型，然后把每个创作动作拆成有明确输入输出的节点，再给节点绑定负责人和审批规则。以下步骤不依赖特定版本，只围绕界面里能看到和表单里能填写的配置项展开。
判断：多角色工作流能否跑通，取决于账号角色是否可分配、节点输入输出是否明确、负责人与审批规则是否覆盖每个交接点。操作上，先查角色配置入口，再按“需求输入→初稿生成→人工修改→审核→发布”拆节点，用项目ID关联各节点，最后用一篇短文章试跑全流程。验证方式：观察任务流转日志并修正失败节点。边界：不同套餐开放的角色数量不同，配置入口名称也可能有差异，需要结合当前环境确认。
先确认当前账号可用的角色类型
进入 OnSolo 的设置或成员管理入口，通常能看到“角色”或“权限”列表。如果当前页面没有明显的角色配置项，可以检查侧边栏的“成员管理”“项目设置”或“工作流”模块。不同套餐开放的角色数量可能不同，建议先确认下面三类角色是否可用：
- 编辑：负责修改稿件、调整结构，通常持有内容编辑权限，不直接发布。
- 审核：负责检查内容质量、合规性和事实错误，通常持有审核通过/驳回权限。
- 发布：负责最终发布，通常持有发布权限，且只能操作已审核通过的内容。
如果账号可用角色中没有你需要的类型，可以考虑用“管理员”或“自定义角色”临时替代，或者核对当前套餐是否包含协作功能。先确认这一步，能避免后面配置好节点却无法分配负责人的问题。
按创作流程拆分工作流节点
把从需求到成品的动作映射为节点，每个节点都需要有明确的输入、输出和执行动作。常见拆分方式是：
- 需求输入：输入是原始需求，输出是一张包含选题、要求、素材的需求单。
- 初稿生成：输入需求单，输出初稿内容。
- 人工修改：输入初稿，输出修改后的稿件。
- 审核：输入修改稿，输出审核通过或驳回的意见。
- 发布：输入审核通过的稿件，输出已发布文章及链接。
节点之间需要靠业务字段串联。OnSolo 中比较通用的做法是使用“项目ID”或“任务ID”作为关联标识。例如，在“初稿生成”节点的输出中填写项目ID，后续节点按这个ID拉取上一节点产物，就能避免角色之间交接混乱。
为每个节点设置负责人与审批规则
节点配置的核心字段通常包括：负责人、审批开关、审批人、超时提醒阈值。负责人决定谁来执行该节点；审批开关决定该节点完成后是否需要其他人确认；审批人决定谁来确认；超时提醒阈值用于防止任务一直卡在某个节点。下面给出一个通用的 YAML 骨架，字段名可以根据 OnSolo 的表单调整：
nodes:
- id: node_input
type: input
title: 需求输入
owner: project_admin
input: 无
output: 需求单
approval: false
timeout_hours: 24
- id: node_draft
type: content
title: 初稿生成
owner: writer
input: 需求单
output: 初稿
approval: true
approval_owner: editor
timeout_hours: 48
- id: node_review
type: review
title: 人工修改
owner: writer
input: 初稿
output: 修改稿
approval: true
approval_owner: editor
timeout_hours: 24
- id: node_edit
type: edit
title: 审核
owner: editor
input: 修改稿
output: 审核稿
approval: true
approval_owner: publisher
timeout_hours: 12
- id: node_publish
type: publish
title: 发布
owner: publisher
input: 审核稿
output: 已发布文章
approval: false
timeout_hours: 6如果 OnSolo 不支持直接导入 YAML，可以按这个骨架在界面表单里逐项填写。重点是确认每个节点都有“负责人”和“审批人”两个字段，并且审批开关在需要双方确认的节点上保持开启。超时提醒阈值先保守设置，比如初稿生成给 48 小时，人工修改给 24 小时，后续再根据实际节奏调整。
用最小案例验证工作流
配置完成后，不要直接铺开到全量内容，先用一篇短文章跑通全流程。执行步骤建议如下：
- 在 OnSolo 中创建测试项目，项目名如“工作流验证”，并记录项目ID。
- 在项目里添加三个角色：编辑、审核、发布，并分别指定负责人。
- 从“需求输入”节点开始，提交一个真实但简单的需求，例如“写一篇 300 字的新功能说明”。
- 观察任务流转日志，看任务是否依次经过初稿生成、人工修改、审核、发布，并检查每个节点是否被正确的负责人接收。
- 在任意节点手动驳回一次，确认驳回后任务回到上一节点并重新流转。
- 记录失败点，常见失败情况有：节点未串联、负责人无权限、审批人未收到通知。
如果测试中某个节点卡住，优先检查该节点的负责人是否已被添加为项目成员，以及审批人是否与负责人在同一权限层级。跑通最小案例后，再逐步加入设计、排版等角色，并调整超时阈值。