企业官网建设流程全解析

Webnovel Writer 上下文预算管理：context_manager 与 context_ranker 如何控制 token 消耗

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

Webnovel Writer 是基于 Claude Code 的长篇网文辅助创作系统，专为解决 AI 写作中的「遗忘」和「幻觉」问题而生，支持 200 万字量级连载。它的秘密武器之一，就是一套精密的上下文预算管理机制：由context_manager负责"该带什么、带多少"，由context_ranker负责"什么排前面"。两者配合，让每一章的创作都在有限的 token 预算内拿到价值最高的信息，而不是把整本书硬塞进模型窗口。📦

为什么"全量塞入"在长篇连载中行不通

写第 1 章时，上下文可能只有几百字；写到第 500 章时，如果要把全部大纲、设定、前文摘要、角色状态都喂给模型，token 消耗会爆炸式增长，而且大量信息对"这一章"毫无用处。

Webnovel Writer 的思路是：

1. 先圈定范围：只加载与当前章节相关的窗口内数据；
2. 再按权重装配：不同章节类型（剧情/战斗/情感/过渡）使用不同的预算配比；
3. 最后排序加分：把悬念、钩子、高严重度告警等高信号内容排到最前面。

这样模型"读到"的每一段文字都在预算之内，token 花在刀刃上。✂️

预算三杠杆：窗口、截断、权重

杠杆一：固定窗口 —— 只带"身边"的数据

在 config.py 中，所有预算参数都有明确默认值，每个章节包只取窗口内的内容：

其中"故事骨架"（story_skeleton）设计得特别精巧：写第 400 章时，系统会按context_manager.py中_load_story_skeleton的逻辑，从第 380、360、340……章各摘一段 400 字的缩影，让模型"记得住全书大走向"，却不用付出整本书的 token 代价。🗺️

此外，章节大纲加载时硬截断在 1500 字（见_load_outline），世界观、力量体系等全局设定也只取"骨架"文件。

杠杆二：模板权重 —— 不同章节类型，不同预算

在 context_weights.py 中，系统定义了 4 种上下文模板，每种模板对三大区块（core 剧情核心 / scene 场景人物 / global 全局设定）的预算配比不同：

战斗章把 45% 的预算给场景与人物（招式、在场角色最关键），过渡章则把 50% 给剧情核心（推进主线最重要）——预算跟着写作任务走，而不是平均分配。⚖️

杠杆三：动态预算 —— 连载越久，预算重心越偏移

这是很多长文工具忽略的细节。_resolve_context_stage会把章节分为三个阶段：

• early（第 30 章前）：core 权重上浮，人物和剧情刚铺展，最需要"记得住设定"；
• mid（30~120 章）：使用基础权重；
• late（第 120 章后）：global 权重从 0.25 提升到 0.35。

为什么后期要加大全局设定权重？因为连载越久，"遗忘"的代价越大——力量体系、人物关系网早就定型，模型必须看到更多全局锚点才能避免前后矛盾。这套阶段权重同样定义在 context_weights.py 的TEMPLATE_WEIGHTS_DYNAMIC_DEFAULT中。📈

ranker 的排序魔法：不删内容，只调顺序

窗口和权重决定了"装什么"，而 context_ranker.py 决定了"先看到什么"。它不删除任何内容，只做确定性排序：对摘要、元数据、出场角色、故事骨架、告警五个列表重新打分排序。

核心打分公式（_combine_score）：

总分 = 新近度 × 0.7 + 频率 × 0.3 + 加分项

三个因子各有门道：

• 新近度：1 / (1 + 章节差距)，上一章的摘要几乎满分，十章前的摘要只剩约 1/11 的分数；
• 频率：log(1 + 出场次数) / log(11)，用对数压缩，避免"戏份最多的主角"无限霸榜；
• 钩子加分（+0.2）：摘要里如果出现"？""悬念""钩子""反转""冲突"，说明这是剧情关键节点，直接提权置顶。

另外两个细节体现了工程经验：

1. 出场角色如果带有warning标记（存疑实体），扣 0.15 分，防止"待澄清的角色"干扰创作；
2. 告警列表中，严重级别为 critical/high 的 +0.3，文本含"冲突、矛盾、违规、断裂"等关键词的再 +0.3——红线问题永远排最前。🚨

所有权重（0.7 / 0.3 / 0.2）都是可配置项，打开context_ranker_debug后，每个条目还会附带_context_score调试分，方便你验证排序是否符合预期。

一条完整流水线：build_context 做了什么

在 context_manager.py 中，一次上下文构建分三步走：

_build_pack(chapter) → 装配 13 个区块（core / scene / global / 契约 / 信号 / 骨架……） ↓ ranker.rank_pack(pack) → 对五个高频列表重新排序，并写入 meta 中的 ranker 参数 ↓ _assemble_json_payload(...) → 按模板权重裁剪区块，标记 context_contract_version

最终产出的不是原始文件堆，而是一份结构化的上下文包。下游的 context-agent.md（写作前的研究 agent）会消费这份包，输出一份"五段写作任务书"交给起草阶段——也就是说，token 预算在这里被两次压缩：先由 manager 圈范围，再由 agent 压缩成人类可读的任务书。🧩

新手上手建议：如何调好你的上下文预算

• 先跑默认值：所有参数在 config.py 都有经过调校的默认值，大多数项目无需修改；
• 摘要窗口（3 章）偏小？如果你的剧情伏笔跨度常超过 3 章，可以适当调大context_recent_summaries_window，但记得它直接乘在每章 token 消耗上；
• 连载过 120 章：留意context_dynamic_budget_late_chapter阈值，确保后期章节自动切到 late 阶段，把全局设定权重拉高；
• 想验证排序：开启context_ranker_debug，在输出里检查_context_score_detail，确认钩子章节是否真的排在前面；
• 想临时关闭排序：设context_ranker_enabled为 False 即可回到纯按窗口装配的模式。

相关行为均有测试覆盖，可参考 test_context_manager.py 与 test_context_ranker.py。

相关源码导航

一句话总结：Webnovel Writer 用"窗口圈范围 → 权重定预算 → 排序提信号"三层漏斗，把 200 万字量级的记忆压缩成每章几十 K 的有效上下文——这正是它敢让 AI 连续写几百章而不"失忆"、不"幻觉"的底气所在。💪

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