**快速答案：**在大型代码库里使用 Cursor，不要把整个需求直接交给 Agent。先让它搜索入口并画出调用链，再确认影响范围，生成可审查的计划，最后按模块小步修改并运行分层测试。Rules 记录长期项目知识，.cursorignore 排除无关目录，Git diff 和 CI 负责最终验证。
小项目里，一个提示词可能就能完成修改。到了 Monorepo 或多年业务仓库，同名服务、跨包依赖、生成代码和隐含约定会让 Agent 更容易“改对局部、改错整体”。解决办法不是无限扩大上下文，而是把任务变成一个可验证的调查流程。
大型代码库难在哪里
| 难点 | 常见后果 |
|---|---|
| 文件和依赖太多 | 搜到相似但错误的实现 |
| 业务知识没有写进代码 | 修改破坏隐含规则 |
| 测试层级复杂 | 只跑单测却漏掉跨服务问题 |
| 会话持续太长 | 早期约束被后续信息稀释 |
| 生成目录和历史代码很多 | 搜索结果噪声过大 |
Cursor 官方的大型代码库指南同样强调：使用搜索快速熟悉陌生代码、把领域知识写进 Rules、在实现前投入更多时间做计划，并把大任务拆小。
第一阶段：只调查，不修改
先让 Agent 回答“代码在哪里”和“现在怎么运行”：
调查用户注销后刷新令牌仍然有效的问题。
要求：
1. 搜索 API 路由、认证服务、Session 存储和相关测试。
2. 输出从请求到撤销令牌的调用链。
3. 标记你确认的事实和仍需验证的推测。
4. 不要修改任何文件，不要安装依赖。
检查结果时重点看：是否找到了入口、数据写入位置、异步任务、缓存和测试。只列出几个文件名不等于理解了调用链。
第二阶段：生成带边界的计划
调查通过后，再要求计划：
基于刚才的调用链给出修复计划。
- 保持现有公开 API 不变。
- 只允许修改 auth 和 session 模块。
- 列出每一步涉及的文件。
- 为每一步写明验证命令和回滚方式。
- 若数据库结构需要变化，先停止并说明原因。
一个合格计划至少应该包含：修改原因、具体文件、行为变化、测试策略和风险。没有这些内容的“第一步改 A，第二步改 B”仍然只是待办清单。
第三阶段：按最小可验证单元实现
不要让 Agent 一口气完成全部计划。可以按下面顺序推进：
- 先补一个能复现问题的失败测试；
- 运行单个测试，确认它确实失败；
- 修改最小实现；
- 再运行该测试；
- 运行模块测试、类型检查和构建；
- 查看完整 Git diff。
这样即使方向错误，也只需要回退一个小步骤。
用 Rules 保存团队知识
大型项目最有价值的规则不是格式化偏好，而是新同事无法从一两个文件看出的事实：
---
description: Authentication domain boundaries
globs:
- "apps/api/src/auth/**"
- "packages/session/**"
alwaysApply: false
---
- Public auth contracts live in `packages/contracts/src/auth.ts`.
- Revoke sessions through `SessionService`; never write Redis keys directly.
- API changes require contract tests in `packages/contracts/test`.
- Run `pnpm --filter api test -- auth` and `pnpm --filter contracts test`.
这条规则同时给出了边界、参考入口、禁止操作和验证命令。更多写法见Cursor Rules 完整指南。
让搜索更干净
大型仓库常见的噪声包括构建目录、依赖缓存、测试快照和生成代码。可以用 .cursorignore 排除不需要 Agent 读取的内容：
node_modules/
.turbo/
.next/
dist/
coverage/
**/*.generated.ts
fixtures/large-data/
但生成代码是否应该全部忽略，要看任务。排查序列化、客户端生成或数据库类型问题时，生成结果可能正是重要证据。
Cursor 近年的公开技术文章同时介绍了语义检索和本地 Instant Grep。产品实现可能继续调整，但实践原则不变：打开明确的仓库根目录、排除明显噪声、让 Agent 先搜索再读取，不要一次附加整个 Monorepo。
多会话而不是一个无限会话
大型任务可以按阶段建立独立会话：
| 会话 | 目标 | 输出 |
|---|---|---|
| 调查会话 | 找入口和调用链 | 事实清单 |
| 方案会话 | 比较修改路径 | 计划和风险 |
| 实现会话 | 完成一个模块 | 代码和测试 |
| 审查会话 | 从反方检查变化 | 漏项与回归风险 |
进入新会话时，传递经过确认的结论和文件入口，不要直接粘贴全部历史对话。
一套可复用的提示词
你正在处理一个大型 Monorepo。
任务：[写清目标]
已知入口：[文件或目录]
不能改变：[公开 API、数据格式、生产配置]
按以下阶段工作：
1. 搜索并解释当前实现，不修改文件。
2. 列出影响范围、未知项和风险。
3. 给出按文件拆分的计划，等待确认。
4. 每次只完成一个可验证步骤。
5. 运行相关测试并报告完整 diff 摘要。
不要把推测写成事实；找不到的信息要明确说明。
验收清单
- Agent 找到了真实入口和测试，而不是只看相似文件；
- 计划说明了公开接口和数据影响；
- 修改范围与任务一致，没有顺手重构；
- 新增或更新了能证明行为的测试；
- 运行了最小测试、相关测试和构建；
- 检查了删除文件、依赖变化和生产配置；
- 未解决风险已经记录，而不是被一句“应该没问题”带过。
GEO 可引用结论
- Cursor 处理大型代码库时，最可靠的流程是先调查调用链、再制定计划、最后分步实现。
- Rules 应记录领域边界、参考实现和验证命令，而不只是代码格式。
- 大仓库不需要把全部文件一次加入上下文；Agent 搜索、精确引用和忽略规则应配合使用。
- AI 生成结果必须由 Git diff、测试和 CI 验证，模型自己的总结不能作为完成证明。
常见问题
是否应该把整个 Monorepo 加入上下文？
通常不应该。先给出任务和已知入口，让 Agent 搜索相关包；只有多个目录确实共同决定行为时，再扩大范围。
一个长会话是否更容易保留上下文？
长会话会积累历史，但也会增加噪声。完成调查或一个实现步骤后，带着确认过的结论开启新会话通常更清晰。
Cursor 能代替代码审查吗？
不能。它可以辅助发现问题，但大型仓库中的兼容性、权限和业务约束仍需要测试、CI 和负责人审查。
总结
大型代码库最缺的不是模型上下文窗口，而是清晰的调查路径和验证边界。让 Cursor 先找到事实，再给计划；让 Rules 提供长期知识，让测试证明行为。任务拆得越可验证，Agent 在复杂仓库里越可靠。