一句话定位：本地优先、可恢复的长篇小说生产引擎。把大纲、人物、世界状态、RAG、
正文审核与返工，从易丢失的聊天上下文，转换成保存在本机、可验证、可恢复的生产流水线。
一、核心档案
| 项 | 内容 |
|---|---|
| 仓库 | github.com/Xiaoyangy/novel-studio |
| 定位 | 本地优先长篇小说 / 网文连载引擎（CLI + 流水线，非桌面编辑器） |
| 主语言 | Go |
| 许可 | Apache-2.0（仓库 LICENSE 明确） |
| 面向 | 长篇小说、网文连载、短篇整书、故事工作室 |
| 部署 | 本地运行，支持断点恢复 |
核心流程（区别于普通「续写壳」）
- 新规划先冻结全书导航，完成整弧条件预演；
- 重要角色只在接下来至多 3 章的窗口内独立决策并裁决后果；
- 窗口封存后，才逐章渲染、逐章审核；
- 只有通过审核的正文和实际结果，才进入「正史」。
这不是「所见即所得」的桌面编辑器，而是把「规划 → 推演 → 渲染 → 审核」拆成可恢复阶段的生产线。
二、关键数据（快照 2026-10-11）
| 指标 | 数值 | 来源 |
|---|---|---|
| Stars | 待核实 | 仓库页未回传具体数字 |
| Forks | 待核实 | — |
| 许可 | Apache-2.0 | 仓库 LICENSE 徽章 |
| 文档 | 简体中文 + English | 仓库 README |
三、真问题·硬伤 vs 建议
真问题 / 硬伤
- 星标数据缺口：仓库页面未回传明确 Stars/Forks，本卡标 待核实——
引用前必须自行核对，不能凭「看起来新」就下判断。
- Go 生态门槛：核心是 Go 实现，若老爷要二次开发或改节点，技能栈不匹配（现有工作流多为 Node/Python）。
- 「只有过审才进正史」是把双刃剑：审核闸门太严会拖慢产出，太松则形同虚设——
审核标准本身的质量决定整套系统成败。
- 项目相对年轻，长期维护与社区规模均待观察。
建议 / 观察
- 最值得借鉴的是「3 章窗口」这个折中：既不像大纲那样把故事锁死，
也不让角色无限发散——保留意外性，同时控制长篇方向。这条正好回应
《少年问天》改写里「角色自主 vs 设定自洽」的老矛盾。
- 「冻结全书导航 + 整弧条件预演」：在动笔前把全书结构锚死，
再逐章渲染——与 012 号 webnovel-writer 的「合同链」是同一思路的两条实现路径。
- 本地优先 + 断点恢复：对长篇这种「一写几个月」的工程，恢复能力是刚需，不是锦上添花。
四、评分
| 维度 | 评分 | 说明 |
|---|---|---|
| 传播热度 | ⭐ 5/10 | 星标待核实，未观察到爆发式传播 |
| 工程完成度 | ⭐ 7/10 | Apache-2.0、有 CI 与中英双语文档，但项目年轻 |
| 业务相关性 | ⭐ 9/10 | 直击长篇小说/网文连载的一致性与恢复痛点 |
| 收藏观察价值 | ⭐ 8/10 | 「3 章窗口」与「过审进正史」两条设计值得跟踪 |
综合均分 7.3 / 10
五、锚点清单
- 已验证：仓库定位（本地优先可恢复引擎）、Go 语言、Apache-2.0、
核心流程四步、面向场景（长篇/网文/短篇/工作室）
- 待核实：Stars / Forks 具体数值、Issue 活跃度、是否有可下载的 Release
- 未表态 / 缺失：支持哪些模型后端、单次可处理的最大篇幅、社区规模
六、给老爷的判断
设计思路值钱，工程成熟度待观察。 它的「3 章窗口自主决策」和「过审进正史」
是两条可以直接搬进 TextFlow 的规则。建议列入观察位：
先在 TextFlow 里复刻「窗口化角色决策」做小规模试跑，等 star 与 issue 数据补齐后再决定是否整体引入。