敲下最后一行 Commit 信息，git push origin main，这个博客的雏形算是正式上线了。不是那种花里胡哨的 CMS，也不是 WordPress 套壳，是我自己用 Next.js 和 Supabase 攒出来的，核心就一个：语义检索。这年头，谁还靠关键词搜博客？你记得住自己三年前写过“多线程爬虫绕过频率限制的三种野路子”这种标题吗？反正我记不住。但语义检索记得，你问“怎么让爬虫跑快点别被封”，它能把那篇文章翻出来。
搞这个的初衷很简单，我受够了。受够了在 Notion、语雀、本地 Markdown、甚至微信收藏里散落着过去十年所有的技术碎片、踩坑记录和一闪而过的想法。它们像沉在海底的硬盘，我知道里面有东西，但捞不上来。以前觉得有个搜索框就行，后来发现，你搜“Axure 交互”，根本找不着那篇讲“如何用动态面板模拟微信下拉刷新”的笔记，因为标题里没写“Axure”。信息检索的精度，直接决定了这些碎片是资产还是垃圾。
技术栈选型折腾了小半个月。向量数据库这块，Pinecone 太贵，Chroma 本地部署麻烦，最后选了 Supabase 的 pgvector 扩展。理由就一个：省心。我的博客数据（文章、笔记、代码片段）本身就在 Postgres 里，用 pgvector 等于原生支持，不用再搞一套外部服务，链路短，出问题好排查。Embedding 模型用的 text-embedding-3-small，够用，便宜，速度也快。流程是这样跑的：博客编译构建的时候，我会用一个 Node 脚本，把所有的 Markdown 内容过一遍，提取正文，去掉 Front Matter，然后分批调用 OpenAI 的 Embedding API 生成向量，存到 pgvector 的一个专门表里，和文章表通过外键关联。
真正的难点在检索链路的构建和优化上。你不能直接把用户问题扔去生成向量然后做余弦相似度搜索就完事了，那会出来一堆相关但没用的东西。我搞了个三层过滤：第一层，语义搜索，用 pgvector 的 <-> 操作符找最相似的 Top 10 个文本块（我把长文章按段落切分了）。第二层，关键词增强，从用户问题里提取实体名词，在语义结果里做二次权重匹配。第三层，时间衰减，我故意加了个小 trick，让最近两年内的内容权重更高——因为我发现五年前我写的“微信小程序审核避坑指南”，一半的 API 现在都已经废弃了，老古董的参考价值得打折。这个 RAG（检索增强生成）的“R”部分，花了我最多时间调参。
前端界面极简，就一个搜索框。但背后，敲下搜索的那一刻，触发的是 Serverless Function（Vercel 的），它先去生成问题向量，然后在 Supabase 里完成那套混合检索，最后把检索到的文本块和元数据（标题、链接、日期）返回，前端渲染成一个可点击的列表。我甚至没做“AI 总结答案”，因为现阶段，我需要的是“精准定位到我曾经写过的原始信息”，而不是让 AI 给我编一个。编出来的东西，我敢信吗？我不敢。我的数字资产，第一要求是保真。
这就是 2025 年，一个超级个体最基础的数字化基建。不再追求日更的流量焦虑，而是把过去十年散落的“认知”真正管线化、资产化。这个博客本身不会有流量，它是我个人的外部大脑皮层。下一个 Commit，我打算把 n8n 工作流接进来，自动抓取我 Twitter 的 Thread、Newsletter 的草稿，也向量化存进来。让这个系统活起来，自己喂养自己。沉淀资产不是建个仓库，是设计一套持续运转的代谢系统。今天，这系统算是有了第一个心跳。
