novel-delegate-task-writing

name	novel-delegate-task-writing
description	用 delegate_task 替代 CC CLI 写小说正文。触发：DRAFT/POLISH步骤。

delegate_task 小说正文生成方案

背景

2026-08-13 回测验证：Claude Code CLI 通过 pandai 中继调用 v4-flash/v4-pro 时存在严重问题——DSML 标记干扰、thinking block 吞正文、stream-json 解析复杂、进程不退出。改用 Hermes 原生 delegate_task 子智能体（glm-5.2-thinking）后问题全部消除。

回测数据（第66章）

指标	原流程(Claude Code sonnet)	delegate_task(DRAFT+EXPAND)
最终字数	2305	2738
对话比例	48.07%	40.4%
总耗时	712秒	238秒（快67%）
费用	$2.36	~$0.05（降98%）
API调用	stream-json事件流	11次（4+7）
机械问题	—	0
真实地名	—	无

核心流程

DRAFT（初始正文生成）

1. 主 Agent 读取骨架 + 前文时间线 + 书配置 → 构造 goal
2. delegate_task 派发 leaf 子智能体，goal 中包含完整骨架和铁律
3. 子智能体返回正文文本（summary）
4. 主 Agent 验证：review_scan.py 检查字数/对话比例/机械问题

EXPAND（字数不足时扩写）

1. 初稿字数 < 2000 时，把初稿 + 扩写指令作为 goal 派发第二个子智能体
2. 扩写指令指定：增加对话交锋轮次、增加围观者反应、增加对手反应细节
3. 禁止：环境描写凑字、机械动作、静态等待

POLISH（内容打磨）

同 DRAFT 流程，把初稿 + 审查报告作为 goal 派发子智能体。

⛔ 禁止截断（铁律）

用户原话：「截断？剧情还能接？粗暴截断不就是傻逼行为？字数和对话占比差不多就行了」

绝对不要为了满足字数上限而截断正文。字数超了就是超了——这是小说，不是代码。截断会破坏剧情连贯性和章末钩子。

字数/对话比例的弹性区间（2026-08-13 确认）：

• 字数：2000—2800（目标 2350，但不强制截断）
• 对话比例：≥ 38%
• 字数略超（如 2700、2800）或对话比例略低（如 38-40%）不算问题，不微调

delegate_task goal 构造要点

必须包含

• 完整骨架（从 00-大纲细纲/章节骨架/第N章_骨架.md 读取）
• 前文时间线速查（最近3章）
• 书配置摘要（地名白名单、系统面板字段、方言词表）
• 铁律三条：禁止真实地名、系统面板原封不动、字数+对话+格式要求
• 网文校准：情绪直接给、事件密度高、大白话、钩子具体

context 参数

• 明确告知子智能体这是小说正文生成任务
• 列出关键约束（字数、对话比例、格式）
• 列出禁止项（真实地名、系统新功能、环境凑字、自创人物/机构）

已知限制

1. 字数不稳定：glm-5.2-thinking 首次生成约 1760 字（压缩 20%），需要扩写补足
2. 对话比例偏低：初次生成约 29%，需要扩写时明确要求增加对话交锋
3. 禁用词：子智能体可能使用"最终"等禁用词，REVIEW 阶段 review_scan.py 会拦截

与 Claude Code CLI 的对比

维度	Claude Code CLI	delegate_task
模型	v4-flash/v4-pro（pandai中继）	glm-5.2-thinking（Hermes原生）
干扰	DSML标记、thinking吞正文	无
超时管理	idle_timeout + capture_idle_timeout	自动完成（2分钟内）
文件I/O	模型自行Read/Write	主Agent负责落盘
验证	模型自我验收（浪费轮次）	主Agent脚本验证
成本	$2.36/章	~$0.05/章

推荐流程（最终版）

PREP → PLOT → 骨架 → delegate_task DRAFT → 验证 → 
  (字数不足<2000?) → delegate_task EXPAND → 验证 →
  (字数超了?) → 不动，直接通过 →
REVIEW → delegate_task POLISH → 验证 → TRACK → BACKUP

走过的弯路（避免重复）

1. capture mode（零工具）：v4-flash 把正文写在 thinking block 里，不产生 text output。thinking 提取逻辑太脆弱（多版本正文混在 7 万字 thinking 中）。放弃。
2. Write-only 到候选文件：v4-flash 仍先做 10 万字 thinking，max-turns=2 用完也没调用 Write。放弃。
3. overshoot 系数调优：v4-flash 字数极不稳定（1974~3691），overshoot 无法稳定命中。放弃。
4. 智能截断：用户明确拒绝——「粗暴截断是傻逼行为」。字数超了就超了，不截断。
5. 结论：问题根源是 pandai 中继的 v4-flash extended thinking 行为，不是 prompt 或工具配置。delegate_task 绕过了所有中间层。

相关文件

• references/delegate-task-novel-writing.md — 详细回测日志、prompt 模板
• 脚本 chapter_fast_gate.py 的 chapter_gate_text() — 文本验证（不依赖文件I/O）
• 脚本 review_scan.py — 正式审查扫描器（主 Agent 使用）

注意

• novel-main SKILL.md 已在 2026-08-13 更新为 delegate_task 方案（DRAFT/POLISH 步骤）。
• novel-writing SKILL.md（入口技能）仍多处引用旧的 Claude Code CLI 和 claude_runner.py 命令，且仍保留"delegate_task 禁用"铁律。需用户执行 hermes curator adopt novel-writing 后才能自动更新。
• claude_runner.py 的 capture_mode 和 thinking 提取逻辑仍保留在代码中，但不再推荐使用。