把 AI 解过的题沉淀成共享知识

用 AI 排错的人大概都经历过同一个场面：问题解决了，解法留在一段会话记录里，窗口一关就找不回来。下次自己或别人撞上同样的问题，只能从头再问一遍。真正的问题不是 AI 不能重复解决，而是可用的解法已经存在过，只是没人把它留下来。

Shared Knowledge 就是冲着这一点做的。它是一个 MCP 服务器，把 AI 对话里已经验证过的解法整理成一篇 Markdown 文章提案，再提交成 GitHub 上的 Pull Request 等人审查。合并之后，文章发布到文档站，并生成一个音频版本。整个过程里，对话本身始终是私密的，服务器只提取与解法相关的内容；分享这件事必须由使用者主动发起，不存在自动发布。

流水线短到可以一行写完：对话、显式分享、MCP、Markdown、Pull Request、人工审查、合并、文档与音频。其中最关键的约束是人工审查。MCP 能做的是把知识结构化、把一次贡献准备好，它不能替任何人判断什么内容值得公开。

服务器对外只暴露三个工具，而且刻意保持窄：搜索用字段加权排序在知识库里查找；读取按路径安全地取回某一篇文章，防止路径穿越；校验负责检查结构并开出一个 GitHub Pull Request。工具少，边界清楚，调用方的助手才有空间决定怎么用。

技术选型上做了明显的减法。GitHub 是唯一的事实来源，知识库就是纯 Markdown，版本、历史、分支、差异对比、代码审查这些 Git 本来就能做，没有理由再重建一套。渲染交给 Astro 和 Starlight，静态内容已经过人工确认，不需要一个常驻的应用服务器。搜索只做字段加权关键词匹配，在这个规模下够用；只有四篇文章时引入向量数据库，不会让系统更聪明，只会让原型更重。

中途改过一次架构。最初的版本里，MCP 服务器自己调用 Gemini，把对话摘要变成结构化文章。功能上能跑，但方向不对：服务器正在变成一个绑定单一模型厂商的单体应用，这跟 MCP 要解决的问题相反。改法是把结构化规则做成一个 MCP prompt，规定英文输出、必须包含哪些区块、分类和标签只能用受控词表；真正生成内容的是调用方的助手，用它自己的模型，服务器回到校验和发布的角色。代价是主动放弃了某个奖项的参评资格，因为把 Gemini 移出了关键路径。这是有意的取舍，不是疏忽。

接入方式很普通。任何兼容 stdio 的 MCP 客户端都能连上，比如 Claude Desktop，或者 VS Code 里 GitHub Copilot Chat 的 Agent 模式。克隆仓库、完成安装、配置自己的访问令牌、把地址指向自己的知识仓库，之后任何会说 MCP 的助手都能读取这个库，并以使用者自己的 GitHub 身份提交 Pull Request。

验证走了两条完全不同的路径，没有写死任何东西。第一条贡献是一篇讲可选依赖如何让导入链整体崩溃的文章，流程完整跑通：真实问题由 AI 助手协助解决，转成带章节、元数据和标签的 Markdown 文章，服务器自动校验并开 PR，Copilot 的自动审查指出 YAML 格式和标题问题，修复后合并，合并之后才生成音频并发布到文档站。第二条走的是对话式 Agent 模式，在 Codespace 里，助手主动先查了一遍已有知识库做查重，然后才决定发布。这个行为没有写在 MCP 服务器里，服务器只是提供工具，怎么使用由调用方助手决定。

这个项目本身也是用它所主张的方式做出来的。几个 AI 环境各自承担固定角色，在人工监督下协作：一个负责分七个批次顺序推进开发，每批都写明边界，禁止越界实现，避免不同组件互相破坏；一个作为独立代码审查者检查 PR、跑关键检查；一个负责本地迭代、重构和快速修边界问题。谁的活谁做，最终判断留给。

真实世界里冒出来的问题更有意思。有一次自动审查报告了一个看起来非常有说服力的 GitHub 认证缺陷，连代码片段和行号都给了，先去核对，发现那一行和它描述的代码在仓库里根本不存在。AI 审查确实有用，但它仍然需要有人去核对作业。音频生成则一直报一个误导性很强的错误，原因是网页界面里选的音色属于共享语音库，免费账户通过 API 访问不到；把音色加进自己的列表后，第二个问题浮现出来：GitHub Actions 里一个空变量悄悄覆盖了代码里的默认值。环境变量只在键缺失时回退默认值，设成空字符串并不会回退。还有一次是手工造成的状态不一致，本地测试时删掉了 MP3 文件，却没有同步更新清单，下一次 CI 读清单，直接认为音频已经是最新的。代码没坏，是人改了文件却让系统状态对不上。

音频只在 PR 合并之后生成，未经审查的内容永远不会被合成。回听生成的音频时，会碰到一个很实际的工程问题：适合人阅读、也适合 Git 差异对比的格式，未必适合语音合成引擎。TTS 读原始 Markdown 时，区块标题会直接撞进后面的正文，没有真正意义上的停顿，听起来缺少呼吸和叙事结构。后面要加一个中间步骤，把文章的结构转成一份真正的旁白脚本。Markdown 仍然是唯一的事实来源，音频变成一种有明确用途的派生格式。

很容易想到把它扩成完整的社区平台：投票、评论、向量搜索、仪表盘。但这不是现在的优先级。先要验证的是这个环本身够不够简单：一个人解决了问题，选择把答案交回来，另一个人可以直接复用。更自然的下一步是把 MCP 服务器用 Streamable HTTP 放到远端，不用本地安装，在已有的助手里加一个地址就能用。这个环能不能转起来，不取决于投票和仪表盘，而取决于有人愿意给出答案，以及另一个人愿意信任并读它。