从“能总结 PDF”到
“可验证的 AI 深度阅读工作台”
基于现有 AI Reader 项目的能力与代码结构，按「需求分析 → 需求拆解 → 市场调研 → 竞品分析 → 产品设计 → 工作流落地」六步法重新定义产品。重点不是再增加几个 AI 按钮，而是把长文档理解、证据追溯、主动阅读与个人知识沉淀连成闭环。
这个项目已经不是空白 Demo，但“系统能力”还没有完全显性化
当前代码已覆盖阅读、书库、目录、深度解读、划词分析、追问、批注、想法、朗读和分享卡片；大书采用分块 → 章节聚合 → 全书聚合的 Map-Reduce 分析。但产品呈现仍偏“功能集合”，缺少对可靠性、证据、任务状态和企业级工程能力的明确表达。
PDF 阅读、目录跳转、文本选择、高亮与页码定位。
全书深度解读、核心命题、论证链、框架、概念、案例与阅读路径。
划词解析、关键词、追问、笔记、AI 辅助想法、朗读、分享。
Next.js 14 + DeepSeek；本地书库与 JSON/LocalStorage 缓存；大书并发分块分析。
先追“为什么要 AI 阅读”，而不是默认答案是“做一个 ChatPDF”
上传一本 PDF，让 AI 总结、解释、回答问题，并辅助做笔记。
缩短从“打开一本长文档”到“获得可验证理解”的时间，同时降低漏读、误读和信息回找成本。
用户不是缺“生成一段摘要”的工具，而是缺一个能在阅读过程中持续提供证据、结构和知识沉淀的研究助手。
让 AI 能力形成可展示、可复用、可量化的阅读产品，而不是一次性调用大模型。
快速理解全书结构；对难点获得解释；追溯结论来源；把重要内容变成自己的笔记和可复用知识。
可靠解析 → 结构化理解 → 检索与问答 → 引用校验 → 批注沉淀 → 评估与反馈。
5W2H + Agent 四问，把“阅读助手”拆成可实现的系统
Why：降低长文档理解和信息回溯成本。
Who：研究、产品、咨询、投资、学习等需要精读长文档的知识工作者。
What：理解、问答、证据、笔记。
When：预读 / 精读 / 回看 / 输出。
Where：阅读器主界面内完成，不强迫用户在多个工具间切换。
How：解析 + OCR + 章节化 + RAG + 分层生成 + Citation Verifier。
How much：一期优先保证“可读、可问、可引用、可保存”。
不是先问“市场有多大”，而是先验证问题是否高频、能否被 AI 稳定解决、价值是否足够
- 一本书到底讲什么？
- 这个结论依据在哪一页？
- 某概念和前文有什么关系？
- 读过的信息如何快速回找？
- 可提取文本 PDF：高
- 扫描 PDF：取决于 OCR
- 跨章关联：需要检索和分层聚合
- 事实引用：必须增加验证链
建议记录：首次洞察耗时、找到证据耗时、每章摘要人工耗时、单书 AI 成本、重试率。以“节约有效阅读时间”替代虚假的 DAU 叙事。
真实阅读任务访谈、用户屏幕录制、失败问答、书籍类型分布、扫描件比例、笔记转化路径、现有工具实测。
三层找竞品，四维拆解，不只盯着“AI 阅读器”这个品类
“上传文档 → 对话/总结”的 AI 文档工具。
阅读批注、知识管理、研究笔记类工具，它们解决同一类“理解与沉淀”问题。
原生 PDF 阅读器 + 通用大模型 + 手工笔记；成本低，但上下文断裂、证据追溯弱。
MoSCoW 圈定一期：先把 Must 做扎实
| 优先级 | 能力 | 设计标准 | 验收信号 |
|---|---|---|---|
| Must | 可靠上传与解析 / OCR fallback | 数字 PDF 走 text layer；扫描版自动 OCR；解析状态可见、可重试。 | 不再用“扫描版暂不支持”作为常态失败出口。 |
| Must | 全书结构化深度解读 | 章节级分析缓存；覆盖率、失败分块、模型与生成时间可见。 | 大书任务可恢复，局部失败不导致整书失败。 |
| Must | 证据化问答 | 先检索正文，再回答；每条书中结论绑定页码和证据片段；不足则 abstain。 | 引用存在性与支撑度可测。 |
| Must | 高亮 / 想法 / 笔记持久化 | 不只 LocalStorage；按用户/书籍/页码保存，并支持导出。 | 换浏览器/重启后仍可恢复。 |
| Should | 全书 Ask / 研究模式 | 支持“只基于书中”“书中 + 外部知识”两种模式，来源明确隔离。 | 用户知道哪些是原书、哪些是模型知识。 |
| Should | 分析任务中心 | 进度、耗时、Token/成本、失败重试、取消任务。 | 长任务从黑盒变成可运营系统。 |
| Could | 跨书对比 / 概念图谱 | 多书 RAG + 概念节点关联。 | 形成知识工作台扩展能力。 |
| Won't · 一期 | 社区、内容流、复杂协作审批 | 先不扩大产品边界。 | 避免在核心可靠性未解决前做“功能大而全”。 |
书库 → 阅读器 → 深度解读 / 证据链 / 问书 / 笔记；任务状态与来源贯穿所有 AI 结果。
页码、证据片段、覆盖率、置信度、来源类型、失败原因必须可见。
错误态、空态、长任务、可取消、重试、缓存命中、审计信息都有完整状态。
UI 与解析/检索/生成/存储解耦；本地开发可跑，生产环境可切对象存储、DB 与 Job Queue。
从“请求一个大模型接口”升级为可解释、可失败恢复的 Agent Workflow
工作流 A · 文档入库与深度解读
格式、大小、重复文件、元数据。
页级正文 + 页码 + 章节线索。
低文本覆盖率时自动进入 OCR。
书签 / 目录 / heading detection。
观点、概念、证据、局限。
章节摘要与论证关系。
全书框架、命题、方法与路径。
页码存在性 + 证据支撑度。
支持增量生成与恢复。
覆盖、错误、耗时、成本。
工作流 B · 全书问答
AI 阅读产品的质量不能只看“看起来像不像好答案”
模型给出的页码是否真的存在且对应当前书。
被引用片段是否确实支撑回答中的关键结论。
可解析书籍的全书任务最终完成率，允许分块重试。
按书页数、字符数、OCR 比例记录耗时与模型成本。
- 页码不存在的诱导问题
- 跨章节综合问题
- 书中没有答案的问题
- 作者观点 vs 通用知识冲突
- 扫描版 / 双栏 / 目录异常 / 中英混排
- 同一概念多处定义不一致
- Time to First Insight：首次有效洞察耗时
- Evidence Jump Rate：用户点击证据回原文比例
- Insight → Note Conversion：AI 结果转成笔记比例
- Question Resolution Rate：问书一次解决率
- Deep Analysis Completion：深度解读完成率
- Weekly Reopen：用户是否因已沉淀内容而回来
把项目从作品集 Demo 做成“像真实企业产品”的三阶段路径
先解决“能不能稳定读”
- OCR fallback
- 解析状态机与任务进度
- 引用校验器
- 统一错误模型
- 持久化存储抽象
再解决“能不能深度理解”
- 全书 RAG 与 Ask Book
- 章节级增量缓存
- 证据 rerank
- 框架/论证图可视化
- 评测集与回归测试
最后解决“能不能被组织采用”
- 用户 / Workspace / RBAC
- 对象存储与数据库
- 异步 Job Queue
- 成本与质量监控
- 导出、审计与数据保留策略