把 AI 对话里的解决方案直接转成 GitHub PR 这种思路太绝
我最近研究了一个 Shared Knowledge MCP 方案，它的逻辑很简单：别让解决方案死在聊天记录里，直接让 AI 把那个 fix 过程写成 Markdown，然后通过 MCP 自动开一个 GitHub PR 提交到知识库。
这个流程最核心的点在于它不是全自动的。如果 AI 随口胡编一个答案就自动发布，那知识库很快就变成垃圾场了。它的链路是：AI 对话 → 用户手动触发分享 → MCP 提取核心方案 → 生成 Markdown → 提交 PR → 人工 Review → 合并发布。
最让我觉得实用的是这个 MCP 怎么把“对话”变成“文档”的。它不是简单的复制粘贴，而是要求 AI 提取出具体的场景、报错原文和最终的修复代码。
举个具体的例子，我之前碰到一个 pyproject.toml 里的可选依赖导致导入链崩溃的坑，正常流程是我问 AI → AI 给出方案 → 我改好代码 → 关掉窗口。但用这个 MCP 之后，我直接下令 publish_knowledge，它就帮我把这个坑点整理成了一篇带元数据、带标签的 Markdown 文章，直接推到了 GitHub 的一个 PR 里。
这里有个细节：即使是 AI 提交的 PR，依然会触发 GitHub Copilot 的自动 Review。比如它会提醒我 YAML 格式不对或者标题层级有问题，我微调之后 merge，这篇文章就正式进入了公开文档库。
如果你也想实现类似的自动化知识沉淀，可以参考这个简单的逻辑链路：
一、配置 MCP Server 处理文件写入和 GitHub API 调用
你需要给 MCP 授权 GitHub 的写权限，让它能创建分支并 push 代码。
二、定义结构化的 Markdown 模板
不能让 AI 随便写，必须强制要求包含以下字段，否则 Review 时没法看：
---
title: "具体的问题描述"
tags: [python, dependency, bugfix]
date: 2024-05-20
---
## Problem
(这里必须贴出具体的报错 StackTrace)
## Solution
(这里贴出修改前后的代码对比)
## Why it works
(解释底层逻辑，防止以后忘记)三、构建触发指令
在 Cursor 的 .cursorrules 或者 Claude Code 的配置里，定义一个明确的动作。比如当你输入 share this fix 时，触发 MCP 运行以下伪代码流程：
# 1. 提取当前对话中关于 solution 的片段
# 2. 调用本地 markdown_generator 格式化内容
# 3. 调用 github_api 创建新分支: feat/knowledge-xxx
# 4. git push && gh pr create最骚的操作是，这个方案在合并 PR 后还接了一个 ElevenLabs 的音频生成。这意味着以后我不用读文档，直接听一遍那个 Bug 是怎么修的就行了。
这种模式其实是在把 AI 当成一个“知识搬运工”。我们不需要 AI 替我们思考，但需要它帮我们把碎片化的对话记录快速结构化。比起手动在 Notion 或 Obsidian 里记笔记，这种“对话 → PR → 文档”的路径几乎没有心智负担，因为你只需要在问题解决的那一刻说一句“分享这个”，剩下的交给 MCP 跑就行了。
