DrowseBook 的起点不是“再做一个电子书阅读器”，而是一个更窄的判断：很多用户已经习惯用手机听内容，但他们真正痛苦的是订阅、云端、账号、跳字、格式不透明和被打断。
这种项目适合独立开发者切入，因为它不是和大型内容平台抢版权书库，而是服务用户已经拥有的文件：EPUB、PDF、TXT、MOBI、AZW3。用户要的不是另一个内容商店，而是一个安静、离线、能把自己的书读出来的工具。
所以 DrowseBook 从立项开始就把“睡前、通勤、本地文件、系统 TTS、一次买断”放在一起看。它不是一个炫技型 AI 项目，而是一个把阅读和听书流程变得可信的小工具。
开发细节补充：这篇记录放在 DrowseBook 入梦书 的产品日记里，不是为了把一个功能包装成故事，而是把“01 · 立项调研：为什么做一个睡前听书阅读器”放回真实项目推进中看。它要同时回答三件事：用户为什么需要这个点，开发时哪些边界必须先定住，以及这个选择会怎样影响上架、推广和后续课程复盘。平台口径是 iPhone / iOS / 端侧，当前公开状态是 App Store / v1.1 已通过 / 无追踪，所以文案不能脱离真实发布进度。
对应的 docs 线索主要来自 DrowseBook 产品策略、格式解析和加载架构记录、v1.1 迭代总记录、外部提审与本地完成度审计。公开页面不会照搬内部工作记录，而是把可公开、可学习、不会泄露私密路径和账号信息的事实整理出来。DrowseBook 的 docs 很完整：开发哲学、22 条痛点功能清单、UI 结构、格式语言覆盖、定价买断、外部提审和完成审计都有记录。 开发计划连续记录了 EPUB、PDF、TXT、MOBI、AZW3 的格式对齐，惰性加载、章节热区、图片管线和阅读听书进度统一。 v1.1 记录把导入文件夹、音景、继续阅读、收费墙口径和多语言上架放在同一轮迭代里，说明它已经进入真实产品修补阶段。 公开文章要把这些工程事实翻译成用户能理解的选择：为什么本地、为什么系统 TTS、为什么一次买断、为什么少打扰。
从产品功能看，DrowseBook 入梦书 关联的能力包括：支持 EPUB、PDF、TXT、MOBI、AZW3、Apple 系统语音朗读、环境声和睡眠计时、无账号、无广告、无追踪。写这类日记时，不能只说“做了什么”，还要说明为什么先做这些、为什么暂时不做另一些。比如一个按钮、一个导入流程、一个本地模型开关或一段截图文案，放在代码里只是小改动，放在产品里却会影响用户理解、审核员复现和后续推广素材。
从工程推进看，这篇日记对应的检查点是：本地文件导入、TTS 和睡眠场景；v1.1 已于 2026-06-21 用户确认审核通过；生活工具类 App 的产品页案例。真实开发最容易失真的是中间过程，因为最后页面看起来只有一个结果，但实际会经历方案取舍、权限确认、素材准备、测试设备、审核备注和发布节奏。把这些过程写下来，后面做同类产品时才不会重新踩同一个坑。
从隐私和合规看，当前约束是：书籍文件、阅读位置和设置保存在 App sandbox，不使用账号和第三方追踪。这类信息必须前置到开发日记里，因为独立产品的可信度不是靠口号建立的，而是靠数据在哪里处理、用户能不能退出、功能是否离线可用、商店页怎么承诺、隐私政策是否与实现一致这些小事实积累出来的。
从课程和复用看，这篇内容可以沉淀到 iOS 本地阅读、TTS、安静产品设计、App Store 隐私标签。它的价值不只是给访问者看一个产品，而是展示一个独立开发者怎样把想法转成可验证的产品：先收窄场景，再选技术路径，再做体验最小闭环，最后把审核、推广、运营数据和失败教训都纳入下一次迭代。
本地阅读工具要先建立可信边界，再用格式支持、性能和安静体验证明价值。 这也是为什么每篇产品日记都要写到足够长：不是为了凑字数，而是为了把“证据、决策、实现、边界、复盘”都放在同一页，让读者看到一个判断是怎样被逐步验证出来的。最难的是让多格式阅读、TTS、进度、性能和睡眠场景互相配合，而不是变成功能堆叠。
所以这篇日记的结论不是“功能已经写完”，而是把一个阶段的判断公开化：哪些证据足够支撑继续推进，哪些资料还需要回到源码、商店材料、公开文案或运营观察里补齐。这样的记录会比单纯的发布公告更慢，但也更真实，能让产品页、发布记录和课程内容保持同一条事实线。
验收时我会把它拆成四个层次：第一层是用户路径能不能走通，第二层是异常状态有没有被诚实处理，第三层是页面上的按钮、状态、截图和文案是否对应真实发布渠道，第四层是公开证据能否支撑这个判断。只要其中一层对不上，产品看起来再完整，也不能算真正进入下一个阶段。
交接时也要保留边界：源码、构建、测试、商店元数据、公开文案、平台反馈和运营观察分别保存原始资料。产品日记只把这些事实翻译成读者能理解的过程，不替任何私有记录保存原始材料。
把这些内容公开出来，还有一个很现实的原因：AI 教程如果只展示成功结果，很容易让人误以为产品是一次生成出来的。真实情况恰好相反，真正可学习的是一次次收窄、验证、失败、补证据和重新提交。日记越具体，后续读者越能看到判断的脉络，而不是只看到一个漂亮的截图。
需求不是读书，而是把自己的文件听起来
头部听书产品已经验证了“把文本读出来”的需求，但很多产品把需求导向了自己的书库、订阅计划和云端服务。DrowseBook 反过来问：如果用户已经有书，能不能直接导入、继续读、继续听，而且不需要账号？
这个定位天然适合 iPhone。通勤、做家务、睡前关灯、戴 AirPods，这些都不是桌面阅读场景，而是手机和系统音频能力最强的地方。
竞品差评给出的切入口
差评里反复出现的不是“功能太少”，而是体验不可信：TTS 跳段、重复、卡住；免费试用突然变订阅；用户自己的书被平台逻辑干扰；PDF 会把页码、脚注和页眉读出来。
这些痛点可以直接翻译成产品差异：不用云 TTS，使用 Apple 系统语音；不建自有书库，只读用户文件；不做订阅，做一次买断；不做扫描和虚假广告，明确支持 DRM-free 文件。
为什么不是 DeepRead 式大愿景
早期很容易想把阅读器做成 AI 摘要、知识图谱、双语对照、云同步和智能书架的集合。但这些能力会快速拉高复杂度，也会把最核心的“打开就能听”稀释掉。
DrowseBook 的立项选择是收缩：首版先把本地导入、格式解析、阅读位置、系统 TTS、后台播放和买断边界做稳。以后可以加智能能力，但不能牺牲离线、安静和可信。
商业考虑：买断产品也要先验证场景
阅读听书是一个有付费心智的品类，但独立开发者不能靠堆功能赢头部。DrowseBook 选择的是更清楚的价值交换：免费下载试用，想长期把自己的书架和听书流程放进去，再一次解锁。
这类产品的课程价值也很高。它能讲清楚一个独立 App 怎么从竞品差评、场景定义、技术边界、隐私政策、商店页和审核策略一步步落地。