Proofnote

从证明格式到文档引擎

Proofnote 最初来自一个很普通的问题：邮件并不适合展示较长的数学解释。Gmail 不会渲染 Markdown，一旦公式、推导、条件与补充说明同时出现，很快就会变成一整块难以阅读的文字，我经常不得不为了让邮件看得下去而主动简化解释。

那次尝试产生了 Solution Note 1.0，它现在通过一条明确的兼容导入/导出路径继续被支持。它面向证明的呈现思路延续到了现代的 Proof Note 工作流中，但它已经不再是 Proofnote 的底层文档模型。

文档由内容模块构建

一篇文档由设计好的模块组成，包括标题、小标题、段落、公式、代码、表格、图片、语义模块与列表。写作意味着为每一部分内容选择它的语义，而不是和自由 CSS 搏斗。

排版、间距与打印规则由 Proofnote 统一控制，因此不同笔记之间保持一致，在屏幕、打印与 PDF 中读起来也是同一个样子。模块编辑器让这套结构始终可见、可改，而可复用模板则把反复出现的文档形态变成一步就能套用的东西。

面向 AI 协作写作

AI 生成的内容被当作需要校验的输入，而不是可以直接信任的输出。模型可以生成 Proofnote Document Format JSON，而 Proofnote 会在内容进入编辑器之前检查语法、Schema、文档限制、LaTeX 与结构一致性。

Proofnote Editable HTML 把这条工作流从单向生成扩展了出去：文档可以导出为人和 AI 都能编辑的语义化 HTML，在应用之外修改之后再导入回来。Proofnote 会恢复那些显式的语义改动，例如文字修改、模块插入、删除、移动、表格、标题与 LaTeX 源码，而把 CSS、class、外层包装与渲染预览视为纯粹的呈现。

当协议出现歧义时，导入器不会去猜。重复的模块标识、损坏的基线、互相冲突的字段、过期修订以及其它不安全状态都会被诊断并拒绝，而不是被悄悄转换成另一份文档。

本地优先的文档、Project 与模板

多篇文档存放在以 IndexedDB 为主的本地文档库中，正常使用不需要账户，也不需要应用后端。内置模板覆盖 Blank、Proof Note、Research Note、Lab Report 与 Essay / Report，任何文档都可以保存为个人模板。

本地 Project 容器提供了一种轻量的方式，用来组织相关文档，而不会把 Proofnote 变成一个文件系统或 IDE。一个 Project 可以把彼此独立的证明、实验、审查与笔记收拢在同一个总览与导航树之下，而成员关系始终只是本地文档库的元数据，不属于可移植文档本身。

因此，把文档在 Project 之间移动，不会改变它的规范内容、Editable HTML 身份、修订谱系或导出的文件。删除一个 Project 只会移除本地容器，其中的文档仍会以未归档文档的形式保留下来。

为可移植性而设计

Proofnote JSON 是规范形态：它是完整的备份与迁移文件，承载的是文档模型本身，而不是它的某一种渲染结果。Presentation HTML 则是可分享、可归档、可阅读的形态，渲染所需资源会被一并嵌入；打印与 PDF 输出把同一条线延伸到最终呈现。

Proofnote Editable HTML 是与 Presentation HTML 不同的另一项承诺：它是人和 AI 都能编辑的语义表示，可以在应用之外修改，再往返回到规范文档，并与记录下来的基线进行校验。把这两种格式明确区分开，才能让一边专注于忠实呈现，另一边专注于安全的语义编辑。

当前状态

Proofnote 目前处于 v3.1.0-rc.1，当前工作区修订为 v1.48。核心文档模型、模块编辑器、本地文档库、Project 导航以及 Editable HTML 往返协议都已进入发布候选状态。近期工作更多集中在加固本地持久化、修订冲突、导入边界、语义恢复与失败行为，而不再是引入新的文档概念。

项目记录