最近在看Claude Code的设计发现一个有意思的现象当所有AI编程助手都在卷向量索引、语义搜索的时候Claude Code反其道而行——用Grep和Glob。Grep1973年诞生的文本搜索工具。GlobUnix shell里最基础的文件匹配。这个选择在技术圈引发了不小的争议。Milvus的博客说”Claude Code的grep-only方式会烧掉太多tokens”HackerNews上也有人质疑“Cursor用向量搜索Claude用grep这不是倒退吗“但Anthropic团队在访谈里透露了个细节他们测过RAG、向量索引这些方案最后发现这种”agentic search”让模型智能地使用Grep/Glob的效果反而最好。为什么会这样什么是”Agentic Search”Claude Code的搜索能力核心靠两个工具Glob- 文件模式匹配找文件。支持**/*.go、src/**/*.ts这样的模式Grep- 内容搜索搜代码。支持正则表达式可以过滤文件类型这两个工具本身很蠢。Glob只会按文件名匹配Grep只会按正则搜索都不懂语义。但当模型来驱动它们时就不一样了。用户说“找处理用户认证的代码”传统向量索引的做法工具: 语义搜索 user authentication 返回: login(), handleAuth(), verifyUser() ... 工具自己理解语义Claude Code的做法模型: 先用Glob找可能相关的文件 工具: glob **/*auth*.go 返回: auth.go, auth_handler.go, middleware/auth.go 模型: 在这些文件里搜关键词 工具: grep func.*Login auth.go 返回: func LoginHandler(...) 模型: 读一下这个函数 工具: read auth.go:35-60 返回: 函数实现代码看出区别了吗向量索引是让工具来理解语义然后给模型喂结果。 Agentic search是让模型来理解语义然后指挥工具执行。所有的智能都在模型里工具只负责最基础的操作。为什么简单工具更好传统IDE的做法是让工具自己变聪明。IntelliJ IDEA启动要构建PSI树、stub索引运行时要维护语法树、更新索引几个GB内存、几十个后台线程就这么没了。Cursor更进一步用Merkle树索引代码库智能分块后生成向量嵌入存到远程数据库。确实能做语义搜索——搜”用户认证”能找到login、authenticate、verifyUser这些不同命名的函数。但问题是当模型已经足够强大的时候这些工具层的智能是多余的。向量搜索失败的时候你要调试嵌入质量有问题语义理解偏了索引过期了分块策略不对向量数据库抖动排序算法有bugGrep失败就一个原因正则不匹配。改正则重新搜。而且模型可以做很多向量索引做不到的事组合使用Glob和Grep先缩小范围再精确搜索根据上一次搜索结果调整策略理解上下文知道在哪些文件里搜索更有可能找到出错后自我修正换个关键词再试这就是”agentic”的含义——让模型成为agent工具只是手。Claude Code的工具箱看看Claude Code实际提供的工具文件搜索Glob - 按文件名模式匹配Grep - 按内容搜索LS - 列文件文件操作Read - 读文件Edit/MultiEdit - 编辑文件Write - 写文件执行Bash - 执行命令其他WebFetch - 抓取网页WebSearch - 网络搜索Agent/Task - 启动子agentTodoWrite - 任务管理没有语法分析没有类型推导没有符号索引。都是最基础的操作。复杂的事情交给模型代码补全 → 模型理解上下文智能重构 → 模型理解语义错误检查 → 模型知道类型系统代码导航 → 模型组合Grep和Read意图理解 → 模型本身就是工具层保持简单模型层承担智能。无状态的优势Unix的设计哲学每个程序只做一件事并且做好。Grep做搜索不管搜索结果怎么用Glob找文件不管文件内容是什么。Claude Code继承了这个思想。对比有索引的系统启动构建索引几分钟运行维护索引后台线程崩溃恢复索引检查一致性修改更新索引增量or全量Grep/Glob启动立即可用运行实时执行崩溃重启就行修改下次自动看到每次搜索都是全新的每次结果都是最新的。没有状态就没有状态管理的复杂度。这也是为什么几百行代码就能实现一个基础的agent——当你不需要维护索引、缓存、状态时代码自然就简单了。什么时候简单比复杂更好Linus在选择宏内核vs微内核的时候说过“微内核在理论上很美但实践中复杂度爆炸。“向量索引在理论上很美语义搜索理解意图上下文推荐智能补全预构建索引搜索快但实践中需要上传代码隐私问题需要维护索引一致性问题需要同步状态分布式问题搜索失败难调试黑盒问题Grep/Glob在理论上很蠢只能模式匹配每次都重新搜不理解语义但实践中本地执行零隐私风险无需维护零一致性问题实时搜索零同步问题行为确定零黑盒问题当你有GPT-4/Claude这样的模型时工具的”蠢”不是缺点而是优点。因为所有智能都在模型里工具只要可靠就够了。2025年的启示现在回头看Claude Code的选择并不是倒退而是一种清醒。在AI能力已经很强的2025年真正稀缺的不是智能而是可预测性- 工具行为确定不是”大概率对”可调试性- 出错能定位不是AI黑盒可组合性- 工具能自由组合不是封闭系统可信赖性- 关键时刻不掉链子向量索引这些”聪明”的工具在90%的场景下很酷但在10%的关键时刻让你抓狂——当你最需要它准确的时候它给了你”语义相似”的错误答案。Grep/Glob这种”愚蠢”的工具在100%的场景下都可靠。搜错了改正则。找不到文件换个模式。每一步都清晰可控。作为一个程序员我更喜欢后者。Linus说过“Talk is cheap. Show me the code.”Unix哲学说“Do one thing and do it well.”Grep做了50年的搜索Glob做了50年的文件匹配现在还在用这本身就是最好的证明。Claude Code选择了一条看似”倒退”的路——不用向量数据库不建代码索引就用最基础的Unix工具。但这条路上有Unix的影子有Linus的实用主义有极简设计的智慧。在一个AI能力爆炸的时代也许最先进的设计就是让模型承担100%的智能让工具保持100%的简单。提供 最小化 Claude Code 实现Python 实现 mini-claude-code GitHub - shareAI-lab/mini_claude_code: 0 -1 diy your agent cli.Golang 实现 mini-claude-code GitHub - cexll/mini-claude-code-go: mini claude code for go参考资料谈谈Claude Code的设计哲学为什么最好的设计是”健忘”的Claude Code: Anthropic’s Agent in Your TerminalHow Claude Code is built - Pragmatic EngineerUnix Philosophy
最近在看Claude Code的设计发现一个有意思的现象当所有AI编程助手都在卷向量索引、语义搜索的时候Claude Code反其道而行——用Grep和Glob。Grep1973年诞生的文本搜索工具。GlobUnix shell里最基础的文件匹配。这个选择在技术圈引发了不小的争议。Milvus的博客说”Claude Code的grep-only方式会烧掉太多tokens”HackerNews上也有人质疑“Cursor用向量搜索Claude用grep这不是倒退吗“但Anthropic团队在访谈里透露了个细节他们测过RAG、向量索引这些方案最后发现这种”agentic search”让模型智能地使用Grep/Glob的效果反而最好。为什么会这样什么是”Agentic Search”Claude Code的搜索能力核心靠两个工具Glob- 文件模式匹配找文件。支持**/*.go、src/**/*.ts这样的模式Grep- 内容搜索搜代码。支持正则表达式可以过滤文件类型这两个工具本身很蠢。Glob只会按文件名匹配Grep只会按正则搜索都不懂语义。但当模型来驱动它们时就不一样了。用户说“找处理用户认证的代码”传统向量索引的做法工具: 语义搜索 user authentication 返回: login(), handleAuth(), verifyUser() ... 工具自己理解语义Claude Code的做法模型: 先用Glob找可能相关的文件 工具: glob **/*auth*.go 返回: auth.go, auth_handler.go, middleware/auth.go 模型: 在这些文件里搜关键词 工具: grep func.*Login auth.go 返回: func LoginHandler(...) 模型: 读一下这个函数 工具: read auth.go:35-60 返回: 函数实现代码看出区别了吗向量索引是让工具来理解语义然后给模型喂结果。 Agentic search是让模型来理解语义然后指挥工具执行。所有的智能都在模型里工具只负责最基础的操作。为什么简单工具更好传统IDE的做法是让工具自己变聪明。IntelliJ IDEA启动要构建PSI树、stub索引运行时要维护语法树、更新索引几个GB内存、几十个后台线程就这么没了。Cursor更进一步用Merkle树索引代码库智能分块后生成向量嵌入存到远程数据库。确实能做语义搜索——搜”用户认证”能找到login、authenticate、verifyUser这些不同命名的函数。但问题是当模型已经足够强大的时候这些工具层的智能是多余的。向量搜索失败的时候你要调试嵌入质量有问题语义理解偏了索引过期了分块策略不对向量数据库抖动排序算法有bugGrep失败就一个原因正则不匹配。改正则重新搜。而且模型可以做很多向量索引做不到的事组合使用Glob和Grep先缩小范围再精确搜索根据上一次搜索结果调整策略理解上下文知道在哪些文件里搜索更有可能找到出错后自我修正换个关键词再试这就是”agentic”的含义——让模型成为agent工具只是手。Claude Code的工具箱看看Claude Code实际提供的工具文件搜索Glob - 按文件名模式匹配Grep - 按内容搜索LS - 列文件文件操作Read - 读文件Edit/MultiEdit - 编辑文件Write - 写文件执行Bash - 执行命令其他WebFetch - 抓取网页WebSearch - 网络搜索Agent/Task - 启动子agentTodoWrite - 任务管理没有语法分析没有类型推导没有符号索引。都是最基础的操作。复杂的事情交给模型代码补全 → 模型理解上下文智能重构 → 模型理解语义错误检查 → 模型知道类型系统代码导航 → 模型组合Grep和Read意图理解 → 模型本身就是工具层保持简单模型层承担智能。无状态的优势Unix的设计哲学每个程序只做一件事并且做好。Grep做搜索不管搜索结果怎么用Glob找文件不管文件内容是什么。Claude Code继承了这个思想。对比有索引的系统启动构建索引几分钟运行维护索引后台线程崩溃恢复索引检查一致性修改更新索引增量or全量Grep/Glob启动立即可用运行实时执行崩溃重启就行修改下次自动看到每次搜索都是全新的每次结果都是最新的。没有状态就没有状态管理的复杂度。这也是为什么几百行代码就能实现一个基础的agent——当你不需要维护索引、缓存、状态时代码自然就简单了。什么时候简单比复杂更好Linus在选择宏内核vs微内核的时候说过“微内核在理论上很美但实践中复杂度爆炸。“向量索引在理论上很美语义搜索理解意图上下文推荐智能补全预构建索引搜索快但实践中需要上传代码隐私问题需要维护索引一致性问题需要同步状态分布式问题搜索失败难调试黑盒问题Grep/Glob在理论上很蠢只能模式匹配每次都重新搜不理解语义但实践中本地执行零隐私风险无需维护零一致性问题实时搜索零同步问题行为确定零黑盒问题当你有GPT-4/Claude这样的模型时工具的”蠢”不是缺点而是优点。因为所有智能都在模型里工具只要可靠就够了。2025年的启示现在回头看Claude Code的选择并不是倒退而是一种清醒。在AI能力已经很强的2025年真正稀缺的不是智能而是可预测性- 工具行为确定不是”大概率对”可调试性- 出错能定位不是AI黑盒可组合性- 工具能自由组合不是封闭系统可信赖性- 关键时刻不掉链子向量索引这些”聪明”的工具在90%的场景下很酷但在10%的关键时刻让你抓狂——当你最需要它准确的时候它给了你”语义相似”的错误答案。Grep/Glob这种”愚蠢”的工具在100%的场景下都可靠。搜错了改正则。找不到文件换个模式。每一步都清晰可控。作为一个程序员我更喜欢后者。Linus说过“Talk is cheap. Show me the code.”Unix哲学说“Do one thing and do it well.”Grep做了50年的搜索Glob做了50年的文件匹配现在还在用这本身就是最好的证明。Claude Code选择了一条看似”倒退”的路——不用向量数据库不建代码索引就用最基础的Unix工具。但这条路上有Unix的影子有Linus的实用主义有极简设计的智慧。在一个AI能力爆炸的时代也许最先进的设计就是让模型承担100%的智能让工具保持100%的简单。提供 最小化 Claude Code 实现Python 实现 mini-claude-code GitHub - shareAI-lab/mini_claude_code: 0 -1 diy your agent cli.Golang 实现 mini-claude-code GitHub - cexll/mini-claude-code-go: mini claude code for go参考资料谈谈Claude Code的设计哲学为什么最好的设计是”健忘”的Claude Code: Anthropic’s Agent in Your TerminalHow Claude Code is built - Pragmatic EngineerUnix Philosophy
基础架构设计与实现指南)
