实用指南
用 DeepSeek 写小说:选对工作区,从已有稿件接着写
源码核对日期 2026-09-13
按作品需要保存在哪里来选。只想临时脑暴、点评大纲或改一段文字,并准备自己复制回稿件,用普通 DeepSeek 模型聊天即可;希望围绕本地写作目录持续创作,由会话、Skills 和文件/编辑器/Chat 工作台共同管理项目,可选 DeepSeek Harness(DSH)加社区插件 Oh Story DSH;不想在本地运行 DSH,而想用账户化的浏览器项目,则选独立的 ZenStory 托管服务 app.zenstory.ai。四者不是同一层:DeepSeek 是模型/Provider 选择,DSH 是 Agent 宿主,@oh-story/dsh 是装进该宿主的社区插件,ZenStory 托管版是另一套应用。安装插件不会把它装进普通 DeepSeek 聊天,本指南也不声称 ZenStory 托管版原生使用 DeepSeek。 若要先理解聊天、Skills 与 Agents 的通用差异,可阅读写作者的 AI Agent Skills 指南;若要逐项比较 ZenStory AI 的三种写作环境,可查看工作流对比。 已有稿件时,先交代当前确认版、最后完整章与尚未完成的尾稿,不要只说“继续写”。下方的档案悬疑示例把这些材料转成有代价的下一场戏选择,再决定是否导入或改文件。
开始之前
- 使用普通聊天时,只带上这次任务所需的片段和约束,并由你自己保管权威稿件;聊天回答不会自动同步到写作项目。
- 使用本地 DSH 路线时,准备 Node.js 24+,以及一个愿意交给 DSH workspace 管理的作品目录。下方固定版本安装使用 DSH
0.1.5-rc.1与社区插件@oh-story/dsh@0.1.9。 - 让 DSH 生成文本前先配置模型/Provider。源码说明可以在“设置 → 模型”中添加 Provider 和 API Key,或在启动前设置
DEEPSEEK_API_KEY。模型、凭据、权限和会话由 DSH 管理,插件不读取这些凭据。 - ZenStory 托管版位于
https://app.zenstory.ai,属于独立的账户化流程。不要预期本地 DSH workspace、插件安装或普通 DeepSeek 聊天历史会自动出现在其中。 - 已有稿件时先留独立备份,点名原稿文件、未完成章节,以及相关设定或旧续写设想。没有采纳的细纲不是故事里已经发生的事;说明本轮只讨论、可以写规划文件,还是允许修改正文。
操作步骤
- 按任务选择最小够用的环境 只问一个问题——例如给出三个梗概、点评简介或改写你提供的一场戏——普通聊天准备最少。已有八万字稿件,或需要让设定、逐章细纲、正文与连续性状态跨会话保留的连载,可选 DSH 加插件。希望稿件位于账户化网页项目、又不想在本地运行 DSH,则用 ZenStory 托管版。若本来就在其他受支持的 coding-agent 宿主里工作,请按单独的 Agent Skills 指南选择,不要假设 DSH 插件也能直接装进去。
- 在 DSH Web 中安装社区插件 运行示例中的固定版本命令。命令临时提供 pnpm,因为 DSH 的
plugin add会用到它;随后把@oh-story/dsh装入webprofile,并启动 DSH Web。终端需要保持运行。浏览器没有自动打开时,使用 DSH 在终端打印的完整本地地址,但不要分享其中用于首次认证的 token。 - 在宿主层配置模型 在 DSH 的“设置 → 模型”中添加 Provider 和模型;如果准备使用对应的 DeepSeek Provider,也可以在启动 DSH 前提供
DEEPSEEK_API_KEY。这是 DSH 的配置,不是 Oh Story 插件的配置。查看已有作品可以稍后再配模型,但生成新文本需要可用的模型配置。 - 先打开作品目录,再发写作请求 点击 Workspaces 旁的加号,添加真正存放小说的目录,选中 workspace 并打开会话。空目录起初仍显示 DSH 原生 Chat;Agent 写出可识别的小说文件后,小说工作台才会出现。这个标签只是同一 DSH workspace 的视图,不是第二个 Agent,也不是 ZenStory 账户。
- 从零开书:给出有边界的请求 输入
/story-long-write 帮我开书,并写清题材、读者承诺、主角、核心压力、预计篇幅、视角、语气、明确禁区和本轮停靠点。内置流程默认先建立项目、核心设定、卷纲与首批十章细纲,然后停在正文前。先审方向,不要一轮要求生成整本小说。 - 写新章:点名章节与停笔点 确认设定和细纲后,再明确输入
/story-long-write 写第1章。检查正文/中的实际章节、大纲/中对应细纲及相关设定,不要只看 Chat 摘要。修改意见要落到可执行约束:哪个事实、人物声音、信息揭示边界或章尾节拍需要变化,然后点名要求修改该章。 - 已有稿件:先谈下一场戏,不急着导入 在同一 workspace 中点名这次需要的原稿和设定,先要求列出已确认事实、视角人物所知、未解假设,再给两个续写方向;未完尾稿单独标注。自然语言的 Chat-only 请求可以明确禁止创建或移动文件、生成正文及调用媒体服务;这轮讨论不会初始化小说工程或让新工作台自动出现。示例里,“认出一种笔迹习惯”提出了问题,不等于已经证明是谁写的。
- 区分只讨论、完整导入与已有工程 只想讨论一场戏,就留在 Chat。松散原稿需要变成可续写工程时,随包
/story-import支持文本文件、目录或粘贴文本,先确认范围和尾章是否完整,再经过完整拆解管道迁移;它不是“轻量载入这段文字”。尾章未完时,由作者选择基于残章续写,还是先补完再导入。如果书目已有当前格式的追踪/_tracking-state.json,先确认当前书目,不重复完整导入。这一路线的专业角色由 DSH 随包提供,不要为了导入而部署其他宿主的 Agent 目录。 - 先选行动代价,再明确写作范围 比较续写方向时,看主角要冒什么风险、放弃什么,而不只是哪个更刺激。批准新细纲与允许写正文是两件事;确实尚不存在的新章可用
/story-long-write 写第N章,已有残稿则要明确提出修改/补完、保护开头,不把目标当空白文件。随包流程的指定章默认一章,日更续写却可能默认两到三章,因此要点名章节与停笔点。以后回到同一 workspace 继续,稿件文件与 DSH profile 配置分别备份。
示例
示例
建议输入——以下为原创示例,不是实测模型回答:
终端——安装固定版本插件并启动 DSH Web: npx -y --package pnpm@11.7.0 --package @deepseek-ai/dsh@0.1.5-rc.1 dsh plugin --profile web add @oh-story/dsh@0.1.9 && npx -y @deepseek-ai/dsh@0.1.5-rc.1 web
在你选定的空 workspace 对应 DSH 会话中输入: /story-long-write 帮我开书 写一部约 24 万字、面向成年读者的近未来悬疑连载。 核心梗:市档案员发现,每晚 02:17 都有一名普通居民从全部公共记录中消失,但她手写的修订次日又会恢复。 读者承诺:程序化调查,以及“哪个版本的人值得留下”带来的选择代价。 主角:严谨、回避冲突,并因失踪的手足与事件有私人关联。 使用第三人称限知和克制文风;第一卷不得全知解释系统真相。 本轮只建立项目设定、卷纲和首批十章细纲,停在正文前,并列出创建的文件。
检查并确认计划后输入: /story-long-write 写第1章 严格使用已确认的本章细纲,只写第 1 章,保留信息揭示边界;在主角发现一份从未打开的档案里出现了与她有相同缺笔习惯的修订笔迹时收尾;此时不证明是谁写的。正文写入项目文件,不要继续第 2 章。
已有稿件练习——原创编辑示例,不是生成结果 这次给档案员取名“纪宁”。下文只是相关摘录,不是完整章节,也没有创建真实 workspace 文件。实际使用时换成你的真实文件名,并提供相关完整原稿,不只给这份练习。
作者提供的材料: - 原稿/第001章.md:作者已确认的完整第一章,以下摘录就是章尾。 - 原稿/第002章_未完.md:未完成的开头,不是已经写完的第二章。 - 参考/旧续写设想.md:没有采纳的提议,不是正文证据。 - 参考/本书设定.md:已确认的创作简报,包括失踪手足与限知视角。
已确认的第一章末尾: 纪宁第一次翻开417号档案。页脚那行“准予更正”里,“更”字少了最后一捺, 正是她多年改不掉的写法。
第二章未完开头: 她把调阅卡推到窗口。值班员压住卡片:“申请调原始登记,得留你的工号。” 纪宁把笔尖停在签名栏上方。 [作者写到这里停下。尚未签字、递交申请或拿到登记册。]
旧的、尚未采纳的第二章设想: “潜入保管室偷走原始登记册,确认是失踪的手足伪造了笔迹。” 这是剧情提议,不是已经成立的证据;采纳它会改变调查方式与揭示时机。
第一轮请求——自然语言 Chat 讨论,不必启动写作 Skill: 只读上述四份文件。第一章已完,第二章未完。 分开列出已确认事件、残稿提出的当前情境,以及旧规划。 纪宁实际知道什么,又只是在怀疑什么? 给出两个继续追查原始登记的方向,不确认笔迹作者。 每个方向说明她采取什么行动、遇到什么阻力、场末发生什么可见变化。 保持第三人称限知,不全知解释,不自动获准调阅,不跳过签字动作。 只在 Chat 回复,不创建、移动或修改文件,不生成正文,不调用媒体服务。
编辑对材料的阅读——不是声称 Agent 已经这样回答: - 第一章确立了:她在从未翻开的档案里认出一种笔迹习惯。 尚不能推出“就是她写的”“手足伪造”或“发生了时间穿越”。 - 残稿停在笔尖悬空;即使只看这个片段,她也还没签字。 值班员说需要工号,不等于这一摘录已证明整座档案馆的统一制度。 - 作者若保留这个开头,第二章要接住的是尚未作出的决定;章没完成前, 不能把残稿情节当成已完成章节写入追踪检查点。 - 调查不必马上查明笔迹作者也能前进:留下可追问的申请,或让另一个人 面对这个疑点;这两者都不等于已经拿到登记册。
两个新增的候选场景——虚构创作选择,不是项目已有事实: A.承担署名代价。纪宁签下自己的工号,写明要核对修订笔迹;值班员收下申请, 给的是回执编号,不是登记册。她获得了可追问的线索,也让签名把自己与调查 联系起来。章尾落在交出申请:动作已经做出,但不能暗示调阅已获批或身份已查明。 B.不签字,先求一个见证。纪宁请值班员和她一起看有疑点的那一页。 他不愿独自判断,伸手拿电话准备叫主管。停在尚未接通时:她没有取得调阅权, 想悄悄调查却必须应对另一个人的主动行动。值班员不必认得她的笔迹、知道秘密, 更不必先被写成反派,这个阻力就可以成立。
选 A,是让回避冲突的主角第一次用自己的名字承担调查;选 B,是让她保密的打算 受到当场的人际压力。它们是两种方案,不是可以悄悄拼成一段既成剧情的两个事件。
A 的候选收束——仅为编辑写的短段示意,不是完整章、已采纳的改稿或 DSH 实测输出: “申请理由?” 纪宁让笔尖落下,在签名栏写完自己的工号。 她在下面补了一行:核对修订笔迹,再把签好的卡片推过去。 值班员撕下回执。上面只有申请编号,没有调阅结果。 她折好纸条,签过工号的申请留在窗口里面。 这里回答的是“她是否署名追查”,不是“谁写了那行修订”。
准备落稿前——先区分材料状态: 如果仍是松散文件,可以继续只讨论,也可以明确选择完整导入。导入前先确认范围、 目标书目和尾稿策略;要保留开头就选“基于残章续写”。参考/下的规划笔记要与原稿 目录分开。不要把 Chat 讨论说成已经导入;已有当前格式工程则不重复导入整本书。
工程准备好之后,先只规划: /story-long-write 补纲 我选 A,保留残稿开头。本轮只规划第二章,停在正文前。 不要采纳未确认的旧第二章续写设想。我授权将本章细纲定为署名申请这一场戏。 其他章、已确认的第一章和既有追踪事实不变。 回执只说明申请已递交,不代表调阅获批;笔迹作者仍然未知。
审过细纲后,如果第二章的残稿文件已经存在: /story-long-write 修改第2章 这是未完成章节,不是要求跳到下一章,也不是覆盖一个空白新章。 先定位并备份实际文件,列出将保留的开头和本次补完边界;等我确认后再改正文。 然后只按已确认的 A 方案补完第二章,保留已有开头;在交出署名申请、拿到回执时 收尾,不获得调阅权、不确认笔迹作者。 不重写第一章,不把原残稿算成已经完成第二章,不继续第三章。 真实文件或追踪状态如果与这些描述冲突,先报告。
如果实际上根本没有第二章正文文件,才用“写第2章”的新章入口。 区分依据是真实文件,不只是上一条 Chat 消息说了什么。
预期文件
- 默认开书完成后,通常会得到
设定/下供作者阅读的题材定位与关系等文件,大纲/下的全书/卷级大纲和逐章细纲,以及追踪/下初始化的连续性状态。内置流程说明第一轮默认停在首批十章细纲之后。 - 明确请求写章后,正文按章写入
正文/(例如正文/第001章_章名.md),连续性视图也由写作流程更新。需要审的是稿件文件,而不是 Chat 中一句“已经完成”。 - DSH 小说工作台用文件树、编辑器和 Chat 呈现同一项目。ZenStory 托管版也有浏览器工作台,但它属于独立账户与应用边界;界面都叫工作台,不代表底层使用同一插件、模型或项目文件。
- 完整导入会迁移原文而不改写其内容。残章可以出现在正文文件中,但
last_chapter与当前状态快照仍截至最后完整章,尾稿处理策略写入连贯性风险。文件存在不代表该章已经完成。
验证结果与边界
- 继续前,打开完成消息中点名的文件,确认核心梗、视角、禁区、信息揭示边界与本章停笔点确实落在项目里。只看到工作台标签或一段流畅回答,不能证明项目已更新。
- 针对档案例子,看行动是否真的写出来:选 A 就要让签字与递交申请在场内发生;回执不能偷换成已经获准调阅,认出笔迹也不能偷换成证明作者。结合正文与实际项目状态核对第二章是否已经补完,不因存在“第二章”文件就当作完成。
- 之后换会话时重新打开同一 workspace,先要求诊断项目状态。核对最后完成章节与下一章细纲,再明确只生成你要的范围。
- 把模型输出当作草稿:连续性、可能复用或缺乏依据的内容、事实与发表权利都需要作者自行复核。本指南比较工作流,不代表实测写作质量,也不保证直接可发表。