Inkstone 自托管笔记系统 30 天验收清单：从能部署到能放心长期使用

Inkstone 不适合只用“能不能部署成功”来判断。它是一套运行在 Cloudflare Workers 上的自托管 Markdown 笔记应用，官方定位包括写作、实时预览、全文搜索、可选语义搜索、双链、离线编辑、多设备同步、公开分享、导出和 WebDAV/S3 备份。真正的验收标准应该是：连续使用 30 天后，你是否知道数据在哪里、权限怎么收口、断网和冲突会怎样、备份能不能恢复、密码丢失怎么处理、退出时能否拿走可读 Markdown。

下面这份清单按 30 天试用设计。它不复述部署教程，也不假定任何固定免费额度、价格或隐藏命令；所有判断都落到可观察证据上。试用结束时只做三种决定：继续使用、修完再试，或者停止迁入核心资料。

验收原则：先定义“可接受”，不要边用边猜

第一天开始前，先把 Inkstone 当成一个生产中的个人服务，而不是一次玩具部署。部署者拥有 Cloudflare 账户、D1 数据库、R2 或 KV 附件存储、OAuth KV、Durable Objects、Workers AI 绑定和备份目的地的责任；安全文档也明确说明，Inkstone 是自托管软件，不提供绕过密码重置的后门，Cloudflare 账户、域名、访问策略、备份位置和及时更新都由实例所有者负责。

通过标准：30 天内至少完成一次真实写作、一次附件使用、一次跨设备同步、一次离线编辑、一次导出、一次备份和一次恢复演练。
失败标准：只完成部署截图，没有恢复证据；只写测试文本，没有导出和退出路径；只看功能列表，没有验证登录、权限和备份边界。
记录方式：用一份普通验收表记录日期、动作、结果、截图或导出文件位置、发现的问题、决定。不要把验收证据只留在 Inkstone 里。

第 1—3 天：前置条件和部署证据

部署验收的核心不是“页面打开了”，而是实例的所有基础组件都落在你控制的账号中，并且你能解释每个组件的用途。官方 README 对存储边界写得很清楚：D1 保存账号、笔记、文件夹、标签、设置、版本、分享、全文索引、AI embeddings 和后台索引队列；R2 或 Workers KV 保存附件和头像；OAUTH_KV 保存 OAuth 客户端、授权码、访问/刷新令牌和授权记录，不保存笔记正文；浏览器 IndexedDB 保存本地缓存和待同步的离线写入；SyncHub Durable Object 负责实时变更通知；CredentialVault Durable Object 隔离保存用于加密备份凭据的密钥；WebDAV 或 S3 是用户配置的异地备份目标。

前置条件：确认 Cloudflare 账户归属、域名归属、GitHub fork 归属、备份目标归属、管理员邮箱或登录凭据归属。多人团队试用时，还要提前确认谁是 owner，谁有 Cloudflare 控制台权限。
部署证据：保存 Workers 实例地址、自定义域名、D1 数据库名称、附件存储模式、OAuth KV 绑定、Durable Object 绑定、备份目标配置页面截图或文字记录。证据只需证明边界存在，不需要公开密钥。
版本证据：记录当前使用的 Inkstone 版本或提交。官方 v0.8.0 说明提到现有 D1 会通过自动、幂等迁移新增和调整索引，但更新自托管实例前仍建议保留最新备份；这条建议应写入后续更新流程。
验收结论：如果你无法说清 D1、R2/KV、OAUTH_KV、Durable Object 和备份目标分别保存什么，先不要导入大量真实资料。

第 4—7 天：登录、安全和 owner 责任

自托管笔记最容易被低估的是登录风险。普通 SaaS 可以联系客服找回账号；Inkstone 的安全边界不同。官方安全文档明确说，丢失 owner 密码时，需要从可信备份恢复或重新初始化实例，不存在绕过密码重置的通道。这不是缺陷，而是自托管系统应有的边界：系统不应留一个能绕过 owner 密码的万能入口。

owner 密码演练：把 owner 密码纳入密码管理器，记录恢复负责人和恢复位置；不要把密码只记在 Inkstone 笔记里。验收时确认至少一名负责人知道“密码丢失后不能靠后台找回，只能恢复可信备份或重建”。
会话边界：在常用电脑、手机和平板登录一次，记录退出登录是否生效、换设备后是否需要重新认证、共享设备上是否能完全清掉会话。
分享边界：创建一条公开笔记链接，测试访问密码和有效期；到期或撤销后，用无痕窗口确认外部无法继续访问。不要用含私人信息的笔记做第一次测试。
MCP/API 边界：如果启用私有远程 MCP 或 API key，只接受可撤销、可区分权限、可记录用途的密钥。官方 README 提到 MCP 具备 OAuth 2.1 with PKCE、可撤销的 ink_... API key、标准 search/fetch、有限读取、修订安全写入、独立 trash 权限和按账号授权管理；验收时要确认自己实际需要哪些权限，而不是默认全开。

第 8—12 天：D1、R2/KV、OAuth KV 的数据边界

30 天试用里要故意制造几类数据，观察它们分别落在哪个边界：普通文字笔记、带标签笔记、带附件笔记、公开分享笔记、离线编辑版本、搜索索引、AI 索引、备份快照。这样做的目的不是窥探底层表结构，而是避免以后把“Markdown 可迁移”误解成“所有状态都天然可迁移”。

D1 验收：创建、改名、移动、加标签、收藏、置顶、归档、删除和恢复几篇笔记；确认这些结构性状态在重新登录后仍然存在。全文搜索和版本历史也属于 D1 相关能力，测试时应包含中文标题、中文正文、英文术语和代码片段。
附件验收：上传图片和一个普通附件，分别在正文引用、公开分享、导出和备份中检查是否可用。官方 v0.8.0 修复了 Markdown 示例围栏中附件引用遗漏的问题；如果你的使用方式依赖大量示例或教程文档，附件引用应列入重点检查。
R2/KV 选择：只记录自己实际采用的是 R2 还是 Workers KV，不要在验收报告中写入未验证的容量、价格或性能承诺。能满足附件读写、导出和恢复即可进入下一阶段；不能满足时，先换存储策略再扩大使用。
OAuth KV 验收：启用外部访问能力时，确认撤销授权后旧令牌不再可用。由于 README 明确说明 OAUTH_KV 不保存笔记正文，这个边界有利于审计，但不代表令牌可以随意长期保留。

第 13—17 天：离线、同步和冲突处理

Inkstone 的可靠性能力包括可安装 PWA、离线启动、浏览器缓存、离线写入队列、乐观并发控制、本地即时变更与回滚、stale-sync 保护、冲突副本、实时通知和选举标签页轮询兜底。验收时不要只在高速网络下写一篇文章，而要故意制造网络断开、双设备同时编辑和浏览器刷新。

离线写入：在一台设备断网后编辑一篇低风险测试笔记，重新联网后确认内容是否同步、失败是否有可见提示、是否出现冲突副本。
双设备冲突：在电脑和手机同时修改同一段文字，观察系统是合并、保留较新版本、生成冲突副本，还是需要人工处理。只要结果可见、可解释、可恢复，就可以接受；静默覆盖应列为阻断问题。
多标签页：同一浏览器打开多个标签页，分别编辑、刷新和关闭，确认旧响应不会覆盖新内容。v0.8.0 对笔记打开流程和离线编辑恢复做了改进，试用时应验证这些改进是否符合自己的工作流。
移动端体验：v0.8.0 重做了移动端笔记库、账号体验和底部导航。移动验收不只看能不能打开，还要测试搜索入口、新建笔记、切换编辑/阅读、设置入口和长文滚动。

第 18—21 天：搜索和 AI 可选性

Inkstone 的基础搜索是 D1 FTS5 全文搜索，支持中文索引、筛选、最近笔记和命令面板；语义或混合搜索依赖 Workers AI，是可选能力。验收时应先确认关键词搜索能满足日常找笔记，再决定是否开启 AI。不要把 AI 搜索当成系统可用性的前提。

关键词搜索：准备十几篇真实结构的测试笔记，包含中文词、英文库名、命令片段、日期、人名和项目代号；分别用标题、正文、标签和近期笔记入口搜索。
AI 可选性：未配置 AI 绑定时，系统应继续使用关键词搜索。官方 v0.8.0 还把本地开发默认路径改为不等待远程 Workers AI，只有明确 AI 模式才走真实 AI 路径；这说明 AI 应被当作增强项，而不是基础依赖。
隐私边界：如果启用语义搜索，记录哪些内容会生成 embeddings、索引何时更新、关闭后如何处理旧索引。不要把敏感笔记放入尚未验收的 AI 搜索范围。
通过标准：80% 以上常用笔记能用关键词或命令面板快速找回；AI 搜索即使关闭，也不影响写作、同步、导出和备份。

第 22—26 天：备份、恢复和更新前保护

Inkstone 的可迁移性必须靠恢复演练证明。官方 README 说明，JSON 导出保留旧版结构化笔记数据；ZIP 导出和远程备份使用相同的已验证 Markdown 快照格式，包括可读笔记、归档和回收站笔记、附件与完成标记；远程备份支持 WebDAV 和 S3 兼容存储，重复附件内容在每个快照中只保存一次；大备份可通过选择备份文件夹恢复，而不需要一次性把完整归档读入内存；登录密码、活动会话、分享密码和备份服务凭据不包含在导出中。

手动导出：分别做 JSON、ZIP 或 Markdown 相关导出，打开导出的普通 Markdown 文件，确认中文、表格、任务列表、脚注、数学公式、Mermaid、代码块、Front Matter 和附件引用是否仍可读。
远程备份：配置一个 WebDAV 或 S3 兼容目标，手动运行一次备份，再检查目标目录是否出现完整快照和完成标记。不要把“设置已保存”当成“备份已成功”。
恢复演练：在测试环境或干净实例中恢复一份低风险备份，检查笔记正文、归档、回收站、附件和基本结构。恢复成功前，不要把 Inkstone 当成唯一存档。
更新前保护：每次升级 Inkstone 前先保留最新备份。即使 v0.8.0 的 D1 迁移声明为自动、幂等，也不应跳过备份证据。

第 27—29 天：导出、退出和长期绑定成本

自托管的价值不只是能运行，还包括能退出。Inkstone 的笔记以普通 Markdown 为基础，ZIP 导出和远程备份也强调可读 Markdown 快照，这是它比许多封闭笔记服务更稳的地方。但退出不等于所有体验都无损迁移：文件夹状态、标签、双链、块引用、版本历史、分享链接、搜索索引、AI embeddings、会话、密码和备份凭据都需要分别看待。

退出演练：随机抽取几篇笔记，把导出的 Markdown 放进本地编辑器或另一个知识库工具中打开；检查标题、正文、附件路径和内部链接是否还能理解。
不可迁移清单：列出你不能接受丢失的状态，例如版本历史、公开链接、标签层级、关系图谱或 MCP 授权。如果某项没有明确迁移办法，就不要把它当成长期依赖。
供应商绑定：D1、R2/KV、Durable Objects、Workers AI 和 Workers 运行时都属于 Cloudflare 生态。接受这一点后再长期使用；如果你的组织要求平台可替换，Inkstone 可能只适合作为个人工具或边缘试点。

第 30 天：Go / Fix / Stop 决策

最后一天不要再加功能，专门做决策。把 30 天证据按“必须通过、可修复、不可接受”三类整理，再决定是否迁入正式资料。

Go：继续使用。条件是部署边界清楚，owner 密码和 Cloudflare 账号安全可控，日常写作顺畅，关键词搜索可用，离线和冲突结果可解释，导出可读，远程备份和至少一次恢复演练通过。AI 搜索、MCP、公开分享可以继续保持可选。
Fix：修完再试。适用于功能大体满意，但某个证据缺失：例如没有恢复演练、附件导出不完整、移动端体验不适合、分享撤销未验证、AI 索引边界不清楚。先补齐问题，再重新跑相关 3—7 天验收。
Stop：停止迁入核心资料。适用于无法接受 owner 密码丢失处理方式、不能承担 Cloudflare 账户和备份责任、离线冲突存在静默覆盖风险、导出不可读、恢复失败，或组织要求不允许绑定 Cloudflare 平台能力。

一页版验收表

我能说明 D1、R2/KV、OAUTH_KV、IndexedDB、Durable Objects、Workers AI、WebDAV/S3 分别保存什么。
我保存了部署、版本、存储模式、域名和备份目标的证据。
owner 密码已进入密码管理器，并且我知道密码丢失不能绕过重置。
公开分享、撤销、访问密码和有效期已经用无痕窗口测过。
至少一次离线编辑和一次双设备冲突测试有明确结果。
关键词搜索可以找回大多数真实笔记；AI 搜索即使关闭也不影响核心流程。
JSON、ZIP 或 Markdown 导出已经打开检查，附件和归档/回收站内容在备份恢复中被验证。
升级前备份流程明确，退出时能拿到可读 Markdown。
最终决策已写成 Go、Fix 或 Stop，而不是“先用着看”。

如果这张表大部分无法打勾，问题不一定在 Inkstone，而是在你还没有准备好承担自托管笔记系统的所有者责任。Inkstone 的优势是把数据和运行边界放回个人 Cloudflare 账户里；30 天验收的目的，是确认你愿不愿意、也能不能长期负责这些边界。