Cursor Max Mode 的直接效果是：给当前任务放开更大的上下文窗口和更完整的推理过程，让 Agent 在大仓库里少「看不见文件」。代价是用量消耗明显加快，延迟也会上去。它是开关，不是更高一级的订阅名称；没有这个开关时，你仍可以在普通模式下写代码。
什么时候值得打开
适合打开的场景包括：跨多个包的重构、阅读陌生模块并画出调用链、一次性修复需要同时看测试与实现的顽固 bug。这些任务在普通截断上下文里会表现成「改了 A 忘了 B」。短问答、改一个函数、补一行类型，打开 Max Mode 几乎只是在烧额度。
Max Mode 不能弥补错误的工作区范围。你把整个公司 monorepo 丢进去再打开它，得到的是更贵的迷失。仍然要先用文件夹引用缩小范围，再决定是否加这个开关。
使用步骤与观察指标
- 在 Chat 或 Composer 的模型/模式菜单里找到 Max Mode 开关，只对当前这条任务打开。
- 打开后先看它列出的文件是否变全了。如果文件列表依旧离谱，问题在引用，不在模式。
- 观察 Usage 曲线。一次 Max 任务相当于若干次普通问答时，就该改回普通模式做收尾。
- 任务结束后立刻关掉，避免下一条「改文案」的短需求继承这个开关。
- 团队若有预算墙，把 Max Mode 写进内部约定：仅复盘和架构讨论可用。
需要接受的副作用
更大窗口不等于更准确。模型仍会幻觉不存在的函数，只是它现在能「头头是道地」引用更多文件。你必须继续看 diff。延迟增加时，不要并行开两个 Max 会话抢同一工作区，合并冲突会很难收拾。若官方调整了 Max 的计费倍率，以产品内说明为准。
把 Max Mode 当成专项工具而不是默认档
可以在团队里把它类比成「深检模式」：平时关掉，只有在调用链跨很多包、普通模式连续漏改时才打开，用完即关。若每个人的默认会话都是 Max，Usage 会在月初被少数几次仓库漫游吃掉，月底真正的疑难反而没预算。专项工具的管理比开关本身更重要。你也可以在规则里提醒：打开 Max 前必须先给出目录范围，否则这次请求直接视为浪费。
Max Mode 打开时尽量避免同时开超长的历史线程。旧线程里堆着过期 diff 和过期报错，更大的窗口会把这些噪声一并送进去，效果可能更差。正确做法是新开会话、引用当前目录、用几句说清目标，再打开 Max。窗口是用来装当前事实的，不是用来装聊天记录的。若延迟已经高到你开始切窗口做别的事，说明这次任务不该开 Max，或范围仍然太大。
常见问题
Max Mode 会永久改变我的套餐吗？
不会。它是请求级或会话级选项，关了就回到普通上下文策略。
免费档有 Max Mode 吗？
以你账号里实际能看到的开关为准。即便能打开，消耗策略也可能更严，不适合拿来当日常默认。
开了 Max 仍然漏文件？
检查忽略规则和工作区根目录。Max 放大的是窗口，不是无视 .cursorignore。把关键目录显式引用进去。
