最近在讨论型社区里看到一句非常直接的话I wont read LLM authored fiction。这句话一下子把我拉回一个真实的阅读现场打开一个模型生成的小说片段句子流畅比喻工整情节也有起承转合但我读了不到几百字就想退出来。周围也有同学说AI写的短篇偶尔能骗过眼睛但一到中长篇幅就“露馅”。“露馅”这个词用得很准指的不是语法错误而是一种整体性的不对劲。这让我意识到拒绝阅读AI小说不是一个口味问题它背后藏着当前LLM在长文本创作上的真实边界。今天的博客不打算声讨模型也不打算替AI辩护而是想从技术实操的角度拆一下为什么这种情况下不该读、不想读以及如果你真的要用LLM参与创作该怎么做才不会翻车。1. 为什么“不读AI小说”是一个技术判断而不是偏见1.1 模型生成的文本只在语言表层成立如果让我给“不对劲”找一个更清晰的解释我会说模型生成的文本往往只在语言表层成立在叙事底层并不连续。什么叫语言表层就是你单独摘取任何一句话都会觉得通顺。形容词搭配没问题句式有起伏甚至还能用上互文、语气暗示这些技巧。什么叫叙事底层就是人物说的话必须符合他的性格、动机和当下处境剧情推进必须有因果链条一个角色的转变不该在没有任何事件铺垫的情况下突然发生。LLM做的是下一个词的概率预测。它没有一个“人物档案”也没有一个“事件因果”模块在后台持续维护。它看到的是一堆文本碎片于是它会尽量挑选看起来合理的说法而不是确保这句话符合整个故事世界。我见过一个例子。设定里主角是一个经历过背叛、从此拒绝信任的人。前两章模型写得很到位他对陌生人的善意充满警惕对话里全是试探。到了第三章没有任何前置事件他突然对刚认识的角色掏心掏底把最深的秘密告诉对方。如果你把这一章单独拿出来对话是通顺的人物也有情绪但只要放到整个故事里就会发现这个角色不是不好而是被模型写成另一个人了。读者说不清到底是哪里出了问题只会感到一种微妙的被欺骗感。这就是“像小说”和“成为小说”的区别。前者只要求文本在局部像后者要求整个虚构世界在因果、时间、人格层面都稳定。1.2 阅读小说读的是一个人的“经验底稿”所以“I wont read LLM authored fiction”并非纯粹的技术保守主义。读者读小说读的是人的经验、人的限制、人的不可预测的判断。机器可以把“失恋”这个词重组出一百种伤痛但它没有真的失去过什么。它可以模仿第一人称的脆弱感但没有对时间的感知没有深夜独处的生理记忆。这些经验性的东西恰好是长篇小说最重的那部分底稿。没有底稿的文字像一座用语言搭出来的布景近看很华丽但经不住人物在里面生活。我见过不少技术圈的人讨论既然模型已经能写出六万字的网文为什么还有读者说“没感觉”原因可能就在这。长篇网文当然可以靠强烈的冲突和快速更新留住人但读者一旦停下来想就很容易发现人物动机是悬浮的。这不是模型不够聪明而是它与物理世界的经验之间隔了一层符号。它能学到“痛苦”这个单词出现在哪些语境里但它不知道胃疼、失眠、手指颤抖是什么体验。因此“不读AI小说”更像一个有经验的读者在拒绝一种不完整的艺术形式。它不是对AI技术的否定而是对“语言流畅”与“叙事成立”之间巨大落差的敏锐察觉。2. 长文本创作难在哪模型缺的不是词汇而是结构化记忆如果你只是让LLM写一个三百字的童话片段它可以做得不错。但小说创作通常不是单次生成而是跨章节、跨情节、跨角色视角的持续维护。这恰恰是模型最吃力的地方。2.1 上下文窗口再大也不等于“记得住”很多新入坑的人觉得上下文窗口只要够长模型就能记住整个故事。这其实是误解。上下文窗口解决的是“这一刻能读到多少 token”不解决“如何从所有信息里提取当前最重要的约束”。哪怕你给我一个十万字的上下文模型在生成某个场景时也不会像人类作者那样先去翻一遍第十万字里的伏笔。它只会在当前注意力范围里做相关性判断。尤其当人物关系复杂、事件线索很多时十万字里的早期设定可能被稀释。所以我在构建创作类应用时通常会做三件事不再把所有章节都塞进 prompt。把关键设定拆成独立条目存成可检索的知识库。每次生成前只检索与当前场景最相关的设定片段。这套思路和很多技术人提到的“LLM Wiki”非常接近。简单说不是让模型消化全部内容而是把知识切成一块一块按需喂给它。放在小说创作里就是人物、世界观、时间线、风格要求、当前章节摘要都变成独立条目。这样模型在生成每个场景时只拿到它此刻真正需要的那部分信息。2.2 单次生成做不了长故事编排、Agent和工具链的前景除了记忆外长篇创作还要求“计划—执行—检查—修改”的多步循环。单次生成一个完整章节本质上是在“没有提纲的情况下一次跑完”。这就像让一个写手不看大纲、不做人物小传直接闷头写完一章。他可能能写出漂亮的句子但全篇结构大概率出问题。于是技术圈开始用编排框架、Agent、RAG、MCP 这类工具把流程拆开。编排框架负责定义流程先定章节目标再设计情节要点最后生成正文。Agent 可以扮演不同角色一个负责整理大纲一个负责写草稿一个负责审稿。RAG 负责在每一步之前检索相关设定。MCP 则可以把素材库、网页抓取、写作规范等外部资源接进来让模型在创作时能查询资料而不是凭概率硬编。这套组合确实能解决一部分“一致性”问题。比如人物漂移可以通过 RAG 反复注入人物设定来降低时间线错乱可以通过结构化摘要来约束风格不稳定可以给模型固定参考片段。还有一个容易被忽略的细节本地推理时的精度选择。如果你在本地跑开源模型FP16、BF16、FP32 这些精度选项会影响的不只是显存占用也可能影响输出文本的流畅度和稳定性。低精度推理在多数场景下够用但如果你用它连续生成几万字小说某些微妙的情感描述可能变得生硬。更稳妥的做法是先小样本对比再决定用哪种精度跑正式章节。2.3 工具能补一致性但补不了生活经验不过你看我们聊了这么多最终补的还是工程短板记忆、流程、一致性。这些东西非常重要但它们不构成小说的灵魂。故事里最动人的部分往往是作者对世界的独特观察一个人说谎前会先摸耳朵两个人多年后重逢第一句不是问候而是沉默一个孩子发现母亲也怕黑。这些细节不是从“设定库”里检索出来的是作者真的在生活里感受过、被震动过才放进小说里的。模型没有这种经验。它通过语料学习到“母亲怕黑”可以出现在感人故事里但这种组合对它来说只是概率不是记忆。所以工具链可以让小说变得更“像样子”却很难让小说有真正的“存在感”。这就是为什么我不建议把作者整个替换掉而建议把它当做一个非常能干、但缺乏真实生命经验的乙方。3. 如果你还是想用LLM辅助创作先跑通这四层工作流如果你读完前面依然想让LLM参与创作我的建议是不要一上来就让它“直接写一章”而是先搭一套四层工作流。这套流程适合从短篇扩展到中长篇也能帮你控制质量。3.1 第0层把虚构世界变成“LLM Wiki”很多失败案例都死在开头模型对人物一无所知就开始生成故事。你会看到角色一会儿叫张三一会儿叫张先生一会儿又变成“那个男人”。解决办法很朴素先建一个创作资产库。把所有关键信息结构化人物小传姓名、年龄、性格、目标、恐惧、口头禅、秘密。世界观时间、地点、社会规则、魔法/科技体系、关键势力。时间线已经发生过的事件、目前进行到哪一天、什么线索还没回收。风格样本你觉得满意的三个段落用来告诉模型“我要的是这种味道”。这个资产库可以只是一个 markdown 文件夹也可以放进向量数据库。关键是让每个条目短小、明确、彼此关联。不要写成长篇散文要写成条目式设定。因为模型检索时更喜欢清晰具体的片段而不是一整面墙的抒情描写。我把这个步骤叫“LLM Wiki”。它和开发团队维护技术文档很像不是把知识全部塞进模型而是把知识放在模型旁边需要的时候再取。3.2 第1层用RAG把设定变成可检索的长期记忆有了资产库之后每次生成前都要检索相关内容。这比把整个设定库拼进 prompt 更省 token也比扔几个关键词更稳定。一个常见的流程是拿到当前章节摘要或章节目标。把目标转成检索 query从向量库里召回 5 到 10 条相关设定。把召回的设定、上一章摘要、当前场景描述一起拼进 prompt。让模型只负责写当前这个场景不要试图回顾整个故事。下面是一个示意结构不是某个具体库的完整代码# 仅表示流程结构实际 API 以你使用的框架为准 from your_vector_store import VectorStore from your_llm_client import chat store VectorStore(namespacenovel_world) query 主角在第三幕最害怕什么会如何回避承诺 contexts store.query(query, top_k8) system_prompt 你是一个小说写作助理。 请根据以下人物设定与时间线写出当前场景。 当前场景要求主角在雨夜收到一封来自旧友的信。 保持人物动机一致不要引入与设定冲突的事件。 user_prompt \n.join(contexts) \n请输出场景正文。 result chat(system_prompt, user_prompt)这个流程的价值在于模型每次看到的都是“当前最相关的设定”。它不需要记住整本书只需要理解当前这个人、当下这件事。3.3 第2层用Agent和编排框架拆解章节任务当故事篇幅变长时单次“检索 生成”还是不够。因为一章可能有多个情节节点每个节点需要不同侧重点。这时候可以用 Agent 或编排框架把一个章节拆成多个子任务大纲 Agent根据章节目标列出 3 到 5 个情节点。场景 Agent逐个生成情节点对应的场景文本。审稿 Agent检查每个场景是否与设定冲突是否有术语漂移。修改 Agent根据审稿意见重写部分段落。这个过程非常像真实创作中的“提纲—初稿—修改”。区别在于模型没有审美自觉所以审稿 Agent 的检查标准必须非常具体不要写“请确保文笔优美”这种空泛要求而写“检查人物名是否一致”“检查时间线是否冲突”“检查主语是否频繁切换”。我一般会在 Agent 之间保留一个中间产物章节摘要。每跑完一章把章节摘要压缩成 200 字以内存回知识库。这样下一章生成时模型能通过检索拿到上一轮的信息而不是靠上下文窗口硬扛。3.4 第3层人类审查才是终稿入口前面所有层都是在“提高下限”真正决定作品层次的是人的审查。自动化生成速度快但它不懂“人心”。它可能写出一个推进剧情的场景但这个场景里的人物像棋子不像人。只有人能在阅读时感受到“这个角色在这里的反应太平淡了”“这个反转虽然意外但缺少暗示”。所以我会建议每生成一章先通读再标记问题再用修改指令让模型重写局部。不要在模型生成后直接发布。不是歧视模型而是长篇创作本身需要“审美主人”。没有人的判断前面那些 RAG、Agent 只是让错误更一致而不是让故事更好。4. AI小说读起来不对劲时按这五层顺序排查很多时候我们给LLM配置好了工具链生成的文本还是不对劲。此时先别急着换模型、调参数按顺序排查。大多数问题出在输入约束而不是模型能力。4.1 人物层动机和目标是否连续先看人物。角色这一章想做的事和上一章是否一样如果他从“逃离城市”突然变成“留在城市重建旧居”中间必须有事件。如果没有那多半是 prompt 里的人物设定没有被检索到或者被上下文里其他文本淹没了。排查动作找到该角色最近一次出场的关键摘要确认生成时是否被注入到 prompt 中。如果没有说明 RAG 检索的 query 不够准确或章节摘要没有摘要到位。4.2 时空层时间线、地点和因果是否一致再看时间和空间。模型经常把白天写成夜晚把主角从北方城市瞬间移动到南方小镇。这种错误通常不是因为模型“笨”而是因为时空信息没有被结构化存储。排查动作在知识库里维护一份“当前时间线”和“地点状态”每次生成前把最近的日期、地点、在场人物拉出来。不要指望模型自己从上一章推导出“现在是在春天还是秋天”。4.3 风格层视角、时态和措辞是否稳定很多模型生成的内容会突然切换视角。一段以第一人称“我”叙述下一段突然变成全知视角。这是因为训练数据里混入了大量不同风格的文本模型在生成时未必能保持稳定的叙事视角。排查动作在 prompt 里明确写出“始终使用第三人称有限视角只从主角的感知出发不描写读者无法知道的信息”。如果还是偏可以把一段稳定的风格样本放在 prompt 末尾让模型模仿它的句式节奏。4.4 信息层上下文、检索和工具链是不是喂错了内容如果人物、时间、风格都没有明显问题但整体读起来还是“飘”那就要检查信息流。有没有可能 RAG 召回到了一段错误的设定有没有可能 MCP 抓取网页素材时抓进来的内容污染了上下文有没有可能上一章摘要太长把真正重要的信息挤掉了排查动作把实际发送给模型的 prompt 打印出来逐段看一遍。你很快会发现某条不相关的设定被排在重要设定之前模型就把注意力放在那个错误信息上了。信息层的错误通常是最隐蔽的因为模型不会报错它会“顺应”你给的材料材料偏了它就跟着偏。4.5 参数层温度、采样和精度对输出的影响最后再查参数。温度太高输出会天马行空top_p 设置过宽也会让文本变得发散。这些参数对短句生成影响不明显但对连续几百字的小说场景影响很大。排查动作如果发现文本失控先把 temperature 降到 0.7 左右top_p 设到 0.9 以下生成一段对比。如果依然不稳定再检查本地推理的精度。FP16 在多数写作任务里没问题但某些小模型在量化后容易出现措辞生硬。不要指望参数调节能解决所有问题但它是排查链路上必须扫清的最后一道障碍。下面是一张简单的排查顺序表你可以打印出来贴在工位上排查层主要检查内容常见问题人物层动机、目标、性格是否连续角色突然改变态度行为不符合设定时空层时间线、地点、因果关系是否一致季节错乱人物瞬间换地点风格层视角、时态、措辞是否稳定第一人称与全知视角混用信息层RAG 检索、MCP 采集、上下文内容检索到无关设定工具喂错信息参数层温度、top_p、精度、输出长度文本发散、风格不稳、无意义重复5. 让LLM当“乙方”别让它当“作者”聊到最后我想把“I wont read LLM authored fiction”这句话再翻出来。它更像是一条创作分工的边界LLM可以参与写作流程但它不应该独占作者署名。5.1 适合交给LLM的创作环节从实操经验看这些环节交给LLM效率和体验都不错素材检索把散落的世界观、人物小传、历史事件用 RAG 快速召回。头脑风暴给定一个冲突让模型给出十个可能的走向你再从中挑一个。平行版本同一场景让模型写出三种语气方便你比较。扩展和压缩把一段提纲扩写成场景或者把一章缩成摘要。命名词汇给角色、地点、物品起名字模型可以给出大量候选。细节补充你知道场景里需要一封信但不知道信的内容可以让他先写一版草稿。这些工作的共同特点是需要语言能力不需要深度的个人经验。模型可以快速生成大量候选再由人做出判断和选择。5.2 不适合交给LLM的创作环节反过来下面这些环节尽量不要完全交给模型核心立意故事要表达什么作者对世界的判断是什么。人物动机角色为什么做出某个人生选择这里凝结了作者对人性的理解。结局取舍哪个角色活下来哪段关系被切断哪种遗憾被保留。审美决策一句比喻是否太俗一段描写是否讨好读者这些需要独立审美判断。你可以拿这些环节去问模型获得参考意见但最终拍板的人应该是有血有肉的人类作者。否则长篇创作会变成一种“高速度的平庸”每一句都通顺每一段都似曾相识整体却没有一个真正想表达的内核。5.3 “我不读AI小说”是一条诚实的边界所以在我看来“我不读AI小说”不是一句偏执的宣言。它更像一个长期阅读者保护自己体验的边界。我不需要为了追赶潮流硬去读一本让大脑觉得“这可能是人写的”但身体知道“这不是生活”的小说。也不需要在技术社区里假装AI已经全面超越人类作者。模型确实在进步它能组织语言、安排情节、模拟情绪但它缺少“经历”本身。创作者真正的护城河从来不是“写得快”而是“经历过、思考过、怀疑过之后做出了判断”。LLM可以帮助处理大量重复劳动也可以成为灵感的加速器但文学创作里最珍贵的部分依然来自一个真实的人面对世界时的反应。如果哪一天你读到一部AI小说真的被打动了那么打动的可能不是模型的文字而是你在那只言片语里看到的自己生活的影子。那也很美。但那不是模型的故事是你的故事。