Webnovel Writer 断点续跑实现原理run_ledger 与 run_logger 如何记录可信进度【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writerWebnovel Writer 是一套基于 Claude Code 的长篇网文辅助创作系统专为 200 万字量级连载设计。它的「断点续跑」能力由 run_ledger运行账本与 run_logger脱敏日志两个模块支撑写章中途失败后重新执行命令即可从最近的可信进度自动继续而不是从头重写。本文用 5 分钟讲清它们的实现原理。为什么长篇 AI 写作需要断点续跑一章网文不是「生成一下就完事」而是一条包含 6 个步骤的流水线起草正文 → 写作审查 → 提取故事事实 → 提交 → 更新资料投影→ 备份流程越长中途出错的概率越大API 超时、磁盘写入失败、审查服务卡住……如果每次都从头重跑不仅浪费算力还可能用旧正文覆盖你刚改过的手稿。传统方案的缺陷在于「文件存在」不等于「这步真的做完了」。比如正文文件存在但章纲在正文写完后才更新这份正文其实已经过期了。Webnovel Writer 的解法是为每一步记录带文件指纹的账本条目续跑时逐条校验只信「仍然可信」的进度。两个模块各管什么模块职责落盘位置run_ledger记录写章 6 步的状态与输入/输出文件指纹生成续跑建议.webnovel/run_ledger.jsonrun_logger写入脱敏的运行日志命令、异常摘要、耗时供故障排查.webnovel/logs/run_last.log简单说账本回答「下一步该跑什么」日志回答「上次到底出了什么事」。作者日常只看账本产出的报告日志只在不可恢复故障时才需要翻。run_ledger 原理6 步账本 文件指纹6 个写章步骤被逐一登记账本固定跟踪 6 个步骤定义于 run_ledger.py步骤含义续跑动作可能是draft起草正文skip / runreview一致性审查skip / rundata提取本章故事事实skip / runcommit提交事实到 Story Systemskip / runprojection更新索引、摘要、记忆等资料skip / run / retrybackup备份本章skip / run / retry每个步骤完成时系统会写入状态、时间戳、耗时以及输入/输出文件的签名sha256 哈希 文件大小 修改时间见 file_signature。续跑前先「验指纹」生成续跑建议时build_write_resume_plan系统不是盲目相信账本而是做三重校验正文指纹比对重新计算正文文件的 sha256与账本记录不一致 → 判定你手改过正文暂停并询问「沿用手改版还是重新起草」。时间先后校验如果章纲/合同的更新时间晚于正文说明依据已过期正文标记为不可信。提交状态联动读取.story-system/commits/下的 commit 文件状态accepted / rejected决定后续步骤是跳过、重跑还是补跑。遇到模糊地带会主动询问系统内置了 4 类「需要你确认」的续跑分支场景系统行为正文与账本记录不一致chapter_file_changed询问沿用手改正文还是重新起草章纲晚于正文outline_newer_than_draft询问沿用旧正文还是重跑本章已 acceptedchapter_already_accepted询问重写正文还是只查看状态提交被拒chapter_commit_rejected提示先修复阻断项再重新提交这正是「可信进度」的核心宁可停下来问你一句也不拿过期产物继续跑。run_logger 原理日志自动打码密钥绝不落盘排查「上次为什么失败」时日志里常混着 API 密钥这类敏感信息。run_logger 在写入前会做两层脱敏redact_payload键名匹配任何包含api_key、secret、token、authorization、password、credential的字段值直接替换为redacted。文本扫描即使是普通字符串里的RERANK_TOKENabc123这类赋值正则也会把值打码。单测 test_run_logger.py 验证了嵌套 JSON、Bearer token、环境变量三种形态的密钥都进不了日志文件。3 条命令看懂断点进度以下命令通过统一 CLI 调用详见 commands.md目的命令记录某步状态webnovel.py run-ledger record-write-step --chapter 12 --step draft --status completed查看续跑建议webnovel.py run-ledger write-resume --chapter 12 --format text写一条脱敏日志webnovel.py run-log --event write_failed --payload-json {chapter:12}write-resume的输出长这样text 格式resume_from: data chapter: 12 - draft: skip (正文可信) - review: skip (审查结果匹配当前正文) - data: run (data artifacts 缺失或过期) - commit: run (尚未生成 commit)一眼就能看出从第 3 步继续前两步不用重跑。相关源码与文档想深入源码时从这几处入手账本核心run_ledger.py6 步定义、指纹校验、续跑计划日志核心run_logger.py脱敏正则、写日志行为测试test_run_ledger.py、test_run_logger.py设计出处author-friendly-reporting-plan-2026-06-07.md 第 9 节「断点续跑设计」CLI 用法commands.md小结run_ledger 用「步骤 文件指纹 提交状态」三位一体的校验把「文件还在」升级为「这步仍可信」run_logger 用两层脱敏让日志可以放心保存故障现场。两者配合让长篇连载创作在偶发失败后从失败点继续而不是从头再来——这正是支撑 200 万字量级稳定连载的工程底座。【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考