200K行代码，README两年前更新，架构文档不存在——这是每个开发者入职第一天就会遇到的经典场景。读代码比写代码难，随机翻文件只会让你浪费几小时却毫无头绪。
这里有一套把AI变成代码导游的方法。中等规模项目，30分钟完成摸底。
第一步：先看地图，再进房间
读代码之前，先理解项目的形状。用tree命令限制深度，避免被文件淹没：
# 获取项目前两级结构tree -L 2 -I 'node_modules|.git|__pycache__|.venv|dist'# 大型项目只看目录tree -L 3 -d -I 'node_modules|.git|__pycache__|.venv'
输出大概长这样：
├── src/
│ ├── api/
│ ├── models/
│ ├── services/
│ └── utils/
├── tests/
│ ├── unit/
│ └── integration/
├── docker-compose.yml
├── pyproject.toml
└── README.md
把tree输出贴进AI助手（ChatGPT、Claude、Copilot Chat都行），问：
「这是刚接手的项目文件树。每个顶层目录大概是做什么的？暗示了什么架构模式？」
60秒后你拿到一张心理地图：API路由在哪、业务逻辑放哪、测试在哪。大脑处理空间布局比处理文本快，文件树就是代码库的空间地图，AI负责填标签。
第二步：配置文件是最诚实的文档
配置文件列出的是实际依赖、脚本和设置——不是某人想写什么，而是项目实际在用什么。
按这个顺序读：
# Python项目cat pyproject.toml # 或requirements.txt、setup.py# JavaScript项目cat package.json# 有容器的项目cat docker-compose.yml# 环境变量告诉你有哪些外部服务cat .env.example # 别碰.env——那是真密钥
Python项目的pyproject.toml能告诉你一切：
[project]dependencies = ["fastapi>=0.104.0","sqlalchemy>=2.0","pydantic>=2.5","httpx>=0.25.0","celery>=5.3.0",][project.scripts]serve = "app.main:run"worker = "app.tasks:start_worker"
这10行透露的信息：FastAPI做API层、SQLAlchemy管数据库、Pydantic做数据验证、HTTPX发外部请求、Celery跑后台任务。两个入口脚本：serve启动服务，worker启动任务处理器。
把配置文件贴给AI，问：
「根据这些依赖，这个项目是做什么的？需要哪些外部服务？」
5分钟过去。你已经知道技术栈、外部依赖和入口点。
第三步：找到前门，跟一次完整请求
每个应用都有个前门。找到它，然后追踪第一个请求的完整路径。
入口点通常长这样：
# Python/FastAPI# 找包含@app.get/@app.post的文件find . -name "*.py" -type f | head -20 | xargs grep -l "app = FastAPI\|@app\." 2>/dev/null# JavaScript/Express# 找app.listen或router定义find . -name "*.js" -type f | head -20 | xargs grep -l "app.listen\|router\|express()" 2>/dev/null
找到入口文件后，挑一个最简单的路由（比如GET /health或GET /status），手动追踪：
1. 请求从哪进（路由定义）2. 经过什么中间件3. 调用哪个服务/控制器4. 怎么跟数据库交互5. 响应怎么组装返回
把入口文件和一条路由的代码贴给AI：
「这是入口文件和/health路由的实现。帮我画出这条请求的数据流：从进来到出去经过了哪些组件？」
AI会生成一个流程图式的说明。你现在理解了一条请求的生命周期，这是理解整个架构的锚点。
10分钟。你掌握了请求流转的核心路径。
第四步：让AI解释关键抽象
每个代码库都有一组核心抽象：用户、订单、会话、任务—— whatever the domain is。找到这些类的定义，让AI解释它们之间的关系。
找核心模型的快捷方式：
# Python：找继承自Base或db.Model的类grep -r "class.*Base\|class.*db.Model" --include="*.py" . | head -10# JavaScript：找mongoose schema或class定义grep -r "new Schema\|class.*{" --include="*.js" . | head -10
把3-5个核心模型文件贴给AI：
「这些是项目的核心数据模型。它们之间是什么关系？哪些是关键业务概念？」
AI会帮你理清：用户有多个订单，订单有多个商品，会话关联用户和设备——这种关系图通常藏在几十行import和foreign key定义里，肉眼很难快速提取。
15分钟。你掌握了业务领域的核心概念和它们的关系。
第五步：用AI生成「如果改这里会坏什么」清单
最后一步：验证理解，发现隐藏依赖。
挑一个你即将要改的文件（或者随便挑个中等复杂度的模块），把代码和文件路径贴给AI：
「如果我要修改这个函数，可能会破坏哪些地方？列出直接依赖和潜在的副作用。」
好的AI助手会指出：这个函数被X、Y、Z三个地方调用；它修改了全局状态A；异步任务B依赖它的返回值格式；测试文件C有个mock需要同步更新。
这就是代码库里最值钱的信息——隐性契约。README不会写，注释经常过期，只有AI能帮你快速扫描调用链和风险面。
20-25分钟。你不仅理解了代码，还知道了改动的爆炸半径。
最后5分钟：建立你的索引
把刚才的发现整理成个人速查表。不需要正式文档，几张便签就够：
- 入口文件：src/main.py → 找路由去src/api/- 数据库模型：src/models/，User和Order是核心- 改业务逻辑先检查src/services/，别直接动模型- 后台任务用Celery，配置在worker.py
下次遇到「这个bug在哪修」的问题，你知道从哪下手。
30分钟整。你没有读完20万行代码——那不可能也不必要。但你建立了足够的心智模型，能定位问题、评估改动、继续深挖。
这套方法的核心假设是：AI擅长快速建立框架，但不替代你读关键代码。它帮你跳过机械性的目录遍历和grep，把时间花在真正需要人类判断的地方——理解业务逻辑、评估设计决策、发现代码异味。
有个细节值得玩味：原文作者强调配置文件是「最诚实的文档」，因为「不是某人想写什么，而是项目实际在用什么」。这个观察本身比任何工具技巧都值钱——它指向一个常被忽视的真相：代码库的真相藏在可执行文件里，不在注释里，也不在Wiki上。
你现在接手一个新项目，会先tree一下，还是直接点开src文件夹开始翻？
热门跟贴