你有没有遇到过这种场景明明用的是同一个模型、同一个工具同事的 AI 编程助手像老手一样稳准狠你的却像刚转行的实习生改一个 bug 顺手把无关代码翻个底朝天最后给出一堆似是而非的建议。我去年带团队推 AI 辅助开发一开始大家的工具都配得差不多跑了一周结果却是天壤之别。逐条对比会话输入之后我发现一个扎心的事实产出质量八成由 context-mode 决定也就是我们到底以什么方式、把哪些信息喂给了模型。模型本身的智商差距远没有我们想象的那么大。这篇文章不聊那些虚头巴脑的提示词技巧我把一整年折腾 context-mode 的经验完整梳理一遍。它适合正在用 Cursor、Copilot、Cline、Codex 这类 AI 编程助手的开发者也适合在小团队里负责推广 AI 工具的人。内容包括三种上下文模式的区别、如何用规则文件固化项目的长期记忆、上下文窗口被撑爆的诊断和补救以及一个真实项目的完整配置过程。官方文档能告诉你按钮在哪但很难告诉你什么时候该用哪种模式、为什么用错了会翻车这部分我会用自己的踩坑记录补上。1. AI 编程辅助产出质量差八成是 context-mode 的问题1.1 一个答非所问的现场团队里有个同事用 Cursor 改前端样式目标很明确让某个按钮在移动端隐藏只调整 CSS。结果 AI 不仅改了样式还顺手重构了组件的 props 接口、把一段 service 层调用也优化了最后他花了一下午做回滚。只看这个结果谁都会觉得是模型太自作主张。但把 Chat 面板打开一看就明白了上下文里没有任何本次任务边界的说明只有一个几百行的组件文件以及上一条历史对话的尾巴——那条对话恰好还在讨论接口重构。模型没有能力猜到我只想动样式这个隐含前提它只能根据喂给它的全部上下文推断你大概想继续重构这个组件。这就是 context-mode 失控最常见的样子不是 AI 突然犯傻而是你给它的视野本身就是错位的。1.2 上下文模式的本质模型输出只是上下文的投影理解 context-mode 之前先放下一个执念大模型不会因为某个版本升级就突然从笨变聪明。同一个模型在同一个温度参数下回答质量会随着输入内容发生剧烈波动。你在对话里给它的全部文本——系统提示词、规则文件、参考文件、历史对话、工具执行结果——合起来才决定了它这次输出围绕什么展开、边界在哪里。来打个比方。你让一个经验丰富的老工程师帮忙改代码如果只丢给他一个文件路径他肯定会先把整个项目结构和相关调用链翻一遍如果你明确说只准碰这个文件的样式部分其他一律不动他干活就会收敛很多。context-mode 干的就是这件事它管理的是老工程师能看到的资料范围以及他行动的权限边界。只是大多数开发者完全没意识到自己一直在用默认配置等于让老工程师裸奔着进工地。这也能解释另一个常见现象很多人觉得上下文给得越多AI 越聪明于是把所有源码、文档一股脑塞进去。实际情况恰恰相反模型对长上下文的注意力天然是分散的塞入大量无关内容它会抓住某些巧合的关联放大发挥。上下文不是堆料是筛选。1.3 三种上下文形态手动引用、自动上下文、全局检索我习惯把主流 AI 编程工具的 context-mode 归纳为三种形态手动引用。你在对话框里用 或 # 显式指定文件、文件夹、文档片段让它们成为对话的固定输入。这是最朴素的方式精确但费手。自动上下文 / Agent 自主读取。工具开启 Agent 模式后AI 自己决定要读哪些文件、跑哪些命令、看哪些输出按需取用。Cursor 的 Agent 模式、Windsurf 的 Cascade、Cline 的 Plan/Act 都类似这种。省心但 token 消耗可能失控而且一旦没有约束AI 的探索路径会很不稳定。全局语义检索。通过 Codebase / #Codebase 这样的入口触发仓库级语义索引让工具把与描述最相关的文件片段自动检索出来注入上下文。这不是把整个仓库塞进窗口而是做了一次联想检索适合大仓库里定位代码。这三者不是互斥关系我后面会详细说明什么时候混用、什么时候只用一种。先把它们的底层差异讲透你才知道自己每次点击到底发生了什么。2. 三种 context-mode 的核心差异与选型判断2.1 手动引用精确但费力单文件小改动优先手动引用看似简单里面其实藏着一个很多人不知道的细节你告诉 AI读取文件 A工具通常不是把文件截断成几行摘要而是把整个文件内容当作文本注入。一个 800 行的组件文件按常见换算大约 6000 到 8000 token。三个这样的文件就轻松吃掉了 2 万 token 的窗口。很多人的惯性是多 几个文件让 AI 看得全面些结果窗口被快速填满模型的有效注意力也被稀释。我的建议是单文件小改动、改样式、修 typo、写测试用例这一类目标清晰的小任务直接用手动引用并且只引用真正涉及的文件。如果某个文件很大先自己定位到相关函数段落把这段内容作为选中文本贴进对话而不是整个文件拖进去。这样可以大幅减少 token 浪费也能让 AI 的输出更聚焦。还有一个实用技巧当你在编辑器里选中一段代码再唤起 Chat/Copilot大多数工具会自动把这段选中内容作为上下文。所以先选中、再提问本身就是一种高效的手动引用方式比 整个文件更精准。我实测下来用选中代码替代整个文件引用单次交互 token 能省 60% 以上而且很少出现AI 被文件其他部分带偏的情况。2.2 自动上下文省心但烧 token必须有边界Agent 类功能的卖点就是你提需求它自己读代码、自己动手。听起来很美实际用起来最需要警惕。没有显式边界时Agent 可能会为了找一个小配置项读遍半个仓库token 哗哗地烧输出质量却不一定好因为读入的内容里有很多是它顺手探索到的无关信息。给 Agent 加边界目前比较成熟的实践是两条线。一条是对话层面的约束明确写清楚只允许修改 src/features/notification 目录下的文件不要改动 server 目录不要运行测试以外的命令把探索范围收窄。另一条是工具层面的配置在 Cursor 的项目规则里写明默认禁止事项或者在 Cline 的 .clinerules 里定义读文件优先级。两条线配合Agent 才会既有探索自由度又不至于跑飞。还有一点Agent 模式跑长任务时会自己维护一份已读文件列表。很多工具会在侧边栏或日志里展示它读了哪些文件。我建议每跑完一个阶段就扫一眼这个列表如果发现它读了明显不该碰的东西立刻打断并修正描述。别等到最后才发现它把 30 个文件全部读了一遍然后基于一份混乱的信息改代码。2.3 全局检索大仓库语义定位的好帮手Codebase / #Codebase 这类功能依赖工具建立的语义索引。它的工作方式是把你的问题转成向量表示去索引库里找语义上最接近的若干代码片段然后把片段拼接进上下文。它解决的是我不知道这段逻辑写在哪个文件里的问题。但全局检索有一个天然弱点检索回来的都是片段不是完整文件。这对上下文友好但也意味着 AI 只看到局部看不到全貌。比如它检索到函数calculatePrice的实现片段但没看到这个函数是在哪个模块被调用的、调用方的数据结构长什么样就容易给出局部优化但全局不兼容的方案。所以我通常把 Codebase 当作入口定位器而不是直接生成器。先用它定位到相关文件再手动打开这些文件把关键部分加入上下文做第二轮深度推理。这样既发挥了检索的效率又补足了它缺失的全局视野。2.4 场景选型速查表整理了一张表是我日常分配的参考基本可以覆盖大多数情况。场景推荐模式理由单文件小改动、改样式、修 typo手动引用 选中代码成本低、方向唯一跨 3 到 5 个文件的小功能Agent 白名单目录时区能自主探索又不会跑偏大仓库里定位某段逻辑Codebase 语义检索免手动翻找重构大模块手动引用 规则文件明确边界防止 AI 扩大修改面疑难 bug 深挖小步多次、每次新会话避免历史污染生成新代码但需参考旧实现手动引用旧文件 明确只参考不修改让模型有样板可用选型的关键不是哪个高级用哪个而是哪种方式让模型的注意力最集中在你想要的那一小块。我在团队里反复强调context-mode 选择的本质是注意力管理不是参数调优。3. 让 context-mode 长期稳定的配置文件体系3.1 规则文件是项目的长期记忆会话是短暂的项目是长期的。如果每开一个新会话都要把技术栈、目录约定、禁止事项重新说一遍既痛苦又容易遗漏。规则文件就是干这件事的。Cursor 里的 .cursorrules、新版带 glob 匹配的 .cursor/rules 目录Cline 的 .clinerules 和 .clinerules/ 多文件目录Copilot 的 .github/copilot-instructions.mdCodex CLI 的 AGENTS.md本质上都是同一个东西项目级系统提示词。这个文件的价值被多数人严重低估。我见过太多人把它当成日志本或者干脆不建。实际上一个写得好好的规则文件能让每次会话的 AI 从第一次见这个项目的实习生变成已经入职三个月的熟手。你省下的不是打字时间而是大量来回纠偏的对话轮次。3.2 规则文件该写什么、不写什么规则文件最忌讳空泛。像请写出高质量的代码这种话毫无信息量模型只会礼貌地表示认同然后继续按默认行为做事。真正有用的是那些不看项目文档就无法准确知道的硬信息。我建议按四类内容组织技术栈与版本框架、语言、包管理器、构建工具以及有没有特殊约束比如只能使用某个 npm 镜像、Node 必须是某个大版本。目录结构与分层约定哪个目录放组件、哪个目录放 API 调用、哪个目录必须保持纯净。模型对常见结构有先验认知但你的项目未必按它熟悉的套路来。强制约束与禁止事项比如客户端禁止直连数据库所有 API 请求必须带 requestId禁止修改 schema 文件如需变更先写迁移脚本这类红线。这是碾平 AI 越界行为最有效的手段。高频工作流比如改后端接口时同步更新 swagger 文档新增组件必须配 stories。这类流程约束会让产出更接近团队规范。不写什么不写与代码无关的公司背景、项目历史、团队八卦不写大段风格口号不写模型已经很清楚的语言特性和框架常识。规则文件每多一行都会占用上下文预算所以要像写代码一样对待它短、准、可执行。3.3 排除与忽略把垃圾挡在窗口外面大部分 AI 编程工具在做全局检索或 Agent 自主读取时会尊重项目的 .gitignore 配置。node_modules、dist、build 这些目录通常不会进上下文这是个好消息。但坏消息是总有一些文件你不想让 AI 碰它们又不在 .gitignore 里。比如大型的 JSON 配置文件、生成的 API 类型定义、带敏感信息的本地环境变量样例哪怕只是样例也不该喂给模型、几千行的锁文件。应对方法是三层防线。第一层是规则文件里的 glob 匹配比如在 .cursor/rules 里写!**/generated/**告诉工具这些目录不要读。第二层是对话级别的显式排除不要读取 server/migrations 目录下的文件那些是数据库自动生成的。第三层是日常习惯不把本地 .env 文件拖进任何上下文包括手动引用。这条习惯跟工具能力无关就是安全意识。3.4 一个可以直接抄的规则模板下面这个模板来自我给一个 Vue 3 Express 全栈项目配的 .cursorrules效果比较稳你可以按自己的堆栈改着用。# 项目技术栈 - 前端Vue 3 TypeScript Vite Pinia - 服务端Express Prisma PostgreSQL - 包管理器pnpm # 目录约定 - src/components 只放纯展示组件禁止写入业务逻辑 - src/features/[domain] 按业务域组织内部包含components、api、stores、types - server/routes 只做参数校验和路由转发业务逻辑一律放在 server/services - server/migrations 由 Prisma 自动生成禁止手改 # 强制约束 - 客户端禁止直接访问数据库所有数据操作必须通过 /api - 新增 API 必须同时在 docs/api.md 中补充说明 - 组件样式必须使用 scoped禁止写全局 CSS - 如果已有工具函数禁止新增重复实现优先复用 src/utils 下的函数 # 工作流 - 修改数据模型时先修改 schema.prisma生成迁移再更新对应类型 - 开发新页面时先写路由再建页面组件最后补关键交互测试注意这份模板的字数控制在合理范围内不会挤压太多上下文预算。实际使用中如果你的项目横跨多个技术栈建议分类建多个规则文件并利用 glob 匹配让不同目录下的会话自动带上最相关的规则而不是一份文件里塞满所有内容。4. 上下文窗口耗尽时的现象、诊断与应对4.1 上下文耗尽的三个典型症状很多开发者遇到AI 突然变笨的时候第一反应是换模型或换工具。但根据我的经验半数以上情况其实是上下文窗口快要被塞满了。症状通常有三种。输出变短、变泛。本来能写完整实现突然开始给伪代码 省略号或者把方案总结成要点不再展开细节。这是模型在窗口末尾的典型表现它还在尽力回答但已经没有足够空间输出长内容了。前后矛盾。前一分钟你让它确定用方案 A它答应了再问两句它又在解释方案 B 的优劣。这不是它忘了而是早期对话的细节已经被压缩或挤出有效注意力范围。直接截断报错。最直观的信号输出生成到一半断掉工具提示上下文长度超出限制或类似信息。出现这个基本不用再挣扎了会话已经没法继续。4.2 token 消耗怎么估算、怎么看每个模型窗口大小不同主流的在 100K 到 200K token 左右。你说200K 挺大的实际上消耗得很快。这里给一个粗糙但好用的估算口径一个英文单词大约 1.3 到 1.5 token一页典型的英文文档约 500 到 700 token中文的 token 消耗通常比英文更高一点大致 1 个汉字约 0.5 到 1 个 token。换算到代码场景一个 2000 行的 TypeScript 文件动辄 1 到 2 万 token一连引用五个文件窗口的大半就没了。大多数工具会在输入框附近显示当前上下文的估算用量有的甚至带进度条和颜色警示。我在团队里立了个规矩任何一次重要任务开始前看一眼这个指示器。如果用量已经超过一半先删掉不重要的参考文件或者干脆开新会话把关键约束一次性说清楚。别抱着再坚持一下的心态后面几乎必然翻车。4.3 自动压缩的坑它记住的未必是你要的重点当上下文快要触顶时很多工具会自动生成一份摘要把早期对话总结压缩后继续。听起来贴心但这里有个大坑自动压缩的摘要权重由工具决定它可能着重保留用户说了什么需求却丢掉你随口提过但非常重要的背景条件。AI 自己可不知道哪些约束是红线哪些是参考。我遇到过最典型的一次我在会话里提到不要改动 user 表的索引刚优化过后面又聊了很多其他实现细节。上下文压缩后这个约束从摘要里消失了AI 继续运行时直接把索引改成了它认为更合理的方案。不是它坏是真的没了这条信息。所以越重要的约束越要写进规则文件而不是埋在对话历史里。规则文件是每次会话都稳定注入的压缩机制动不了它。口头约束在长会话里是很不可靠的。4.4 手动拆包续聊把长任务切成多个短对话这是我这一年学到最实用的一招把大任务拆成多个小对话每个小对话只解决一个子问题。比如实现一个新的支付页面这个任务我不会丢给 AI 一口气做完而是拆成四步。第一步新会话让它设计方案只引用支付相关接口文档和现有页面样例。第二步确认方案后新会话让它实现 API 层和状态管理。第三步新会话让它实现 UI 组件手动引用设计系统文件。第四步新会话让它写关键用例。每次会话都从干净的上下文开始目标单一窗口消耗小压缩机制也无从发挥副作用。代价是需要自己多切几次会话、手动传递必要的上下文但这个代价远远低于一个会话里越聊越乱、最后来回返工的时间损失。拆开之后每个子任务的输出质量会肉眼可见地提升。5. 实盘案例给一个开源仓库加通知功能我是怎么配 context-mode 的5.1 任务背景与初始配置有一次我帮一个团队给他们的开源仓库加一个站内通知功能。仓库不大不小200 个文件左右代码量约 20 万行技术栈是 Vue 3 前端加 Express 后端。任务本身很清晰后端加通知表、提供通知列表和已读接口前端加通知入口、列表页和红点提示。接手时项目里已经有一个 .cursorrules内容只有一行技术栈描述约等于没有。我一开始也没太当回事直接打开了新会话把需求贴进去还专门 了 src 目录下几个相关文件。第一步就让 AI 去产出后端数据模型的设计方案。5.2 第一轮失败我犯了三个典型错误第一轮方案没过多久就暴露了问题。AI 给出的 schema 设计里有 notice 表但它的主键类型和项目里现有表的风格不一致字段命名也走了英文复数风格的惯用套路和项目里已经是单数命名惯例不统一。我让它参考现有表重新设计它却开始把 user 表、order 表也翻出来统一优化越扯越远。复盘这轮失败根源是我犯了三个错误。第一没有给 Agent 划边界它读取文件时把很多无关模块也带进了上下文注意力被分散。第二规则文件形同虚设项目自己的命名约定和表结构风格没有被固化AI 只能靠猜。第三我在对话里不断补充约束但这些约束都在历史里上下文一压缩就丢模型越到后面越记不住。5.3 调整上下文策略白名单 规则文件 分步执行我停下来重新建规则文件。在 .cursorrules 里补上了数据库命名约定表名单数、字段 snake_case、时间戳统一叫 created_at 和 updated_at、现有表的主键风格BIGINT 自增、以及新表必须包含 version 乐观锁字段这类项目特有规范。同时加了一条强制约束不允许修改与通知功能无关的任何文件。然后我把全局检索也用上了。先用 Codebase 搜已读状态和红点提示确认项目里有没有类似实现可以复用结果找到了一个消息模块虽然不是完全一样但它的接口风格和服务层写法值得借鉴。我把这些定位到的文件手动加入上下文作为后端设计的样板。执行上我改成三步走。第一步只做后端建表、写迁移、注册路由、服务层实现对话目标是单一且明确的。第二步新开会话只做前端 API 封装和状态管理。第三步再新开会话只做 UI 页面和红点交互。每步之间传递的信息只有几个关键接口签名不再把所有细节都塞进一个会话。5.4 最终效果和资源配置这一版明显顺多了。后端一轮通过前端两轮微调后也能跑通联调。整个过程中有个数字我记得很清楚第一轮失败时那个会话到后期上下文指示器已经接近满格满屏都是参考了哪些文件的记录。拆开之后的三个会话每个基本都只用掉窗口的 30% 左右留给模型输出更具体实现的空间反而更大了。这个案例不是模型有多强纯粹是 context-mode 管理对了。规则文件承担了项目约定白名单承担了修改边界全局检索承担了样板定位分步会话承担了注意力集中。每一步都不是什么高深技巧组合起来效果却很显著。6. 我踩过的上下文管理坑最后留下的几条经验6.1 索引会过期Codebase 可能给你旧代码有一阵我做大仓库重构Codebase 频繁返回明显过期的代码片段。AI 基于这些片段给出建议我一执行就报错折腾了很久才发现语义索引没有及时更新。Cline 和 Cursor 都会在文件变更后重建索引但偶尔会出岔子。我的处理方法是全局检索结果不可靠时优先确认目标文件当前内容是否与检索片段一致必要时重启工具或手动触发索引重建。别盲目信任检索结果它只是帮你提高定位效率不是最终正确答案。6.2 规则文件写太长一样会挤压上下文规则文件有用但不是越长越好。有一个项目我把规则文件写成了小册子洋洋洒洒三千字涵盖了各种边界情况。结果 AI 每次会话光读规则就吃掉几千 token而且规则之间还有隐性的优先级冲突输出经常自相矛盾。后来我把规则压缩到五百字以内只保留核心约束和目录约定效果反而更好。规则文件是给模型看的不是给团队展示的文档短才能被真正执行。6.3 一味手动引用会累死自己还会忽略上下文历史手动引用大法虽好但也有副作用。一次我接了个跨模块的任务前前后后引用了十几个文件对话框上方堆了一长串引用列表结果模型越到后面越混乱因为它要把所有这些文件的内容和对话历史一起维持。后来我才明白手动引用的上限不是工具的是模型注意力的。引用文件超过五六个就该考虑拆任务或启用 Agent 自主探索而不是继续硬塞。6.4 把 context 管理当工程来做而不是当参数调最后一条经验偏认知层面。很多人遇到 AI 输出质量波动就换模型、调温度很少人会去复盘这轮会话我到底喂了什么。实际上 context-mode 的管理更像是工程问题需要立规矩、建配置、定流程。每次任务开始前花三十秒想清楚这个任务该用哪种上下文形态、哪些文件真正相关、哪些红线要写进规则文件。坚持下来产出质量的提升远比换个最强模型来得实在。我自己现在的习惯是新项目第一天先把规则文件建好再写第一行业务代码。这个习惯帮我省掉了大量和 AI 反复解释、反复纠偏的时间。如果你只能从这篇文章带走一件事我希望是这句话别跟模型较劲先看看你给了它什么样的上下文。
AI编程助手输出质量差？八成是context-mode没管好
你有没有遇到过这种场景明明用的是同一个模型、同一个工具同事的 AI 编程助手像老手一样稳准狠你的却像刚转行的实习生改一个 bug 顺手把无关代码翻个底朝天最后给出一堆似是而非的建议。我去年带团队推 AI 辅助开发一开始大家的工具都配得差不多跑了一周结果却是天壤之别。逐条对比会话输入之后我发现一个扎心的事实产出质量八成由 context-mode 决定也就是我们到底以什么方式、把哪些信息喂给了模型。模型本身的智商差距远没有我们想象的那么大。这篇文章不聊那些虚头巴脑的提示词技巧我把一整年折腾 context-mode 的经验完整梳理一遍。它适合正在用 Cursor、Copilot、Cline、Codex 这类 AI 编程助手的开发者也适合在小团队里负责推广 AI 工具的人。内容包括三种上下文模式的区别、如何用规则文件固化项目的长期记忆、上下文窗口被撑爆的诊断和补救以及一个真实项目的完整配置过程。官方文档能告诉你按钮在哪但很难告诉你什么时候该用哪种模式、为什么用错了会翻车这部分我会用自己的踩坑记录补上。1. AI 编程辅助产出质量差八成是 context-mode 的问题1.1 一个答非所问的现场团队里有个同事用 Cursor 改前端样式目标很明确让某个按钮在移动端隐藏只调整 CSS。结果 AI 不仅改了样式还顺手重构了组件的 props 接口、把一段 service 层调用也优化了最后他花了一下午做回滚。只看这个结果谁都会觉得是模型太自作主张。但把 Chat 面板打开一看就明白了上下文里没有任何本次任务边界的说明只有一个几百行的组件文件以及上一条历史对话的尾巴——那条对话恰好还在讨论接口重构。模型没有能力猜到我只想动样式这个隐含前提它只能根据喂给它的全部上下文推断你大概想继续重构这个组件。这就是 context-mode 失控最常见的样子不是 AI 突然犯傻而是你给它的视野本身就是错位的。1.2 上下文模式的本质模型输出只是上下文的投影理解 context-mode 之前先放下一个执念大模型不会因为某个版本升级就突然从笨变聪明。同一个模型在同一个温度参数下回答质量会随着输入内容发生剧烈波动。你在对话里给它的全部文本——系统提示词、规则文件、参考文件、历史对话、工具执行结果——合起来才决定了它这次输出围绕什么展开、边界在哪里。来打个比方。你让一个经验丰富的老工程师帮忙改代码如果只丢给他一个文件路径他肯定会先把整个项目结构和相关调用链翻一遍如果你明确说只准碰这个文件的样式部分其他一律不动他干活就会收敛很多。context-mode 干的就是这件事它管理的是老工程师能看到的资料范围以及他行动的权限边界。只是大多数开发者完全没意识到自己一直在用默认配置等于让老工程师裸奔着进工地。这也能解释另一个常见现象很多人觉得上下文给得越多AI 越聪明于是把所有源码、文档一股脑塞进去。实际情况恰恰相反模型对长上下文的注意力天然是分散的塞入大量无关内容它会抓住某些巧合的关联放大发挥。上下文不是堆料是筛选。1.3 三种上下文形态手动引用、自动上下文、全局检索我习惯把主流 AI 编程工具的 context-mode 归纳为三种形态手动引用。你在对话框里用 或 # 显式指定文件、文件夹、文档片段让它们成为对话的固定输入。这是最朴素的方式精确但费手。自动上下文 / Agent 自主读取。工具开启 Agent 模式后AI 自己决定要读哪些文件、跑哪些命令、看哪些输出按需取用。Cursor 的 Agent 模式、Windsurf 的 Cascade、Cline 的 Plan/Act 都类似这种。省心但 token 消耗可能失控而且一旦没有约束AI 的探索路径会很不稳定。全局语义检索。通过 Codebase / #Codebase 这样的入口触发仓库级语义索引让工具把与描述最相关的文件片段自动检索出来注入上下文。这不是把整个仓库塞进窗口而是做了一次联想检索适合大仓库里定位代码。这三者不是互斥关系我后面会详细说明什么时候混用、什么时候只用一种。先把它们的底层差异讲透你才知道自己每次点击到底发生了什么。2. 三种 context-mode 的核心差异与选型判断2.1 手动引用精确但费力单文件小改动优先手动引用看似简单里面其实藏着一个很多人不知道的细节你告诉 AI读取文件 A工具通常不是把文件截断成几行摘要而是把整个文件内容当作文本注入。一个 800 行的组件文件按常见换算大约 6000 到 8000 token。三个这样的文件就轻松吃掉了 2 万 token 的窗口。很多人的惯性是多 几个文件让 AI 看得全面些结果窗口被快速填满模型的有效注意力也被稀释。我的建议是单文件小改动、改样式、修 typo、写测试用例这一类目标清晰的小任务直接用手动引用并且只引用真正涉及的文件。如果某个文件很大先自己定位到相关函数段落把这段内容作为选中文本贴进对话而不是整个文件拖进去。这样可以大幅减少 token 浪费也能让 AI 的输出更聚焦。还有一个实用技巧当你在编辑器里选中一段代码再唤起 Chat/Copilot大多数工具会自动把这段选中内容作为上下文。所以先选中、再提问本身就是一种高效的手动引用方式比 整个文件更精准。我实测下来用选中代码替代整个文件引用单次交互 token 能省 60% 以上而且很少出现AI 被文件其他部分带偏的情况。2.2 自动上下文省心但烧 token必须有边界Agent 类功能的卖点就是你提需求它自己读代码、自己动手。听起来很美实际用起来最需要警惕。没有显式边界时Agent 可能会为了找一个小配置项读遍半个仓库token 哗哗地烧输出质量却不一定好因为读入的内容里有很多是它顺手探索到的无关信息。给 Agent 加边界目前比较成熟的实践是两条线。一条是对话层面的约束明确写清楚只允许修改 src/features/notification 目录下的文件不要改动 server 目录不要运行测试以外的命令把探索范围收窄。另一条是工具层面的配置在 Cursor 的项目规则里写明默认禁止事项或者在 Cline 的 .clinerules 里定义读文件优先级。两条线配合Agent 才会既有探索自由度又不至于跑飞。还有一点Agent 模式跑长任务时会自己维护一份已读文件列表。很多工具会在侧边栏或日志里展示它读了哪些文件。我建议每跑完一个阶段就扫一眼这个列表如果发现它读了明显不该碰的东西立刻打断并修正描述。别等到最后才发现它把 30 个文件全部读了一遍然后基于一份混乱的信息改代码。2.3 全局检索大仓库语义定位的好帮手Codebase / #Codebase 这类功能依赖工具建立的语义索引。它的工作方式是把你的问题转成向量表示去索引库里找语义上最接近的若干代码片段然后把片段拼接进上下文。它解决的是我不知道这段逻辑写在哪个文件里的问题。但全局检索有一个天然弱点检索回来的都是片段不是完整文件。这对上下文友好但也意味着 AI 只看到局部看不到全貌。比如它检索到函数calculatePrice的实现片段但没看到这个函数是在哪个模块被调用的、调用方的数据结构长什么样就容易给出局部优化但全局不兼容的方案。所以我通常把 Codebase 当作入口定位器而不是直接生成器。先用它定位到相关文件再手动打开这些文件把关键部分加入上下文做第二轮深度推理。这样既发挥了检索的效率又补足了它缺失的全局视野。2.4 场景选型速查表整理了一张表是我日常分配的参考基本可以覆盖大多数情况。场景推荐模式理由单文件小改动、改样式、修 typo手动引用 选中代码成本低、方向唯一跨 3 到 5 个文件的小功能Agent 白名单目录时区能自主探索又不会跑偏大仓库里定位某段逻辑Codebase 语义检索免手动翻找重构大模块手动引用 规则文件明确边界防止 AI 扩大修改面疑难 bug 深挖小步多次、每次新会话避免历史污染生成新代码但需参考旧实现手动引用旧文件 明确只参考不修改让模型有样板可用选型的关键不是哪个高级用哪个而是哪种方式让模型的注意力最集中在你想要的那一小块。我在团队里反复强调context-mode 选择的本质是注意力管理不是参数调优。3. 让 context-mode 长期稳定的配置文件体系3.1 规则文件是项目的长期记忆会话是短暂的项目是长期的。如果每开一个新会话都要把技术栈、目录约定、禁止事项重新说一遍既痛苦又容易遗漏。规则文件就是干这件事的。Cursor 里的 .cursorrules、新版带 glob 匹配的 .cursor/rules 目录Cline 的 .clinerules 和 .clinerules/ 多文件目录Copilot 的 .github/copilot-instructions.mdCodex CLI 的 AGENTS.md本质上都是同一个东西项目级系统提示词。这个文件的价值被多数人严重低估。我见过太多人把它当成日志本或者干脆不建。实际上一个写得好好的规则文件能让每次会话的 AI 从第一次见这个项目的实习生变成已经入职三个月的熟手。你省下的不是打字时间而是大量来回纠偏的对话轮次。3.2 规则文件该写什么、不写什么规则文件最忌讳空泛。像请写出高质量的代码这种话毫无信息量模型只会礼貌地表示认同然后继续按默认行为做事。真正有用的是那些不看项目文档就无法准确知道的硬信息。我建议按四类内容组织技术栈与版本框架、语言、包管理器、构建工具以及有没有特殊约束比如只能使用某个 npm 镜像、Node 必须是某个大版本。目录结构与分层约定哪个目录放组件、哪个目录放 API 调用、哪个目录必须保持纯净。模型对常见结构有先验认知但你的项目未必按它熟悉的套路来。强制约束与禁止事项比如客户端禁止直连数据库所有 API 请求必须带 requestId禁止修改 schema 文件如需变更先写迁移脚本这类红线。这是碾平 AI 越界行为最有效的手段。高频工作流比如改后端接口时同步更新 swagger 文档新增组件必须配 stories。这类流程约束会让产出更接近团队规范。不写什么不写与代码无关的公司背景、项目历史、团队八卦不写大段风格口号不写模型已经很清楚的语言特性和框架常识。规则文件每多一行都会占用上下文预算所以要像写代码一样对待它短、准、可执行。3.3 排除与忽略把垃圾挡在窗口外面大部分 AI 编程工具在做全局检索或 Agent 自主读取时会尊重项目的 .gitignore 配置。node_modules、dist、build 这些目录通常不会进上下文这是个好消息。但坏消息是总有一些文件你不想让 AI 碰它们又不在 .gitignore 里。比如大型的 JSON 配置文件、生成的 API 类型定义、带敏感信息的本地环境变量样例哪怕只是样例也不该喂给模型、几千行的锁文件。应对方法是三层防线。第一层是规则文件里的 glob 匹配比如在 .cursor/rules 里写!**/generated/**告诉工具这些目录不要读。第二层是对话级别的显式排除不要读取 server/migrations 目录下的文件那些是数据库自动生成的。第三层是日常习惯不把本地 .env 文件拖进任何上下文包括手动引用。这条习惯跟工具能力无关就是安全意识。3.4 一个可以直接抄的规则模板下面这个模板来自我给一个 Vue 3 Express 全栈项目配的 .cursorrules效果比较稳你可以按自己的堆栈改着用。# 项目技术栈 - 前端Vue 3 TypeScript Vite Pinia - 服务端Express Prisma PostgreSQL - 包管理器pnpm # 目录约定 - src/components 只放纯展示组件禁止写入业务逻辑 - src/features/[domain] 按业务域组织内部包含components、api、stores、types - server/routes 只做参数校验和路由转发业务逻辑一律放在 server/services - server/migrations 由 Prisma 自动生成禁止手改 # 强制约束 - 客户端禁止直接访问数据库所有数据操作必须通过 /api - 新增 API 必须同时在 docs/api.md 中补充说明 - 组件样式必须使用 scoped禁止写全局 CSS - 如果已有工具函数禁止新增重复实现优先复用 src/utils 下的函数 # 工作流 - 修改数据模型时先修改 schema.prisma生成迁移再更新对应类型 - 开发新页面时先写路由再建页面组件最后补关键交互测试注意这份模板的字数控制在合理范围内不会挤压太多上下文预算。实际使用中如果你的项目横跨多个技术栈建议分类建多个规则文件并利用 glob 匹配让不同目录下的会话自动带上最相关的规则而不是一份文件里塞满所有内容。4. 上下文窗口耗尽时的现象、诊断与应对4.1 上下文耗尽的三个典型症状很多开发者遇到AI 突然变笨的时候第一反应是换模型或换工具。但根据我的经验半数以上情况其实是上下文窗口快要被塞满了。症状通常有三种。输出变短、变泛。本来能写完整实现突然开始给伪代码 省略号或者把方案总结成要点不再展开细节。这是模型在窗口末尾的典型表现它还在尽力回答但已经没有足够空间输出长内容了。前后矛盾。前一分钟你让它确定用方案 A它答应了再问两句它又在解释方案 B 的优劣。这不是它忘了而是早期对话的细节已经被压缩或挤出有效注意力范围。直接截断报错。最直观的信号输出生成到一半断掉工具提示上下文长度超出限制或类似信息。出现这个基本不用再挣扎了会话已经没法继续。4.2 token 消耗怎么估算、怎么看每个模型窗口大小不同主流的在 100K 到 200K token 左右。你说200K 挺大的实际上消耗得很快。这里给一个粗糙但好用的估算口径一个英文单词大约 1.3 到 1.5 token一页典型的英文文档约 500 到 700 token中文的 token 消耗通常比英文更高一点大致 1 个汉字约 0.5 到 1 个 token。换算到代码场景一个 2000 行的 TypeScript 文件动辄 1 到 2 万 token一连引用五个文件窗口的大半就没了。大多数工具会在输入框附近显示当前上下文的估算用量有的甚至带进度条和颜色警示。我在团队里立了个规矩任何一次重要任务开始前看一眼这个指示器。如果用量已经超过一半先删掉不重要的参考文件或者干脆开新会话把关键约束一次性说清楚。别抱着再坚持一下的心态后面几乎必然翻车。4.3 自动压缩的坑它记住的未必是你要的重点当上下文快要触顶时很多工具会自动生成一份摘要把早期对话总结压缩后继续。听起来贴心但这里有个大坑自动压缩的摘要权重由工具决定它可能着重保留用户说了什么需求却丢掉你随口提过但非常重要的背景条件。AI 自己可不知道哪些约束是红线哪些是参考。我遇到过最典型的一次我在会话里提到不要改动 user 表的索引刚优化过后面又聊了很多其他实现细节。上下文压缩后这个约束从摘要里消失了AI 继续运行时直接把索引改成了它认为更合理的方案。不是它坏是真的没了这条信息。所以越重要的约束越要写进规则文件而不是埋在对话历史里。规则文件是每次会话都稳定注入的压缩机制动不了它。口头约束在长会话里是很不可靠的。4.4 手动拆包续聊把长任务切成多个短对话这是我这一年学到最实用的一招把大任务拆成多个小对话每个小对话只解决一个子问题。比如实现一个新的支付页面这个任务我不会丢给 AI 一口气做完而是拆成四步。第一步新会话让它设计方案只引用支付相关接口文档和现有页面样例。第二步确认方案后新会话让它实现 API 层和状态管理。第三步新会话让它实现 UI 组件手动引用设计系统文件。第四步新会话让它写关键用例。每次会话都从干净的上下文开始目标单一窗口消耗小压缩机制也无从发挥副作用。代价是需要自己多切几次会话、手动传递必要的上下文但这个代价远远低于一个会话里越聊越乱、最后来回返工的时间损失。拆开之后每个子任务的输出质量会肉眼可见地提升。5. 实盘案例给一个开源仓库加通知功能我是怎么配 context-mode 的5.1 任务背景与初始配置有一次我帮一个团队给他们的开源仓库加一个站内通知功能。仓库不大不小200 个文件左右代码量约 20 万行技术栈是 Vue 3 前端加 Express 后端。任务本身很清晰后端加通知表、提供通知列表和已读接口前端加通知入口、列表页和红点提示。接手时项目里已经有一个 .cursorrules内容只有一行技术栈描述约等于没有。我一开始也没太当回事直接打开了新会话把需求贴进去还专门 了 src 目录下几个相关文件。第一步就让 AI 去产出后端数据模型的设计方案。5.2 第一轮失败我犯了三个典型错误第一轮方案没过多久就暴露了问题。AI 给出的 schema 设计里有 notice 表但它的主键类型和项目里现有表的风格不一致字段命名也走了英文复数风格的惯用套路和项目里已经是单数命名惯例不统一。我让它参考现有表重新设计它却开始把 user 表、order 表也翻出来统一优化越扯越远。复盘这轮失败根源是我犯了三个错误。第一没有给 Agent 划边界它读取文件时把很多无关模块也带进了上下文注意力被分散。第二规则文件形同虚设项目自己的命名约定和表结构风格没有被固化AI 只能靠猜。第三我在对话里不断补充约束但这些约束都在历史里上下文一压缩就丢模型越到后面越记不住。5.3 调整上下文策略白名单 规则文件 分步执行我停下来重新建规则文件。在 .cursorrules 里补上了数据库命名约定表名单数、字段 snake_case、时间戳统一叫 created_at 和 updated_at、现有表的主键风格BIGINT 自增、以及新表必须包含 version 乐观锁字段这类项目特有规范。同时加了一条强制约束不允许修改与通知功能无关的任何文件。然后我把全局检索也用上了。先用 Codebase 搜已读状态和红点提示确认项目里有没有类似实现可以复用结果找到了一个消息模块虽然不是完全一样但它的接口风格和服务层写法值得借鉴。我把这些定位到的文件手动加入上下文作为后端设计的样板。执行上我改成三步走。第一步只做后端建表、写迁移、注册路由、服务层实现对话目标是单一且明确的。第二步新开会话只做前端 API 封装和状态管理。第三步再新开会话只做 UI 页面和红点交互。每步之间传递的信息只有几个关键接口签名不再把所有细节都塞进一个会话。5.4 最终效果和资源配置这一版明显顺多了。后端一轮通过前端两轮微调后也能跑通联调。整个过程中有个数字我记得很清楚第一轮失败时那个会话到后期上下文指示器已经接近满格满屏都是参考了哪些文件的记录。拆开之后的三个会话每个基本都只用掉窗口的 30% 左右留给模型输出更具体实现的空间反而更大了。这个案例不是模型有多强纯粹是 context-mode 管理对了。规则文件承担了项目约定白名单承担了修改边界全局检索承担了样板定位分步会话承担了注意力集中。每一步都不是什么高深技巧组合起来效果却很显著。6. 我踩过的上下文管理坑最后留下的几条经验6.1 索引会过期Codebase 可能给你旧代码有一阵我做大仓库重构Codebase 频繁返回明显过期的代码片段。AI 基于这些片段给出建议我一执行就报错折腾了很久才发现语义索引没有及时更新。Cline 和 Cursor 都会在文件变更后重建索引但偶尔会出岔子。我的处理方法是全局检索结果不可靠时优先确认目标文件当前内容是否与检索片段一致必要时重启工具或手动触发索引重建。别盲目信任检索结果它只是帮你提高定位效率不是最终正确答案。6.2 规则文件写太长一样会挤压上下文规则文件有用但不是越长越好。有一个项目我把规则文件写成了小册子洋洋洒洒三千字涵盖了各种边界情况。结果 AI 每次会话光读规则就吃掉几千 token而且规则之间还有隐性的优先级冲突输出经常自相矛盾。后来我把规则压缩到五百字以内只保留核心约束和目录约定效果反而更好。规则文件是给模型看的不是给团队展示的文档短才能被真正执行。6.3 一味手动引用会累死自己还会忽略上下文历史手动引用大法虽好但也有副作用。一次我接了个跨模块的任务前前后后引用了十几个文件对话框上方堆了一长串引用列表结果模型越到后面越混乱因为它要把所有这些文件的内容和对话历史一起维持。后来我才明白手动引用的上限不是工具的是模型注意力的。引用文件超过五六个就该考虑拆任务或启用 Agent 自主探索而不是继续硬塞。6.4 把 context 管理当工程来做而不是当参数调最后一条经验偏认知层面。很多人遇到 AI 输出质量波动就换模型、调温度很少人会去复盘这轮会话我到底喂了什么。实际上 context-mode 的管理更像是工程问题需要立规矩、建配置、定流程。每次任务开始前花三十秒想清楚这个任务该用哪种上下文形态、哪些文件真正相关、哪些红线要写进规则文件。坚持下来产出质量的提升远比换个最强模型来得实在。我自己现在的习惯是新项目第一天先把规则文件建好再写第一行业务代码。这个习惯帮我省掉了大量和 AI 反复解释、反复纠偏的时间。如果你只能从这篇文章带走一件事我希望是这句话别跟模型较劲先看看你给了它什么样的上下文。