完整蓝图不等于同阶段交付

更新于 2026-06-25

**用户要「完整方案」时，不要把完整方案砍成 MVP，也不要把完整蓝图理解成「所有东西同一阶段交付」；正确形态是「全量架构 + 分阶段落地 + 风险门控」。** 把「要做什么」（全量）和「什么时候做」（阶段）分成两个维度，才能既不漏系统、又不承诺一次交完。

完整方案至少要覆盖的六块

只写技术结构不算完整方案，还缺：

  1. 产品版图 —— 2.0 到底包含哪些用户能力（笔记、剪藏、订阅、搜索、AI 回顾、标签/知识库、多端同步、浏览器扩展、账号/订阅/支付、Admin、导入 1.x 数据）
  2. 数据权威模型 —— 云端 PostgreSQL 是不是 source of truth？本地是缓存还是可离线编辑的真相？原 vault 文件还保留吗？能否导出完整本地知识库？见 数据权威模型要先于同步与迁移确定
  3. 同步协议 —— 版本字段、sync cursor、pull/push/conflict、tombstone、改名与附件规则、两端跑同一组测试用例
  4. 迁移方案 —— 2.0 不能无视 1.x：扫描本地 vault、导入 Markdown/HTML/clips/feeds、绑定本地路径与云端 ID、失败回滚、可否选择「不上传只本地用」
  5. 各端完整范围 —— 例如 Apple 端不只是「调 API」，而是完整客户端：SwiftUI、SwiftData、SyncEngine、Keychain、Share Extension、Spotlight、Menu Bar、全局快捷键、推送、自适应布局、打包签名审核
  6. 后端完整范围 —— 把散落在 Web API / packages / agent 里的职责收拢成明确的后端边界

常见失误

把「完整方案」和「分阶段落地」对立起来，于是要么交一份被砍到只剩骨架的 MVP，要么承诺一次性把所有端和系统做完。架构上可以全量，交付上必须分阶段。

相关