novel_draft

实时聊天写作的草稿镜像：AI 一段段地写，每写完一段就把这一段正文交给本工具，由程序追加进独立目录 .novel-writer/drafts/<书>/ 并自行累计字数；只追加，AI 不读、不改、不清；正式章节文件在用户确认之前一个字节都不动。它不生成正文，也不判断「该不该问人」——问不问、什么时候问，由程序按字数阈值决定，工具只把结论放在 nextAction 里（continue / ask_user）。

为什么必须另起一个目录

这是整个功能的设计核心，也是唯一一处「放错位置就会静默把整本书的数字搞坏」的地方。

插件所有章节扫描都按 <书库根>/novels/<书>/ 下的文件枚举（core.scanChapters），并把每个 .md 当成一章参与统计：章节数、总字数、六维基线、语义索引、风格自检、关键词、连贯性审计……全部从这份枚举派生。只要把「正在写的半成品」写进那个目录，这些数字就会被草稿污染——同一章出现两份、章号撞号、字数虚增、基线漂移、语义索引里混入还没定稿的段落。

更麻烦的是它不会报错：界面上只表现为「数字怪怪的」「同一章好像有两份」「基线忽然变了」，用户很难据此自查，模型也无从判断。

因此草稿镜像固定落在数据目录里，与正文目录同级但不相交：

工具层有一道硬断言：每次计算镜像路径后都跑一次 isInsideBookDir(root, book, target)，一旦路径落进正文目录就直接拒绝执行：

isInsideBookDir 比较的是 resolve() 之后的绝对路径，并按目录边界判定（b === a 或 b 以 a + 路径分隔符 开头），因此 …/novels/雨夜灯甲/x 不会被误判成 …/novels/雨夜灯 内部。解析失败（拿不到可用绝对路径）时返回 false，即「不敢断言在内部」——真正拦人的是路径本身由 draftBookDir 拼出，永远落在 .novel-writer/drafts/ 下。

参数

契约口径：required: ["action", "book", "text"]，additionalProperties: false；参数表里没有 read / clear / index——「只追加」不是文档承诺，而是接口面上不存在修改某一段的能力（test/chat-writing-test.mjs 用断言钉住这一条）。

输出结构

契约必返字段（output.schema.required，共 13 个）：

ask_user 时 question 的固定文案（程序拼，不由模型改写）：

渲染层（output.render）给人看的那段文本骨架：

<type>novel-draft</type>
<content>
<message>

镜像文件（给人看的，你不要读）：<draftFile>
第 N 段已写入（C 字）｜待确认 P/T 字｜本章已提问 K 次

nextAction = continue → 程序判定：继续写下一段（还差 R 字到阈值）——不要自己去问用户。
nextAction = ask_user → 程序判定：现在停下来问用户（阈值已到）。
                         【问题】<question>
                         【本批正文】<combinedText>
</content>

提问节奏：阈值与账本

「什么时候停下来问用户」是本版刻意从模型手里拿走的判断：交给模型决定，就等于让「短段该不该合并着问」变成临场发挥，而这正是要消除的东西。

阈值：默认 400，用户可填 100~5000

阈值不是每章一份：它存在状态文件 state.json 的顶层 chatThreshold（面板「实时聊天写作 → 提问节奏」那一行，或 novel_sentence_config 的 chatThreshold 参数），全书生效；读取侧取值口径是 state.chatThreshold ?? 400。

判定：达到或超过即提问

阈值只决定「何时问」，不影响落盘：每一段都是立刻 append，哪怕只有 5 个字。所以「短段自动合并」合的是提问，不是写入。

账本：该章一份 __state.json

计数不靠读回镜像正文，而是程序自己的账本 <章键>__state.json，与镜像同目录、同章键：

{
  "segments": 2,
  "pendingChars": 0,
  "totalChars": 425,
  "prompts": 1,
  "pending": [],
  "updatedAt": "2026-11-10T13:39:39.069Z"
}

账本丢了会怎样：读不到或 JSON 损坏时，按镜像里已有的段头重建——只数 ## 第N段 的行数（/^## 第\s*\d+\s*段/gm），不把正文读进上下文，并把 pendingChars / totalChars / prompts 归零。结果是段号能续上（不会从第 1 段重新覆盖），但「本轮待确认字数」从头累计。账本写入走 atomicWriteJson（临时文件 + 原子替换）。

章键归一与同章认领

镜像文件名与账本文件名共用同一个章键，保证两者永远配对。章键由 draftKeyFor 产出：

归一之外还有第二层兼容：resolveDraftTarget 在规范文件不存在时，会扫一遍该书的 __draft.md，认领章号相同的第一份既有文件（按文件名排序）作为本章镜像与账本：

这一层是为了兼容早期按字面量命名的镜像（3__draft.md）：不认领的话，升级后同一章会再多出一个 第03章__draft.md，历史内容看起来像丢了。

镜像文件长什么样

正文结构只有逐段块，没有标题头；每段以 ## 第N段 开头，行尾带写入时间戳：

## 第1段 · 2026-11-10 13:39:39

第一小段。

## 第2段 · 2026-11-10 13:39:39

……（这一段正文）

## 定稿落盘 · 第2章 · 2026-11-10 13:39:39

> 本章已写入正式章节：第02章 有篇.md（16 字）。本文件是草稿镜像，只追加、只给人看。