Grep 为何能击败 LSP？
Grep beats LSP? Why coding agents ignore your fancier tools
我本以为语义导航能帮 Coding Agent 减少噪声，但测试发现它们更偏爱简单的 Grep。强制使用 LSP 反而降低了任务成功率。关键在于工具是否对 LLM 友好：结果不仅要精准，更要提供模型能直接利用的上下文。当 LSP 返回结果包含代码片段时，效率显著提升。这说明 Agent 的能力取决于模型与工具运行环境（Harness）的协同，而非模型本身。在嘈杂的代码库中，语义导航确实有价值，但工具接口的设计必须匹配模型的交互习惯。
工具对模型友好，不仅在于结果精准，更在于能否提供下一步所需的上下文，并以模型可直接使用的形式呈现。
HN 评论区
54- tonyarkles
我和 Claude Code 之间经历了一种有趣的协同进化。我会让它执行某个任务，观察它的操作（通常是大量的 find、grep 和 ripgrep），任务完成后，我会问它有没有什么工具能让工作更轻松。这促使我发现了 fzf 等工具（比如用于索引邮件的 notmuch）。随后，我将这些工具整合进自己的工作流中，无论是 CLI 还是 Emacs。
我们还合作开发了一些 Python 工具，用于处理我常需分析和处理的某种较慢的数据格式。该工具对整个语料库进行了索引，分析时，我（或 Claude Code）只需进行一次转换即可生成 Parquet 格式，之后便可用 DuckDB 进行查询。这个工具极大地缩短了我一次性分析任务的周转时间；此外，作为一个基于 Typer 构建的 Python CLI 工具，其接口对 LLM 调用框架来说也非常易于发现。
- ghthor
我把 serena 用作所有 LSP 的 MCP，效果很棒。它会安装钩子，提醒 Claude 使用 LSP 工具。
- nomilk
有点跑题，但我的 LSP 配置每隔几个月就会出问题。我懒得自己修了，直接打开 ~/dotfiles 目录下的 LLM，抱怨一番直到它修好，通常几分钟就能搞定。
有趣的是，观察这个过程需要多少工作量。（这让我对过去的自己多了几分同情：一个笨拙的人类怎么可能知道并推理出这些东西！？尤其是当我几个月没碰过这些配置，几乎完全忘了它们的时候）。
通常情况下，有 10 到 20 个非常小的程序协同工作才能提供预期的体验。解决这些看似简单的问题（比如“我的 LSP 不工作了”）所需的分钟数和 token 数，有时远超预期。
- the_duke
我写了一个能打印稀疏 AST 的工具，效果非常好。
https://github.com/theduke/smartedit
安装该插件后，GPT 5.6 通常会自动使用它，显著减少了代码探索时间和 token 消耗。例如，它只需打印文件中的类型和函数（不含函数体），仅在需要时才展开。
（注：它也有编辑功能，但效果不太好，因为模型在后期训练中严重偏向于常见的编辑工具。）
- x-complexity
要让 LSP 正常工作，依赖两个前提条件：
(a) LSP 的工具本身构建精良且一致；
(b) 使用它的 LLM 经过充分训练，能够正确使用 LSP。
使用像 grep 这样的原生工具同样依赖这两个假设，但：
(a) 由于 grep 核心功能的固化（这是好事），这一条件已得到满足；
(b) 这一条件更是超额满足，因为 LLM 可以被专门训练来正确使用 grep，而不是去适应“20 种被 LSP 包装的 grep 变体，它们略有不同，容易让人措手不及”。
此外，grep 几乎总是存在于默认的 Linux 环境中，因此其存在是默认假设，需要时可以放心依赖。