很多朋友问我，为什么同样是AI编程助手，别人用起来一天能写完一个功能，自己用起来就像跟一个刚入职的实习生对话——问东答西、越改越乱、动不动就把代码改得面目全非。我观察了一阵子，发现绝大多数问题不在模型本身，而在一个很多人根本不在意的开关上：context-mode。
context-mode，字面意思就是“上下文模式”。往浅了说，它是AI编程工具里Ask、Edit、Agent这三种工作模式的统称；往深了说，它决定了你以什么方式、多大范围，把“上下文”交给模型。你给AI看到的东西不对，再强的模型也白搭。这篇文章我就结合自己用Cursor这类AI编程工具做了大半年项目的经验，把context-mode拆开讲透：三种模式到底怎么选、怎么用，怎么给AI喂上下文让它真正听懂你的项目，还有那些踩过的坑，一次说完。不管你是刚开始接触AI编程的开发者，还是已经在用的技术负责人，这篇内容都值得花十分钟看完。
1. 上下文模式到底是个什么东西：先搞懂AI的“临时工作台”
1.1 你喂给AI的信息，就是它的整个世界
很多人误以为AI编程助手“记住”了你的项目，其实完全不是这么回事。大语言模型本身没有任何记忆，每一次对话都是临场发挥。它能看到什么、能依据什么来回答，完全取决于你在当前这次会话里给它“看”了哪些内容。这个临时可见的信息集合，就是上下文。
我之前打过一个比方：AI就像一个刚进组的实习生，他没有过去一个月的工作记忆。你给他看需求文档，他就能照着需求干活；你只把他领到工位上，说“你随便干点什么吧”，他大概率会把事情搞砸。context-mode管的就是这个“你给他看什么、让他接触多大范围”的机制。
具体到一次对话里，上下文包括这么几块：你的提问、和AI一来一回的历史消息、你通过@符号手动引用的文件内容、AI通过代码库索引检索到的相关代码片段、系统指令和项目规则。所有这些东西加起来，构成了AI当前时刻的“认知边界”。超出这个边界的信息，AI不会凭空知道，它只会一本正经地胡编。
这也是为什么同样一个AI模型，有人觉得它“懂我”，有人觉得它“弱智”。差别根本不在模型，而在你如何管理和投喂上下文。模型是发动机，上下文是油箱和轮胎，你往油箱里灌水，发动机再猛也跑不动。
1.2 Ask、Edit、Agent：三种模式就是三档授权
现在主流的AI编程工具，普遍把context-mode做成了三档，只是各家叫法略有不同。我用Cursor举例，因为它把这个概念表达得最清晰，其他工具大同小异，思路完全可以平移。
第一档叫Ask模式。这个模式下，AI是一个纯粹的顾问。你可以向它提问、让它解释代码逻辑、讨论方案、做代码评审，但它不会直接动手修改任何文件。它只负责“动嘴”，不负责“动手”。
第二档叫Edit模式。这个模式下，AI会直接修改你选中的代码区域。你可以圈住一个函数、一段逻辑，告诉它“把这里改成XX”，它会生成修改后的代码并替换到你的文件里。但它默认只动你圈定的那部分，不会主动去翻别的文件。
第三档叫Agent模式。这是目前最激进的一档，也是翻车率最高的一档。在Agent模式下，AI获得了“全权代理”的授权：它可以自己读取项目里的多个文件、全局搜索代码、修改任意文件、执行命令、跑测试，甚至连续做一串任务。你给它一个目标，它自己决定路径。
我用一个表格把这三种模式横向对比，看得更清楚：
| 模式 | AI能做什么 | AI不能做什么 | 典型场景 | 风险等级 |
|---|---|---|---|---|
| Ask | 回答问题、解释代码、给方案 | 修改文件 | 理解业务、方案讨论、代码评审 | 极低 |
| Edit | 修改你选中的代码片段 | 改动范围外的代码 | 改函数、修Bug、补注释 | 中低 |
| Agent | 读文件、搜代码、改文件、跑命令 | 无明确边界，全靠你给约束 | 跨文件重构、新功能开发 | 高 |
模式切换本身很简单。在Cursor的对话输入框附近，一般会有一个模式下拉或切换按钮，点击就能在Ask、Edit、Agent之间切换。平时养成一个习惯：动手之前先看一眼当前在哪个模式，至少能帮你避免一半的“AI乱改代码”问题。
1.3 为什么模式选错，效果直接打骨折
我见过太多人把Ask、Edit、Agent当成“心情好就切一下”的东西，结果就是各种拧巴。给你讲两个我实际遇到过的典型场景。
第一个场景：某同事想理解一个老项目的支付流程，他在Agent模式下问了一句“这个项目的支付流程是怎么设计的”。结果AI不仅花了几分钟翻遍整个代码库，还自作主张把两个看起来“不相关”的文件给“优化”了一版，改完还告诉他“顺手帮你重构了一下”。他当场血压就上来了。这就是典型的模式选错——你只是想让AI给你讲讲业务，却给了它改文件的权限。就好比你问同事“这个报表怎么做的”，他没回答，反而把你的报表给打印碎了一张。
第二个场景反过来：一个朋友想改一个工具函数里的边界判断逻辑，他用的是Ask模式，问了一堆“这样做行不行”“那样呢”，AI给了很详细的建议，但他还得自己回到代码里手动改。改完之后又跑回来问“这样改对不对”，AI说“对的”。一来一回折腾二十分钟，其实用Edit模式圈住函数，一句话就改完了。
这两个场景说明一个道理：context-mode的核心不是“哪个模式更强”，而是“哪个模式最匹配你当前的任务”。选Ask是为了安全和理解，选Edit是为了精准修改，选Agent是为了跨文件干活。模式选错了，要么AI瞎干活，要么你白费口舌，效率直接腰斩。
2. 模式选择的实操指南：什么场景开什么模式
2.1 Ask模式：先当个顾问问清楚，别急着动手
Ask模式的使用场景非常明确：你还没想清楚要改什么，或者你只是想从AI那里获取信息。这个模式下，AI不会动你的代码，你可以放心大胆地“问东问西”。
我最常这么用：看到一个文件读不懂，直接@这个文件到对话里，然后问“这个函数在做什么，依赖哪些外部状态”。又或者，在做技术方案之前先抛个话题，“我想给这个模块加缓存，有什么思路”，让AI基于当前代码给出几个方向。这个时候Ask模式就是最优解，因为它不会真的改你的代码，你可以尽情探索、试错。
这里分享一个小技巧：在Ask模式下提问，千万别只甩一句“帮我看看这段代码”。我看到很多人直接把一个文件路径丢进去，然后问“这个怎么写”，结果AI回答得模棱两可。正确姿势是主动@这个文件进来，明确说明你想了解的细节。比如：
@src/services/orderService.js 这个文件里的 placeOrder 方法，事务是怎么控制的？ 如果中间抛了异常，有没有回滚风险？带上@引用之后，AI读到的就是真实文件内容，而不是它凭文件名猜出来的“脑内版本”。这个习惯会直接影响你问到的内容质量。
Ask模式还有一个隐藏用法：让AI帮你做代码走查。选一个文件@进来，让它列出一等一的风险点、潜在Bug、可优化项。因为这个模式不会改代码，AI的输出会更“放得开”，不会畏手畏脚。
2.2 Edit模式：圈定范围，精准修改
Edit模式是我日常用得最多的一档，尤其是修Bug、写小功能的时候。它的核心价值在于：你划定了一个明确的修改范围，AI的改动被限制在这个圈里，不容易殃及池鱼。
用法上有一个关键动作：一定要先选中你要改的代码区域，再切到Edit模式说明你的需求。比如你圈住一个函数，然后说“把这个函数的超时时间从原来的5秒改成可配置参数，默认还是5秒”。AI会基于你选中的这段代码做修改，替换生成的内容。你没有选中的部分，它默认不会动。
不过，Edit模式也不是绝对安全。我踩过一个坑：我选中了一个函数说“优化一下异常处理逻辑”，AI把函数体重写了一遍，逻辑没问题，但把我手写的日志输出格式给改了，和项目其他模块的日志风格对不上。所以在Edit模式下的提示词里，一定要把“不要改动范围外的代码”“不要改变现有风格”这类约束写进去。哪怕AI不能百分之百完全听话，有约束比没约束强十倍。
再补一个实战细节：用Edit模式改完代码之后，记得随手扫一眼改动结果，看diff比看全部代码重要。绝大多数时候改动是你想要的，但偶尔AI会自作聪明改掉变量名、调整格式之类无关痛痒的东西。这些细小的噪声不影响运行，却会污染你的代码审查记录。
2.3 Agent模式：全权代理，但必须画好边界
Agent模式是效率神器，也是最容易翻车的模式。它适合那种“明确知道要做什么、但任务横跨多个文件”的场景。比如重构一个模块、新增一个完整的功能、协调多个文件之间的调用关系。
用Agent模式之前，一定要先做一件事：想清楚边界。AI是代理，不是你肚子里的蛔虫，你不说清楚“哪些不能碰”，它就会默认“什么都能碰”。我一般会在指令里包含三块东西：目标、范围约束、验收标准。
举个例子，我之前让Agent去给一个订单模块添加“订单备注”支持，指令是这样的：
给订单模块添加备注字段支持，具体需求： 1. 订单表新增 remark 字段，允许为空，长度不超过500字 2. 创建订单的接口支持传入备注 3. 订单详情接口返回备注字段 4. 只改 order 相关的 service、controller、mapper 和数据库脚本 5. 不要动支付相关的任何代码 6. 改完后，列出所有改动的文件清单这个指令里的4、5两条就是边界约束，6是验收标准。没有这些，AI就会真的按它自己的想法横冲直撞。我见过最夸张的一次，Agent模式写一个小功能，半小时后我发现它改了十几个文件，包括README、配置文件、测试代码，全是在它的“自由意志”下完成的。
还有一个操作习惯：开Agent模式跑任务之前，确保代码库是干净的（没有未提交的改动），或者你至少记一下当前的改动基线。这样无论AI怎么折腾，你都能随时用Git撤回到出发位置。这个保险下来，很多事故都能化险为夷。
2.4 组合拳实战：一个订单接口改造从需求到落地
说了这么多，用一个小案例把三种模式串起来走一遍。假设我们的项目里有一个订单列表接口，目前返回XML格式，需求是改成JSON，同时增加一个排序参数。
第一步，用Ask模式摸清现状。我@了controller和service文件，问AI“现在订单列表接口在哪个方法处理，返回格式是怎么控制的，有没有现成的JSON序列化工具类”。AI很快告诉我：接口在OrderController.listOrders里，返回类型是XML实体的Bean，项目里已经有Jackson依赖，可以直接用。这一步我没有让AI改任何东西，纯粹是了解情况。
第二步，用Edit模式做单点修改。我选中OrderController里listOrders方法对应的返回类型声明，切到Edit模式，说“把这里改成返回JSON格式的OrderVO，构造函数里已有的字段保持对齐”。AI替换了返回类型和注解，改动被牢牢限制在这个方法里。我看了看diff，没问题。
第三步，新增排序参数。这个需求涉及Controller方法的入参、Service里的查询条件拼接、Mapper里的SQL加order by，横跨三个文件。我切到Agent模式，给出边界约束：“只改动订单查询链路相关文件，把sortBy和order两个参数传递下去，数据库查询按字段排序，白名单允许的字段有createTime和amount，其他字段一律忽略”。AI自己跨文件完成了修改，并在最后列出了所有涉及的改动文件。
第四步，我通过Git diff把Agent的改动整体审查了一遍，发现它把Mapper的XML文件也改对了，还贴心补充了参数注释。整个过程大概20分钟，如果纯手工这三处联动改动，至少得一个小时起步。
这个案例想表达的是：三种模式不是割裂的，它们是同一件事的不同阶段。先用Ask搞清楚状况，再用Edit做小范围改动，最后用Agent处理跨文件联动。谁把顺序搞反了，谁就要吃苦头。
3. 上下文喂养手册：如何让AI始终处于“正确模式”
3.1 手动投喂：@引用让AI精确读取文件
如果说模式是“AI的工作授权”，那@引用就是“AI的信息来源”。所有AI编程工具里，@都是最基础也最好用的上下文投喂方式。你可以在输入框里@一个文件名，让AI读取该文件的完整内容；@一个文件夹，让AI读取整个目录下的文件清单和核心文件；@Codebase（或类似功能），让AI基于代码库索引检索与你的问题最相关的代码片段。
我见过有人用AI编程助手，从不主动@文件，就干巴巴地问“我这个项目有没有限流逻辑”。AI没有上下文，只能凭对开源项目的惯性理解来回答，十有八九是错的。如果你的问题是基于特定项目、特定文件、特定业务的，那就必须@对应的内容。这就像你去问一个同事问题，至少得把相关文档递到人家手里，不能指望他脑子内置了你项目的所有细节。
有一个常见的误区是：以为@了文件就能100%保证AI读取了全部内容。实际上，大模型的上下文窗口是有限的，一个巨型文件（比如一大坨几千行的老代码）可能被AI“截断”或“略读”。遇到这种大文件，我都会先手动把文件里最可疑的段落复制出来，直接贴在对话里，确保它“看到”了关键部分。别嫌麻烦，这比让AI猜要靠谱得多。
3.2 算一笔Token账：你的上下文窗口到底能装多少代码
聊上下文，绕不开Token预算。Token是模型处理文本的基本单位，一行英文代码大约消耗5到10个Token，一句中文对话大约消耗10到20个Token。不同的模型有不同的上下文窗口，比如Claude系列的窗口比较大，可以达到200K Token级别，一些默认模型可能是128K甚至更低，具体数值看你的工具订阅情况。
200K Token听起来很大，但别高兴太早。我来帮你算笔账：200K Token大约相当于15万英文单词、或者20多万英文字符，如果换成代码，大概是3到5万行。听着很充裕对吧？但实际使用中，系统指令、项目规则、你的提问、AI的回答、工具调用返回结果，全都要占用这个窗口。尤其Agent模式跑起来，AI自己搜索代码片段、阅读文件，一轮对话可能消耗几万Token。真实留给“有效代码”的空间，往往不到窗口的一半。
所以我的操作准则是：
- 一个完整的功能讨论尽量在一轮对话内解决，不要拖到几百轮。
- 一旦感觉AI开始“忘事”——比如你前面说了“排序字段只要createTime和amount”，后面它又问你“排序字段用哪个”——立即开新对话。
- 开新对话的时候，把关键信息用一小段文字重新交代一遍，不要指望AI记得上一个对话的任何内容。
很多人的AI“失忆”，其实不是模型傻了，是你们的对话已经长到超出上下文窗口了。懂Token账，你就能主动避开这个坑。
3.3 代码库索引：为什么AI好像“认识”你的项目
不知道你有没有过这种经验：用Agent模式提问“这个项目的登录逻辑在哪里”，AI咣咣几下就找到了相关文件，仿佛对你的项目了如指掌。这背后是代码库索引在起作用。工具会扫描你的项目文件，建立一张“代码语义地图”，当你问问题的时候，它会先在索引里检索和你问题相关的代码片段，再把这些片段作为上下文喂给模型。
索引是个好东西，但它有个致命前提：必须足够新。如果你刚新增了一个文件，或者刚刚重命名了一个模块，索引还没来得及更新，AI就会变成“睁眼瞎”——明明代码就在那，它偏说找不到。很多新手第一次用Agent模式都会遇到这种情况，急得满头大汗，最后发现是索引没刷新。
解决方法很简单：
- 在设置里找到索引管理页面（不同工具位置不同），手动触发一次“Resync”或“Refresh”。
- 养成习惯：每次从Git拉取新代码、切分支、大幅改动目录结构之后，手动刷新一次索引。
另外还有一个小优化：把项目根目录里不必要的目录排除在索引之外，比如node_modules、target、dist、.git这些。索引范围越大，检索的噪声就越高，AI越容易找到一堆无关文件来干扰判断。让索引聚焦在真正的源码上，AI的检索质量会明显提升。
3.4 用规则文件给AI立规矩，让每次对话都自动进入正轨
除了手动@和代码库索引，还有一种更省力的上下文管理方式：项目级规则文件。在Cursor里是.cursorrules，在别的工具里可能有类似设定。它相当于给AI写了一份“入职培训手册”，AI在每次对话开始的时候都会先读取这份规则，从而默认了解项目的技术栈、代码风格、注意事项。
我写过一个精简版的.cursorrules，参考思路是这样的：
# 项目规则 - 本仓库是一个Java Spring Boot后端项目，不要尝试修改构建配置。 - 代码风格：使用4空格缩进，方法名用驼峰，常量用大写加下划线。 - 禁止自动格式化代码，除非用户明确要求。 - 不要改动 pom.xml 和 application.yml 中与部署相关的配置。 - 所有新增的数据库字段必须同步提供 SQL 变更脚本。 - 遇到不明确的需求时，先向用户提问，而不是自行假设。这份规则文件的效果很明显：以前AI动不动就想动我的配置文件，写了规则之后，这类误操作明显减少。尤其当你在一个多人协作项目里，规则文件能让团队里所有人都享受到一致的AI行为习惯，而不是每个人都在跟AI斗智斗勇。
需要注意的是，规则文件不是万能的。它更偏向“约束”而不是“知识注入”，你不可能靠规则文件把整个业务背景塞给AI。复杂的上下文还得靠@引用和索引来动态补充。
4. 我踩过的那些坑：典型翻车现场与排查速查
4.1 答非所问，AI净说“正确的废话”
症状：你问“这个接口的超时时间在哪里配置”，AI回复一大段关于“超时时间的一般知识”，但完全没提到你项目里的配置文件。原因大概率是上下文没喂对。
排查思路先从这几点下手：
- 你有没有@相关文件？如果没有，AI只能基于常识回答。
- 你的提问是否太模糊？“超时时间”这种词在项目里可能出现在多个地方，你应该给AI一个具体的起点，比如“@application.yml 里跟HttpClient相关的超时配置”。
- 项目索引是否更新？如果索引是旧的，AI检索不到最新的自定义配置类名。
绝大多数“AI废话”都逃不出这三条原因。
4.2 AI改错了文件，或者改得整个项目跑不起来了
症状：让AI修一个前端组件的样式，结果它顺手把接口封装文件也改了，构建直接挂掉。原因就一个：模式选择太激进，边界没划清楚。
这个坑我非常熟悉。解决思路很简单：
- 如果任务是局部的，优先用Edit模式，不要直接上Agent。
- 用Agent模式时，在指令里写明“只允许修改哪些文件”“禁止修改哪些文件”。
- 开工前确保本地Git是干净的，或者至少记录基线。改完代码后先用Git diff审查改动，再跑构建和测试。
任何时候，git diff是你在AI时代最好的朋友。别嫌看diff费时间，看一版AI的全局改动，通常几百行，认真过一遍要比事后排故障快得多。
4.3 聊着聊着AI开始“失忆”
症状：会话前期你告诉过AI的东西，后期它完全没反应，甚至反问你“这个需求你刚才没说过吗”。这就是上下文窗口被撑爆了、早期的信息被挤掉了。
解决这个事情最好的办法不是“让它记住”，而是“别让它记那么久”。我现在的习惯是：每个不超过30到50轮对话就开一个新会话，开新会话时用一小段“上下文摘要”把关键信息带过来。比如新会话的第一句话写：
我们正在改造订单模块，之前确定了几件事：接口返回格式改为JSON、新增sortBy和order参数（白名单字段是createTime和amount）、数据库脚本在upgrade/v2.sql里。接下来我们继续处理订单详情的字段映射。这几行字很轻，但对AI来说就是最重要的记忆锚点。比你在一个快爆炸的对话里反复强调“我之前说过了啊”要有效得多。
4.4 Agent说“找不到那个文件”，但代码明明就在那
症状：你明确知道某个文件存在，AI却信誓旦旦“项目里没有这个文件”。九成原因是代码库索引过期了，尤其在你新增文件、重命名目录、拉取新分支之后最常出现。
处理起来也快：
- 到索引设置里手动刷新。
- 刷新完之后重新发起问句，别在旧会话里反复追问，旧会话里AI的“错误记忆”可能会干扰它重新查找。
- 确认你要找的文件没有被.gitignore或索引排除规则挡在外面。
这个坑出现的频率不高，但出现一次就容易让人抓狂。早排查早安心。
4.5 安全红线：别把密钥和敏感信息喂给AI
这是一个非常容易被人忽略的问题。你在对话中@配置文件的时候，如果这个文件里有数据库密码、第三方API密钥、内网地址，这些内容就会成为发给模型的上下文。从技术上讲，这些内容可能会被工具服务商用于日志、审计或模型迭代。
不是说所有工具都不安全，而是你自己得留一手。我个人的习惯是：
- 敏感配置文件（application-secret.yml、.env等）不轻易@进对话。
- 如果实在需要AI分析某段包含密钥内容的代码，我会先把密钥字段打码，再粘贴进去。
- 涉及未公开业务逻辑的大段代码，也要慎重。默认不把公司核心代码整个丢给AI。
该用的时候大胆用，该防的时候也别犯糊涂。这条搞明白了，你能省掉不少未来的麻烦。
5. 进阶玩法：把上下文模式用出“团队感”
5.1 大重构之前，先做一次“上下文编排”
当你面对一次大规模重构，比如把一个单体函数拆成多个模块、把同步调用改成异步，别着急一个Agent指令扔过去。先做一个“上下文编排”的动作：梳理出这次改动涉及的顶层文件、依赖关系和顺序，然后分阶段交给AI。
我一般会把重构拆成几个子任务，每个子任务开一个新会话来跑。比如第一步只改接口层，第二步改业务层，第三步改数据层。每步之间用代码评审连接，而不是让AI一口气完成所有事。这么做能让你在每一层都保持控制力，任何一步出问题都不会拖累整个重构。
5.2 团队统一上下文模板，让AI风格一致
如果你是一个技术负责人，完全可以考虑把.cursorrules以及一套Prompt模板固化到团队仓库里。新成员接手项目、新环境搭建完成，直接引入这套模板，AI输出的代码风格就会和团队规范对齐。
模板里至少应该涵盖：技术栈申明、代码风格约束、禁止改动清单、常见需求的标准回答方式、以及“遇到不明确需求时先提问还是先动手”的偏好。一套好模板能省掉非常多管理成本。这相当于给每个人配备了一位熟悉团队规范的“虚拟同事”。
5.3 有时候，关掉AI才是最优解
说了这么多，最后说一个反向的经验：不是所有问题都该开着AI干活。
如果你已经明确知道方案，而且需要的是“稳定的、可预期的”修改，手写通常更快。比如改一个变量名、调整一个常量值、微调一段SQL，这些场景手动做十秒就完成，切模式、等生成、看diff，反而折腾。还有那种极其复杂的、牵一发动全身的敏感业务逻辑，AI介入的风险远大于收益。
学会判断“什么时候让AI进来、什么时候把它请出去”，是context-mode使用进阶的标志。AI是工具，不是目的。把工具用在该用的地方，效率才能最大化。
最后分享一个我自己的习惯：每天开工前，我会花五分钟检查当前的模式、确认关键文件已经被索引、瞄一眼规则文件是否需要更新。这个“开机检查”看着简单，但它帮我避掉了大部分低级事故。如果你想用好context-mode，建议从今天开始也试试这个习惯。
