信息架构的终极悖论：越整齐，越难找。作者从朋友找充电器的日常场景切入，对比传统信息架构与AI工具Claude Code的“笨办法”，揭示一个反常识的设计真相——当产品快速迭代时，提前建好的索引反而成为障碍。本文从交互设计视角，重新审视“探索成本”与“所见即所得”的平衡。

上周去朋友家吃饭，他让我帮忙从书房拿个充电器。

我问他放哪了，他说”你翻翻就有”。我进去，一整面墙的抽屉，我哪知道翻哪个。最后是他自己进来，站在门口扫了两眼，走过去拉开左下角第三个抽屉，拿出来了。

出来的时候我在想一件事：他其实没有一张东西清单。他没记着充电器在左下第三个抽屉，他是进屋、看、走过去、拉开。整个过程不到十秒。

我做交互的，职业病，看到这一幕第一反应是：他这套找东西的流程，比我平时给用户设计的导航还顺。

我一直以为，找东西要靠提前把结构搭好

我们这行有个几乎不需要论证的信条：好的信息架构，是提前规划出来的。

你做一个 App，第一件事就是画信息架构图。哪个功能归哪个 tab，二级菜单挂在哪，面包屑怎么走。你恨不得在用户开口之前，就把所有东西都归好类、贴好标签、连好路。用户要找什么，顺着你搭的结构一层层点下去就到了。这套逻辑我信了很多年——用户不该”翻”，用户该”直达”。

前几年 AI 编程工具火的时候，用的也是这套思路，甚至更极端。它把整个代码仓库先通读一遍，切成一小块一小块，给每块都算个坐标，存进一个专门的库。你一提问，它拿问题去库里比对，捞出最像的几块给你。这套东西叫 RAG，那两年几乎是默认答案，谁都这么干。

说白了，就是提前把整个空间归好类、建好索引。跟我画信息架构图一模一样。

可我后来发现，这套东西有个我一直没敢正视的毛病

信息架构最尴尬的地方在哪？它是提前定的，可产品是一直在变的。

你上线时那张架构图，画得再漂亮，三个版本迭代下来就开始拧巴。新功能不知道往哪塞，老入口舍不得删，最后二级菜单里塞进去八个八竿子打不着的东西。用户还是照着你最初的分类去找，可东西早就不在那儿了。

这不就是那张三个月前贴的抽屉标签吗——标签还在，里面的东西换过好几茬了。

RAG 的毛病一模一样。你今天改了个函数名，索引还记着旧的；昨天删了个文件，库里那块还在。它拿着一份过期的地图给你带路，还带得特别自信。

Claude Code 干脆把这张地图扔了

做 Claude Code 的人后来说了件挺反常识的事。他们早期版本就是标准的 RAG 加本地向量库，内部一测，换个更”笨”的办法，效果反而更好。

那个笨办法是什么？不建索引了，给 AI 三个特别朴素的工具，让它像人一样进屋去翻。这三个工具，恰好就是我朋友拉抽屉那套动作拆开的：一个glob，按大类先圈个范围——”充电器八成在放电子设备那几格”；一个grep，在范围里挨个翻，不对就换个词接着翻；还有一个 read，翻到疑似的，拿出来看看是不是要的那个。圈范围、翻、拿出来确认，找到就收工。

我第一眼看到这决定，反应跟看我朋友拉抽屉一样：这不就是退回原始状态了吗，怎么会更好。

后来我是从设计的角度想通的。我们这行有个词叫”探索成本”，一直被当成贬义——让用户去探索，等于设计失败。可我可能一直把它想窄了。探索成本高不高，其实得看被探索的东西稳不稳定。图书馆的书上了架十年不挪窝，那提前编目录当然值；可一个天天迭代的产品、一份天天在改的代码，你为它维护一张”永远对不上”的地图，用户被这张错地图坑的次数，说不定比让他现翻还多。

现翻还有个我做设计时最看重的好处：它看到的永远是此刻的样子。用户拉开抽屉，里面是什么就是什么，不存在菜单写着有、点进去却是空的。这种所见即所得，恰恰是我们花大力气想给用户的东西——结果 AI 用最笨的办法先做到了。

说到这我想起我自己那个 Obsidian 知识库。刚开始我是照着 Karpathy 那套 wiki 方法论搭的——分门别类，标签打满，每条笔记都要归到该去的位置。搭出来那一刻确实挺爽，整整齐齐，像个正经知识库的样子。

可用了没多久我就发现不对劲。我记的东西大多是闲散的——半个念头、一段吐槽、一点没想透的总结，它们本来就不该被塞进某个规规矩矩的分类里。更要命的是，分类一多，我反而找不着了。明明记过一条东西，我却想不起来当初把它归哪去了，翻了七八个文件夹都没捞着。

后来我把那套重分类基本拆了，标签能省则省，想到什么先记进去再说，找的时候直接搜。屋子是乱了点，但每条都是我自己此刻随手扔进去的，我心里有数。那套 Karpathy 的分类没错，它规整得多，可它不是我脑子里那张图——整齐有时候比乱还难找。RAG 就是那个帮你把知识库分门别类的方法论：它归得井井有条，然后你自己的东西反而找不着了。

那信息架构、索引，是不是就该扔了

当然不是。我要真这么说，我这些年白干了。

你看我自己的手机就知道。微信、支付宝、相机，全扔在第一屏，从来没归过类——因为天天用，随手一点就开，归类反而多一步。可我手机里也有个文件夹，叫”政务”，里面躺着个税、公积金那几个 App，规规矩矩收着。为什么这几个我愿意归档？因为它们一年用不了两次，而且真要用的时候都挺急，我没工夫一屏一屏划过去找。

落到设计上，我现在给自己定的分界线就两个问题：这东西变得快不快？用户临时去翻，翻得起翻不起？

变得慢、又不能慢慢翻的——老老实实建结构。像帮助中心、像合规条款、像那种一年更新一次但出事要秒查到的东西。这些地方我照样画我的信息架构图，一点不含糊。

变得快、或者翻一翻也不费劲的——别硬塞进那套僵死的层级里了。让入口活一点，让搜索强一点，让用户（或者 AI）自己现找。你自己这周写的几个文件，AI 两下就翻到了，你非要先给它建个库、库还老过期，图啥。

我这么说不一定全对——RAG 的技术细节我肯定没吃透，业界也还在吵。但作为一个天天跟用户到底怎么找东西死磕的人，我信我这双眼睛看到的：再漂亮的结构，只要它跟不上变化，就会从帮忙变成骗人。

那个充电器，朋友最后是自己进来拿的。不是他记性好，是他知道自己那点东西，扫两眼就找得到，犯不着列清单。

但我注意到，他书房门口还挂着一块小白板，上面写着”XX资料—右柜最上层”。那行字看着有点旧了，估计好几个月没动过。

我盯着看了两秒，没说话。有些东西，确实值得挂在门口。

写这篇纯是有些无聊想到了比较好的例子。回来查了下，Claude Code 那帮人是真把 RAG 换成 glob、grep、read 了，负责人 Boris Cherny 亲口说的。我不是搞技术的，术语看着头大，但落到我这行——不就是该不该提前把信息架构定死这么点事嘛。