企业官网建设流程全解析

Webnovel-Writer Harness v6 架构设计解析：以 Claude Code 为底座的长篇网文创作流水线重构方案

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

本文依据仓库设计文档 docs/archive/superpowers/specs/2026-04-02-harness-v6-design.md 展开，并结合 memory_contract.py、memory_contract_adapter.py、reviewer.md、context-agent.md、review_pipeline.py 等源码佐证。

Webnovel-Writer 是一套基于 Claude Code 的长篇网文辅助创作系统，目标是支撑 500-2000 章、200 万字量级的连载写作。本文详解其 Harness v6 设计：如何围绕「23 条问题清单」完成主流程收敛（废弃 → 合并 → 接口冻结），重构写前上下文、统一审查、记忆契约与章纲约束，把单章 Token 消耗从 300-500 万压缩到预估 80-150 万。读完你将掌握这套「Claude Code 原生能力 + 卷纲约束 + 记忆契约」三层 harness 的完整架构、接口冻结策略与迁移退出标准。

1. 设计背景与终极目标

v6 设计文档（2026-04-02 起草，2026-04-09 更新为草案 v7）源于三类输入：用户反馈、issue#5 的 token 分析、以及 23 条问题清单。它的终极目标不是做一个更大的工具集，而是：

• 写出一本长篇网络小说（500-2000 章），支持多种主流题材
• 文笔优秀，减少 AI 味
• 剧情跌宕起伏、出人意料（AI 主导创意，作者事后审核）
• 长上下文后保持文风且不吃书
• 完善的人机协作，可注入作者灵感
• 系统稳定，减少上下文消耗
• 合适的错误改善机制

2. 核心原则：三层 harness，减法优先

v6 的设计哲学可浓缩为四条原则：

2.1 本轮非目标（避免 scope creep）

以下方向已确认但不在 v6 迁移基线内，避免范围蔓延：

• Plan schema 全量落地——章纲字段草案仅作参考，plan skill 重构排在 Phase 6
• References 全量范例化——P0 方法论先补，P1 允许后续迭代
• Memory 底层存储重构——Phase 5，先冻结 v0 契约即可
• Init 迭代打磨机制——待 init 方案细化，不阻塞主链
• Anti-AI 超越黑名单的新机制——Phase 7，当前先用 reviewer 的ai_flavor维度兜底

本轮优先事项只有一个：主流程收敛（废弃 → 合并 → 接口冻结）+ 迁移退出标准达成。

3. 问题清单：23 条痛点的根因分析

v6 重构的起点是一份覆盖 Init、Plan、Write、记忆、系统级五个层面的问题清单。逐条理解这些问题，才能看懂后续每个设计决策的动机。

3.1 Init 层（3 条）

3.2 Plan 层（6 条）

3.3 Write 层（7 条）

3.4 记忆层（4 条）

3.5 系统级（3 条）

4. 已确认的设计方向：废弃、合并与重构

4.1 废弃项清单

可以看到，废弃项的共性都是「重复造轮子」或「token 无产出」——Claude Code 原生能力能替代的编排层全部砍掉，这是减法优先原则的直接体现。

4.2 新 Write 流程与章节状态模型

重构后的写章流程从 8 步收敛为 6 步：

Step 0.5 预检 → Step 1 上下文搜集（context-agent，research 模式） → Step 2 起草 → Step 3 审查（单 agent，code review 格式） → Step 4 润色 + 风格适配 + anti-AI → Step 5 数据回写（统一记忆模块，单次调用） → Step 6 Git 备份

章节状态模型（单调递进，不可回退）：

状态推进规则（解决问题 #15 的写作/回写耦合）：

• 由 Step 2/4/5 完成时分别推进，写入state.json.progress.chapter_status[NNNN]
• Step 5 失败不回滚 Step 1-4，章节停留在chapter_reviewed，不得开始下一章
• 允许带着回写 debt 结束会话，但下次会话必须先补完 Step 5
• 查询入口：

python -X utf8 "${SCRIPTS_DIR}/webnovel.py" --project-root "${PROJECT_ROOT}" state get-chapter-status --chapter {N}

这套模型的关键设计是「把回写失败从整条链的阻断点降级为章节级 debt」——写作链不再被存储故障卡死，但状态机的单调性又保证了记忆永远不欠账。

4.3 Context-Agent 新模式：从全量灌入到按需 research

旧模式的病根是「一次性全量灌入 → 输出巨大执行包」，新设计改为 research 模式四步走：

1. 调用记忆模块合并接口 → 拿到基础上下文（章纲目标、角色状态、未闭合伏笔）
2. 思考：这章还需要什么额外信息？
3. 按需调用记忆模块独立接口补充（某角色历史、某条世界规则、上章结尾）
4. 确认信息充分 → 按固定格式输出写作提示

在仓库实现中，这一点已经完全落地。context-agent.md 定义的主入口与按需补查命令如下：

# 主入口（一次性拿全基础包） python -X utf8 "${SCRIPTS_DIR}/webnovel.py" --project-root "{project_root}" memory-contract load-context --chapter {NNNN} # 按需补查（基础包不足时才调，已含的不重复查） python -X utf8 "${SCRIPTS_DIR}/webnovel.py" --project-root "{project_root}" memory-contract query-entity --id "{entity_id}" python -X utf8 "${SCRIPTS_DIR}/webnovel.py" --project-root "{project_root}" memory-contract query-rules --domain "{domain}" python -X utf8 "${SCRIPTS_DIR}/webnovel.py" --project-root "{project_root}" memory-contract get-timeline --from {N} --to {M} python -X utf8 "${SCRIPTS_DIR}/webnovel.py" --project-root "{project_root}" index get-reader-signals --limit 5 --last-n 20

load-context已打包的基础内容（无需重复查询）包括：story_contracts（MASTER/volume/chapter/review）、recent_summaries、urgent_loops、active_rules、protagonist、memory_pack（追读力）、genre_profile_excerpt、author_style_patterns（/webnovel-learn 累积的作者文风修正）、style_contract（设定集/风格契约）。只有当 contracts 返回空时才直接 Read.story-system/*.json。

4.4 统一审查：code review 格式 + blocking 语义

审查从「6 个 checker 各自打 90 分」重构为「1 个 agent 输出结构化问题清单」。

最小 schema：

{ "issues": [ { "severity": "critical | high | medium | low", "category": "continuity | setting | character | timeline | ai_flavor | logic | pacing | other", "location": "第3段", "description": "主角使用了第15章已失去的能力'xxx'", "evidence": "原文：'萧炎催动xxx斗技' vs 记忆：第15章已失去该能力", "fix_hint": "改为使用当前已有的yyy能力", "blocking": true } ], "blocking_count": 1, "summary": "发现1个阻断问题，2个高优问题" }

阻断规则：

• blocking=true的问题替代原timeline_gate语义——存在任何 blocking issue 时，不得进入 Step 4
• severity=critical默认blocking=true；其余 severity 由审查 agent 判断

blocking 修复循环：

• 存在 blocking issue 时，由主流程（非 reviewer）修复对应问题
• 修复后必须重跑 Step 3（完整审查），确认 blocking 清零
• 若用户明确覆盖（如判断为误报），可跳过重审直接进入 Step 4，需在 review report 中标注覆盖原因

关于用户覆盖，仓库提供了更细的裁决依据：blocking-override-guidelines.md 明确区分了三类场景——涉及设定冲突、时间线冲突、事实错误、连续性断裂的 issue禁止建议 override；而节奏偏差、角色风格软偏差、可选节点未覆盖等场景才允许用户确认后 override。

指标沉淀（轻量）：

• 每次审查结果写入index.db.review_metrics，字段：chapter, issues_count, blocking_count, categories, severity_counts, timestamp
• 用于趋势观测（连续 N 章某类问题反复出现 → 提示系统性问题）
• overall_score保留为衍生兼容字段（由 severity_weighted 扣分计算），仅用于排序/趋势，不可用于 gate 决策
• gate 决策始终以blocking=true和 issue 明细为准

仓库中的 review-schema.md 已将这套设计冻结为 schema：review_results.json保留完整issues列表，随后由 review-pipeline 生成review_metrics.json，同时包含落库兼容字段（overall_score、dimension_scores、severity_counts等）与 v6 观测字段（issues_count、blocking_count、categories等）。review_pipeline.py 的main()支持--review-results、--metrics-out、--report-file、--save-metrics四个参数，其中--save-metrics可直接写入index.db省去单独调用。

anti-AI 职责划分：

• Step 3 负责发现anti-AI 问题（category="ai_flavor"），列入问题清单
• Step 4 负责修复——消费 Step 3 的ai_flavorissue 逐条修改
• Step 4 修复后，必须独立复检——默认路径：重跑reviewer，仅启用ai_flavor维度。Step 4 不得自判 pass/fail
• 替代检查方案必须同时满足：① 独立于 Step 4 执行（不可由润色流程自判）；② 结构化 JSON 输出（含blocking_count）；③ 结果可落盘、可追溯（写入.webnovel/tmp/）

这一设计的核心动机是避免「自己改、自己说通过」的闭环偏差——审查与修复必须分离到不同步骤执行。

仓库中的统一审查 agent reviewer.md 进一步收窄了职责：只查 5 个维度（设定一致性setting、时间线timeline、叙事连贯continuity、角色一致性character、逻辑logic），不评分、不给建议、不写摘要性评价，且强制要求对每个维度输出结论（无问题也显式输出pass），并规定「只报可验证的问题——必须有 evidence（原文引用 or 数据对比）」。category取值规范中pacing/other仅为后端兼容枚举，该 agent 不主动产出。

4.5 记忆模块：接口契约先行，存储实现后置

记忆模块分两阶段交付，核心策略是先把契约冻结，存储重构不阻塞主链。

阶段 A：接口契约（先定，不依赖存储实现）

上层消费者（context-agent、data-agent、审查 agent）只依赖契约，不依赖具体存储实现。

v0（已实现，当前冻结）——由memory_contract.py（Protocol + 类型定义）和memory_contract_adapter.py（适配器）实现，CLI 入口为webnovel.py memory-contract子命令：

# 合并接口 memory.commit_chapter(chapter: int, result: dict) -> CommitResult memory.load_context(chapter: int, budget_tokens: int) -> ContextPack # 独立接口（context-agent research 模式按需调用） memory.query_entity(entity_id: str) -> EntitySnapshot memory.query_rules(domain: str) -> list[Rule] memory.read_summary(chapter: int) -> str memory.get_open_loops(status: str = "active") -> list[OpenLoop] memory.get_timeline(from_ch: int, to_ch: int) -> list[TimelineEvent]

在 memory_contract.py 中，这套契约被实现为@runtime_checkable的MemoryContractProtocol，并定义了六个 dataclass 返回类型（CommitResult、EntitySnapshot、Rule、OpenLoop、TimelineEvent、ContextPack），每个都带to_dict()便于序列化落库。上层消费者只依赖该 Protocol，不直接依赖StateManager/IndexManager/ScratchpadManager等具体实现。

memory_contract_adapter.py 则是薄适配器：不做存储重构，仅委托给现有模块。从源码可见：

• commit_chapter会根据 result 是否包含review_result/fulfillment_result/disambiguation_result/extraction_result四个键自动选择主链（ChapterCommitService）或 legacy 路径
• load_context内部组装 9 类 sections：story_contracts、runtime_status、memory_pack、outline、recent_summaries、protagonist/progress、active_rules（前 5 条）、urgent_loops（前 3 条）、genre_profile_excerpt、author_style_patterns（project_memory.json）、style_contract（风格契约.md，截取前 2000 字符）
• 各契约方法内部均有 try/except 降级，任一存储模块失败只记 warning 不中断整链

与 v0 配套的提交类型化在 chapter_commit_schema.py 中可见：ReviewResult（要求顶层blocking_count字段）、FulfillmentResult（planned_nodes/covered_nodes/missed_nodes/extra_nodes）、DisambiguationResult（pending）、ExtractionResult（accepted_events/state_deltas/entity_deltas）——这正是 v1 中「result: dict→ 类型化CommitPayload」的落地形态。

v1（Phase 3 增强目标，v0 冻结后再迭代）：

• commit_chapter的result: dict→ 替换为类型化CommitPayload（明确字段：chapter_file、review_result、entities、summary 等）
• load_context增加intent: Literal["draft", "review", "repair"]参数，按意图裁剪返回内容
• query_rules的domain: str→ 细化为domain: str, scope: str = "all"支持子域过滤
• 所有返回结构统一包含横切元数据：source、chapter_range、confidence

v0 → v1 的升级不影响上层 prompt，仅影响 CLI 参数和返回字段丰富度——这正是接口冻结的价值：prompt 改动永远有稳定接口可依赖。

阶段 B：存储实现（后做）

已确认方向：

• 按时效分层：近期（详细）→ 中期（摘要）→ 远期（活跃事实）
• 时间线作为索引轴
• 记忆类型：角色状态（可变）、世界规则（稳定）、伏笔（有生命周期）

具体实现方案搁置，待进一步思考。

4.6 Plan：章纲约束重构方向

章纲作为 harness 给 write 足够约束，但约束形式需要变：

• 约束「方向和边界」，不约束「具体发生什么」
• 时间约束隐性化——不在章纲里写死时间锚点，通过记忆系统间接传递，写后校验
• Strand 比例按题材预设，不硬编码 60/20/20
• 卷级叙事功能——每章需要标注在卷中的叙事角色（起/承/转/合）

章纲最小字段草案（待验证）：

内容层（章纲本体）：

{ "chapter_goal": "主角通过考验进入迦南学院", "must_payoff": ["第3章埋下的丹药伏笔"], "forbidden_turns": ["主角不可直接暴露隐藏身份"], "narrative_role_in_arc": "承", "strand_profile": "main_heavy", "time_pressure_source": "入学截止" }

消费策略层（控制章纲如何喂给写作 AI，不属于故事内容）：

{ "writer_exposure_policy": { "verbatim_fields": ["chapter_goal", "must_payoff", "forbidden_turns"], "transform_fields": { "narrative_role_in_arc": "转为隐性节奏提示，不直接告知'承'", "time_pressure_source": "仅作为校验依据，不在正文中直接提及具体数字或倒计时" } } }

说明：

• chapter_goal：方向而非剧透，不写「主角救了叫朵朵的小女孩」
• forbidden_turns：明确边界，防止跑偏
• strand_profile：取代硬编码数值配比，由 genre-profiles 定义具体权重（如main_heavy= 主线 70%+、balanced= 均衡、relationship_heavy= 感情线主导）
• writer_exposure_policy：独立于内容层，由 context-agent 消费时解释，章纲 schema 本身不混入传输逻辑

这套设计直指问题 #4、#6、#7 的根因：章纲只负责「方向与边界」，是否剧透、如何暴露由消费策略层单独控制，时间压力只作为写后校验依据而不再进入正文。

4.7 Skill/Agent Prompt 统一模板

每个 skill/agent 文件按固定结构编写，解决问题 #21 的格式混乱：

1. 身份与目标 2. 可用工具与脚本（含调用方式） 3. 思维链（ReAct / 其他） 4. 输入 5. 执行流程（每步：输入 → 动作 → 输出） 6. 边界与禁区 7. 检查清单 8. 输出格式 9. 错误处理

仓库中的 context-agent.md 与 reviewer.md 正是这一模板的完整落地样板（均为 9 段式结构，含工具调用、边界禁区、检查清单、SubagentRun 信号、错误处理表）。

4.8 参考资料：删冗余、补范例

删除：冗余引用、已废弃文档、重复的 shared 引用（共 13 个文件）。

补充（P0，16 条）：

• 反派设计、镜像反派、对手梯度、人物关系动力学
• 时间线设计、长篇升级节奏、反派压迫递进、伏笔埋设与回收
• 感情线递进、身份隐藏与曝光
• 暧昧/打脸/反转/对峙场景写法
• 章节开头钩子、章节结尾 cliffhanger

要求：参考资料按优先级分层补充真实小说片段：

• P0（关键方法论）：必须包含真实小说片段作为正面/反面范例——追读力钩子、反转写法、对峙场景等直接影响写作质量的方法论
• P1（次级方法论）：允许先用自写范例或抽象示例，后续逐步替换为真实片段

改造：现有genres/和write/references/下的文件从「结构模板」改为「方法论 + 范例 + 反面教材」。

5. Token 优化预估

以下为方向性估算，具体取决于正文长度、审查轮次、research 命中率。需用真实运行日志验证。

假设条件：

• 单章正文 2000-2500 字
• 审查无 blocking 需返工的情况
• context-agent research 模式命中率 > 80%

值得强调的是，最大的两个节省来源（审查合并、context-agent research 化）都源于「减少 token 无产出环节」，而非压缩正文信息量——这与问题 #12、#11 的根因一一对应。

6. 实施路径与接口冻结策略

Phase 1/2A/3 可并行探索，但合并前需一次接口冻结，优先冻结以下两项：

• review-schema（reviewer 输出格式 + metrics 落库字段）
• memory-contract CLI（记忆模块接口签名 + 返回类型）

冻结后 Phase 1/2A 的 prompt 改动才有稳定的接口可依赖。

7. 迁移退出标准：v6 完成的 6 条硬指标

以下条件全部满足时，视为 v6 迁移完成：

1. 仓库内不再存在对 6 个 checker 的运行时引用——skill/agent prompt 中无continuity-checker、setting-checker等旧名
2. webnovel-write / webnovel-review 均只走 reviewer 流——审查路径唯一
3. workflow_manager相关代码完全移除——不残留 import、调用或配置
4. legacy 术语分层清零：
   • 运行时引用（skill/agent/script 中）：0 处
   • prompt/skill 生效路径引用：0 处
   • 测试 fixture / 迁移兼容样本：允许存在，但必须集中在evals/或tests/目录
   • 历史文档（docs/）：允许存在，但必须标注[deprecated]
5. 至少 1 个真实项目完成连续 10 章验证，验收维度：
   • 无流程阻断异常（全链路 plan → write → review → data 跑通）
   • 无状态回写错乱（chapter_status 单调递进，state.json / index.db 一致）
   • 无 review / write / data 契约不一致（reviewer 输出可被 review-pipeline 正确解析，data-agent 产物符合 memory v0 契约）
6. 章节状态模型已落地到 state.json——chapter_drafted/chapter_reviewed/chapter_committed可通过 CLI 查询，状态推进由 Step 2/4/5 原子写入

8. 未解决的设计问题

9. 总结：v6 设计对同类系统的可迁移启示

Harness v6 的价值不止于一个网文工具的内部重构，它的方法论对任何「LLM 长流程 Agent 系统」都有借鉴意义：

1. 把编排层让给平台原生能力：Claude Code 的/resume、Task、自动 compaction 能覆盖的，绝不自建 workflow 层——省下的是真金白银的 token。
2. 审查与修复必须职责分离：「自己改、自己说通过」是闭环偏差的温床；发现（Step 3）、修复（Step 4）、独立复检（重跑 ai_flavor 维度）三段式是不可省略的最小可信闭环。
3. 接口契约先于存储实现冻结：MemoryContractProtocol +review-schema的冻结，让 prompt 改动与存储重构解耦，Phase 1/2A/3 因此可以并行。
4. 状态机单调性是长链系统的安全网：chapter_drafted → chapter_reviewed → chapter_committed不可回退，配合「回写 debt 可带出会话但必须先补」的规则，兼顾了健壮性与数据一致性。
5. 减法优先胜过叠加流程：23 条问题中有近半数（审查、context、workflow、风格适配）是通过「砍」而不是「加」解决的。

仓库中 memory_contract.py、reviewer.md、context-agent.md、review_pipeline.py、review-schema.md 等文件即为该设计的现存实现，可作为深度阅读的起点。

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