前言¶

用 DeepSeek Harness（DSH）写长篇小说时，常见路径是「细纲 → 正文」。细纲往往只交代结果，例如「林砚在拍卖会拍下玉佩」；加价过程、在场人物、旧敌反应、玉佩来历等，会在生成正文时由模型自行补全。若你使用 novel-forge 一类工具，门禁通常是整章细纲的批/不批——粒度是一章，批准时方案已基本定型，小细节难以再改。

下面介绍社区插件 dsh-novel-beat（维护者 DrizzleGig，分类：工作流）。它把拦截粒度下沉到决策点：凡会改变故事状态的节点，在生成正文之前逐条问询作者，拍板结果落盘，并可编译成细纲片段供后续写作使用。插件简介为：Novel fork decision gate for DSH · 小说剧情决策闸。

这是什么¶

dsh-novel-beat 是 DSH 上的工作流插件，面向「用智能体写小说、又不想在关键分叉上完全交给模型」的场景。它不替代整本书的大纲系统；而是在「细纲与正文之间」加一道决策闸。

判定规则在 README 中写得很明确，也是唯一标准：

会改变故事状态的，都要问；只描述世界的，不用问。

能落进「账本」的状态变更视为决策点，例如：动作（动手 / 忍住）、知情、关系、得失、角色状态、承诺、时序、剧情分叉等。风、光、温度、比喻、氛围类描写不进清单，由模型自行处理。

五个工具¶

插件通过五个工具完成列点、拍板、门禁与编译，名称与作用如下。

README 说明：不依赖任何其他插件。五个工具只读写插件自有目录；未安装 novel-forge 时也可当写作提纲走完流程；若已安装 novel-forge，可将 beat_compile 结果填入 novel_outline save_chapter。

典型工作流¶

经过上面的工具划分，一章内推荐顺序如下。

beat_plan（列决策点）
   ↓  逐个 ask_user_question 问作者
beat_decide × N
   ↓
beat_gate  → PASS
   ↓
beat_compile → 细纲片段
   ↓
novel_outline save_chapter + approve（若使用 novel-forge）
   ↓
novel_write_chapter

先做 beat_plan 拉出本章决策点，再对每个点通过问询与 beat_decide 记录选择；beat_gate 通过后再 beat_compile。与 novel-forge 衔接时，把编译结果写入章节细纲并走原有批准与正文生成步骤。

数据落盘¶

每章一个 JSON 文件，路径形如：

<工作区>/.dsh-novel-beat/<书名>/ch012.json

文件中保存该章全部决策点的选项、影响与发展、作者选择、拍板时间等信息，便于回溯与续写。

安装与启用¶

安装方式以仓库 README 为准（示例为 Windows 本地 bundle 路径；改代码后需先卸再装才会重载）：

# 改完代码要「先卸再装」才会重载
plugin_manager remove_bundle  target=dsh-novel-beat
plugin_manager install_bundle target=D:\插件\plugins\novel-beat

请将 install_bundle 的 target 改为你本机插件目录的实际路径。package.json 中当前版本为 0.5.0，许可证 MIT。DSH 社区插件目录位于独立站点 SkillHub 上的 dsh-novel-beat 页，与 DeepSeek / 幻方无官方从属关系；安装前请自行查看源码与许可证。插件以当前 DSH 进程权限运行，仅安装你信任的来源。

适用场景与注意¶

适合：长篇连载、分支剧情多、希望在「信息揭露程度、关系变化、得失」等节点上由人定稿再继续生成的作者；也可从一句创意起步，边推演边拦截，决策点数量随章节密度变化、README 未设硬性上下限。

注意：决策点清单的质量依赖 beat_plan 与判定规则是否被遵守；纯氛围描写不应占用拍板流程。与 novel-forge 的衔接是可选增强，不是硬性前提。

结尾¶

dsh-novel-beat 把 novel-forge 式「整章批准」之前的自由发挥，拆成可审计的决策点问询与门禁，再编译成可执行的细纲约束。若你在 DSH 里写小说并关心分叉归属，可从列点与拍板流程试起。

• 社区目录：https://www.skillhub.cn/plugins/DrizzleGig/dsh-novel-beat
• 源码与说明：https://github.com/DrizzleGig/dsh-novel-beat