前言¶
在 DeepSeek Harness（DSH）裏用模型寫同人，常見做法是直接丟原文和要求，等模型吐出一篇新文。問題在於：設定衝突、人物 OOC、伏筆失收往往要改完才發現，成本高且難追溯「當時模型忽略了什麼」。二創工坊（dsh-fanwork）把流程拆成可審查的步驟：先對原文做結構抽取與邏輯風險體檢，每條風險帶原文引證和修復選項；你在界面上逐條裁決後，再並行生成多篇立意不同的候選稿，每稿由獨立審稿提示詞給出六維評分與問題清單，定稿時可導出正文與審計附錄。插件不內置模型、不帶額度，需自備 OpenAI 兼容接口與 API Key。
這是什麼¶
dsh-fanwork 是維護者 gothepharnayadlsos-cyber 發佈的 DeepSeek Harness 插件，在 SkillHub 目錄中歸類爲工作流。它將「讓模型寫二創」變成可裁決的流水線：結構 digest → 邏輯風險報告 → 人工決策 → 並行多稿 → 逐稿審覈 → 導出。社區插件目錄爲獨立站點，與 DeepSeek / 幻方無官方從屬關係。
核心功能¶
邏輯風險體檢¶
體檢階段使用 4 族 17 類風險分類（完整定義見倉庫 lib/prompts.js），每條風險需有原文引證，無引證不成立。節選示例：
| 族 | 編號 | 類別 | 判定問題 |
|---|---|---|---|
| 衝突 | C1 | 設定衝突 | 同一規則或能力是否被兩次不同地陳述 |
| 衝突 | C2 | 時間衝突 | 事件先後、年齡、季節能否同時成立 |
| 缺口 | G1 | 動機缺口 | 關鍵行爲是否有與其分量匹配的鋪墊 |
| 結構 | S1 | 伏筆失收 | 已埋伏筆是否被遺忘或突兀回收 |
| 體驗 | E1 | OOC | 行爲是否偏離人物既定性格與關係 |
| 體驗 | E4 | 合規風險 | 是否觸及版權、敏感內容或平臺規則 |
決策臺賬與多稿生成¶
用戶對每條風險選擇修復方案，或在「更多要求」中手寫約束；選擇寫入決策臺賬，並作爲約束注入生成。生成階段默認並行 2–3 稿，立意可區分（如正面推進、側面切片、反向假設）。每篇候選稿經六維審覈：原作一致性、人物保真、內部邏輯、需求覆蓋、合規、文筆。
長文與採樣¶
- 原文 ≤ 1.2 萬字：一次調用抽取骨架（人物 / 設定 / 時間線 / 事件 / 伏筆）。
- 原文 > 1.2 萬字：按 1.2 萬字切塊，併發解析後合併去重（併發數可在配置中調整）。
- 體檢階段對超過 1 萬字的原文按段落均勻採樣（保留原句，引證仍可定位），界面會標註「採樣」。
README 中給出的實測參考（4.2 萬字原文、2 篇候選、800 字目標篇幅）：骨架 4 塊併發約 70 s，體檢約 70–110 s，整段約 2.5–3 分鐘；2 萬字以內體驗最好。
隱私與數據落盤¶
API Key 僅保存在本機 <dataDir>/settings.json（默認 ~/.dsh/fanwork，權限 0600），頁面只顯示掩碼；項目數據在 ~/.dsh/fanwork/projects/<id>/，不做遙測。導入原文支持拖入 .txt / .md、選擇文件，或填寫本地路徑（支持 ~，≤ 4 MB）由服務端讀取，文件不進瀏覽器、不上傳。
安裝與啓用¶
插件要求 DSH 版本 >=0.2.0-rc.2 || >=0.2.1-rc.2（見 package.json 的 engines.dsh）。安裝後 /fanwork 路由自動掛載，無需改配置文件。
方式 A：插件市場（推薦）¶
在 DeepSeek Harness 中打開 設置 → 插件，搜索 dsh-fanwork，安裝並按提示重啓。
方式 B：命令行¶
dsh plugin --profile <你的 profile> add dsh-fanwork
裝完重啓 DSH。
卸載¶
dsh plugin --profile <profile> remove dsh-fanwork
本地 link 安裝時使用倉庫腳本加 --uninstall（見 README「方式 C」）。
典型用法¶
準備： OpenAI 兼容的接口地址、模型名、你自己的 API Key。未配置時生成類接口返回 403 NOT_CONFIGURED。
- 打開
http://127.0.0.1:<DSH 端口>/fanwork，或在 DSH 輸入框執行/fanwork獲取當前地址（端口隨啓動可能變化；插件也會寫入<dataDir>/last-url.txt）。 - 第 0 步 · 配置 API：填寫接口地址（如
https://api.deepseek.com）、模型名（如deepseek-chat）、Key，可先「測試連接」，再「保存並開始」。 - 導入原文並填寫創作要求（方向、篇幅、視角、風格、禁忌、補充要求），點「開始體檢」。
- 逐條裁決風險：選修複方案或展開「更多要求」。
- 點「應用裁決並生成」，得到多篇候選及六維審覈報告；不滿意可用「按新要求換一批」，滿意則「採用此稿」。
- 導出：項目目錄下的
export.md（正文 + 風險報告附錄 + 決策臺賬）。
工作流概覽：
原文 + 創作要求 → 骨架抽取 → 風險體檢 → 用戶裁決 → 多稿生成 → 六維審覈 → 定稿導出
↑ 不滿意時「更多要求」可回到多稿生成
配置¶
在插件行或 profile 的 cordis.patch.yml（id: fanwork）中修改 config:：
| 字段 | 默認值 | 含義 |
|---|---|---|
candidates |
3 |
每次生成幾稿（1–4） |
concurrency |
4 |
長文分塊解析併發（1–6） |
reasoningEffort |
low |
推理強度；長文本建議保持 low，否則推理易佔滿 token 預算 |
callTimeoutMs |
600000 |
單次模型調用超時（毫秒） |
dataDir |
~/.dsh/fanwork |
項目數據目錄 |
接口地址、模型名、Key 不在上述 YAML 中，僅通過頁面寫入 settings.json。
適用場景與注意¶
適合： 需要在二創前系統排查原文邏輯與設定風險、希望保留「爲何這樣改」的決策記錄、並對比多篇不同立意稿件的同人作者或工作流愛好者。
注意：
- 插件以當前 DSH 進程的權限運行；安裝前應自行查看 GitHub 源碼 與 MIT 許可證，確認可接受其行爲（含讀本地文件、調用你配置的遠程 API）。
- 二創請自行確認原文使用權；導出文件已附原作信息與二創聲明。
- 體檢長時間無響應時，可查看
<dataDir>/fanwork.log（JSON 行日誌）；常見原因是reasoningEffort過高。
結尾¶
二創工坊把「寫二創」從單次 prompt 變成可審查、可裁決、可導出的流水線，適合在意設定一致性與改寫可控性的場景。插件目錄頁：SkillHub · dsh-fanwork；源碼與完整 HTTP 接口說明：github.com/gothepharnayadlsos-cyber/dsh-fanwork。
