如何构建一个与人工智能兼容的第二大脑

王建峰·2026年04月17日 17:30

如何构建一个与人工智能兼容的第二大脑

你正开车前往汽车经销店。途中，你开始自言自语地谈论一篇你一直在思考的文章。人工智能问了你一个问题。你一边并入高速公路，一边即兴发挥了两分钟。它将你所说的话提炼成结构清晰的文章，归档到相应的文档中，然后继续处理下一部分。你全程无需触碰任何屏幕。

当你把车开进停车场时，已经出现了三个你出门时还不存在的区域。当你回到家时，一份草稿已经静静地躺在你的文档编辑器里，格式正确、条理清晰、标题齐全，而你却从未打开过它。你甚至从未真正坐下来写作，就写完了一整篇文章。

我正是这样写出了你正在阅读的这篇文章。捕捉灵感、整理思路、检索资料——这三项任务通常会耗费从产生想法到最终完成文档的大部分时间——而这些工作都是在一天的时间里悄然进行的。

现在想象一下另一种情况。开车的时候你也有过同样的想法，但你的工具听不到你的声音。所以你只能等到回家。你打开一个文档。你盯着空白的页面。你努力回想自己想写什么，但灵感早已消失殆尽。在车里，这个想法仿佛鲜活了起来。现在，它却成了工作。你写了几句话，然后分了神，关掉了标签页。三周后，你找到了那份草稿，意识到它已经不再有意义，于是把它删掉了。

这就是人工智能兼容系统和人工智能驱动系统之间的差距。 一种系统能够随时随地捕捉你的思考，而另一种系统则需要你坐下来，进行写作的仪式。 一种系统能够促进你的想法发展，而另一种系统则会在各种摩擦中让它们流失。

本文将探讨二者之间的区别——以及为什么你使用的几乎所有工具都属于错误的一边。

协调始终是个问题

市面上所有笔记应用都号称能帮你整理笔记，结果却让你疲于奔命地进行归档工作。命名、归档、添加标签、链接、描述、检索——这些都是伪装成“整理笔记”的协调工作。一旦你停止输入，这些工具就什么都不做了。

人工智能出现后，这并非一个新问题。这原本就是一个无人愿意承认的问题。人们常抱怨的“知行不一”的鸿沟，实际上是“知寻不明”的鸿沟。你已经获取了信息，但六周后却找不到，因为在你关闭标签页的那一刻，系统就把检索的责任转嫁给了你。

自主代理并非造成此问题的始作俑者。它们只是进行了压力测试，直到问题公开爆发。所有现有的工具都基于一个假设——由人来做决定：

何时创建文档

该给它取什么名字呢？

归档地点

何时再次寻找它

当知识工作者每周可能只撰写十份文件时，这种假设是成立的。放慢速度进行整理所带来的人为摩擦虽然令人恼火，但尚可克服。

代理程序不存在这种摩擦，因为无需人工干预，避免了对积压文件的质疑。如果代理程序每天创建五十份文档，那么一周之内，这些工具就会变成垃圾场——页面层层嵌套，毫无检索路径；文件名称随意，完全是代理程序当时的想法，三天后，对于试图查找特定内容的人来说，这些文件毫无用处。

人工智能并没有破坏知识管理工具。它们一直都存在缺陷。 人类始终扮演着协调层的角色——负责归档、维护结构、记住信息存放位置。一旦将人类从这个循环中移除，或者人工智能的运行速度超过了人类手动维护的能力，整个系统就会暴露其本来的面目：一个缺乏协调机制的存储容器。人工智能代理并没有暴露新的缺陷。它们只是生成文档的速度快到足以让原本的缺陷变得无法忽视。

AI驱动 vs AI兼容

各大生产力工具都在竞相添加人工智能功能。Notion 有人工智能摘要功能，Google Docs 有 Gemini，Obsidian 有连接语言模型的插件。它们都由人工智能驱动，但没有一个是真正意义上的人工智能兼容工具。

所谓“人工智能驱动”，是指将语言模型生硬地移植到一个原本为人类设计的工具上。屏幕布局、文件夹结构、数据组织方式——所有的一切都是按照用户点击菜单、拖拽操作的假设构建的。人工智能必须克服所有这些障碍。它运行在一个从未考虑过其思维方式的系统中。

这就是为什么大多数工具中的人工智能感觉就像一个被困在房间里的智能助手，它无法自由行动。工具会说“这里有个搜索栏，找到你需要的东西”。人工智能搜索后得到七十五个结果，却无法分辨哪个才是真正重要的，最终只能靠猜测或让你选择。工具还会说“这里有个页面”——人工智能可以阅读页面内容，或许还能概括总结，但它无法将信息转移到其他地方，无法将其与相关内容关联，也无法在未经你手动协调的情况下执行任何操作。智能是存在的，但架构却处处阻碍着它。

“AI兼容”意味着该系统从一开始就被设计成信息能够顺畅无阻地流动——无论是在工具之间、任务之间，还是在处理同一任务的人类和AI之间。 数据结构经过优化，语言模型无需浏览下拉菜单或嵌套文件夹层级，即可读取、处理并还原数据。操作足够简单，AI无需猜测你的意图。

这就是实际操作中的样子。我撰写、组织和修改了这篇文章，全程没有打开任何文档编辑器。需要说明的是，这并不意味着人工智能完成了写作——它只是负责格式和组织。它实际完成了以下工作：

几秒钟内就提取出了全文

认真听取了用浅显易懂的语言编写的修改说明，并立即付诸实践。

应用程序之间不支持复制粘贴，不支持手动归档，不支持切换标签页

信息之所以能流向需要去的地方，是因为底层系统就是为这种信息流而设计的。

这就是差距所在。所谓“人工智能驱动”，是指在原有缺陷的架构内实现更智能的功能；而“人工智能兼容”，则意味着架构本身已被重构，从而使智能能够真正地在其中运行。

要理解其中的原因，只需看看每次有人试图在现有产品中集成人工智能时都会出错的堆栈就知道了。大多数团队从未质疑过这一点，因为软件一直以来都是这样构建的。它的顺序如下：

用户界面 ——包括屏幕、按钮、模态框和拖放交互。它的设计面向的是会阅读、点击并思考操作步骤的人。这里的每一个设计决策都假定是由人来操作的。
数据模型 ——底层数据如何组织以支持界面。如果用户界面有嵌套页面，数据模型也有嵌套对象。如果用户界面支持拖放排序，数据模型会跟踪排序索引。界面塑造数据。
API—— 构建在数据模型之上的程序层。由于数据模型是为了服务于接口而构建的，因此 API 也继承了所有相同的假设。例如，嵌套结构、仅在模态上下文中才有意义的必填字段、以及人类永远不会看到但现在语言模型必须访问的 ID 查找表。
语言模型 ——最后才加入，像是事后才想到的。它必须反向推导，逐一推导上层所有嵌入的 UI 假设。每一步都与数据模型对抗。

这就是为什么谷歌的Gemini无法在不经人工干预的情况下将谷歌文档转换为谷歌幻灯片的原因。人工智能并不负责这些繁琐的转换工作——这些工作都由你来完成。你需要复制谷歌文档的输出内容，粘贴到幻灯片中，然后告诉幻灯片内置的人工智能如何处理这些内容。

同一家公司开发的两款产品，位于同一生态系统中，却无法在没有中间人作为信使的情况下相互通信。直接问 Gemini 能否做到这一点，答案是：不能——但这里有六个步骤，需要借助第三方工具才能实现。开篇第一句：

虽然 Google Docs 没有原生的“转换为幻灯片”按钮，但您可以使用一些可靠的第三方扩展程序和 AI 工具自动实现此目的。

谷歌并非个例，这已成为行业标准。市面上所有PKM工具——Notion、Obsidian、Roam、Mem——的架构都如出一辙：先设计界面，再围绕界面构建数据模型，API是事后添加的，AI则是最后才加入的。它们都没有考虑到智能代理每天无需人工干预即可生成数百份文档的时代背景。

在这种规模下，以用户界面为先导的技术栈不仅会运行缓慢，还会因自身过载而崩溃。 每个未经人工干预的智能体创建的文档都只有标题和时间戳，没有描述，没有检索路径。每月一千个任务，知识库就荡然无存了。你得到的只是一堆垃圾，上面放着一个搜索栏，但这个搜索栏根本无法使用。

理论上，这种反转操作很简单，但几乎没人这么做。设计时首先要考虑语言模型实际的思考方式。

使用扁平化的 JSON 而不是嵌套的层级结构——因为嵌套结构会造成标记膨胀和遍历错误，而这些错误会在规模扩大时累积。

操作简单，状态明确。参数清晰易懂，绝不会造成误解。

没有模态假设，没有必要的查找步骤，也没有只有在屏幕上才能理解的数据结构。

一旦 API 清晰且数据模型扁平化，界面就成为可选的。它是一个围绕 API 返回结果构建的查看窗口——并非数据源，也不是工作流程中必需的步骤。无需打开编辑器，即可编写 21 条永久笔记、丰富 143 个元数据字段并改进搜索功能。编辑器仅用于阅读和润色。所有协调工作都在 API 层完成，通过任务和代理，以机器速度运行。

当用户界面优先时，API 会继承所有用户界面的假设。当 API 优先时，系统无需任何人干预即可运行。

为什么元数据毫无用处，搜索功能也失效了？

文件柜确实是解决一个棘手问题的绝佳方案：

你有一份需要存放在某个地方的文件。
你创建了文件夹，贴上标签，然后把纸放了进去。
你把它们归档到抽屉里了。

这套系统之所以有效，是因为一个人实际能生产的纸张数量存在一个天然的上限。你的书写速度终究是有限的，而文件柜的运转速度也只能跟上。

计算机出现后，没有人停下来思考文件柜模式是否还适用。他们只是简单地将其照搬过来：

文件夹变成了电子文件夹
文件有了名称
层级结构变得更深

整个物理世界的组织逻辑被映射到一个没有任何相同限制的媒介上——而且没人注意到，因为在一段时间内，数据量还在可控范围内。一个人，每周只创建少量文档，仍然可以维持系统运转正常的假象。

但想想普通人的硬盘里到底存了些什么。如果你把所有文件、邮件和下载的文档都打印出来，然后试图把它们全部归档到实体文件柜里，那你需要好几个房间。一个人十年积累的数字信息量足以淹没任何现有的文件系统，因为文件柜模式是基于人类的读写速度设计的，它根本就不是为硬盘设计的。

然而，这仍然是目前的模式。你桌面上的每个文件夹都像一个文件柜。Notion 中的每个标签都像一个实体文件夹上的标签。附加到每个文件的元数据——创建日期、修改日期、最后打开日期——就相当于你在归档前在纸上盖上日期戳。它告诉你时间，却不告诉你内容。

文件最重要的就是它里面的内容——这也是你打开它的唯一原因。附加到文件上的每一条元数据，无论是在桌面端还是云端笔记工具中，都告诉你除了内容之外的一切信息。

关键词搜索 会找到包含你输入的词语的文档，但它并不理解这些文档的实际内容。在 Google 文档中搜索“协调”，会得到 75 条结果。这可能只是顺带提及，也可能是整篇论文。系统无法区分。对人类来说，这很烦人。而对于需要正确上下文才能做出决策的智能体来说，这是一个可靠性问题，并且会波及下游的每一个任务。

语义搜索的 工作原理不同。它将每个文档转换成其含义的数学表示，因此在搜索时，您匹配的是概念而不是字符。您无需记住某个事物的名称，只需知道它指的是什么即可。

这就是它在实践中的样子。我多年来积累的阅读笔记被整合到一个知识库中。我问它“我读过哪些关于用人工智能打造品牌声音的文章？”，它会找到我几个月都没翻阅过的笔记——并非因为它们包含完全相同的词语，而是因为它们的含义相近。像 Readwise 这样的工具更进一步：它的聊天功能让你可以和自己标注的内容进行对话，从你保存的所有内容中提取语义最相关的段落。这并非关键词搜索，而是基于含义的检索。

文件柜永远做不到这一点。任何仿照文件柜建造的东西也做不到。

没有现成的工具是为这个世界而设计的。

你是不是经常更换笔记应用，希望新的应用能解决之前那个应用没能解决的问题？每次迁移都感觉像是一个全新的开始——系统更简洁，结构更清晰，这次肯定能用得住。正如蒂亚戈·福特在《构建第二大脑》一书中写道：每个新的效率应用都承诺会带来突破，但最终往往只是又多了一项需要管理的任务。问题从来不在于工具本身，而在于每个工具在你完成输入的那一刻，就把协调的重担又转嫁给了你。

人工智能即将使这种弃用循环显著恶化。

这些工具的设计初衷都是为了同一个用户：一个人，每周创建少量文档，自行归档。在自主代理出现之前，这种假设对于工作量巨大的知识工作者来说就已经行不通了。但至少人最终会停止工作。人会疲惫，会分心，会觉得维护系统太过费力，然后默默地停止添加内容。正是这种摩擦力，才避免了垃圾填埋场彻底被填满。

这就是实际操作中代理规模化工作的样子。在一小时内完成的二十一份文档，包括写作和笔记，每一份文档都缺少：

描述
标签
语义内容
关于内部内容的任何背景信息

只有一个文档 ID 和代理给它起的名字。现在想象一下，三天后让 AI 查找其中一份文档——不是像人一样扫描列表，而是作为一个语言模型，需要检索正确的上下文才能完成任务。你搜索，得到一串标题，但这些标题几乎毫无意义，模型要么猜错，要么浪费大量令牌试图推断它真正需要的内容。

这并非检索问题，而是协调级联问题。创建时缺失一个元数据字段，就会在后续流程中引发一系列错误决策。语言模型不仅会因元数据不足而受到影响，其可靠性还会随着底层知识系统对内容描述不足程度的增加而急剧下降。 每个缺少描述的文档都会给后续查找该文档的任务带来额外的负担。

再多的AI附加到现有工具上也无法解决这个问题。微软和谷歌犯了同样的错误——将智能添加到各自独立的产品中，而这些产品之间并没有共享的协调层。AI本身很智能，但其底层架构存在缺陷，最终架构缺陷总是胜出。

从另一侧看你的工具是什么样子

所有关于人工智能工具的讨论都集中在人工智能能为你做什么。几乎没有人会问，在人工智能眼中，你的工具是什么样的。

我们请 Claude 审阅了两个他日常使用的 Python 脚本——一个封装了专为人类设计的外部工具，另一个是我们自己开发的、面向人工智能的原生文档编辑器。两个脚本的功能相同：创建、搜索、更新和整理文档。审阅过程非常坦诚。

这款以人为本的工具只获得了三星（满分五星）。人工智能将其描述为“我只想记个笔记，它却让我操作重型机械”。问题在于：

三十个函数，数千行代码
根据调用的操作不同，参数名称也会发生变化——有时是字典，有时是位置参数，有时是完全改变行为的标志。
根据你提出的问题，返回的响应结构呈现不同的形式。

工具确实有效。但人工智能花在操作工具上的时间比实际工作的时间要多。

这款人工智能工具获得了五星好评。评论称：“它不会妨碍我工作，让我专注于自己的工作。”原因：

创建文档需要三个参数
每次操作的返回值保持一致
搜索功能是根据含义而非关键词来查找内容。

人工智能将其描述为由某人目睹人工智能运行困难后决定修复它而开发出来的。其中一个工具处处与人工智能对抗，而另一个工具则消失了。

这就是人工智能驱动和人工智能兼容之间的具体区别。以人为本的工具并非存在缺陷——它本来就是为用户点击菜单和阅读屏幕而设计的。每一个设计决策都基于人眼和人手的交互。当人工智能出现时，它继承了所有这些假设，却不得不逐一规避。而人工智能兼容的工具则从另一个问题出发：人工智能完成工作究竟需要什么？答案是更简单的操作、可预测的结构，以及任何无需猜测的内容。

其背后的工程原理与直觉相悖：语言模型的性能会随着需要处理的信息量增加而成反比。你增加的每一层复杂性，都会让系统找到新的方法来出错。你移除的每一层复杂性，都意味着少了一个出错的可能性。驱动人工智能兼容设计的关键问题从来不是“如何让它更健壮”，而是“我可以删除什么”。

LLM-First Development

安德烈·卡帕西创造了这个术语。西蒙·威利森划出了一条真正重要的界限：“如果LLM（生命周期管理模型）生成了你代码的每一行，但你已经审查、测试并理解了所有内容，那不是直觉式编码——那只是把LLM当作打字助手。”直觉式编码就是部署模型生成的任何代码，然后祈祷它能行得通。LLM优先开发则截然不同。它要求参与开发的人做到三件事。

1.理解

理解意味着要有足够的知识去审视人工智能构建的模型，并提出一个问题：你能可靠地执行它，还是会出错？语言模型会以可预测的方式失效。它们会错误地记住复杂的嵌套有效载荷。当序列状态模糊时，它们会产生不一致的结果。它们会跳过或错误地识别长参数列表中的可选字段。你不需要是开发人员也能识别出某个解决方案是否过于复杂，以至于人工智能无法可靠地处理。你需要知道人工智能是如何出错的。一旦你了解了这一点，你的本能反应就不是在脆弱的部分添加重试逻辑，而是用极其简单的方案来替换它，确保人工智能不会出错。

2.审查

审查意味着让人工智能阅读自己的代码。让 Claude 审核自身的功能，解释它实际执行的操作，并找出可能出错的地方。构建它的模型本身也是揭示其内部隐藏假设的最佳工具。

3.测试

测试意味着运行实际系统并观察出现的问题。每个脚本都应该返回状态。每个任务都应该记录完成情况。每次失败都应该产生包含足够上下文的错误信息，以便追溯到问题的根源。这种架构并非来自软件工程教科书——它源于不断追问“我如何知道它是否有效”，并从一开始就将答案融入架构之中。那些凭感觉写代码的人从来不会问这个问题。他们运行脚本，想当然地认为它已经成功，直到下游出现问题，才发现根本找不到任何线索。

由此得出的工程原理很简单：增加的复杂性越多，人工智能出错的可能性就越大。减少层级，系统就越可靠。以LLM为先导的设计理念，其核心问题从来不是“如何提高系统的鲁棒性”，而是“哪些部分可以删除”。

加法会使复杂程度倍增，减法则会化解复杂程度。