双库协同规范
定义 Vault（工作台）与 tishici（大脑）的定位边界、内容归属、知识流转流程、AI 协同职责与例外处理规则。
1. 目的与适用范围
本规范用于约束以下两类知识库的协同方式：
- Vault：Obsidian 私有工作文档库，用于承载项目交付、客户沟通、供应商管理及项目过程资料。
- tishici：VitePress 静态站型个人知识库，用于沉淀可复用知识、方法论、案例拆解、提示词与公开表达内容。
适用对象：
- 自己的日常记录、写作、复盘、提炼
- AI 在两个知识库中的辅助行为
- 项目知识向通用知识的提炼与反向应用
2. 核心原则
2.1 一句话原则
Vault 管"做事"，tishici 管"长本事"。
2.2 五条基本原则
- 先判敏感性，再判复用性。 只要存在明显商业敏感、客户敏感、内部敏感，默认留在 Vault。
- 项目事实归 Vault，通用方法归 tishici。 项目发生了什么、为什么这样做、受什么约束，属于 Vault；可复用的方法、框架、模板、原则，属于 tishici。
- 混合内容必须拆分，不整体搬运。 一篇文档中同时存在项目上下文与通用结论时，应拆成"项目实例"与"抽象方法"两部分处理。
- 单一事实源（Source of Truth）。 通用方法论只保留一份权威版本在 tishici；项目特定事实只保留一份权威版本在 Vault。
- AI 负责辅助，不负责越权。 AI 可以发现、建议、提炼、起草、校验、提醒；AI 不可擅自发布、删除、外发、替用户做公开风险判断。
3. 双库定位
| 维度 | Vault | tishici |
|---|---|---|
| 隐喻 | 工作台 | 大脑 |
| 核心职责 | 项目交付、客户沟通、供应商管理、过程留痕 | 知识沉淀、方法论提炼、复用资产、对外表达 |
| 受众 | 仅自己 | 自己 + 对外可读 |
| 生命周期 | 随项目起止，有归档节点 | 持续积累，长期演化 |
| 主要内容 | 方案、会议纪要、报价、厂家资料、项目决策 | 提示词、Playbook、案例拆解、速查表、原则 |
| 风险等级 | 高，默认私有 | 中到低，默认可被阅读 |
4. 内容归属规则
4.1 四问判定法
新增内容或整理旧内容时，按以下顺序判断：
- 是否包含敏感信息？ 包含客户名、项目名、金额、合同、内部人员、未公开架构等 → 默认 Vault
- 是否强依赖具体项目上下文？ 离开具体项目就不成立 → Vault
- 是否可复用于两个及以上场景？ 能抽象成方法、清单、原则、模板 → 候选进入 tishici
- 是否适合公开表达？ 即使可复用，若无法安全脱敏 → 保留在 Vault
判定结论：
- 满足 1 或 2 → Vault
- 不满足 1/2，且满足 3/4 → tishici
- 同时包含项目事实与通用结论 → 拆分处理
- 无法判断 → 先留 Vault，标记为"待提炼"
4.2 内容归属矩阵
| 内容类型 | 归属 | 处理规则 |
|---|---|---|
| 项目方案 / PRD | Vault | 含客户上下文、项目约束、交付目标 |
| 会议纪要 | Vault | 原始事实记录，不外流 |
| 报价 / 合同 / 商务沟通 | Vault | 商业敏感 |
| 厂家原始资料 | Vault | 商业敏感、时效性强 |
| 项目特定技术决策 | Vault | 如"某项目为何选 Spring Boot" |
| 通用技术选型方法论 | tishici | 如"前端框架选型指南" |
| 提示词模板 | tishici | 不含项目字段时为通用资产 |
| 项目中填充后的提示词实例 | Vault | 若含客户/业务上下文 |
| 案例拆解 | tishici | 公开产品、公开资料的分析 |
| Playbook / 方法论 | tishici | 通用流程、框架、策略 |
| 命令速查 / 工具用法 | tishici | 高复用、低敏感 |
| 语录 / 原则 | tishici | 长期沉淀 |
| 调研报告 | 视情况 | 项目专属调研 → Vault；通用赛道研究 → tishici |
| 踩坑记录 | 拆分 | 项目过程留 Vault；抽象教训进 tishici |
| 白皮书 / 技术综述 | 拆分 | 通用认知进 tishici；项目约束留 Vault |
| 模板 / 清单 | tishici 为准 | 项目实例版在 Vault，模板母版在 tishici |
4.3 最小流转单元
知识流转的最小单位不必须是一整篇文档，也可以是：
- 一个章节或一段总结
- 一个决策条目或一张对比表
- 一套检查清单或一个方法框架
- 一个案例中的"可复用结论"
原则：提炼"知识块"，而不是机械搬整篇。
5. Source of Truth 规则
5.1 通用知识
- 通用方法论、模板、清单、原则 → tishici 为唯一事实源
- Vault 中若需使用，应保留：简要摘要 + tishici 链接 + 本项目的适配说明
5.2 项目知识
- 项目背景、约束、沟通记录、决策理由 → Vault 为唯一事实源
- tishici 不记录可识别的项目细节
5.3 项目偏离通用方法
若某项目因特殊约束偏离了 tishici 中的方法论：
- 不视为冲突
- 在 Vault 中记录"偏离说明"：偏离了哪条通用方法、为什么偏离、影响评估、是否可反向修订 tishici
5.4 重复内容处理
若两边都存在"通用版"内容：
- 以 tishici 为准
- Vault 删除重复展开内容，改为"摘要 + 引用"
- 若 Vault 版本含项目上下文，则只保留项目相关部分
6. 知识流转机制
6.1 流转方向
正向提炼：Vault（项目实践）──提炼──→ tishici（可复用知识）
反向应用：tishici（方法论）──引用/适配──→ Vault（项目决策）
同步修订：tishici 方法论更新 → 检查受影响的 Vault 项目文档6.2 流转触发条件
出现以下任一信号，即进入"候选评估"：
| 触发信号 | 示例 |
|---|---|
| 重复出现（2 次以上） | 连续两个项目都写了"无人机巡检系统架构方案" |
| 项目复盘 | 产出了可脱离项目复用的结论 |
| 技术决策沉淀 | 某类决策标准已稳定 |
| 厂家评估 | 形成可复用的评估框架 |
| 踩坑经验 | 教训具有跨项目价值 |
| 模板固化 | 某结构、提纲、清单反复被使用 |
| 方法更新 | tishici 中既有方法被新项目修正 |
| 引用频繁 | 同一份旧笔记被多个项目引用 |
建议阈值
- 重复 2 次以上：可进入候选
- 重复 3 次以上：应优先提炼
- 形成稳定步骤/判断框架：即使只出现 1 次，也可提炼
6.3 候选内容状态
| 状态 | 含义 |
|---|---|
| 原始 | 仅存在于原始项目记录中 |
| 候选 | 已识别有复用价值，待确认 |
| 提炼中 | 正在脱敏、抽象、结构化 |
| 已入库 | 已进入 tishici |
| 已引用 | Vault 中已替换为引用说明 |
| 已归档 | 内容失效或被新版本替代 |
6.4 正向流转操作流程（Vault → tishici）
Step 1：识别
由 AI 或用户识别候选内容。输出至少包含：来源文档、可复用点、建议归类、脱敏风险。
Step 2：预判
按"四问判定法"判断归属：
- 敏感且不可安全剥离 → 留在 Vault
- 可拆分 → 进入拆分
- 可公开表达 → 进入提炼
Step 3：确认
必须由用户确认：是否流转、流转什么粒度、归入 tishici 哪个栏目。
Step 4：提炼
- 脱敏：去标识化、去商业信息、去内部细节
- 抽象：从"这个项目怎么做"变成"这类问题怎么做"
- 结构化：整理为清单、步骤、原则、案例、速查表等
- 补边界：写清适用条件、不适用场景、例外情况
Step 5：入库
在 tishici 中完成：新建或更新页面 → 归入正确分类 → 更新 sidebar + 索引 → 处理与旧页面的重复关系。
Step 6：回链
在 Vault 中：保留原始项目事实 → 将通用展开内容替换为"摘要 + 指向 tishici 的引用" → 必要时添加"本项目适配说明"。
Step 7：校验
- 是否仍可通过细节反推出客户/项目
- 是否与现有 tishici 页面重复
- 是否需要修订旧方法论
- 是否存在失效引用
6.5 反向应用流程（tishici → Vault）
当在 Vault 中进行方案、调研、复盘、决策时：
- 先搜索 tishici 是否已有相关方法、模板、清单
- 若有，优先引用，不重复发明
- 若项目有特殊约束，记录"适配说明"或"偏离说明"
- 若实践结果修正了原方法，则标记为新的候选沉淀
原则：项目不是重新造知识，而是调用、适配、验证知识。
7. 脱敏规则
7.1 直接标识信息
必须去除：客户名称、项目名称、供应商名称、内部人员姓名与联系方式、合同编号、报价金额、商务条款。
7.2 间接标识信息
需要评估并处理：可反推客户身份的地域/时间/规模/场景组合、私有网络结构/域名/仓库名、内部截图、未公开功能与路线图、过于独特的系统组合。
7.3 脱敏后的表达方式
- 用"某客户 / 某项目 / 某类场景"替代具体名称
- 用"中大型部署 / 高并发场景"替代具体规模
- 用"某次选型评估"替代具体招投标背景
- 用"成本受限 / 交付周期紧"替代具体金额与商务条款
7.4 脱敏失败处理
若内容一旦抽掉项目细节就失去价值，或仍可能被反推：
- 不进入 tishici
- 保留在 Vault
- 如有必要，仅提炼更高层的抽象原则
8. AI 协同职责
8.1 在 Vault 中的职责
写作前：
- 先检索 tishici 是否已有可复用内容
- 提醒用户可直接引用的方法、模板、清单
写作中：
- 识别正在生成的内容中，哪些属于项目事实、通用知识、混合内容
- 对混合内容提出拆分建议
写作后：
- 评估是否产出了可沉淀知识
- 输出"候选流转建议"
决策更新后：
- 判断新决策是否具有普适性
- 若可能修正旧方法，提醒用户回看 tishici
8.2 在 tishici 中的职责
入库前：
- 检查是否与既有内容重复
- 检查是否仍残留项目敏感信息
- 协助选择最合适的内容类型与栏目
更新中：
- 若方法论被改写，提醒检查哪些 Vault 项目正在引用它
发布前：
- 做一次公开风险审查：是否有可识别信息、是否把项目结论误写成通用规律
8.3 AI 的权限边界
AI 可以： 检索、对比、归类、提炼、起草、改写、查重、提醒同步。
AI 不可以在未经确认时：
- 擅自将 Vault 内容发布到 tishici
- 擅自删除 Vault 原始记录
- 擅自判定某内容"可公开"
- 擅自用通用结论覆盖项目事实
- 擅自移动文件或改写知识库结构
8.4 AI 标准提醒格式
当 AI 发现候选沉淀内容时，统一用以下格式：
💡 流转建议
- 来源：[Vault 文档路径 / 章节]
- 可沉淀点：[值得抽象的知识]
- 建议类型：Playbook / 案例 / 速查 / 提示词 / 白皮书
- 脱敏风险：低 / 中 / 高
- 建议动作：暂留 Vault / 提炼入 tishici / 拆分后再流转9. 冲突消解与例外处理
| 场景 | 处理方式 |
|---|---|
| tishici 有通用版，Vault 有项目特定版 | 正常状态，无需处理 |
| 两边都有通用版 | 以 tishici 为准，Vault 改摘要 + 引用 |
| Vault 有内容但 tishici 缺失 | 进入候选评估 |
| tishici 方法论更新，Vault 引用过时 | AI 提醒检查受影响项目 |
| 项目必须偏离通用方法 | 在 Vault 记录偏离说明，不覆盖 tishici |
| 内容可复用但无法安全脱敏 | 保留在 Vault，仅提炼更高层原则 |
| 同一主题在 tishici 出现多篇重叠 | 合并为一篇主文，其余改索引或归档 |
| 旧方法已失效 | 在 tishici 标记过时，检查 Vault 引用 |
10. 维护机制
10.1 例行检查节点
| 时机 | 检查内容 |
|---|---|
| 每个项目收尾时 | 复盘可提炼知识 |
| 每周回顾时 | 检查"候选"状态内容 |
| 每次重大方法论更新时 | 检查 Vault 是否有受影响引用 |
| 每月一次 | 做查重、过时内容、失效引用检查 |
10.2 关注清单
- 是否有通用内容长期滞留在 Vault
- 是否有 tishici 文章缺乏边界条件
- 是否有 Vault 引用了过时方法
- 是否有旧页面重复表达同一知识
- 是否有内容已经不适合公开
11. 执行口径
当归属不明确时，统一按以下默认策略执行：
- 默认保守 — 先留 Vault
- 先拆分再判断 — 不要整篇搬运
- 先确认再发布 — AI 不替用户做最终公开决策
- 先保留原始事实 — Vault 记录不因提炼而消失
- 先维护单一事实源 — 避免两边长期双写
附录：现有待处理项
| 内容 | Vault 位置 | tishici 位置 | 建议操作 |
|---|---|---|---|
| BG 端技术选型白皮书 | BG 端系统技术选型白皮书.md | playbook/methodology/tech-stack | 通用部分合并到 tishici，Vault 保留项目约束 |
| C 端技术选型白皮书 | C 端系统技术选型白皮书.md | playbook/methodology/tech-stack | 同上 |
| SaaS 私有化方案 | SAAS平台私有化.md | 无 | 评估是否提炼为通用 Playbook |