同一本书，一人一份：我如何设计 AI 个性化扫书报告
同一本书，在不同网文推书圈子里，可能得到截然不同的入坑结论。
有人能接受非圆满结局，却不能接受 NTR 等核心感情背叛；有人优先看感情线，有人只想先排查剧情注水、升级体系崩坏和后期烂尾。
扫书帖并不只是复述剧情。即使没有写明"适合谁"，它也会按照作者和所在圈子的标准做出取舍：哪些问题必须先说，哪些风险足以劝退，哪些内容可以一笔带过。
网文社区天然会按题材和口味分圈，所以这种方式通常有效。但它最多只能做到"一群人一套标准"。
我想再往前走一步：
同一本书只保留一套事实；每位读者都根据自己确认过的阅读画像，得到一份属于自己的 AI 扫书报告。
实现它的关键，不是让 AI 对同一本书理解出不同事实，而是把"书"和"人"分开。
BookGraph 保存人物、事件、关系变化和原文证据，回答"书里发生了什么"；阅读画像保存用户确认过的题材偏好、阅读重点和明确雷点，回答"其中什么对这个读者最重要"。
书的事实只有一套，报告可以一人一份。
一、这个想法为什么直到问书地图出现才可行
我很早就想做个性化 AI 扫书，却一直没有真正落地。
扫书报告必须建立在对整本书的理解上。至少以我当前默认使用的 DeepSeek V4 Flash 为例，无论 Prompt 写得多好、模型再聪明，只要判断依赖全书信息，就绕不开读取足够原文的时间和 Token 下限。
所以我最初开发 AI 问书时，走的是相反方向：通过 RAG 和 Agent Harness 搜索当前问题需要的原文，让模型尽量少读，而不是在用户提问前先扫完整本书。
但用户会问"两个人最后怎么样""这条感情线后面有没有越界""前面的伏笔收住了吗""后期为什么会崩"。这些问题没有稳定关键词，依据可能散落在不同章节。只命中几个片段，很容易把局部情节误当成整本书的结论。
我最终把 AI 对整本书的一次理解，沉淀成结构化 BookGraph：先按章节或内容单元提取人物、事件、关系变化和证据位置，再在全书层合并人物身份、时间线与关系演变。
这样，一次全书理解就不再只服务某一道问题。它既能生成一人一份的扫书报告，也能为全书问书、高能进度条和动态人物关系图等能力提供同一套事实底座。
既然完整理解一本书的成本已经付过，就应该尽可能复用这份结构化结果，而不是让每项功能重新读一遍书。
一个因为成本搁置很久的产品想法，到这里才真正具备工程条件。
二、画像最难的不是建出来，而是有没有稳定的"进水口"
恰好，阅读 App 天然拥有这样一条持续、低摩擦的进水口：阅读统计。
用户最近读了哪些书、读了多久、是否读完，都会在正常使用中自然产生，不需要额外写日志，也不需要反复填写问卷。
因此，我没有把阅读画像做成一次性问卷，也没有让 AI 在后台维护另一份"它认为的用户画像"。
系统里只有一份用户可以查看和修改的阅读画像，但它有两条入口：用户主动设置，用来建立最初的偏好基线；阅读统计驱动的 AI 阅读观察，用来发现之后可能发生的变化。
对于缺少题材标签的本地 TXT 或 EPUB，系统会先根据书名等可用信息形成候选题材，再结合实际阅读记录提出观察。
例如，用户近期连续读了几本种田经营文，AI 可以询问：
最近的阅读中，"种田 / 经营"持续出现，要不要把它加入"也会看"？
但这条观察不会直接修改阅读画像。
书名推断可能出错，连续阅读也可能只是书荒、跟风，或者一段时间突然上头。用户接受，建议才进入画像；用户拒绝，原画像保持不变。
阅读统计提供信号，AI 阅读观察把信号翻译成候选，用户确认后才更新画像。
稳定的进水口解决了画像怎样持续获得新信息，却不代表这些信息天然可靠。用户确认不是多余的一步，而是把带有噪声的行为信号转化为长期偏好的关键边界。
AI 的建议权限也被刻意限制。它可以建议新增"也会看的题材"或"也会关注的阅读重点"，但不能仅凭近期行为推断用户能够接受哪些雷点，也不能擅自判断用户偏好哪种感情线结构。
"最近看过"不等于"长期喜欢"，"没有立刻弃书"也不等于"能够接受"。
图 2：左侧为用户主动建立阅读画像；右侧为阅读统计触发的 AI 阅读观察。
同一份阅读画像的两条入口：用户主动建立偏好基线，AI 根据阅读统计提出候选变化；两者最终都由用户确认。
三、画像可以改变报告取舍，但不能改写书中事实
阅读画像在哪个阶段进入系统，比画像包含多少字段更重要。
我把扫书分成两层。
第一层按章节或内容单元提取事件、人物状态、关系变化和原文证据。这个阶段不读取用户画像。同一本书，无论由谁阅读，人物做过什么、关系如何变化、结局是否发生，都只能有一套事实。
第二层进行全书综合时，才读取用户已经确认的阅读画像，决定哪些看点和风险应该前置、哪些内容值得展开，以及最终怎样给出入坑判断。尚未得到用户确认的 AI 阅读观察，不会进入这一层。
例如，"两个核心人物最终没有在一起"是一条固定事实。
对于明确排斥非圆满结局的读者，它应该出现在报告最前面；对于能够接受这类结局、但更在意剧情有没有讲圆的读者，报告则应继续解释前面的铺垫是否成立、人物选择是否说得通、关键伏笔有没有收住。
改变的是报告的顺序、篇幅和判断重点，不是书中的结局。
BookGraph 回答"书里发生了什么"，阅读画像回答"其中什么对这个读者最重要"。两者只在最终综合阶段相遇。
这也意味着，同一本书只需要完成一次结构化理解，就可以服务不同读者，不必因为画像不同而重新读一遍全书。
为了让报告中的判断能够回到原文，模型只能引用它实际看到的短 ID。系统端检查 ID 是否真实存在、是否属于当前书本与处理范围，再将其映射为可以查看和跳转的原文位置。
模型负责语义判断，系统端负责保证地址真实、范围合法。能够跳回原文，不代表判断一定正确，后者仍然需要通过评测持续约束。
在工程上，我把章节拆成有界并发任务，并加入缓存和断点恢复，避免一个单元失败后整本重来。这些设计只服务于一个目标：让一次全书理解稳定沉淀，并被不同读者的扫书报告反复复用。
结语
这次设计让我重新理解了 AI 个性化。
它不是把用户偏好追加进 Prompt，也不是让模型根据行为数据，在后台悄悄定义用户。
阅读统计可以持续提供信号，但不能直接成为偏好结论；AI 可以提出观察，但用户决定哪些内容进入阅读画像；画像可以改变报告重点，却不能改变书中事实。
目前，统一阅读画像、AI 阅读观察和个性化扫书链路已经进入 TestFlight 内测。接下来需要验证的，不是还能增加多少画像字段，而是这些观察是否真正有用、是否会打扰用户，以及一人一份的报告能不能帮助读者更快决定要不要入坑。
一个 AI 产品是否真正懂用户，不取决于它敢猜多少，而取决于它知道什么可以观察、什么必须确认、什么绝不能改写。