本文是专栏《AI 编程实战》第 2 篇。回到目录与导读。上一篇：AI 编程的三次进化。
上一篇说第三代工具能改一整个项目。但这里有个矛盾：《大模型专栏》第 5 篇讲过，模型的上下文窗口是有限的，一次装不下太多内容。那一个几十万行、上千个文件的代码库，它根本读不完，怎么可能改得对？
答案很关键，也解释了 AI 编程好用与不好用的分水岭：
它不是把整个项目背进脑子，而是像一个刚接手项目的老工程师——用到哪，才去翻哪几个文件。
人类工程师怎么读陌生项目？
想想你接手一个陌生代码库、要改"登录"功能时，你会怎么做？你不会从第一行读到最后一行。你会：
- 搜一下
login关键词，看看相关代码在哪几个文件； - 打开这几个文件，顺藤摸瓜看它调用了谁、被谁调用；
- 心里大概有数了，就动手改。
你全程只读了整个项目的一小部分——但正好是相关的那部分。 AI 编程工具干的是一模一样的事，只不过它翻文件的速度快得多。
工具的两种"翻文件"办法
第三代工具主要靠两种方式，把"相关的那几个文件"塞进模型的上下文里。
办法一：按意思检索（语义检索 / RAG）
有些工具会预先把你项目里的每段代码，转成一串代表其"含义"的数字（向量），存进一个库。你提需求时，它把你的需求也转成向量，去库里找意思最接近的几段代码捞出来。
这正是《AI Agent 专栏》第 6 篇讲的 RAG（检索增强生成），只不过检索的对象从"文档"换成了"代码"。好处是：你说"改一下支付逻辑"，就算你不知道代码在哪个文件，它也能靠"意思相近"找到相关代码。
办法二：像人一样主动搜（工具调用）
另一些工具（尤其是智能体式的，如 Claude Code）走的是更"拟人"的路子：给模型配上 搜索、读文件、列目录 这些工具，让它自己一步步去探索。
目标：修复"导出 Excel 时中文乱码"
模型的动作：
搜 "export" "excel" → 找到 export_service.py
读 export_service.py → 看到用了某个编码库
搜 该库的用法 → 定位到编码设置那一行
→ 找到问题，动手改
这本质就是ReAct 循环："想一下该看什么 → 去看 → 根据看到的再决定下一步"。它更灵活、更接近老工程师的排查过程，代价是多花几轮来回、多花点算力。
实际产品里，这两种办法常常混着用：先用检索快速缩小范围，再让模型主动去翻关键文件确认。
你能帮它"看得更准"的几件事
理解了原理，就知道怎么配合能让它干得更好——核心是"帮它更快找到对的文件"：
- 项目结构清晰：文件、函数命名见名知意。你搜得到的，它也搜得到；你靠命名猜得出的，它也猜得出。一团乱麻的代码库，AI 也会晕。
- 主动给线索：直接告诉它"相关代码在
src/payment/目录"或"参考OrderService的写法"，能省掉它一堆摸索，又快又准。 - 写好项目说明：很多工具支持一个项目级的说明文件（比如放在仓库根目录，约定项目架构、规范、常用命令）。相当于给新来的工程师一份"入职手册"，它每次干活前都会先读。
- 别指望它懂"只在你脑子里"的背景：没写进代码、没写进文档的隐含约定（"这个字段其实弃用了""那个接口线上不能动"），它无从得知——这些得你显式说。
为什么它有时会"看漏"
明白了机制，也就明白了它出错的常见原因——几乎都出在"没找到对的上下文"：
- 相关代码藏得太隐蔽：命名奇怪、逻辑绕、跨了好几层，检索和搜索都没捞到关键那段，它就只能凭不全的信息瞎猜。
- 项目太大、关系太复杂：改 A 处会牵动远在天边的 B 处，而 B 处没被读进来，它就漏改了。
- 上下文塞太满：硬把一堆文件全塞进去，反而触发《大模型专栏》第 5 篇说的"中间迷失"——关键信息埋在中间被读漏。给得准，比给得多重要。
一句话：AI 改代码出错，很多时候不是它"笨",而是它"没看到该看的那部分"。 你的活儿，就是帮它把视野对准。
小结
- 模型上下文有限，所以它不是通读整个项目，而是按需只看相关的几个文件——和老工程师读陌生代码一个套路。
- 两种"翻文件"办法：语义检索（RAG，按意思找） 和 主动搜索（配工具让它自己探索，即 ReAct），实际常混用。
- 你能帮它看得更准：清晰的结构与命名、主动给线索、写好项目说明文件、显式交代隐含背景。
- 它出错多半源于没找到该看的上下文——给得准比给得多重要。
它能找到对的文件、也读懂了，接下来就看你把需求讲得清不清楚了。下一篇讲一个被严重低估的技能：给 AI 写代码的"提示词"，本质是在写一份"规格说明"。