加载失败
Karpathy（AI 研究者 Andrej Karpathy）提出过一个由 LLM 维护的“wiki”设想：内容以 Markdown 文件保存，并用 Git 做版本控制，让 agent 能持续写入、回滚和审计。这个 HN Show HN 帖子展示的是一个沿着这个思路实现的项目，重点在于让 agent 维护知识库而不是只做一次性问答。评论里最热的技术争点是检索架构：先用 BM25（基于词项匹配的检索算法）还是直接上 vector db（向量数据库，基于语义嵌入检索）。Karpathy 之前在 X 上谈过类似 LLM wiki/LLM OS（把 LLM 视为操作中枢）的想法，所以评论同时夹杂了技术细节、工具替代方案以及对他本人风格的褒贬。
不少评论认可先用 BM25 再考虑 vector db 的思路，认为很多团队会跳过测量就直接上向量检索。帖子里提到在 500 个 artifacts 上做到 85% recall@20，因此讨论重点转到路由策略本身是否可靠。有人追问 heuristic classifier 到底根据什么判断查询是短查询还是 narrative query，因为 agent 生成的长句也可能只是一次普通依赖查询。如果这些查询被送进更贵的 cited-answer loop，BM25 先行带来的 latency 优势就可能被抵消。
一部分评论喜欢用 Markdown 搭建知识库并交给 Git 管理，认为这种组合更利于长期保存、回滚和自动化编辑。有人明确提出想了解 Markdown 为什么会提升 durability，并推测它可能比其他格式更适合 LLM 处理。也有人补充自己正在做一个类似的 Markdown+Git 项目，说明这个方向吸引的是一类更偏“可版本化、可审计”的知识管理需求。
有人直接质疑，既然目标是一个可维护的知识库，为什么不直接用 Obsidian vault（Obsidian 的本地笔记库）再加插件。这个问题的核心是复用成熟的个人知识管理生态，而不是重新造一套面向 agent 的 wiki 系统。后续回复对界面和办公室风格也表示认可，说明除了技术路线，产品观感同样影响大家对方案的接受度。
有人贴出 Karpathy 的原帖作为背景，说明这个项目是在回应他关于 LLM wiki 的设想。另一部分评论则把讨论带向对 Karpathy 个人风格的评价：有人不喜欢他对 LLM 的过度热情，也有人提到他之前的 LLM OS 表述加深了这种印象。与此同时，也有人反驳这种批评只是嫉妒，或者是在针对一个在 Twitter 上影响力很强、粉丝群很激进的人。整体看，这里既是技术讨论，也是对 AI 圈话语领袖的态度分歧。
BM25: 一种基于词项匹配的传统信息检索排序算法，常用于关键词搜索。
vector db（向量数据库）: 存储 embedding 并按语义相似度检索的数据库方案。
recall@20: 检索评估指标，表示正确结果是否出现在前 20 个候选中。
cited-answer: 先检索证据，再生成带引用来源答案的回答方式。
Markdown: 一种纯文本标记格式，适合长期保存、diff 和版本管理。
Git: 分布式版本控制系统，用来跟踪文件历史和协作修改。
Obsidian vault: Obsidian 中用于组织 Markdown 笔记的本地笔记库目录。