作为一名热爱编程并对AI写作有兴趣的开发者，我最近在探索如何使用AI大模型来辅助长篇小说的创作。然而，一个巨大的障碍横亘在面前：上下文长度限制。
无论模型的能力多强，当你的故事超过它能“记住”的范围时，它就会迷失方向。角色关系、伏笔细节、世界观设定……这些长篇小说的灵魂，在有限的上下文窗口前，变得支离破碎。今天，我想分享我如何解决这个问题，并介绍我为此开发的Android应用。
一、 问题的核心：被束缚的创作想象力
以我使用的DeepSeek模型为例，它支持128K Token的上下文，这大约能容纳8万个汉字。这听起来很多，对吧？
但让我们算一笔账：
- 一部网络长篇小说，动辄上百章。
- 按每章4000字计算，仅仅20章的全文，就足以填满整个宝贵的上下文窗口。
这意味着，当你写到第21章时，AI已经“忘记”了第1章开篇那个至关重要的伏笔。这种“失忆”会导致情节前后矛盾、人物性格突变，让AI生成的续写内容与整体故事脱节。我们需要的不是一次性的对话，而是一个能让AI始终把握故事全局的“协作记忆系统”。
二、 解决方案：分层摘要体系——从章节到卷宗
既然无法提交全文，那么我们就提交故事的“精髓”。我的解决方案是构建一个分层摘要体系。
1. 章节摘要（核心基石）
- 为每一章生成一个约500字的摘要。
- 摘要需提炼：核心情节推进、关键对话、人物关系变化、重要伏笔。
- 效果：原本4000字的一章，被压缩了8倍。理论上，我们可以将超过100章的摘要置入上下文，这足以覆盖绝大多数长篇作品。
2. 卷宗摘要（更高维度的概括）
- 如果小说分为多卷（如“第一卷：觉醒”、“第二卷：远征”），我们可以为每一卷生成一个更精炼的摘要（例如200字）。
- 在需要回顾遥远过去的情节时，用卷摘要代替其下所有章的摘要，能指数级地节省上下文空间。
工作流示意图： 假设我们正在创作第105章，提交给AI的上下文结构如下：
[系统指令]：你是一名小说家，请根据以下故事背景和过往情节，续写最新一章。
---
[故事核心设定与主要人物介绍]（固定内容）
---
[第一卷摘要]（200字，概括1-50章）
[第二卷摘要]（200字，概括51-100章）
---
[第101章全文]（4000字，提供最近的完整上下文）
[第102章摘要]（500字）
[第103章摘要]（500字）
[第104章摘要]（500字）
---
[写作指令]：请续写第105章，要求......
通过这种方式，AI在动笔之前，已经拥有了一个从宏观到微观的完整故事脉络，从而能生成连贯、合理且忠于前文的精彩内容。
三、 从思路到产品：自动化助手Android App
手动维护这个摘要体系无疑是非常繁琐的。为了将这一方法论产品化，我开发了一款Android应用。
技术栈选择：
- 界面：采用现代、声明式的 Jetpack Compose，打造流畅的原生UI体验。
- 数据持久化：使用 Room 作为数据库框架，稳定高效地管理项目、章节、卷和摘要等结构化数据。
- AI能力：无缝接入 DeepSeek API，作为整个应用的大脑。
应用核心功能：
- 项目与章节管理：轻松创建你的小说项目，新增和管理各个章节。
- 智能上下文拼接：当你需要续写某一章时，应用会根据预设策略（如“最近N章全文 + 更早章节摘要”），自动为你拼接好完整的提示词，你只需一键提交。
- 一键生成摘要：写完一章后，点击“生成摘要”按钮，应用会自动调用AI，根据本章内容提炼出高质量的500字摘要，并保存至数据库。
- 卷管理：支持创建卷，并允许你基于下属所有章节的摘要，生成更高层次的卷摘要。
这个应用将复杂的上下文管理抽象成了简单的按钮点击，让创作者可以专注于故事本身，而非技术细节。
Github链接
APP已基于GPL协议开源。
