[{"data":1,"prerenderedAt":2947},["ShallowReactive",2],{"header-counts":3,"footer-counts":6,"wiki-llm-wiki":9},{"tools":4,"reviews":5},77,25,{"tools":4,"reviews":5,"playbooks":7,"news":8},22,13,{"id":10,"title":11,"body":12,"category":2918,"description":682,"extension":2919,"meta":2920,"navigation":1008,"path":2921,"published":2922,"relatedModels":2923,"relatedTools":2927,"seo":2933,"slug":1461,"stem":2934,"summary":2935,"tags":2936,"updated":2945,"__hash__":2946},"wiki\u002Fwiki\u002Fllm-wiki.md","LLM Wiki (大语言模型维基知识库)",{"type":13,"value":14,"toc":2827},"minimark",[15,20,33,43,46,51,54,116,120,124,127,155,165,169,176,185,189,324,327,335,402,406,413,532,538,542,554,651,662,667,670,673,683,687,693,697,704,715,719,727,730,780,787,790,793,913,920,924,1072,1075,1079,1090,1096,1102,1106,1116,1119,1123,1126,1147,1150,1156,1160,1166,1169,1175,1179,1182,1202,1205,1210,1216,1221,1224,1349,1354,1360,1365,1368,1385,1390,1393,1398,1401,1404,1410,1414,1417,1424,1428,1435,1438,1442,1445,1447,1563,1588,1591,1594,1605,1608,1613,1616,1621,1624,1629,1632,1635,1642,1646,1649,1656,1660,1666,1670,1681,1685,1692,1695,1702,1706,1709,1713,1716,1720,1723,1727,1730,1734,1737,1742,1746,1758,1763,1819,1822,1828,1833,1859,1866,1869,1876,1971,1979,1982,1985,2017,2020,2027,2059,2064,2068,2079,2084,2087,2218,2223,2230,2235,2238,2246,2249,2267,2271,2280,2389,2395,2399,2406,2410,2420,2424,2431,2435,2438,2441,2447,2450,2457,2461,2468,2472,2479,2483,2486,2490,2493,2497,2504,2508,2511,2515,2521,2525,2529,2540,2544,2551,2555,2558,2562,2629,2633,2636,2656,2659,2663,2666,2680,2687,2691,2697,2700,2706,2709,2744,2751,2756,2759,2823],[16,17,19],"h2",{"id":18},"什么是-llm-wiki","什么是 LLM Wiki",[21,22,23,24,28,29,32],"p",{},"LLM Wiki（大语言模型维基知识库）是 OpenAI 联合创始人 Andrej Karpathy 于 2026 年 4 月在 GitHub Gist 上提出的",[25,26,27],"strong",{},"新型知识管理范式","。核心思路是：",[25,30,31],{},"把大模型看作知识编译器，将零散的原始资料预先编译成结构化、可互联、可迭代更新的 Markdown 维基知识库","。",[21,34,35,36,32],{},"Karpathy 在帖子中写道：\"我最近消耗的 token，越来越少用来写代码，越来越多用来整理知识。\"这条帖子获得了 170 万+浏览，Hacker News 上 284 分、90 条评论，VentureBeat 和 Analytics India Magazine 都做了专题报道 ",[37,38,42],"a",{"href":39,"rel":40},"https:\u002F\u002Fventurebeat.com\u002Fai\u002Fkarpathy-llm-wiki\u002F",[41],"nofollow","$TRAE_REF",[21,44,45],{},"打个比方：传统笔记工具（如 Obsidian）是\"开发环境\"，大模型是\"程序员\"，Wiki 知识库就是双方共同维护的\"代码库\"。人类负责筛选信息、把控方向，LLM 承担摘要、关联、纠错、归档等重复性工作。",[47,48,50],"h3",{"id":49},"karpathy-的人机协作三部曲","Karpathy 的人机协作三部曲",[21,52,53],{},"LLM Wiki 是 Karpathy 关于「人机协作」的第三块拼图：",[55,56,57,73],"table",{},[58,59,60],"thead",{},[61,62,63,67,70],"tr",{},[64,65,66],"th",{},"阶段",[64,68,69],{},"时间",[64,71,72],{},"核心理念",[74,75,76,90,103],"tbody",{},[61,77,78,84,87],{},[79,80,81],"td",{},[25,82,83],{},"Vibe Coding",[79,85,86],{},"2025 年 2 月",[79,88,89],{},"接受 AI 写的代码，不逐行审查，信模型，测结果",[61,91,92,97,100],{},[79,93,94],{},[25,95,96],{},"Agentic Engineering",[79,98,99],{},"2026 年 1 月",[79,101,102],{},"把编程任务拆解给 Agent 执行，人类负责架构设计",[61,104,105,110,113],{},[79,106,107],{},[25,108,109],{},"LLM Wiki",[79,111,112],{},"2026 年 4 月",[79,114,115],{},"把知识整理工作交给 LLM，人类负责筛选方向和质量把控",[16,117,119],{"id":118},"为什么需要-llm-wiki","为什么需要 LLM Wiki",[47,121,123],{"id":122},"传统-rag-的四个痛点","传统 RAG 的四个痛点",[21,125,126],{},"传统 RAG（检索增强生成）虽然解决了大模型知识过时的问题，但本身有固有缺陷：",[128,129,130,137,143,149],"ol",{},[131,132,133,136],"li",{},[25,134,135],{},"分块损失"," — 一篇结构化的论文切成 512 token 的碎片后，上下文关系全丢了",[131,138,139,142],{},[25,140,141],{},"检索不稳定"," — Embedding 相似度不等于语义相关度，换个说法就可能检索不到",[131,144,145,148],{},[25,146,147],{},"无知识积累"," — 每次提问都从零开始重新检索、理解，对话结束后知识不留存",[131,150,151,154],{},[25,152,153],{},"知识碎片化"," — 原始文档之间没有显式关联，知识只是\"堆\"在数据库里",[21,156,157,158,161,162],{},"这些问题并非 RAG 的 Bug，而是其设计哲学决定的——",[25,159,160],{},"RAG 本质上是\"检索时理解\"","。Karpathy 提出了一个反直觉的思路：",[25,163,164],{},"为什么不在入库时就让 LLM 理解好？",[47,166,168],{"id":167},"llm-wiki-的核心理念","LLM Wiki 的核心理念",[21,170,171,172,175],{},"LLM Wiki 跳出\"检索+拼接\"的思维，借鉴",[25,173,174],{},"编译原理","：原始资料只编译一次，后续查询直接复用编译成果。这就像把散落的参考文献变成一本百科全书——查一次资料，整理成书，以后直接翻书即可。",[177,178,179],"blockquote",{},[21,180,181,184],{},[25,182,183],{},"关键洞察","：如果你的知识库足够精炼，你根本不需要复杂的向量检索。100 个 Wiki 页面，每个平均 500 tokens，总共才 50,000 tokens——现在的 LLM 动辄 128K 甚至 200K 的上下文窗口，完全可以把整个 Wiki 塞进去。",[16,186,188],{"id":187},"llm-wiki-vs-传统-rag","LLM Wiki vs 传统 RAG",[55,190,191,203],{},[58,192,193],{},[61,194,195,198,201],{},[64,196,197],{},"对比维度",[64,199,200],{},"传统 RAG",[64,202,109],{},[74,204,205,222,233,247,258,269,280,291,302,313],{},[61,206,207,210,216],{},[79,208,209],{},"核心模式",[79,211,212,215],{},[25,213,214],{},"即时检索型","（解释器模式），每次查询重新检索拼接",[79,217,218,221],{},[25,219,220],{},"预编译型","（编译器模式），一次编译、多次复用",[61,223,224,227,230],{},[79,225,226],{},"知识处理",[79,228,229],{},"原始文档→分块→向量化→检索→拼接",[79,231,232],{},"原始文档→LLM 编译→结构化 Wiki 页面→查询 Wiki",[61,234,235,238,241],{},[79,236,237],{},"依赖组件",[79,239,240],{},"分块器、Embedding 模型、向量数据库、重排序模型",[79,242,243,246],{},[25,244,245],{},"仅需大模型 + 本地文件夹","，组件极简",[61,248,249,252,255],{},[79,250,251],{},"知识积累",[79,253,254],{},"无，查询结束知识即消失",[79,256,257],{},"复利效应，资料越多知识库越丰富",[61,259,260,263,266],{},[79,261,262],{},"内容形态",[79,264,265],{},"非结构化文本片段，语义碎片化",[79,267,268],{},"结构化 Markdown，双链引用、元数据、分类标签",[61,270,271,274,277],{},[79,272,273],{},"运维成本",[79,275,276],{},"部署复杂，需专业技术人员",[79,278,279],{},"纯文件管理，个人即可上手",[61,281,282,285,288],{},[79,283,284],{},"可读性",[79,286,287],{},"向量库黑盒，人工难以审核",[79,289,290],{},"全透明 Markdown，支持人工编辑校验",[61,292,293,296,299],{},[79,294,295],{},"查询负担",[79,297,298],{},"重（需理解原文片段）",[79,300,301],{},"轻（知识已结构化）",[61,303,304,307,310],{},[79,305,306],{},"更新成本",[79,308,309],{},"低（增量更新向量）",[79,311,312],{},"高（需要重新编译）",[61,314,315,318,321],{},[79,316,317],{},"适合数据量",[79,319,320],{},"大规模（10GB+）",[79,322,323],{},"中小规模（\u003C 500 页文档）",[47,325,326],{"id":326},"三代知识检索范式的演进",[21,328,329,330,334],{},"RAG 是第一代，GraphRAG 是第二代，LLM Wiki 是第三代 ",[37,331,42],{"href":332,"rel":333},"https:\u002F\u002Fm.toutiao.com\u002Fgroup\u002F7657839645065003555\u002F",[41],"：",[55,336,337,353],{},[58,338,339],{},[61,340,341,344,347,350],{},[64,342,343],{},"范式",[64,345,346],{},"核心思路",[64,348,349],{},"代表作",[64,351,352],{},"适合场景",[74,354,355,371,387],{},[61,356,357,362,365,368],{},[79,358,359],{},[25,360,361],{},"RAG",[79,363,364],{},"向量检索 + 即时拼接",[79,366,367],{},"LangChain、LlamaIndex",[79,369,370],{},"大规模通用问答",[61,372,373,378,381,384],{},[79,374,375],{},[25,376,377],{},"GraphRAG",[79,379,380],{},"知识图谱 + 社区摘要",[79,382,383],{},"Microsoft GraphRAG",[79,385,386],{},"多跳推理、关系型问答",[61,388,389,393,396,399],{},[79,390,391],{},[25,392,109],{},[79,394,395],{},"知识编译 + 全量上下文",[79,397,398],{},"Karpathy Gist、sage-wiki",[79,400,401],{},"个人知识库、深度研究",[47,403,405],{"id":404},"llm-wiki-vs-graphrag-深度对比","LLM Wiki vs GraphRAG 深度对比",[21,407,408,409,334],{},"GraphRAG（微软提出）和 LLM Wiki 经常被放在一起讨论，但它们的出发点完全不同 ",[37,410,42],{"href":411,"rel":412},"http:\u002F\u002Fm.toutiao.com\u002Fgroup\u002F7634063690081321515\u002F",[41],[55,414,415,425],{},[58,416,417],{},[61,418,419,421,423],{},[64,420,197],{},[64,422,377],{},[64,424,109],{},[74,426,427,439,457,470,482,495,508,520],{},[61,428,429,433,436],{},[79,430,431],{},[25,432,346],{},[79,434,435],{},"从文档中抽取实体和关系，构建知识图谱，按社区聚类生成摘要",[79,437,438],{},"把原始资料编译成结构化 Markdown Wiki，全量加载到上下文",[61,440,441,446,449],{},[79,442,443],{},[25,444,445],{},"知识表示",[79,447,448],{},"图结构（节点 + 边 + 社区摘要）",[79,450,451,452,456],{},"Markdown 文件 + ",[453,454,455],"code",{},"[[双链]]"," + YAML 元数据",[61,458,459,464,467],{},[79,460,461],{},[25,462,463],{},"查询方式",[79,465,466],{},"图遍历 + 社区摘要检索",[79,468,469],{},"全量上下文 + 结构化问答",[61,471,472,476,479],{},[79,473,474],{},[25,475,251],{},[79,477,478],{},"无持久化结构，每次查询基于图谱临时推导",[79,480,481],{},"持久化 Wiki 页面，知识持续沉淀和复利增长",[61,483,484,489,492],{},[79,485,486],{},[25,487,488],{},"构建成本",[79,490,491],{},"图谱构建极其昂贵（实体抽取 + 关系建模 + 社区检测）",[79,493,494],{},"中等（LLM 编译 + 页面维护）",[61,496,497,502,505],{},[79,498,499],{},[25,500,501],{},"维护方式",[79,503,504],{},"文档更新需重建图谱",[79,506,507],{},"增量 Ingest + 定期 Lint",[61,509,510,514,517],{},[79,511,512],{},[25,513,284],{},[79,515,516],{},"图谱结构，非技术人员难以审核",[79,518,519],{},"全透明 Markdown，人工可直接编辑",[61,521,522,526,529],{},[79,523,524],{},[25,525,352],{},[79,527,528],{},"多跳推理、关系型问答（\"A 公司的供应商的竞争对手是谁\"）",[79,530,531],{},"深度研究、个人知识体系、概念关联",[21,533,534,537],{},[25,535,536],{},"选型建议","：如果你的问答场景高度依赖实体间关系推理（多跳查询），GraphRAG 更合适；如果你需要的是一个持续积累、可读可审、轻量运维的个人知识库，LLM Wiki 更合适。两者不是互斥的--社区已有人尝试在 LLM Wiki 的 Wiki 层基础上叠加知识图谱，兼顾结构化沉淀和图遍历能力。",[47,539,541],{"id":540},"从-memex-到-llm-wiki80-年的知识管理梦","从 Memex 到 LLM Wiki：80 年的知识管理梦",[21,543,544,545,548,549,553],{},"Karpathy 在原始 Gist 中提到了 Vannevar Bush 1945 年在《As We May Think》中提出的 ",[25,546,547],{},"Memex"," 概念 ",[37,550,42],{"href":551,"rel":552},"http:\u002F\u002Fm.toutiao.com\u002Fgroup\u002F7626377286300533248\u002F",[41],"。这段历史值得了解：",[55,555,556,568],{},[58,557,558],{},[61,559,560,562,565],{},[64,561,69],{},[64,563,564],{},"里程碑",[64,566,567],{},"核心贡献",[74,569,570,583,596,609,625,638],{},[61,571,572,577,580],{},[79,573,574],{},[25,575,576],{},"1945",[79,578,579],{},"Vannevar Bush 提出 Memex",[79,581,582],{},"设想一种个人知识机器，文档之间有\"关联线索\"（trails），可沿链接跳转",[61,584,585,590,593],{},[79,586,587],{},[25,588,589],{},"1968",[79,591,592],{},"Douglas Engelbart \"Mother of All Demos\"",[79,594,595],{},"演示了超文本、鼠标、协作编辑，将 Memex 的理念部分落地",[61,597,598,603,606],{},[79,599,600],{},[25,601,602],{},"1989",[79,604,605],{},"Tim Berners-Lee 发明万维网",[79,607,608],{},"超链接概念大规模普及，但 Web 是公共的，不是个人知识库",[61,610,611,616,619],{},[79,612,613],{},[25,614,615],{},"2000s",[79,617,618],{},"Roam Research、Obsidian 等双链笔记工具",[79,620,621,622,624],{},"个人知识管理工具兴起，",[453,623,455],{}," 让笔记互相连接",[61,626,627,632,635],{},[79,628,629],{},[25,630,631],{},"2023-2025",[79,633,634],{},"RAG 范式流行",[79,636,637],{},"大模型 + 向量检索，解决了\"找\"的问题，没解决\"留\"的问题",[61,639,640,645,648],{},[79,641,642],{},[25,643,644],{},"2026.04",[79,646,647],{},"Karpathy 提出 LLM Wiki",[79,649,650],{},"LLM 解决了 Memex 80 年来无人愿意做的\"维护\"问题",[21,652,653,654,657,658,661],{},"Bush 当年设想的 Memex 比后来的万维网更接近 LLM Wiki--",[25,655,656],{},"私有的、主动策划的、文档之间的连接和文档本身一样有价值","。但 Bush 解决不了一个问题：",[25,659,660],{},"谁来做维护？"," 人类会厌倦、会偷懒、会放弃。80 年后，LLM 解决了这个问题。",[177,663,664],{},[21,665,666],{},"\"人类之所以会放弃维护 wiki，是因为维护负担的增速超过了价值增速。大模型消除了这个瓶颈。\" -- Karpathy",[16,668,669],{"id":669},"三层架构",[21,671,672],{},"Karpathy 定义的 LLM Wiki 采用极简的三层目录结构：",[674,675,680],"pre",{"className":676,"code":678,"language":679},[677],"language-text","LLM-Wiki\u002F\n├── raw\u002F          # 第一层：原始资料目录（只读）\n├── wiki\u002F         # 第二层：LLM 生成的维基知识库\n└── CLAUDE.md     # 第三层：全局规则配置文件\n","text",[453,681,678],{"__ignoreMap":682},"",[47,684,686],{"id":685},"第一层raw-原始资料仓库","第一层：raw\u002F — 原始资料仓库",[21,688,689,692],{},[25,690,691],{},"永久只读","，所有原始资料（PDF、论文、文章、笔记、截图、录音转文字稿等）放入后不做任何修改。这是知识溯源底座，所有 Wiki 页面内容均可追溯至此。LLM 只读不写，确保你永远能回头验证原始信息。",[47,694,696],{"id":695},"第二层wiki-核心知识库","第二层：wiki\u002F — 核心知识库",[21,698,699,700,703],{},"由 LLM 全权维护，按概念、实体、摘要、综合分析等维度组织成 Markdown 文件。所有页面包含标准 YAML 元数据、正文、双链引用（",[453,701,702],{},"[[页面名称]]","）、来源标注和更新时间。典型规模为 100 篇左右的文章，约 40 万词——整个 Wiki 可以一次性塞进当前主流模型的上下文窗口。",[21,705,706,707,710,711,714],{},"内置 ",[453,708,709],{},"index.md","（全局索引）和 ",[453,712,713],{},"log.md","（更新日志），记录知识库迭代全过程。",[47,716,718],{"id":717},"第三层claudemd-规则配置文件","第三层：CLAUDE.md — 规则配置文件",[21,720,721,722,726],{},"这是 Karpathy 所说的**\"廉价本体论\"**（Cheap Ontology）",[37,723,42],{"href":724,"rel":725},"https:\u002F\u002Fm.toutiao.com\u002Fgroup\u002F7625637860418257449\u002F",[41],"。传统知识本体（OWL、SPARQL）需要专业本体工程师来定义，年薪十几万美金。Karpathy 说用自然语言写一份 CLAUDE.md 就行了——定义好 Wiki 的结构和规则，LLM 就能按规矩办事。",[21,728,729],{},"CLAUDE.md 解决了三个核心问题：",[55,731,732,745],{},[58,733,734],{},[61,735,736,739,742],{},[64,737,738],{},"问题",[64,740,741],{},"没有 Schema",[64,743,744],{},"有 Schema",[74,746,747,758,769],{},[61,748,749,752,755],{},[79,750,751],{},"格式",[79,753,754],{},"混乱不统一",[79,756,757],{},"严格模板、标准结构",[61,759,760,763,766],{},[79,761,762],{},"质量",[79,764,765],{},"长短不一、详略不同",[79,767,768],{},"质量稳定、可预测",[61,770,771,774,777],{},[79,772,773],{},"维护",[79,775,776],{},"知识库逐渐混乱",[79,778,779],{},"知识库持续整洁",[21,781,782,783,786],{},"更强大的设计是——",[25,784,785],{},"修改 Schema 就能修改 LLM 行为，不需要改一行代码","。想让摘要更详细？改 CLAUDE.md 里的字数限制就行。想新增一种页面类型？在模板里加一个定义即可。",[16,788,789],{"id":789},"五大页面类型",[21,791,792],{},"在完整的实现中，Wiki 可以根据需要分为五类页面，各司其职：",[55,794,795,811],{},[58,796,797],{},[61,798,799,802,805,808],{},[64,800,801],{},"类型",[64,803,804],{},"目录",[64,806,807],{},"内容",[64,809,810],{},"示例",[74,812,813,833,853,873,893],{},[61,814,815,820,825,828],{},[79,816,817],{},[25,818,819],{},"Entities",[79,821,822],{},[453,823,824],{},"entities\u002F",[79,826,827],{},"人物、组织、项目",[79,829,830],{},[453,831,832],{},"geoffrey-hinton.md",[61,834,835,840,845,848],{},[79,836,837],{},[25,838,839],{},"Concepts",[79,841,842],{},[453,843,844],{},"concepts\u002F",[79,846,847],{},"技术概念、理论",[79,849,850],{},[453,851,852],{},"transformer-architecture.md",[61,854,855,860,865,868],{},[79,856,857],{},[25,858,859],{},"Summaries",[79,861,862],{},[453,863,864],{},"summaries\u002F",[79,866,867],{},"源文档摘要",[79,869,870],{},[453,871,872],{},"attention-is-all-you-need.md",[61,874,875,880,885,888],{},[79,876,877],{},[25,878,879],{},"Synthesis",[79,881,882],{},[453,883,884],{},"synthesis\u002F",[79,886,887],{},"跨文档综合分析",[79,889,890],{},[453,891,892],{},"evolution-of-nlp.md",[61,894,895,900,905,908],{},[79,896,897],{},[25,898,899],{},"Queries",[79,901,902],{},[453,903,904],{},"queries\u002F",[79,906,907],{},"归档的高质量问答",[79,909,910],{},[453,911,912],{},"query-scaling-laws.md",[21,914,915,916,919],{},"每种页面都有严格的模板：YAML frontmatter 元数据 + 标准化的 Markdown 结构 + ",[453,917,918],{},"[[双向链接]]"," 交叉引用。",[47,921,923],{"id":922},"标准-wiki-页面示例","标准 Wiki 页面示例",[674,925,929],{"className":926,"code":927,"language":928,"meta":682,"style":682},"language-markdown shiki shiki-themes github-light github-dark","---\ntitle: Transformer 架构原理\ntype: concept\nsources:\n  - raw\u002Fpapers\u002Fattention-is-all-you-need.pdf\nrelated:\n  - [[Self-Attention 机制]]\n  - [[BERT vs GPT]]\ncreated: 2026-04-10\nupdated: 2026-06-01\nconfidence: high\n---\n\n# Transformer 架构原理\n\n核心思想：摒弃循环和卷积，完全依赖注意力机制建立序列中任意位置的依赖关系。\n\n## 关键贡献\n- 多头注意力机制（Multi-Head Attention）\n- 位置编码（Positional Encoding）\n- 并行化训练\n\n## 相关概念\n#深度学习 #NLP #注意力机制\n","markdown",[453,930,931,939,945,951,957,963,969,975,981,987,993,999,1004,1010,1016,1021,1027,1032,1038,1044,1050,1056,1060,1066],{"__ignoreMap":682},[932,933,936],"span",{"class":934,"line":935},"line",1,[932,937,938],{},"---\n",[932,940,942],{"class":934,"line":941},2,[932,943,944],{},"title: Transformer 架构原理\n",[932,946,948],{"class":934,"line":947},3,[932,949,950],{},"type: concept\n",[932,952,954],{"class":934,"line":953},4,[932,955,956],{},"sources:\n",[932,958,960],{"class":934,"line":959},5,[932,961,962],{},"  - raw\u002Fpapers\u002Fattention-is-all-you-need.pdf\n",[932,964,966],{"class":934,"line":965},6,[932,967,968],{},"related:\n",[932,970,972],{"class":934,"line":971},7,[932,973,974],{},"  - [[Self-Attention 机制]]\n",[932,976,978],{"class":934,"line":977},8,[932,979,980],{},"  - [[BERT vs GPT]]\n",[932,982,984],{"class":934,"line":983},9,[932,985,986],{},"created: 2026-04-10\n",[932,988,990],{"class":934,"line":989},10,[932,991,992],{},"updated: 2026-06-01\n",[932,994,996],{"class":934,"line":995},11,[932,997,998],{},"confidence: high\n",[932,1000,1002],{"class":934,"line":1001},12,[932,1003,938],{},[932,1005,1006],{"class":934,"line":8},[932,1007,1009],{"emptyLinePlaceholder":1008},true,"\n",[932,1011,1013],{"class":934,"line":1012},14,[932,1014,1015],{},"# Transformer 架构原理\n",[932,1017,1019],{"class":934,"line":1018},15,[932,1020,1009],{"emptyLinePlaceholder":1008},[932,1022,1024],{"class":934,"line":1023},16,[932,1025,1026],{},"核心思想：摒弃循环和卷积，完全依赖注意力机制建立序列中任意位置的依赖关系。\n",[932,1028,1030],{"class":934,"line":1029},17,[932,1031,1009],{"emptyLinePlaceholder":1008},[932,1033,1035],{"class":934,"line":1034},18,[932,1036,1037],{},"## 关键贡献\n",[932,1039,1041],{"class":934,"line":1040},19,[932,1042,1043],{},"- 多头注意力机制（Multi-Head Attention）\n",[932,1045,1047],{"class":934,"line":1046},20,[932,1048,1049],{},"- 位置编码（Positional Encoding）\n",[932,1051,1053],{"class":934,"line":1052},21,[932,1054,1055],{},"- 并行化训练\n",[932,1057,1058],{"class":934,"line":7},[932,1059,1009],{"emptyLinePlaceholder":1008},[932,1061,1063],{"class":934,"line":1062},23,[932,1064,1065],{},"## 相关概念\n",[932,1067,1069],{"class":934,"line":1068},24,[932,1070,1071],{},"#深度学习 #NLP #注意力机制\n",[16,1073,1074],{"id":1074},"四大核心原理",[47,1076,1078],{"id":1077},"_1-知识编译ingest","1. 知识编译（Ingest）",[21,1080,1081,1082,1085,1086,1089],{},"这是 LLM Wiki 与 RAG 最本质的区别。当新资料放入 ",[453,1083,1084],{},"raw\u002F"," 目录后，LLM ",[25,1087,1088],{},"一次性完整阅读全文","（而非分块截取），然后完成：",[674,1091,1094],{"className":1092,"code":1093,"language":679},[677],"原始文档 → 内容提取 → LLM 生成摘要 → 创建 Summary 页面\n  → LLM 提取实体 → 创建\u002F更新 Entity 页面\n    → LLM 提取概念 → 创建\u002F更新 Concept 页面\n      → 更新双向链接 → 更新 index.md → 记录 log.md\n",[453,1095,1093],{"__ignoreMap":682},[21,1097,1098,1101],{},[25,1099,1100],{},"一次编译，多次复用","，彻底解决传统 RAG 反复解析原始文档的冗余开销。",[47,1103,1105],{"id":1104},"_2-知识查询query","2. 知识查询（Query）",[21,1107,1108,1109,1112,1113,32],{},"用户提问时，系统直接读取 ",[453,1110,1111],{},"wiki\u002F"," 目录下的结构化 Markdown 页面，通过页面索引和双链关系快速定位相关内容。查询的设计哲学是：",[25,1114,1115],{},"先查已编译的知识（Wiki），再查原始资料（Raw Sources），最后综合生成答案",[21,1117,1118],{},"有价值的问答会被自动归档成新的 Wiki 页面（Query 类型），意味着 Wiki 会通过使用不断\"自我增长\"——你问得越多，知识库越丰富。",[47,1120,1122],{"id":1121},"_3-知识自检lint","3. 知识自检（Lint）",[21,1124,1125],{},"借鉴代码静态分析的理念，定期触发巡检任务，让 LLM 遍历整个知识库自动执行三类维护：",[1127,1128,1129,1135,1141],"ul",{},[131,1130,1131,1134],{},[25,1132,1133],{},"修正矛盾"," — 对比新旧资料，统一冲突观点",[131,1136,1137,1140],{},[25,1138,1139],{},"补全链接"," — 为孤立页面补充关联，完善知识网络",[131,1142,1143,1146],{},[25,1144,1145],{},"清理过期"," — 识别过时信息并标注更新",[21,1148,1149],{},"Lint 操作会输出健康报告：",[674,1151,1154],{"className":1152,"code":1153,"language":679},[677],"🔍 知识库健康检查报告\n健康评分: 85.0%\n| 问题类型     | 数量 |\n|--------------|------|\n| 孤立页面     | 2    |\n| 断链         | 1    |\n| 过期内容     | 3    |\n| 内容矛盾     | 0    |\n",[453,1155,1153],{"__ignoreMap":682},[47,1157,1159],{"id":1158},"_4-知识溯源traceability","4. 知识溯源（Traceability）",[21,1161,1162,1163,1165],{},"每个 Wiki 页面的元数据中都绑定 ",[453,1164,1084],{}," 目录下的原始文件，人工审核时一键追溯源头，兼顾 AI 自动化与人工可控性，降低大模型幻觉带来的风险。",[16,1167,1168],{"id":1168},"完整工作流",[674,1170,1173],{"className":1171,"code":1172,"language":679},[677],"原始资料入库 (raw\u002F)\n  → LLM 编译生成 Wiki 页面 (wiki\u002F)\n    → 用户查询（读取 Wiki 而非 raw）\n      → 定期 Lint 巡检修复\n        → 新增资料继续编译迭代\n          → 循环增长\n",[453,1174,1172],{"__ignoreMap":682},[16,1176,1178],{"id":1177},"如何搭建-llm-wiki","如何搭建 LLM Wiki",[47,1180,1181],{"id":1181},"前置准备",[1127,1183,1184,1190,1196],{},[131,1185,1186,1189],{},[25,1187,1188],{},"本地文件管理","：系统文件夹即可，推荐搭配 Obsidian（天然支持双链和 Markdown）",[131,1191,1192,1195],{},[25,1193,1194],{},"大模型服务","：Claude、GPT-4、通义千问等在线 API，或本地部署 Llama 3、Qwen 等开源模型",[131,1197,1198,1201],{},[25,1199,1200],{},"文本编辑器","：VS Code、Typora 等",[47,1203,1204],{"id":1204},"搭建步骤",[21,1206,1207],{},[25,1208,1209],{},"步骤 1：创建目录结构",[674,1211,1214],{"className":1212,"code":1213,"language":679},[677],"LLM-Wiki\u002F\n├── raw\u002F\n├── wiki\u002F\n└── CLAUDE.md\n",[453,1215,1213],{"__ignoreMap":682},[21,1217,1218],{},[25,1219,1220],{},"步骤 2：编写 CLAUDE.md 规则文件",[21,1222,1223],{},"写入页面格式要求、链接规则、元数据规范、Lint 巡检标准。以下是一个完整的模板参考：",[674,1225,1227],{"className":926,"code":1226,"language":928,"meta":682,"style":682},"# LLM Wiki 全局运维规则\n\n你当前角色为 LLM Wiki 专属维护者，仅负责处理知识库相关工作。\n\n## 一、页面格式要求\n1. 所有 wiki 目录下的 Markdown 文件必须包含标准 YAML 头部：\n   title、type、sources、related、created、updated、confidence\n2. type 仅可选：concept(概念)、entity(实体)、source-summary(摘要)、\n   comparison(对比分析)、synthesis(综合分析)\n3. confidence 分为 high\u002Fmedium\u002Flow 三档\n\n## 二、链接与引用规则\n1. 页面之间使用双链 [[页面名称]] 关联，禁止无效链接\n2. 所有内容必须标注来源，溯源至 raw\u002F 目录下的原始文件\n3. 新增页面必须关联至少 1 个已有相关页面\n\n## 三、内容撰写规则\n1. 基于 raw 目录原始资料提炼，禁止编造内容\n2. 正文逻辑清晰，分层使用标题，添加相关标签\n3. 多篇资料内容冲突时，同时保留多方观点并标注矛盾点\n\n## 四、Lint 巡检规则\n1. 检测孤立页面并补充关联链接\n2. 核查内容矛盾、过时信息并标注更新\n3. 补全缺失的元数据与来源标注\n",[453,1228,1229,1234,1238,1243,1247,1252,1257,1262,1267,1272,1277,1281,1286,1291,1296,1301,1305,1310,1315,1320,1325,1329,1334,1339,1344],{"__ignoreMap":682},[932,1230,1231],{"class":934,"line":935},[932,1232,1233],{},"# LLM Wiki 全局运维规则\n",[932,1235,1236],{"class":934,"line":941},[932,1237,1009],{"emptyLinePlaceholder":1008},[932,1239,1240],{"class":934,"line":947},[932,1241,1242],{},"你当前角色为 LLM Wiki 专属维护者，仅负责处理知识库相关工作。\n",[932,1244,1245],{"class":934,"line":953},[932,1246,1009],{"emptyLinePlaceholder":1008},[932,1248,1249],{"class":934,"line":959},[932,1250,1251],{},"## 一、页面格式要求\n",[932,1253,1254],{"class":934,"line":965},[932,1255,1256],{},"1. 所有 wiki 目录下的 Markdown 文件必须包含标准 YAML 头部：\n",[932,1258,1259],{"class":934,"line":971},[932,1260,1261],{},"   title、type、sources、related、created、updated、confidence\n",[932,1263,1264],{"class":934,"line":977},[932,1265,1266],{},"2. type 仅可选：concept(概念)、entity(实体)、source-summary(摘要)、\n",[932,1268,1269],{"class":934,"line":983},[932,1270,1271],{},"   comparison(对比分析)、synthesis(综合分析)\n",[932,1273,1274],{"class":934,"line":989},[932,1275,1276],{},"3. confidence 分为 high\u002Fmedium\u002Flow 三档\n",[932,1278,1279],{"class":934,"line":995},[932,1280,1009],{"emptyLinePlaceholder":1008},[932,1282,1283],{"class":934,"line":1001},[932,1284,1285],{},"## 二、链接与引用规则\n",[932,1287,1288],{"class":934,"line":8},[932,1289,1290],{},"1. 页面之间使用双链 [[页面名称]] 关联，禁止无效链接\n",[932,1292,1293],{"class":934,"line":1012},[932,1294,1295],{},"2. 所有内容必须标注来源，溯源至 raw\u002F 目录下的原始文件\n",[932,1297,1298],{"class":934,"line":1018},[932,1299,1300],{},"3. 新增页面必须关联至少 1 个已有相关页面\n",[932,1302,1303],{"class":934,"line":1023},[932,1304,1009],{"emptyLinePlaceholder":1008},[932,1306,1307],{"class":934,"line":1029},[932,1308,1309],{},"## 三、内容撰写规则\n",[932,1311,1312],{"class":934,"line":1034},[932,1313,1314],{},"1. 基于 raw 目录原始资料提炼，禁止编造内容\n",[932,1316,1317],{"class":934,"line":1040},[932,1318,1319],{},"2. 正文逻辑清晰，分层使用标题，添加相关标签\n",[932,1321,1322],{"class":934,"line":1046},[932,1323,1324],{},"3. 多篇资料内容冲突时，同时保留多方观点并标注矛盾点\n",[932,1326,1327],{"class":934,"line":1052},[932,1328,1009],{"emptyLinePlaceholder":1008},[932,1330,1331],{"class":934,"line":7},[932,1332,1333],{},"## 四、Lint 巡检规则\n",[932,1335,1336],{"class":934,"line":1062},[932,1337,1338],{},"1. 检测孤立页面并补充关联链接\n",[932,1340,1341],{"class":934,"line":1068},[932,1342,1343],{},"2. 核查内容矛盾、过时信息并标注更新\n",[932,1345,1346],{"class":934,"line":5},[932,1347,1348],{},"3. 补全缺失的元数据与来源标注\n",[21,1350,1351],{},[25,1352,1353],{},"步骤 3：导入原始资料",[21,1355,1356,1357,1359],{},"将论文、笔记、文档放入 ",[453,1358,1084],{}," 目录，保持原始文件只读。",[21,1361,1362],{},[25,1363,1364],{},"步骤 4：执行知识编译",[21,1366,1367],{},"两种方式：",[1127,1369,1370,1376],{},[131,1371,1372,1375],{},[25,1373,1374],{},"手动交互","：将 CLAUDE.md + raw 资料上传至大模型，输入编译指令，将返回的 Markdown 文件保存到 wiki\u002F 目录",[131,1377,1378,1381,1382],{},[25,1379,1380],{},"命令行自动化","：使用 Claude Code 等工具，执行 ",[453,1383,1384],{},"claude --ingest .\u002Fraw --wiki .\u002Fwiki --rule .\u002FCLAUDE.md",[21,1386,1387],{},[25,1388,1389],{},"步骤 5：查询使用",[21,1391,1392],{},"用 Obsidian 打开 wiki\u002F 目录直接浏览，或通过 AI 问答方式查询整个知识库。",[21,1394,1395],{},[25,1396,1397],{},"步骤 6：定期巡检",[21,1399,1400],{},"每周或每新增 5 份以上资料后执行 Lint 巡检，保持知识库质量。",[16,1402,1403],{"id":1403},"社区开源实现",[21,1405,1406,1407,334],{},"Karpathy 发布 Gist 后，社区很快涌现出多个开源实现，以下是三个最具代表性的项目 ",[37,1408,42],{"href":724,"rel":1409},[41],[47,1411,1413],{"id":1412},"sage-wikigo-编译器范式","sage-wiki（Go）— 编译器范式",[21,1415,1416],{},"用 Go 编写，与 Karpathy 构想对齐度最高的实现。把知识库当编译目标，编译管道分 5 个 Pass：diff 检测、并行 LLM 摘要、概念提取去重、Wiki 文章生成、图片处理，支持断点续传。",[21,1418,1419,1420,1423],{},"搜索系统采用四维混合搜索：BM25 全文搜索 + 向量余弦相似度 + RRF 融合 + 标签加权和时间衰减。知识图谱支持 8 种语义关系（implements、extends、contradicts 等），支持 BFS 遍历和环检测。还做了 MCP 服务器，提供 14 个工具可被 Claude Code 调用。单一二进制，零依赖，",[453,1421,1422],{},"go install"," 即可运行。",[47,1425,1427],{"id":1426},"llm-wikipython-cli-与-llm-完全分离","llm-wiki（Python）— CLI 与 LLM 完全分离",[21,1429,1430,1431,1434],{},"Python CLI 处理所有确定性操作（解析文档、建索引、搜索、校验），",[25,1432,1433],{},"CLI 中一行 LLM 调用代码都没有","。所有智能操作通过一份 SKILL.md 文件委托给外部 Agent，你可以接任何 LLM Agent 来驱动。",[21,1436,1437],{},"格式支持非常广，用 MarkItDown 库支持 PDF、DOCX、PPTX、HTML、图片、音频、ZIP 等 20 多种格式。中文支持完善，用 jieba 做分词，有 CJK 停用词过滤。架构上采用 Clean Architecture，Domain 层零外部依赖，测试覆盖 162 个用例。",[47,1439,1441],{"id":1440},"thinking-spaceelectron-全功能工作站","Thinking-Space（Electron）— 全功能工作站",[21,1443,1444],{},"跨平台桌面应用（Mac、Windows、iOS），有完整的 UI、多标签编辑器、内嵌终端。支持 55 种以上的 Agent 能力操作，多个 AI 提供商，内置 Excalidraw 绘图、思维导图、PDF 转换、RSS 阅读器。但它与 Karpathy 的\"编译式知识库\"思路关系较松，更像一个 AI 增强的笔记工具。",[47,1446,536],{"id":536},[55,1448,1449,1465],{},[58,1450,1451],{},[61,1452,1453,1456,1459,1462],{},[64,1454,1455],{},"维度",[64,1457,1458],{},"sage-wiki",[64,1460,1461],{},"llm-wiki",[64,1463,1464],{},"Thinking-Space",[74,1466,1467,1481,1495,1509,1523,1536,1550],{},[61,1468,1469,1472,1475,1478],{},[79,1470,1471],{},"语言",[79,1473,1474],{},"Go",[79,1476,1477],{},"Python",[79,1479,1480],{},"TypeScript + Electron",[61,1482,1483,1486,1489,1492],{},[79,1484,1485],{},"LLM 集成",[79,1487,1488],{},"内建多 Provider",[79,1490,1491],{},"零 LLM，通过 SKILL.md 委托",[79,1493,1494],{},"多 Provider 直接调用",[61,1496,1497,1500,1503,1506],{},[79,1498,1499],{},"输入格式",[79,1501,1502],{},"PDF, MD",[79,1504,1505],{},"20+ 格式",[79,1507,1508],{},"Markdown + YAML",[61,1510,1511,1514,1517,1520],{},[79,1512,1513],{},"搜索",[79,1515,1516],{},"四维混合搜索",[79,1518,1519],{},"BM25 + jieba",[79,1521,1522],{},"词法模糊匹配",[61,1524,1525,1528,1531,1534],{},[79,1526,1527],{},"中文支持",[79,1529,1530],{},"无专门处理",[79,1532,1533],{},"jieba 原生支持",[79,1535,1530],{},[61,1537,1538,1541,1544,1547],{},[79,1539,1540],{},"Agent 协议",[79,1542,1543],{},"MCP 14 工具",[79,1545,1546],{},"SKILL.md",[79,1548,1549],{},"55+ Capability",[61,1551,1552,1555,1558,1560],{},[79,1553,1554],{},"许可证",[79,1556,1557],{},"MIT",[79,1559,1557],{},[79,1561,1562],{},"AGPL-3.0",[1127,1564,1565,1573,1581],{},[131,1566,1567,1570,1571],{},[25,1568,1569],{},"研究者","：有大量论文和文章要处理，想要自动编译，选 ",[25,1572,1458],{},[131,1574,1575,1578,1579],{},[25,1576,1577],{},"文档格式杂、含中文、想自由切换 Agent","：选 ",[25,1580,1461],{},[131,1582,1583,1578,1586],{},[25,1584,1585],{},"不习惯命令行、想要图形界面",[25,1587,1464],{},[16,1589,1590],{"id":1590},"社区反响与争议",[47,1592,1593],{"id":1593},"支持的声音",[1127,1595,1596,1599,1602],{},[131,1597,1598],{},"Tech podcaster Charly Wargnier 称其为\"能自我修复的活知识库\"",[131,1600,1601],{},"Lex Fridman 确认自己在用类似的设置",[131,1603,1604],{},"企业家 Vamshi Reddy 说：\"每个企业都有一个 raw\u002F 目录，没有人编译过它，这就是产品。\"Karpathy 本人点赞了这条评论",[47,1606,1607],{"id":1607},"反对与质疑",[21,1609,1610],{},[25,1611,1612],{},"1. 知识可信度问题（Epistemic Integrity）",[21,1614,1615],{},"最尖锐的批评来自 Hacker News：真正的问题不在于怎么组织知识，而在于知识可不可信。如果 LLM 把错误信息写进了 Wiki，后面所有查询都会被污染，而且你很难发现。raw\u002F 层不可变的设计提供了一个验证锚点，Lint 操作的存在也说明 Karpathy 意识到了这个问题，但目前没有完美解法。",[21,1617,1618],{},[25,1619,1620],{},"2. 认知外包风险",[21,1622,1623],{},"HN 用户 qaadika 维护着一个 4100 条笔记的 Obsidian 库，他说：\"整理知识的苦活本身就是洞察产生的过程，把这事交给 AI，你得到的知识库跟你这个人没什么关系。\"写文档的价值在于更新你自己的心智模型。",[21,1625,1626],{},[25,1627,1628],{},"3. 规模限制",[21,1630,1631],{},"Karpathy 自己说的甜蜜点是 100 篇文章、40 万词。超过这个量级，系统可能撑不住。有人警告说，到了某个临界点，Agent 自己都理不清里面的内容了。",[16,1633,1634],{"id":1634},"常见误解与正确理解",[21,1636,1637,1638,334],{},"LLM Wiki 发布后，社区出现了大量解读，其中不乏误解。澄清几个最普遍的误区 ",[37,1639,42],{"href":1640,"rel":1641},"http:\u002F\u002Fm.toutiao.com\u002Fgroup\u002F7635263462699958824\u002F",[41],[47,1643,1645],{"id":1644},"误解一llm-wiki-就是另一种-rag","误解一：LLM Wiki 就是另一种 RAG",[21,1647,1648],{},"这是最普遍的误读。RAG 的工作方式是\"检索时理解\"——每次查询都重新去原始文档里捞碎片、即时拼凑，答完即忘。而 LLM Wiki 是\"入库时理解\"——资料进入的那一刻就完成编译，知识被结构化地沉淀下来。",[21,1650,1651,1652,1655],{},"一个形象的比喻：",[25,1653,1654],{},"RAG 是仓库管理员，LLM Wiki 是图书管理员","。前者你来问一个问题，它跑进仓库捞几个箱子，拼一段答案给你；后者一次性读完所有书，建好分类目录和索引，下次有人问问题，直接走到对应的那一页。",[47,1657,1659],{"id":1658},"误解二llm-wiki-需要复杂的向量检索基础设施","误解二：LLM Wiki 需要复杂的向量检索基础设施",[21,1661,1662,1663,32],{},"恰恰相反。LLM Wiki 的设计哲学是\"简单优于复杂\"。Karpathy 自己称 index.md 为\"穷人的向量库\"——在 100 篇文章的规模下，一个纯文本的索引文件就够用了。不需要向量数据库、不需要 Embedding 模型、不需要重排序模型，",[25,1664,1665],{},"只需要大模型 + 本地文件夹",[47,1667,1669],{"id":1668},"误解三llm-wiki-交给-ai-后人类就不用管了","误解三：LLM Wiki 交给 AI 后人类就不用管了",[21,1671,1672,1673,1676,1677,1680],{},"这也是危险的误读。LLM Wiki 的人机分工是：",[25,1674,1675],{},"LLM 做苦力活","（归档、交叉引用、更新、保持一致性），",[25,1678,1679],{},"人类做决策活","（筛选材料、定义 Schema、验证质量）。Karpathy 挑的是\"人类最不擅长的事\"——人类做归档会烦、会忘、会偷懒、会前后不一致，LLM 不会。但最终的质量把控、方向判断，始终需要人类参与。",[47,1682,1684],{"id":1683},"误解四llm-wiki-是通用的知识管理方案","误解四：LLM Wiki 是通用的知识管理方案",[21,1686,1687,1688,1691],{},"LLM Wiki 最适合",[25,1689,1690],{},"领域内聚","的场景——研究一个课题、读一本书、做一个竞争分析。如果你的知识库是\"什么都往里堆\"——编程笔记、游戏攻略、设计素材、项目模板混在一起——跨领域的交叉引用只会制造噪音。有开发者拿自己积累了五六年的 Obsidian 知识库去试（几千个文件、十几个领域），结果\"啥也不是\"。这不是 LLM Wiki 的问题，而是领域不内聚的资料本身就不适合编译成单一 Wiki。",[16,1693,1694],{"id":1694},"实际使用中的五大痛点",[21,1696,1697,1698,334],{},"LLM Wiki 的理念优雅，但实际落地时有一些需要正视的挑战 ",[37,1699,42],{"href":1700,"rel":1701},"http:\u002F\u002Fm.toutiao.com\u002Fgroup\u002F7638819620891181577\u002F",[41],[47,1703,1705],{"id":1704},"痛点一规模天花板比想象中来得早","痛点一：规模天花板比想象中来得早",[21,1707,1708],{},"原始方案的索引机制是一个 index.md 文件，里面存着所有页面的摘要和链接。每次查询 LLM 都要从头读到尾。大约 200-300 篇中等长度的技术文章，就能把它撑满。之后 index.md 越来越长，上下文窗口越来越拥挤，响应越来越慢。Karpathy 自己也提到了这一点，建议规模变大后接入本地搜索引擎（如 qmd）来替代纯文本索引。",[47,1710,1712],{"id":1711},"痛点二超长文档缺乏处理方案","痛点二：超长文档缺乏处理方案",[21,1714,1715],{},"默认流程是一次性读完整篇文档。但如果你丢进去一份 200 页的技术报告或一本书，LLM 的上下文窗口直接撑不住。截断意味着后半段信息全丢，硬塞则成本暴涨、幻觉频发。这个问题在原始方案里没有明确解法，需要自己设计分块策略。",[47,1717,1719],{"id":1718},"痛点三真实成本不低","痛点三：真实成本不低",[21,1721,1722],{},"每次 Ingest 一篇新文章，LLM 要读新资料、扫描现有 Wiki 页面、更新 10-15 个关联页面、写日志。一次完整的 Ingest 实际消耗约 7.5 万到 25 万 token。按 Claude 的 API 价格计算，每篇文章的摄入成本在 $1.5-3 美元之间。如果每月摄入 50 篇，仅 Ingest 一项就要花 $75-150 美元。换便宜模型能省钱，但可能导致摘要质量下降、交叉引用混乱。",[47,1724,1726],{"id":1725},"痛点四冷启动门槛高","痛点四：冷启动门槛高",[21,1728,1729],{},"前 5-10 篇资料基本是调校期。你需要反复迭代 CLAUDE.md，告诉 LLM 该怎么分类、怎么命名、怎么建立关联。这需要你对 LLM 的行为模式有足够深的理解。Karpathy 能上手就用，因为他本人就是 AI 领域最顶尖的专家之一。对大多数人来说，写 Schema 就像做卷子最后一道大题——只会写个\"解\"字。",[47,1731,1733],{"id":1732},"痛点五lint-机制本身也会幻觉","痛点五：Lint 机制本身也会幻觉",[21,1735,1736],{},"Lint 让 LLM 检查 LLM 生成的内容，这个环节同样存在幻觉风险。最终的质量兜底，绕了一大圈，还是回到人工审阅。和你自己写笔记然后偶尔回头检查，底层逻辑上并没有本质区别，只是中间多了一层自动化。",[177,1738,1739],{},[21,1740,1741],{},"这些痛点不是 LLM Wiki 的\"致命缺陷\"，而是它的\"已知边界\"。Karpathy 的原始 Gist 本身就是一份\"想法文件\"（idea file），有意设计得抽象，目的是让你和 LLM 一起把它实例化成适合自己领域的版本。",[47,1743,1745],{"id":1744},"突破规模天花板qmd-本地搜索引擎","突破规模天花板：qmd 本地搜索引擎",[21,1747,1748,1749,1752,1753,1757],{},"Karpathy 在原文中点名推荐了 ",[25,1750,1751],{},"qmd"," 作为规模扩展的解决方案 ",[37,1754,42],{"href":1755,"rel":1756},"http:\u002F\u002Fm.toutiao.com\u002Fgroup\u002F7627860809834365474\u002F",[41],"。qmd 是一个专门为 LLM 工作流设计的本地 Markdown 搜索引擎，全程在设备端运行，不依赖任何云端 API。",[21,1759,1760,334],{},[25,1761,1762],{},"三层检索架构",[55,1764,1765,1778],{},[58,1766,1767],{},[61,1768,1769,1772,1775],{},[64,1770,1771],{},"层",[64,1773,1774],{},"技术",[64,1776,1777],{},"作用",[74,1779,1780,1793,1806],{},[61,1781,1782,1787,1790],{},[79,1783,1784],{},[25,1785,1786],{},"第一层",[79,1788,1789],{},"FTS5 全文索引（BM25）",[79,1791,1792],{},"精确关键词匹配",[61,1794,1795,1800,1803],{},[79,1796,1797],{},[25,1798,1799],{},"第二层",[79,1801,1802],{},"向量嵌入（语义检索）",[79,1804,1805],{},"语义相似度匹配，换个说法也能找到",[61,1807,1808,1813,1816],{},[79,1809,1810],{},[25,1811,1812],{},"第三层",[79,1814,1815],{},"LLM 重排序",[79,1817,1818],{},"理解查询意图后二次精排",[21,1820,1821],{},"三层结果通过 RRF（Reciprocal Rank Fusion）算法融合，最终返回最相关的内容块。",[21,1823,1824,1827],{},[25,1825,1826],{},"智能分块机制","：按 Markdown 标题边界切割，每块约 900 token，15% 重叠。这意味着 200 页的超长文档不需要一次性塞进上下文--用不同主题词多次检索，每次只取 3-5 个块（约 3000-4500 token），精准定位到需要的段落。",[21,1829,1830,334],{},[25,1831,1832],{},"如何解决五大痛点",[1127,1834,1835,1841,1847,1853],{},[131,1836,1837,1840],{},[25,1838,1839],{},"规模天花板"," - qmd 替代 index.md，有真正的混合检索索引，几千篇文章照样跑，响应速度不随规模退化",[131,1842,1843,1846],{},[25,1844,1845],{},"超长文档"," - 块级检索让 200 页文档变成可分批消化的知识单元，不再\"一锅端或截断\"二选一",[131,1848,1849,1852],{},[25,1850,1851],{},"成本"," - 每次查询不再需要把整个知识库塞进上下文，token 消耗压缩一个数量级",[131,1854,1855,1858],{},[25,1856,1857],{},"MCP 集成"," - qmd 提供 CLI 接口和 MCP 服务器，LLM 可以直接调用它作为原生工具",[21,1860,1861,1862,1865],{},"安装方式：",[453,1863,1864],{},"bun install -g qmd","，然后在 CLAUDE.md 中配置让 LLM 优先使用 qmd 搜索而非全量加载 index.md。",[47,1867,1868],{"id":1868},"成本优化策略",[21,1870,1871,1872,334],{},"LLM Wiki 的真实成本不容忽视，但可以通过以下策略大幅压缩 ",[37,1873,42],{"href":1874,"rel":1875},"http:\u002F\u002Fm.toutiao.com\u002Fgroup\u002F7642522729027011072\u002F",[41],[55,1877,1878,1891],{},[58,1879,1880],{},[61,1881,1882,1885,1888],{},[64,1883,1884],{},"策略",[64,1886,1887],{},"节省幅度",[64,1889,1890],{},"做法",[74,1892,1893,1906,1919,1932,1945,1958],{},[61,1894,1895,1900,1903],{},[79,1896,1897],{},[25,1898,1899],{},"分层模型策略",[79,1901,1902],{},"60-70%",[79,1904,1905],{},"Ingest 和 Lint 用强模型（Claude Opus \u002F GPT-4），日常查询用弱模型或本地模型",[61,1907,1908,1913,1916],{},[79,1909,1910],{},[25,1911,1912],{},"增量编译",[79,1914,1915],{},"50%",[79,1917,1918],{},"只编译新增\u002F变更的文件，不重复编译已有内容（sage-wiki 的 diff 检测 Pass 就是这个思路）",[61,1920,1921,1926,1929],{},[79,1922,1923],{},[25,1924,1925],{},"摘要优先",[79,1927,1928],{},"40%",[79,1930,1931],{},"查询时先读 Summary 页面（短），需要细节时再回溯 Raw（长），避免每次全量加载",[61,1933,1934,1939,1942],{},[79,1935,1936],{},[25,1937,1938],{},"qmd 检索替代全量加载",[79,1940,1941],{},"80%+",[79,1943,1944],{},"规模超 100 篇后，用 qmd 精准检索替代全量塞入上下文",[61,1946,1947,1952,1955],{},[79,1948,1949],{},[25,1950,1951],{},"批量 Ingest",[79,1953,1954],{},"30%",[79,1956,1957],{},"多篇短文批量传入一次编译，减少重复扫描 wiki 目录的开销",[61,1959,1960,1965,1968],{},[79,1961,1962],{},[25,1963,1964],{},"本地模型兜底",[79,1966,1967],{},"90%+",[79,1969,1970],{},"日常 Lint 和简单查询用 Ollama 本地模型，零 API 成本",[177,1972,1973],{},[21,1974,1975,1978],{},[25,1976,1977],{},"经验法则","：编译阶段省的钱，会在查询阶段十倍还回来。Ingest 用强模型是值得的投资，因为一次编译的成果会被查询成百上千次复用。",[16,1980,1981],{"id":1981},"适用场景",[47,1983,1984],{"id":1984},"个人场景",[1127,1986,1987,1993,1999,2005,2011],{},[131,1988,1989,1992],{},[25,1990,1991],{},"个人研究者"," - 追踪论文、建立知识体系",[131,1994,1995,1998],{},[25,1996,1997],{},"技术学习者"," - 整理学习笔记、关联概念",[131,2000,2001,2004],{},[25,2002,2003],{},"内容创作者"," - 管理写作素材、积累领域知识",[131,2006,2007,2010],{},[25,2008,2009],{},"独立开发者"," - 个人技术文档、项目知识沉淀",[131,2012,2013,2016],{},[25,2014,2015],{},"读书笔记"," - 类比托尔金粉丝 Wiki，把多本书的读书笔记编译成主题知识库",[47,2018,2019],{"id":2019},"团队与企业场景",[21,2021,2022,2023,334],{},"LLM Wiki 不只是个人工具，在企业场景中同样有价值 ",[37,2024,42],{"href":2025,"rel":2026},"http:\u002F\u002Fm.toutiao.com\u002Fgroup\u002F7656833389776896547\u002F",[41],[1127,2028,2029,2035,2041,2047,2053],{},[131,2030,2031,2034],{},[25,2032,2033],{},"团队知识库"," - LLM 读取 Slack 对话、会议记录、项目文档，维护一份不断更新的团队知识库。新人入职不用翻遍半年的聊天历史，直接问 Wiki",[131,2036,2037,2040],{},[25,2038,2039],{},"竞品分析"," - 追踪一个行业或公司的方方面面：新闻、财务数据、监管文件、研究报告。新信息进入时，LLM 自动更新相关分析页面，标注与旧数据的矛盾",[131,2042,2043,2046],{},[25,2044,2045],{},"尽职调查"," - 投资尽调过程中，将法律文件、财务报表、行业报告编译成结构化 Wiki，支持跨文档综合查询",[131,2048,2049,2052],{},[25,2050,2051],{},"项目文档沉淀"," - 将项目过程中的设计文档、技术决策记录、Postmortem 报告编译成 Wiki，项目结束后知识不流失",[131,2054,2055,2058],{},[25,2056,2057],{},"课程笔记"," - 整理一个学期的课程材料，自动关联概念，期末复习时直接查询 Wiki",[177,2060,2061],{},[21,2062,2063],{},"企业家 Vamshi Reddy 说：\"每个企业都有一个 raw\u002F 目录，没有人编译过它，这就是产品。\"Karpathy 本人点赞了这条评论。",[47,2065,2067],{"id":2066},"冷启动策略已有大量文章怎么办","冷启动策略：已有大量文章怎么办",[21,2069,2070,2071,2074,2075,334],{},"如果你已经积累了数百甚至上千篇 Markdown 文章，不要试图一次性全部编译。推荐",[25,2072,2073],{},"三阶段分批策略"," ",[37,2076,42],{"href":2077,"rel":2078},"http:\u002F\u002Fm.toutiao.com\u002Fgroup\u002F7627058045159211583\u002F",[41],[21,2080,2081],{},[25,2082,2083],{},"阶段一：元数据扫描（快速、低成本）",[21,2085,2086],{},"用脚本批量读取每篇文章的标题 + 前 200 字，生成一个 raw\u002Findex.csv，包含文件路径、大致主题、写作时间。这一步花费很少，但给 AI 一张全局地图。",[674,2088,2092],{"className":2089,"code":2090,"language":2091,"meta":682,"style":682},"language-bash shiki shiki-themes github-light github-dark","# 示例：批量提取元数据\nfor f in raw\u002F**\u002F*.md; do\n  title=$(head -1 \"$f\")\n  preview=$(head -20 \"$f\" | tail -19)\n  echo \"$f|$title|$preview\" >> raw\u002Findex.csv\ndone\n","bash",[453,2093,2094,2100,2123,2154,2185,2213],{"__ignoreMap":682},[932,2095,2096],{"class":934,"line":935},[932,2097,2099],{"class":2098},"sJ8bj","# 示例：批量提取元数据\n",[932,2101,2102,2106,2110,2113,2117,2120],{"class":934,"line":941},[932,2103,2105],{"class":2104},"szBVR","for",[932,2107,2109],{"class":2108},"sVt8B"," f ",[932,2111,2112],{"class":2104},"in",[932,2114,2116],{"class":2115},"sZZnC"," raw\u002F**\u002F*.md",[932,2118,2119],{"class":2108},"; ",[932,2121,2122],{"class":2104},"do\n",[932,2124,2125,2128,2131,2134,2138,2142,2145,2148,2151],{"class":934,"line":947},[932,2126,2127],{"class":2108},"  title",[932,2129,2130],{"class":2104},"=",[932,2132,2133],{"class":2108},"$(",[932,2135,2137],{"class":2136},"sScJk","head",[932,2139,2141],{"class":2140},"sj4cs"," -1",[932,2143,2144],{"class":2115}," \"",[932,2146,2147],{"class":2108},"$f",[932,2149,2150],{"class":2115},"\"",[932,2152,2153],{"class":2108},")\n",[932,2155,2156,2159,2161,2163,2165,2168,2170,2172,2174,2177,2180,2183],{"class":934,"line":953},[932,2157,2158],{"class":2108},"  preview",[932,2160,2130],{"class":2104},[932,2162,2133],{"class":2108},[932,2164,2137],{"class":2136},[932,2166,2167],{"class":2140}," -20",[932,2169,2144],{"class":2115},[932,2171,2147],{"class":2108},[932,2173,2150],{"class":2115},[932,2175,2176],{"class":2104}," |",[932,2178,2179],{"class":2136}," tail",[932,2181,2182],{"class":2140}," -19",[932,2184,2153],{"class":2108},[932,2186,2187,2190,2192,2194,2197,2200,2202,2205,2207,2210],{"class":934,"line":959},[932,2188,2189],{"class":2140},"  echo",[932,2191,2144],{"class":2115},[932,2193,2147],{"class":2108},[932,2195,2196],{"class":2115},"|",[932,2198,2199],{"class":2108},"$title",[932,2201,2196],{"class":2115},[932,2203,2204],{"class":2108},"$preview",[932,2206,2150],{"class":2115},[932,2208,2209],{"class":2104}," >>",[932,2211,2212],{"class":2115}," raw\u002Findex.csv\n",[932,2214,2215],{"class":934,"line":965},[932,2216,2217],{"class":2104},"done\n",[21,2219,2220],{},[25,2221,2222],{},"阶段二：按主题分批摄入",[21,2224,2225,2226,2229],{},"不要按时间顺序，而是",[25,2227,2228],{},"按主题聚类摄入","。例如先处理所有技术类文章，让同一主题的知识在 Wiki 里先成体系。每批 10-20 篇，编译后检查质量，调整 Schema。",[21,2231,2232],{},[25,2233,2234],{},"阶段三：增量维护",[21,2236,2237],{},"冷启动完成后，之后每新增一篇文章就做一次小 Ingest 操作。知识库进入\"日常运营\"模式。",[177,2239,2240],{},[21,2241,2242,2245],{},[25,2243,2244],{},"关键原则","：先选 50 篇你最熟悉的文章做试验，跑通整个流程，再扩展到全部。不要追求一步到位。",[16,2247,2248],{"id":2248},"局限性",[1127,2250,2251,2258,2261,2264],{},[131,2252,2253,2254,2257],{},"不适合",[25,2255,2256],{},"海量动态实时数据","（实时新闻、动态业务数据）",[131,2259,2260],{},"大规模知识库（数百篇以上长文档）编译阶段算力消耗较高",[131,2262,2263],{},"依赖大模型文本理解能力，存在少量内容幻觉风险，需人工抽检",[131,2265,2266],{},"不适合多人实时协作场景（并发编辑 Markdown 文件会有冲突）",[16,2268,2270],{"id":2269},"llm-wiki-vs-传统知识管理工具","LLM Wiki vs 传统知识管理工具",[21,2272,2273,2274,2074,2277,334],{},"LLM Wiki 不是 Obsidian、Notion 或 Roam Research 的替代品，而是对这些工具的",[25,2275,2276],{},"范式升级",[37,2278,42],{"href":2077,"rel":2279},[41],[55,2281,2282,2293],{},[58,2283,2284],{},[61,2285,2286,2288,2291],{},[64,2287,197],{},[64,2289,2290],{},"传统笔记工具（Obsidian \u002F Notion）",[64,2292,109],{},[74,2294,2295,2311,2322,2335,2346,2357,2367,2378],{},[61,2296,2297,2299,2305],{},[79,2298,209],{},[79,2300,2301,2304],{},[25,2302,2303],{},"手动整理型","，你写什么就是什么",[79,2306,2307,2310],{},[25,2308,2309],{},"AI 编译型","，LLM 帮你构建和维护",[61,2312,2313,2316,2319],{},[79,2314,2315],{},"知识增长",[79,2317,2318],{},"线性增长，第 100 条笔记不会让第 50 条变聪明",[79,2320,2321],{},"复利增长，每个新资料都让已有知识更丰富",[61,2323,2324,2327,2332],{},[79,2325,2326],{},"交叉引用",[79,2328,2329,2330],{},"依赖手动添加 ",[453,2331,455],{},[79,2333,2334],{},"自动生成，LLM 在 Ingest 时完成全套关联",[61,2336,2337,2340,2343],{},[79,2338,2339],{},"维护负担",[79,2341,2342],{},"随笔记量增加而线性增长，维护成本高",[79,2344,2345],{},"随知识量增加，LLM 自动处理，人类零维护",[61,2347,2348,2351,2354],{},[79,2349,2350],{},"知识活性",[79,2352,2353],{},"写完后基本\"死\"了，不会再被更新",[79,2355,2356],{},"持续活跃，每次 Lint 和新 Ingest 都会刷新",[61,2358,2359,2362,2365],{},[79,2360,2361],{},"查询能力",[79,2363,2364],{},"全靠搜索，无上下文理解",[79,2366,469],{},[61,2368,2369,2372,2375],{},[79,2370,2371],{},"数据结构",[79,2373,2374],{},"自由的笔记，格式不统一",[79,2376,2377],{},"严格的 Schema 约束，模板统一",[61,2379,2380,2383,2386],{},[79,2381,2382],{},"人工参与",[79,2384,2385],{},"所有内容需要你亲手写",[79,2387,2388],{},"你只负责选材料和定 Schema，LLM 写",[21,2390,2391,2392,32],{},"Karpathy 自己也用 Obsidian——但他把 Obsidian 定位为\"IDE\"，LLM 是\"程序员\"，Wiki 是\"代码库\"。你在 Obsidian 里浏览和审阅像看代码，LLM 负责编写和维护像写代码。",[25,2393,2394],{},"这不是替代关系，是分工关系",[16,2396,2398],{"id":2397},"与-ai-生态的深度集成","与 AI 生态的深度集成",[21,2400,2401,2402,334],{},"LLM Wiki 不是一个孤立的方案，它能与现有的 AI 工具链形成强大的协同效应 ",[37,2403,42],{"href":2404,"rel":2405},"http:\u002F\u002Fm.toutiao.com\u002Fgroup\u002F7656391791108801065\u002F",[41],[47,2407,2409],{"id":2408},"与-obsidian-搭配","与 Obsidian 搭配",[21,2411,2412,2413,2415,2416,2419],{},"Obsidian 天然支持 Markdown 和 ",[453,2414,455],{},"，是 LLM Wiki 的完美前端。你可以在 Obsidian 中打开 wiki\u002F 目录，实时查看 LLM 创建的页面、跟随链接跳转、在图谱视图中可视化知识网络。Karpathy 推荐的实操方式是：",[25,2417,2418],{},"一边打开 AI Agent 对话窗口，一边打开 Obsidian","，LLM 做出编辑后你实时浏览结果。",[47,2421,2423],{"id":2422},"与-claude-code-搭配","与 Claude Code 搭配",[21,2425,2426,2427,2430],{},"Claude Code 可以作为 LLM Wiki 的执行引擎。通过 ",[453,2428,2429],{},"CLAUDE.md"," 配置文件，Claude Code 能自动完成 Ingest、Query、Lint 全套操作。社区已有实现将 Claude Code 与 Obsidian 对接，形成\"Claude Code + Obsidian = 知识库王炸\"的组合。",[47,2432,2434],{"id":2433},"与-mcp-协议集成","与 MCP 协议集成",[21,2436,2437],{},"LLM Wiki 可以与 MCP 协议深度结合。例如 sage-wiki 项目就提供了 MCP 服务器，暴露 14 个工具供 Claude Code 调用——搜索知识库、读取页面、提取概念、更新索引等，全部通过标准 MCP 协议完成。这意味着你的知识库可以成为一个\"MCP 资源\"，被任何支持 MCP 的 AI 工具访问。",[47,2439,2440],{"id":2440},"与本地模型搭配",[21,2442,2443,2444,2446],{},"对于隐私敏感的场景，LLM Wiki 可以搭配本地部署的模型（如 Ollama、LM Studio）使用。虽然本地模型在编译质量上可能不如 GPT-4 或 Claude，但对于个人知识库的日常维护，完全够用。社区实现中，",[453,2445,1461],{},"（Python）项目就通过 SKILL.md 将智能操作委托给外部 Agent，你可以自由切换任何 LLM。",[16,2448,2449],{"id":2449},"最佳实践与经验建议",[21,2451,2452,2453,334],{},"综合社区的真实使用经验，以下是几条值得采纳的建议 ",[37,2454,42],{"href":2455,"rel":2456},"http:\u002F\u002Fm.toutiao.com\u002Fgroup\u002F7636002113772765723\u002F",[41],[47,2458,2460],{"id":2459},"_1-从小处着手先跑通闭环","1. 从小处着手，先跑通闭环",[21,2462,2463,2464,2467],{},"不要一上来就想把整个知识库编译完。选一个",[25,2465,2466],{},"单一领域","（比如\"学习 Transformer 架构\"或\"做竞品分析\"），先扔 5-10 篇资料进去，跑通 Ingest → Query → Lint 的完整闭环。体验过\"编译一次、多次复用\"的感觉后，再扩展到更多领域。",[47,2469,2471],{"id":2470},"_2-schema-是灵魂值得反复迭代","2. Schema 是灵魂，值得反复迭代",[21,2473,2474,2475,2478],{},"CLAUDE.md 不是一次写好的。前 5-10 篇资料的冷启动期，你会不断发现\"这个分类不对\"、\"那个模板不好用\"。每发现一次就修改一次 Schema。",[25,2476,2477],{},"最终你的 Schema 本身就是你知识管理哲学的体现","——它比任何笔记都更能反映你的思维方式。",[47,2480,2482],{"id":2481},"_3-先养-raw再建-wiki","3. 先养 raw\u002F，再建 wiki\u002F",[21,2484,2485],{},"LLM Wiki 的起点不是 Schema，不是 wiki 结构，而是你持续往里扔东西的 raw\u002F 目录。没有足够的高质量原始素材，wiki 就是空的。建议先积累 50-100 篇核心资料，再让 LLM 开始大规模编译。顺序很重要。",[47,2487,2489],{"id":2488},"_4-定期-lint别等知识腐烂","4. 定期 Lint，别等知识腐烂",[21,2491,2492],{},"把 Lint 巡检纳入你的知识管理节奏。建议每新增 5 份以上资料，或每两周，执行一次 Lint。让 LLM 检查矛盾、补全缺失链接、标记孤立页面。长期跳过的 Lint，知识库会像没有维护的代码库一样慢慢腐烂。",[47,2494,2496],{"id":2495},"_5-查询结果要回写让知识复利","5. 查询结果要回写，让知识复利",[21,2498,2499,2500,2503],{},"这是最容易忽略但最有复利价值的操作。每次你问了一个好问题，让 AI 把答案保存到 wiki 的某个分类下（如 synthesis\u002F 或 queries\u002F）。下次同样的疑问，不需要重新推导。",[25,2501,2502],{},"知识库会通过使用不断\"自我增长\"","——你问得越多，它越丰富。",[47,2505,2507],{"id":2506},"_6-注意领域隔离","6. 注意领域隔离",[21,2509,2510],{},"如果你的知识涉及多个不相关的领域，不要试图塞进同一个 Wiki。建立多个独立的 LLM Wiki 仓库，每个仓库对应一个领域。跨领域的交叉引用只会制造噪音——行业研报和游戏攻略放在同一个 Wiki 里，对任何一个领域都没有帮助。",[47,2512,2514],{"id":2513},"_7-不要为了省钱用弱模型做编译","7. 不要为了省钱用弱模型做编译",[21,2516,2517,2518,32],{},"Ingest 阶段使用弱模型，摘要质量会显著下降、交叉引用会混乱。建议 Ingest 和 Lint 用强模型（Claude、GPT-4），日常查询可以用弱模型或本地模型。",[25,2519,2520],{},"编译阶段省的钱，会在查询阶段十倍还回来",[16,2522,2524],{"id":2523},"faq常见问题","FAQ：常见问题",[47,2526,2528],{"id":2527},"q-llm-wiki-会取代-rag-吗","Q: LLM Wiki 会取代 RAG 吗？",[21,2530,2531,2532,2535,2536,2539],{},"不会。两者解决不同问题。RAG 适合",[25,2533,2534],{},"大规模、实时性要求高","的场景（企业知识库、客服 Bot），LLM Wiki 适合",[25,2537,2538],{},"中小规模、深度积累","的场景（个人研究、团队知识沉淀）。Karpathy 自己也说不排斥 RAG--当 Wiki 规模超过上下文窗口时，在 Wiki 层之上叠加 RAG 检索是自然的演进方向。",[47,2541,2543],{"id":2542},"q-我已经有-obsidian-notion-知识库了要推倒重来吗","Q: 我已经有 Obsidian \u002F Notion 知识库了，要推倒重来吗？",[21,2545,2546,2547,2550],{},"不需要推倒重来。你的现有笔记就是天然的 raw\u002F 目录。新建一个平行的 wiki\u002F 目录，让 LLM 从你的已有笔记中编译出结构化 Wiki。",[25,2548,2549],{},"raw\u002F 是输入，wiki\u002F 是输出","，两者并行存在。",[47,2552,2554],{"id":2553},"q-llm-wiki-适合多人协作吗","Q: LLM Wiki 适合多人协作吗？",[21,2556,2557],{},"原始设计是个人工具。Markdown 文件的并发编辑会产生冲突，就像两个人同时编辑同一个代码文件一样。但社区已有解决方案：将 wiki\u002F 目录放入 Git 版本控制，用分支和合并管理多人编辑。sage-wiki 等开源实现已支持 AI 辅助的冲突合并--LLM 自动检测冗余内容、合并不同视角的编辑。对于小型团队（3-5 人），这是可行的。",[47,2559,2561],{"id":2560},"q-用什么模型做-llm-wiki-最好","Q: 用什么模型做 LLM Wiki 最好？",[55,2563,2564,2576],{},[58,2565,2566],{},[61,2567,2568,2570,2573],{},[64,2569,66],{},[64,2571,2572],{},"推荐模型",[64,2574,2575],{},"原因",[74,2577,2578,2591,2603,2616],{},[61,2579,2580,2585,2588],{},[79,2581,2582],{},[25,2583,2584],{},"Ingest（编译）",[79,2586,2587],{},"Claude Sonnet \u002F GPT-4",[79,2589,2590],{},"需要强理解力和长上下文，质量直接影响整个 Wiki",[61,2592,2593,2598,2600],{},[79,2594,2595],{},[25,2596,2597],{},"Lint（巡检）",[79,2599,2587],{},[79,2601,2602],{},"需要逻辑推理能力来检测矛盾和断链",[61,2604,2605,2610,2613],{},[79,2606,2607],{},[25,2608,2609],{},"Query（查询）",[79,2611,2612],{},"GPT-4o-mini \u002F Claude Haiku \u002F 本地模型",[79,2614,2615],{},"已编译的知识查询不需要最强模型，省钱",[61,2617,2618,2623,2626],{},[79,2619,2620],{},[25,2621,2622],{},"中文场景",[79,2624,2625],{},"DeepSeek \u002F Qwen",[79,2627,2628],{},"中文理解和分词更精准",[47,2630,2632],{"id":2631},"q-llm-编译出来的内容有错误怎么办","Q: LLM 编译出来的内容有错误怎么办？",[21,2634,2635],{},"三个防线：",[128,2637,2638,2644,2650],{},[131,2639,2640,2643],{},[25,2641,2642],{},"raw\u002F 层不可变"," - 任何 Wiki 内容都可以追溯回原始文件验证",[131,2645,2646,2649],{},[25,2647,2648],{},"Lint 巡检"," - 定期检查矛盾和过时信息",[131,2651,2652,2655],{},[25,2653,2654],{},"人工抽检"," - 对 confidence 为 low 的页面重点审核",[21,2657,2658],{},"LLM Wiki 的竞争对手不是\"完美的知识管理\"，而是\"不做知识管理\"。一个不完美但持续维护的知识系统，比一个完美但永远没人维护的系统好一万倍。",[47,2660,2662],{"id":2661},"q-多久做一次-lint","Q: 多久做一次 Lint？",[21,2664,2665],{},"建议两种触发方式：",[1127,2667,2668,2674],{},[131,2669,2670,2673],{},[25,2671,2672],{},"定量触发","：每新增 5 份资料后执行一次",[131,2675,2676,2679],{},[25,2677,2678],{},"定时触发","：每两周执行一次",[21,2681,2682,2683,2686],{},"如果知识库更新不频繁，每月一次也可以。关键是",[25,2684,2685],{},"不要跳过","--长期不 Lint 的知识库会像没有测试的代码库一样，慢慢腐烂到不可信。",[47,2688,2690],{"id":2689},"q-能用本地模型完全离线运行-llm-wiki-吗","Q: 能用本地模型完全离线运行 LLM Wiki 吗？",[21,2692,2693,2694,2696],{},"可以。搭配 Ollama 或 LM Studio 部署本地模型（如 Qwen 2.5、Llama 3），配合 qmd 做本地检索，整个 LLM Wiki 完全在本地运行，零 API 成本、零数据外泄。代价是编译质量可能不如 Claude \u002F GPT-4，需要更频繁的人工抽检。",[453,2695,1461],{},"（Python）项目就通过 SKILL.md 将智能操作委托给外部 Agent，你可以接任何本地模型。",[16,2698,2699],{"id":2699},"总结",[21,2701,2702,2703,32],{},"LLM Wiki 是知识管理领域的一次范式创新。它跳出了传统 RAG\"检索+拼接\"的固有思维，用\"编译器模式\"实现了知识的前置加工与长期沉淀。它的核心价值不在于取代 RAG，而是",[25,2704,2705],{},"弥补 RAG 在长期知识沉淀、体系化构建、轻量化运维上的短板",[21,2707,2708],{},"Karpathy 的底层哲学可以概括为：",[128,2710,2711,2717,2723,2732,2738],{},[131,2712,2713,2716],{},[25,2714,2715],{},"编译优于检索"," — 提前让 LLM 理解文档，而不是查询时临时理解",[131,2718,2719,2722],{},[25,2720,2721],{},"质量优于数量"," — 500 字精炼摘要 > 5000 字原文",[131,2724,2725,2728,2729,2731],{},[25,2726,2727],{},"显式关联优于隐式"," — ",[453,2730,918],{}," > Embedding 空间相似度",[131,2733,2734,2737],{},[25,2735,2736],{},"简单优于复杂"," — 如果能全量加载，就不需要复杂的检索系统",[131,2739,2740,2743],{},[25,2741,2742],{},"Schema 驱动"," — 修改文档即修改行为，非技术人员也能参与",[21,2745,2746,2747,2750],{},"对于科研人员、开发者、终身学习者而言，LLM Wiki 让零散资料逐步沉淀为结构化、可复用的个人知识资产。与传统的笔记整理不同，它的本质是",[25,2748,2749],{},"人机协同的知识运营","——人类负责筛选方向和校验质量，AI 负责编译、关联、维护等重复性工作，二者共同构建一个持续进化的知识体系。",[177,2752,2753],{},[21,2754,2755],{},"如果你研究的领域需要深度理解，别把所有整理工作都扔给 AI。用它来打理交叉引用、更新索引、整理结构，但概念之间的关联和判断，还是自己来比较靠谱。",[16,2757,2758],{"id":2758},"延伸阅读",[1127,2760,2761,2768,2775,2782,2789,2796,2803,2810,2816],{},[131,2762,2763],{},[37,2764,2767],{"href":2765,"rel":2766},"https:\u002F\u002Fgist.github.com\u002Fkarpathy\u002F442a6bf555914893e9891c11519de94b0",[41],"Andrej Karpathy 的原始 Gist",[131,2769,2770,2774],{},[37,2771,2773],{"href":2772},"\u002Fwiki\u002Frag.html","RAG（检索增强生成）"," - 了解传统方案",[131,2776,2777,2781],{},[37,2778,2780],{"href":2779},"\u002Fwiki\u002Fmcp.html","MCP（Model Context Protocol）"," - AI 工具连接协议",[131,2783,2784,2788],{},[37,2785,2787],{"href":2786},"\u002Fcoding\u002Flocal\u002Follama.html","Ollama"," - 本地部署大模型的工具",[131,2790,2791,2795],{},[37,2792,2794],{"href":2793},"\u002Fcoding\u002Fcli\u002Fclaude-code.html","Claude Code"," - 命令行 AI 编程助手",[131,2797,2798,2802],{},[37,2799,2801],{"href":2800},"\u002Fcoding\u002Flocal\u002Flm-studio.html","LM Studio"," - 本地模型图形化管理工具",[131,2804,2805,2809],{},[37,2806,2808],{"href":2807},"\u002Fagent\u002Fprotocol\u002Fsmithery.html","Smithery"," - MCP 服务器一站式发现与安装平台",[131,2811,2812,2815],{},[37,2813,83],{"href":2814},"\u002Fwiki\u002Fvibe-coding.html"," - Karpathy 提出的人机协作编程范式",[131,2817,2818,2822],{},[37,2819,2821],{"href":2820},"\u002Fwiki\u002Fembedding.html","Embedding"," - 向量嵌入基础概念，理解 RAG 检索原理",[2824,2825,2826],"style",{},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html pre.shiki code .sJ8bj, html code.shiki .sJ8bj{--shiki-default:#6A737D;--shiki-dark:#6A737D}html pre.shiki code .szBVR, html code.shiki .szBVR{--shiki-default:#D73A49;--shiki-dark:#F97583}html pre.shiki code .sVt8B, html code.shiki .sVt8B{--shiki-default:#24292E;--shiki-dark:#E1E4E8}html pre.shiki code .sZZnC, html code.shiki .sZZnC{--shiki-default:#032F62;--shiki-dark:#9ECBFF}html pre.shiki code .sScJk, html code.shiki .sScJk{--shiki-default:#6F42C1;--shiki-dark:#B392F0}html pre.shiki code .sj4cs, html code.shiki .sj4cs{--shiki-default:#005CC5;--shiki-dark:#79B8FF}",{"title":682,"searchDepth":947,"depth":947,"links":2828},[2829,2832,2836,2841,2846,2849,2855,2856,2860,2866,2870,2876,2885,2890,2891,2892,2898,2907,2916,2917],{"id":18,"depth":941,"text":19,"children":2830},[2831],{"id":49,"depth":947,"text":50},{"id":118,"depth":941,"text":119,"children":2833},[2834,2835],{"id":122,"depth":947,"text":123},{"id":167,"depth":947,"text":168},{"id":187,"depth":941,"text":188,"children":2837},[2838,2839,2840],{"id":326,"depth":947,"text":326},{"id":404,"depth":947,"text":405},{"id":540,"depth":947,"text":541},{"id":669,"depth":941,"text":669,"children":2842},[2843,2844,2845],{"id":685,"depth":947,"text":686},{"id":695,"depth":947,"text":696},{"id":717,"depth":947,"text":718},{"id":789,"depth":941,"text":789,"children":2847},[2848],{"id":922,"depth":947,"text":923},{"id":1074,"depth":941,"text":1074,"children":2850},[2851,2852,2853,2854],{"id":1077,"depth":947,"text":1078},{"id":1104,"depth":947,"text":1105},{"id":1121,"depth":947,"text":1122},{"id":1158,"depth":947,"text":1159},{"id":1168,"depth":941,"text":1168},{"id":1177,"depth":941,"text":1178,"children":2857},[2858,2859],{"id":1181,"depth":947,"text":1181},{"id":1204,"depth":947,"text":1204},{"id":1403,"depth":941,"text":1403,"children":2861},[2862,2863,2864,2865],{"id":1412,"depth":947,"text":1413},{"id":1426,"depth":947,"text":1427},{"id":1440,"depth":947,"text":1441},{"id":536,"depth":947,"text":536},{"id":1590,"depth":941,"text":1590,"children":2867},[2868,2869],{"id":1593,"depth":947,"text":1593},{"id":1607,"depth":947,"text":1607},{"id":1634,"depth":941,"text":1634,"children":2871},[2872,2873,2874,2875],{"id":1644,"depth":947,"text":1645},{"id":1658,"depth":947,"text":1659},{"id":1668,"depth":947,"text":1669},{"id":1683,"depth":947,"text":1684},{"id":1694,"depth":941,"text":1694,"children":2877},[2878,2879,2880,2881,2882,2883,2884],{"id":1704,"depth":947,"text":1705},{"id":1711,"depth":947,"text":1712},{"id":1718,"depth":947,"text":1719},{"id":1725,"depth":947,"text":1726},{"id":1732,"depth":947,"text":1733},{"id":1744,"depth":947,"text":1745},{"id":1868,"depth":947,"text":1868},{"id":1981,"depth":941,"text":1981,"children":2886},[2887,2888,2889],{"id":1984,"depth":947,"text":1984},{"id":2019,"depth":947,"text":2019},{"id":2066,"depth":947,"text":2067},{"id":2248,"depth":941,"text":2248},{"id":2269,"depth":941,"text":2270},{"id":2397,"depth":941,"text":2398,"children":2893},[2894,2895,2896,2897],{"id":2408,"depth":947,"text":2409},{"id":2422,"depth":947,"text":2423},{"id":2433,"depth":947,"text":2434},{"id":2440,"depth":947,"text":2440},{"id":2449,"depth":941,"text":2449,"children":2899},[2900,2901,2902,2903,2904,2905,2906],{"id":2459,"depth":947,"text":2460},{"id":2470,"depth":947,"text":2471},{"id":2481,"depth":947,"text":2482},{"id":2488,"depth":947,"text":2489},{"id":2495,"depth":947,"text":2496},{"id":2506,"depth":947,"text":2507},{"id":2513,"depth":947,"text":2514},{"id":2523,"depth":941,"text":2524,"children":2908},[2909,2910,2911,2912,2913,2914,2915],{"id":2527,"depth":947,"text":2528},{"id":2542,"depth":947,"text":2543},{"id":2553,"depth":947,"text":2554},{"id":2560,"depth":947,"text":2561},{"id":2631,"depth":947,"text":2632},{"id":2661,"depth":947,"text":2662},{"id":2689,"depth":947,"text":2690},{"id":2699,"depth":941,"text":2699},{"id":2758,"depth":941,"text":2758},"architecture","md",{},"\u002Fwiki\u002Fllm-wiki","2026-07-10",[2924,2925,2926],"claude-sonnet-4","gpt-5","deepseek-r1",[2928,2929,2930,2931,2932],"coding\u002Flocal\u002Follama","coding\u002Flocal\u002Flm-studio","coding\u002Fcli\u002Fclaude-code","coding\u002Fide\u002Fcursor","agent\u002Fprotocol\u002Fsmithery",{"title":11,"description":682},"wiki\u002Fllm-wiki","Andrej Karpathy 提出的新型知识管理范式：将大模型作为知识编译器，把原始资料预编译为结构化 Markdown 维基，取代传统 RAG 的即时检索模式。",[109,2937,2938,2939,2940,2941,2942,2943,2944],"知识管理","RAG替代","Karpathy","本地知识库","知识编译","人机协作","Obsidian","知识库架构","2026-07-12","wdOqlYsTL7O6GQ8svLnBy2CLfYh2sJncwnl6colm1P4",1784044506299]