前言¶

用 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