MOSSPersonal Context Hub

Phase 0

Phase 0 框架图

Phase 0 框架图

本文承接 整体框架蓝图，用于沉淀 Phase 0 的框架图。当前已完成总体框架图、顶层域图、对象关系图、数据流图、权限与敏感度分级图、阶段路线图的 v1。

阅读顺序

建议按以下顺序阅读：

  1. 总体框架图：先看 MOSS 的整体层次。
  2. 顶层域图：再看 6 个顶层域如何收敛信息范围。
  3. 对象关系图：再看核心对象如何连接。
  4. 数据流图：再看信息如何从输入流向反馈和输出。
  5. 权限与敏感度分级图：再看哪些数据如何被约束。
  6. 阶段路线图：最后看 Phase 0 到 Phase 5 的推进顺序。

图例：实线与虚线

Mermaid 图里的线型语义统一如下：

  • 实线箭头 -->：表示主流程、主结构或直接归属关系。
    • 在总体框架图和数据流图里，实线表示数据处理主链路。
    • 在顶层域图里，实线表示 MOSS 由 5 个生活/认知域组成。
    • 在对象关系图里，实线表示对象之间的直接业务关系。
  • 虚线箭头 -. ... .->：表示辅助关系、覆盖关系、约束关系、修正关系或多归属关系。
    • 覆盖：顶层域用于解释标准化对象层里的对象归属，不代表数据真实流动。
    • 约束：Governance 或 Rule 对其他层、对象或域施加规则、权限、审计和自动化边界。
    • 修正 / 校准：Feedback 对对象、主题、项目、信源质量或理解结果产生反向修正。

简单说：实线表示“系统怎么走 / 由什么组成”，虚线表示“如何解释 / 如何约束 / 如何修正”。

一、总体框架图

MOSS 总体框架图 v1

这张图回答一个问题：MOSS 作为 Personal Context Hub，整体由哪些层组成，6 个顶层域如何覆盖系统，Governance 如何作为横切控制域约束其他层。

flowchart TB
  subgraph Domains["6 个顶层域"]
    K["Knowledge<br/>内容 / 订阅 / 学习 / 输出"]
    A["Action<br/>任务 / 日程 / 承诺 / 计划"]
    C["Context<br/>项目 / 人 / 地点 / 事件 / 消息"]
    S["Self<br/>目标 / 偏好 / 健康 / 情绪 / 人生事件"]
    AS["Asset<br/>理财 / 消费 / 实物 / 账号 / 证件"]
    G["Governance<br/>隐私 / 规则 / 权限 / 审计 / 自动化边界"]
  end

  subgraph Sources["数据源层"]
    S1["Notion / Obsidian"]
    S2["收藏 / RSS / Newsletter"]
    S3["日程 / 任务 / 会议"]
    S4["图片 / 文件 / 票据"]
    S5["理财 / 账号 / 证件"]
    S6["关系 / 项目 / 决策 / 日记"]
  end

  subgraph Pipeline["系统处理链路"]
    P1["采集层<br/>同步 / 导入 / OCR / API / 手动添加"]
    P2["原始归档层<br/>原文 / Markdown / 图片 / PDF / 链接快照"]
    P3["标准化对象层<br/>Content / Source / Topic / Project / Decision / Goal / Event / Task / Asset / Rule / Feedback"]
    P4["理解层<br/>摘要 / 标签 / 主题 / 实体 / 关联候选 / 重要性评分"]
    P5["索引层<br/>全文搜索 / 向量索引 / 知识图谱 / 时间线"]
    P6["展示与查询层<br/>Dashboard / Search / Ask / Topic View / Project View"]
    P7["反馈层<br/>有用 / 没用 / 稍后看 / 归档 / 关联项目 / 人工修正"]
    P8["行动层<br/>提醒 / 建议 / 计划草案 / 自动整理 / 低风险执行"]
  end

  Sources --> P1 --> P2 --> P3 --> P4 --> P5 --> P6 --> P7 --> P8
  P7 --> P3
  P7 --> P4

  K -.覆盖.-> P3
  A -.覆盖.-> P3
  C -.覆盖.-> P3
  S -.覆盖.-> P3
  AS -.覆盖.-> P3

  G -.约束.-> Sources
  G -.约束.-> P1
  G -.约束.-> P2
  G -.约束.-> P4
  G -.约束.-> P6
  G -.约束.-> P8

总体框架关键判断

  1. 6 个顶层域是分类坐标，不是数据库表。 Knowledge / Action / Context / Self / Asset / Governance 用来判断信息归属和系统边界。

  2. Governance 是横切控制域。 它约束采集、归档、AI 理解、查询和行动，而不是普通内容分类。

  3. 反馈层是系统变聪明的关键。 用户反馈会反向修正对象、主题、项目、信源质量和理解结果。

  4. Phase 0 不实现这些层。 这张图是框架图，不是实现计划。Phase 0 不接入真实数据源，不做数据库、搜索、AI 摘要或 Dashboard。

二、顶层域图

顶层域图 v1

这张图只表达骨架：MOSS 由 5 个生活/认知域组成，Governance 作为横切控制域约束其他域。具体定义和示例放在图下方表格里。

flowchart TB
  M["MOSS"]

  subgraph LifeDomains["5 个生活 / 认知域"]
    K["Knowledge"]
    A["Action"]
    C["Context"]
    S["Self"]
    AS["Asset"]
  end

  G["Governance"]

  M --> K
  M --> A
  M --> C
  M --> S
  M --> AS

  G -.约束.-> K
  G -.约束.-> A
  G -.约束.-> C
  G -.约束.-> S
  G -.约束.-> AS

顶层域说明表

顶层域 回答的问题 覆盖内容
Knowledge 我知道什么、学什么、输入和输出了什么 内容、订阅、学习、输出
Action 我要做什么、推进什么、承诺什么 任务、日程、承诺、计划
Context 和谁有关、在哪里、处于什么关系和环境 项目、人、地点、事件、消息
Self 我是谁、状态如何、目标和偏好是什么 目标、偏好、健康、情绪、人生事件
Asset 我拥有什么、依赖什么资源、有哪些权益 理财、消费、实物、账号、证件
Governance 什么有风险、什么要保护、什么规则不能破 隐私、规则、权限、审计、自动化边界

多归属示例

示例 归属
合同纠纷 Governance / Action / Context
健康体检 Self / Governance
投资笔记 Knowledge / Asset
旅行计划 Action / Context / Asset

顶层域使用规则

  • 顶层域不是单选分类；一条信息可以同时归入多个顶层域。
  • 新增信息域先尝试归入这 6 个顶层域。
  • 只有确实无法归入这 6 个顶层域时，才考虑新增顶层域。
  • Governance 不回答“这是什么内容”，而回答“能不能被采集、进入 AI、被搜索、被自动化，是否需要审计和确认”。

三、对象关系图

对象关系图 v1

这张图回答一个问题：MOSS 的核心对象之间如何连接。它只画 Phase 0 需要确认的主干对象，不把所有长期对象都塞进来。

flowchart LR
  subgraph Input["输入与来源"]
    Source["Source<br/>信源 / 工具 / 输入来源"]
    Person["Person<br/>作者 / 联系人 / 参与者"]
  end

  subgraph Knowledge["Knowledge"]
    Content["Content<br/>文章 / 笔记 / 收藏 / 订阅内容"]
    Topic["Topic<br/>主题 / 领域 / 概念"]
  end

  subgraph Context["Context"]
    Project["Project<br/>项目 / 研究主题 / 长期事项"]
    Event["Event<br/>日程 / 会议 / 时间块"]
  end

  subgraph Action["Action"]
    Task["Task<br/>任务 / 计划 / 行动项"]
    Commitment["Commitment<br/>承诺 / 义务 / 责任关系"]
  end

  subgraph SelfAsset["Self / Asset"]
    Goal["Goal<br/>长期目标 / 阶段目标"]
    Decision["Decision<br/>判断 / 选择 / 依据"]
    Asset["Asset<br/>预算 / 持仓 / 财务目标"]
  end

  subgraph GovernanceDomain["Governance"]
    Rule["Rule<br/>原则 / 权限 / 自动化边界"]
    Feedback["Feedback<br/>有用 / 没用 / 修正 / 归档"]
  end

  Source --> Content
  Person --> Content
  Person --> Project
  Person --> Event

  Content --> Topic
  Content --> Project
  Content --> Decision
  Content --> Task

  Project --> Goal
  Project --> Task
  Project --> Event

  Event --> Task
  Task --> Commitment

  Decision --> Goal
  Decision --> Project
  Asset --> Goal

  Feedback -.修正.-> Content
  Feedback -.修正.-> Topic
  Feedback -.修正.-> Project
  Feedback -.校准.-> Source

  Rule -.约束.-> Source
  Rule -.约束.-> Content
  Rule -.约束.-> Event
  Rule -.约束.-> Task
  Rule -.约束.-> Asset

对象关系说明表

关系 含义
Source -> Content 内容来自某个信源、工具或手动输入。
Content -> Topic 内容被归入主题、领域或概念。
Content -> Project 内容对某个项目、研究主题或长期事项有用。
Content -> Decision 内容影响了某个判断或选择。
Content -> Task 内容可以转成行动项。
Project -> Goal 项目服务于长期目标或阶段目标。
Event -> Task 日程、会议或时间块产生任务。
Task -> Commitment 有些任务背后是对人、组织或自己的承诺。
Decision -> Goal 决策需要对齐目标，也可以改变目标。
Feedback -> Content / Topic / Project / Source 人工反馈用于修正归属、状态、重要性和信源质量。
Rule -> * 规则用于约束采集、处理、查询和自动化。

对象关系设计判断

  • Content 是后续内容中心的入口对象，但不是长期唯一中心。
  • Feedback 是闭环对象，会改变内容状态、主题归属、项目关联、信源质量和后续推荐。
  • Rule 是自动化边界对象，保存什么不能自动做、什么必须确认、什么不能进入 AI。
  • Commitment 和 Task 不同；任务是动作，承诺是责任关系。

四、数据流图

数据流图 v1

这张图回答一个问题：一条信息进入 MOSS 后，如何从原始输入变成可查询、可反馈、可进一步产生建议或计划的对象。

flowchart LR
  D0["数据源<br/>Notion / Obsidian / 收藏 / RSS / 日程 / 图片 / 理财"]
  D1["采集<br/>同步 / 导入 / OCR / API / 手动添加"]
  D2["原始归档<br/>原文 / 文件 / 图片 / PDF / 链接快照"]
  D3["标准化<br/>Content / Event / Task / Asset / Rule 等对象"]
  D4["AI 理解<br/>摘要 / 标签 / 主题 / 实体 / 关联候选"]
  D5["索引<br/>全文索引 / 向量索引 / 图谱 / 时间线"]
  D6["展示与查询<br/>Dashboard / Search / Ask / 视图"]
  D7["人工反馈<br/>有用 / 没用 / 归档 / 修正 / 关联项目"]
  D8["后续输出<br/>提醒 / 建议 / 计划草案 / 低风险自动整理"]

  D0 --> D1 --> D2 --> D3 --> D4 --> D5 --> D6 --> D7 --> D8
  D7 -.修正对象.-> D3
  D7 -.校准理解.-> D4
  D7 -.影响排序.-> D5

数据流说明表

环节 目的 Phase 0 是否实现
数据源 明确长期会接入哪些来源 不实现，只画范围
采集 把外部信息带入系统 不实现
原始归档 保留可回查原始数据 不实现
标准化 把信息变成统一对象 只定义对象，不建库
AI 理解 生成摘要、标签和关联候选 不实现
索引 支持搜索、问答、图谱和时间线 不实现
展示与查询 让用户能看见和查询 不实现
人工反馈 修正系统理解和状态 只定义反馈位置
后续输出 提醒、建议、计划或自动整理 不实现

五、权限与敏感度分级图

权限与敏感度分级图 v1

这张图回答一个问题：不同敏感度的数据，在采集、存储、AI 处理、查询和自动化上应该有什么不同规则。

flowchart TB
  subgraph Levels["敏感度分级"]
    L1["普通<br/>公开文章 / 网页收藏 / 公开资料"]
    L2["中敏<br/>个人笔记 / 项目资料 / 日程 / 任务"]
    L3["高敏<br/>图片 / 聊天记录 / 健康 / 财务"]
    L4["极敏<br/>证件 / 密钥 / 身份信息 / 完整持仓 / 家庭信息"]
  end

  subgraph Controls["处理规则"]
    C1["可默认索引"]
    C2["本地优先<br/>按需进入 AI"]
    C3["本地加密<br/>默认不进云端 AI"]
    C4["只存元信息<br/>强确认 / 强审计"]
  end

  L1 --> C1
  L2 --> C2
  L3 --> C3
  L4 --> C4

  G["Governance<br/>权限 / 审计 / 删除 / 自动化边界"]
  G -.约束.-> C1
  G -.约束.-> C2
  G -.约束.-> C3
  G -.约束.-> C4

权限分级说明表

级别 示例 处理原则
普通 公开文章、网页收藏、公开资料 可默认进入索引和 AI 理解。
中敏 个人笔记、项目资料、日程、任务 本地优先，进入 AI 前应可配置。
高敏 图片、聊天记录、健康、财务 默认本地加密，默认不进云端 AI。
极敏 证件、密钥、身份信息、完整持仓、家庭信息 只存必要元信息，任何处理都需要强确认和审计。

六、阶段路线图

阶段路线图 v1

这张图回答一个问题：MOSS 从框架设计到主动助理的进入顺序是什么。

flowchart LR
  P0["Phase 0<br/>整体框架蓝图<br/>先画系统"]
  P1["Phase 1<br/>统一关注内容中心<br/>能推荐 / 能校准"]
  P2["Phase 2<br/>订阅和信息流<br/>少推噪音"]
  P3["Phase 3<br/>任务、日程和计划<br/>内容连接行动"]
  P4["Phase 4<br/>图片和资产<br/>视觉与财务进入系统"]
  P5["Phase 5<br/>推荐和主动助理<br/>建议与低风险自动化"]

  P0 --> P1 --> P2 --> P3 --> P4 --> P5

阶段路线说明表

阶段 目标 暂不做
Phase 0 画清楚顶层域、对象关系、数据流、权限和阶段边界 不接入真实数据，不做数据库、搜索、AI、Dashboard
Phase 1 统一关注内容中心 不做提醒、日程规划、理财分析或高影响自动执行
Phase 2 订阅和信息流 不追求收更多，重点是信源分层、去重和降噪
Phase 3 任务、日程和计划 不自动改日程，只生成建议和计划草案
Phase 4 图片和资产 不自动交易，不默认处理高敏数据
Phase 5 推荐和主动助理 高影响动作仍需手动确认

七、图清单与状态

图 状态 说明
总体框架图 已完成 v1 解释 MOSS 的整体层次和处理链路。
顶层域图 已完成 v1 解释 6 个顶层域、横切治理和多归属。
对象关系图 已完成 v1 解释核心对象之间的主干关系。
数据流图 已完成 v1 解释信息从输入到反馈和输出的链路。
权限与敏感度分级图 已完成 v1 解释不同敏感度数据的处理规则。
阶段路线图 已完成 v1 解释 Phase 0 到 Phase 5 的推进顺序。