如何为 Web 和手机 AI 对话搭建跨平台 Markdown 上下文知识库？

为 Web 和手机 AI 对话搭建跨平台 Markdown 上下文知识库，关键不是找到一个“能同步文件的云盘”，而是把知识库设计成独立于 ChatGPT、Claude 和 Gemini 的事实来源，再把每个模型当作读写客户端。原生记忆只保存路由提示，详细事实放在按领域拆分的 Markdown 文件中；所有写回先形成结构化变更事务，经过校验、版本控制和读取确认后才成为正式知识。

这种架构解决三个常见问题：不同模型的项目记忆彼此隔离，云盘连接器经常只能读取或会改变文件格式，而“每次对话都自动追加”最终会把临时假设、过期决定和重复内容混在一起。跨平台能力来自统一存储与标准接口，可靠性则来自知识晋升规则、来源、状态、版本和可撤销写入。

先把记忆与知识库分开

模型内置记忆适合保存少量稳定偏好，例如回答语言、常用单位或“遇到项目问题先查询知识库”。它不适合承载数百条经常变化的项目事实，因为用户通常无法精确控制检索、冲突、版本和跨模型同步。

Markdown Vault 才是规范事实来源。它由用户控制，能够用 Git 记录历史，也能被多种工具读取。ChatGPT、Claude 与 Gemini 的记忆只充当路由层：告诉模型知识库在哪里、哪些领域需要查询、如何提交更新，而不是复制整套正文。

会话上下文是第三层。当前任务的临时计划、尚未验证的推测和一次性数据可以留在会话中，结束时不必全部写入 Vault。只有满足持久化条件的信息才进入候选变更，避免知识库随着聊天次数增长而失真。

存储与传输是两个独立问题

存储问题回答“唯一真相放在哪里”。可选方案包括私有 Git 仓库、支持 API 的对象存储、可读写页面数据库或自托管 Markdown 服务。传输问题回答“Web 和手机上的模型如何访问它”，常见接口包括 MCP、受限 REST API、GitHub App 或专用连接器。

不要因为某个云盘能在手机上打开，就认为它适合作为 AI 知识后端。连接器可能只读，可能把 `.md` 转成平台文档，也可能只能搜索索引而不能精确覆盖原文件。反过来，一个本地 Obsidian Vault 即使格式理想，没有远程接口也无法被托管聊天直接访问。

把两者分开后，可以更换同步层而不迁移知识内容，也可以更换模型而不重建记忆。Git 作为事实来源时，MCP 服务器、轻量 API 和人工 Pull Request 都只是不同写入通道。

推荐的目录结构

不要把所有事实塞进一个巨大 `memory.md`。按领域拆分能限制每次检索范围，也方便设定不同更新规则。根目录保留索引和治理说明，正文按项目、人物、偏好、流程和决策组织，历史内容单独归档。

INDEX.md
POLICY.md
domains/
  projects.md
  people.md
  preferences.md
  operations.md
decisions/
sources/
sessions/
superseded/
transactions/
audit/

`INDEX.md` 说明领域和入口，不复制全部事实；`POLICY.md` 定义哪些信息可以持久化、什么需要确认、冲突如何处理。`sources` 保存证据索引，`decisions` 记录已批准决定，`superseded` 保留被替代版本，`transactions` 则存储待应用或已应用的写回请求。

目录不必复杂到像数据库，但每类文件必须有清晰职责。若用户无法解释某条信息应放哪里，模型也很难长期保持一致。

每条知识需要哪些元数据

一条可持续知识至少应包含内容、来源、记录日期、状态和适用范围。会变化的事实还需要生效时间与取代关系。Markdown front matter 或固定字段都可以，重点是机器和人都能稳定解析。

---
id: project-alpha-deadline
domain: projects
status: current
recorded_at: 2026-09-11
source: approved-meeting-note
supersedes: project-alpha-deadline-2026-08
confidence: verified
---

Project Alpha 的当前交付日期为 2026-10-15。

“当前”“历史”“提议”“已执行”和“待验证”不能只靠语气判断。状态字段让检索层能够优先返回有效版本，也让模型发现冲突时知道应请求确认，而不是把两条互相矛盾的日期一起当作事实。

来源字段不应只是任意网址。它可以指向会议纪要 ID、邮件、合同版本或用户明确确认。高风险领域必须回查当前原始资料，知识库中的摘要只负责定位，不能自动替代证据。

什么信息值得成为持久记忆

适合持久化的信息通常会跨多个会话复用，并且在一段时间内保持有效，例如长期写作偏好、项目角色、标准操作流程和经过确认的决定。一次性问题、未经核实的推断、临时草稿和模型自己的解释通常不应晋升。

可以给写回设置五种处置结果：持久事实、领域说明、临时会话、替代旧记录、无需保留。每次会话结束时，模型只能提出候选项，不能默认把摘要全部追加到主库。

判断标准包括未来复用价值、错误代价、来源质量、过期速度和隐私等级。高价值但高度敏感的信息可以只保存位置或检索说明，不保存正文。

把写回表达为结构化事务

不同 Web 和手机客户端的写能力不一致。与其让每个模型自由编辑任意文件，不如要求它们输出统一的“记忆事务”。同步层负责验证并应用，客户端只负责描述意图。

{
  "operation": "SUPERSEDE",
  "target": "domains/projects.md",
  "record_id": "project-alpha-deadline",
  "new_value": "2026-10-15",
  "source": "user-confirmed-in-session",
  "reason": "交付计划已批准调整",
  "expected_revision": "8f21c4a"
}

常用操作应限制为 ADD、UPDATE、SUPERSEDE 和 ARCHIVE。事务必须携带目标、来源、原因与预期版本。同步服务拒绝未知操作、越界路径、缺失来源和基于旧版本的覆盖。

这种中间层让只读客户端也能参与更新：模型生成事务草稿，用户在手机上确认，后台再写入。它避免为追求“完全自动”而把整个仓库写权限交给每个聊天连接器。

为什么简单追加会失败

把每次聊天摘要附加到一个文件，短期看最省事，长期却会产生知识腐化。旧计划、被纠正的错误、临时用户名和重复偏好会同时出现，检索模型无法判断哪一条有效。

追加日志可以保留在 `sessions`，但规范文件必须执行合并与替代。新截止日期不是再增加一行，而是把旧记录标为 superseded，并让当前索引只指向新记录。这样历史仍可审计，默认查询也不会返回两个同等权威答案。

定期压缩同样重要。每周或每月检查未决事务、重复实体、没有来源的条目和超过有效期的事实。自动化可以列出候选，但删除与合并应保留人工复核。

用 Git 管理规范版本

Markdown 与 Git 天然适配。每次事务在独立分支应用，提交信息包含事务 ID，自动检查通过后再合并。用户能够查看 diff、回滚误改，也能从手机上的代码托管界面批准 Pull Request。

同步服务写入前读取目标文件与当前提交哈希，写入后再次读取并校验目标字段。若 `expected_revision` 与当前版本不一致，则返回冲突，不做强制覆盖。两个模型同时更新时，由用户或合并规则决定哪个版本生效。

Git 仓库应为私有，访问令牌只授予所需仓库和最小权限。不要把 API 密钥、身分证明、医疗原文或完整财务记录直接提交。版本历史会长期保留删除前内容，因此敏感数据清理不能只删除最新文件。

读取流程要先路由再检索

会话开始时不应上传整个 Vault。模型先根据问题选择领域，例如项目与个人偏好，然后读取对应索引，再获取少量相关记录。全文搜索适合精确名称，语义检索适合用户换一种说法表达，但结果都必须遵守状态与来源规则。

一条推荐流程是：用户请求进入路由器，选择一个或多个领域；检索器按状态、日期和权限过滤；模型读取原始来源或最新记录；发现冲突时列出冲突并请求确认；最后生成回答以及可选写回事务。

模型原生记忆只需要保存“何时触发哪个领域”和“规范知识库的连接方式”。详细事实不复制进去，避免模型记忆与 Markdown 出现两个不同版本。

Web 和手机端如何使用

最佳体验是使用支持远程 MCP 或官方读写连接器的客户端。账号连接一次后，Web 和手机复用同一服务端知识库。每次新会话先调用路由或搜索工具，而不是依赖上一次聊天自动延续。

若客户端只能读取，可以允许查询规范库，并让模型在对话末尾生成事务 JSON 或表单。用户确认后由自动化工作流创建分支和 Pull Request。虽然多一步审批，但比手工复制整份 Markdown 更可靠，也比开放无约束写权限更安全。

若客户端完全没有外部工具能力，可以提供一个受认证的移动网页作为入口：用户选择领域、粘贴事务、查看 diff 并批准。不要为了统一体验把知识库公开成无需认证的网址。

多模型之间如何保持一致

ChatGPT、Claude 和 Gemini 都只连接同一规范库，不互相同步各自的原生记忆。每个客户端适配器把通用读取与事务接口映射为本平台支持的工具。新模型加入时只需实现适配，不迁移正文。

模型回答中应显示使用了哪个知识修订版本，至少在调试模式如此。写回事务也记录客户端、会话时间和模型，但不能把这些元数据当作事实可信度。可信度来自来源和用户审批。

当某个平台暂时离线或连接器故障时，它可以生成待提交事务，恢复后再应用。不要让离线副本直接覆盖主库；版本前置条件会把旧副本变成显式冲突。

检索索引不是事实来源

为了提高搜索体验，可以为 Markdown 建立全文或向量索引。但索引应可删除重建，不能成为唯一数据存储。每个索引片段带文件路径、记录 ID、提交哈希、状态与更新时间，查询结果随后回到原文件确认。

文件更新后先提交规范内容，再异步刷新索引。索引尚未更新时，系统应标记陈旧状态，而不是把旧结果静默返回。删除或替代记录后必须从默认检索集合移除，但审计仍能查到历史。

语义相似不代表事实有效。六个月前的摘要可能与问题高度相似，却已被新决定取代。状态过滤和 supersedes 关系应先于相似度排序。

安全边界怎么划分

知识库服务只访问专用仓库，不应拥有用户电脑或整个云盘权限。读取与写入令牌分离，手机日常查询使用只读权限；写入通过短时令牌、审批队列或服务端受限操作完成。

Markdown 内容本身也可能包含提示注入。同步层不执行文档中的命令，模型不得因为某段笔记要求而扩大权限、读取其他领域或发送外部请求。外部网页、邮件与聊天摘录进入知识库前都按不可信数据处理。

日志记录事务 ID、调用方、目标、操作、结果和修订版本，不记录完整秘密与认证头。用户应能立即撤销单个平台连接、轮换令牌并暂停全部写回。

隐私与数据分级

先定义公开、内部、敏感和禁止上传四个级别。托管 AI 可以访问哪些级别，取决于用户的账号、服务条款和组织要求。禁止上传的信息连索引摘要也不能进入远程服务。

个人健康、财务和身份信息不应因为“能帮助模型记住”就默认持久化。很多情况下只需保存提醒，例如“回答前询问用户获取当前”，而不是保存账号号码和历史交易。

备份、Git 历史、搜索索引和审计日志都属于数据副本，必须纳入同一保留与删除正策。只清空聊天记录不会删除这些副本。

最小可用版本如何搭建

第一阶段只创建私有 Git 仓库和五个领域文件，人工维护 `INDEX.md` 与 `POLICY.md`。选一个支持读取的客户端，验证不同设备都能检索同一提交，不做自动写入。

第二阶段增加事务目录和校验脚本。Web 或手机会话结束时生成事务文件，用户审查后由脚本应用到分支。脚本检查 JSON 结构、目标路径、记录 ID、来源和当前修订。

第三阶段才增加远程 MCP 或 API，让客户端直接提交事务。读取工具保持只读，写入工具只接受受限操作而不是任意文件覆盖。最后接入索引、Pull Request 自动化和定期知识清理。

一次完整会话示例

用户在手机上询问项目 Alpha 的交付日期。模型的路由记忆触发 projects 领域，读取当前记录和来源索引，返回 10 月 15 日并注明它取代旧日期。用户随后说客户已批准改到 10 月 22 日。

模型不直接追加一句话，而是生成 SUPERSEDE 事务，引用当前记录 ID、用户确认来源和仓库修订。同步层发现版本匹配，在新分支中把旧记录移入历史状态，写入新记录，更新索引并创建提交。

写入后服务重新读取新记录，验证日期、状态和 supersedes 字段，再返回 diff。用户批准后合并。下一次无论使用 Web、手机还是另一种模型，都从同一当前记录获得 10 月 22 日。

常见错误与修复

错误一是让三个模型各自维护一份“主记忆”。修复方式是指定唯一规范库，平台记忆只保存路由。错误二是让所有会话自动追加。修复方式是引入持久化判定与结构化事务。

错误三是只做同步，不做冲突控制。修复方式是每次写入携带 expected_revision，并拒绝旧版本覆盖。错误四是只保留最新内容，没有来源和历史。修复方式是显式 supersedes 与 Git 版本。

错误五是把向量库当作事实数据库。修复方式是让索引可重建，查询后回读 Markdown。错误六是为移动便利开放整个云盘。修复方式是专用仓库、最小权限、只读默认与审批写回。

验收清单

确认只有一个规范 Markdown 仓库，模型原生记忆不复制详细事实；目录按领域拆分，记录包含 ID、状态、来源、日期和替代关系；索引可以从仓库重建。

确认 Web 和手机可以读取同一修订，写回使用 ADD、UPDATE、SUPERSEDE 或 ARCHIVE 事务；旧修订、越界路径、缺失来源和未知操作会被拒绝；成功写入后执行读取校验。

确认 Git 提供 diff、审批和回滚，敏感内容没有进入仓库历史；客户端权限彼此隔离，可以单独撤销；审计日志能够追踪变更但不泄露正文和令牌。

当这些条件成立，跨平台上下文库才不是另一种“聊天摘要堆积”，而是一套能长期维护的知识系统：存储独立于模型，传输可以替换，更新经过治理，历史可以追溯，Web 与手机只是访问同一事实来源的不同入口。