产品 人人都是产品经理 · CyrusChang · 8小时前 · AI 生成
找东西这件事，AI 也想明白了 作者通过朋友找充电器的日常场景，对比传统信息架构（提前建索引）与 AI 工具 Claude Code 的"笨办法"（用 glob、grep、read 现翻），揭示一个反常识的设计真相：当产品快速迭代时，提前建好的索引会因过时反而成为障碍，用户会被错误的地图误导。文章从交互设计视角，提出"探索成本"与"所见即所得"的平衡，核心见解是：再漂亮的结构，只要跟不上变化，就会从帮忙变成骗人。适合产品经理、交互设计师、对 AI 工具底层机制感兴趣的技术从业者阅读。原文 ↗ 原文 ↗
核心观点
▍ 信息架构的终极悖论：越整齐，越难找。提前建好的索引，在产品快速迭代时反而会因过时成为障碍，误导用户。 01 朋友找充电器时，没有用"清单"或"分类"，而是靠"扫一眼、走过去、拉开"的流程，十秒内完成，探索成本极低。 02 Claude Code 早期采用 RAG 方案（提前建索引），但内部测试发现，替换为三个简单的工具（glob、grep、read）后效果更好，相当于让 AI 像人一样"现翻"。 03 RAG 的索引会因代码变更（改函数名、删文件）而过期，拿着过期的地图带路，会产生误导。 04 作者自己的 Obsidian 知识库，最初按 Karpathy 的 wiki 方法论严格分类，后来发现"分类一多，反而找不着了"，最终拆解了重分类体系，改用直接搜索。 05 作者手机桌面：高频 App（微信、支付宝）不归类，直接用；低频但紧急的 App（如政务类）会专门建文件夹归档。 反方 / 局限
— 作者承认自己的观点不一定全对，RAG 的技术细节没吃透，业界仍在争论。 — 作者也承认，对于"变得慢、又不能慢慢翻"的内容（如帮助中心、合规条款），提前建好信息架构仍然必要，不能一概否定。
概念锚点 Claude Code 的搜索哲学
Claude Code 没有采用传统的 RAG 向量索引，而是给了 AI 三个类似人类翻找的工具：glob 按文件名圈定范围、grep 按内容关键词排查、read 读取完整文件确认。负责人 Boris Cherny 亲口承认，内部测试发现这套「笨办法」效果反而更好。本质是把信息检索从「提前建好路标」变成「边走边问路」，在快速变化的代码仓库里，后者命中率更高。
▸ 1 条关联资料
▼
前置背景 Karpathy 的镜像解法
几乎同一时间，AI 大神 Karpathy 提出了 LLM Wiki 模式，用三层目录结构（raw/原始资料、wiki/编译产物、output/衍生输出）让 AI 把知识「编译」一次后持续维护，而非每次重新翻文档。这跟 Claude Code 放弃 RAG 的思路站在同一反方向——都认为传统索引在变动的知识库前会失效，但 Karpathy 选择用增量编译代替永久索引，Claude Code 选择用实时搜索代替预建索引。
▸ 2 条关联资料
▼
平行视角 RAG 的拥护者怎么算这笔账
尽管 Claude Code 放弃了 RAG，但 72% 的企业 RAG 系统在 2026 年已采用混合方案（BM25 + 向量检索 + 重排序），金融文档领域 BM25 的准确率甚至反超向量模型。支持者认为：RAG 的「过时索引」问题可以通过增量更新、实时 chunk 优化等技术手段缓解，且对于稳定的大型知识库（如法律条文、产品手册），提前建索引的成本远低于每次实时搜索带来的延迟。Claude Code 的「笨办法」更适合小型、高频变动的代码库，而非所有场景。
▸ 2 条关联资料
▼
延伸追问 什么场景该用「翻」而非「搜」
文章给出了一个朴素的分界线：东西变得快不快、翻不翻得起。但这个分界在真实产品中并不好划——比如帮助中心，内容更新慢但用户很急，传统分层索引依然有效；而 Obsidian 个人知识库，用户自己都不知道用了什么关键词，全局搜索配全文预览反而更快。真正值得追问的是：用户的「翻找成本」能不能被设计成一种愉悦的意外发现，而不是填表格式的焦虑？Notion 的 AI 问答和 Obsidian 的图谱搜索给出了两种不同的答案。
▸ 2 条关联资料
▼