总结本文记录当前的整体架构与流程并附一次实际写作的产物链路。把「收集、设计、精修、审校」交给需人工确认的智能体把「写作」做成一条确定性的执行流水线核心思路是知识库先行、阶段分离、人在环中。结论当前系统输出的单元剧文章目标平台Lofter类型动画同人文远没达到能够发布平台接受检验的水平。AI写小说是否能够做到AI为主人工为辅还是只能做到人工为主AI为辅目前博主正探索中。文章目录一、前言AI 写长篇到底难在哪二、项目速览三、总体架构知识库-设计-写作-审核四、五段式流程五、几个关键设计六、实战案例七、资源与结语7.1 资源7.2 结论7.3 教训附录AI小说示例单场景质量很低不建议欣赏懒得写间奏一、前言AI 写长篇到底难在哪让大模型写一段几百字的场景并不难难的是把它写「长」还写「住」。实践中遇到的问题主要在四处问题表现原因分析解决思路人设崩角色像换了个人说话方式、决策逻辑前后不一致缺少稳定的人设约束模型在不同段落中“重写”角色统一角色卡、固定说话习惯、动作逻辑和情绪基线文风漂开头是一种语气中段像换了个模型生成过程没有统一文风召回和约束长文本容易漂移通过 RAG 检索风格示范分段锁定语气与句法场景不连贯上一幕的动作、时间、道具下一幕对不上缺少连续性上下文和节拍约束场景切换时丢失状态用 beat 结构、前情梗概和场景状态跟踪维护连续性二、项目速览一套基于Qdrant 向量检索 LLM的小说写作系统技术栈为 Python Qdrant LangChain Git多仓配合 opencode 的 subagent 编排。一次创作拆成五段收集 → 设计 → 写作 → 精修 → 审校其中「收集」是写作前的知识库构建「写作」是不调用分析/设计能力的纯执行段其余三段以「subagent 人工确认」的形式进行。三、总体架构知识库-设计-写作-审核系统的第一层不是写作而是写作前的知识库预处理。四个独立子仓各管一段构成一条从「抓原文」到「产资产」的流程┌──────────────────────────────────────────────┐ │ ① 预处理 / 知识库层写作前动作 · 独立子仓 │ └──────────────────────────────────────────────┘ ┌───────────────┐ ┌────────────────────────┐ │ lofter_fetch │────────►│ 短篇原文Markdown │ │ 抓取同人短篇 │ └───────────┬────────────┘ └───────────────┘ │ ┌──────────────────────┼───────────────────────┐ ▼ ▼ ▼ ┌────────────────────┐ ┌──────────────────┐ ┌────────────────────┐ │short-story-analysis│ │ style-corpus-rag │ │ csp │ │ 多维度分析 │ │ 分块→标注→向量化 │ │ 检索→蒸馏→质检角色卡│ └─────────┬──────────┘ └────────┬─────────┘ └─────────┬──────────┘ ▼ ▼ ▼ 内核/框架/开篇 三报告 文风向量库Qdrant 角色卡人设规范 └──────────────┬───────┴──────────────────────┘ ▼ 三类写作前知识资产 ┌──────────────────────────────────────────────────────────────────────┐ │ ② 编排层 opencode subagent人在环中阶段分离 │ │ scene-designer → scene-refiner → scene-polisher → scene-wordsmith │ │ → scene-reviewer可选 │ └───────────────────────────────┬──────────────────────────────────────┘ ▼ ┌──────────────────────────────────────────────────────────────────────┐ │ ③ 执行层 src/writing/纯确定性流水线不内置分析 / 设计 / 精修 │ │ scene_pipeline → beat_parser / beat_retriever / writing_guide / │ │ screen_writer / scene_summarizer │ └───────────────────────────────┬──────────────────────────────────────┘ ▼ ┌──────────────────────────────────────────────────────────────────────┐ │ ④ 配置层 config/* ⑤ 输出层 output/*带时间戳可追溯 │ └──────────────────────────────────────────────────────────────────────┘四个子仓的分工如下lofter_fetch采集从 LOFTER 按热度/标签抓取同人短篇落盘为带元数据的 Markdown。short-story-analysis分析对抓取到的文章做多维度分析产出「底层内核 / 叙事框架 / 开篇拆解」三份方法论报告——这是后续「设计」的原料。csp · Character Card Producer角色卡根据网络公开资料萌娘百科 API 等做检索 → 交叉验证 → 行为蒸馏 → 质量检查生成可追溯、可更新的写作用角色卡记录研究日期与资料边界。style-corpus-rag文风库把文风示范语料分块 → 多标签标注写作手法 / 情绪 / 场景→ 向量化入库建成可检索的文风知识库Qdrant供写作阶段召回示范段落。这四步都在写作之前分别回答「写什么题材」「怎么组织故事」「角色是谁」「用什么文风」。三类资产各归其位——三报告用于创意参考、角色卡进设定上下文、文风库进写作检索。四、五段式流程候选包 推荐选定确认打回修订draft_bundlefinal通过反馈① 收集 · 子仓预处理三报告 / 文风库 / 角色卡② 设计 · scene-designeragent结构 → 场景分析 → beat用户选案② 展开多场景剧本agent用户确认剧本③ 写作 · scene_pipeline执行解析 → 按 beat 检索 → 文风 → 初稿④ 精修agentrefiner → polisher → wordsmith用户审阅 / 反馈⑤ 审校 · scene-revieweragent可选菱形为人工决策点其余为脚本或 agent 节点agent设计 / 精修 / 审校以 subagent 形式经 opencode 编排写作段为纯脚本执行。收集四个子仓把网络原文转成写作前的知识资产三报告 / 文风库 / 角色卡。设计scene-designer 产出多场景剧本经「选案 剧本确认」两道人工门。写作scene_pipeline 纯执行到初稿多场景用--context注入上一场景梗概保持动作连续。精修refiner → polisher → wordsmith 依次处理表达逻辑、文风、字词。审校可选scene-reviewer 做多维审校并闭环修改。全程落盘、可追溯设计文件、初稿、精修输入包、审校包、最终正文都带时间戳互不覆盖。五、几个关键设计阶段分离 人工双确认门设计、精修、审校各有各的空间候选要用户选案、剧本要用户确认才轮到写作。参考机制迁移卡借鉴参考作品时区分「可迁移的因果机制」与「不可搬用的表层」只借机制与读感。设定与文风解耦角色卡与官方设定负责「像谁」风格 RAG 只提供语感结构由剧本设计、写法由文风规范各自负责。按 beat 分配检索把检索粒度对齐叙事节拍避免整段召回导致文风串味。子仓化与可重建知识库与向量库拆成独立子仓风格库可由语料全量重建主仓只留一层薄转发。六、实战案例以最近完成的《梦限大MewType》同人单元剧《客座第一键》藤都子 × 薇欧拉 恋爱喜剧为例整条链路的产物是收集从短篇知识库取到一份参考作品的三报告配套角色卡与文风库设计产出参考机制迁移卡与三份候选用户选定「客座第一键」后展开为三场景剧本每场景 5–6 个行动 beat写作逐场景生成初稿场景之间注入上一场景梗概精修三场景分别过表达/逻辑精修、文风精修、炼字成稿合成最终正文附录给出其中一个场景。这里比较能体现设计意图的一点是「工作在明、情在暗」一条不署名的键盘轨把两个角色不愿直说的话交给工作和道具承载。七、资源与结语7.1 资源主仓https://gitee.com/zhuowoodbird/novel_rag_mewtype子仓Gitee 同组织lofter_fetch、short-story-analysis、style-corpus-rag角色卡生成器 csphttps://github.com/Jacob-Zhuo/Character_Skill_Producer7.2 结论整体上这套系统处理的是长文本的「可控性」把设计、精修、审校这些主观环节拆成可人工确认的步骤把执行环节做成确定性流水线。它不保证文本质量只是让改动的影响范围和结果更可追溯。就现状而言它仍有明显不足多场景衔接、文风稳定性、审校的有效性都还不理想距离满意还有距离。后续会继续在检索重排、审校自动化和多作品风格库上推进。7.3 教训背景个人项目从 9 月起断续开发编码主要由 DeepSeek 协助完成。系统改了两版初版以gitee分支的形式保存。现状反思系统目前需要大改。例如设计阶段取自short-story-analysis的三份报告多为「作品复述」而非「可迁移机制」抽象规律与具体素材混在一起、又未标适用边界即便提示词写明「不要照搬」模型仍容易被牵引——因此要从知识库这一层改起。类似问题还有方案可行性与行文缺少人味。开发先 Plan 再 Build需求问清再动手减少返工。能用 Agent 驱动就不把流程写死在脚本里逐步从「脚本自动化」转向「智能调用 脚本自动化」。测试时让 Agent 实时汇报进度、统计 token脚本执行要可中断、可恢复而非从头重跑。方法AI 开发的前提是对目标系统「成竹在胸」但这依赖很高的判断力难以一步到位。更现实的做法是先搭出初步的模块化系统再依据整体输出决定取舍——过早深挖单个模块往往白费因为模块的上下文与是否该重构都取决于全系统的测试结果。整体开发规律呈现一个「总—分—总」、螺旋上升的过程。前期开发完系统后期以点带面优化。我目前进入以点带面优化的过程了打算深入研究某个模块对比效果。附录AI小说示例单场景质量很低不建议欣赏摘自单元剧《客座第一键》三场景中的第一场景《懒得写间奏》。懒得写间奏凌晨一点十七分。野乃花把一条键盘轨丢进合轨文件夹紧跟着补上一行字。句尾缀着笑脸和三个感叹号不用看署名隔着屏幕都能闻出那股「拜托了都子酱」的热血味。留言写着「这轨明天彩排前必须有匿名投稿箱收的我原样塞进来了别问问就是直觉告诉我能用」藤都子盯着屏幕看了两秒。直觉。她把手机往旁边一推转向电脑摸出耳机戴上。管它什么直觉先听再说。点开文件。她原本只打算听两小节判断能不能用。第一小节。握鼠标的手停住了。是那双手触键的方式。旋律一概让给主唱自己只在缝里垫一下副歌前那一拍换别人早该顶上去那双手却先退半步。该推的时候不推该亮的时候让开像早就习惯站在后面等别人先走。耳机里循环着同一个小节。都子把进度条拖回去再听一遍。搭在空格键上的手指顿了半拍。这种弹法谁都能写。她在心里重复了一遍。舌尖抵着上颚像在念咒。然后她把文件拖进废件夹。删。下一秒又拖了回来。理由没时间重写。再删。这种投稿不能用——手却比脑子先动把文件拖了回来。再删。这回的理由是格式好像没问题。拖回的时候她自己都听得出这借口有多牵强。再删。间奏太薄不够用——理由还没想完指尖已经先动了。删。拖回。文件第五次落回轨道的时候她盯着屏幕把它改名为「K-07」。一个编号。冷冰冰的不留任何痕迹。窗外救护车的鸣笛掠过红蓝光扫过天花板一角又消失。她抱着丸君把脸埋进手臂。丸君的戏偶脸被挤得歪了一点绒毛蹭着下巴。「……反正又不是没人能写。」她对着绒毛说声音闷在胳膊里「这种轨谁都能……」后半句咽了回去。合轨。她新建了一个巡演版合轨工程把K-07拖进去。主唱轨叠上来吉他跟进来鼓点卡着拍。她自己的键盘轨早就录好此刻垫在K-07底下。手指在键盘模拟器上虚敲几个音没按录制只是比着轨的位置在心里数拍。间奏。到间奏她的手停了。两轨叠在一起。键盘垫在底下主唱在上面走合起来的声音是对的是完整的是彩排能用的。可她听着听着眉头皱了起来。多。多了一个音。不是K-07多是她自己的声部多了。两条轨叠在一块间奏那段陡然显得挤像两个人同时开口谁也听不清谁。都子把音量调大又调小再调大。那一段被翻来覆去地听耳机捂得发烫。她选中自己的键盘轨在间奏段按了删除。波形从中间坍下去一块黑的像分镜稿被撕掉一页。间奏只剩K-07孤零零垫在底下主唱换气的空隙里它只垫上半口气像在等一句接不上的话。她把空出来的这一段单独导出另存为新文件。文件名「空白参考.mp3」。凌晨一点四十三分。屏幕一角野乃花那句「必须有」还亮着。都子把新文件放进草稿文件夹让它和那些「最后没用」「太冒险」「存着吧」的项目躺在一起。她盯着文件夹看了很久。然后翻出野乃花转来的那个匿名投稿箱地址。附件拖进去。不写称呼不写正文只落一个文件名「空白参考.mp3」。按下发送。进度条走完。发送成功。时间戳停在凌晨两点零七分。连载的原稿还摊在手边铅笔压着空白格截稿日用红笔圈了三遍。她把手机按在稿纸角落屏幕朝下像盖住什么不该被看见的东西。丸君歪在桌角戏偶的眼睛在屏幕光里闪了一下。「……我只是懒得写间奏。」她对着丸君说声音很轻像怕被谁听见。丸君没有回答。绒毛脸歪着表情固定在某个似笑非笑的弧度上。都子盯着那个弧度看了几秒伸手把丸君的帽子往下拉了拉盖住半张脸。「反正又不是没人能写。」她没把「吧」字说出口。