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 校验模块与测试用例逐条拆解这套协议的设计意图与实现方式。一、文档定位缺陷补偿层与单一事实源文件头部元信息明确了它在整个技能体系中的位置主服务 skillwebnovel-writeStep 2起草正文阶段次服务 skillwebnovel-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_directivechapter_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 标签三步流程写作时直接写纯正文新角色/地点/物品正常描写不施加标记负担完成后Data Agent 自动识别新实体并写入 index.db不确定实体Data Agent 标记为uncertain由人工确认3.1 Data Agent 的提取与消歧实现data-agent.md 定义了提取的完整 schema 与边界产出fulfillment_result.jsonplanned/covered/missed/extra_nodes、disambiguation_result.jsonpending 数组、extraction_result.jsonaccepted_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.pyextraction_confidence_high: float 0.8 extraction_confidence_medium: float 0.5对应三条决策路径与文档标记 uncertain 由人工确认精确对应置信度区间动作处理方式≥ 0.8auto自动采用直接写入0.5 ~ 0.8warn采用 warning写入disambiguation_warnings 0.5manual待人工确认写入disambiguation_pending3.2 未消歧实体的写前阻断disambiguation_pending不只是待办它会在下一章写前变成硬阻断。prewrite_validator.py 的build()方法中只要state.json存在disambiguation_pendingblocking_reasons就会追加存在高优先级 disambiguation_pending从而让prewritegate 判定blockingtrue。这形成了上一章未确认实体 → 下一章无法动笔的强制闭环从源头杜绝带着悬案写作。四、章节约束分层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写作时预防六大硬性写作纪律禁止连续 3 段以上使用相同句式结构情绪描写必须通过行为/生理暗示禁止直接标签他感到X每 500 字至少有一次节奏变化短句爆发、对话插入、场景切换对话必须带意图冲突禁止纯信息传递章末禁止安全着陆——必须保留至少一个未解决的问题或不安感删掉万能副词缓缓/淡淡/微微用具体动作替代第 6 条的万能副词禁用在webnovel-writeStep 4 润色阶段由references/polish-guide.md的 Anti-AI 检测细则 与词库段配套执行当anti_ai_force_checkfail时不得进入 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 的代码级扫描战斗后无善后描述都市异能题材→ 战斗必须留下战利品、后果或局面变化八、示例与错误对照可执行的判定逻辑文档给出的两则示例是设定即物理 / 发明需识别最直观的执行示范示例一新技能使用路径输入主角需要使用天雷掌击败敌人 输出查询 index.db 中是否有天雷掌技能若有直接使用若无在正文中描写获得途径如拜师/领悟/传承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输出结构化 JSONreview-pipeline --save-metrics将阻断判定blockingtrue落库到index.db的review_metrics表。审查维度中的设定一致性角色能力是否与当前境界匹配正是设定即物理的审查侧镜像而叙事连贯上章钩子是否有回应正是 Hard 层上章承诺必须回应的审查侧镜像。两侧数据最终汇入 index.dbentities/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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考