AI coding agent 这两年越来越常见但很多 agent 第一步就是给仓库建索引。索引做得好定位符号快但代价也不小要常驻服务、要维护增量更新、要花时间等待首次索引。如果你对这种重方案有顾虑Atlarix 这种 local-first、基于 grep、无索引的 AI coding agent 值得先看看。它的核心思路并不复杂不建索引不依赖远端服务用 grep 在本地代码库里找线索把搜索结果作为上下文交给模型再生成改动方案。它解决的问题是在没有完整索引、没有大规模基础设施的情况下依然能给程序员一个“能跑起来的本地代码助手”。这篇文章不准备把它夸成什么全能工具更多是从实测和落地角度拆一下这套无索引方案解决的问题是什么适合哪些仓库拿到一个同类项目后怎么跑通最小闭环跑批量和接入日常开发时要注意什么。如果你正被建索引慢、代码不敢上传云端、小仓库用重 agent 太浪费这些问题困扰阅读价值会更高。1. 无索引不是偷懒是另一种取舍一个 AI coding agent 能不能高效理解代码库关键看它怎么定位代码。传统做法是建索引Atlarix 这类方案选择不建。理解这个取舍比记住功能列表重要得多。1.1 传统 coding agent 为什么喜欢建索引建索引的本质是把代码库里的符号、类型、引用关系、调用链提前抽取出来存成一种方便查询的结构。模型在回答问题时不再需要全量扫描所有源文件而是去索引里查某函数在哪里定义、哪里调用、哪些类型互相依赖。对于大型 monorepo这是必要的否则每次请求都可能因为扫描文件过多而超时。但索引不是免费的。首次建索引可能持续几分钟甚至几十分钟仓库越大越明显。索引建好之后还要持续更新有人改了文件、新增了依赖、移动了目录索引没过多久就又和真实代码不一致了。很多重型 agent 前端不觉得麻烦是因为集成方帮你把索引服务部署好了你自己部署时会遇到内存占用、定时任务、增量同步一堆问题。所以对一个中小型项目或本地个人项目来说建索引可能是一种过度设计。代码量不大全量扫描本来就很快多维护一套索引反而成了负担。这就是“无索引”方案存在的基础。1.2 无索引设计的实际收益无索引方案的核心是用 grep 这类文本检索工具在每次需要理解代码时动态地找出相关文件再把结果拼进给模型的提示里。这类方案的收益可以从几个方面看。第一是启动成本低。不需要等待索引生成拿到代码仓库就可以开始。依赖也少grep 几乎所有 Linux/macOS 环境都自带Windows 下也有 Git Bash 或 WSL 可用。第二是代码留在本地。查询过程是在本地目录里做的如果有人把模型也配置成本地模型整个闭环可以完全不联网适合对源码保密要求比较高的场景。第三是可解释性强。模型不是从某个黑盒索引里取结论而是基于你提供的 grep 输出生成回答至少你能检查检索依据是不是真实存在。第四是灵活度好。grep、rg、git grep想换哪种检索方式都可以绕开重量级中间件。这里要提醒一句无索引并不代表没有任何结构。项目里的目录组织、命名规范、文件边界仍然是模型理解代码的基础。只是它不像索引那样需要预先计算和持续维护而是把“检索”这件事交给调用时刻的文本匹配。2. 先确认适不适合你的项目没有索引是优点还是缺点取决于你的仓库形态。我在拿到一个 agent 类工具时第一件事不是看它支持多少命令而是拿自己的项目做一次小样本试跑再判断能不能继续用。2.1 适合哪些场景最适合的是中小型代码库比如个人项目、开源库、微服务里的单服务模块。代码量在几万到几十万行这个量级grep 全量扫描通常还是毫秒到秒级别加上模型推理时间体验可以接受。只要符号命名比较稳定“登录逻辑”能对应到 login.go 或者 auth.ts用文本匹配就能找到大部分关联文件。还适合隐私敏感或代码不能外传的环境。如果团队不允许把源码直接发给外部 API又想用 AI 辅助开发本地模型加本地检索就是一个合理组合。即使还是调用了外部模型至少你传给它的不是整个仓库而是通过 grep 筛选出来的少量相关片段外发数据的暴露范围会小很多。学习和小型重构也合适。比如你要梳理某个函数的所有调用点找出过时的 TODO或者清理重复代码grep 方案能快速给出候选清单再由 Agent 整理成可读报告。2.2 哪些情况会明显吃力有几类项目我不建议对无索引方案抱太高期望。首先是超大 monorepo。几十万上百万行代码没有索引的情况下每次都要扫全量速度会很难看。即使 grep 本身很快当文件数量达到几十万每次请求都全量扫一遍会占满磁盘 IO 和 CPU。这时要么靠目录白名单手工缩小范围要么还是得回到索引方案。其次是高度依赖语义关联的项目。文本匹配能找到出现某字符串的文件但找不出“两个名字完全不同、逻辑上却是一对”的实体。比如你的代码里有一个订单模型、一个支付回调两者没有共享词仅仅靠 grep 就很难把它们自动关联起来。如果项目还存在大量代码生成、反射调用、动态 import也会漏掉很多关系。此外二进制文件和重度压缩内容不适合 grep。打包产物、图片、序列化文件、minified JavaScript扫出来要么是一堆乱码要么是超长单行塞给模型反而浪费上下文。遇到这种仓库必须先排除这些目录。可以简单对照一下场景是否适合无索引 Agent中小型 Web/CLI 项目适合启动快、依赖少大型多模块仓库谨慎检索慢、需要排除范围隐私敏感、本地模型适合代码不出本机强语义、跨模块重构不太适合缺少索引和类型图大量二进制或压缩文件不适合需要先清理源快速原型/TODO 清理适合grep 能快速定位这个表不是我拍脑袋是跑过几次项目后比较稳定的经验。判断标准主要是你的代码能不能靠“出现某个词”被找到。能就适合不能就得考虑补充其它手段。3. 本地环境与最小闭环复现思路如果你打算实际玩一下这类方案我建议不要一开始就追求功能完整。先跑通一条最小路径grep 找出目标文件把结果交给模型得到一个可读结论。跑通之后再谈批量、配置和自动化。3.1 环境准备操作系统方面Linux/macOS 用系统自带 grep 就可以。Windows 建议用 Git Bash、WSL 或 PowerShell 的 Select-String否则可能遇到路径分隔符和编码问题。项目代码先放到本地目录确认有读权限。Agent 侧需要有一个能接收文本并回复的推理通道。可以选择本地模型比如通过 Ollama、llama.cpp 这类工具启动本地模型服务也可以调用外部模型 API但必须确认代码脱敏、隐私策略和公司合规要求。这一步不是广告只是给你一个可参考的方向。具体用哪种取决于你的显卡、内存、网络条件和数据敏感度。给一个很朴素的原则如果只是学习用你能最快启动的模型服务就行如果要处理公司代码先问自己“这段代码能不能放在当前模型服务的调用日志里”。能接受才继续。3.2 用 grep 构建模型上下文先演示最普通的 grep 用法。假设我要找 loadConfig 这个函数在 Python 项目里的定义和调用位置grep -rn loadConfig --include*.py .-r 递归-n 显示行号--include 只搜 Python 文件。如果不加 --include会把所有二进制、压缩包、图片文件也扫一遍结果杂乱还容易把 prompt 撑爆。如果仓库很大可以排除掉 node_modules、vendor、dist 这类目录grep -rn loadConfig --include*.js --exclude-dirnode_modules --exclude-dirdist .如果项目使用 Git我更喜欢用 git grepgit grep -n loadConfig -- *.jsgit grep 默认只搜 Git 已跟踪的文件不会把 .gitignore 里忽略的临时文件、构建产物卷进来。结果更干净速度通常也更快。这一点对无索引 Agent 很重要搜索噪音越少模型越不容易被无关内容带偏。接着把结果保存成临时文件方便作为上下文传给 Agentgrep -rn handleTimeout src/ --include*.go -C 3 context.txt-C 3 表示把匹配行附近的前后三行也带进去。这样模型能看到函数周围的上下文而不只是一行孤零零的匹配。“-C” 行数不要太夸张否则一个匹配点可能带出几十行整个 prompt 很快超过模型上下文长度。3.3 单条任务验证与人工审阅拿到 context.txt 之后就可以把它交给编码 Agent。用一个简单的提示词描述任务You are a coding assistant. The following grep results show occurrences of handleTimeout in the repository. Please identify: 1. Where handleTimeout is defined. 2. Where it is called. 3. What the current timeout behavior is. Then propose a minimal change to make the timeout configurable. Do not invent code that is not related to the grep results.这类提示词很朴素但它符合无索引方案的基本原则让模型基于当前检索结果作答而不是凭空猜测。模型回复之后不要直接复制到编辑器。先检查它引用的文件路径、函数名、行号是否真的和 context.txt 一致再决定是否采纳。我一般会把这一步当作“能跑”的验收标准Agent 能根据 grep 结果定位到一个真实存在的函数给出清晰的引用列表并且不会输出大段不存在的代码。能达到这个标准再继续做批量任务。达不到先回头检查检索结果是否准确不要急着增加模型参数。如果模型回答和搜索上下文明显相关但方案不实用多半是缺少项目约束。可以在 prompt 里加上一句请保持现有项目风格优先复用已有函数。这个约束虽然简单但对输出稳定性帮助很大。4. 关键参数和判断标准效果不能只看能不能跑很多项目刚上手都能跑通一个 demo但到真实任务就翻车。原因往往不是模型不够聪明而是参数没有调到一个合理范围或者你根本不知道什么样的输出算合格。无索引方案的几个关键参数值得逐项看一遍。4.1 需要关注的核心参数参数作用建议搜索路径决定扫描范围尽量限定到 src、app、lib 等有效目录include/exclude控制文件类型和忽略目录排除 node_modules、dist、build、vendor上下文行数 -C决定匹配行周围信息量新手先从 -C 2 或 -C 3 开始大小写 -i决定搜索是否区分大小写不确定时先开 -i再看结果噪音正则 -E支持更复杂的匹配需要匹配多个模式时使用模型上下文窗口决定能塞入多少 grep 结果单条任务控制在上下文一半以内并发/批量数决定同时跑多少任务先跑单条再逐步增加这些参数不是死的。以 -C 为例如果函数只有一行定义前后 3 行足够如果函数体很长3 行可能看不出逻辑需要把搜索范围改成先定位函数起始行再单独截取函数体。灵活度是很高但代价是你要花时间理解检索粒度。4.2 效果、速度和资源怎么判断判断效果不要只看模型是否返回了一大段文本。更靠谱的指标是它有没有列出具体文件路径和行号有没有直接引用你的代码片段有没有在回答里区分“代码库中已有逻辑”和“它自己补全的假设”。如果一个 Agent 回答得很顺但拿不出任何真实代码依据那它大概率是在编。还有个实用技巧处理运行时报错时不要直接让 Agent 猜原因。先执行 tail -n 50 server.log | grep -i error把日志里的错误行、堆栈摘出来和 grep 到的代码片段一起作为上下文。很多问题在日志里已经写了原因Agent 只是帮你翻译成代码改动。判断速度分开看检索时间和模型响应时间。grep 单次检索能在秒级完成说明扫描范围合理。模型响应时间则取决于本地显卡、显存、模型大小或 API 延迟。如果一次任务要等超过你耐心范围先看看是不是 grep 扫的目录太大或者 prompt 太长导致首字延迟变高。判断资源占用重点是 CPU、内存和磁盘 IO。无索引方案一般不会占用太多内存因为没有常驻索引服务但大批量并发时会同时拉起多个 grep 和多个模型请求内存和显存会快速上升。我的经验是不要一上来就开最大并发。先跑单条再看任务队列最后再考虑并行。低配置机器能跑单条不代表能跑批量。还有一点容易被忽略输出一致性。连续对同一个问题提问两次如果 Agent 一版一个结论说明 prompt 或者检索结果不稳定。无索引方案的检索结果通常是确定的同一个 grep 命令多次执行结果应该一致排除了检索波动后剩下的不稳定就要看模型和温度参数。5. 从单条问答到批量和日常工作流单条任务能吃透后面才有批量化的意义。不要反过来先搭一堆自动化结果单条问题还没跑通最后脚本报错都不知道去哪查。5.1 批量扫描问题线索批量任务不需要复杂框架。一个简单的思路是把想要扫描的模式写进一个 shell 循环每次输出到一个独立文件for pattern in FIXME TODO HACK deprecated; do grep -rn $pattern src/ --include*.ts --exclude-dirnode_modules output-${pattern}.txt done这样每个关键词都有独立的输出文件后续你想让 Agent 分别分析还是统一汇总都方便。一个常见的误区是把所有结果放在同一个大文件里然后让 Agent 一次性处理。如果文件过大超过上下文窗口模型只能看到前一部分后面的问题就会被漏掉。稳妥做法是按目录或按关键词拆分再逐份处理。批量任务还要考虑失败重试和输出命名。如果循环里遇到某个文件权限不足grep 可能直接报错脚本不会自动跳过。你需要在脚本里把错误重定向到日志保证一个文件失败不会导致整个任务中断。输出文件命名最好包含关键词和日期避免下次运行覆盖掉上次结果。5.2 把 Agent 接进日常开发工作流这种无索引 Agent 不一定要做成一个大型 IDE 插件。它完全可以作为命令行工具存在你在终端里跑一下 grep把结果丢给 Agent再拿回复做参考。轻量但有效。我的习惯是给常用命令做几个 alias。比如搜索某个函数时直接输入一个别名自动执行 git grep 并保存上下文文件。这不是 Atlarix 独有的能力而是无索引方案天然适合的交互方式需要什么临时查什么。如果你在 VS Code 里用可以把 grep 命令配置成任务或者用插件自带的终端命令。不要为了接入一个工具而把整个开发环境搞得特别复杂。反正它的核心卖点本来就是轻量如果部署完变成另一个常驻服务那还不如直接用带索引的方案。5.3 接入 CI 或定时任务的思路再进一步可以把这类 Agent 接进定时任务。比如每天晚上对仓库跑一次关键词扫描生成一份“待处理技术债”报告作为第二天开发的参考。这种场景不要求 Agent 实时响应延迟高一点也不影响。但 CI 场景要特别注意不要让 Agent 自动提交代码。无索引方案通过 grep 检索相关性但 grep 本质上不知道类型、不知道语义Agent 的输出仍然可能有错。正确的流程是Agent 生成建议人工 review再走 Git 提交和 PR。自动化和自动提交是两回事。另外如果定时任务跑得很频繁而你的模型是本地模型要考虑显卡和内存的持续占用。批量任务建议错峰执行避免和日常开发抢资源。6. 常见坑与排查顺序最后给一份我自己排查时会优先看的清单。这些问题不是 Atlarix 独有的任何靠 grep 搜索代码做上下文的 Agent 都可能遇到。6.1 结果少、漏代码先查搜索方式和范围如果 Agent 说找不到某个函数而你确认代码里一定有不要先怀疑模型。按这个顺序查看 grep 命令的搜索路径是否覆盖了文件所在目录。看 include 是否漏了文件后缀比如 .tsx、.vue、.svelte。看 exclude-dir 是否把有效目录也排除了。看大小写和正则转义loadConfig 和 loadconfig 完全不一样(、[、 这类字符也需要转义。看项目里有没有硬链接、软链接grep 默认可能不会跟随某些链接目录。看文件编码UTF-8 没问题GBK 中文注释可能匹配不到。如果用的是 git grep还需要注意新文件没有 git add 时git grep 搜不到。不是方法不存在是文件还没被 Git 跟踪。6.2 输出不准、乱改代码先缩小上下文模型基于 grep 结果编代码通常有两个原因。一个是上下文太窄只看到调用处没看到函数定义所以自己脑补了一个结构另一个是上下文太杂grep 同时匹配了同名但无关的内容模型被误导。遇到这种情况先不要反复调 prompt。先扩大视野把函数定义附近的代码也用 grep 定位出来加进 context。再检查搜索关键词是否太宽泛比如搜索 user所有 user 相关文件都出来了不如改为 userProfile 或 userId。上下文干净了模型输出基本会稳定。另外如果模型建议删掉一段逻辑一定要在改动前先看那段逻辑的引用点有多少。grep 搜索一下它在别处有没有被调用。没有索引的情况下这可能要你手动搜好几个关键词但至少比让模型直接删安全。6.3 卡住、无响应、太慢时的排查顺序任务卡住不一定是 Agent 功能有问题。先用最基础的手段确认环境# 查看进程和端口是否被占用 sudo ss -lntp | grep 8080 # 查看日志尾巴找错误关键字 tail -n 50 server.log | grep -i error\|timeout然后再看是不是输入文件太大。有些人习惯把整个 grep 结果塞进 prompt但一个 grep 大文件可能包含几万行直接超过模型上下文窗口模型服务可能长时间不返回。遇到这种情况把 -C 参数调小或者只保留匹配行或者按文件拆分。最后才是看模型服务本身的参数比如并发数、显存占用、温度。如果单条任务能稳定完成、批量任务开始卡那大概率是并发问题。先把并发降到 1一条一条跑确认稳定后再提高。排查顺序总结起来就是先看现象再看输入再看环境再看参数最后看模型。直接改模型参数是效率最低的排查方式因为很多问题在进入模型之前就发生了。无索引不是万能解但它给“轻量 AI coding agent”提供了一个很现实的思路仓库不大、不想建索引、代码又不能乱传时先用 grep 找到相关代码再让模型做理解和建议。这个方案真正落地时最该盯住的不是功能列表而是搜索范围、上下文大小和人工审阅。先把单任务跑稳再谈批量和自动化。踩过几次之后我发现很多问题不是工具能力不够而是搜索的代码范围太脏、边界没划清楚。 无索引AI编码助手：用grep实现轻量本地代码搜索
AI coding agent 这两年越来越常见但很多 agent 第一步就是给仓库建索引。索引做得好定位符号快但代价也不小要常驻服务、要维护增量更新、要花时间等待首次索引。如果你对这种重方案有顾虑Atlarix 这种 local-first、基于 grep、无索引的 AI coding agent 值得先看看。它的核心思路并不复杂不建索引不依赖远端服务用 grep 在本地代码库里找线索把搜索结果作为上下文交给模型再生成改动方案。它解决的问题是在没有完整索引、没有大规模基础设施的情况下依然能给程序员一个“能跑起来的本地代码助手”。这篇文章不准备把它夸成什么全能工具更多是从实测和落地角度拆一下这套无索引方案解决的问题是什么适合哪些仓库拿到一个同类项目后怎么跑通最小闭环跑批量和接入日常开发时要注意什么。如果你正被建索引慢、代码不敢上传云端、小仓库用重 agent 太浪费这些问题困扰阅读价值会更高。1. 无索引不是偷懒是另一种取舍一个 AI coding agent 能不能高效理解代码库关键看它怎么定位代码。传统做法是建索引Atlarix 这类方案选择不建。理解这个取舍比记住功能列表重要得多。1.1 传统 coding agent 为什么喜欢建索引建索引的本质是把代码库里的符号、类型、引用关系、调用链提前抽取出来存成一种方便查询的结构。模型在回答问题时不再需要全量扫描所有源文件而是去索引里查某函数在哪里定义、哪里调用、哪些类型互相依赖。对于大型 monorepo这是必要的否则每次请求都可能因为扫描文件过多而超时。但索引不是免费的。首次建索引可能持续几分钟甚至几十分钟仓库越大越明显。索引建好之后还要持续更新有人改了文件、新增了依赖、移动了目录索引没过多久就又和真实代码不一致了。很多重型 agent 前端不觉得麻烦是因为集成方帮你把索引服务部署好了你自己部署时会遇到内存占用、定时任务、增量同步一堆问题。所以对一个中小型项目或本地个人项目来说建索引可能是一种过度设计。代码量不大全量扫描本来就很快多维护一套索引反而成了负担。这就是“无索引”方案存在的基础。1.2 无索引设计的实际收益无索引方案的核心是用 grep 这类文本检索工具在每次需要理解代码时动态地找出相关文件再把结果拼进给模型的提示里。这类方案的收益可以从几个方面看。第一是启动成本低。不需要等待索引生成拿到代码仓库就可以开始。依赖也少grep 几乎所有 Linux/macOS 环境都自带Windows 下也有 Git Bash 或 WSL 可用。第二是代码留在本地。查询过程是在本地目录里做的如果有人把模型也配置成本地模型整个闭环可以完全不联网适合对源码保密要求比较高的场景。第三是可解释性强。模型不是从某个黑盒索引里取结论而是基于你提供的 grep 输出生成回答至少你能检查检索依据是不是真实存在。第四是灵活度好。grep、rg、git grep想换哪种检索方式都可以绕开重量级中间件。这里要提醒一句无索引并不代表没有任何结构。项目里的目录组织、命名规范、文件边界仍然是模型理解代码的基础。只是它不像索引那样需要预先计算和持续维护而是把“检索”这件事交给调用时刻的文本匹配。2. 先确认适不适合你的项目没有索引是优点还是缺点取决于你的仓库形态。我在拿到一个 agent 类工具时第一件事不是看它支持多少命令而是拿自己的项目做一次小样本试跑再判断能不能继续用。2.1 适合哪些场景最适合的是中小型代码库比如个人项目、开源库、微服务里的单服务模块。代码量在几万到几十万行这个量级grep 全量扫描通常还是毫秒到秒级别加上模型推理时间体验可以接受。只要符号命名比较稳定“登录逻辑”能对应到 login.go 或者 auth.ts用文本匹配就能找到大部分关联文件。还适合隐私敏感或代码不能外传的环境。如果团队不允许把源码直接发给外部 API又想用 AI 辅助开发本地模型加本地检索就是一个合理组合。即使还是调用了外部模型至少你传给它的不是整个仓库而是通过 grep 筛选出来的少量相关片段外发数据的暴露范围会小很多。学习和小型重构也合适。比如你要梳理某个函数的所有调用点找出过时的 TODO或者清理重复代码grep 方案能快速给出候选清单再由 Agent 整理成可读报告。2.2 哪些情况会明显吃力有几类项目我不建议对无索引方案抱太高期望。首先是超大 monorepo。几十万上百万行代码没有索引的情况下每次都要扫全量速度会很难看。即使 grep 本身很快当文件数量达到几十万每次请求都全量扫一遍会占满磁盘 IO 和 CPU。这时要么靠目录白名单手工缩小范围要么还是得回到索引方案。其次是高度依赖语义关联的项目。文本匹配能找到出现某字符串的文件但找不出“两个名字完全不同、逻辑上却是一对”的实体。比如你的代码里有一个订单模型、一个支付回调两者没有共享词仅仅靠 grep 就很难把它们自动关联起来。如果项目还存在大量代码生成、反射调用、动态 import也会漏掉很多关系。此外二进制文件和重度压缩内容不适合 grep。打包产物、图片、序列化文件、minified JavaScript扫出来要么是一堆乱码要么是超长单行塞给模型反而浪费上下文。遇到这种仓库必须先排除这些目录。可以简单对照一下场景是否适合无索引 Agent中小型 Web/CLI 项目适合启动快、依赖少大型多模块仓库谨慎检索慢、需要排除范围隐私敏感、本地模型适合代码不出本机强语义、跨模块重构不太适合缺少索引和类型图大量二进制或压缩文件不适合需要先清理源快速原型/TODO 清理适合grep 能快速定位这个表不是我拍脑袋是跑过几次项目后比较稳定的经验。判断标准主要是你的代码能不能靠“出现某个词”被找到。能就适合不能就得考虑补充其它手段。3. 本地环境与最小闭环复现思路如果你打算实际玩一下这类方案我建议不要一开始就追求功能完整。先跑通一条最小路径grep 找出目标文件把结果交给模型得到一个可读结论。跑通之后再谈批量、配置和自动化。3.1 环境准备操作系统方面Linux/macOS 用系统自带 grep 就可以。Windows 建议用 Git Bash、WSL 或 PowerShell 的 Select-String否则可能遇到路径分隔符和编码问题。项目代码先放到本地目录确认有读权限。Agent 侧需要有一个能接收文本并回复的推理通道。可以选择本地模型比如通过 Ollama、llama.cpp 这类工具启动本地模型服务也可以调用外部模型 API但必须确认代码脱敏、隐私策略和公司合规要求。这一步不是广告只是给你一个可参考的方向。具体用哪种取决于你的显卡、内存、网络条件和数据敏感度。给一个很朴素的原则如果只是学习用你能最快启动的模型服务就行如果要处理公司代码先问自己“这段代码能不能放在当前模型服务的调用日志里”。能接受才继续。3.2 用 grep 构建模型上下文先演示最普通的 grep 用法。假设我要找 loadConfig 这个函数在 Python 项目里的定义和调用位置grep -rn loadConfig --include*.py .-r 递归-n 显示行号--include 只搜 Python 文件。如果不加 --include会把所有二进制、压缩包、图片文件也扫一遍结果杂乱还容易把 prompt 撑爆。如果仓库很大可以排除掉 node_modules、vendor、dist 这类目录grep -rn loadConfig --include*.js --exclude-dirnode_modules --exclude-dirdist .如果项目使用 Git我更喜欢用 git grepgit grep -n loadConfig -- *.jsgit grep 默认只搜 Git 已跟踪的文件不会把 .gitignore 里忽略的临时文件、构建产物卷进来。结果更干净速度通常也更快。这一点对无索引 Agent 很重要搜索噪音越少模型越不容易被无关内容带偏。接着把结果保存成临时文件方便作为上下文传给 Agentgrep -rn handleTimeout src/ --include*.go -C 3 context.txt-C 3 表示把匹配行附近的前后三行也带进去。这样模型能看到函数周围的上下文而不只是一行孤零零的匹配。“-C” 行数不要太夸张否则一个匹配点可能带出几十行整个 prompt 很快超过模型上下文长度。3.3 单条任务验证与人工审阅拿到 context.txt 之后就可以把它交给编码 Agent。用一个简单的提示词描述任务You are a coding assistant. The following grep results show occurrences of handleTimeout in the repository. Please identify: 1. Where handleTimeout is defined. 2. Where it is called. 3. What the current timeout behavior is. Then propose a minimal change to make the timeout configurable. Do not invent code that is not related to the grep results.这类提示词很朴素但它符合无索引方案的基本原则让模型基于当前检索结果作答而不是凭空猜测。模型回复之后不要直接复制到编辑器。先检查它引用的文件路径、函数名、行号是否真的和 context.txt 一致再决定是否采纳。我一般会把这一步当作“能跑”的验收标准Agent 能根据 grep 结果定位到一个真实存在的函数给出清晰的引用列表并且不会输出大段不存在的代码。能达到这个标准再继续做批量任务。达不到先回头检查检索结果是否准确不要急着增加模型参数。如果模型回答和搜索上下文明显相关但方案不实用多半是缺少项目约束。可以在 prompt 里加上一句请保持现有项目风格优先复用已有函数。这个约束虽然简单但对输出稳定性帮助很大。4. 关键参数和判断标准效果不能只看能不能跑很多项目刚上手都能跑通一个 demo但到真实任务就翻车。原因往往不是模型不够聪明而是参数没有调到一个合理范围或者你根本不知道什么样的输出算合格。无索引方案的几个关键参数值得逐项看一遍。4.1 需要关注的核心参数参数作用建议搜索路径决定扫描范围尽量限定到 src、app、lib 等有效目录include/exclude控制文件类型和忽略目录排除 node_modules、dist、build、vendor上下文行数 -C决定匹配行周围信息量新手先从 -C 2 或 -C 3 开始大小写 -i决定搜索是否区分大小写不确定时先开 -i再看结果噪音正则 -E支持更复杂的匹配需要匹配多个模式时使用模型上下文窗口决定能塞入多少 grep 结果单条任务控制在上下文一半以内并发/批量数决定同时跑多少任务先跑单条再逐步增加这些参数不是死的。以 -C 为例如果函数只有一行定义前后 3 行足够如果函数体很长3 行可能看不出逻辑需要把搜索范围改成先定位函数起始行再单独截取函数体。灵活度是很高但代价是你要花时间理解检索粒度。4.2 效果、速度和资源怎么判断判断效果不要只看模型是否返回了一大段文本。更靠谱的指标是它有没有列出具体文件路径和行号有没有直接引用你的代码片段有没有在回答里区分“代码库中已有逻辑”和“它自己补全的假设”。如果一个 Agent 回答得很顺但拿不出任何真实代码依据那它大概率是在编。还有个实用技巧处理运行时报错时不要直接让 Agent 猜原因。先执行 tail -n 50 server.log | grep -i error把日志里的错误行、堆栈摘出来和 grep 到的代码片段一起作为上下文。很多问题在日志里已经写了原因Agent 只是帮你翻译成代码改动。判断速度分开看检索时间和模型响应时间。grep 单次检索能在秒级完成说明扫描范围合理。模型响应时间则取决于本地显卡、显存、模型大小或 API 延迟。如果一次任务要等超过你耐心范围先看看是不是 grep 扫的目录太大或者 prompt 太长导致首字延迟变高。判断资源占用重点是 CPU、内存和磁盘 IO。无索引方案一般不会占用太多内存因为没有常驻索引服务但大批量并发时会同时拉起多个 grep 和多个模型请求内存和显存会快速上升。我的经验是不要一上来就开最大并发。先跑单条再看任务队列最后再考虑并行。低配置机器能跑单条不代表能跑批量。还有一点容易被忽略输出一致性。连续对同一个问题提问两次如果 Agent 一版一个结论说明 prompt 或者检索结果不稳定。无索引方案的检索结果通常是确定的同一个 grep 命令多次执行结果应该一致排除了检索波动后剩下的不稳定就要看模型和温度参数。5. 从单条问答到批量和日常工作流单条任务能吃透后面才有批量化的意义。不要反过来先搭一堆自动化结果单条问题还没跑通最后脚本报错都不知道去哪查。5.1 批量扫描问题线索批量任务不需要复杂框架。一个简单的思路是把想要扫描的模式写进一个 shell 循环每次输出到一个独立文件for pattern in FIXME TODO HACK deprecated; do grep -rn $pattern src/ --include*.ts --exclude-dirnode_modules output-${pattern}.txt done这样每个关键词都有独立的输出文件后续你想让 Agent 分别分析还是统一汇总都方便。一个常见的误区是把所有结果放在同一个大文件里然后让 Agent 一次性处理。如果文件过大超过上下文窗口模型只能看到前一部分后面的问题就会被漏掉。稳妥做法是按目录或按关键词拆分再逐份处理。批量任务还要考虑失败重试和输出命名。如果循环里遇到某个文件权限不足grep 可能直接报错脚本不会自动跳过。你需要在脚本里把错误重定向到日志保证一个文件失败不会导致整个任务中断。输出文件命名最好包含关键词和日期避免下次运行覆盖掉上次结果。5.2 把 Agent 接进日常开发工作流这种无索引 Agent 不一定要做成一个大型 IDE 插件。它完全可以作为命令行工具存在你在终端里跑一下 grep把结果丢给 Agent再拿回复做参考。轻量但有效。我的习惯是给常用命令做几个 alias。比如搜索某个函数时直接输入一个别名自动执行 git grep 并保存上下文文件。这不是 Atlarix 独有的能力而是无索引方案天然适合的交互方式需要什么临时查什么。如果你在 VS Code 里用可以把 grep 命令配置成任务或者用插件自带的终端命令。不要为了接入一个工具而把整个开发环境搞得特别复杂。反正它的核心卖点本来就是轻量如果部署完变成另一个常驻服务那还不如直接用带索引的方案。5.3 接入 CI 或定时任务的思路再进一步可以把这类 Agent 接进定时任务。比如每天晚上对仓库跑一次关键词扫描生成一份“待处理技术债”报告作为第二天开发的参考。这种场景不要求 Agent 实时响应延迟高一点也不影响。但 CI 场景要特别注意不要让 Agent 自动提交代码。无索引方案通过 grep 检索相关性但 grep 本质上不知道类型、不知道语义Agent 的输出仍然可能有错。正确的流程是Agent 生成建议人工 review再走 Git 提交和 PR。自动化和自动提交是两回事。另外如果定时任务跑得很频繁而你的模型是本地模型要考虑显卡和内存的持续占用。批量任务建议错峰执行避免和日常开发抢资源。6. 常见坑与排查顺序最后给一份我自己排查时会优先看的清单。这些问题不是 Atlarix 独有的任何靠 grep 搜索代码做上下文的 Agent 都可能遇到。6.1 结果少、漏代码先查搜索方式和范围如果 Agent 说找不到某个函数而你确认代码里一定有不要先怀疑模型。按这个顺序查看 grep 命令的搜索路径是否覆盖了文件所在目录。看 include 是否漏了文件后缀比如 .tsx、.vue、.svelte。看 exclude-dir 是否把有效目录也排除了。看大小写和正则转义loadConfig 和 loadconfig 完全不一样(、[、 这类字符也需要转义。看项目里有没有硬链接、软链接grep 默认可能不会跟随某些链接目录。看文件编码UTF-8 没问题GBK 中文注释可能匹配不到。如果用的是 git grep还需要注意新文件没有 git add 时git grep 搜不到。不是方法不存在是文件还没被 Git 跟踪。6.2 输出不准、乱改代码先缩小上下文模型基于 grep 结果编代码通常有两个原因。一个是上下文太窄只看到调用处没看到函数定义所以自己脑补了一个结构另一个是上下文太杂grep 同时匹配了同名但无关的内容模型被误导。遇到这种情况先不要反复调 prompt。先扩大视野把函数定义附近的代码也用 grep 定位出来加进 context。再检查搜索关键词是否太宽泛比如搜索 user所有 user 相关文件都出来了不如改为 userProfile 或 userId。上下文干净了模型输出基本会稳定。另外如果模型建议删掉一段逻辑一定要在改动前先看那段逻辑的引用点有多少。grep 搜索一下它在别处有没有被调用。没有索引的情况下这可能要你手动搜好几个关键词但至少比让模型直接删安全。6.3 卡住、无响应、太慢时的排查顺序任务卡住不一定是 Agent 功能有问题。先用最基础的手段确认环境# 查看进程和端口是否被占用 sudo ss -lntp | grep 8080 # 查看日志尾巴找错误关键字 tail -n 50 server.log | grep -i error\|timeout然后再看是不是输入文件太大。有些人习惯把整个 grep 结果塞进 prompt但一个 grep 大文件可能包含几万行直接超过模型上下文窗口模型服务可能长时间不返回。遇到这种情况把 -C 参数调小或者只保留匹配行或者按文件拆分。最后才是看模型服务本身的参数比如并发数、显存占用、温度。如果单条任务能稳定完成、批量任务开始卡那大概率是并发问题。先把并发降到 1一条一条跑确认稳定后再提高。排查顺序总结起来就是先看现象再看输入再看环境再看参数最后看模型。直接改模型参数是效率最低的排查方式因为很多问题在进入模型之前就发生了。无索引不是万能解但它给“轻量 AI coding agent”提供了一个很现实的思路仓库不大、不想建索引、代码又不能乱传时先用 grep 找到相关代码再让模型做理解和建议。这个方案真正落地时最该盯住的不是功能列表而是搜索范围、上下文大小和人工审阅。先把单任务跑稳再谈批量和自动化。踩过几次之后我发现很多问题不是工具能力不够而是搜索的代码范围太脏、边界没划清楚。