GBrain MECE 自动整理指南
MECE = Mutually Exclusive, Collectively Exhaustive（相互独立，完全穷尽）
GBrain 的核心原则：每一段知识都有唯一的"家"，不会重复，不会遗漏。
一、什么是 MECE 整理？
1.1 传统知识管理的失败
传统笔记工具的问题：
- 同一个事实存在于多个地方，版本不一致
- 不知道哪个是最新的
- 维护成本高，人类会忘记更新
- 搜索时得到重复/冲突的结果
1.2 GBrain 的解决方案
MECE 目录结构：
- 每一段知识通过决策树，落到唯一的目录
- 每个目录有明确的
README.md说明"什么放这里，什么不放" - 顶层有
RESOLVER.md主决策树 - AI agent 自动维护，不需要人类记住规则
关键洞察：知识管理失败 30 年是因为维护成本落在人类身上。AI agent 不会厌倦、不会忘记、一次可以处理 50 个文件。大脑保持活跃是因为维护成本接近零。
二、核心三原则
原则 1：每段知识有唯一"家"
决策流程：
用户输入/信号 → 读 RESOLVER.md → 确定目录 → 检查是否重复 → 创建/更新页面
重要细节：MECE 适用于目录，不适用于现实。
- 一个人可以有多个角色（创始人、朋友、投资人）
- 但页面只有一个（
people/jane-doe.md） - 通过交叉引用展现多面性
- 避免重复页面，但不限制关系
原则 2：Compiled Truth + Timeline（双层页面）
每个页面有两层，用 --- 分隔：
线上方 - Compiled Truth（编译后的真相）
- 执行摘要（一段话）
- State 字段（当前状态）
- Open Threads（待办事项，解决后删除）
- See Also（交叉引用）
- 每次更新重写
线下方 - Timeline（时间线）
- 追加不修改
- 逆时序证据日志
- 每条记录：日期 + 来源 + 发生了什么
- 待办解决后移到此处
杀手级特性：合成是预计算的。不同于 RAG 每次查询重新推导，大脑已经完成了工作。交叉引用已存在，矛盾已标记。
原则 3：每次信号触发丰富
信号来源 → 丰富管道 → 更新相关实体页面
- 会议 → 更新参与者页面
- 邮件 → 更新联系人页面
- 推文 → 更新人物/公司页面
- 日历 → 更新相关实体页面
关键：你不需要记住更新页面。系统 wired correctly 时，每次接触实体都会自动丰富。
三、目录结构
brain/
├── RESOLVER.md — 主决策树（agent 创建任何页面前先读）
├── schema.md — 页面规范、模板、工作流
├── index.md — 内容目录（1 行摘要）
├── log.md — 所有导入/更新的时序记录
│
├── people/ — 每个人一页
│ ├── README.md — resolver：什么放这里，什么不放
│ └── .raw/ — 原始 API 响应侧车文件
│
├── companies/ — 每个组织一页
├── deals/ — 交易/投资（有条款和决策）
├── meetings/ — 具体事件记录（含转录）
├── projects/ — 正在构建（有仓库/规范/团队）
├── ideas/ — 未实现的可能性
├── concepts/ — 思维模型和框架（可以教的）
├── writing/ — 散文产物（文章、哲学、草稿）
├── programs/ — 主要工作流（宏观，非微观）
├── org/ — 机构战略和运营
├── civic/ — 政治格局、政策、政府
├── media/ — 公共叙事、内容运营、社交监控
├── personal/ — 私人笔记、健康、自我反思
├── household/ — 家庭运营、房产、后勤
├── hiring/ — 候选人管道和评估
├── sources/ — 原始数据导入和存档快照
├── prompts/ — 可复用 LLM 提示词库
├── inbox/ — 未分类的快速捕获（临时）
└── archive/ — 死页面，历史记录
不变规则：
- 每个目录一个知识领域
- 每个实体一个文件
- 每个目录有 resolver
RESOLVER.md是主决策树，保证 MECE 归档
四、自动整理机制
4.1 Resolver（解析器）协议
创建任何页面前，agent 必须：
1. 读 RESOLVER.md — 确定应该去哪个目录
2. 搜索现有页面 — 避免重复（精确 + 模糊搜索）
3. 检查 aliases — 可能是同一个人的不同名字
4. 如果匹配 → 更新现有页面（添加新 alias）
5. 如果不匹配 → 创建新页面
4.2 实体去重协议
创建页面前：
1. 精确 + 模糊搜索名字
2. 搜索 aliases: grep -rl "NAME_VARIANT" /brain/people/
3. 检查 .raw/ 侧车文件中的邮箱/社交账号
4. 匹配 → 更新现有页面（添加新 alias）
5. 不匹配 → 创建新页面
发现重复时：
1. 选更完整的页面作为幸存者
2. 合并 timeline 条目（按时间排序）
3. 合并 aliases
4. 更新所有交叉引用
5. 删除重复页面
6. commit: merge: [duplicate] into [survivor]
4.3 关键区分规则
| 混淆点 | 区分标准 |
|---|---|
| Concept vs Idea | 能当框架教？→ concept；能构建？→ idea |
| Concept vs Personal | 会公开分享？→ concept；私人反思？→ personal |
| Idea vs Project | 有人在做？→ project；没人做？→ idea |
| Writing vs Concepts | 精炼框架？→ concept；发展性散文？→ writing |
| Writing vs Media | 文章本身？→ writing；内容基础设施？→ media |
| Person vs Company | 关于人？→ people/；关于组织？→ companies/ |
| Household vs Personal | PA 能执行？→ household；私人反思？→ personal |
如果都不符合 → 放入 inbox/，标记为 schema 需要演进
五、页面结构模板
人物页面示例
# Jane Doe
> 执行摘要：她是谁，为什么重要，与她互动需要了解的关键信息。
## State
- **Role**: 现任职位
- **Company**: 现任公司
- **Relationship**: 与你的关系（朋友、同事、投资人等）
- **Key Context**: 2-4 条当前最重要的事
## What They Believe
世界观、立场、第一性原理。每条声明必须标注来源和类型：
- [信念] — 观察自：[推文/会议/文章，日期]
- [信念] — 自述：[采访/简介，日期]
- [信念] — 推断：[N 次互动中的模式，置信度：高/中/低]
## What They're Building
当前项目、近期成果、产品方向
## What Motivates Them
野心驱动因素、职业轨迹、什么让他们起床
---
## Timeline
### 2026-05-27
- [Source: meeting with Alice] 讨论了 Q3 路线图，她承诺 6 月 1 日前提供预算
### 2026-04-15
- [Source: Twitter @janedoe] 宣布晋升为 VP Engineering
### 2026-03-01
- [Source: LinkedIn] 加入 Acme Corp
公司页面示例
# Acme Corp
> 执行摘要：公司是做什么的，为什么重要，当前状态。
## State
- **Stage**: A 轮 / B 轮 / 盈利 / 等
- **MRR**: 月收入（带来源和日期）
- **Team Size**: 团队规模
- **Key Metrics**: 关键指标
## What They're Building
产品方向、近期发布、技术栈
## Key People
- [[jane-doe]] - CEO
- [[bob-smith]] - CTO
## Funding History
- 2026-05: A 轮 $2M（领投：Widget VC）
- 2025-03: Seed $500K
---
## Timeline
### 2026-05-20
- [Source: deal/acme-seed] 完成 A 轮融资
### 2026-04-15
- [Source: company blog] 发布 2.0 版本
六、自动维护工作流
6.1 Cron Jobs 自主维护
| 任务 | 频率 | 动作 |
|---|---|---|
| 大脑健康检查 | 每日 | gbrain doctor |
| 矛盾检测 | 每日 | 扫描 contradictions |
| 孤儿页面清理 | 每周 | 查找无入链页面 |
| 重复页面合并 | 每周 | 相似名字/公司审计 |
| index.md 重建 | 每日/按需 | 扫描目录树重建 |
| log.md 更新 | 每次 ingest | 追加记录 |
| 社交雷达扫描 | 每日 | 监测提及 |
| 邮件监控 | 每日 | 更新联系人 |
| 联系人同步 | 每周 | 更新角色/公司 |
6.2 典型自主大脑的一天
早上 8:00
- 晨间简报 cron 运行
- 读取昨晚的会议转录
- 更新所有参与者页面
- 生成今日简报
上午 10:00
- 用户与 agent 对话
- 提及新公司 "Widget AI"
- enrich 技能触发
- 创建/更新 Widget AI 页面
- 添加交叉引用
下午 2:00
- 社交雷达 cron 运行
- 发现 Jane Doe 的新推文
- 更新 Jane 的页面
- 提取新信念/观点
晚上 10:00
- 邮件监控 cron 运行
- 发现新联系人
- 创建联系人页面（或更新现有）
- 同步到 CRM
凌晨 2:00
- 维护 cron 运行
- 检测矛盾
- 清理孤儿页面
- 重建 index.md
核心洞察：cron 任务不是各自独立工作，而是喂养丰富管道，丰富管道喂养每个未来的 cron 任务。整个系统是飞轮。
七、数据库 + Markdown 架构
四层数据库原语
1. 实体注册表
- 规范 ID、所有别名、所有外部 ID（LinkedIn、Twitter、邮箱、电话）
- "这是同一个人吗？"的单一事实来源
- 合并实体 = 数据库操作（指向同一规范记录）
2. 事件分类账
- 每个信号 = 不可变事件（参加会议、收到邮件、发布推文、完成丰富）
- 事件有来源：来源、时间戳、置信度、原始负载引用
- Timeline 从分类账生成，不会丢失事件
3. 事实存储
- 带来源的断言（"Jane Doe 是 Acme 的 CTO"，来源=crustdata，置信度=高）
- 来源冲突时，两个事实并存（可见冲突）
- 线上方从事实存储生成
4. 关系图
- 实体间的类型化边（Person→Company: CTO, started: 2024-01）
- 支持图查询（"我认识谁在这家公司？"）
为什么重要
- 身份解析 = 数据库操作（合并实体 ID），不是文件合并
- 矛盾是结构性的（两个事实不同值），不是文本的（希望 LLM 发现差异）
- 并发解决了 — 事件追加，事实 upsert，Markdown 重建
- 图查询有效 — 遍历而不是 grep
八、文件层规范
5 条铁律
-
用 frontmatter 存储结构化元数据
- 角色、公司、阶段、分数、标签等可查询内容放 frontmatter
- 不要埋在散文中
-
用
.raw/存储来源- 保存每个 API 响应，带来源和时间戳
- 映射到事实存储的 provenance
-
把 timeline 当作事件流
- 有日期、有来源、追加不修改
- 映射到事件分类账
-
保持编译真相与证据分离
- 线上方 = 合成
- 线下方 = 证据
- 合成是生成视图，证据是可查询记录
-
一致使用规范 slugs
- 每个交叉引用使用文件名 slug
- 这些是实体注册表中的实体 ID
九、实践建议
9.1 开始使用
# 1. 初始化大脑
gbrain init --pglite
# 2. 安装技能包
gbrain skillpack scaffold --all
# 3. 导入现有知识
gbrain import ~/my-knowledge
# 4. 验证安装
gbrain doctor
9.2 日常使用
# 查询知识
gbrain query "Alice 是做什么的？"
# 查找关系
gbrain graph-query people/alice --depth 2
# 健康检查
gbrain doctor --fast
# 查找孤儿页面
gbrain orphans --json
9.3 维护命令
# 重建索引
gbrain sync --reembed
# 修复损坏的数据
gbrain repair-jsonb --dry-run
# 查看 schema
gbrain schema show --json
# 迁移
gbrain upgrade
十、常见问题
Q: MECE 太僵化，现实是模糊的怎么办？
A: MECE 适用于目录，不适用于现实。
- 一个人可以有多个角色，但页面只有一个
- 通过交叉引用展现多面性
- 如果确实无法分类，放
inbox/，标记 schema 需要演进
Q: 如何避免重复页面？
A: 创建页面前：
- 读 RESOLVER.md
- 搜索现有页面（精确 + 模糊）
- 检查 aliases
- 只有确定没有才创建
Q: Cron 任务如何设置？
A: 使用 gbrain autopilot --install 自动安装，或手动配置：
# 每日运行
0 8 * * * gbrain doctor --fast
0 9 * * * gbrain sync --watch
# 每周运行
0 10 * * 1 gbrain doctor --json
Q: 如何处理冲突信息？
A:
- 用户直接声明 = 最高优先级
- 编译真相 = 次高
- Timeline 条目 = 证据
- 外部来源 = 最低
冲突时，注明两个来源，不要静默选择。
十一、相关文档
文档来源：基于 GBrain 官方文档 GBRAIN_RECOMMENDED_SCHEMA.md 整理