# 我用 AI 写了 500 份文档，然后什么都找不到了 三个月前我写过一份授权许可对比。我记得写过，脑子里还能浮现出它的标题、结论，以及那张对比三个方案的表格。可我就是找不到它。 那时我已经有 500 多份文档：架构决策、研究笔记、部署手册、会议纪要。全是过去几个月里借助 AI 专注工作的产物。每一份单独看都言之成理，合在一起却成了一个我无法导航的集合。 ![Obsidian 图谱视图，显示数百个互不相连的文档节点](/media/images/90/46/90462ccd-0e4e-411f-9c4c-8c3ea0920b33-obsidian-vault-knowledge.png) 500 多份文档，外加几本导入的参考书。知识就在那里，却够不着。 2005 年，Thomas Limoncelli 出版了一本面向系统管理员的时间管理书。书里的核心类比让我至今印象深刻：你的大脑是内存（RAM），快，但容量有限，一断电就没了。要把工单系统当硬盘用，把一切都写下来，这样你就可以放心地忘掉。 我们听进去了。我们建了维基（Wiki）、工作项追踪系统、Notion 工作区、Obsidian 库，硬盘越做越大。但没人追问一句：搜索引擎在哪里？ 现有的追踪系统里，工作项（Issue）下塞满了冗长的技术评论。架构决策、表结构讨论、调研结论，全埋在一层层回复里。而搜索只认关键词：你搜“认证流程”，一无所获，因为评论里写的是“登录步骤”。你附上一张报错截图，它就从搜索里消失了。知识明明在系统里，却取不出来。 问题不在于我们不记录。我们记得比以往任何时候都多。问题在于，记下来之后怎么再找回来。 ## 把一切都写下来 第一阶段完全照 Limoncelli 的方子来：每个决策、每条发现都写成一份文档。20 份文档时，这套办法没问题。到了 50 份，你开始忘记哪些已经写过。到了 100 份，你花在翻找旧笔记上的时间比写新笔记还多。到了 500 份，这个集合就成了一座埋葬美好初衷的坟场。 于是我把结构自动化了。我让 AI 助手为每份文档生成 YAML 元数据：压缩摘要、标签、项目名、日期、状态、估算的 token 数。内容一变，AI 就自动更新这些字段。 接着我更进一步，搭了一套清单（manifest）系统：根目录下一个 `_manifest.yaml`，列出每个项目及其文档数量；每个项目再有一份自己的清单，记录每份文档的摘要、标签、依赖关系和 token 估算。想法是给 AI 一份目录：先读 200 个 token 的清单，再决定要不要去 grep 那 50,000 个 token 的正文。省时间，也省钱。 结构大致如下（项目名改过了，但形态是真实的）： ``` # _manifest.yaml (root) total_documents: 738 sections: - section: projects/portfolio-tracker document_count: 6 types: [architecture, research] - section: projects/speech-api document_count: 10 types: [guide, reference] - section: projects/seo-toolkit document_count: 6 types: [research] - section: servers document_count: 5 types: [server-config] ``` 每个项目目录都有自己的清单，记录每份文档的细节： ``` # projects/portfolio-tracker/_manifest.yaml documents: - path: billing-design.md summary: Subscription billing with prorated upgrades token_estimate: 4237 depends_on: [investment-memo] - path: competitive-landscape.md summary: Market analysis after two competitors shut down token_estimate: 4505 - path: feature-ideas.md summary: AI-powered alerts, screener, multi-source data token_estimate: 2863 depends_on: [competitive-landscape, investment-memo] ``` 每份文档还带有自己的 YAML frontmatter，AI 读完头部就能决定要不要继续往下读： ``` # projects/portfolio-tracker/billing-design.md --- id: pt-billing-design project: portfolio-tracker type: architecture status: active summary: Subscription billing: calendar-month cycles, prorated upgrades, payment gateway integration tags: [billing, subscriptions, payments] token_estimate: 4237 --- # Feature ideas *Date: 2026-02-18* *Status: Draft specification* *Related: [investment-memo.md](investment-memo.md), [competitive-landscape.md](competitive-landscape.md), [monetization-brief.md](monetization-brief.md)* ``` AI 会先读 frontmatter，看一眼摘要和标签，不相关就直接跳过。顶部的关联链接把文档连成一张网：投资备忘录链到竞品分析，竞品分析链到功能规格，功能规格又链回商业化简报。我其实是在用 Markdown 文件和 YAML 头部搭一个维基，再靠脚本维持交叉引用的同步。 某一刻我退后一步，审视自己搭出来的东西：元数据字段、交叉链接的文档、基于 Git 的版本追踪、清单索引、状态标签。这分明就是一个项目追踪系统加一个维基，只不过是用脚本和 YAML 勉强粘在一起的。它覆盖了从副业项目（一个债券筛选器的想法、一个 API 封装）到基础设施文档和研究笔记的一切。我写了脚本自动重新生成清单，还加了指令让 AI 先读清单、判断哪些文档相关，然后才读全文。 这套东西一度运转得相当不错。我可以按项目、按类型、按依稀记得的标签筛选。AI 几秒钟就能扫完清单，直奔需要的文档。但底层仍然是关键词搜索。清单能告诉 AI 东西在*哪里*，却说不清东西*是什么意思*。我搜“定价策略”，它找不到商业化简报，因为摘要里写的是“免费增值订阅模式”。同一个概念，不同的措辞。清单让导航变高效了，却没让检索变聪明。 后来我开始和一位朋友合作一个项目。他不是开发者。我告诉他，元数据、结构、所有工具链都由我负责，他只管写。我们选了 Obsidian，用 Git 同步。 立刻就崩了。崩的不是写作，是同步。每次改动都要提交一次。他改了文件，我改了元数据，两个人一起推送，合并冲突。对一个非技术人员来说，Git 合并冲突就是一道墙：`HEAD`、`<<<<<<<`、`>>>>>>>`。他本不该需要知道这些是什么意思。 把这事放大到三四个人。一个小团队，一家小公司。每个人都要写，每个人都要找东西，没人想学 Git。几周之内，大家不再提交。然后不再写。知识重新缩回每个人的脑子里，正好回到 Limoncelli 说要把它弄出来的那个地方。 ![Obsidian 图谱视图，显示少数几个相连的簇，大部分节点仍是孤立的](/media/images/0b/fa/0bfa9a6f-0a79-45a1-aa2c-c2801209db31-obsidian-vault-project.png) 手动加链接有点用，但撑不起规模。 单人工具加上版本控制，并不会自动变成团队工具。从“我能用”到“我们能用”，需要的是完全不同的架构。 ## 在现有追踪系统上打补丁 Markdown 加 Git 在协作上失败了。顺理成章的下一步：找一个现成的开源项目追踪系统。Web 界面、多用户、没有合并冲突。 我写了一个 Python 命令行工具，让 AI 助手可以操作这个系统：创建工作项、更新状态、添加评论。我还给 AI 单独开了一个用户账号，这样动态日志里能分清哪些是人做的、哪些是 AI 做的。这部分是好用的。 然后我需要在工作项上加自定义元数据：项目阶段、组件、commit 哈希、分支。系统不支持任意字段。于是我把 YAML frontmatter 塞进工作项描述里，再在上面搭一层筛选逻辑。补丁叠补丁。 评论也变得重要起来。冗长的技术讨论、埋在回复串里的架构决策，搜索必须覆盖这些。接着是维基。对 AI 上下文窗口来说太长的文档，还需要分块和摘要。 命令行工具还有一个更深层的问题：AI 的每一条命令都要人工确认。是、否、是、否，没完没了。全部自动放行？那等于把不受限制的 shell 权限交给了 AI。MCP（Model Context Protocol，模型上下文协议）用结构化工具取代原始命令，解决了确认的问题。但 MCP 的权限是在客户端这边管的。客户端配错了，权限形同虚设。所以我在服务端做了一层权限控制：由追踪系统自己决定每个 AI 智能体（AI agent）能做什么，不管调用方是哪个客户端。权限和数据放在同一个地方。 版本管理是另一个缺口。用文件的话，即便 AI 会自动提交，人也会忘。AI 覆盖了某处内容，上一个版本就没了。没有 diff，没有历史，没有退路。 看着这一堆变通方案，我意识到自己并不是在扩展一个追踪系统，而是在一个处处抗拒我的东西上面搭建另一个产品。该停止打补丁，开始正式构建了。 ## 理解语义的搜索 关键词搜索之所以失效，是因为人的用词并不一致。一月你写的是“认证流程”，三月写的是“登录步骤”，六月写的是“SSO 集成”。同一个概念，三种说法。关键词搜索把它们当作毫不相干的东西。 混合搜索解决了这个问题。向量嵌入捕捉语义，全文搜索处理精确词条。两者结合，搜“认证是怎么工作的”就能找出这三份文档，并按相关度排序。再加上元数据筛选：按项目、组件、日期范围或任意自定义字段收窄范围。搜索知道内容的含义，而不只是认得其中的字词。 然后是最后一块。AI 智能体直接查询知识库。你不用搜，智能体替你搜。而且很省：系统不会把一整篇 10,000 字的页面塞进上下文，而是返回带章节标题的摘要，智能体只请求自己需要的那一节。原本要烧掉 15,000 个 token 的查询，现在只用 600 个。减少 96%，直接换来更低的 API 费用，以及上下文窗口里更多留给真正工作的空间。 每一次编辑都会自动生成版本。不管是人还是 AI，不管来自浏览器还是 API。任意两个版本之间都有完整 diff，一键回退。没人需要记得去提交。 ## 缺失的那一层 把 Limoncelli 的类比推到底： 大脑是内存。这我们早就知道。 工单系统是硬盘。这我们建好了。 混合搜索是搜索引擎。它从来不在追踪系统里。 能访问知识库的 AI 智能体是 DMA 控制器（不经过 CPU 直接读取磁盘的硬件）。这正是我们现在在造的。 二十年来我们一直在做更大的硬盘：更多文档、更多维基、更多 Notion 页面。检索层从来没有过。知识是存在的，只是拿不到。 ## 所以我做了一个东西 一个自托管（私有化部署）的平台：搜索理解语义，元数据有结构，版本自动生成，权限在服务端强制执行，AI 智能体查询知识库也不会吃掉你的上下文窗口。 它叫 [Specivo](https://github.com/specivo/specivo)。开源，不按席位收费。 硬盘终于有了搜索引擎。