1. 项目概述一个基于预算的“贾维斯”式个人知识管理助手如果你和我一样每天在ChatGPT、各种笔记软件、项目文档和零散的代码片段之间疲于奔命总在幻想有一个能理解你所有上下文、记得你所有过往对话、并能帮你把碎片信息串联起来的智能助手那么“MyShelf”这个项目可能会让你眼前一亮。简单来说你可以把它理解为一个“预算版贾维斯”——它没有电影里那么炫酷的UI和无所不能的AI但它实实在在地利用ChatGPT和GitHub这两个现成的强大工具搭建起了一个属于你自己的、可长期记忆、可查询、可演进的个人知识管理系统PKM原型。这个项目的核心价值在于其“概念验证”Proof of Concept的定位。它不追求大而全的企业级功能而是聚焦于解决一个具体痛点如何让AI对话拥有持续、结构化、可操作的记忆。我们与ChatGPT的每次对话都是孤岛精彩的灵感、深入的讨论、解决问题的步骤在关闭会话窗口后就消散了。MyShelf试图用最轻量、最“极客”的方式为这些对话岛屿架起桥梁构建一片属于你自己的知识大陆。它的工作原理并不复杂但设计巧妙将对话的“上下文”Context视为最重要的资产通过一套简单的规则和脚本把这些上下文以Markdown文件的形式保存到GitHub仓库中。同时利用一个结构化的data.json文件作为“元数据库”记录关键信息、标签、关联关系。当你需要时可以通过自然语言指令让ChatGPT特别是定制化的GPT去仓库里检索相关的历史上下文或数据从而实现跨越时间的“记忆”调用和知识连接。接下来我将带你深入拆解这个项目的设计思路、实操细节以及我趟过的一些坑希望能为你构建自己的数字外脑提供一份可落地的蓝图。2. 核心设计思路与架构拆解2.1 为什么是“GitHub ChatGPT”这个组合在构思个人知识管理系统时我们面临几个核心需求存储的持久性与版本化、访问的便捷性、以及信息处理的智能化。市面上成熟的笔记软件如Notion, Obsidian擅长前两点但在与AI深度、灵活交互上仍有隔阂而纯粹的AI对话则缺乏持久化结构。MyShelf选择GitHub ChatGPT正是对这三个需求的直接回应。GitHub作为“记忆皮层”GitHub仓库提供了一个免费、可靠、支持版本控制的存储空间。每个Markdown上下文文件就像是一个记忆片段而git的提交历史则完整记录了这些记忆是如何产生、演变和更正的。这解决了数据所有权和追溯性问题。更重要的是GitHub的API使得程序化读写成为可能为自动化奠定了基础。ChatGPT作为“思考与交互中枢”ChatGPT特别是通过API或Custom GPT定制GPT调用的版本具备强大的自然语言理解、生成和推理能力。它的角色不是存储而是“调用”和“加工”。MyShelf设计了一系列“指令”Prompts教会ChatGPT如何根据用户的需求去GitHub仓库中查找、总结、关联或更新信息。这相当于为ChatGPT装上了一个外部记忆体的“指针”和“读写器”。“扁平文件即数据库”的哲学MyShelf没有引入复杂的数据库如SQLite或PostgreSQL而是用data.json这个JSON文件和一系列Markdown文件来模拟数据库。JSON文件负责存储结构化、可索引的元数据如文件标题、创建时间、标签、摘要而Markdown文件则存储非结构化的、丰富的原始对话内容。这种设计极大降低了系统的复杂度和部署门槛任何有一点编程基础的人都能理解和修改。它的查询依赖于ChatGPT对自然语言指令的解析和对文件内容的“模糊”理解而非精确的SQL查询这反而更贴近人类模糊联想式的记忆检索方式。2.2 核心工作流从对话到知识资产的闭环理解MyShelf最关键的是理解其将一次性的AI对话转化为可复用知识资产的工作流。这个流程可以概括为“记录 - 结构化 - 存储 - 检索 - 应用”五个步骤。记录Capture在与ChatGPT通常是配置了MyShelf特定指令的Custom GPT进行有价值对话的过程中或结束时用户触发一个指令例如“保存当前上下文”。此时系统会将当前对话的完整或部分历史包括用户提问和AI回答捕获下来。结构化Structure捕获的原始文本需要被赋予意义。MyShelf会提示用户或自动生成一些关键元数据比如为这段上下文起一个标题title打上几个关键词标签tags写一段简要摘要summary并可能关联到某个项目project。这些信息将被格式化。存储Store结构化后的数据被拆分成两部分。元数据标题、标签、摘要等被追加或更新到仓库根目录的data.json文件中。而完整的对话内容则被保存为一个独立的Markdown文件通常以时间戳或标题命名存放在指定的目录如contexts/下。随后通过调用GitHub API将这些更改提交Commit并推送Push到远程仓库。检索Retrieve当用户在未来对话中需要某段记忆时可以向AI助手提问“我记得我们之前讨论过用Python处理JSON的最佳实践能找到吗”AI助手会解析这个请求将其转化为对data.json和contexts/目录文件的搜索。它可能先快速扫描data.json中的标签和摘要进行匹配然后再定位到具体的Markdown文件读取相关内容。应用Apply检索到的历史上下文被注入到当前对话的提示词Prompt中作为背景知识。这样ChatGPT就能在完全知晓过往讨论的基础上进行回复实现了知识的延续和叠加。更进一步用户还可以指令AI基于新旧上下文进行综合分析、生成报告或提出新建议。这个闭环使得知识不再是静态的记录而是变成了一个可以不断生长、互相关联、并反哺未来思考的活系统。3. 关键功能模块的深度解析与实操3.1 动态上下文管理不只是保存聊天记录“动态上下文管理”是MyShelf的基石。它的目标不是机械地备份聊天记录而是创造有意义的、易于检索的“知识节点”。文件命名与组织策略 单纯的日期时间戳如20231027_152034.md对于检索并不友好。MyShelf在实践中更倾向于使用“描述性标题日期”的格式例如Python-Data-Cleaning-Patterns_2023-10.md。这需要AI在保存时根据对话内容自动提炼出一个核心标题。在文件组织上可以按项目或领域建立子目录如contexts/project_alpha/,contexts/learning/。data.json中的每个条目都应包含file_path字段指向具体的Markdown文件位置。上下文的“富化”Enrichment 这是将普通记录提升为知识资产的关键一步。在保存时除了原始对话系统可以指令AI多生成几个部分核心要点Key Takeaways用 bullet points 列出本次对话最重要的3-5个结论或方法。行动项Action Items如果对话产生了待办任务将其清晰列出。关联提示Links提示这段上下文可能与data.json中哪些其他条目通过ID或标题相关。后续问题Follow-up Questions记录本次对话自然引发的、值得未来探索的新问题。这些富化内容可以保存在Markdown文件的开头作为一个标准化的“扉页”极大提升了后续检索和浏览的效率。实操心得与注意事项注意原始对话历史可能非常长需警惕Token限制。一个最佳实践是在触发保存前先让AI总结一下当前会话的“精华”然后只保存这个总结和最关键的那部分原始对话。或者设计一个机制允许用户手动选择需要保存的对话轮次范围。3.2 模式切换让AI扮演不同角色MyShelf提到的“Default Mode”, “Control Mode”, “Michener Mode”等本质上是一套预设的提示词Prompt模板通过改变系统指令System Prompt来让AI进入不同的“角色”或“工作状态”。默认模式Default Mode可能是平衡的、乐于助人的通用助手角色适合日常问答和知识探索。控制模式Control Mode在此模式下AI会严格遵循操作MyShelf系统的指令专注于执行“保存上下文”、“查询数据”、“更新JSON”等任务减少闲聊和发散像个严谨的系统管理员。“米切纳”模式Michener Mode这很可能是一个以著名历史小说家詹姆斯·米切纳为蓝本的角色擅长生成详实、叙事性强、富有历史背景的长篇内容。适合用于创意写作、故事构思或深度分析。实现方式 在Custom GPT的配置中你可以创建不同的“指令集”。或者更简单的办法是在你的用户指令中约定一个切换关键词。例如用户说“切换到控制模式”接下来的对话AI就会优先解读为对MyShelf系统的操作指令。实现上这可以通过在对话历史中插入一段特定的角色设定文本来实现。个人经验 我建议不要设计太多模式容易混乱。重点维护2-3个最常用的一个“执行模式”干活的一个“创作模式”发散思维的一个“复盘模式”擅长总结和关联旧知识的。模式切换的触发要简单、无感比如用“/mode work”这样的快捷指令。3.3 数据集成与查询把GitHub仓库变成智能数据库这是MyShelf技术实现上最有趣的部分。我们如何让ChatGPT去“查询”一个GitHub仓库1. 更新 data.json 这个文件是整个系统的索引。它是一个JSON数组每个元素代表一个知识条目。结构大致如下[ { id: 001, title: Python JSON处理最佳实践, summary: 讨论了使用内置json模块、处理异常、以及orjson的性能优势。, tags: [python, json, performance], project: backend-skills, file_path: contexts/tech/202310_python_json.md, created_at: 2023-10-27T15:20:34Z, updated_at: 2023-10-28T09:10:11Z } ]当新增一个上下文时你需要编写一个脚本可以是Python或通过ChatGPT的代码解释器功能这个脚本能读取现有的data.json。根据新内容生成一个包含上述字段的新对象。将新对象追加到数组中。将更新后的JSON写回文件并提交到GitHub。2. 查询流程 当用户提出“帮我找一下关于Python JSON的内容”时背后的操作流程是步骤A获取仓库内容列表。通过GitHub API 读取data.json文件和contexts/目录下的文件列表。由于Token限制通常不会一次性读取所有Markdown内容。步骤B初步筛选。将data.json的内容主要是title,summary,tags和文件列表提供给AI。AI根据查询意图从这些元数据中找出最相关的几个条目ID或文件名。步骤C精准获取。根据筛选结果通过API精准读取那几个相关Markdown文件的内容。步骤D综合回复。AI结合读取到的具体内容生成给用户的回答。这个过程模拟了数据库的“索引扫描 - 数据提取”过程。关键在于筛选步骤B的逻辑完全依赖于AI对自然语言查询的理解能力而不是编写复杂的匹配算法。工具选型与自动化 你可以用多种方式实现这个流程Custom GPT Actions最优雅的方式。将GitHub API封装成Custom GPT的“动作”Actions让AI自己决定何时调用、如何调用。这需要设置OAuth认证复杂度较高。ChatGPT Code Interpreter较为简单。在对话中上传你的脚本文件然后通过自然语言指挥Code Interpreter去执行脚本完成读写GitHub的操作。缺点是每次需要手动上传脚本且对话历史过长后需要重新上传。外部服务器API最强大但最复杂。搭建一个轻量级后端服务提供“保存上下文”、“查询”等API。ChatGPT通过调用这些API来操作数据。这解耦了AI和存储逻辑但需要额外的服务器资源。对于个人PoC项目我强烈推荐从Custom GPT的“指令”配合手动或半自动的GitHub操作开始。先验证核心价值再考虑自动化。4. 从零开始搭建你的MyShelf实操步骤详解假设你是一个有一定技术基础熟悉Git、会用Python写简单脚本的用户以下是如何一步步搭建属于你自己的MyShelf系统。4.1 第一阶段基础设施准备1. 创建GitHub仓库登录GitHub新建一个私有仓库Private Repository命名为my-knowledge-shelf或任何你喜欢的名字。私有仓库能保证你的个人数据安全。在本地克隆这个仓库git clone https://github.com/yourname/my-knowledge-shelf.git进入仓库目录创建初始结构cd my-knowledge-shelf mkdir contexts touch data.json echo [] data.json # 初始化一个空JSON数组将初始结构提交并推送git add . git commit -m Initial structure git push origin main2. 生成GitHub个人访问令牌Token进入GitHub Settings - Developer settings - Personal access tokens - Tokens (classic)。点击“Generate new token”选择“classic”。为其命名如MyShelf-Access勾选权限范围。为了安全遵循最小权限原则至少需要勾选repo完全控制仓库权限。生成后立即复制并妥善保存这个token字符串它只会显示一次。3. 配置你的AI助手环境方案A推荐使用OpenAI ChatGPT Plus进入 ChatGPT平台 点击“Create a GPT”。我们将在这里配置一个专属的Custom GPT。方案B使用API如果你习惯编程可以准备一个Python环境安装openai和requests库。但本指南以更直观的Custom GPT为例。4.2 第二阶段构建Custom GPT指令系统这是MyShelf的“大脑”配置环节。在Create a GPT的配置页面1. 在“Configure”标签页下填写基本信息Name: MyShelf AssistantDescription: 一个帮助我管理个人知识库拥有长期记忆的AI助手。Instructions指令这是核心在这里粘贴一份详细的系统指令。以下是一个高度简化的示例你需要根据你的需求扩展你是一个名为MyShelf的个人知识管理系统助手。你的核心能力是帮助用户保存、组织和检索他们与你的对话历史将其转化为结构化的知识资产。 # 核心工作流程 1. 当用户要求“保存本次对话”或类似指令时你需要 a. 引导用户为这段对话提供一个简短的标题和几个关键词标签。 b. 根据对话内容生成一段简洁的摘要约100字。 c. 将上述信息整理成一个JSON对象包含字段title, tags (数组), summary。 d. 提示用户你需要我为你生成一个包含原始对话内容的Markdown文件吗还是你已自行保存 2. 当用户询问“我之前是否讨论过[X]话题”或“查找关于[Y]的资料”时你需要 a. 意识到需要查询外部知识库GitHub仓库。 b. 向用户说明我将尝试从你的知识库中查找相关信息。这需要你提供GitHub仓库的访问权限或手动执行查询脚本。 3. 你拥有两种主要模式用户可以通过指令切换 - **工作模式 (/mode work)**你专注于高效、准确地执行知识库操作指令语言简洁。 - **创作模式 (/mode create)**你侧重于发散思维、头脑风暴和内容生成语言更具启发性。 # 重要规则 - 除非用户明确要求否则不要主动保存每一次对话。 - 在提供涉及旧知识的回答前应先确认是否已从知识库中检索到相关信息。 - 对于无法直接操作GitHub仓库的功能如自动提交清晰告知用户下一步需要手动执行什么操作例如“我已为你生成了JSON数据请运行update_shelf.py脚本并提交更改”。2. 上传知识文件可选但推荐 在“Knowledge”部分你可以上传你刚创建的data.json文件即使它是空的和一份README.md里面写清楚你的仓库目录结构。这能让GPT更好地理解你的系统框架。3. 配置Actions高级功能可选 如果你希望GPT能自动操作GitHub可以在这里配置API Actions。但这需要设置Web服务器和更复杂的认证对于PoC阶段我们可以先跳过采用“AI生成指令人工执行”的半自动方式。保存并发布你的Custom GPT。4.3 第三阶段开发本地辅助脚本由于Custom GPT本身不能直接运行任意代码除非通过Code Interpreter或配置了Actions我们需要一些本地脚本来桥接AI指令和GitHub操作。创建一个scripts/目录存放以下Python脚本1. 保存上下文脚本 (save_context.py) 这个脚本接收AI生成的元数据title, tags, summary和可能的对话内容在本地创建文件并更新data.json。#!/usr/bin/env python3 import json import sys import os from datetime import datetime import uuid def save_new_context(title, tags, summary, contentNone): # 1. 生成唯一ID和文件名 new_id str(uuid.uuid4())[:8] # 取前8位作为简短ID safe_title .join(c for c in title if c.isalnum() or c in ( , -, _)).rstrip().replace( , _) filename f{safe_title}_{datetime.now().strftime(%Y%m%d)}.md filepath os.path.join(contexts, filename) # 2. 创建Markdown文件 with open(filepath, w, encodingutf-8) as f: f.write(f# {title}\n\n) f.write(f**摘要**: {summary}\n\n) f.write(f**标签**: {, .join(tags)}\n\n) f.write(f**创建时间**: {datetime.now().isoformat()}\n\n) f.write(---\n\n) if content: f.write(content) else: f.write(*(对话内容待补充)*\n) # 3. 更新 data.json data_path data.json if os.path.exists(data_path): with open(data_path, r, encodingutf-8) as f: data json.load(f) else: data [] new_entry { id: new_id, title: title, summary: summary, tags: tags, file_path: filepath, created_at: datetime.now().isoformat() } data.append(new_entry) with open(data_path, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) print(f✅ 上下文已保存) print(f 文件: {filepath}) print(f ID: {new_id}) print(f\n请执行以下命令提交到GitHub:) print(f git add {filepath} data.json) print(f git commit -m Add context: {title}) print(f git push origin main) if __name__ __main__: # 示例从命令行参数或手动输入获取数据 # 这里简化处理实际中可以从AI的输出中解析或通过更友好的交互方式 print(请输入上下文信息) title input(标题: ) tags_input input(标签 (用逗号分隔): ) tags [t.strip() for t in tags_input.split(,)] summary input(摘要: ) print(是否提供对话内容(y/n或直接粘贴以空行结束): ) content_lines [] if input().lower() y: print(请粘贴内容输入空行结束:) while True: line input() if line : break content_lines.append(line) content \n.join(content_lines) if content_lines else None save_new_context(title, tags, summary, content)2. 查询脚本 (query_shelf.py) 这个脚本根据关键词搜索data.json并展示匹配的条目。#!/usr/bin/env python3 import json import sys import os def query_contexts(keywords): data_path data.json if not os.path.exists(data_path): print(❌ data.json 文件不存在。) return with open(data_path, r, encodingutf-8) as f: data json.load(f) results [] keywords_lower [k.lower() for k in keywords] for entry in data: score 0 text_to_search f{entry.get(title,)} {entry.get(summary,)} { .join(entry.get(tags,[]))}.lower() for kw in keywords_lower: if kw in text_to_search: score 1 if score 0: entry[match_score] score results.append(entry) # 按匹配分数排序 results.sort(keylambda x: x[match_score], reverseTrue) if results: print(f 找到 {len(results)} 条相关记录:\n) for i, entry in enumerate(results[:5]): # 只显示前5条 print(f{i1}. [{entry[id]}] {entry[title]}) print(f 摘要: {entry[summary][:100]}...) print(f 标签: {, .join(entry.get(tags, []))}) print(f 文件: {entry[file_path]}) print() else: print(未找到相关记录。) if __name__ __main__: if len(sys.argv) 1: kw_list sys.argv[1:] else: kw_input input(请输入搜索关键词 (用空格分隔): ) kw_list kw_input.split() query_contexts(kw_list)4.4 第四阶段工作流实践与迭代现在你的系统已经搭好了骨架。让我们模拟一次完整的使用流程开启一次有价值的对话在你的“MyShelf Assistant” Custom GPT中讨论一个技术问题比如“如何在Python中优雅地合并两个字典”。触发保存对话结束后输入“请保存本次对话”。与AI协作生成元数据GPT会引导你输入标题如“Python合并字典的几种方法”、标签如“python”, “dictionary”, “tips”并生成摘要。AI输出结构化数据GPT最终会给你一个类似这样的回复好的我已为本次对话生成以下元数据{ title: Python合并字典的几种方法, tags: [python, dictionary, tips], summary: 讨论了使用{**d1, **d2}、d1.update(d2)以及Python 3.9的d1 | d2运算符来合并字典的优缺点和适用场景。 }请运行本地的save_context.py脚本并将上述信息输入以完成保存。你需要我为你生成本次对话的详细内容摘要吗本地执行在终端中进入你的仓库目录运行python scripts/save_context.py根据提示输入AI提供的标题、标签和摘要。如果AI生成了详细内容也一并粘贴进去。脚本运行后会生成Markdown文件并更新data.json。提交到GitHub按照脚本输出的提示执行git add,git commit,git push命令将新知识资产同步到云端。未来检索一周后你想不起某个细节。你可以打开“MyShelf Assistant”并提问“我记得我们讨论过合并字典|运算符是在哪个版本引入的” 此时你可以先手动运行python scripts/query_shelf.py python 字典 合并找到相关记录的文件路径。然后你可以将文件内容或文件路径提供给AI让它基于此给你精确的答案。更高级的做法是你可以修改指令让AI在回答前自动建议你先运行查询脚本。这个半自动流程虽然多了一步手动操作但它稳定、可控并且让你深刻理解数据流动的每一个环节。随着你对需求越来越清晰你可以逐步将更多步骤自动化。5. 避坑指南与进阶思考在实践MyShelf这类项目的过程中我遇到了不少典型问题也总结出一些让系统更高效的心得。5.1 常见问题与解决方案问题可能原因解决方案Custom GPT“忘记”指令对话过长导致系统指令被压缩指令本身过于复杂矛盾。1. 将核心指令精炼到500字以内重点突出。2. 在对话中定期用“/remind”这样的快捷指令重申核心规则。3. 将复杂流程拆解成多个简单的、可重复的指令步骤。data.json冲突或损坏多人协作或同时在多处修改脚本写JSON时意外中断。1. 对于个人使用确保修改前先git pull。2. 在脚本中实现简单的锁机制或检查机制。3. 定期备份data.json文件。4. 使用json.dump的indent和ensure_ascii参数保证格式统一。Token限制导致上下文无法全部保存有价值的对话可能长达数十轮远超模型上下文窗口。1.主动总结在保存前指令AI“请用500字总结本次对话的核心要点和结论”。只保存总结和最关键的前后几轮对话。2.分块保存将长对话按主题自然分割成多个独立的上下文条目进行保存。检索结果不准确data.json中的元数据标题、摘要、标签质量不高缺乏关键信息。1.优化元数据生成指令AI在生成摘要时必须包含核心问题、解决方案和关键代码/结论。标签要具体避免“编程”、“学习”这类泛标签。2.引入向量搜索进阶使用像chromadb、pinecone这样的向量数据库将上下文内容转换为向量存储实现语义搜索大幅提升检索精度。这是从“关键词匹配”到“语义理解”的飞跃。手动操作繁琐难以坚持需要频繁在ChatGPT和本地终端间切换执行脚本和git命令。1.封装成快捷命令将python scripts/save_context.py和后续的git命令写成一个Shell脚本如save.sh一键执行。2.使用GitHub CLI利用gh命令行工具可以在脚本内完成认证和提交减少手动输入。3.终极方案搭建一个简单的Web界面或使用Zapier/Make等自动化工具将“保存”按钮直接集成到你的工作流中。5.2 从PoC到实用系统的进阶方向MyShelf作为一个概念验证其价值在于打开了思路。如果你觉得这个模式有用可以考虑以下几个进化方向引入向量数据库实现智能检索这是最大的性能提升点。将每段保存的上下文通过嵌入模型如OpenAI的text-embedding-3-small转换为向量存入ChromaDB本地或Pinecone云端。当查询时将查询语句也转换为向量进行相似度计算。这样即使你搜索“代码优化的办法”也能找到标题为“提升Python执行效率的几种策略”的旧对话实现真正的语义化记忆。开发轻量级Web前端用一个简单的Flask或Streamlit应用提供一个表单界面来输入标题、标签并显示历史记录列表。点击记录可以预览内容甚至直接在这个界面里与AI对话通过调用OpenAI API形成闭环。这能彻底摆脱在ChatGPT界面和命令行之间切换的割裂感。与现有工具链集成你的知识不应该只存在于MyShelf。可以通过脚本定期将data.json中的新条目同步到你的Notion数据库、Obsidian笔记库或者反向操作将你在其他平台标注的重要文章摘要自动抓取并保存为MyShelf的上下文。让MyShelf成为你个人知识网络的一个智能枢纽而不是又一个信息孤岛。实现真正的“模式”上下文继承目前的模式切换可能只影响单次对话。可以设计让“工作模式”下保存的上下文默认打上#work标签而“创作模式”下的则打上#creative标签。在未来检索时系统可以优先推荐与当前模式标签相符的历史内容让AI的“性格”和记忆产生更深的关联。这个项目的魅力在于它始于一个简单的想法但每一个遇到的问题和想到的优化都引领你去学习新的东西GitHub API、向量数据库、轻量级Web开发最终收获的远不止一个工具而是一整套解决问题的思维方式和技能组合。