1. 项目概述：从“本地LLM维基”到“云端共享大脑”的实践

最近，Andrej Karpathy 发布了一个名为“LLM Wiki”的 Gist，它精准地描述了一个在我脑海中盘旋了近一年的模式。这个模式的核心，直指当前AI知识管理领域一个普遍的痛点：我们是否真的需要每次提问都让LLM（大语言模型）从零开始，在海量文档中重新“挖掘”知识？Karpathy 的答案是否定的。他提出的模式是，让一个LLM智能体像图书管理员一样，持续、增量地维护一个由Markdown文件构成的持久化维基。你可以把它想象成：Obsidian（一个强大的本地知识库工具）在一端，Claude Code（或其他LLM编程环境）在另一端，而LLM则负责处理所有繁琐的“簿记”工作——更新、链接、查重、纠错。这样一来，人类得以从机械的维护中解放，专注于真正的思考。

这个模式无疑是正确的，它揭示了知识工作的未来形态：知识应该被“合成”一次，然后被“复用”无数次，而不是为每个查询重复支付高昂的“合成税”。然而，当我试图将这个绝妙的想法融入我的日常生活时，问题出现了。我按照Karpathy的描述，搭建了本地的实现：一个Obsidian仓库，一个运行着Claude Code的终端，一套 CLAUDE.md 的元数据规范，外加日志文件。它确实能工作，但随之而来的是一系列令人沮丧的“摩擦”，这些摩擦最终扼杀了我的使用习惯。于是，我决定亲手解决这些问题，并由此构建了Hjarni。

2. 核心思路拆解：为什么RAG不够，而“维护型维基”是未来？

要理解Hjarni的价值，我们首先需要深入剖析传统RAG（检索增强生成）的局限性，以及“维护型维基”模式的优势所在。

2.1 RAG的“重复发现”困境

RAG的工作流程可以概括为：用户提问 -> 从向量数据库中检索相关文档片段 -> 将片段与问题一起喂给LLM -> LLM生成答案。这个过程存在一个根本性的效率瓶颈： 每一次查询都是一次全新的知识发现之旅 。

想象一下，你是一位研究员，你的电脑里存放着过去五年阅读过的所有论文。每次有人问你一个专业问题，你不是直接翻开你精心整理的读书笔记，而是打开全文搜索，把可能相关的几十篇论文摘要再快速浏览一遍，然后现场组织语言回答。这就是RAG在做的事情。它没有“记忆”，没有“理解”，只有临时的、基于相似度的拼接。

这种模式带来了几个显著问题：

1. 计算浪费 ：相同的背景知识会在成千上万次不同的查询中被反复检索、处理和合成，消耗大量算力。
2. 一致性风险 ：由于每次都是即时合成，LLM可能在不同时间对同一事实给出略有出入的表述，甚至产生矛盾。
3. 缺乏深度关联 ：RAG擅长找到与查询词直接相关的片段，但它无法自动建立跨文档、跨时间的深层概念联系。比如，它很难主动告诉你“今天读的这篇新文章，其结论与你三周前记录的一个想法直接冲突”。

2.2 “维护型维基”的“复利”优势

Karpathy提出的“LLM Wiki”模式，其核心是 将知识的管理从“检索”转变为“维护” 。在这个模式下，LLM扮演的是一个主动的、持续的知识库管理员。

它的工作流程更像是：

1. 你摄入一篇新文档或产生一个新想法。
2. LLM智能体分析其内容，并对照现有的维基（Markdown文件集合）。
3. LLM执行一系列“簿记”操作：
   • 创建/更新页面 ：为新主题创建页面，或更新现有页面。
   • 建立双向链接 ：自动识别并添加 [[内部链接]] ，将新内容与已有知识网络连接。
   • 发现并标记矛盾 ：识别新信息与旧记录之间的不一致，并添加显式的警告或注释。
   • 提炼摘要与标签 ：生成摘要，添加相关标签，便于未来检索。
4. 所有这些“合成”工作只做一次。之后，任何查询都可以直接在这个已经梳理好、链接好、校验过的知识网络上进行，LLM只需要进行轻量的“读取”和“解释”，而无需重做“理解”和“组织”的繁重工作。

这带来的是一种“知识复利” 。每一次维护都在增强整个知识网络的价值。交叉引用已经存在，矛盾已被标记，核心概念得到了提炼。知识的瓶颈不再是“读取”或“思考”，而是“簿记”——而这项工作，恰恰是LLM不知疲倦且擅长完成的。人类会因为维护工作枯燥且增长过快而放弃维基，但LLM不会。

2.3 本地模式的“三重摩擦”与云端化的必然

尽管本地模式在理念和技术上可行，但在实际日常使用中，我遭遇了三种相互叠加的摩擦，这些摩擦对于培养稳固的知识习惯是致命的：

摩擦一：物理绑定——“一台机器，一个维基” 你的知识库被锁死在一台设备的硬盘上。当你在岳父母家突然灵光一现，想记录一个绝妙的想法时，你无法做到。你必须等到回到那台特定的电脑前。这种延迟足以让大多数稍纵即逝的灵感彻底消失。

摩擦二：工具绑定——“一个LLM客户端，一座孤岛” 你的整个工作流被绑定在特定的LLM工具上。Claude Code可以编辑你的Markdown文件，但ChatGPT看不到它们。你手机上的Claude官方App也无法直接与之交互。你不得不将所有想法都“ funnel ”（汇集）到那个唯一接入的终端工具里，这打断了你自然的、多场景的思考与记录流程。

摩擦三：协作断裂——“分享即终结” 你可以通过Git仓库把一堆Markdown文件分享给同事。但你无法分享一个“活的”、他们也能用自己的LLM客户端直接查询和增补的维基。知识库变成了一个静态的快照，而非一个动态的、可共同培育的“大脑”。

注意 ：这三种摩擦并非技术上的“硬伤”，而是体验上的“软刀子”。它们不会让你完全无法使用，但会日复一日地消耗你的耐心和动力，最终让你回归到更简单（但低效）的笔记方式，比如一个简单的记事本或零散的聊天记录。

正是为了消除这些摩擦，Hjarni应运而生。它的核心设计目标就是： 实现Karpathy“LLM Wiki”模式的全部理念，但将其从本地文件系统中解放出来，通过一个开放的协议暴露给任何LLM客户端。

3. Hjarni架构解析：基于MCP的开放式知识网络

Hjarni的本质，是Karpathy LLM Wiki模式的一个托管式、网络化的实现。其技术核心在于对 MCP（Model Context Protocol） 的深度利用。

3.1 MCP：LLM的“通用USB接口”

MCP可以理解为LLM世界的“通用插件协议”。它由Anthropic提出，旨在标准化LLM与外部工具、数据源之间的通信方式。简单来说，一个支持MCP的服务（Server）可以将其功能暴露给任何兼容MCP的客户端（Client），无论这个客户端是Claude、ChatGPT、Cursor还是其他任何集成了MCP的AI助手。

Hjarni将自己构建为一个MCP Server。这意味着：

• 对用户透明 ：你不需要知道MCP的具体细节。你只需要知道，你的笔记库（Hjarni）现在变成了一个任何兼容LLM都能访问的“网络服务”。
• 对LLM客户端通用 ：只要你的LLM客户端支持MCP（目前Claude Desktop, Cursor, Windsurf等已原生支持），它就能发现并连接到你的Hjarni知识库。

3.2 Hjarni的核心数据模型

为了支撑一个灵活而强大的知识网络，Hjarni设计了以下核心数据单元：

1. 笔记（Note） ：知识的基本载体，对应一篇Markdown文档。包含标题、Markdown正文内容、创建/修改时间等元数据。
2. 容器（Container） ：用于组织笔记的逻辑分组。类似于文件夹，但更灵活。一个笔记可以属于多个容器（例如，一篇关于“Python异步编程”的笔记可以同时放在“编程”和“后端开发”容器中）。
3. 标签（Tag） ：轻量级的分类和标记系统。用于快速过滤和关联相关主题。
4. 链接（Link） ：笔记之间的双向关联。这是维基功能的核心。当你在笔记A中提及笔记B的标题时，Hjarni会自动（或经LLM辅助）创建双向链接，并在相关笔记的界面上显示“反向链接”（Backlinks）。

所有这些结构——你原本需要在Obsidian中手动或通过插件来构建和维护的——在Hjarni中都以结构化数据的形式存在于云端数据库中，并通过一套清晰的API暴露出来。

3.3 工作流全景：无缝的跨平台、跨客户端体验

让我们通过一个具体的用户故事，看看Hjarni如何消除前述的“三重摩擦”：

• 场景一：灵感捕捉（手机） 你在通勤路上，用手机上的Claude App读到了一篇关于“新型电池技术”的报道。你直接对Claude说：“帮我把这篇文章的核心发现和我的‘新能源投资’笔记关联起来，并更新‘固态电池’技术页面。” Claude App通过MCP调用Hjarni的接口，创建或更新了相应的笔记，并建立了链接。

• 场景二：深度加工（桌面，Claude Code） 晚上回到家，你打开电脑，在Claude Code中继续研究一个投资项目。你问：“调出我之前记录的关于电池供应链风险的所有笔记。” Claude Code通过MCP从Hjarni中检索出所有相关笔记，并提供给你一个整合的视图。你在此基础上进行深度分析，并将结论写成一篇新的“投资决策框架”笔记，Hjarni自动将其与之前的电池技术、公司财报等笔记关联。

• 场景三：应用查询（IDE，Cursor） 几天后，你在用Cursor编写一段与能源数据抓取相关的代码时，突然想确认某个技术参数。你直接在Cursor的聊天框中问：“我们之前记录的磷酸铁锂电池的能量密度典型值是多少？” Cursor通过MCP查询Hjarni，瞬间从“电池技术”笔记中提取出准确信息。

整个过程中，你从未“打开Hjarni”这个动作。 你只是在和你当时正在使用的LLM对话，而LLM背后连接着你统一的、持续进化的“第二大脑”。没有同步冲突，没有工具切换，没有地点限制。

3.4 协作功能：从个人大脑到团队大脑

Hjarni的Pro计划支持多席位（Seats）。这意味着：

• 两人或小团队 可以共享同一个Hjarni知识库。
• 每位成员及其使用的所有LLM客户端 （他们的Claude、他们的Cursor）都拥有访问和编辑权限。
• 团队可以共同维护一个关于项目的技术文档、竞争分析、客户反馈或创意想法的动态知识库。
• LLM在协助任何一位成员时，都能基于整个团队积累的知识上下文进行回答，真正实现知识的集体传承与复用。

4. 关键权衡：Hjarni vs. 本地模式，你该如何选择？

没有任何方案是完美的。Hjarni通过云端化和标准化解决了可访问性和协作问题，但也意味着你需要放弃本地模式中的一些强大特性和控制权。以下是一个诚实的利弊分析：

你选择Hjarni，可能会失去：

特性	本地模式（Obsidian+LLM）	Hjarni	影响分析
版本历史	完整的Git历史记录。可以回滚到任意版本，查看差异，创建分支进行实验。	提供基本的更新历史，但并非完整的Git log。无法进行复杂的版本树操作。	如果你重度依赖Git来管理知识迭代的每一步，或者喜欢用分支来探索不同的想法脉络，这可能是硬伤。
可视化图谱	Obsidian拥有极其美观、交互性强的力导向图视图，能直观展示笔记间的网络关系。	Hjarni展示笔记间的链接关系，但暂无同等级别的动态、可视化图谱。	对于依赖图谱视图来激发灵感或宏观把握知识结构的人来说，这是一个显著的体验降级。
文件系统访问	笔记是纯Markdown文件，存放在本地文件夹中。可以用 grep , find , sed 等任何命令行工具处理，也可以用任何文本编辑器打开。	笔记存储在云端数据库。你只能通过Hjarni的界面或API进行操作。无法直接用系统工具进行批量查找替换。	对于黑客型用户，或依赖特定文件系统工作流（如用脚本处理笔记）的人来说，这是最大的限制。
插件生态	Obsidian拥有庞大而活跃的社区插件市场（如Dataview用于高级查询、Marp用于制作幻灯片、各种主题和增强工具）。	Hjarni是一个功能聚焦的产品。它提供了核心的维基功能，但没有（短期内也不会有）类似Obsidian的插件生态系统。	如果你深度绑定了某些Obsidian插件来实现特定工作流（如制作周报、管理待办事项），迁移到Hjarni意味着需要放弃这些工作流或寻找替代方案。
离线可用性	完全离线，无需网络。	需要网络连接才能进行读写操作（尽管客户端可能有缓存机制）。	在网络不稳定或无网络环境下的可用性受限。

那么，谁应该坚持本地模式，谁应该转向Hjarni？

坚持Karpathy的本地模式，如果你：

• 是终端和本地文件的绝对拥趸 ：你的工作流深深扎根于命令行、Git和纯文本文件。
• Obsidian插件重度用户 ：你的知识管理离不开Dataview、Templater等高级插件。
• 将版本控制视为生命线 ：你需要为知识的每一次演变保留完整的、可分支的Git历史。
• 对“仅限此笔记本电脑”的摩擦无感 ：你的主要工作设备固定，且不常在移动中记录灵感。
• 对数据主权和隐私有极致要求 ：你必须将数据100%掌握在自己手中的硬盘上。

选择Hjarni，如果你：

• 追求无缝的多设备、多场景体验 ：你希望在任何地方（手机、平板、办公室电脑、家里电脑）、使用任何你喜欢的LLM客户端（Claude, ChatGPT, Cursor等）都能无障碍地存取和加工你的知识。
• 厌恶同步的麻烦 ：你受够了在不同设备间手动或通过云盘同步文件带来的冲突和延迟。
• 渴望开箱即用的协作 ：你希望与合作伙伴共享一个活的、可共同编辑和查询的知识库，而不仅仅是分享文件快照。
• 认同“知识即服务”的理念 ：你更关心知识被便捷地使用和连接，而不是管理承载知识的文件本身。
• 愿意用极致的控制权换取极致的便利性 ：你接受将数据托管在专业服务中，以换取更高的可用性和集成度。

实操心得 ：这个选择没有对错，只有适合与否。我个人是从本地模式的深度用户转向Hjarni的。促使我转变的决定性时刻，是我连续第三次在手机上产生想法却无法及时记录，以及当我试图向同事解释我的知识库结构时，发现分享一个Git仓库根本无济于事。我意识到，对我来说，知识的“流动性”和“可及性”的价值，已经远远超过了本地文件系统带来的控制感。

5. 实施指南：如何开始构建你的LLM增强维基

无论你选择本地方案还是Hjarni，以下步骤和核心原则都是通用的。

5.1 第一步：定义你的知识模式（Schema）

这是最重要的一步，相当于为你知识库的“数据结构”建模。不要一上来就扔文档，先花时间设计。

1. 确定核心实体 ：你的知识主要围绕哪些事物展开？是“人物”、“公司”、“产品”、“概念”、“项目”、“会议记录”还是“代码片段”？为每种实体创建一个笔记模板。
2. 设计元数据字段 ：每个模板应该包含哪些固定字段？例如，一个“人物”笔记模板可能包含： 姓名 、 职位 、 公司 、 联系方式 、 首次接触日期 、 标签 （如 #客户 #合作伙伴 #行业专家）。
3. 规划链接关系 ：实体之间如何关联？“人物”属于“公司”，“产品”由“公司”发布，“概念”在“项目”中被应用。在你的模板中，可以预留章节（如“## 相关链接”）来鼓励手动或让LLM自动填充这些关系。
4. 创建 INDEX.md 或 HOME.md ：这是一个总览页面，作为你知识库的入口。它可以包含最新笔记、最重要的项目索引、待办事项或一个简单的搜索指南。

示例：一个极简的 CLAUDE.md 模板（用于指导LLM）

# 笔记创建/更新规范

## 指令
你是一个知识库管理员。请根据用户提供的内容，创建或更新Markdown格式的笔记。

## 笔记模板
### 对于“概念”类笔记
文件名：`概念-{概念名称}.md`
内容结构：
# {概念名称}
**定义**：{简洁定义}
**核心要点**：
- {要点1}
- {要点2}
**相关链接**：
- [[相关概念1]]
- [[相关概念2]]
**标签**：#{领域} #{子领域}

### 对于“人物”类笔记
文件名：`人物-{姓名}.md`
内容结构：
# {姓名}
**职位**：{职位}
**所属组织**：[[{公司名}]]
**背景**：{简要背景}
**与我方的关联**：{如：潜在客户、合作伙伴、行业影响者}
**最近互动**：{日期和摘要}
**标签**：#{客户类型} #{行业}

## 操作规则
1.  始终使用双括号`[[ ]]`创建内部链接。
2.  更新笔记时，首先检查是否存在矛盾信息，如有，在顶部添加`> **注意：矛盾**`区块说明。
3.  为所有笔记添加至少一个相关标签。

将这个模板保存在你的知识库根目录，并告诉你的LLM智能体遵循它。

5.2 第二步：搭建自动化工作流

本地模式的核心是让LLM自动执行“簿记”。你需要一个触发和运行这些任务的机制。

方案A：使用脚本和定时任务（Cron） 这是最直接的方式。你可以写一个Python脚本，使用OpenAI或Anthropic的API，定期扫描某个“收件箱”文件夹（比如 _inbox ）中的新文件（可能是你手动保存的文章、转录的语音备忘录等），然后调用LLM按照你的 CLAUDE.md 规范去处理它们，生成或更新对应的维基笔记。

方案B：使用自动化工具（如n8n, Zapier, Make） 如果你不想写代码，可以使用这些可视化自动化工具。设置一个触发器（如“当Google Drive的‘待处理’文件夹新增文件”），然后连接OpenAI API节点，将文件内容发送给LLM，并按照提示词（即你的规范）要求其处理，最后将结果保存回Obsidian仓库（通过Dropbox/Google Drive同步）。

方案C：直接使用Hjarni 如果你选择Hjarni，这一步被极大地简化了。你只需要：

1. 注册Hjarni账号并创建一个知识库。
2. 在你的LLM客户端（如Claude Desktop）中配置MCP，添加Hjarni Server（Hjarni会提供详细的连接指南）。
3. 然后，你就可以在任何对话中直接使用自然语言指挥LLM去操作Hjarni了。例如：“帮我把刚才我们讨论的API设计要点保存到Hjarni，标题叫‘微服务API设计原则’，并链接到已有的‘架构决策记录’笔记。”

5.3 第三步：培养你的“提问-维护”习惯

工具搭建好后，习惯的培养是关键。你需要改变“遇到问题才去翻找”的被动模式，转变为“持续喂养，主动维护”的主动模式。

• 即时捕获 ：读到好文章、想到好点子、开完重要的会，第一时间不是仅仅收藏或录音，而是 立刻 将其发送给你的“收件箱”或直接告诉你的LLM助手：“把这个加到我的知识库，归类到XX主题下。”
• 定期回顾与清理 ：每周或每两周，花15分钟浏览你的知识库主页或图谱。让LLM帮你总结新增内容，或者主动提问：“过去一周有哪些关于‘机器学习’的新笔记？它们和之前的‘数据预处理’笔记有什么联系？” 这能帮助你巩固记忆并发现新的连接。
• 以用代维 ：最好的维护就是在使用中维护。当你向LLM提问时，如果它给出的答案引用了你的知识库，但你觉得不准确或不完整，不要只是接受答案。立即下达指令：“这个答案基于的‘XXX’笔记似乎过时了，根据我们刚才讨论的新信息，请更新那篇笔记。”

5.4 第四步：进阶技巧与优化

当你的知识库初具规模后，可以考虑以下优化：

1. 实施分层结构 ：除了标签和链接，可以引入“容器”或“分类”进行粗粒度管理。例如，所有“项目”相关的笔记放入 Projects/ 容器，所有“学习资料”放入 Resources/ 容器。
2. 建立摘要与索引页 ：让LLM定期为某个大主题（如“2024年Q2投资分析”）自动生成摘要页，汇总该主题下所有相关笔记的核心结论和链接。
3. 矛盾检测与消解 ：这是LLM的强项。可以设置一个定期任务，让LLM扫描整个知识库，寻找可能存在矛盾的陈述（例如，关于同一技术指标的两个不同数值），并生成一份“待核查矛盾列表”供你审阅。
4. 知识库健康度检查 ：让LLM分析你的知识库，报告“孤儿笔记”（没有被任何其他笔记链接的）、缺少关键字段的笔记、或最近很久没有更新的核心主题，提醒你进行维护。

6. 常见问题与故障排除实录

在实际构建和运行LLM维基的过程中，你一定会遇到各种问题。以下是我在本地模式和开发Hjarni过程中积累的一些常见坑点及解决方案。

6.1 LLM表现不稳定或“不听话”

• 问题 ：LLM有时不严格按照你的 CLAUDE.md 模板创建笔记，或忽略建立链接的指令。
• 排查与解决 ：
  • 检查系统提示词（System Prompt） ：确保你的指令清晰、无歧义。使用明确的格式要求，如“必须使用##二级标题”、“链接必须使用 [[ ]] 格式”。在提示词开头强调“严格遵守以下规范”。
  • 提供更具体的示例（Few-shot Learning） ：在提示词中，不仅给出模板，还给出1-2个完整的、正确的示例笔记。LLM通过示例学习的效果通常比单纯描述规则更好。
  • 分步执行 ：复杂的更新任务可以拆解。先让LLM“提取核心信息并生成符合模板的草稿”，你审核后再发出“根据草稿更新或创建笔记”的指令。
  • 模型选择 ：如果使用OpenAI API，尝试从 gpt-3.5-turbo 切换到 gpt-4 或 gpt-4-turbo ，后者在遵循复杂指令方面通常更可靠。

6.2 知识库出现信息矛盾或冗余

• 问题 ：同一事实在不同笔记中有不同表述，或者多个笔记内容高度重叠。
• 排查与解决 ：
  • 设立“权威来源”笔记 ：对于关键概念或数据，指定一篇笔记为“主笔记”或“权威定义”。在其他笔记中引用时，使用链接指向它，而不是重新描述。
  • 定期运行“去重与合并”任务 ：编写脚本或设置自动化流程，定期让LLM扫描所有笔记，识别内容重叠度高的笔记，并建议合并方案。例如：“检测到‘神经网络优化’和‘深度学习训练技巧’两篇笔记有60%内容重叠，建议合并为一篇‘模型优化方法综述’，并将原笔记作为别名或链接保留。”
  • 利用链接而非复制 ：鼓励在笔记中通过 [[链接]] 引用其他笔记的详细内容，而不是大段复制粘贴。

6.3 本地文件同步冲突

• 问题 ：在多设备使用Obsidian+Git的方案时，可能会遇到文件合并冲突。
• 排查与解决 ：
  • 主从设备策略 ：指定一台设备为“主编辑设备”，其他设备以“只读”或“谨慎添加”为主。在主设备上进行定期的整合和清理。
  • 使用支持冲突解决的同步服务 ：如使用Syncthing，它比简单的云盘同步能更好地处理文件版本。或者使用Obsidian官方同步服务。
  • 原子化提交 ：每次编辑后，立即进行Git提交并附上清晰的提交信息，这有助于在冲突时理解更改意图。
  • 接受Hjarni的解决方案 ：这实际上是Hjarni要解决的核心问题之一——通过中心化的数据库和API，彻底消除文件层面的同步冲突。

6.4 Hjarni连接或API调用失败

• 问题 ：在LLM客户端中无法连接到Hjarni，或执行操作时返回错误。
• 排查与解决 ：
  1. 检查MCP配置 ：确保在LLM客户端（如Claude Desktop）的MCP设置中，已正确添加Hjarni Server，并且URL、认证密钥填写无误。
  2. 检查网络 ：确认你的设备可以访问Hjarni的服务器地址。暂时关闭防火墙或VPN试试。
  3. 查看客户端日志 ：大多数MCP客户端会有日志输出。查看日志中是否有连接错误或权限错误信息。
  4. 确认API速率限制 ：如果你是高频用户，注意是否触发了API调用频率限制。
  5. 简化操作 ：如果执行复杂操作失败，尝试拆分成更简单的步骤。例如，先创建笔记，再单独添加链接。

6.5 从本地迁移到Hjarni（或反向）的顾虑

• 问题 ：数据被锁定在某个平台，无法自由迁移。
• 解决思路 ：
  • Hjarni的导出功能 ：一个负责任的知识托管服务必须提供完整的数据导出能力。Hjarni应该（并且通常会）提供将整个知识库以标准格式（如包含所有Markdown文件和元数据的ZIP包）导出的功能。
  • 本地作为备份 ：你可以将本地Obsidian仓库作为Hjarni的“冷备份”。定期使用脚本通过Hjarni的API拉取所有数据，并转换成Markdown文件保存到本地。这样你既享受了Hjarni的便利，也保留了本地副本。
  • 双向同步工具（高级） ：理论上可以开发一个工具，监听本地文件夹和Hjarni API的变化，实现双向同步。但这会引入复杂的冲突解决逻辑，一般不建议普通用户尝试。

构建这样一个系统，无论是本地还是云端，初期都需要一些投入。但一旦它运转起来，你就会发现，你与信息的关系发生了根本性的改变。你不再是在信息的海洋里盲目捕捞，而是在培育一个不断成长、愈加持久的智慧伙伴。Karpathy在Gist结尾引用了Vannevar Bush的Memex构想，那始终是一个由个人策展、带有联想轨迹的知识库。Bush未能解决的难题是“谁来维护”。现在看来，答案或许是：不是人类。无论你选择用Markdown文件在本地构建，还是使用像Hjarni这样的托管服务，方向都是一致的：停止向LLM倾倒文档，开始建造一个属于你自己的、活的“大脑”。这不仅仅是一个工具，这是一种全新的工作与思考方式。