三个月前我写过一份授权许可对比。我记得写过，脑子里还能浮现出它的标题、结论，以及那张对比三个方案的表格。可我就是找不到它。
那时我已经有 500 多份文档：架构决策、研究笔记、部署手册、会议纪要。全是过去几个月里借助 AI 专注工作的产物。每一份单独看都言之成理，合在一起却成了一个我无法导航的集合。
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 说要把它弄出来的那个地方。
单人工具加上版本控制，并不会自动变成团队工具。从“我能用”到“我们能用”，需要的是完全不同的架构。
在现有追踪系统上打补丁
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。开源，不按席位收费。
硬盘终于有了搜索引擎。