过去十年创作的内容，终于变成了 AI 能读的知识库

最近有不少人问我，ranchen.org 里面那些内容到底是怎么弄出来的。这个网站现在汇集了我过去散落在不同地方的一千多个内容：LinkedIn 文章、视频、播客，还有一些别的平台上的记录。看起来像是突然冒出来一个完整的个人知识库，其实背后没有什么神奇的东西。

它本质上就是一件很朴素的事：把过去说过的话，从各个平台上搬回来，整理成 AI 能读、我自己也能回看的格式。

我做这件事不是为了怀旧。说实话，一个人十年下来真正反复思考的东西也没有那么多。很多观点换了场景、换了表达，但底层关心的问题是连续的。以前这些内容散落在 LinkedIn、YouTube、播客平台和各种网页里，对人来说还能靠记忆找一找，对 AI 来说基本等于不存在。

所以我真正想做的，不是“备份互联网”。我想要的是一个自己的 source of truth：以后写文章、做判断、训练自己的工作流时，AI 至少知道我以前说过什么、怎么说、哪些判断是一脉相承的，哪些地方我后来改过想法。

这件事分两层。第一层是怎么把内容抓下来，这一层很脏，很具体，也没什么高级理论。第二层是为什么要这样组织内容，这一层才是我现在越来越在意的地方：AI 时代最稀缺的东西，很多时候不是 implementation，而是 context。

先说怎么做：不是爬虫教程，是把自己的内容搬回来

把不同平台的内容整理回来，本质上确实是一个爬数据的过程。但这件事在不同平台上的难度差很多。

有些页面很容易，打开就是公开 HTML，直接读就行。有些平台就麻烦得多，尤其是那些强依赖登录态、动态加载、反爬虫机制比较重的平台。你如果写一个普通程序去请求，很容易拿不到完整内容，或者很快被挡住。

我现在用得最多的是 Codex 加 Chrome extension。

这里的关键不是“绕过”什么，而是 Chrome 里面本来就有我自己的登录状态。原则上，我自己在浏览器里能正常看到的内容，Codex 通过扩展插件也可以在这个上下文里帮我读取、整理和下载。很多真实的个人内容并不在干净的公开网页里，而是在你登录之后才能看到的页面里。用 Chrome 做入口，事情就自然很多。

我的操作大概是这样：

1. 把 Codex 的 effort 开高一点，比如 X-high。
2. 安装并连好 Chrome 的扩展插件。
3. 把要整理的 URL 发给它，让它读取正文、元数据和页面资产。
4. 明确告诉它：图片要下载到本地，正文里不能只留别人的 CDN URL。
5. 对 YouTube、Podcast 这种内容，如果量不大，我通常自己先把链接找出来，再交给它处理。

这里最容易被忽略的是第四点。很多人做归档时只把正文抓下来，图片还是指向原平台的 CDN。短期看没问题，半年一年之后，链接可能过期，可能防盗链，可能平台改了路径。到那时你再打开自己的文章，里面全是坏图。

所以我会要求它把图片资产真正落到本地，把路径写进 metadata 或正文里。外部 URL 可以保留做来源记录，但不要成为唯一可用的资产位置。归档这件事如果不能在本地重建，严格说就还没有完成。

音视频内容更麻烦一点。它们天然不是文本，AI 后面要检索和引用，必须先有一层文字底稿。我会让 Codex 帮我抓 metadata，比如标题、链接、发布时间、描述这些。然后用 AssemblyAI 的 API 做 speech to text。

这个转录我不会神化。中文音频转出来有时候并不准，口语、专有名词、夹杂英文时更容易出错。但它的价值不是成为最终可引用的精修稿，而是先让原本不可搜索的视频和播客进入同一个文本系统。以后 AI 至少可以通过 transcript 找到“我大概在哪里讲过这个问题”，真正要引用时再回去核对。

所以整个抓取流程没有什么 magic。更多时候是很具体的脏活：找 URL，确认页面能不能读，下载图片，保存 metadata，检查转录，修掉坏链接。工具确实让这件事快了很多，但工具并不会替你决定哪些东西值得保留、用什么结构保留、以后要怎么被使用。

我后来发现，归档时最重要的不是“尽快把网页保存下来”，而是把每一条内容变成一个未来还能被理解的对象。正文只是其中一部分。发布时间、原始链接、平台、图片本地路径、音视频链接、转录文本，这些看起来琐碎的字段，才决定了以后 AI 能不能把这条内容放回正确语境里。

比如同一句话，如果它来自一篇正式文章，和来自一次播客里的即兴回答，权重是不一样的。前者通常更像经过整理后的判断，后者可能更接近当时的想法过程。只抓正文不抓 metadata，以后模型看起来读到了内容，但其实丢了很大一块判断边界。

为什么要做：旧内容不是历史，是未来 AI 的上下文

如果只是为了做一个个人作品集，我其实不需要这么麻烦。挑几十篇代表作，做成一个漂亮页面就够了。

但我现在对 ranchen.org 的定位不是作品集，而是一个长期的 context 库。它要服务的不只是人类读者，也要服务未来的 AI 写作、检索和判断。

很多人用 AI 写文章时，最常见的问题不是模型不够强，而是模型完全不知道你是谁。它不知道你以前对 AI coding 的判断，没看过你在 Pure Global 做知识库时踩过的坑，也不知道你对数据库、静态网站、agent flow 的偏好来自哪里。你给它一个题目，它当然能写出一篇结构完整的文章，但那篇文章很容易像互联网上任何一个人都能写出来的文章。

这就是我说 context 比 implementation 更重要的原因。现在让 AI 写一段代码、生成一个页面、改一篇文章，已经越来越便宜。真正麻烦的是：你要让它带着你的历史、你的偏见、你的判断边界去工作。

AI 不是缺少“会写”的能力，它缺的是知道“你为什么会这么写”的上下文。

我在公司里也有类似经验。Pure Global 内部推 AI 知识库的时候，我们把很多国家的法规、内部培训资料、SOP 都整理进去。后来我发现，真正改变工作方式的不是“我们有了一个聊天机器人”，而是大家开始围绕同一个 source of truth 工作。

当 AI 答错了，问题不是抱怨模型，而是回头看知识库哪里不清楚、哪里过期、哪里重复。开会讨论完一个新规则，也不是写一份没人再看的会议纪要，而是把结论整理回知识库。久而久之，这个系统会变得越来越干净。

个人内容库也是一样。ranchen.org 里这些旧文章、旧视频、旧播客，不是为了证明我以前说得都对。恰恰相反，它们让我看到自己哪些判断一直没变，哪些想法后来修正了，哪些例子只是某个时间点的观察。这个连续性本身很重要。

如果没有这个 source of truth，每一次写作都是从零开始。AI 会根据当下这一段提示猜你的语气，猜你的立场，猜你过去可能怎么想。它猜得再好，也还是在猜。

这也是为什么我不太相信“一个万能提示词解决写作”的说法。提示词当然有用，但它更像方向盘，不是地图。你可以告诉模型“写得像我一点”“多引用我以前的观点”“语气克制一点”，但如果它没有读过你以前的材料，这些要求很快会滑向某种平均化的模仿。

真正有用的是把旧内容变成约束。AI 写到某个判断时，可以回头看我以前是不是这么说过；写到某个例子时，可以知道它来自文章、视频还是播客；写到一个看似漂亮的结论时，也能被旧材料拽回来：这句话有没有依据？是不是说过头了？这种约束不一定让文章更华丽，但会让文章更像一个人长期思考后的结果。

为什么我尽量不用数据库

ranchen.org 的技术架构很简单：部署在 Vercel 上，是一个纯静态网站，没有数据库，也没有复杂后台。

我知道“不要用数据库”这句话听起来容易被误解。数据库当然有它该存在的地方，交易系统、权限系统、高频写入、复杂查询，这些都不是 Markdown 文件该硬扛的场景。我反对的是另一种默认反应：明明只是一个内容型网站、一个个人知识库，也习惯性先加一层数据库，再加一层后台，再加一层管理界面。

对我这个场景来说，数据库反而会让事情变得不透明。

第一是版本管理。内容如果都在文件里，所有变化都可以走 Git。新增文章、修 metadata、替换图片、调整页面结构，本质上都是一次 commit。出了问题可以 diff，可以 review，可以 revert。网站部署到 Vercel 之后，每次 push 都是一次清楚的构建和发布。

数据库里的内容当然也能备份，也能做 migration，也能加审计表。但那是另一套复杂度。对一个个人内容系统来说，我不想为一个本来可以用 Git 解决的问题，再维护一套额外机制。

第二是 AI 透明度。

当 data 和 logic 都在同一个 repo 里，AI 可以直接搜索文件名、读 Markdown、看 front matter、顺着目录结构理解内容之间的关系。文件位置、命名、时间戳，本身就是上下文信号。

这个差别在日常使用里很明显。比如我想让 AI 找出过去所有和“AI 写作”“静态网站”“一人公司”相关的内容，它不需要先问我要数据库连接，也不需要等待某个后台接口暴露查询能力。它可以直接在文件系统里搜索，再打开相关条目阅读。很多时候，目录结构本身已经告诉它：这是 LinkedIn 文章，那是播客转录，这是某一次视频的 metadata。

这不是说文件系统天然比数据库高级，而是说在 AI 参与开发和写作的场景里，透明度本身就是生产力。人能看懂，AI 也能看懂；人能 diff，AI 也能 diff；人能 review，AI 也能顺着同一套文件结构给出修改建议。

如果内容藏在数据库里，AI 每次要理解系统，都要先理解 schema，再通过 query 或 API 把数据取出来。不是说做不到，而是多了一层。多一层就多一个信息损耗点，也多一个维护点。

我以前在复盘一个失败的 Cursor 项目时写过一个类似的教训：很多时候我们以为中间状态越完整，流程就越可靠，但 AI 工作流里恰恰可能相反。太多中间层会增加故障点，也会让人误以为自己在做严谨工程，实际上只是在维护复杂度。

我现在更喜欢的方式是：内容就是文件，结构就是目录，发布就是 Git 加 Vercel。邮件系统也一样，我没有用很重的 newsletter 平台，而是直接用 Resend。订阅管理用它的 segment，发送用 broadcast，对我来说已经足够。

这不是为了追求某种极简美学，而是因为少一个系统，就少一层状态。少一层状态，AI 和人都更容易看清楚到底发生了什么。

我的写作流程：先把 context 准备好，再让模型一次性写

有了这个历史内容库之后，我现在写新文章的流程也比较固定。

一开始通常不是写作，而是讨论。我会先跟 AI 聊很多，很多想法最早只是几百字的语音记录，非常 raw，里面有重复、停顿、半截句子，也有一些我自己还没想清楚的判断。这个阶段我不追求完整，只追求把真正想说的问题倒出来。

下一步才进入正式流程。我会调用 Codex 的 exec mode，指定一个文件夹，让它知道哪些是我以前写过的内容。它会按照我设定好的本地流程，把当前 idea 和历史文章关联起来，找出以前哪里说过类似的话、哪些旧观点能支撑现在这篇文章、哪些地方可能要补一个边界。同时，它也会把需要的外部信息整理进一个 intermediate Markdown 文件。

这个中间文件很重要。它不是最终文章，但它把 raw idea、历史内容、可能引用的旧文、相关材料都放到一个地方。对模型来说，这一步相当于把写作所需的 context 先整理干净。

然后我会把整包东西一次性喂给模型：原始 idea、材料包、写作要求、格式约束。这里我现在反而不喜欢用很重的 agentic writing flow。

原因很简单，写作和搜集资料不是同一种任务。搜集资料可以 agentic 一点，因为它需要搜索、筛选、打开文件、比对信息。写正文时，我更在意整篇文章的主线、语气和节奏。如果把它拆成多个 agent 分段写，再拼起来，结构可能看起来更完整，但声音容易散。

我在写 AI-native development 那篇文章里说过，AI 时代很重要的能力是表达意图、管理上下文、验证输出。写作也是这样。人的工作不是把每一段都手敲出来，而是把问题讲清楚，把材料准备好，把约束说清楚，最后认真 review。

我现在大致把流程分成四步：

1. 先和 AI 讨论，得到一份很粗糙的 raw idea。
2. 用 Codex 读取历史内容和相关材料，生成 intermediate Markdown。
3. 把 raw idea、材料和写作要求一次性输入模型，生成主体。
4. 再让 Codex 按写作规范和 review 要求过一遍，做最后修订。

这里面最容易被误解的是第三步。一次性生成不是偷懒，也不是迷信模型。它成立的前提是前面的 context 已经准备得足够好。材料不够、主线不清楚、约束不明确时，single-turn 只会一次性生成一篇很完整的废话。

但当 context 够干净时，一次性成文反而更容易保留整体感。文章的开头、转折、例子和结尾是同一个模型在同一个上下文窗口里一起考虑的，不需要后面再强行缝合。就我现在的体验看，Gemini 3.5 Flash 在“说人话”这件事上表现不错，尤其是中文长文，它比较容易写出自然的段落节奏。当然，最后还是要 review。模型能写，不等于它不会顺手编得太满。

最后一次 review 我会看得很具体。不是只问“这篇文章好不好”，而是检查它有没有把素材堆成清单，有没有编出我没说过的经历，有没有把一个有限的工程偏好写成普世真理，有没有为了显得深刻而把语气推得太满。AI 最容易犯的错误不是完全跑题，而是在一个基本正确的方向上写过头。第二遍改稿很多时候就是把这些地方往回拉。

所以我其实没有把写作变成一个完全自动化的流水线。更准确地说，这是一个人机分工的流程：我负责提出判断和方向，Codex 负责整理 context，模型负责生成初稿，最后再由 Codex 和我一起把不自然、不准确、没依据的地方压掉。

这件事最后会回到组织记忆

ranchen.org 看起来是一个个人网站，但我做完之后越来越觉得，它和公司里的 AI 知识库是一回事，只是规模和对象不同。

在公司里，如果知识只存在人的脑子里，组织就会反复丢东西。一个人离开，一个流程没人说得清；一个客户案例没人记录，下一次又重新踩坑；一个法规判断讨论过，过几个月又被重新问一遍。

AI 知识库真正有用的地方，不是它能让大家少问几个问题，而是它逼着你把组织里的隐性知识变成显性知识。谁说的、什么时候说的、为什么这么判断、后来有没有修正，都要有一个地方承接。

我现在比较喜欢的一条工作纪律是：先问 AI，再开会；开完会，再把新结论回灌给 AI。

这听起来很简单，但它改变了知识流动方向。过去是人和人对齐，人走了知识就走了。现在是人通过 AI 对齐，而 AI 背后的知识库会持续积累。前提当然是有人愿意做清洗、删除、修正这些脏活。没有这一步，知识库很快也会变成垃圾堆。

个人写作也是类似的。一个人过去的文章、播客、视频，如果不整理，就只是散落在平台上的内容。整理之后，它们才变成可以被复用的 context。未来我写任何一个新主题时，AI 都可以回头看：我以前是不是讲过类似问题？当时的判断是什么？现在这篇文章有没有和过去矛盾？如果矛盾，是因为我改变了看法，还是因为模型写偏了？

这比“自动写文章”重要得多。自动写文章只是一个输出能力，context 库才是长期复利。

而且这个复利不是抽象的。它会体现在很小的地方：下一篇文章不需要重新解释我为什么偏好静态站；下一次讨论 AI 写作，不需要重新翻一遍旧 LinkedIn；某个观点如果以前已经写过，新的文章可以直接站在那个判断上继续往下推。这样写出来的东西才不会每次都像第一次认识自己。

几个边界

我不想把这件事讲成一个万能方法，所以边界也要说清楚。

第一，Codex 加 Chrome extension 很好用，但它不是让你随便抓别人内容的理由。我的场景是整理我自己的内容，处理我自己账号能正常访问的页面。浏览器登录态越强，越需要清楚授权边界。

第二，speech to text 只是底稿。尤其是中文和中英混杂的内容，自动转录一定会有错。它适合做检索入口，不适合不经核对就当成精确引用。

第三，不用数据库不是工程宗教。对 ranchen.org 这种内容型静态站，文件和 Git 很合适；换成高频交互、复杂权限或实时状态，数据库当然还是该用就用。我的判断是：能用文件解决的内容系统，不要过早把自己关进数据库层。

第四，AI 写作流程也不是越自动越好。你可以让 AI 搜索、整理、生成、review，但核心判断仍然要来自人。否则你最后得到的只是一个结构很好、语气很顺、但谁写都一样的文本。

我现在越来越相信，未来很多个人和公司都会回到一个很朴素的问题：你有没有把自己的 context 管好？

模型会变，工具会变，今天叫 Codex，明天可能换一个名字。真正留下来的，是你有没有一个干净的、可搜索的、能被人和 AI 同时理解的知识底座。

所以如果你也想做类似的事情，不需要一开始就搭很复杂的系统。先从几十个链接开始，把正文抓下来，把图片落本地，把 metadata 写清楚，把文件结构整理好。然后让 AI 在这个目录里工作，看看它能不能真正理解你过去说过的话。

做到这一步，你会很快发现，AI 写作里很多所谓的提示词技巧，其实没有那么重要。真正重要的是你有没有给它足够好的材料，以及这些材料是不是以一种透明、稳定、可维护的方式存在。

归档旧内容不是向后看。它更像是在给未来的自己铺一条路：下一次你要表达一个新判断时，不必从空白开始，也不必让模型凭空模仿你。它可以回到你过去留下的那些文件里，重新找到你的语气、你的逻辑、你的犹豫和变化。

这才是我做 ranchen.org 这件事最核心的原因。