给网文、短剧和视频解说配四个创作工作台（oh-story-dsh）

用 AI 助手写长篇的人常卡在同一处：模型能写句子，但角色设定、大纲和已定稿的章节散在几次会话里，新开会话接不上；写到几十万字，哪一章什么时候改过也说不清。

oh-story-dsh 是 DeepSeek Harness 的社区插件，装上后 DSH Web 多出小说、短剧、游戏、视频解说四个创作工作台，读项目文件夹，产出稿件、分镜与成片等创作文件。

它跟常见「AI 写作软件」的分野在内容落在哪。所有创作内容都是 workspace 里的真实文件，工作台只把这些文件投影成界面，不写并行数据库。改哪份文件就是改哪一层决定，人工没保存的内容不会被并发的 Agent 写入覆盖。

它不做什么

它是 DeepSeek Harness 的社区插件，与 DeepSeek 没有隶属关系。Agent、会话、模型、权限审批和 Chat 全部是 DSH 原生的，插件不带第二套 Agent 运行时，也没有自己的项目数据库。

它不附带模型。开始创作前要在 DSH 的「设置 → 模型」里添加 Provider 并填入 API Key，或在启动前设好环境变量 DEEPSEEK_API_KEY。只想查看已有作品，首次引导里可以选「稍后配置」。

短剧的图、视频、配音和音乐不由插件生成，由短剧「生产」交给 short-drama-produce Skill，再去调外部供应商的 API。插件不替你付这笔钱，Key 也不存在插件里，只放在宿主机环境变量，插件只报告有没有配。

环境上有硬门槛。Node.js 需要 24 以上；视频工作台还要宿主机装 Python 3.10+ 与 ffmpeg/ffprobe。插件与 DSH 的版本要对齐，默认线接受 >=0.2.0-rc.2 <0.2.1-0，alpha 试用线是 >=0.2.1-alpha.1 <0.2.2-0，两条线不能混用；版本不匹配时 DSH 会在安装与加载阶段直接拦下并给出提示。

用之前先准备好什么

• Node.js 24+，以及一个与插件版本匹配的 DSH。
• 一个存作品的目录。首次启动时 DSH 会在「文稿」目录下自动建默认工作区 deepseek-harness/default-workspace，正式写稿建议另建目录后用「添加工作区」选进来。
• 模型侧：DSH 设置里配好的 Provider，或环境变量 DEEPSEEK_API_KEY。
• 短剧生产按需配：OPENAI_API_KEY（图片）、ARK_API_KEY 与 SEEDANCE_MODEL（Seedance 视频）、MINIMAX_API_KEY（MiniMax 视频、语音、音乐）。只配用得到的那几个即可，没有视频 Key 仍能写分镜、生成关键帧图片。
• 视频工作台：Python 3.10+、ffmpeg/ffprobe，以及 MIMO_API_KEY；用 Fish Audio 的 TTS 还要 FISH_API_KEY。
• 素材本身要有权处理。仓库给的示例提示词写的是「自有或已获授权小说」，视频解说也是拿原片当输入。

主要功能

• 四个工作台随项目出现。目录里已有创作项目时显示小说、短剧、游戏、视频四个标签；空目录保留 DSH 原生 Chat，输入 /story、/short-drama、/novel-to-game quick 或 /video-recap 开始，Agent 写出第一个创作文件后工作台自动出现。工作台只在当前 workspace 真的有创作项目时才接管布局，随时可收起，收起后回到 DSH 原生形态，选择按 workspace 记住。
• 小说工作台。三栏布局：文件树、编辑器、Chat。Agent 写文件时编辑器跟着走，点 Chat 里的文件名就能在编辑器打开。上游是 Oh Story 0.8.5，13 个 Skills 与 7 个 Roles，入口 /story、/story-long-write、/story-review，覆盖长篇、短篇、选题、扫榜、拆文、导入、审稿、去 AI 味与封面。
• 短剧工作台。每集最多五份 Markdown：剧本.md、视觉设定.md、分镜.md、图片提示词.md、视频提示词.md。「生产」视图把它们投影成镜头板、素材板、任务/版本、成片顺序和可平移缩放的无限关系画布，并就地指出重复 ID、悬空引用与格式错误。生图、生视频、配音、生音乐的任务先预览、你确认后才调供应商 API。上游是 Drama Skills 0.8.1 的 11 个 Skills，入口 /short-drama、/short-drama-write、/short-drama-storyboard、/short-drama-edit。
• 游戏工作台。左侧实时试玩、右侧 Chat。/novel-to-game quick 把小说改成可玩 ADV，产物写进 game-adaptations/<project>/，build/app/index.html 就绪后自动进入项目列表，可刷新、全屏、切换项目。游戏跑在独立 origin 与 iframe sandbox 里，随包带一个《金瓶梅》ADV 可玩示例。另有 /game-build 与 /game-qa。
• 视频解说工作台。左侧预览、右侧 Chat。项目放在 video-recaps/<project>/：原片在 sources/，工作产物在 work/，交付在 outputs/。可在原片、剪后片、成片之间切换，查看阶段提示、运行清单与质检产物，视频经 HTTP Range 流式预览。入口 /video-recap、/video-script、/video-reference。
• 作者记忆与写作习惯。v0.1.15 让写正文时能带上的作者习惯大约多一倍，没带上的会在章末汇报里用原话点名。这一版只换了随包的 Oh Story（0.8.4 到 0.8.5），插件代码和 DSH 版本线都没变，重装插件、重启 DSH、新开会话即生效，作者记忆不用迁移。
• 三条共同规矩。文件就是创作事实，工作台只投影文件；花钱的事先确认，任何调供应商 API 的任务都先在界面上看到准确内容再执行；不占别的场景，收起后不影响 DSH 原生用法。

安装与最短示例

需要 Node.js 24+。安装命令会临时提供 pnpm，只装了 Node.js 的机器也能执行：

npx -y --package [email protected] --package @deepseek-ai/[email protected] dsh plugin --profile web add @oh-story/[email protected] &&
npx -y @deepseek-ai/[email protected] web

保持终端运行，浏览器默认自动打开；没自动打开就复制终端打印的完整 http://127.0.0.1:3080/?token=... 链接访问，首次认证需要链接里的 token。关掉终端服务就停。安装与启动要用同一个 dsh 版本。

也可以用 GitHub Release 里的预构建包，命令结构与上面一致，把包名换成 tgz 地址：

npx -y --package [email protected] --package @deepseek-ai/[email protected] dsh plugin --profile web add https://github.com/zenstory-ai/oh-story-dsh/releases/download/v0.1.15/oh-story-dsh-0.1.15.tgz &&
npx -y @deepseek-ai/[email protected] web

起来以后点左侧 Workspaces 旁的「添加工作区」，选中存作品的文件夹，再在「选择工作区」里选它。创作文件写进当前会话所属的工作区。

关键参数

模型与媒体的凭据全部走宿主机环境变量。短剧生产用到的那组，写法在 README 里是这样的：

export OPENAI_API_KEY=...            # 图片
export ARK_API_KEY=... SEEDANCE_MODEL=...   # 视频，模型/Endpoint ID 以账号开通的为准
npx -y @deepseek-ai/[email protected] web

插件启动时会把这五个内置 adapter 登记到一份不含凭据的配置文件，默认在系统临时目录下仅当前用户可读写的 oh-story-dsh-<uid>/ 里，「生成环境」条会显示完整路径。自己写 adapter 或改超时，就把文件路径写进 OH_STORY_DRAMA_ADAPTER_CONFIG。声音参考要额外显式配置：自动生成的通用 profile 不声明 reference_audio，只有确认所选模型支持后，才在项目外的自定义 adapter 配置里为该 profile 声明 reference_roles，并用同一个环境变量指过去。未声明时会在付费提交前拒绝，不会静默丢掉声音。

想让原版 web 保持干净，可以把插件装进独立 profile：

npx -y --package [email protected] --package @deepseek-ai/[email protected] dsh plugin --profile story add @oh-story/[email protected]

新 profile 默认没有界面，要编辑 ~/.dsh/profiles/story/package.json 的 dsh.profile.bundles：

"bundles": [
  "@deepseek-ai/dsh-base",
  "@deepseek-ai/dsh-web-app",
  "@oh-story/dsh"
]

@deepseek-ai/dsh-web-app 是 DSH 自带的 Web 界面包，要在创作插件之前加载。之后两个 profile 可以用不同端口同时运行：

npx -y @deepseek-ai/[email protected] web                          # 原版 DSH
npx -y @deepseek-ai/[email protected] --profile story --port 3081  # 创作工作台

结果在哪里看

小说工作台里，结果就在 workspace 的文件树和编辑器里，Chat 里的文件名点开即跳。短剧的成片由 /short-drama-edit 按《剪辑单.md》渲染到 剧集/<EP>/制作成果/成片/。游戏的产物落在 game-adaptations/<project>/，可玩页面是 build/app/index.html。视频解说的交付物在 video-recaps/<project>/outputs/。模型用量和耗时由 DSH 自己在右侧 Chat 里报，不是插件给的。

实际使用中的坑

作者记忆的读取上限偏小，而且早期不能自行配置（Issue 已解决）。写长篇的人会明显感到前面攒下的写作习惯带不全，v0.1.15 把写正文时能带上的习惯数量提升到了大约两倍，没带上的会在章末汇报里点名。

固定侧边栏早期无法关闭，影响把 DSH 用在其他场景时的心情（Issue 已解决）。插件后来把接管布局限制在真的有创作项目的 workspace，并允许随时收起。

右侧聊天栏里 AI 的答复会被下方聊天框遮住，任务区域也有过内容被遮挡的情况（两个 Issue 均已解决）。

token 消耗到底多少，有用户直接在 Issue 里问，目前没有答复，状态是待解决。上游 DSH 的 npm alpha 已经指向 0.2.1-alpha.2，而本仓库声明并测试的版本停在 0.2.0-rc.2 与 0.2.1-alpha.1，这条版本跟进也还是待解决状态。

横向对照

同类项目里，同一个团队的 oh-story-claudecode 是把同一批网文 Skills 装进命令行 Agent 的做法，EthanYoQ/AI-Novel-Writer 走的是独立桌面软件的路子。

如果你的主力 Agent 是 Claude Code 或 Codex，oh-story-claudecode 这类纯 skills 形式更省事，不必为了写小说再装一套 DSH。oh-story-dsh 的价值绑在 DSH 的 Web 界面和四个工作台的联动上，代价就是版本耦合：插件要和 DSH 版本线对齐，上游发 alpha 时你只能等适配，Issue 里那条版本跟进至今还挂着待解决。灵活度上它不如不绑定宿主的项目。

合规与授权边界

这个插件处理的是别人的创作素材，边界落在素材本身。仓库示例提示词自己写的是「自有或已获授权小说」，视频解说以原片作为输入，短剧成片最终是要发布的内容。拿没有授权的网文、影视原片喂进去，做出来的东西再好看也不能发；生图、生视频、配音调用的是第三方供应商的接口，各自的使用条款和版权归属由那家说了算，插件只负责在提交前把内容摊给你确认。发布到各平台还要再过一遍平台自己的内容审核规则。

适合谁

已经在用 DeepSeek Harness、作品格式以 Markdown 文件为主、并且愿意自己配齐模型与媒体供应商 Key 的作者，可以直接把它当主力环境用。同时要写小说、短剧、游戏改编和视频解说中两样以上的人收益最大，四个工作台共用一套会话、模型与凭据，不用来回切工具。

只想在浏览器里点几下就出稿的人不适合。它不替你准备 Node.js、不替 you 买 API 额度、不替你把 ffmpeg 装好，版本线还要自己盯。用 Claude Code 或 Codex 写小说的，去看那个团队的 oh-story-claudecode 更直接。项目地址在 https://github.com/zenstory-ai/oh-story-dsh，MIT 许可证，主要语言是 Python（61.3%），另有 JavaScript 19.3% 与 TypeScript 17.1%，当前 497 个 Star、83 个 Fork、6 个开放 Issue，最近一次提交在 2026-10-10，最新版本 v0.1.15。

焚评：这个项目的量化评分

本项目的选题来自 焚.com（一个按公开公式给 GitHub 项目打分的站）。焚评当前总分 9.1 分（满分 10）。下表是各维度的得分：

评分口径、权重与计算方式见焚.com 的评分方法页；数据随 GitHub 指标刷新，具体数值以焚.com 当前页面为准。本文正文为诀.com 独立撰写，评分数据由焚.com 授权引用。