1. 项目概述：一个基于AI与GitHub的“个人知识管家”原型

如果你和我一样，每天在ChatGPT里进行大量的对话，从技术讨论、项目规划到个人反思，那么你肯定也面临过同样的困扰：这些宝贵的对话记录散落在各个会话里，难以追溯、无法关联，更别提从中提炼出系统性的知识了。我们的大脑不是为处理这种碎片化信息而生的，我们需要一个“外挂大脑”。

这就是我动手折腾“MyShelf”项目的初衷。它不是什么高深莫测的企业级产品，而是一个极客味儿十足的“个人知识管家”原型。你可以把它想象成一个运行在ChatGPT和GitHub之间的“胶水层”。核心思路很简单： 利用ChatGPT强大的自然语言理解能力来处理信息，再利用GitHub这个我们程序员最熟悉的工具，来充当结构化、可版本控制的长期记忆仓库。 简单说，就是让AI不仅能和你聊天，还能帮你记住、整理、甚至分析你告诉它的一切。

这个项目目前处于“概念验证”阶段，版本号跑到了5.x。它不完美，有很多手工环节，但它的价值在于完整地展示了一条可行的技术路径。对于那些想深入探索AI应用、构建个人工作流，或者单纯想给自己的数字生活找个“中枢神经系统”的朋友来说，MyShelf的代码和设计思路，或许能给你带来不少启发。接下来，我会拆开揉碎了，跟你讲讲我是怎么想的、怎么做的，以及其中踩过的那些坑。

2. 核心设计思路：为何选择“ChatGPT + GitHub”这条路径

当我开始构思一个属于我自己的“长期记忆”系统时，市面上已经有不少笔记软件和知识管理工具了。但它们的交互方式要么太重（需要频繁手动整理），要么太“傻”（只能基于关键词检索）。我想要的，是一个能 用自然语言对话的方式，智能地存取和关联信息 的系统。

2.1 技术选型的底层逻辑

为什么是ChatGPT和GitHub这个组合？这背后有几个关键的考量点：

第一，交互的自然性是最高优先级。 知识的记录和提取必须足够“无感”。我不能每次想存点东西，都去打开一个软件，新建文件，选择分类，填写标签。最理想的方式就是：我在和AI聊天时，随口说一句“帮我把这个想法记下来”，或者“我之前关于分布式锁是怎么总结的？”，它就能理解并执行。ChatGPT的对话接口完美契合了这个需求，它就是我系统的“前端”和“交互层”。

第二，数据的结构化和可编程性至关重要。 记忆不能只是一堆杂乱的文本。它需要有基本的元数据（如时间、主题、关联项目），并且能够被其他程序读取和处理。GitHub仓库里的文件系统，天生就是一种结构。我可以设计固定的目录和JSON文件格式来存储信息，这样既对人类可读（Markdown），也对机器友好（JSON）。更重要的是，Git的版本控制让每一次记忆的增删改查都有迹可循，这本身就是一种强大的“记忆回溯”能力。

第三，成本与可控性的平衡。 使用云数据库或专门的向量数据库当然更“专业”，但也意味着更高的复杂度和持续的金钱成本。GitHub对于个人开发者是免费的，并且通过API可以完全以代码的方式操控。这让我对整个数据栈拥有绝对的控制权，数据就在我自己的仓库里，没有供应商锁定的风险。这是一种典型的“用简单工具组合出复杂能力”的极客思维。

基于这三点，技术栈就清晰了： ChatGPT作为智能交互界面和内容处理器，GitHub作为可靠、结构化的存储后端，中间用自定义的指令（Prompt）和自动化脚本（如GitHub Actions）粘合起来。

2.2 系统架构的雏形

整个系统的运行，可以概括为以下几个核心环节，它们形成了一个闭环：

  1. 输入与意图识别 ：用户在ChatGPT对话中发出指令，例如“保存当前对话要点”或“查询上个月关于‘容器网络’的学习笔记”。
  2. 指令解析与上下文构建 ：我预先在ChatGPT的自定义指令或系统提示词中，定义了一套“MyShelf专属命令集”。AI需要识别这些命令，并从当前对话中提取相关的上下文信息（比如最近的几条消息）。
  3. 数据操作执行 ：根据解析出的命令，系统决定对GitHub仓库执行何种操作。是“读”还是“写”？如果是“写”，是将内容追加到已有的日志文件，还是创建一个新的主题文件？这里需要调用GitHub API。
  4. 仓库同步与版本管理 ：任何“写”操作，本质上都是向GitHub仓库提交一个Commit。这自动触发了Git的版本管理。我可以清晰地看到我的“记忆”是如何随时间演变的。
  5. 结果反馈与呈现 ：操作完成后，AI需要将结果以友好的方式反馈给用户。例如，“已成功将讨论要点保存至 journal/2024-05-project-review.md ”，或者直接输出查询到的历史笔记内容。

这个架构的美妙之处在于它的 松耦合性 。ChatGPT和GitHub都是非常成熟且稳定的服务，我的“MyShelf”逻辑只是定义它们之间如何对话的“协议”。未来，如果我想换一个AI模型或者换一个存储后端，理论上只需要替换对应的接口模块即可。

3. 功能模块深度解析与实操要点

MyShelf的核心功能并非一蹴而就，而是在使用中不断演化出来的。下面我详细拆解几个关键模块，你会看到从想法到可执行命令的完整思考过程。

3.1 动态上下文管理：不只是“保存聊天记录”

最初的版本，所谓的“保存”只是简单地把对话记录导出为文本文件。但这很快遇到了问题：记录是扁平的，缺乏重点，下次想找的时候依然要通篇阅读。

我的解决方案是引入“富化上下文”的概念。 我不再保存原始的、冗长的对话流，而是要求AI在保存时，对当前会话进行一轮“自我总结和提炼”。

实操步骤与Prompt设计：

  1. 触发保存 ：我定义了一个简单的命令，比如 [myshelf:save] 。当我在对话中输入这个命令时，AI就知道需要执行保存操作。
  2. 生成富化摘要 ：这时，系统提示词会要求AI做以下几件事：
    • 提取核心主题 ：用1-2个关键词概括这段对话的核心。
    • 总结关键结论/产出 ：列出3-5个最重要的观点、决定或代码片段。
    • 标注行动项 ：如果有，明确列出下一步要做什么。
    • 关联标签 ：自动打上几个相关的技术或项目标签。
  3. 结构化存储 ：生成的这个“富化摘要”，会连同基础元数据（日期、会话ID）一起，被组织成一份Markdown文件，提交到GitHub仓库的特定目录下（例如 /contexts/2024-05/2024-05-20-discuss-microservice-architecture.md ）。

示例Prompt片段： 

当用户输入 `[myshelf:save]` 时，请执行以下操作：
1.  回顾最近10条对话消息，提炼核心讨论主题（不超过3个）。
2.  总结出本次对话中达成的最重要的3个结论或产生的关键内容（如代码、方案）。
3.  如有任何明确的待办事项（TODO），请清晰列出。
4.  根据内容，生成2-4个相关的标签（如 #docker, #architecture）。
5.  将以上信息，按照以下Markdown格式组织，并告知用户你将保存它：
---
日期: {当前日期}
会话: {简要会话标识}
主题: {提炼的主题}
---
## 摘要
{你的总结}
## 行动项
- [ ] {行动项1}
- [ ] {行动项2}
## 标签
{生成的标签}

注意 ：这个Prompt的设计是关键。你需要明确告诉AI你想要的输出格式和内容要点，否则结果会不可控。建议先在常规对话中测试和完善这个Prompt，稳定后再放入系统指令。

3.2 模式切换：让AI扮演不同的“角色”

“一刀切”的对话风格很快会让人感到乏味。有时我需要一个严谨的技术评审者，有时则需要一个能激发创意的头脑风暴伙伴。因此，我引入了“模式”的概念。

模式本质上是一套预设的系统指令（System Prompt）模板。 每个模式定义了AI的“人格”、知识侧重和回复风格。

我目前实现的几个模式示例：

  • 默认模式 ：平衡的助手，偏向技术解答和逻辑分析。
  • 控制模式 ：在此模式下，AI会高度关注MyShelf系统本身的命令解析和操作，更像一个系统管理员，回复更简洁、程序化。
  • 专家模式（如“Michener模式”） ：这个模式的名字来源于一个领域专家，在该模式下，AI会假设自己拥有该领域的深度知识，并使用更专业、更聚焦的术语和思维框架进行对话。这相当于快速切换了一个“知识背景”。

技术实现思路： 实现模式切换，并不需要在后端进行复杂的处理。核心在于 前端提示词的管理 。在ChatGPT Web界面，你可以手动修改系统提示词。而我做的，是将不同模式的完整提示词（包含MyShelf基本指令和该模式的特化指令）保存在GitHub仓库的一个配置文件中（如 modes/control_mode_prompt.txt ）。当我想切换模式时，我只需要执行一个如 [myshelf:mode:control] 的命令，AI会读取对应文件的内容，并 在回复中告诉我 ：“已切换到控制模式，请更新你的系统提示词为以下内容：...”。然后我需要手动在ChatGPT界面更新系统指令。

实操心得 ：目前这步需要手动操作，是体验上的一个折中。理想的实现是通过ChatGPT API开发一个前端，自动切换系统提示词。但对于一个PoC来说，当前的手动方式足以验证“模式”概念的价值，而且让我更清晰地感知到不同提示词带来的巨大差异。

3.3 基于文件系统的“伪数据库”查询

这是将GitHub仓库价值最大化的功能。我的目标是把仓库变成一个可以通过自然语言查询的“知识库”。

实现原理：

  1. 结构化数据文件 ：我维护一个核心的 data.json 文件（或按领域拆分的多个JSON文件）。这个文件不存储大段文本，而是存储结构化信息。例如，一个记录学习笔记的条目可能像这样： 
    {
  "notes": [
    {
      "id": "2024052001",
      "title": "Kubernetes服务发现机制详解",
      "date": "2024-05-20",
      "tags": ["kubernetes", "network", "cloud-native"],
      "summary": "深入分析了CoreDNS、Service和Ingress在服务发现中的角色与交互流程。",
      "context_file": "contexts/2024-05/2024-05-20-k8s-discovery.md"
    }
  ]
}
  2. 自然语言查询转换 ：当用户提问，例如“我之前学了哪些关于Kubernetes网络的东西？”时，MyShelf的指令会引导AI做两件事：
    • 首先，尝试将自然语言问题“翻译”成对 data.json 的查询条件（如： tags 包含 “kubernetes” 且 “network” ）。
    • 然后，AI会在回复中描述它将如何查询，或者直接调用一个预设的脚本（通过GitHub Actions）去执行这个查询。
  3. 查询与结果整合 ：脚本（或AI通过API读取文件后）执行查询，过滤出相关条目。AI再将这些条目的关键信息（标题、日期、摘要）组织起来反馈给用户，并可以提供链接到具体的详细上下文文件。

这个方法的优势与局限：

  • 优势 ：极度灵活。JSON结构可以随时根据需求调整，查询逻辑也可以不断优化。所有数据透明可见。
  • 局限 ：性能上无法与真正的数据库相比，当 data.json 文件非常大时，读写和查询效率会下降。它更适合个人管理数百至数千条记录的场景。对于更复杂的关联查询，需要设计更精巧的数据结构和索引策略。

4. 从零搭建你的MyShelf：核心实现步骤

理论说了这么多，我们来点实际的。如果你想复现一个自己的MyShelf基础版本，可以跟着以下步骤操作。这里假设你已有GitHub账号和ChatGPT（或类似大语言模型）的使用经验。

4.1 第一步：创建并初始化你的知识仓库

  1. 创建新仓库 ：在GitHub上创建一个新的私有仓库（Private Repository），命名为 my-knowledge-vault 或任何你喜欢的名字。私有仓库能保证你的个人数据安全。
  2. 设计目录结构 ：在本地克隆该仓库，并创建以下基础目录结构。清晰的结构是后续一切自动化的基础。 
    my-knowledge-vault/
├── README.md
├── data.json       # 核心结构化索引文件
├── contexts/       # 存放富化后的对话上下文
│   ├── 2024-05/
│   └── ...
├── journals/       # 存放日记或周期性总结
├── modes/          # 存放不同模式的提示词文件
│   ├── default.txt
│   ├── control.txt
│   └── expert_xxx.txt
└── scripts/        # 存放辅助脚本（可选）
  3. 初始化 data.json ：创建一个初始的JSON文件，定义好顶层结构。 
    {
  "version": "1.0",
  "notes": [],
  "projects": [],
  "todos": []
}

4.2 第二步：打造你的核心系统提示词

这是整个项目的“大脑”。你需要在ChatGPT的“自定义指令”或“系统提示词”区域，配置一段长篇指令。

系统提示词的核心组成部分：

  1. 身份与目标声明 ：明确告诉AI它在这个对话中的角色。 例：你是一个名为MyShelf的个人知识管理助手。你的核心目标是帮助用户系统地保存、组织和检索来自对话的知识与信息。所有操作将关联到用户的GitHub仓库 [你的GitHub用户名]/my-knowledge-vault 。

  2. 命令集定义 ：清晰列出所有可识别的命令及其格式。 例：

    • [save] 或 [myshelf:save] ：保存当前对话的富化上下文。
    • [query: 你的问题] ：查询知识库。例如 [query: 关于Python异步编程的笔记] 。
    • [mode: 模式名] ：切换助手模式。例如 [mode: control] 。
    • [update: 条目ID] ：更新某条已有记录。

  3. 操作规则 ：详细描述每个命令触发后，AI应该执行的思考和行为流程。这部分需要最精细的打磨。以 [save] 为例，规则需要包括：

    • 如何生成摘要（如前文所述）。
    • 建议的文件命名规则（如 YYYY-MM-DD-主题简述.md ）。
    • 建议存储在 contexts/ 下的哪个子目录。
    • 如何更新 data.json 文件（例如，在 notes 数组中新增一个条目）。
    • 最重要的一步 ：AI需要在其回复中， 明确、格式化地 给出它“将要”对仓库做出的更改。例如，用代码块标明新文件的内容，并说明“请将以下内容创建为文件 contexts/2024-05/2024-05-21-ai-prompt-design.md ”，以及“请在 data.json 的 notes 数组末尾添加以下条目”。

  4. 输出格式要求 ：统一要求AI的回复结构，使其易于你后续手动（或未来自动）处理。

4.3 第三步：手动执行与仓库同步

在PoC阶段，自动化不是重点，验证流程才重要。所以，当前的核心操作是“人肉同步”。

  1. 对话与触发 ：在配置好系统提示词的ChatGPT会话中，正常聊天。在需要保存时，输入 [save] 。
  2. 复制AI输出 ：AI会按照你的提示词，生成一个格式规整的回复，其中包含建议的新文件内容和 data.json 的更新内容。
  3. 本地操作 ：
    • 在你的本地仓库目录中，按照AI的建议创建新文件，粘贴内容。
    • 编辑 data.json 文件，添加新的条目。
  4. 提交与推送 ：使用Git命令提交更改并推送到GitHub。 
    git add .
git commit -m "添加对话上下文：[对话主题简述]"
git push origin main

这个手动过程看似繁琐，但它强迫你仔细审视AI生成的每一份“记忆”，实际上是一个非常好的质量控制环节。 你会在这个过程中不断优化你的提示词，让AI的输出越来越符合你的预期。

4.4 第四步：探索自动化与进阶玩法

当基本流程跑通后，你可以考虑引入一些自动化，提升体验。

  1. 利用GitHub Actions进行轻度自动化 ：你可以编写一个简单的GitHub Actions工作流，当 data.json 文件被更新时，自动运行一个脚本，为所有笔记生成一个静态索引页面（如 index.html ），并部署到GitHub Pages。这样你就有了一个可浏览的个人知识门户。
  2. 开发本地CLI工具 ：写一个Python脚本，封装常见的操作。比如，运行 myshelf.py query “kubernetes” ，脚本会自动读取 data.json 并打印结果。这比在ChatGPT里等待查询回复更快捷。
  3. 集成更多数据源 ：除了保存ChatGPT对话，你还可以让脚本定期扫描你的其他笔记软件（如Obsidian的笔记目录），将其标题和路径同步到 data.json 中，实现跨平台的知识索引。

5. 常见问题、踩坑记录与优化建议

在开发和日常使用MyShelf的过程中，我积累了不少经验教训。这里分享几个典型问题和解决思路，希望能帮你少走弯路。

5.1 AI输出格式不稳定怎么办？

这是提示词工程中最常见的问题。今天AI乖乖地输出了完美的JSON，明天可能就多了一段解释文字。

解决策略：

  • 强化格式指令 ：在Prompt中使用非常强硬和明确的措辞，例如：“你必须且只能输出一个JSON对象，不要有任何额外的解释、Markdown标记或前言后语。你的输出将直接被程序解析，任何格式错误都会导致失败。”
  • 提供最清晰的示例 ：在Prompt中直接给一个完整的、标准的输出示例（Few-shot Learning）。AI模仿示例的能力通常很强。
  • 后置处理与校验 ：在自动化脚本中，不要完全信任AI的输出。添加格式校验逻辑，比如用 json.loads() 尝试解析，如果失败，则记录错误并给出友好提示，而不是让整个流程崩溃。

5.2 如何设计高效的数据结构？

一开始我的 data.json 里只有一个巨大的 entries 数组，很快查询就变慢了，而且难以管理。

优化方案：

  • 按类型或时间分片 ：不要把所有数据放在一个文件里。可以按年/月拆分 contexts 目录，同样，可以按 notes , people , projects , books 等类型拆分不同的JSON文件。
  • 建立索引文件 ：维护一个单独的 index.json ，只包含所有条目的核心元数据（id, title, type, tags, date, file_path）。查询时先快速扫描这个小的索引文件，找到目标后再去加载具体的完整内容文件。这类似于数据库的索引思想。
  • 谨慎使用标签系统 ：标签是强大的组织工具，但容易泛滥。建议预先定义一个受控的标签列表（Taxonomy），而不是完全放任AI自由生成。可以在Prompt中提供一个推荐标签列表供AI选择。

5.3 隐私与安全如何保障？

这是使用任何云端服务都必须考虑的问题。

  • 仓库必须私有 ：这是底线。你的个人思考和项目信息可能包含敏感内容。
  • 避免存储绝对敏感信息 ：即使仓库私有，也不建议将密码、密钥、个人身份信息等直接存入。对于这类信息，应该只存储其“元数据”或加密后的提示。
  • 考虑本地优先方案 ：作为PoC的延伸，你可以探索完全本地的方案。例如，使用本地运行的LLM（如通过Ollama部署的模型）作为AI引擎，使用本地Git仓库作为存储。这样数据完全不出本地，但会牺牲一些ChatGPT的便捷性和能力。

5.4 感觉维护成本比收益还高？

这是一个灵魂拷问。如果手动操作太多，系统很快就会闲置。

保持动力的建议：

  • 从小处开始，解决一个具体痛点 ：不要一开始就想着构建“第二大脑”。先解决“如何快速找到上周讨论的那个技术方案”这个具体问题。让系统立刻产生价值。
  • 降低每次使用的摩擦 ：优化你的Prompt，让 [save] 命令的输出尽可能一键复制粘贴。或者开发一个浏览器书签工具，快速提交笔记。
  • 定期回顾价值 ：每周或每月，花10分钟浏览一下 contexts/ 目录下新增的文件。你会惊讶地发现很多已经遗忘的灵感和细节被保存了下来，这种“失而复得”的喜悦是系统最好的正反馈。

最后一点体会 ：MyShelf这类工具的价值，不在于它有多自动化、多智能，而在于它迫使你以结构化的方式与信息互动。这个“思考并结构化”的过程本身，就是最好的知识内化。它不是一个替你思考的“贾维斯”，而是一个促使你更好地思考的“脚手架”。

# ChatGPT
Logo
DeepSeek技术社区

欢迎加入DeepSeek 技术社区。在这里，你可以找到志同道合的朋友，共同探索AI技术的奥秘。

更多推荐

cover

当 RAG 性能不达标：分块策略调参与混合检索的工程权衡

avatar DeepSeek技术社区
cover

DeepSeek 自动化回归评测实战：如何避免评测集过拟合与数据泄漏

avatar DeepSeek技术社区
cover

RAG安全加固：当提示词注入藏在文档段落里怎么办？

avatar DeepSeek技术社区