Frame: 一个移动优先、AI-召唤式的个人古籍阅读工具

原问题#

我想要做一个能够帮助我阅读消化思考古籍的小应用，就我自己用，最好手机上也能用，主要就是读一读史记、唐诗宋词、离骚之类的

揭示与张力#

1. 「消化思考」是一个被压扁的词,真正可以拆出三层:字词句法 / 论述结构 / 审美与思想。第三层(审美与思想)工具救不了,只能靠时间和反复咀嚼;工具能做的只是「降低停留在文本里的阻力,让积累有机会发生」。

2. 古籍真正的卡点在「框架」不在「字面」。古人共享着一套对今天的我们已经隐形的前提(礼治、宗法、天命……)。一旦那个前提缺失,文字就在眼前变成断章。用户的醍醐灌顶时刻(资治通鉴 / 嫡长子继承制 / 司马光为何「坐视乱亡也不可破礼」)正是「框架解锁」的范例。

3. 核心 design tension 拆成两层:

- 翻译层 = 常驻。用户的真实阅读姿势就是「古文 + 白话译文并排看」,译文不是干扰、是阅读基础设施。v0 必须默认双栏(或上下文切换)、自动备好高质量译文。

- 讲解 / 补框架 / 答疑层 = 召唤式。这一层若主动推送会扼杀困惑(醍醐灌顶的前提),只在用户选段提问时全力配合。

- 设计原则修正版:译文常驻,解读召唤。

4. 痛点已经经过 (a)-(e) 强制选择,锁定为 (a)(b)(c):摩擦(复制粘贴麻烦)、持久化(问答和段落绑不住)、移动体验。不是 (e)(单纯想做工程),也不是 (d)(文本质量问题)。

5. 古籍内部其实再分两类,提示词策略不同:

- 史 / 论散文(史记、资治通鉴):"框架解锁"模式特别契合——已验证。

- 诗 / 词 / 骚(唐诗宋词、离骚):卡点是意象、典故、声律、心境,不是逻辑前提。v0 应优先服务前者,诗词留 v1 再说。

Converged question#

如何做一个最小化、移动优先的个人古籍阅读工具,既显著降低用户当前 (a) 摩擦 (b) 持久化 (c) 移动体验三方面的痛苦,又遵守「译文常驻、解读召唤」的双层原则:翻译作为阅读基础设施默认在场,讲解 / 答疑只在被召唤时出现,不滑向"替代思考"的反模式?

子问题#

1. 技术栈选型:PWA / 原生 / 跨平台?个人项目的最低运维成本路径是什么?
2. 文本来源:史记、资治通鉴等公开古籍的高质量电子化文本从哪取?分卷分篇结构如何处理?(daizhigev20、ctext、殆知阁等)
3. AI 召唤交互:选中段落后的最佳触发模式是什么(长按 / 划线 / 浮动按钮)?手机上特别要怎么设计才不打断阅读流?
4. 提示词工程:能可靠引出「翻译 + 逻辑解读」风格回答的提示词怎么写?对不同文本类型(史 / 论 / 诗)是否需要分支?
5. 持久化模型:问答如何附着段落?thread-per-passage 还是 single-thread-with-anchors?跨设备同步是必要还是过度?
6. 「不做」清单的边界:如何在演化中抵抗 feature creep(添加注释引擎、用户系统、推荐算法等的工程诱惑)?

学习者 orientation#

process-sovereign(健康)

证据:用户在我提出"AI 全译会扼杀醍醐灌顶"的命题被自己的真实经验反驳时,直接给出了反例(「我就是用 AI 翻译白话+补充逻辑解读」),没有为了维持权威或为了让对话顺畅而附和;在 (a)-(e) 选项中能直面 (e)(只是想做工程)的可能性并明确否认。整场对话开放、可被推翻、目的是想清楚而不是被认同。

对下游的指令#

/learn 须:

- 区分两类研究产出:(1) 已有产品调研(古诗文网、殆知阁、中华书局点校本数据库、各家诗词 app)——用来抄、避免重复造轮子;(2) 技术 / 实现路径研究——用来定型 v0。

- 在「LLM 处理文言文 / 古籍解读」这个领域,必须区分「研究证实 / 业界共识 / 个人 vibe 三档」。文言能力在不同 LLM 之间方差很大,值得实测对比(Claude / GPT / 通义 / 文心 / DeepSeek)。

- 关注 PWA + LLM + IndexedDB / SQLite 这类「无后端 / 极轻后端」的个人项目模板。

- 关注高质量公开古籍文本源(GitHub 上的 daizhigev20、中国哲学书电子化计划 ctext 等)的格式、版权、可用性。

/teachme 须:

- 用户是 process-sovereign,可走默认结构,无需强 steel-man。

- 篇幅可以紧凑——用户已具备清晰判断力,不需要过度铺垫。

- 结尾必须留一节明确的「v0 周末可做版」蓝图(技术栈 + 实现步骤),这是用户最实际的产出诉求。