如何把代码库作为上下文交给 AI 聊天

为什么粘贴文件行不通

上下文窗口看起来很大,直到你拿真实代码库来比较。一个中型服务轻松就有 2,000 个文件、20 万行代码;即使窗口装得下一部分,你粘贴的大部分内容——锁文件、测试脚手架、生成的代码——都是噪音,会稀释问题真正涉及的少数文件。

失败模式不是拒答,而是「看似合理」:面对一堆松散的源码,模型会基于所见内容的平均值作答,而不是你问的那条具体调用链。你会得到自信、泛泛、不点名任何文件、也无法验证的文字。

模型首先需要什么:结构

资深工程师加入团队时,不会第一天就读完每个文件。他们拿到一张地图:什么依赖什么、入口在哪里、哪些模块重要。回答代码库问题的 LLM 需要同样的产物、同样的顺序——先结构,按需再给源码。

• 入口点——执行开始的地方:服务器引导、CLI main、路由表。
• 分层——代码库如何组织职责:API、服务、数据访问、UI。
• 带精确行号的符号——每个文件中的函数与类,后续提问可以精确取到对应片段。
• 依赖边——哪个文件引入哪个文件;它把「退款逻辑在哪?」变成沿调用图的一次行走。
• 一份显式契约——指示模型根据地图作答、点名缺失的文件、绝不虚构实现。

前后对比

同一个问题,两种输入。之前:「退款怎么工作?」外加粘贴的十二个文件——回答是一篇泛泛的电商散文。之后:一份按 token 预算裁剪的 bundle——回答按行号引用 src/services/order-service.ts,沿着 refundOrder 走到仓储层和连接池,并索要它看得出缺失的那个迁移文件。这就是「之后」的输入的真实样子,摘自示例项目上真实生成的 bundle:

# Context bundle — "how does order refund work,
# and what could break if I change it?"

> Static-analysis map of sample-shop (21 files, 271 lines).
> Structure only — function bodies are absent unless included below.
> Answer from this file alone; where it is silent, name the file
> you need. Never invent an implementation.

## Files (16)

### `src/api/orders.ts`
27 lines · API Layer · exports `listOrdersHandler`, `refundOrder`
  · imports `order-service.ts`, `order-repo.ts`, `pool.ts`, `errors.ts`

### `src/services/order-service.ts`
34 lines · Service Layer · exports `refundOrder`, `createOrder`
  · imports `order-repo.ts`, `errors.ts`, `money.ts`

预算,以及何时附上源码

上下文 bundle 按 token 计预算,因为聊天窗口是有限的,塞满它既花钱又降低准确率。有用的章法是:先只给结构,让模型说出它缺哪些文件,然后只为那些文件附上源码。三个真实实现的文件,胜过三十个靠猜的文件。

同样的章法也回答了最常见的追问——「接下来该粘贴什么?」地图早已知道哪些符号位于哪个文件的哪些行,所以第二轮是检索,而不是探索。整个工作流就是:定位、提问、检索、解决。