浏览 AI使用教程
大仓库上下文放不下，怎样按模块读取又不丢目标
大仓库不适合一次塞进上下文。先固定问题，再按入口、依赖和数据流分批阅读，并把跨模块结论写进同一张地图，才能避免读到后面忘了前提。
仓库太大放不下时，关键不是多读，而是不丢目标
把整个 monorepo 一次交给 Agent 后，它在回答第四个问题时忘了最初目标，还把旧模块的 `User` 类型当成新接口使用。上下文多并不等于理解完整。
- 模块地图与固定问题始终可见
- 跨批术语和决定有统一账本
- 每个结论能回到文件和行或运行日志
AI 读大型代码库，先从“每批总结都像新的仓库介绍”这一类现象查起
每批总结都像新的仓库介绍
- 原因
- 没有固定问题和跨批状态，模型每次重新理解项目。
- 怎么改
- 建立状态文件，保存入口、已证实关系、未知项、关键路径和下一批要回答的问题。
找到了很多文件却不能定位修改点
- 原因
- 按目录浏览而非沿调用和数据流追踪。
- 怎么改
- 从唯一文案、路由、接口、表名或报错开始，只读能回答当前跳转的文件。
跨批结论互相冲突
- 原因
- 版本、分支、生成物或术语没有记录。
- 怎么改
- 每批写提交、文件路径和证据片段；冲突时回到当前文件复核，不选更像真的一条。
重要配置最后才发现
- 原因
- 只读源码，没有检查规则、构建、CI、环境和生成器。
- 怎么改
- 第一批固定扫描项目规则、清单和验证入口，再进入业务模块。
复测前，固定原始现象、环境和目标
| 需要确认 | 本例内容 |
|---|---|
| 现有材料 | 仓库 18 万行，包含 web、api、worker 与 shared；当前只排查结算失败，入口请求和错误日志已知。 |
| 不能越过的边界 | 先建模块地图，再围绕固定问题分批读取；每批保存结论、证据位置、未知项和下一批问题。 |
| 要交付的结果 | 模块地图、固定问题和跨批结论 |
同一个结算问题贯穿四批
| 批次 | 本批材料 | 可记录结论 | 下一步 |
|---|---|---|---|
| 入口 | apps/web/checkout.ts：POST /checkout | 页面传 orderId，不直接付款 | 追 api/routes/checkout.ts |
| 订单 | api/order-service.ts：Order.status | 只允许 pending 订单进入支付 | 追 payments/adapter.ts |
| 适配器 | payments/adapter.ts：providerRequestId | 关联日志仍需核对支付服务记录 | 追 worker/retry.ts 的重试条件 |
| worker | worker/retry.ts：status=pending/payment_failed | 不能仅凭同名 User 类型推断账号来源 | 比较 shared/customer.ts 与 apps/admin/user.ts 的导入关系 |
这些路径是教学设定。实际记录需补当前提交/时间、行或符号；找不到文件就记未确认，不能把设定填进真实调查结果。
跨批保留的最短状态文件
context.md
由下一会话主动读取
问题：结算失败发生在哪一层？ 范围：web入口→订单→支付适配器→重试worker。 版本：填写实际commit或工作区时间；保留dirty状态。 已确认：只填写读过的路径、符号与短证据。 术语：Order.status必须来自当前调用链导入；admin/User暂不纳入。 未知：支付服务是否收到providerRequestId，待查看脱敏请求记录。 下一批：只验证该未知项；若版本变化先复核已读文件。
AI 读大型代码库：按原条件复测的结果
原始现象
一次读取大量目录后，回答混用两个 User 类型，无法说明结论来自哪个文件。
模块地图、固定问题和跨批结论
预期分成结算入口、订单服务、支付适配器和重试 worker 四批；账本固定订单编号与状态定义。下表只示范路径与待证问题，不能据此声称已读完18万行或确认11个真实文件。