在 AI 编码助手越来越普及的今天我见过太多人陷入一种奇怪的循环装好工具兴奋地试了两天觉得“也就那样”然后放弃过段时间看到别人用得很溜又捡起来再试再放弃。问题几乎出在同一个地方——上下文没喂对。同一个模型同一个提示词在会配置上下文的人手里能准确理解一个几万行代码仓库的结构改 bug 一步到位在不会配置的人手里连“别动测试文件”这种基本约束都记不住。这中间的差距就是上下文工程。很多人把上下文工程等同于提示词工程其实是两码事。提示词工程解决的是“怎么把话说清楚”上下文工程解决的是“怎么把该说的信息准备齐”。到了真实项目里后者往往更影响成败。特别是像 Cursor、Copilot、Codex 这类 AI 编码助手你给它的上下文质量直接决定了它写出来的代码是能直接用的草稿还是需要你从头改到脚的废纸。这篇文章我想分享一套我自己在项目中反复打磨的四层上下文配置方法项目级、会话级、任务级、工具链级。它不是某个工具的专属教程而是一套通用的组织思路你在任何主流 AI 编码助手里都能落地。如果你已经受够了“AI 写的代码总差一口气”这篇文章应该能帮你找到那口气在哪里。1. 上下文工程的核心逻辑与传统做法的差异1.1 从“喂得越多越好”到“喂得越准越好”很多人第一次接触 AI 编码助手时的直觉是把整个项目拖进去让 AI 看得越全越好。于是在项目根目录丢一个大文件里面复制了全部源码再把需求写在最后。结果是什么呢模型很快就被大量无关代码冲昏了头根本没精力关注你真正改动的那个模块。我见过一个最典型的例子同事让 Claude 帮忙改一个支付回调的异常处理顺手把整个 utils 目录 30 多个工具函数全贴进了上下文。模型倒是认认真真读完了但在 7000 多个 token 的噪声信息里它把回调逻辑里的订单状态字段认错了。最后改出来的代码不仅没修好异常反而引入了重复退款的风险。上下文工程的第一性原理是把信息按“与当前任务的关联度”分层管理而不是一股脑地塞给模型。这和人类接手一个新项目时的思路一模一样——你先看架构文档再看相关模块的代码最后才深入到具体函数。AI 编码助手需要的信息也可以分成四层全局的、会话的、任务的、工具能自己获取的。每一层都有不同的存储位置和更新频率。1.2 为什么四层配置比单一大文件更稳如果你只是把配置写进一个巨大的 AGENTS.md 或者 CLAUDE.md也会遇到两个问题第一上下文预算会被迅速耗尽。以 Claude 的 200K 上下文为例看起来很大但真实代码文件的 token 消耗远比你以为的快。一个项目的全局规则文件如果写到了 3000 token每次对话都要把这份规则完整读一遍。假设你一个会话要和模型交互 30 轮这 3000 token 就被重复读了 30 次实际占用的资源是 90K token不算不知道一算吓一跳。第二信息更新会变得极其痛苦。项目规范是持续演进的测试要求会变、命名风格会变、第三方库会升级。如果你把所有规则都放在一个文件里每改一次都要小心翼翼生怕删掉某个再也不会用到的历史约束。而四层配置的思路是全局规则只保留最稳定、最根本的内容经常变的、和具体任务绑定的内容尽量往后放放进会话或任务级别的上下文里。我之前接手过一个用 React TypeScript 写的后台管理系统前后两个人维护代码风格完全是两种流派。后来我打算用 AI 助手做一次大规模重构但助手总是时不时把旧风格和新风格混着来。我把重构相关的规则全部放进任务级上下文也就是当次对话的附加说明里只在全局规则文件里留了“遵循项目现有 ESLint 配置不得自创风格”这一条情况立刻好转。可见信息放在哪一层和这条信息本身有多“长期”高度相关。1.3 四层框架概览打个比方如果 AI 编码助手是一个新入职的工程师那么——第一层项目级上下文相当于公司的《员工手册》讲的是企业的价值观和红线这个项目用什么语言、什么框架、什么目录结构、禁止做什么。入职第一天就能看完入职一年后还是那几条。第二层会话级上下文相当于你开周会时的“当前项目进度同步”这周在做什么、上次改到哪里、有什么已知的坑。第三层任务级上下文相当于你派活时的“任务单”这次要做的是哪个功能涉及哪个接口验收标准是什么。第四层工具链上下文相当于新员工自己的“搜索引擎和知识库”他能自己去翻代码库、查文档、看 git 历史不需要你把所有事都喂到嘴边。这四层不是互相替代的关系而是配合关系。配置得当AI 编码助手会在合适的时机自动获取合适的信息精准得像在项目里干了半年一样配置不当它就是一个记性极差、但执行力极强的外包永远在问你“这个文件在哪”“这个接口的返回结构是什么”。2. 第一层配置项目级上下文把根扎稳2.1 项目级规则文件应该写什么、不写什么项目级上下文的核心载体是那些 AI 编码助手会自动读取的规则文件。在 Cursor 里叫.cursor/rules在 Claude Code 里是CLAUDE.md在 Codex 里大致对应AGENTS.md。不管名字是什么这一类文件承担的都是“长期记忆”功能。我建议你把以下几类内容写进项目级规则文件项目基础画像项目是做什么的目标用户是谁主要业务模块有哪些。这能让 AI 在生成代码时对齐业务语义而不是只停留在语法正确。技术栈清单千万别只写“React TypeScript”。要把关键版本号、包管理器、UI 组件库、状态管理方案、路由方案、数据请求方案全部写清楚。AI 的预训练知识里 React 版本差异经常搞混你在规则文件里写死“项目使用 Next.js 14 App Router”远比让它自己从代码里猜要靠谱。目录结构与模块边界哪些目录是新增代码的主战场哪些目录是生成代码的禁区比如dist、node_modules、编译产物。硬性红线禁止手改锁文件、禁止在 reducer 里写副作用、禁止在页面组件里直接发请求。这种红线约束是项目级文件价值最大的部分。要注意的是不要把经常变化的“临时规范”写进项目级文件。比如“这次重构我们统一把 API 函数命名改为fetchXxx”这种话属于会话级的它只会在这个迭代里有效。你把它写进项目级文件过两周就把文件搞得越来越臃肿AI 也无从判断哪条规则还有效。2.2 让 AI 理解大型仓库的目录结构项目级文件里最大的难点不是告诉 AI 你的代码规范而是让 AI 真正理解一个大型仓库的“空间感”。一个动辄几百个文件的 monorepo光靠自然语言描述很难让模型建立准确的心智模型。我的习惯做法是在项目级规则文件里附上一棵经过手工压缩的目录树只保留有意义的层级和文件。不要用tree命令输出的全量结果那个太长了而且把node_modules这种垃圾信息也带进去毫无意义。比如一个后端项目我会这样写server/ src/ modules/ # 业务模块按领域划分 user/ # 用户模块 order/ # 订单模块 common/ # 跨模块共享代码 decorators/ # 自定义装饰器 filters/ # 异常过滤器 guards/ # 守卫 config/ # 环境配置 test/ e2e/ # 端到端测试然后在规则文件里明确“新增业务代码请优先放入src/modules/{domain}/下对应模块src/common/下只放被至少两个模块引用的共享代码所有环境变量必须在src/config/中定义 schema”。这样 AI 在生成代码时就不只是“写出一段 TypeScript”而是“在正确的位置写出一段符合项目组织方式的 TypeScript”。这俩区别用过的人都知道有多大。2.3 一个可复用的项目级规则模板下面是我目前在自己项目里使用的规则文件模板你可以直接抄走改改重要提示这份模板适合中型项目团队人数在 1-20 人之间。如果项目规模特别大我建议拆成多个规则文件按目录或领域分别加载避免单个文件过长。# 项目概述 这个项目是一个面向中小型电商商家的订单管理系统提供订单处理、库存管理、售后流程、数据报表等核心能力。目标用户是商家运营人员使用场景以桌面端浏览器为主。 # 技术栈 - 前端框架Next.js 14App RouterTypeScript 5.x - 状态管理Zustand禁止使用 Redux - 样式方案Tailwind CSS CSS Modules - 数据请求TanStack Query axios - UI 组件shadcn/ui二次封装需放在 src/components/ui-extended - 测试Vitest React Testing Library - 包管理器pnpm # 目录结构说明 此处放上一节提到的压缩目录树 # 编码规范 - 组件文件使用 PascalCase 命名工具函数使用 camelCase 命名 - 禁止在 useEffect 中直接修改状态副作用必须通过事件或 reducer 触发 - API 请求必须走统一封装的 request 实例禁止直接使用 fetch - 错误处理必须同时考虑 error 状态和 loading 状态禁止只写成功路径 - 所有日期处理统一使用 dayjs禁止引入 moment # 硬性红线 - 禁止修改 pnpm-lock.yaml - 禁止在 app/api 目录之外编写后端接口 - 禁止在客户端组件中直接访问 process.env 里的密钥这个模板的核心是具体到能直接执行。你写“代码要规范”AI 是不知道怎么办的你写“组件文件使用 PascalCase 命名”AI 就会照着做。这个区别本质上就是把“模糊期望”翻译成“机器指令”。3. 第二层配置会话级上下文打造过程中的临时记忆3.1 会话上下文要解决什么问题项目级规则文件是长期记忆但 AI 编码助手在工作中真正需要的是“短期记忆”。它就像一个记性不太好的同事你和它开了一个新会话它就把上次讨论的内容忘得干干净净。除非你显式把“当前进度”喂给它否则它只能靠猜。会话级上下文要解决的就是这个让 AI 在同一个任务周期内保持一致的上下文理解。这个“任务周期”可以是一天的工作也可以是一次完整的功能开发甚至是一次从重构到测试的完整迭代。我自己的习惯是每开始一个阶段性任务先写一份“会话简报”包含三块当前进度上次做到哪一步了哪些功能已完成哪些还差什么。已知约束本次任务中特殊的技术约束或业务约束比如“支付模块的接口尚未联调不要生成真实请求”“这次只重构逻辑不要动 UI 样式”。已完成决策我们之前讨论过但没写进项目级规则的一些决定比如“错误提示统一用 toast不用 alert”“分页参数约定从 0 开始”。翻译成实际操作就是在每次对话开始时用一段简短的话把这个会话目标说清楚。比如我们要继续昨天的登录功能改造。目前登录接口已封装完毕token 存储已改用 cookie之前是 localStorage已废弃。今天的目标是完成登录页的 UI 联调表单校验已完成还差错误提示和 loading 状态。注意这次不要动记住我功能产品说那个下一版再做。这段话看着不长但对 AI 的意义极大。它帮你把模型的注意力锁定到当前任务范围内避免它东一榔头西一棒子更避免它“好心”地去重写你已经完成的逻辑。3.2 用 TODO 和决策日志管理对话中的临时信息会话级上下文不能只靠开头的“会话简报”因为随着对话进行你会不断做出新决策、发现问题、调整方案。这些信息如果不加管理会让后续的模型越来越困惑。我强烈建议你在项目中维护一份session-notes.md不需要是正式文档就是给自己和 AI 看的草稿。我这边的实践是每次用 AI 编码助手工作之前都会先看一眼这份文件把过期的内容划掉补上新内容。有些比较严谨的项目我甚至在会话开始时先把这份文件读给 AI让它知道这是“当前会话的唯一权威依据”。举个例子有一次我在做一个图表组件的性能优化最开始决定用 memo 包一层后来实测发现 memo 本身也有开销决定改成“只在 props 变化时才重渲染”。如果我不把“memo 方案已放弃”这个决策记录下来AI 在新会话里很可能又给你写一遍 memo让你哭笑不得。会话级上下文的关键是保持鲜活。项目级规则文件像一个静态的宪法会话级笔记则像一个动态的日志。宪法不能天天改日志必须时时更新。3.3 实操示例一次完整的功能开发我把“会话简报 进行中的补充”做成一个组合套路下面是一次完整功能开发的示例。[会话开始时] 任务给订单列表页增加“批量导出”功能。 现状列表接口已支持分页和筛选多选状态已存在于组件内。 计划点击导出按钮时调用后端 /api/orders/export 接口接收 Blob 并触发浏览器下载导出范围包含当前筛选条件和所有页码的数据不是仅当前页。 [对话过程中出现新信息] 另外后端说导出接口一次最多支持 5000 条超了要分批。前端不用做分批逻辑但要在导出数量超过 5000 时给出提示。 [对话结束时] 今天的导出功能已完成联调通过。之前决定的分批提示需求已取消因为后端会直接返回错误码。下次会话记录导出按钮文案待产品确认其余全部完成。你看整个过程中我没有让 AI 猜过任何信息每一步的输入输出都是对齐的。很多 AI 编码助手“答非所问”的问题根源就在于你只给了它当下的提示词而没有给它连续的、有上下文的“工作背景”。4. 第三层配置任务级上下文让每次操作都有唯一目标4.1 单任务指令的“最少必要信息”是什么如果说会话级上下文是“今天的工作目标”那么任务级上下文就是“当前这次操作的施工图”。很多人在同一个会话里让 AI“改完这个再改那个”结果 AI 改着改着就串了。更科学的做法是明确区分会话和任务一个会话可以包含多个任务但每个任务的边界要清晰。任务级上下文需要的最少必要信息我总结为四件事任务目标这次要完成什么描述到可以直接验收的程度。涉及的代码位置改动哪个文件、哪个函数、哪个组件尽量给出具体路径和关键标识。输入与输出函数的输入参数、返回结构、需要适配的数据类型。验收标准怎么算“改完了”。可以是“测试通过”“构建无报错”“符合某个接口协议”。我平时写单任务指令时会刻意做到“给 AI 当律师”的程度每个词都有明确的解释每个要求都有对应的场景。模糊的表达只会给 AI 留出自由发挥的空间而这个空间大概率会变成你后期修 bug 的时间。比如帮我修改 src/pages/orders/List.tsx 中的批量导出按钮逻辑。当前按钮写在 Table 的 toolbar 区域点击后需要调用 api/orderApi.ts 里的 exportOrders 函数这个函数接受一个参数当前筛选条件对象返回 PromiseBlob。你需要把按钮的 loading 状态和导出完成的提示补全导出失败时展示 errorToast。验收标准点击按钮后能触发 download 方法保存文件且 loading 期间按钮不可重复点击。这段话提供了任务目标改导出按钮、位置List.tsx、orderApi.ts、输入输出筛选条件对象、Promise 、验收标准能下载、防重复点击。没有一句废话AI 也就没有理由跑偏。4.2 任务上下文的“时效性”把控有一种情况我非常不建议在任务上下文里写入那些“只在本次任务中重要但任务结束就该忘掉”的规则。比如“这次开发用的是临时 mock 数据后面要换真实接口”——这种信息放在任务里没问题但它不应该渗透到项目级规则里。否则下次做别的功能时AI 还会以为项目里在统一使用 mock 数据。任务级上下文应该是最轻、最临时、最具体的一层。它只服务于当下这一次指令。任务完成这层上下文的历史使命也就结束了。我见过一个反面案例有人在一个聊天机器人项目里在任务指令里加了“本项目所有回答必须使用 friendly tone”的约束。这个任务做完了下个任务做的是“客服工单自动分类”AI 依然用 friendly tone 生成所有分类结果和相关文案。要解决这种问题唯一的办法就是任务结束时明确告诉 AI 哪些约束只是临时的。我通常在任务末尾加一句“以上约束只适用于本次任务不写入项目规则文件。”4.3 如何让 AI 自动生成“任务上下文”的脚手架你说每次写任务指令都要这么详细是不是太费事了我的回答是一开始确实费事但熟练之后你会发现大部分任务指令是可以半模板化的。更省力的办法是让 AI 帮你生成任务上下文的脚手架。我现在的工作流是开口的第一句不是直接让 AI 写代码而是先让它“解析任务”我要做批量导出功能改动范围大致在 List.tsx 和 orderApi.ts 中。请先告诉我你理解的 1. 本次任务的完整目标 2. 需要用到的关键函数和数据结构 3. 你认为可能的风险点 4. 你的实现计划 确认后再开始写代码。这一步非常管用。AI 会用一两百个 token 的时间把任务理解成结构化的方案然后你来审核、纠正。等它复述准确了再让它动手。表面上多花了一步实际上省掉了至少一轮“改完不对重新再来”的返工。这里有个关键心智让 AI 编码助手“先想后写”而不是“边想边写”。前者把任务上下文显式化你随时能检查它有没有跑偏后者把上下文隐藏在黑箱里等它写出垃圾代码你才发现。5. 第四层配置工具链上下文让 AI 自己动手查信息5.1 MCP、索引与自动检索的能力边界项目级、会话级、任务级三层配置本质上都是你在“喂”信息给 AI。但你不可能把所有信息都喂进去——代码每天都在变接口文档也在更新如果 AI 每次都要你手动粘贴最新代码那效率就倒退回了原始的复制粘贴时代。第四层上下文——工具链上下文就是让 AI 具备主动获取信息的能力。主流 AI 编码助手基本都支持以下几类机制代码索引/语义搜索Cursor 和 Copilot 都会索引你的代码库AI 能通过自然语言搜索相关文件而不需要你手动提供。MCPModel Context Protocol通过 MCP 服务器AI 可以查询内部文档、读取数据库 schema、调用内部 API 获取数据。终端命令执行部分工具允许 AI 直接跑测试、查 git log、执行 lint 等命令用命令行的输出来校准自己的判断。读取相关文件AI 可以读取与当前文件有引用关系的代码比如从组件文件出发找到它引用的 hooks、utils、类型定义。这一层的关键不是让 AI“能访问”这些信息而是让 AI“知道在什么时候去访问”。我的经验是在项目级规则文件里显式告诉 AI遇到不确定的信息先去查再回答。如果遇到以下情况先自行检索再回答不要凭记忆猜 1. 引用了某个函数但不确定其签名时 2. 需要了解后端接口的请求/响应结构时 3. 项目里已有类似实现时先看看可不可以复用 4. 不确定某个变量的类型定义时这条规则的价值在于它把“AI 该不该去查”这个判断从任务上下文里解放了出来。你不用每次都在任务指令里啰嗦一遍“你先看看这个文件”AI 会自动去做。5.2 给出工具使用的具体边界但是工具链上下文也最容易失控。我见过太多 AI 一言不合就跑去读文件、跑命令结果读了几十个文件上下文完全黑屏它自己也忘了最初要干嘛。所以给 AI 配备工具能力时必须同步设定工具使用的“边界”。我的规则是先查后做但要限时允许 AI 先查相关信息但如果 5 分钟内没有找到关键内容就停下来问我不要自己继续深挖。区分“必读”和“可读”在任务级上下文里明确标注“必读文件xxx”AI 优先读这些其他文件只有在代码报错或逻辑不通时才去读不要主动读。终端命令只读优先允许 AI 跑 git diff、git log、grep 等查询类命令但修改类命令比如自动安装依赖、自动改配置文件必须经过我确认。MCP 查询结果要带来源如果 AI 从数据库 schema 或文档里查到信息要顺手把来源路径贴出来方便我复核。一个小习惯我会在任务指令里写清楚“读文件时优先读和本次任务强相关的文件不要把所有引用链都翻一遍”。就这一句话能省不少 token也能有效避免 AI 在无关文件里越陷越深。5.3 配置一个最小可用方案工具链不是配置得越多越好对个人开发者或小团队来说一个最小可用的配置组合大概是这样工具能力作用建议配置代码索引让 AI 理解仓库结构、找到相关实现打开 Cursor 的索引开关让项目建立 Codebase Index全局规则文件引导 AI 的长期行为习惯根目录维护CLAUDE.md或AGENTS.md自定义命令快速执行测试、lint、类型检查在 Cursor Rules 里配置/check命令跑一遍 test lint特定 MCP 服务根据项目需要接入数据库、文档、Jira不必全接初期只接数据库 schema 和项目 Wiki 两个即可read权限控制防止 AI 乱读文件在规则里写清楚哪些目录可以自由读哪些要先确认这个组合的核心理念是让 AI 有能力查但不给它无限乱查的动力。我曾经见过一个团队给 AI 配了十来个 MCP 服务最后 AI 经常从一个服务跳转到另一个服务光查证就花掉了几万个 token真正写代码的时间所剩无几。工具链越克制效率反而越高。6. 从四层框架到落地一个完整的实战路径6.1 搭建配置的先后顺序如果你正准备在项目里落地这套四层上下文配置我建议你按下面这个顺序来不要一上来就全铺开第一步先定项目级规则文件。这一步是把地基打牢。项目画像、技术栈、目录结构、硬性红线四件事写清楚即可。花一个小时整理能省下未来几十个小时的无效沟通。第二步跑通一个完整的单任务流程。选一个小功能按“会话简报 任务指令 工具链辅助”的方式完整走一遍。看看哪些地方 AI 理解得不好哪些信息你其实忘了提供。这一步会让你发现项目级规则文件的缺口。第三步根据实际反馈迭代规则文件。比如你发现 AI 总是把接口调用写在组件里说明项目级规则文件里“API 调用必须走 request 封装”这条约束不够起眼。可以把它从“规范”区挪到“红线”区并加一句“所有组件内禁止直接调用 api 函数”。第四步逐步增加会话级和工具链配置。等基础流程稳定之后再引入session-notes.md、MCP、自定义命令等高级能力。这样做的好处是每一步你都能清楚地看到收益不会因为一次性配置太多而不知道问题出在哪。6.2 不要把四层做成四座孤岛四层上下文之间不是独立运行的而是形成一个完整的信息流。我的经验是项目级规则文件需要考虑如何和任务级上下文配合。比如我会在项目级规则文件里预留一个“我会在任务指令里写的东内容”的说明。具体来说我会在项目级规则文件里加一段# 如何与本项目协同 当收到一个任务时请先检查任务指令中是否包含“涉及文件”和“验收标准”。如果没有可以在开始前问我确认。在编写代码前请使用代码索引快速定位相关实现必要时读取文件内容。这段看起来很不起眼但它告诉 AI不是只有任务指令本身才算上下文项目规则文件也在协同运作。AI 在工作时会同时参考项目级规则、会话级笔记、任务级指令、工具链结果四者融合后才能真正做到“懂这个项目”。如果其中某一层缺失就会出现典型症状项目级缺失AI 每次都要从头理解技术栈经常写出风格不一致的代码。会话级缺失AI 忘了你之前说过“不要用某个库”或者把已经废弃的方案捡回来。任务级缺失AI 不知道具体改哪个文件凭感觉编写或者改了无关内容。工具链缺失AI 凭记忆写接口、写函数签名经常和真实代码对不上。6.3 一个完整的配置清单我把这套配置整理成一份清单你可以直接打印出来或者放在项目文档里当 checklist 用。层级载体更新频率核心内容项目级CLAUDE.md/AGENTS.md/.cursor/rules低频每周或每迭代项目画像、技术栈、目录结构、编码规范、红线会话级session-notes.md/ 会话开头简报中频每个工作时段当前进度、已知约束、已完成决策任务级每次任务的提示词高频每次交互任务目标、涉及文件、输入输出、验收标准工具链MCP 服务、代码索引、自定义命令低频随项目演进让 AI 具备查询代码、文档、数据的能力这里提醒一点这份清单里的“更新频率”是我个人的经验值不一定适合所有团队。如果你是一个人开发自己的小项目会话级上下文可能一天就过期了如果你在几十人的团队里项目级规则文件可能两周就得评审一次。关键是找到适合自己节奏的频率而不是照搬我的频率。7. 常见问题与排查技巧实录7.1 AI 编码助手“答非所问”时先检查哪层配置AI 答非所问几乎是上下文工程没做好最典型的表现。遇到这种情况我建议你按下面的优先级排查而不要直接去改提示词。第一检查会话级上下文。你是不是新开了一个会话但没提供任何背景信息AI 不知道你在做什么任务自然只能从你那一句话里猜。这是最常见的原因。重新提供会话简报通常能解决一半问题。第二检查任务级上下文。你的任务指令里有没有明确的“涉及文件”和“验收标准”如果只是说“帮我优化一下这个页面”AI 根本不知道你说的“页面”是指哪个文件更不知道“优化”的边界在哪。把任务指令补充完整问题往往就消失了。第三检查项目级规则文件。你有没有在文件里写了自相矛盾的规则比如前面说“禁止使用 Redux”后面又在“技术栈”里提到“Redux 已集成”AI 在冲突的规则面前会展现出一种“随机选择困难症”有时候它听前面的有时候它听后面的结果就是风格不稳定。第四检查工具链能力。AI 是不是在缺少必要信息的情况下硬着头皮编了一个看似合理的答案如果它没权限读数据库 schema、没权限看接口文档它会用训练数据里的通用知识来“猜”。这种情况下你要么给它接入对应的 MCP要么在任务指令里贴出真实 schema。7.2 上下文过载当 AI 开始“遗忘”早期指令另一个高频问题是对话进行到一半你发现 AI 开始不听最早期的指令了比如你明明说过“别动测试文件”它后面却开始改测试了。这不是 AI 故意作对而是上下文被无关信息挤占了。这里有几个常见的原因中间过程里贴了大量无关代码把模型的注意力占满最早的指令被“挤出”了有效记忆范围。MCP 自动检索返回了大量内容占据了上下文窗口导致 AI 对早期指令的关注度下降。你在后续消息里补充了新的但存在冲突的要求AI 优先遵循了最新的消息而无视了旧指令。解决思路是把关键约束放到每个任务指令的开头或结尾而不是只放在会话开头。我在实际工作中如果有一个“绝对不能做”的要求我会在任务指令里重复两遍开头说一遍结尾强调一遍。不是我不信任 AI而是上下文窗口里信息太多重复是确保它不遗忘的最直接手段。同时控制单次对话的信息量。如果一个任务需要讨论的信息特别长我宁可拆成两次任务也不要一次性把所有分析、讨论、代码全塞进一个会话里。保持会话轻量上下文“浓度”才高。7.3 规则文件越改越臃肿怎么办有一位朋友私信我说他的CLAUDE.md已经写到了 4000 多字AI 越来越不听话总是忽略其中某些规则。我一看文件好家伙把项目里遇到的所有历史问题全写进去了从“不要用 var”到“CSS 里禁止使用 important”洋洋洒洒连他自己都分不清哪些规则还适用。项目级规则文件不是“问题血泪史”它应该是“长期行为契约”。如果一条规则只适用于某个历史任务那它就应该随历史一起归档。我自己的维护策略是每两周审查一次项目级规则文件逐条问自己“这条规则如果删了AI 会犯错吗”。如果不会删掉。把“临时但重要”的规则下沉到会话级或任务级上下文不留在项目级文件里。新版规则文件的长度我建议控制在 1500-2500 字之间。太短信息量不足太长AI 会“选择性失明”。7.4 工具链的“万物皆可查”陷阱最后提醒一个工具链层面的坑。很多 AI 编码助手支持 MCP 后你一开心接入了十几个服务——数据库、文档、监控、工单、日历AI 变得无所不知。但实际使用时你的上下文窗口和 AI 的注意力是有限的。每次对话可能只有那么一两个服务真正有用其他服务只会不断返回无关信息把真正的重点稀释掉。我的建议是按需启用服务而不是全部常开。比如本周在开发订单导出功能那就只启用“数据库 schema”和“订单服务文档”这两个 MCP其他全部关掉。等下周做报表需求再切换到报表相关的服务。工具链配置和上下文配置一样都是“少即是多”的哲学。8. 最后分享一点个人体会上下文工程这件事看起来是在调教 AI实际上是在训练自己。以前我写代码时思维是“我自己知道要什么直接写就行”现在和 AI 协作我被迫把自己的思路显式化——为什么要改、改哪里、怎么算改完。这个过程一开始很别扭但时间长了我发现自己写代码前会先想清楚这些问题代码质量反而提升了。我还有一个体会是四层配置不是一次性的“装修”而是持续演化的“维护过程”。你的项目在变AI 工具在变你的需求也在变。规则文件写好了只是第一步定期审视、迭代、修剪才能真正让这套上下文体系保持健康。如果你之前一直觉得 AI 编码助手“也就那样”不妨用这套四层框架重新审视一下自己的用法。很可能你缺的不是更好的模型而是更好的上下文。先试试把项目级规则文件写好再完整的跑一个任务你大概就能感受到区别了。