WebNovel Writer 核心约束体系：网文专属防幻觉协议的三大定律与章节合规清单

WebNovel Writer 核心约束体系：网文专属防幻觉协议的三大定律与章节合规清单

【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统，解决 AI 写作中的「遗忘」和「幻觉」问题，支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer

导读：core-constraints.md是 webnovel-writer 项目面向"章节级写作合规"的单一事实源（single source of truth），它以"缺陷补偿层（网文特定防幻觉协议）"的身份在每次章节写作与审查前加载，用大纲即法律、设定即物理、发明需识别三大定律约束 Claude 在长篇网文创作中的自由发挥边界。读完本文，你将掌握这套协议的全部规则细节、其与 Data Agent 实体提取、index.db 索引、审查流水线之间的底层联动机制，以及如何在实际写章流程中落地执行。

webnovel-writer是一套基于 Claude Code 的长篇网文辅助创作系统，其核心痛点是 AI 写作中的「遗忘」与「幻觉」。与通用写作规范不同，网文创作有独特的一致性风险：主角实力突然跳级、新人物凭空出现、设定前后矛盾、伏笔失联。core-constraints.md正是为此设计的"防幻觉协议"——它不重复 Claude 已知的通用写作规范，只补充网文特定的硬约束。本文将以该文档为骨架，结合仓库中的 Agent 定义、Python 校验模块与测试用例，逐条拆解这套协议的设计意图与实现方式。

一、文档定位：缺陷补偿层与单一事实源

文件头部元信息明确了它在整个技能体系中的位置：

• 主服务 skill：webnovel-writeStep 2（起草正文阶段）
• 次服务 skill：webnovel-reviewStep 2（审查阶段）
• 内容层级：缺陷补偿层（网文特定防幻觉协议）

在 webnovel-write 的 SKILL.md 中，Step 2 明确写道"不加载 core-constraints/anti-ai-guide（已内化到任务书）"——即起草阶段约束由 context-agent 在 Step 1 生成写作任务书时消化，正文阶段只依据任务书输出；而在 webnovel-review 的 SKILL.md Step 3 的"按需加载参考"表中，always加载../../references/shared/core-constraints.md，审查阶段逐条对照执行。

文件<context>部分有一句关键的工程约束：

此文件为 shared 单一事实源；禁止在各 Skill 的 references 下复制修改。若需更新，请修改本文件。

这与仓库中 cool-points-guide.md、strand-weave-pattern.md 的声明完全一致，构成了shared/目录"单一事实源"的管理模式：规则只存在一处，技能通过相对路径引用，避免多副本漂移导致的约束不一致。

二、三大定律：低自由度硬约束

定律	规则	检查方式
大纲即法律	严格执行大纲，不得擅自发挥	审查时对照大纲
设定即物理	实力/招式/物品 ≤ index.db 记录	写作前查询确认
发明需识别	新实体由 Data Agent 自动提取	章节完成后处理

三大定律被标记为"低自由度——必须精确执行"，是整个防幻觉协议的基石。

2.1 大纲即法律

写章流程中，webnovel.py story-system命令会先从详细大纲解析真实本章目标（CHAPTER_GOAL），再刷新 runtime 合同树。SKILL.md 中特别强调：调用 story-system 前"禁止传{章纲目标}、第N章章纲目标等占位 query"，同时chapter_{NNN}.json必须优先检查顶层chapter_directive，chapter_focus只能来自chapter_directive.goal或真实 query，不得从dynamic_context的参考摘要继承。这套"目标溯源"机制保证了写作依据永远锚定在大纲合同上，从数据流层面落实"大纲即法律"。

2.2 设定即物理

"实力/招式/物品 ≤ index.db 记录"意味着主角不能凭空拥有超出索引记录的能力。Index 索引库以 SQLite 存储实体数据（见 index-schema.md 中的entities、aliases、state_changes、relationships等表），写作前可通过state get-entity --id {entity_id}、index get-core-entities等命令查询确认。

2.3 发明需识别

新实体（角色/地点/物品）不允许"静默出现"，而必须由 Data Agent 在章节完成后自动提取并写入 index.db——这正是"设定即物理"的闭环：新设定必须先入账，才能成为后续章节可引用的"物理事实"。

三、新实体处理流程：纯正文 + 自动提取

当前规则已演进为正文不再要求 XML 标签，三步流程：

1. 写作时：直接写纯正文，新角色/地点/物品正常描写，不施加标记负担
2. 完成后：Data Agent 自动识别新实体并写入 index.db
3. 不确定实体：Data Agent 标记为uncertain，由人工确认

3.1 Data Agent 的提取与消歧实现

data-agent.md 定义了提取的完整 schema 与边界：

• 产出fulfillment_result.json（planned/covered/missed/extra_nodes）、disambiguation_result.json（pending 数组）、extraction_result.json（accepted_events、state_deltas、entity_deltas、entities_appeared、scenes、summary_text等）
• entity_deltas的entity_type支持角色|组织|地点|物品|势力五类
• accepted_events的event_type枚举覆盖character_state_changed、power_breakthrough、relationship_changed、world_rule_revealed、open_loop_created等 10 种事件，其中open_loop_created用于伏笔埋设
• 置信度消歧由 entity_linker.py 的evaluate_confidence完成，阈值定义在 config.py：

extraction_confidence_high: float = 0.8 extraction_confidence_medium: float = 0.5

对应三条决策路径（与文档"标记 uncertain 由人工确认"精确对应）：

置信度区间	动作	处理方式
≥ 0.8	auto	自动采用，直接写入
0.5 ~ 0.8	warn	采用 + warning（写入disambiguation_warnings）
< 0.5	manual	待人工确认（写入disambiguation_pending）

3.2 未消歧实体的写前阻断

disambiguation_pending不只是"待办"，它会在下一章写前变成硬阻断。prewrite_validator.py 的build()方法中，只要state.json存在disambiguation_pending，blocking_reasons就会追加"存在高优先级 disambiguation_pending"，从而让prewritegate 判定blocking=true。这形成了"上一章未确认实体 → 下一章无法动笔"的强制闭环，从源头杜绝"带着悬案写作"。

四、章节约束分层：Hard / Soft / Style / Anti-AI

约束按自由度从低到高分为四层，是本章合规检查的核心清单。

4.1 Hard（必须）

• 本章可读性达标：读者能回答"发生了什么 / 谁在做什么 / 为什么"
• 本章必须存在清晰推进：问题、目标、代价、关系变化、信息变化至少一项可被识别
• 上章承诺必须回应：若上章有明确承诺（钩子/未闭合问题），本章必须回应（允许部分兑现，不要求一次性结清）
• 禁止输出占位正文：如[待补充]、[TODO]、...（省略）...

"禁止占位正文"并非仅靠模型自觉，仓库在代码层有双重防线：

• placeholder_scanner.py 通过正则\[待[^\]]*\]、（暂名）|(待补充)、\{占位\}|<占位>扫描大纲/、设定集/下的全部 Markdown，提供--format json/text输出；
• 写章预检阶段执行webnovel.py placeholder-scan --format text强制扫描；
• 同时 prewrite_validator.py 会把"与本章chapter_directive.key_entities相关的未补齐占位"也列为阻断原因（_related_placeholders方法按实体词在占位上下文中的命中判定）。

4.2 Soft（建议）

• 开头尽早进入冲突/风险/强情绪：建议前200-400 字（已从固定 120 字放宽，避免模板化）
• 未闭合问题或下一章期待锚点放在章末或后段（不再限定"后 80-150 字"）
• 局面变化保持节奏感：参考800-1400 字一个脉冲，短章至少一次实质变化
• 微兑现频率按题材 profile 建议执行，不要求机械等间距

注意这些项从"必须"降级为"建议"，但审查流水线仍会在报告中体现——reviewer.md 只查设定一致性、时间线、叙事连贯、角色一致性、逻辑 5 个可验证维度，而 Soft 层建议由 review-pipeline 以非 blocking issue 形式输出。

4.3 Style（可选强化）

• 对话尽量带意图（试探/回避/施压/诱导），减少纯说明句
• 避免连续大段纯解释；若必须解释，切分为"信息 + 行动/反应"
• 避免"回去休息了"式机械收尾；若使用平缓收尾，需同时保留未闭合期待

4.4 Anti-AI（写作时预防）

六大硬性写作纪律：

1. 禁止连续 3 段以上使用相同句式结构
2. 情绪描写必须通过行为/生理暗示，禁止直接标签（"他感到X"）
3. 每 500 字至少有一次节奏变化（短句爆发、对话插入、场景切换）
4. 对话必须带意图冲突，禁止纯信息传递
5. 章末禁止"安全着陆"——必须保留至少一个未解决的问题或不安感
6. 删掉万能副词（缓缓/淡淡/微微），用具体动作替代

第 6 条的"万能副词禁用"在webnovel-writeStep 4 润色阶段由references/polish-guide.md的 "Anti-AI 检测细则" 与词库段配套执行；当anti_ai_force_check=fail时不得进入 Step 5 提交（见 SKILL.md 充分性闸门第 4 条）。

五、爽点与节奏：按题材 profile 调整

• 爽点密度由题材与章型共同决定：过渡章允许低密度，但不允许"整章无收获"
• 组合爽点与里程碑爽点采用滚动窗口评估（5章 / 10-15章），用于预警而非逐章硬判
• 连续同类型爽点达到3 章记为风险预警，优先通过类型变体或执行差异化修正

"滚动窗口"与 cool-points-guide.md 的密度建议表严格对应：

周期	要求
逐章	优先保证有"爽点或同等兑现"，允许过渡章低密度
每 5 章	建议 ≥1 个组合爽点（2 种模式叠加）
每 10-15 章	建议 ≥1 个里程碑爽点（改变主角地位）

cool-points-guide 还给出了"3 章同类型爽点后如何调整"的标准解法：第 4 章改为越级反杀或打脸权威、或穿插 Fire Strand（感情线）调节节奏——与 core-constraints 的"通过类型变体或执行差异化修正"互为印证。爽点强度分级（小爽点/组合爽点/里程碑爽点）与 30/40/30 三段式框架、压扬比例（传统爽文 3:7、硬核正剧 5:5、虐恋黑深残 7:3）共同构成爽点工程的完整方法论。

六、Strand 平衡警告：三线节奏兜底

情节线	警告条件
Quest（主线）	连续 5+ 章
Fire（感情线）	>10 章未出现
Constellation（世界观）	>15 章未出现

该表与 strand-weave-pattern.md 的"交织规则（低自由度 - 必须执行）"完全一致，后者补充了三线占比建议（Quest 55-65% / Fire 20-30% / Constellation 10-20%），以及state.json中的追踪器结构：

{ "strand_tracker": { "last_quest_chapter": 45, "last_fire_chapter": 43, "last_constellation_chapter": 40, "current_dominant": "quest", "chapters_since_switch": 3, "history": [{"chapter": 46, "dominant": "quest"}] } }

history[].dominant为当前标准字段（由 update_state.py 写入），旧数据history[].strand需兼容映射。strand-weave-pattern 还提供了前 30 章织网模板与两个判断示例（第 46 章无警告 / 第 55 章 Fire 断线 13 章触发警告），可用于理解警告条件的实际计算方式。core-constraints 表内只做"预警"而非硬判——这与爽点滚动窗口"预警而非逐章硬判"的设计哲学一致：系统负责提示节奏失衡，创作自由度仍交给作者。

七、禁止事项清单

• [待补充]、[TODO]、...（省略）...→必须完整写出（配合 placeholder-scanner 的代码级扫描）
• 战斗后无善后描述（都市异能题材）→ 战斗必须留下战利品、后果或局面变化

八、示例与错误对照：可执行的判定逻辑

文档给出的两则示例是"设定即物理 / 发明需识别"最直观的执行示范：

示例一（新技能使用路径）

输入：主角需要使用"天雷掌"击败敌人 输出：

1. 查询 index.db 中是否有"天雷掌"技能
2. 若有：直接使用
3. 若无：在正文中描写获得途径（如拜师/领悟/传承），Data Agent 会自动提取

示例二（边界情况：实力等级冲突）

输入：剧情需要主角展示筑基期实力，但 index.db 显示练气期 输出： ❌ 直接写筑基期战力 → 违反"设定即物理" ✅ 先安排突破场景，Data Agent 更新 index.db，再展示新实力

错误对照表（errors 段）：

❌ 错误	✅ 正确
新实体描写模糊（无法自动识别）	确保新实体有明确名称和描写
主角突然会新技能	先描写获得途径
实力设定不一致	写作前查询 index.db 确认
整章无推进点（无目标/无代价/无变化）	补至少一项可识别推进

第一行"新实体必须有明确名称和描写"直接呼应第 3.1 节的置信度消歧机制：模糊描写会导致实体无法通过别名索引命中，进而跌入<0.5 人工确认区间，为下一章制造写前阻断。

九、工程落地：任务书内化 + 审查复核的双通道

这套协议在流水线中有两个执行通道：

写作通道（预防）：context-agent 在 Step 1 生成写作任务书时，按"本章硬性约束 → CBN/CPNs/CEN → 本章禁区 → 风格指引 → dynamic_context 补充参考"的固定顺序输出五段任务书，将 core-constraints 与 anti-ai-guide 内化进约束与风格段；Step 2 只依据任务书起草，"只输出纯正文，无占位符"，并有结构化节点时围绕 CBN→CPNs→CEN 展开。

审查通道（复核）：webnovel-reviewStep 3 恒加载 core-constraints 与 review-schema，再由统一 reviewer 按 5 个维度（setting/timeline/continuity/character/logic）输出结构化 JSON；review-pipeline --save-metrics将阻断判定（blocking=true）落库到index.db的review_metrics表。审查维度中的"设定一致性（角色能力是否与当前境界匹配）"正是"设定即物理"的审查侧镜像，而"叙事连贯（上章钩子是否有回应）"正是 Hard 层"上章承诺必须回应"的审查侧镜像。

两侧数据最终汇入 index.db：entities/aliases承载"设定即物理"的事实底座，state_changes记录状态演化，appearances记录出场与置信度，review_metrics记录审查结果，共同构成 200 万字量级连载下可审计、可追溯的一致性保障。

十、总结

core-constraints.md用一份文件完成了网文创作防幻觉协议的完整闭环设计：三大定律定基调，四层约束定标准，滚动窗口管节奏，Strand 警告兜平衡，占位符扫描做底线，Data Agent 消歧建事实。它与 context-agent（任务书内化）、reviewer（五维复核）、prewrite/precommit/postcommit 三级 write-gate、placeholder-scanner、EntityLinker 置信度机制共同协作，把"防幻觉"从提示词层面的道德约束，落实为数据层、代码层、流程层的硬性工程保障——这正是 webnovel-writer 支撑长篇连载一致性的底层协议之一。

延伸阅读：cool-points-guide.md（爽点工程）、strand-weave-pattern.md（三线交织）、data-agent.md（实体提取 schema）、prewrite_validator.py（写前阻断实现）、placeholder_scanner.py（占位符扫描实现）、reviewer.md（五维审查细则）。

【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统，解决 AI 写作中的「遗忘」和「幻觉」问题，支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer