最近讨论 100万 Token 上下文时，有人聊到了代码规模。 这让我联想到一个问题： 把代码仓库交给 AI，它到底是怎么找到相关代码的？ 我调研学习了目前… · @manongfu · TwKit

@manongfu

最近讨论 100万 Token 上下文时，有人聊到了代码规模。 这让我联想到一个问题： 把代码仓库交给 AI，它到底是怎么找到相关代码的？ 我调研学习了目前常见的几种方式。即使模型已经支持百万 Token 上下文，它们依然各有价值。 1. Grep：按关键词搜索 这是最简单直接的方式：速度快、匹配精确，也不需要提前建立索引。 但它有一个前提：你得大致知道要搜什么。 如果只知道要找「最终支付金额的计算逻辑」，却不知道相关函数、变量或业务术语叫什么，可能就没那么容易找到。 2. 语义搜索：按意思寻找代码 如果不知道准确的关键词，可以尝试用自然语言描述： 「找到用户下单时计算最终支付金额的代码」。 语义搜索通常会通过 Embedding，将问题和代码片段转换成向量，再寻找语义相近的内容，不要求关键词完全匹配。 不过，语义相近不等于找对了逻辑。它可能找到的是订单金额的展示代码，而不是真正计算支付金额的地方。 3. AST / LSP / 调用图：梳理代码关系 找到相关代码只是第一步，还需要弄清楚它和其他代码有什么关系。 1）AST ，将代码解析成结构化的语法树，方便分析代码结构。 2）LSP ，提供跳转定义、查找引用、获取类型信息等能力。 3）调用图，帮助梳理函数之间的调用关系。 借助这些工具，AI 可以从一个函数出发，继续查看它调用了什么、被哪里调用，再结合代码追踪数据如何传递。 4. Agent 自主探索：边查边决定下一步 例如，要理解订单金额的计算过程，AI 可能会先找到下单入口，阅读后发现它调用了优惠券模块；接着查看优惠券实现，再继续追踪会员折扣、运费和最终支付金额的计算。 整个过程中，AI 会根据每一步发现的信息，决定下一步搜索什么、阅读什么。它也可以组合使用前面提到的工具，逐步理解一个陌生仓库。 从几家主流产品的公开实践来看，它们的侧重点并不完全相同： 1）Claude Code：大量使用 Grep 和按需读取文件。 2）OpenAI Codex：使用 rg 等工具搜索代码。 3）Cursor：提供 Instant Grep 等搜索能力，也曾采用语义索引方案。 我觉得这里有个共同的特点：Agent 不再只是被动接收代码，而是会根据任务主动寻找、筛选和组织上下文。 百万 Token 上下文解决的是：能装下多少信息？ 而 Coding Agent 还需要回答： 当前任务需要哪些信息？怎么找到它们？找到之后，又怎么理解和验证？ 给 AI 更多代码，不一定比给它正确的代码更有价值。

曝光 99 · 评论 2 · 点赞 1 · 书签 0