—— Andrej Karpathy

卡帕西被称为"全球最懂AI的人"，是斯坦福李飞飞教授的亲传弟子，ChatGPT背后的关键推手，也是特斯拉前人工智能与自动驾驶视觉负责人。

他在自己一篇爆火的推文中提到，自己最近最重要的AI使用场景不是写代码，而是用AI给自己搭建"个人知识库"。

两天后，他又发布了一篇更详细的长文，把整套方法论完整写了出来。这篇文章在全球科技圈刷屏了，因为它点出了：AI最大的价值，或许不是帮你干活，而是帮你管理大脑。

本文是卡帕西这篇文章的译文，文末附上原文。
原文链接：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

如果你在养小龙虾，可以把这篇文章的链接直接丢给你的龙虾助理，让他去自学习，并形成落地方案，这一定能帮助你的小龙虾变得更聪明。
具体方法参考 >>>

用AI帮你打理个人知识库，越用越聪明。

这是一份写给AI助手的"蓝图"，你可以直接把它交给你的AI助手（比如GPT、Claude、深度求索等）。它讲的是核心思路，具体怎么实现，你的AI会和你一起商量。

核心理念：从"即用即丢"到"越攒越多"

大部分人用AI处理文档，都类似"问答机"模式：上传文件，提问时AI去找相关内容，然后给你答案。这能干活，但每次问答AI都得从头翻资料，没有积累。问一个需要综合五份文档才能回答的微妙问题？AI每次都得重新找、重新拼。主流的文档对话功能基本都是这个模式。

我们的想法不一样。我们不只让AI在提问时临时翻资料，而是让它一点点帮你建设和维护一个活的、有结构的"个人维基"​ —— 一套由Markdown文件组成、相互链接的知识网络，它就站在你和原始资料之间。

当你加入一份新资料，AI不只是把它存起来以后用。它会阅读、提炼，并把新知识"缝"进现有的维基里：更新相关词条、修订主题概述、标注新旧观点的矛盾之处、强化或挑战已有的综合结论。知识被系统化地编译一次，然后持续维护更新，而不是每次提问都重来一遍。

关键在于，这个维基是"活的"而且"会生长"。交叉链接已经埋好，矛盾点已经标出，综合结论时刻反映你读过的所有东西。你每加一份资料、每提一个问题，这个维基都在变得更丰富、更强大。

你几乎不用自己动手写维基—— AI包办所有编写和维护的"体力活"。你负责找资料、提方向、问出好问题。AI则负责总结、关联、归档、整理这些让知识库真正产生长期价值的繁琐工作。实际使用时，你可以一边开着AI助手对话，一边用Obsidian之类的软件实时查看维基。AI根据对话编辑维基，你实时浏览更新后的页面、查看知识图谱。

Obsidian是你的"工作台"，AI是你的"程序员"，维基就是不断完善的"知识代码库"。

这个模式能用在很多地方，比如：

• 个人成长：
  记录目标、健康、心理笔记，把日记、文章、播客心得都归档进来，逐渐形成一份关于你自己的"用户手册"。
• 深度研究：
  花几周甚至几个月研究一个领域，读论文、看报告，逐步建起一个主题维基，你的核心观点也会在其中逐渐演化成型。
• 读书伴侣：
  边读边整理，为人物、主题、情节线建立专属页面。读完一本书，你就拥有了一本丰富的"读书笔记维基"。就像《指环王》粉丝用多年搭建的"托尔金百科"一样，只不过这次是AI在帮你实时维护所有关联。
• 团队知识库：
  用AI维护团队内部维基，数据来自会议记录、项目文档、客户沟通。AI负责了没人爱干的日常维护，让知识库总能跟上进度。
• 其他：
  竞品分析、旅行攻略、学习笔记、爱好钻研……任何需要长期积累、系统化整理知识的场景都适用。

架构：三层结构，各司其职

我们可以把整个系统想象成三层楼：

怎么用？三个核心操作

你可以通过三种主要方式和你的"AI维基管理员"协作：

两个导航利器：索引和日志

维基变大了怎么办？两个特殊文件帮你和AI掌握全局：

1. index.md（索引）：
   像一本书的目录。列出所有页面（带链接和简介），分门别类。AI每吸收一次新资料就更新它。提问时，AI先看目录再找具体页面，在几百个页面的规模下都非常高效。
2. log.md（日志）：
   像一本工作流水账。按时间顺序，只增不改地记录所有操作：哪天吸收了啥、问了啥问题、做了啥检查。如果用固定格式（如## [2026-04-02] 吸收 | 文章标题），用简单的grep命令就能快速查看历史。

为什么这个方法行得通？

维护知识库最烦人的不是读和想，而是琐碎的"管家工作"：更新关联、同步摘要、标注矛盾、保持几十个页面一致……人容易半途而废，因为维护成本增长得比价值快。AI不会烦、不会忘，能一次动十几个文件。​ 让维基得以持续维护的成本几乎为零。

人的角色是：甄选资料、把握方向、提出好问题、进行深度思考。

AI的角色是：包揽所有总结、关联、归档、整理的"体力活"。

这个想法在精神上契合了范内瓦·布什在1945年提出的"Memex"（记忆扩展机）愿景——一个私人的、由关联路径连接的知识库。他当年没解决"谁来维护"的问题，现在，AI解决了。

最后请注意：本文档描述的是一个模式或蓝图，而非具体实现。目录怎么安排、页面什么格式、用什么工具，完全取决于你的需求、喜好和你用的AI。以上所有建议都是可选的、模块化的。最适合你的用法，就是把这个思路交给你的AI助手，和它一起商量，打造出专属于你的那个版本。

---

附原文：

LLM Wiki

A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

The core idea

Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

The idea here is different. Instead of just retrieving from raw documents at query time, the LLM incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files that sits between you and the raw sources. When you add a new source, the LLM doesn't just index it for later retrieval. It reads it, extracts the key information, and integrates it into the existing wiki — updating entity pages, revising topic summaries, noting where new data contradicts old claims, strengthening or challenging the evolving synthesis. The knowledge is compiled once and then kept current, not re-derived on every query.

This is the key difference: the wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read. The wiki keeps getting richer with every source you add and every question you ask.

You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it. You're in charge of sourcing, exploration, and asking the right questions. The LLM does all the grunt work — the summarizing, cross-referencing, filing, and bookkeeping that makes a knowledge base actually useful over time. In practice, I have the LLM agent open on one side and Obsidian open on the other. The LLM makes edits based on our conversation, and I browse the results in real time — following links, checking the graph view, reading the updated pages. Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.

This can apply to a lot of different contexts. A few examples:

• Personal: tracking your own goals, health, psychology, self-improvement — filing journal entries, articles, podcast notes, and building up a structured picture of yourself over time.
• Research: going deep on a topic over weeks or months — reading papers, articles, reports, and incrementally building a comprehensive wiki with an evolving thesis.
• Reading a book: filing each chapter as you go, building out pages for characters, themes, plot threads, and how they connect. By the end you have a rich companion wiki. Think of fan wikis like Tolkien Gateway — thousands of interlinked pages covering characters, places, events, languages, built by a community of volunteers over years. You could build something like that personally as you read, with the LLM doing all the cross-referencing and maintenance.
• Business/team: an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls. Possibly with humans in the loop reviewing updates. The wiki stays current because the LLM does the maintenance that no one on the team wants to do.
• Competitive analysis, due diligence, trip planning, course notes, hobby deep-dives — anything where you're accumulating knowledge over time and want it organized rather than scattered.

Architecture

There are three layers:

Raw sources — your curated collection of source documents. Articles, papers, images, data files. These are immutable — the LLM reads from them but never modifies them. This is your source of truth.

The wiki — a directory of LLM-generated markdown files. Summaries, entity pages, concept pages, comparisons, an overview, a synthesis. The LLM owns this layer entirely. It creates pages, updates them when new sources arrive, maintains cross-references, and keeps everything consistent. You read it; the LLM writes it.

The schema — a document (e.g. CLAUDE.md for Claude Code or AGENTS.md for Codex) that tells the LLM how the wiki is structured, what the conventions are, and what workflows to follow when ingesting sources, answering questions, or maintaining the wiki. This is the key configuration file — it's what makes the LLM a disciplined wiki maintainer rather than a generic chatbot. You and the LLM co-evolve this over time as you figure out what works for your domain.

Operations

Ingest. You drop a new source into the raw collection and tell the LLM to process it. An example flow: the LLM reads the source, discusses key takeaways with you, writes a summary page in the wiki, updates the index, updates relevant entity and concept pages across the wiki, and appends an entry to the log. A single source might touch 10-15 wiki pages. Personally I prefer to ingest sources one at a time and stay involved — I read the summaries, check the updates, and guide the LLM on what to emphasize. But you could also batch-ingest many sources at once with less supervision. It's up to you to develop the workflow that fits your style and document it in the schema for future sessions.

Query. You ask questions against the wiki. The LLM searches for relevant pages, reads them, and synthesizes an answer with citations. Answers can take different forms depending on the question — a markdown page, a comparison table, a slide deck (Marp), a chart (matplotlib), a canvas. The important insight: good answers can be filed back into the wiki as new pages. A comparison you asked for, an analysis, a connection you discovered — these are valuable and shouldn't disappear into chat history. This way your explorations compound in the knowledge base just like ingested sources do.

Lint. Periodically, ask the LLM to health-check the wiki. Look for: contradictions between pages, stale claims that newer sources have superseded, orphan pages with no inbound links, important concepts mentioned but lacking their own page, missing cross-references, data gaps that could be filled with a web search. The LLM is good at suggesting new questions to investigate and new sources to look for. This keeps the wiki healthy as it grows.

Indexing and logging

Two special files help the LLM (and you) navigate the wiki as it grows. They serve different purposes:

index.md is content-oriented. It's a catalog of everything in the wiki — each page listed with a link, a one-line summary, and optionally metadata like date or source count. Organized by category (entities, concepts, sources, etc.). The LLM updates it on every ingest. When answering a query, the LLM reads the index first to find relevant pages, then drills into them. This works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure.

log.md is chronological. It's an append-only record of what happened and when — ingests, queries, lint passes. A useful tip: if each entry starts with a consistent prefix (e.g. ## [2026-04-02] ingest | Article Title), the log becomes parseable with simple unix tools — grep "^## \[" log.md | tail -5 gives you the last 5 entries. The log gives you a timeline of the wiki's evolution and helps the LLM understand what's been done recently.

Optional: CLI tools

At some point you may want to build small tools that help the LLM operate on the wiki more efficiently. A search engine over the wiki pages is the most obvious one — at small scale the index file is enough, but as the wiki grows you want proper search. qmd is a good option: it's a local search engine for markdown files with hybrid BM25/vector search and LLM re-ranking, all on-device. It has both a CLI (so the LLM can shell out to it) and an MCP server (so the LLM can use it as a native tool). You could also build something simpler yourself — the LLM can help you vibe-code a naive search script as the need arises.

Tips and tricks

• Obsidian Web Clipper is a browser extension that converts web articles to markdown. Very useful for quickly getting sources into your raw collection.
• Download images locally. In Obsidian Settings → Files and links, set "Attachment folder path" to a fixed directory (e.g. raw/assets/). Then in Settings → Hotkeys, search for "Download" to find "Download attachments for current file" and bind it to a hotkey (e.g. Ctrl+Shift+D). After clipping an article, hit the hotkey and all images get downloaded to local disk. This is optional but useful — it lets the LLM view and reference images directly instead of relying on URLs that may break. Note that LLMs can't natively read markdown with inline images in one pass — the workaround is to have the LLM read the text first, then view some or all of the referenced images separately to gain additional context. It's a bit clunky but works well enough.
• Obsidian's graph view is the best way to see the shape of your wiki — what's connected to what, which pages are hubs, which are orphans.
• Marp is a markdown-based slide deck format. Obsidian has a plugin for it. Useful for generating presentations directly from wiki content.
• Dataview is an Obsidian plugin that runs queries over page frontmatter. If your LLM adds YAML frontmatter to wiki pages (tags, dates, source counts), Dataview can generate dynamic tables and lists.
• The wiki is just a git repo of markdown files. You get version history, branching, and collaboration for free.

Why this works

The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping. Updating cross-references, keeping summaries current, noting when new data contradicts old claims, maintaining consistency across dozens of pages. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass. The wiki stays maintained because the cost of maintenance is near zero.

The human's job is to curate sources, direct the analysis, ask good questions, and think about what it all means. The LLM's job is everything else.

The idea is related in spirit to Vannevar Bush's Memex (1945) — a personal, curated knowledge store with associative trails between documents. Bush's vision was closer to this than to what the web became: private, actively curated, with the connections between documents as valuable as the documents themselves. The part he couldn't solve was who does the maintenance. The LLM handles that.

Note

This document is intentionally abstract. It describes the idea, not a specific implementation. The exact directory structure, the schema conventions, the page formats, the tooling — all of that will depend on your domain, your preferences, and your LLM of choice. Everything mentioned above is optional and modular — pick what's useful, ignore what isn't. For example: your sources might be text-only, so you don't need image handling at all. Your wiki might be small enough that the index file is all you need, no search engine required. You might not care about slide decks and just want markdown pages. You might want a completely different set of output formats. The right way to use this is to share it with your LLM agent and work together to instantiate a version that fits your needs. The document's only job is to communicate the pattern. Your LLM can figure out the rest.