Level 3 写作班子架构设计方案

项目名称：内容创作部门 Level 3 架构升级
统筹负责：RainBox (主 Agent)
协作负责：HR Manager
设计日期：2026-03-22
版本：v1.0

🎯 项目目标

将内容创作部门从原来的 2 个全能型 Agent（xiaohongshu-writer 和 webnovel-writer）升级为 Level 3 写作班子架构：

小红书业务线：3 个子 Agent（策划+写手+编辑）+ 1 个编排器
网文业务线：3 个子 Agent（策划+写手+编辑）+ 1 个编排器

核心理念：

"三个角色，各管各的阶段，谁也不越界。用编排器把它们串起来。"

📊 三个角色的职责定义

通用职责边界（非常重要！）

角色	做什么	不做什么	交付物
策划（Planner）	项目分析、选题策划、大纲设计	❌ 不写正文	系列规划、控制态大纲
写手（Writer）	根据大纲撰写初稿和定稿	❌ 不做验收（不自己审核）	初稿、定稿文本
编辑（Editor）	深度分析、定稿审核、质量把控	❌ 不改文章（只出报告）	分析报告、检查清单评估

为什么边界要这么硬？

一旦角色边界模糊，AI 就会"自我和解"——写手写完觉得还行，编辑看了也觉得还行，最后质量就下去了。

📋 策划（Planner）：定结构，不写字

核心职责

阶段	具体工作	产出物
项目分析	了解项目背景、目标、受众	项目分析报告
系列规划	确定系列定位、内容矩阵、暗线设计、阅读路径	系列规划文档（11 slot 模板）
大纲设计	创建章节骨架和控制态大纲	控制态大纲（~400 行）

大纲的两个版本

初稿态大纲（~200 行）

章节骨架
结构框架
主题分布

控制态大纲（~400 行）⭐ 核心产物

包含 12 维度控制信息：
1. 每章预期字数
2. 核心立意
3. 素材分布
4. 风格标记
5. 悬念设置（网文）
6. 爽点分布（网文）
7. 情感基调（小红书）
8. Emoji 密度（小红书）
9. 人物出场
10. 世界观元素
11. 前后呼应点
12. 预期效果

控制态大纲是整个流水线最重要的中间产物，写手和编辑都依赖它工作。

工作原则

只管结构，不写正文
信息完整性：11 个 slot 全填满，12 维度控制信息齐全
交付即结束：交出大纲后，任务结束，不参与后续写作

✍️ 写手（Writer）：只管写，不管审

核心职责

阶段	具体工作	产出物
初稿	根据控制态大纲逐章展开	初稿文本
定稿	根据编辑反馈精修全文	定稿文本

初稿阶段

工作方式：
- 接过策划的控制态大纲
- 逐章展开，填充内容

核心原则：

"追求覆盖度，不追求完美"——先把素材铺满，别纠结措辞。

输出标准：
- 大纲的每个点都有对应内容
- 字数符合预期（±20% 可接受）
- 风格基调统一
- 不追求完美，快速完成

定稿阶段

工作方式：
- 接过编辑的深度分析报告
- 精修全文

工作模式：Evaluator-Optimizer 循环（最多 3 轮）

写手精修 → 编辑评估 → 不通过？
    ↓ 是               ↓ 否
写手再改            通过，发布
    ↓
编辑再评 → ...（最多 3 轮）

反馈响应原则：
- 编辑说改就改，不辩解
- 聚焦修正，不讨价还价
- 按检查清单逐项修改

工作原则

只管写，不管审
初稿追覆盖，定稿听编辑
3 轮不过提交人工

📝 编辑（Editor）：只管审，不动笔

核心职责

阶段	具体工作	产出物
深度分析	对初稿进行全面体检	深度分析报告
定稿审核	全量检查清单逐项验收	检查清单评估结果
系列维护	系列一致性检查和规范迭代	系列维护报告、观察日志

1. 深度分析（对初稿的全面体检）

四步流程

步骤	工作内容	产出
交叉验证	核心立意和内容是否一致，数字前后是否矛盾	一致性检查报告
三层输出	结构分析（章节权重）、内容分析（素材覆盖）、风格分析（情绪曲线）	三层分析图表
噪音过滤	区分"必须改"和"可以改"，不让细节淹没核心问题	优先级分类
输出报告	整合成结构化分析报告，交给写手	深度分析报告

报告结构

## 深度分析报告

### 一、整体评估
- 核心立意达成度：80%
- 大纲覆盖率：95%
- 风格一致性：良好

### 二、结构分析
- 开篇定位：✅ 通过
- 章节权重：⚠️ 第 3 章占比过大（35%）
- 结构对称：✅ 问题/方案比 4:6

### 三、内容分析
- 素材覆盖：✅ 控制态大纲 12 个要点全覆盖
- 噪音检查：❌ 第 2 段出现未解释概念"Token"

### 四、风格分析
- 情感曲线：平稳，缺少高潮
- Emoji 密度：7 个/1000 字（小红书标准 8-10）

### 五、必须改进项（CRITICAL）
1. 第 2 段：解释"Token"概念
2. 第 3 章：压缩至 25% 以内

### 六、建议改进项（STANDARD）
1. 增加第 5 段的情感渲染
2. 补充 2-3 个 emoji

2. 定稿审核（全量检查清单逐项验收）

检查项总数

类别	检查项数量
通用检查清单	15 项（大纲 10 + 初稿 8 + 定稿 15）
小红书特定	40 项
网文特定	54 项

评分标准

每一项都是二值判断：Pass / Fail，不搞灰度。

通过率	判定	操作
≥ 90% 且 CRITICAL 全过	✅ 直接通过	进入发布流程
80%~90%，无 CRITICAL 失败	⚠️ 标注风险点，提交你决定	人工判断
< 80% 或 CRITICAL 失败	❌ 必须继续改	回退给写手

检查清单评估报告

## 定稿审核报告

### 检查清单统计
- 总计：70 项（通用 15 + 小红书 40 + 快速七问 15）
- 通过：65 项（92.9%）
- 失败：5 项（7.1%）

### CRITICAL 规则检查
- CR-01 噪音原则：✅ 通过
- CR-02 核心立意：✅ 通过
- CR-03 改进边界：✅ 通过
- CR-04 意象功能：✅ 通过
- CR-05 人的决策：✅ 通过

### 失败项列表（STANDARD）
1. ST-04 结构对称：⚠️ 问题铺垫占 35%（标准 ≤30%）
2. 小红书-emoji密度：⚠️ 7 个/1000 字（标准 8-10）
3. 小红书-CTA存在：❌ 未发现明确的行动号召
4. 小红书-段落长度：⚠️ 第 3 段 6 句（标准 2-4 句）
5. 小红书-短句比例：⚠️ 35%（标准 40%）

### 最终判定
- 通过率：92.9% ✅
- CRITICAL 全过 ✅
- **判定：直接通过**

3. 系列维护

快速模式（每篇必做）

任务	说明
更新概念索引	记录新出现的概念和术语
去重检查	确保不重复讲同一个知识点
暗线追踪	系列文章的隐藏线索是否连贯

深度模式（每 3-5 篇）

任务	说明
全系列一致性检查	风格、立场、用词是否统一
系列规划调整	根据实际情况调整后续规划
风格演化分析	分析系列风格的变化趋势

隐藏职责：观察日志

每轮审核结束后写入观察日志：
- 哪条检查清单反复失败
- 哪条规则形同虚设
- 哪种修改建议没被采纳

这些日志是下一次规范迭代的种子。

工作原则

只管审，不动笔（只出分析报告，不直接改文章）
检查清单逐项过，CRITICAL 不通过就是不通过
Gate 检查不能软
记录观察日志，为规范迭代积累素材

🔄 编排器（Orchestrator）：流水线调度

关键理解

编排器不是 AI，是代码/流程：
- 它是一段预定义的代码路径
- 阶段是固定的，分工是明确的
- 不需要 AI 来决定"下一步该做什么"

编排器的五大职责

职责	说明	实现方式
1. 确认三元组	`(阶段, 风格, 类型)` → 决定加载哪些规范文件	配置文件 + 路由表
2. 固定流水线分派	策划→写手→编辑→写手↔编辑循环	状态机
3. Gate 检查	每个阶段完成后检查通过率，决定通过/回退	检查清单验证逻辑
4. 产出传递	控制上下文大小，只传阶段产出	产出物提取
5. 异常处理	重试 3 次仍不过？提交人工裁决	重试计数器 + 人工介入

Gate 核心逻辑

def gate_check(stage_output, checklist_result):
    """
    Gate 检查逻辑

    返回：
    - "pass": 通过，进入下一阶段
    - "retry": 回退，重新执行本阶段
    - "escalate": 提交人工裁决
    """
    # 检查 CRITICAL 规则
    if has_critical_failure(checklist_result):
        return "retry"  # 强制回退

    # 检查通过率
    pass_rate = calculate_pass_rate(checklist_result)
    if pass_rate < 0.8:
        return "retry"  # 回退并列出未通过项

    # 通过
    return "pass"

完整流水线

系列文章流程（6 步）

① [策划] 系列规划 → Gate→
② [策划] 大纲 → Gate→
③ [写手] 初稿 → 
④ [编辑] 深度分析 → 
⑤ [写手] 定稿 ↔ [编辑] 定稿审核 （循环，最多 3 轮）→ Gate→
⑥ [编辑] 系列维护

独立文章流程（4 步）

① [策划] 大纲 → Gate→
② [写手] 初稿 → 
③ [编辑] 深度分析 → 
④ [写手] 定稿 ↔ [编辑] 定稿审核 （循环，最多 3 轮）→ Gate→

说明：独立文章跳过系列规划和系列维护。

产出传递规则

不传完整历史，只传必要产出：

当前阶段	传递给下一阶段	说明
系列规划	系列规划文档	11 slot 模板
大纲	控制态大纲	~400 行，12 维度控制信息
初稿	初稿文本 + 控制态大纲	编辑需要对照大纲检查
深度分析	深度分析报告	不传初稿全文，只传分析结果
定稿审核	检查清单评估结果 + 未通过项	不传定稿全文，只传反馈

Token 优化：
- 大纲 → 初稿：只传大纲，不传系列规划
- 深度分析 → 定稿：只传分析报告，不传初稿
- 定稿循环：只传未通过项，不传全文

异常处理机制

重试策略

def execute_stage_with_retry(stage, max_retries=3):
    """
    带重试的阶段执行
    """
    for attempt in range(1, max_retries + 1):
        # 执行阶段
        result = execute_stage(stage)

        # Gate 检查
        gate_result = gate_check(result)

        if gate_result == "pass":
            return result

        if attempt < max_retries:
            log(f"阶段 {stage} 第 {attempt} 次尝试失败，重试中...")
        else:
            log(f"阶段 {stage} 已重试 {max_retries} 次仍未通过")
            return escalate_to_human(stage, result)

人工介入场景

3 次重试仍不过
CRITICAL 规则持续失败
检查清单通过率持续 < 60%
出现系统性问题（如大纲本身有问题）

🏢 组织架构升级方案

现状（Level 0）

内容创作部门（2 人）
├── xiaohongshu-writer（全能型）
└── webnovel-writer（全能型）

问题：
- 角色不分离，容易"自我和解"
- 质量控制不严格
- 难以规模化

目标（Level 3）

内容创作部门（8 人 = 6 个子 Agent + 2 个编排器）

├── 小红书业务线（4 人）
│   ├── xiaohongshu-planner（策划）
│   ├── xiaohongshu-writer（写手）
│   ├── xiaohongshu-editor（编辑）
│   └── xiaohongshu-orchestrator（编排器）
│
└── 网文业务线（4 人）
    ├── webnovel-planner（策划）
    ├── webnovel-writer（写手）
    ├── webnovel-editor（编辑）
    └── webnovel-orchestrator（编排器）

优势：
- ✅ 角色分离，职责明确
- ✅ 质量把控严格（Gate 检查）
- ✅ 可扩展（可继续添加新业务线）
- ✅ 规范可迭代（观察日志积累）

📝 小红书业务线详细设计

xiaohongshu-planner（小红书策划）

定位：小红书内容策划专家，专注选题和结构设计

核心技能：
- 熟悉小红书平台特性（标题吸睛、情感共鸣、热点把握）
- 擅长内容策划和大纲设计
- 掌握 writing-meta-spec Skill

职责边界：
- ✅ 做：选题策划、大纲设计、系列规划
- ❌ 不做：不写正文

工作流程：
1. 接收需求（选题方向/系列主题）
2. 进行项目分析（目标受众、核心立意、价值定位）
3. 输出系列规划（如果是系列）
4. 输出控制态大纲（12 维度控制信息）
5. 交付给写手，任务结束

产出物：
- 系列规划文档（11 slot）
- 控制态大纲（~400 行）
- 包含：标题方案、开场钩子、分点结构、emoji 密度预期、情感基调、CTA 设计等

xiaohongshu-writer（小红书写手）

定位：小红书内容写作专家，专注文案创作

核心技能：
- 文笔流畅，语感好
- 熟悉小红书风格（亲切、真诚、轻松）
- 掌握 writing-meta-spec Skill

职责边界：
- ✅ 做：根据大纲写初稿和定稿
- ❌ 不做：不自己审核验收

工作流程：

初稿阶段：
1. 接收控制态大纲
2. 按大纲展开，快速覆盖所有要点
3. 不追求完美，追求覆盖度
4. 输出初稿，交给编辑

定稿阶段：
1. 接收深度分析报告
2. 按优先级修改（CRITICAL 优先）
3. 逐项响应检查清单反馈
4. 输出定稿，交给编辑审核
5. 如果不通过，重复步骤 2-4（最多 3 轮）

产出物：
- 初稿文本
- 定稿文本

xiaohongshu-editor（小红书编辑）

定位：小红书内容审核专家，质量把关人

核心技能：
- 审稿经验丰富
- 熟悉检查清单体系（通用 15 项 + 小红书 40 项）
- 掌握 writing-meta-spec Skill

职责边界：
- ✅ 做：深度分析、定稿审核、系列维护
- ❌ 不做：不直接改文章（只出分析报告）

工作流程：

深度分析阶段：
1. 接收初稿 + 控制态大纲
2. 四步分析：交叉验证、三层输出、噪音过滤、输出报告
3. 输出深度分析报告，交给写手

定稿审核阶段：
1. 接收定稿文本
2. 使用检查清单逐项验证（55 项）
3. 计算通过率，进行 Gate 检查
4. 输出检查清单评估结果
5. 如果不通过，列出未通过项，回退给写手
6. 如果通过，进入发布流程

系列维护：
- 快速模式：每篇更新索引、去重、暗线追踪
- 深度模式：每 3-5 篇做一次全系列检查
- 记录观察日志，为规范迭代积累素材

产出物：
- 深度分析报告
- 检查清单评估结果
- 系列维护报告
- 观察日志

xiaohongshu-orchestrator（小红书编排器）

定位：流水线调度系统（代码实现，非 AI Agent）

核心功能：
1. 路由：根据内容类型加载对应规范文件
2. 调度：按固定流程分派任务（策划→写手→编辑→循环）
3. Gate：每阶段完成后检查通过率
4. 传递：只传必要产出，不传完整历史
5. 异常处理：3 次不过提交人工

实现方式：
- Python 脚本 / Workflow 配置
- 状态机 + 检查清单验证
- 产出物提取 + Token 优化

📝 网文业务线详细设计

webnovel-planner（网文策划）

定位：网络小说策划专家，专注世界观和大纲设计

核心技能：
- 熟悉网文创作（尤其修仙类）
- 擅长力量体系设计、悬念布局、爽点规划
- 掌握 writing-meta-spec Skill

职责边界：
- ✅ 做：世界观设定、系列规划、章节大纲
- ❌ 不做：不写正文

工作流程：
1. 接收需求（题材、世界观方向）
2. 设定世界观（力量体系、势力格局、特殊规则）
3. 系列规划（整体大纲、悬念层次、爽点分布）
4. 章节大纲（控制态，~400 行/章）
5. 交付给写手

产出物：
- 世界观设定文档
- 系列规划文档
- 控制态大纲（章节级）
- 包含：悬念钩子、爽点时机、人物出场、实力展示、节奏控制等

webnovel-writer（网文写手）

定位：网络小说写作专家，专注章节创作

核心技能：
- 文笔流畅，节奏把控好
- 熟悉网文风格（修仙类）
- 掌握 writing-meta-spec Skill

职责边界：
- ✅ 做：根据大纲写章节初稿和定稿
- ❌ 不做：不自己审核

工作流程：

初稿阶段：
1. 接收控制态大纲（章节级）
2. 快速展开，覆盖所有剧情点
3. 不纠结措辞，追求覆盖度
4. 输出初稿

定稿阶段：
1. 接收深度分析报告
2. 按优先级修改
3. 响应检查清单反馈
4. 输出定稿
5. 如不通过，重复（最多 3 轮）

产出物：
- 章节初稿
- 章节定稿

webnovel-editor（网文编辑）

定位：网络小说审核专家，质量和悬念把关

核心技能：
- 审稿经验丰富
- 熟悉悬念检查、爽点验证、人物一致性检查
- 掌握 writing-meta-spec Skill + 网文检查清单（54 项）

职责边界：
- ✅ 做：深度分析、定稿审核、系列维护
- ❌ 不做：不直接改文章

工作流程：

深度分析：
1. 接收初稿 + 大纲
2. 四步分析 + 网文特有检查：
- 悬念层次是否合理
- 爽点分布是否恰当
- 人物行为是否符合设定
- 实力体系是否自洽
3. 输出深度分析报告

定稿审核：
1. 接收定稿文本
2. 检查清单验证（通用 15 + 网文 54 = 69 项）
3. Gate 检查
4. 输出评估结果
5. 如不通过，回退

系列维护：
- 快速模式：概念索引、人物关系、实力体系一致性
- 深度模式：暗线追踪、世界观扩展、伏笔回收
- 观察日志

产出物：
- 深度分析报告
- 检查清单评估结果
- 系列维护报告
- 观察日志

webnovel-orchestrator（网文编排器）

定位：流水线调度系统（代码实现）

核心功能：
1. 路由：加载网文规范文件
2. 调度：策划→写手→编辑→循环
3. Gate：悬念检查、爽点验证、通过率
4. 传递：只传产出，不传历史
5. 异常处理：3 次不过提交人工

实现方式：
- Python 脚本 / Workflow
- 状态机 + 网文检查清单
- 产出物提取

🎯 关键设计原则总结

1. 角色边界要硬 ⭐⭐⭐

原则	说明	为什么
策划不写正文	交出大纲就结束	防止策划"顺手写几段"导致角色混乱
写手不做验收	写完交给编辑	防止写手"自己觉得还行"就发布
编辑不改文章	只出报告和评估	防止编辑"直接改几处"跳过流程

反例：
- ❌ 策划顺手写了个开场白 → 角色边界模糊
- ❌ 写手自己审了一遍觉得 OK → 跳过编辑，质量失控
- ❌ 编辑直接改了几处typo → 绕过写手，流程混乱

2. Gate 检查不能软 ⭐⭐⭐

硬标准：
- CRITICAL 有一项未过 → 强制回退
- 通过率 < 80% → 回退并列出未通过项
- 不能因为"差不多"就放行

反例：
- ❌ "这条 CRITICAL 虽然没过，但其他都挺好的，就算了吧" → 不行！
- ❌ "通过率 78%，很接近 80% 了，放行吧" → 不行！
- ❌ "已经改了 3 轮了，不想再改了，就这样吧" → 提交人工裁决

3. 编排器是代码，不是 AI ⭐⭐

不要让 AI 决定流程：
- ❌ "AI 你看看现在该做什么了"
- ✅ 流程是固定的：策划→写手→编辑→循环

AI 只负责执行：
- 策划 AI：出大纲
- 写手 AI：写内容
- 编辑 AI：审核
- 编排器：调度（代码/工作流）

4. 上下文传递要精简 ⭐⭐

不传完整历史：
- ❌ 把所有对话历史都传给下一个角色
- ✅ 只传阶段产出（大纲、初稿、报告）

Token 优化示例：

策划 → 写手：只传控制态大纲（~2K tokens）
编辑 → 写手：只传分析报告（~1K tokens）
不传：完整的策划过程对话（~10K tokens）

5. 异常处理要明确 ⭐

重试上限：
- 每个阶段最多重试 3 次
- 3 次后仍不过 → 提交人工裁决

不要无限循环：
- ❌ 让 AI 反复改到通过为止
- ✅ 3 次不过说明有系统性问题，需要人介入

人工介入场景：
- CRITICAL 规则持续失败
- 检查清单通过率持续 < 60%
- 出现结构性问题（大纲本身有问题）

📅 实施计划

第一阶段：HR 招聘（1 周）

任务：
- HR 创建 6 个岗位的完整 JD（岗位描述）
- 说明职责、技能要求、协作方式
- 将新员工信息录入组织架构

产出：
- 6 份岗位描述文档
- 更新后的组织架构文档

第二阶段：RainBox 创建 Agent 配置（2 周）

任务：
- 为 6 个子 Agent 创建配置文件（IDENTITY.md、SOUL.md、TOOLS.md 等）
- 每个 Agent 配置 writing-meta-spec Skill
- 明确每个 Agent 的职责边界和工作流程

产出：
- 6 个完整的 Agent 配置目录

第三阶段：RainBox 设计编排器（2 周）

任务：
- 设计编排器架构（Python 脚本 / Workflow）
- 实现 Gate 检查逻辑
- 实现产出传递机制
- 实现异常处理和重试

产出：
- 2 个编排器实现方案（小红书 + 网文）

第四阶段：测试与优化（2 周）

任务：
- 小红书业务线端到端测试
- 网文业务线端到端测试
- 优化 Gate 检查阈值
- 优化产出传递策略

产出：
- 测试报告
- 优化后的配置

第五阶段：上线与迭代（持续）

任务：
- 正式上线 Level 3 架构
- 收集观察日志
- 每 3-5 篇进行规范迭代
- 持续优化流程

🔗 相关文档

设计完成
下一步：由 HR 执行招聘任务，由 RainBox 创建 Agent 配置

本方案由 RainBox (主 Agent) 设计
v1.0 | 2026-03-22