现在Cursor的编码能力和分析整个项目代码的能力已经非常强了，但是如何用它来开发大型项目，还是没有那么直观，还是需要用到一些技巧。
我有一个极其复杂的项目需要做，我向用cursor来实现。我可能会用cursor的plan模式，先做计划，然后去实施。但是cursor的对话session有长度限制，可能生成了很多代码之后，它的上下文窗口就满了，需要重新开启一个对话。像这种特别复杂的项目用cursor开发，应该如何处理呢？
以下是处理复杂项目在 Cursor 中上下文窗口受限的核心策略：
1. 项目文档化是关键
在项目根目录维护一组"活文档"，让每个新 session 都能快速恢复上下文：
PROJECT_OVERVIEW.md--- 项目整体架构、技术栈、核心设计决策PROGRESS.md--- 当前进度，已完成/进行中/待做的模块CONVENTIONS.md--- 代码风格、命名规范、文件结构约定ARCHITECTURE.md--- 模块间的依赖关系、数据流、API 接口定义
每次 session 结束前，让 Cursor 帮你更新这些文档。新 session 开始时，先让它读这些文件。
2. 模块化拆分任务
不要试图在一个 session 里完成所有事情。把项目拆成独立的、边界清晰的任务单元：
- 每个 session 只聚焦一个模块或一个功能
- 模块之间通过明确的接口（类型定义、API contract）解耦
- 先把接口定义好，再分别实现各模块
3. 善用 .cursorrules 文件
在项目根目录放一个 .cursorrules（或 .cursor/rules），把关键约定写进去。这个文件每次 session 都会自动被 Cursor 读取，不占你手动提示的窗口。
4. Session 切换的标准流程
结束旧 session 时：
"请总结一下这次 session 我们做了什么、当前状态、下一步该做什么，更新 PROGRESS.md"
开启新 session 时：
"请先阅读 PROJECT_OVERVIEW.md、PROGRESS.md 和 CONVENTIONS.md，然后我们继续做 [具体任务]"
5. 用 Plan 模式的建议
Plan 模式很适合在 session 开头用来规划，但要注意：
- 让 Plan 的输出落地成文件（比如
PLAN_auth_module.md），而不是只存在对话里 - 大计划拆成阶段性小计划，每个小计划对应一个 session 的工作量
- 实施阶段切到 Act 模式，避免浪费上下文在重复的计划讨论上
6. 其他技巧
- 类型定义先行：先让 Cursor 生成所有 interface/type 定义，这是跨 session 最稳定的"契约"
- 测试驱动：写好测试用例后，即使换 session，新的 Cursor 也能通过测试来验证实现是否正确
- Git 分支：每个功能模块一个分支，session 之间通过 commit message 传递上下文
本质上就是一个原则：把上下文从"对话"转移到"文件"中。对话会丢失，文件不会。
那具体来说，如何写提示词来实现这些呢？
下面是一套实用的提示词模板，覆盖从规划到执行的完整流程。
阶段一：项目初始化（第一个 Session）
提示词 1：生成总体计划
我要开发一个 [项目描述]。技术栈是 [xxx]。
请你作为高级架构师，帮我做以下事情：
1. 分析这个项目的所有功能模块，列出模块间的依赖关系
2. 将项目拆分成多个开发阶段（Phase），每个 Phase 包含 2-3 个可以在一个开发 session 内完成的任务
3. 为每个 Phase 定义清晰的输入和输出（即：开始这个 Phase 前需要什么已经就绪，完成后会交付什么）
4. 确定各模块之间的接口契约（类型定义、API 接口）
请将完整计划输出到 `docs/PROJECT_PLAN.md` 文件中。
格式要求：
- 每个 Phase 有编号、标题、预估工作量、前置依赖
- 每个任务有明确的验收标准（怎样算"完成"）
- 在文件末尾列出所有跨模块的接口定义提示词 2：生成项目基础文档
基于刚才的计划，请生成以下项目文档：
1. `docs/ARCHITECTURE.md` - 项目架构图（用文字描述模块关系和数据流）
2. `docs/CONVENTIONS.md` - 代码规范和项目约定
3. `docs/PROGRESS.md` - 进度跟踪文件，把所有 Phase 和任务列出来，状态标为 [ ] 未开始
4. `.cursorrules` - 把关键的代码规范和架构约定写进去
同时请生成所有模块间的接口类型定义文件（比如 `src/types/` 目录下），这些类型定义是后续所有开发的契约基础。阶段二：每个 Session 开头（恢复上下文）
提示词 3：Session 启动
请先阅读以下文件，恢复项目上下文：
- docs/PROJECT_PLAN.md
- docs/PROGRESS.md
- docs/ARCHITECTURE.md
- docs/CONVENTIONS.md
阅读完毕后，告诉我：
1. 当前项目整体进度
2. 下一个要做的 Phase/任务是什么
3. 这个任务的前置依赖是否都已就绪
然后我们开始做 Phase [X] 的 [具体任务名]。阶段三：单个任务的 Plan → Act
提示词 4：为当前任务做详细计划
现在我们要实现 Phase [X]: [任务名称]。
请先用 Plan 模式为这个任务做详细的实施计划：
1. 列出需要创建/修改的所有文件
2. 按实施顺序排列步骤
3. 标注每个步骤的关键逻辑和需要注意的边界情况
4. 确认与其他模块的接口对接点
请把这个详细计划写入 `docs/plans/PLAN_phase[X]_[任务名].md`
写好计划后先停下来，我确认无误后再开始实施。提示词 5：确认后开始执行
计划确认，请切换到实施模式，按照 `docs/plans/PLAN_phase[X]_[任务名].md` 中的步骤逐步实现。
要求：
- 严格按计划顺序执行，每完成一个步骤简要说明
- 遇到计划中没有预料到的问题，先说明问题再继续
- 实现过程中遵守 .cursorrules 和 CONVENTIONS.md 中的规范
- 每个文件写完后确保能与已有的类型定义对齐阶段四：Session 结束
提示词 6：收尾总结
这个 session 即将结束，请帮我做收尾工作：
1. 更新 `docs/PROGRESS.md`：
- 把已完成的任务标记为 [x]
- 记录当前正在进行但未完成的任务及其进度（完成了哪些步骤，还差什么）
2. 如果本次有任何架构变更或新增约定，更新对应文档
3. 写一段"交接备注"附加到 PROGRESS.md 末尾，包含：
- 本次 session 做了什么
- 遇到了什么问题/做了什么妥协
- 下个 session 应该从哪里开始
- 有什么需要特别注意的坑补充：.cursorrules 参考模板
# Project Rules
## Architecture
- 本项目采用 [架构模式]，所有模块通过 src/types/ 下的接口定义通信
- 新增模块前必须先在 types 中定义接口
## Code Style
- [你的代码风格规范]
## Workflow
- 每个开发任务有对应的计划文件在 docs/plans/ 目录
- 实施前必须先读取对应的 plan 文件
- 任务完成后必须更新 docs/PROGRESS.md
## Key Decisions
- [记录重要的技术决策，比如为什么选了某个库、某个设计模式]核心思路就是：Plan 产出文件，Act 消费文件，Session 之间靠文件传递一切上下文。每个环节都有对应的文档承接，Cursor 不需要"记住"任何东西，只需要"阅读"就能恢复状态。