我把地铁里收藏的 2000 多篇文章，编译成了一座 LLM Wiki

每天上下班地铁上，最容易发生的一件事，就是看到一篇文章，觉得“这个以后肯定有用”，然后点收藏。

AI、LLM、RAG、Agent、Harness、Skill、模型评测、UI 自动化、接口自动化、性能测试、知识图谱、CLI、GitHub 工具……这些主题看上去散，实际做事时又总会撞到一起。

收藏夹刚开始还挺像回事。

过几个月，问题就来了：要设计一套 Agent 评测、补一段 UI 自动化链路，或者判断一个新工具值不值得试时，我明明记得看过相关内容，却只剩下一句“好像在哪收藏过”。

这时才发现，收藏不是沉淀。

它只是把“以后再看”换了个地方堆着。

后来我做了两件事：一件是把收藏做成可公开查阅的技术文章目录；另一件是把本地原料交给 LLM Wiki 编译，生成可以检索、关联和体检的知识结构。

前者是入口，后者是工作台。

这两个东西放在一起，才比较像一套能长期养下去的知识系统。

收藏夹的问题，不是文章太多

很多人整理知识库，第一反应是分目录。

AI 一个文件夹，测试一个文件夹，Agent 再来一个。开始时没问题，目录甚至会带来一种“生活正在变好”的错觉。

但真实问题不按目录边界出现。

比如“怎么评测一个 UI Agent”，里面既有多模态输入，也有任务集、测试环境、执行轨迹、断言、失败归因和回归。它既不是单纯的 UI 自动化，也不是单纯的 LLM 评测。

目录可以收纳文件，却表达不了这些关系。

所以真正需要的，不只是一个更大的收藏夹，而是两层东西：外层让人能按主题快速找到原文；内层让资料之间能长出关联。

先把能公开的部分做成一张目录

这个项目现在不只是 LLM Wiki 框架，也收录我认为值得学习和技术查阅的文章入口。

公开目录里，每一行只有四个字段：标题、标签、原文链接、收藏时间。没有文章正文、摘要、图片或附件。

截至 2026 年 9 月 13 日，目录里有 2,028 条带 HTTP(S) 原文链接的记录，已经生成 Markdown 表格，可以直接点击“打开原文”。

想找 Agent 评测、AI 测试、Skill、OpenClaw、Obsidian 或某个 GitHub 工具时，先按标签和标题筛一遍，再回到原始来源阅读。它不是替代原文，而是把自己长期积累的“信息入口”交出来。

收录方向目前主要是：

• AI、LLM、RAG、模型评测与 AI 认知
• Agent 开发、Harness、Skill、上下文和多 Agent 协作
• Agent 评测、LLM 评测、可观测性与质量工程
• UI 自动化、接口自动化、性能测试与测试开发
• 知识图谱、Obsidian、CLI、AI 开发工具和开源项目

说白了，这一层不是在证明“我看过很多”。

它更像一张持续更新的技术阅读地图：遇到问题时，至少不用从算法推荐和浏览器历史里重新捞针。

再把本地资料编译成 LLM Wiki

目录解决“从哪里开始找”，但还不够解决“这些内容之间有什么关系”。

这就是 LLM Wiki 的位置。

它借用的思路很简单：把 Markdown 当源代码，把整理规则和 LLM 当编译器，把文章页、概念页、索引和健康报告当成产物。

文章 / 笔记 / 剪藏
        ↓
解析 → 概念提取 → 互链 → 索引 → 结构体检
        ↓
可浏览、可搜索、可回溯的 Wiki

在本地工作台里，文章可以来自正式文章、日常笔记和外部剪藏。编译时会优先利用标题关键词、frontmatter 标签和正文词频提取概念；当两篇文章共享至少两个概念时，再生成同主题互链。

因此，搜“Agent 评测”时，不必只命中标题里正好写了这四个字的内容。Task、Environment、Trajectory、Grader、测试集、失败样本、可观测性这些在工程里总会一起出现的对象，也有机会被串起来。

这才是它比普通收藏夹多出来的一点东西。

不是资料突然变聪明了，而是资料有了能被验证的结构。

自动化的重点，不是让脚本多跑几次

知识库一旦持续增长，最怕两件事：一是每次整理都要手工重来；二是系统看似跑通了，实际没人知道结果从哪里来。

所以这套工作台的主线并不复杂：新增或修改资料后做增量编译，刷新索引和健康检查；确认有价值的问答可以归档回写，再进入下一轮编译。

每一层都有明确去处：原料在哪、生成页在哪、概念怎么来的、体检出了什么问题，都能回查。

能跑不等于可控。

对外公开的文章目录也一样。它不是手工复制一份 CSV 后就不管了，而是由本地 frontmatter 自动导出，并在每天的本机定时任务中重新生成 Markdown 表格和 CSV，再提交到 GitHub。

这样新增一篇可公开索引的剪藏，目录会自己更新；但正文不会被顺手带出去。

这道边界，不能靠“我觉得没问题”

最开始想开源时，我也差点把整个 Wiki 目录一把推上去。

后来停下来一看，链路有点长：外部剪藏的原文、图片、编译后的摘要、内容拆解、概念页和互链，很多都不是“换个格式就能自由分发”的东西。

所以现在把公开和私有分开了。

层级	公开什么	为什么
文章目录	标签、标题、原文链接、收藏时间	方便学习和回到来源
LLM Wiki 框架	编译、概念提取、互链、搜索、体检、归档脚本	任何人可用自己的 Markdown 搭建
原始剪藏与完整 Wiki 产物	默认不公开	可能包含第三方正文或其重述

如果原文是自己写的、拥有明确开放许可，或者已经逐篇确认授权，完整 Wiki 产物当然可以单独公开。

但对于普通网络剪藏，公开目录和原文链接已经足够有用。边界收紧一点，项目反而更能长期维护。

别把开源理解成把硬盘一键同步出去。

真正能复用的，是规则、脚本、目录和方法；不是把别人的内容换个目录继续分发。

如果你也有一个快要失控的收藏夹

可以从最小动作开始。

先统一四个字段：标题、标签、原文链接、收藏时间。不要急着让模型总结一切，也不用第一天就搭知识图谱。

目录能稳定更新之后，再把自己的笔记、项目文档和有授权的资料接进编译链路，慢慢补概念、互链、搜索和体检。

先把入口收住，再让关联生长。

我现在越来越觉得，地铁上的十分钟不一定要立刻产出什么。看完一篇文章，留下一个能回来的入口，就已经够了。

剩下的交给时间、规则和下一次真正需要它的场景。

原始方法论：Andrej Karpathy 关于 LLM Wiki 的说明

GitHub 地址：xsoway/llm-wiki-knowledge-vault

#LLM #知识库 #Agent #测试开发 #开源项目