尧图网页设计 
webnovel-writer 网文节奏审查指南信息密度标准、灌水诊断与快节奏写法实战【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer导读本文围绕 webnovel-writer 项目中 节奏审查参考文档 展开讲解在webnovel-review审查流程中如何诊断灌水拖沓问题、量化章节信息密度并给出可落地的快节奏写作规范。读完本文你将掌握每 1000 字至少推进 1 个实质性剧情点的量化标准、四级评分判定表、标准章节与过渡章节的结构模板、分题材节奏参数以及它们如何被 reviewer 审查 Agent 与 review-pipeline 落库管线 真正消费。一、pacing-control 在审查体系中的定位pacing-control.md是一份节奏审查参考文档reference按 frontmatter 声明其name为pacing-controlpurpose为节奏审查时加载诊断灌水拖沓问题。它在整个审查链路中的加载时机非常明确根据 webnovel-review Skill 的 Step 3 参考加载表审查涉及爽点或钩子时加载cool-points-guide而pacing-control属于 reviewer 侧节奏审查时的核心判据。整个审查由webnovel-review技能驱动解析项目根 → 刷新缺失的 runtime 合同 → 按需加载参考 → 读取投影状态与待审正文 → 通过Agent工具调度统一的 reviewer Agent 输出结构化问题 JSON → 由review-pipeline生成报告并落库指标。需要特别说明的是reviewer 的 JSON schema 中category取值规范只允许产出setting/timeline/continuity/character/logic五个维度而 review_schema.py 的VALID_CATEGORIES集合中仍保留了pacing与other作为后端兼容枚举。也就是说节奏/灌水问题在标准五维审查中通常体现为timeline时间线推进异常、continuity叙事连贯或logic逻辑维度下带evidence的 issuepacing本身作为兼容分类存在。从源码结构看这体现了事实审查不评分、只报可验证问题的设计取向灌水诊断更依赖量化的密度标准而非主观文笔评价。二、信息密度标准每 1000 字至少 1 个实质性剧情点pacing-control 给出的核心指标是一条可执行、可复核的硬标准每 1000 字至少推进 1 个实质性剧情点实质性剧情点的定义正反例计入剧情点✅ 主角获得新信息 / 线索 / 能力✅ 人际关系变化好感度 ±10、仇恨度 ±10✅ 战力提升 / 突破 / 学会新招式✅ 剧情转折新冲突 / 新目标 / 新危机✅ 伏笔埋下或回收不计入剧情点无效内容❌ 纯粹风景描写除非与剧情强相关❌ 重复的内心独白❌ 无意义对话寒暄问候这一定义与 core-constraints.md 中本章必须存在清晰推进问题、目标、代价、关系变化、信息变化至少一项可被识别的 Hard 约束相互呼应写作时的 Hard 约束管有没有推进节奏审查的信息密度标准管推进够不够密。四级评分判定表信息密度爽点数量无效内容判定 800 字/点≥ 2 个无优秀 90-100800-1000 字/点1 个极少良好 70-891000-1500 字/点1 个有及格 50-69 1500 字/点0 个大量不及格需重写这张表同时考察三个维度信息密度字/点、爽点数量本章至少 1 个优秀档要求 ≥ 2 个与无效内容占比。其中爽点数量维度的工程化定义可进一步参考 cool-points-guide.md爽点分为小爽点单一模式、多数章节常见、组合爽点2 种以上模式叠加、阶段节点出现、里程碑爽点改变主角地位、低频大节点并按题材给出逐章优先保证有爽点或同等兑现允许过渡章低密度的滚动窗口要求——这与评分表中及格档允许 1 个爽点的容差逻辑一致。三、快节奏 vs 慢节奏网文与传统小说的写作差异pacing-control 用一张对比表明确了两类节奏范式的核心差异维度慢节奏传统小说快节奏网文修炼3 章描写修炼过程3 段话交代第 4 段直接突破铺垫5000 字铺垫反派500 字铺垫直接冲突决策主角纠结 2 章主角纠结 2 段话立即行动副本20 章完成5-8 章完成注意这里的快不是无脑加速而是把过程压缩、把结果前置修炼过程让位于突破结果铺垫让位于冲突决策纠结让位于行动。这与 core-constraints.md 中的 Anti-AI 写作预防规则一脉相承——每 500 字至少有一次节奏变化短句爆发、对话插入、场景切换以及局面变化建议保持节奏感参考 800-1400 字一个脉冲短章至少一次实质变化。这些规则共同构成节奏感的微观实现手段而 pacing-control 提供的是章级、卷级的宏观配比标准。四、章节结构模板标准章节与过渡章节标准章节3000-5000 字开头 300-500 字承接上章 设定场景 铺垫 800-1200 字引入本章核心冲突 发展 1000-1500 字推进剧情 爽点前奏 高潮 500-800 字本章爽点爆发 结尾 300-500 字余韵 引出下章悬念该模板对应网文常见的起承转合五段式开头承接上章钩子呼应 core-constraints.md 中若上章有明确承诺本章必须回应的 Hard 约束中间三段完成冲突引入与爽点爆发结尾留下悬念锚点对应章末必须保留至少一个未解决的问题或不安感的 Anti-AI 规则。过渡章节避免灌水回顾 200-300 字上一阶段收获 新目标 500-700 字确立下一步计划 准备 1000-1500 字为下个篇章做准备 小冲突 500-800 字插入小爽点必须有 悬念 200-300 字引出下一篇章过渡章的核心防灌水机制是强制插入小冲突与小爽点。这与 core-constraints.md 中过渡章允许低密度但不允许整章无收获的规定互为印证——过渡章可以没有大冲突但必须有可识别的小收获否则落入纯过渡无冲突的错误清单。五、分题材节奏标准不同品类的爽点密度与铺垫容忍度pacing-control 给出了四类代表题材的节奏参数题材爽点密度信息密度铺垫容忍度玄幻修仙每 5-8 章 1 大爽点500-1000 字/点中等都市爽文每 3-5 章 1 大爽点400-800 字/点低悬疑推理每 10-15 章 1 大爽点600-1200 字/点高知乎短篇每章至少 1 小爽点300-500 字/点极低关键读法铺垫容忍度高的题材悬疑推理信息密度可以放宽但爽点频率必须压低用长时间积累换取大反转势能铺垫容忍度低的题材知乎短篇、都市爽文信息密度与爽点频率双高几乎不允许慢热。这解释了为何同为网文悬念铺陈与即时爽感需要不同的审查尺子——节奏审查不是一刀切的越快越好而是按题材 profile 校准。进一步的压扬比例参考见 cool-points-guide.md传统爽文压 3 扬 7、硬核正剧压 5 扬 5、虐恋/黑深残压 7 扬 3慢铺垫压→ 快爆发扬→ 停顿 → 再加速是通用节奏脉冲。六、典型灌水案例拆解三段式示范案例 1修炼突破章节❌灌水版1200 字1 个剧情点林天盘膝坐下开始运转功法...500 字详细描写 灵气缓缓进入体内...300 字过程描写 时间一分一秒过去...200 字 终于突破50 字 → 信息密度 1200 字/点 → 严重拖沓✅精简版90 字3 个剧情点林天盘膝坐下吞噬系统疯狂吸收天雷果能量。 三个时辰后——轰筑基八层 林天睁眼拳头一握空气爆鸣。 门外传来惊呼三天就突破了 → 信息密度 30 字/点 → 节奏紧凑灌水版把 1200 字全部花在修炼过程这一无效环节只产出一个剧情点突破精简版用 90 字完成系统吞噬能量能力获取→ 突破战力提升→ 实力展示新信息→ 外界反应人际关系/震惊四个有效节拍其中门外惊呼同时充当了爽点爆发与下一悬念钩子。案例 2赶路过渡场景❌灌水版800 字林天走在山路上看着两旁的树木...内心独白 300 字 路上遇到一只兔子...观察兔子 200 字 天空飘来几朵云...描写天气 300 字✅精简版80 字林天赶了三天路终于抵达血煞秘境入口。刚踏入秘境一股危险气息扑面而来。赶路是典型的过渡性动作传统写法容易堕入风景描写与内心独白堆砌。精简版用一句话完成空间位移随即用危险气息立即制造新的紧张源——这正是过渡章节必须有小冲突模板的微观体现。案例 3检测到连续 500 字无剧情推进严重拖沓标记修正方案A) 删除该段落B) 压缩为 1-2 句话交代C) 插入微冲突路人挑衅 / 意外事件选项 C 与 core-constraints.md 中每 500 字至少有一次节奏变化形成直接对照连续 500 字无推进在写作侧即应被预防在审查侧则是明确的严重拖沓红旗。七、错误修正清单审查侧的可操作规则pacing-control 的errors区块给出了节奏审查的闭环修正规则❌ 信息密度 1500 字/点 → ✅ 压缩或增加剧情点❌ 整章无爽点 → ✅ 至少插入 1 个小爽点❌ 铺垫超过 2000 字仍未进入冲突 → ✅ 立即加速❌ 过渡章节纯过渡无冲突 → ✅ 必须有小爽点❌ 连续 500 字纯描写 → ✅ 删除或压缩这套规则在仓库中并非孤立存在review-schema.md中的 issue 结构severity / category / location / description / evidence / fix_hint / blocking要求每条审查问题必须携带evidence原文引用或数据对比与fix_hint修复方向而 pacing-control 的❌ → ✅结构恰好天然适配description fix_hint的字段语义。从源码结构看reviewer 侧加载节奏参考后可将信息密度 1500 字/点铺垫超过 2000 字这类可量化发现组织为带证据的 issue 输出。八、从审查到落库节奏问题如何进入指标体系当节奏/灌水问题被 reviewer 识别后整条链路由 review_pipeline.py 承接reviewer返回严格 JSON只报问题、不评分主流程写入${PROJECT_ROOT}/.webnovel/tmp/review_results.jsonreview-pipeline --chapter {N} --review-results ... --report-file ... --save-metrics解析 JSON经 review_schema.py 的parse_review_output归一化为ReviewResult生成 Markdown 审查报告与review_metrics.json并写入index.db的review_metrics表overall_score由问题严重度推导SEVERITY_PENALTIEScritical 扣 35、high 扣 15、medium 扣 6、low 扣 2pacing作为SCORE_CATEGORIES之一参与dimension_scores计算——但 review-schema.md 明确说明overall_score仅用于趋势观测与排序gate 决策仍以blockingtrue和 issue 明细为准报告生成时review_author_view.py 会把问题按阻断优先、严重度排序压缩为最值得处理的 1-3 件事面向作者输出⛔必须先改 / ⚠️建议改 / ✅可以继续三段式结论。配套的 webnovel-review 评测用例 验证了整条链路审查第 4 章时要求生成审查报告、识别时间线等事实/一致性问题、将审查指标写入 index.db且报告中的每个 issue 都有 evidence——这保证了包括节奏类问题在内的所有审查结论都可追溯、可复核。九、实战建议把节奏标准嵌入创作与审查循环综合 pacing-control 与仓库内相关规范建议的节奏管理闭环如下写作侧预防在 webnovel-write 创作时即遵循每 500 字一次节奏变化与局面变化 800-1400 字一个脉冲的微观规则从源头减少灌水段落章级自检按标准章节 / 过渡章节模板核对结构占比过渡章强制确认存在小冲突或小爽点审查侧诊断通过/webnovel-review {章号}触发审查由 reviewer 对照信息密度标准产出带证据的问题清单落库与趋势review-pipeline --save-metrics将维度分沉淀进review_metrics表长期追踪各章pacing维度分变化识别节奏恶化的趋势节点题材校准审查前明确题材 profile玄幻、都市、悬疑、短篇用对应的爽点密度与铺垫容忍度作为判定尺子避免跨题材套用同一标准。结语pacing-control 为网文节奏管理提供了一整套可量化、可执行、可复核的标准从每 1000 字至少 1 个实质性剧情点的核心指标到四级评分表、快慢节奏对比、章节结构模板、分题材参数再到灌水案例与错误修正清单。在 webnovel-writer 的审查体系里这些标准不是停留在文档层面的写作建议而是通过webnovel-review技能、reviewerAgent 与review-pipeline管线真正进入章节质量审查与指标沉淀流程的工程化规则——既服务于作者的自我诊断也服务于 Agent 的可验证审查。【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 webnovel-writer 网文节奏审查指南：信息密度标准、灌水诊断与快节奏写法实战
webnovel-writer 网文节奏审查指南信息密度标准、灌水诊断与快节奏写法实战【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer导读本文围绕 webnovel-writer 项目中 节奏审查参考文档 展开讲解在webnovel-review审查流程中如何诊断灌水拖沓问题、量化章节信息密度并给出可落地的快节奏写作规范。读完本文你将掌握每 1000 字至少推进 1 个实质性剧情点的量化标准、四级评分判定表、标准章节与过渡章节的结构模板、分题材节奏参数以及它们如何被 reviewer 审查 Agent 与 review-pipeline 落库管线 真正消费。一、pacing-control 在审查体系中的定位pacing-control.md是一份节奏审查参考文档reference按 frontmatter 声明其name为pacing-controlpurpose为节奏审查时加载诊断灌水拖沓问题。它在整个审查链路中的加载时机非常明确根据 webnovel-review Skill 的 Step 3 参考加载表审查涉及爽点或钩子时加载cool-points-guide而pacing-control属于 reviewer 侧节奏审查时的核心判据。整个审查由webnovel-review技能驱动解析项目根 → 刷新缺失的 runtime 合同 → 按需加载参考 → 读取投影状态与待审正文 → 通过Agent工具调度统一的 reviewer Agent 输出结构化问题 JSON → 由review-pipeline生成报告并落库指标。需要特别说明的是reviewer 的 JSON schema 中category取值规范只允许产出setting/timeline/continuity/character/logic五个维度而 review_schema.py 的VALID_CATEGORIES集合中仍保留了pacing与other作为后端兼容枚举。也就是说节奏/灌水问题在标准五维审查中通常体现为timeline时间线推进异常、continuity叙事连贯或logic逻辑维度下带evidence的 issuepacing本身作为兼容分类存在。从源码结构看这体现了事实审查不评分、只报可验证问题的设计取向灌水诊断更依赖量化的密度标准而非主观文笔评价。二、信息密度标准每 1000 字至少 1 个实质性剧情点pacing-control 给出的核心指标是一条可执行、可复核的硬标准每 1000 字至少推进 1 个实质性剧情点实质性剧情点的定义正反例计入剧情点✅ 主角获得新信息 / 线索 / 能力✅ 人际关系变化好感度 ±10、仇恨度 ±10✅ 战力提升 / 突破 / 学会新招式✅ 剧情转折新冲突 / 新目标 / 新危机✅ 伏笔埋下或回收不计入剧情点无效内容❌ 纯粹风景描写除非与剧情强相关❌ 重复的内心独白❌ 无意义对话寒暄问候这一定义与 core-constraints.md 中本章必须存在清晰推进问题、目标、代价、关系变化、信息变化至少一项可被识别的 Hard 约束相互呼应写作时的 Hard 约束管有没有推进节奏审查的信息密度标准管推进够不够密。四级评分判定表信息密度爽点数量无效内容判定 800 字/点≥ 2 个无优秀 90-100800-1000 字/点1 个极少良好 70-891000-1500 字/点1 个有及格 50-69 1500 字/点0 个大量不及格需重写这张表同时考察三个维度信息密度字/点、爽点数量本章至少 1 个优秀档要求 ≥ 2 个与无效内容占比。其中爽点数量维度的工程化定义可进一步参考 cool-points-guide.md爽点分为小爽点单一模式、多数章节常见、组合爽点2 种以上模式叠加、阶段节点出现、里程碑爽点改变主角地位、低频大节点并按题材给出逐章优先保证有爽点或同等兑现允许过渡章低密度的滚动窗口要求——这与评分表中及格档允许 1 个爽点的容差逻辑一致。三、快节奏 vs 慢节奏网文与传统小说的写作差异pacing-control 用一张对比表明确了两类节奏范式的核心差异维度慢节奏传统小说快节奏网文修炼3 章描写修炼过程3 段话交代第 4 段直接突破铺垫5000 字铺垫反派500 字铺垫直接冲突决策主角纠结 2 章主角纠结 2 段话立即行动副本20 章完成5-8 章完成注意这里的快不是无脑加速而是把过程压缩、把结果前置修炼过程让位于突破结果铺垫让位于冲突决策纠结让位于行动。这与 core-constraints.md 中的 Anti-AI 写作预防规则一脉相承——每 500 字至少有一次节奏变化短句爆发、对话插入、场景切换以及局面变化建议保持节奏感参考 800-1400 字一个脉冲短章至少一次实质变化。这些规则共同构成节奏感的微观实现手段而 pacing-control 提供的是章级、卷级的宏观配比标准。四、章节结构模板标准章节与过渡章节标准章节3000-5000 字开头 300-500 字承接上章 设定场景 铺垫 800-1200 字引入本章核心冲突 发展 1000-1500 字推进剧情 爽点前奏 高潮 500-800 字本章爽点爆发 结尾 300-500 字余韵 引出下章悬念该模板对应网文常见的起承转合五段式开头承接上章钩子呼应 core-constraints.md 中若上章有明确承诺本章必须回应的 Hard 约束中间三段完成冲突引入与爽点爆发结尾留下悬念锚点对应章末必须保留至少一个未解决的问题或不安感的 Anti-AI 规则。过渡章节避免灌水回顾 200-300 字上一阶段收获 新目标 500-700 字确立下一步计划 准备 1000-1500 字为下个篇章做准备 小冲突 500-800 字插入小爽点必须有 悬念 200-300 字引出下一篇章过渡章的核心防灌水机制是强制插入小冲突与小爽点。这与 core-constraints.md 中过渡章允许低密度但不允许整章无收获的规定互为印证——过渡章可以没有大冲突但必须有可识别的小收获否则落入纯过渡无冲突的错误清单。五、分题材节奏标准不同品类的爽点密度与铺垫容忍度pacing-control 给出了四类代表题材的节奏参数题材爽点密度信息密度铺垫容忍度玄幻修仙每 5-8 章 1 大爽点500-1000 字/点中等都市爽文每 3-5 章 1 大爽点400-800 字/点低悬疑推理每 10-15 章 1 大爽点600-1200 字/点高知乎短篇每章至少 1 小爽点300-500 字/点极低关键读法铺垫容忍度高的题材悬疑推理信息密度可以放宽但爽点频率必须压低用长时间积累换取大反转势能铺垫容忍度低的题材知乎短篇、都市爽文信息密度与爽点频率双高几乎不允许慢热。这解释了为何同为网文悬念铺陈与即时爽感需要不同的审查尺子——节奏审查不是一刀切的越快越好而是按题材 profile 校准。进一步的压扬比例参考见 cool-points-guide.md传统爽文压 3 扬 7、硬核正剧压 5 扬 5、虐恋/黑深残压 7 扬 3慢铺垫压→ 快爆发扬→ 停顿 → 再加速是通用节奏脉冲。六、典型灌水案例拆解三段式示范案例 1修炼突破章节❌灌水版1200 字1 个剧情点林天盘膝坐下开始运转功法...500 字详细描写 灵气缓缓进入体内...300 字过程描写 时间一分一秒过去...200 字 终于突破50 字 → 信息密度 1200 字/点 → 严重拖沓✅精简版90 字3 个剧情点林天盘膝坐下吞噬系统疯狂吸收天雷果能量。 三个时辰后——轰筑基八层 林天睁眼拳头一握空气爆鸣。 门外传来惊呼三天就突破了 → 信息密度 30 字/点 → 节奏紧凑灌水版把 1200 字全部花在修炼过程这一无效环节只产出一个剧情点突破精简版用 90 字完成系统吞噬能量能力获取→ 突破战力提升→ 实力展示新信息→ 外界反应人际关系/震惊四个有效节拍其中门外惊呼同时充当了爽点爆发与下一悬念钩子。案例 2赶路过渡场景❌灌水版800 字林天走在山路上看着两旁的树木...内心独白 300 字 路上遇到一只兔子...观察兔子 200 字 天空飘来几朵云...描写天气 300 字✅精简版80 字林天赶了三天路终于抵达血煞秘境入口。刚踏入秘境一股危险气息扑面而来。赶路是典型的过渡性动作传统写法容易堕入风景描写与内心独白堆砌。精简版用一句话完成空间位移随即用危险气息立即制造新的紧张源——这正是过渡章节必须有小冲突模板的微观体现。案例 3检测到连续 500 字无剧情推进严重拖沓标记修正方案A) 删除该段落B) 压缩为 1-2 句话交代C) 插入微冲突路人挑衅 / 意外事件选项 C 与 core-constraints.md 中每 500 字至少有一次节奏变化形成直接对照连续 500 字无推进在写作侧即应被预防在审查侧则是明确的严重拖沓红旗。七、错误修正清单审查侧的可操作规则pacing-control 的errors区块给出了节奏审查的闭环修正规则❌ 信息密度 1500 字/点 → ✅ 压缩或增加剧情点❌ 整章无爽点 → ✅ 至少插入 1 个小爽点❌ 铺垫超过 2000 字仍未进入冲突 → ✅ 立即加速❌ 过渡章节纯过渡无冲突 → ✅ 必须有小爽点❌ 连续 500 字纯描写 → ✅ 删除或压缩这套规则在仓库中并非孤立存在review-schema.md中的 issue 结构severity / category / location / description / evidence / fix_hint / blocking要求每条审查问题必须携带evidence原文引用或数据对比与fix_hint修复方向而 pacing-control 的❌ → ✅结构恰好天然适配description fix_hint的字段语义。从源码结构看reviewer 侧加载节奏参考后可将信息密度 1500 字/点铺垫超过 2000 字这类可量化发现组织为带证据的 issue 输出。八、从审查到落库节奏问题如何进入指标体系当节奏/灌水问题被 reviewer 识别后整条链路由 review_pipeline.py 承接reviewer返回严格 JSON只报问题、不评分主流程写入${PROJECT_ROOT}/.webnovel/tmp/review_results.jsonreview-pipeline --chapter {N} --review-results ... --report-file ... --save-metrics解析 JSON经 review_schema.py 的parse_review_output归一化为ReviewResult生成 Markdown 审查报告与review_metrics.json并写入index.db的review_metrics表overall_score由问题严重度推导SEVERITY_PENALTIEScritical 扣 35、high 扣 15、medium 扣 6、low 扣 2pacing作为SCORE_CATEGORIES之一参与dimension_scores计算——但 review-schema.md 明确说明overall_score仅用于趋势观测与排序gate 决策仍以blockingtrue和 issue 明细为准报告生成时review_author_view.py 会把问题按阻断优先、严重度排序压缩为最值得处理的 1-3 件事面向作者输出⛔必须先改 / ⚠️建议改 / ✅可以继续三段式结论。配套的 webnovel-review 评测用例 验证了整条链路审查第 4 章时要求生成审查报告、识别时间线等事实/一致性问题、将审查指标写入 index.db且报告中的每个 issue 都有 evidence——这保证了包括节奏类问题在内的所有审查结论都可追溯、可复核。九、实战建议把节奏标准嵌入创作与审查循环综合 pacing-control 与仓库内相关规范建议的节奏管理闭环如下写作侧预防在 webnovel-write 创作时即遵循每 500 字一次节奏变化与局面变化 800-1400 字一个脉冲的微观规则从源头减少灌水段落章级自检按标准章节 / 过渡章节模板核对结构占比过渡章强制确认存在小冲突或小爽点审查侧诊断通过/webnovel-review {章号}触发审查由 reviewer 对照信息密度标准产出带证据的问题清单落库与趋势review-pipeline --save-metrics将维度分沉淀进review_metrics表长期追踪各章pacing维度分变化识别节奏恶化的趋势节点题材校准审查前明确题材 profile玄幻、都市、悬疑、短篇用对应的爽点密度与铺垫容忍度作为判定尺子避免跨题材套用同一标准。结语pacing-control 为网文节奏管理提供了一整套可量化、可执行、可复核的标准从每 1000 字至少 1 个实质性剧情点的核心指标到四级评分表、快慢节奏对比、章节结构模板、分题材参数再到灌水案例与错误修正清单。在 webnovel-writer 的审查体系里这些标准不是停留在文档层面的写作建议而是通过webnovel-review技能、reviewerAgent 与review-pipeline管线真正进入章节质量审查与指标沉淀流程的工程化规则——既服务于作者的自我诊断也服务于 Agent 的可验证审查。【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考