最近这两个月我几乎把所有能交给 AI 的编码活儿都交给了「context-mode」这套方法来管理。起因很直接我同时用 Cursor 和 Claude Code 写一个多模块的 Go 服务发现 AI 的表现特别不稳定——同一个会话里让它解释一段遗留代码它讲着讲着突然开始改实现让它做代码审查它又忍不住要补测试修一个 panic它先给我上了一堂并发编程课。一开始我以为是模型不够聪明后来反复试才发现问题不在模型在我的上下文压根儿没有模式。所谓 context-mode并不是某个大厂官宣的新框架也不是一个必须装的重型工具。它是一套管理 AI 编程上下文的实践像 Vim 有 Normal 模式、Insert 模式、Visual 模式一样我们每次和 AI 协作时也明确设定一种「模式」——这次是解释、重构、排错还是审查——并把该模式专属的规则、工具和记忆边界一次性交给 AI。这篇文章我会给出完整的目录结构、配置文件示例和一个很小巧的切换脚本照着抄就能用。适合所有重度依赖 AI 辅助写代码、又经常觉得 AI 时聪明时糊涂的工程师。1. 单一上下文模式下AI 为什么会越聊越笨先讲清楚问题根源。很多人以为 AI 表现不稳定是玄学其实背后有几个非常具体的机制在起作用。理解这些机制才能理解 context-mode 为什么有效。1.1 上下文漂移同一个会话里装了太多角色当我们在同一个聊天会话中既问问题、又要改代码、还要查 bug 时模型并不知道当前这条消息应该处于什么状态。LLM 的行为是按 token 预测的它会受前文中所有类似操作的统计规律影响。一个很典型的例子我让 AI「解释一下这个函数的调用关系」它解释到一半开始顺手写出改进方案因为前几轮我让它重构过另一个函数。它以为你还想要同样的输出。这种现象叫上下文漂移。上下文漂移的本质是模型没有显式的角色切换开关它只能靠对话内容去猜。猜自然就容易偏。当对话超过一定长度最新的指令会被前面大量的历史信息稀释模型反而更容易参考较早的「旧任务」而不是「当前任务」。我自己的观察是一旦同一个会话里出现过三到四种不同类型的请求AI 的行为就开始「糊」。你问它问题它默认你想让它写代码你让它写代码它又默认你想让它解释原理。整个对话变成一锅粥输出质量直线下降。1.2 全局规则互相污染现在的 AI 编程工具都支持全局规则比如 Cursor 的 Rules、Claude Code 里的 CLAUDE.md。全局规则的好处是约束统一但副作用也在这里——统一意味着所有任务共享同一套约束。当你的全局规则里写着「所有代码必须带单元测试」时哪怕你只想让 AI 快速定位 panic 的原因它也会在结论里建议你补测试当规则里写着「不要改动非相关代码」时你让它做重构它又会畏手畏脚。规则和规则之间还会打架。写测试的要求和只定位不改动的要求叠加在一起模型很难知道哪个优先。我把这种局面叫作「规则叠加污染」——每加一条规则模型的行为约束就多一层但同时它的判断自由度也低了一层。最终结果就是规则越多AI 越僵硬甚至有些规则在特定模式下完全帮倒忙。1.3 注意力预算被长对话吃光还有一个经常被忽略的点LLM 的上下文窗口不是无限的每个字都会占用计算预算。当你和 AI 聊了两百行之后你的核心诉求「把这个 panic 的根因查出来」可能只占上下文的很小一部分。模型为了保证整体连贯会用「折中」来处理——它既想保留前面的闲聊信息又想满足你当前的需求结果就是两者都没做到位。我做过一个简单的对比实验同样一个 bug 的日志放在一个刚开的新会话里和放在一个已经聊了三千字的旧会话里让 AI 排查新会话的准确率高了一大截。原因很简单新会话里所有注意力都可以集中在当前这个 bug 上而旧会话里模型还要兼顾之前讨论过的十几个话题。这不是模型退化了是上下文里的噪声太多了。1.4 模式不是玄学是一种显式的工作状态设计我们需要的不是「更聪明的模型」而是「更明确的上下文」。Vim 的模式切换之所以高效是因为它把键盘命令在不同的模式里重新定义了——Normal 模式下按 j 是移动Insert 模式下按 j 就是输入字母 j。行为完全由模式决定不需要用户反复解释。context-mode 借鉴的正是这个思路给 AI 设一个显式的工作状态。状态由四部分组成指令头Instruction Header一句话说清楚当前目标相当于系统提示词。规则集Rules当前模式下必须遵守的行为边界。工具集Tools允许 AI 调用哪些能力禁止哪些能力。记忆边界Memory Boundary使用哪个会话、保留哪些历史信息。切换模式就是切换这组配置而不是在同一个对话里靠自然语言去「说服」AI。这个区别非常关键。2. 把上下文拆成可切换的配置单元目录结构与文件格式讲完原理直接上方案。这套方案的落点是一个项目根目录下的.contexts/文件夹里面放若干个模式文件外加一个几十行的 shell 脚本。整体结构非常轻不绑定任何具体工具。2.1 四个核心组成一个都不能少先展开说说四部分到底怎么写因为很多人一上来就把模式文件写成了「角色设定」这是不够的。指令头是模式文件的第一段也是最重要的一段。不要小看这一两句话它是所有规则里权重最高、最不容易被遗忘的部分。写的时候要有明确动词比如「你现在的工作是代码审查不是写代码」而不是「请以审查者的角色帮助我」。明确动词能把模型的注意力拉到一个具体动作上。规则集要控制在 5 到 10 条再多模型根本记不住。每条规则只说一个动作能具体到「不允许修改任何文件」就不要写「保持克制」。规则之间不要有隐含的优先级矛盾否则模型会产生困惑。比如既说「先输出计划」又说「尽快完成改动」模型就不知道该等确认还是直接动手。工具集是最多人忽略的部分。AI 工具的能力是可以收放的Claude Code 里可以拒绝 AI 调用某类工具Cursor 里可以通过设置控制是否允许自动编辑。让排错模式的 AI 只能读文件和跑命令它就不会自作主张改代码了。工具约束比文字规则可靠得多。记忆边界指每个模式尽量使用独立的会话。不要在同一会话里切换模式因为再怎么注入新指令旧的历史还在上下文里它会持续干扰模型。正确的做法是保存当前会话的关键结论开一个新的干净会话在新会话里加载目标模式的规则文件。2.2 一个可以直接抄的目录结构下面是我在项目里实际使用的目录结构.contexts/ global.md # 所有模式公用的极简约束 refactor.md # 重构模式 debug.md # 排错模式 review.md # 代码审查模式 explain.md # 代码解释模式 coding.md # 日常编码模式global.md的内容必须极简只放那些「无论什么模式都必须遵守」的底线规则比如# Global Rules 1. 禁止编造不存在的 API、函数或配置项。 2. 不确定的信息必须明确标注「不确定」。 3. 不要删除用户数据涉及删除操作必须先征求确认。 4. 当全局规则与具体模式规则冲突时以具体模式规则为准。然后是refactor.md的例子# Refactor Mode ## 目标 在不改变外部行为的前提下安全地改进现有代码的结构、可读性和可维护性。 ## 规则 1. 不要一开始就修改任何文件。 2. 先梳理目标模块的输入输出、调用方、依赖关系。 3. 输出重构计划至少包含影响面、改动点、风险评估、验证方式。 4. 只有在收到「开始」或「同意计划」后才动手修改。 5. 每次只重构一个函数或一个文件改完运行该模块的测试。 6. 禁止顺手添加新功能、调整格式、优化无关代码。每个模式文件都遵循同样的结构目标在前规则在后。目标让 AI 知道为什么做规则让 AI 知道边界在哪里。2.3 模式之间的切换到底是切什么这部分需要明确一个容易误解的点模式切换不是在同一会话里加一句话而是「新会话 新规则」两个动作的组合。为什么不能在同一会话里切换因为旧模式的历史仍然存在它会持续影响模型的判断。就算你告诉 AI「现在进入 debug 模式」前面那十几轮 refactor 讨论依然在上下文窗口里占据大量权重模型的行为还是会向重构倾斜。正确的流程是当前会话结束时让 AI 输出一份简短的 SUMMARY把关键结论、待办事项、文件路径写清楚。把 SUMMARY 存入项目里的.ctx-sessions/目录文件名带时间戳。关闭当前会话。用切换到目标模式的命令开一个新会话加载对应模式文件并把之前的关键结论作为第一条消息的一部分带进来。我自己的口诀是切换模式相当于给 AI 换了一个干净的工位桌面上只留当前模式需要的资料。那些用过的草稿收进文件夹而不是铺满整个桌面。2.4 用一份 YAML 管理所有模式模式的元信息可以用 YAML 集中管理这样就能写脚本自动组装 prompt。我用的modes.yaml长这样modes: coding: description: 日常编码模式 instruction_file: .contexts/coding.md tools: [read, edit, test, shell] deny_tools: [] # 无额外禁用 session: fresh # 每次都是新会话 refactor: description: 安全重构模式 instruction_file: .contexts/refactor.md tools: [read, edit, test] deny_tools: [shell_persistent] # 禁止长期 shell 会话 session: fresh debug: description: 排错模式 instruction_file: .contexts/debug.md tools: [read, test, shell] deny_tools: [edit] # 定位阶段不让改代码 session: fresh review: description: 代码审查模式 instruction_file: .contexts/review.md tools: [read] deny_tools: [edit, shell] session: fresh有了这个 YAML切换模式就变成了一个简单的命令操作下一节会给出具体的脚本实现。这套配置的要点是每个模式都对应一个新的会话并且在工具层面就做好了权限隔离。文字规则是软的工具限制是硬的只有两者叠加AI 才很难跑偏。3. 在 Cursor、Claude Code 和无插件环境里落地 context-mode方案设计得再好落不了地就是空谈。这一节讲三种最常见的落地方式Cursor、Claude Code以及一个通用的 shell 脚本方案。三种方式我都在真实项目里用过可以根据自己的工具链选一种。3.1 Cursor用 Rules 做手动挂载而不是自动匹配Cursor 支持.cursor/rules/目录规则文件可以按 glob 自动匹配。但我强烈建议模式类规则不要依赖自动匹配而是每个会话开头手动引用。原因很简单自动匹配规则适合「全场通用」的约定比如「这个目录下的代码禁止使用 fmt 包」它是根据路径触发的但模式需要的是精确隔离。如果同时有五个规则文件匹配当前文件AI 会把五套规则叠加在一起执行这正是我们要避免的规则污染。我现在的做法是.cursor/rules/里只放一个context-mode.mdc内容只有一句话--- description: 使用 context-mode 时必须在会话开头手动引用对应的模式文件 globs: * --- 所有 context-mode 的规则文件都放在 .contexts/ 目录。开始新任务时先 引用对应模式文件例如 .contexts/debug.md并明确说明当前模式。这样每次打开新会话AI 会看到这个提醒然后我在第一条消息里主动引用模式文件.contexts/debug.md 现在进入排错模式请按这个文件里的规则处理问题。手动引用比自动匹配多了一步操作但换来的是模式之间的绝对隔离。这一步非常值得。3.2 Claude CodeCLAUDE.md 保持精简用启动参数注入模式Claude Code 会读取工作目录下的CLAUDE.md作为全局指令。我见过很多人把 CLAUDE.md 越写越长最后 AI 行为变得很怪就是因为全局规则太重。我的做法是CLAUDE.md里只放最基础的团队约定比如语言、编码风格、禁止事项。模式规则完全不进 CLAUDE.md而是放在.contexts/下启动时用参数注入claude --append-system-prompt $(cat .contexts/debug.md)或者如果你的 Claude Code 版本支持/context命令也可以在会话里直接加载模式文件。但更稳妥的方式还是启动时注入因为这样相当于从第一轮起 AI 就知道自己处于什么模式不需要中间切换。需要注意的是启动参数注入的 prompt 和 CLAUDE.md 之间是叠加关系不是互斥关系。所以要遵守一个原则CLAUDE.md 只放「所有模式通用」的内容任何与具体任务相关的规则都放到对应模式文件里。比如「禁止编造 API」适合放全局但「先复现再定位」只适合 debug 模式。3.3 无插件环境写一个 30 行的 ctx 切换脚本如果你不想依赖特定工具或者你平时在终端里用各种 AI 命令行工具一个小脚本就够用了。我把这个脚本命名为ctx放在项目根目录#!/usr/bin/env bash # ctx: context-mode switcher set -euo pipefail CONTEXTS_DIR.contexts MODE${1:-} if [[ -z $MODE ]]; then echo Usage: ctx mode 2 echo Available modes: 2 ls $CONTEXTS_DIR/*.md | sed s#$CONTEXTS_DIR/##; s/\.md// 2 exit 1 fi if [[ ! -f $CONTEXTS_DIR/$MODE.md ]]; then echo Unknown mode: $MODE 2 echo Available modes: 2 ls $CONTEXTS_DIR/*.md | sed s#$CONTEXTS_DIR/##; s/\.md// 2 exit 1 fi mkdir -p .ctx-cache { echo 进入 $MODE 模式先阅读以下规则并严格遵守。 echo cat $CONTEXTS_DIR/global.md echo cat $CONTEXTS_DIR/$MODE.md } ./.ctx-cache/prompt.md echo Switched to mode: $MODE echo Context prompt written to: ./.ctx-cache/prompt.md用法很简单chmod x ctx ./ctx debug脚本会把 global 规则和 debug 模式规则拼接在一起写入.ctx-cache/prompt.md。之后无论你用哪种 AI 工具都可以把prompt.md的内容作为 system prompt或者直接复制到对话第一条消息里。这个脚本虽然简陋但最重要的是它把模式切换这个动作固化成了一条命令你不用每次去翻目录、粘贴规则。磨刀不误砍柴工值得花五分钟把脚本配好。3.4 团队共享把模式文件当作代码来维护当 context-mode 在团队里推广时模式文件就不再是个人偏好了它成了团队和 AI 协作的接口。所以这些文件应该放进 Git 仓库并且像代码一样接受评审。我在团队里的做法是.contexts/目录随仓库提交所有成员使用同一套模式。模式文件的改动走 PR 评审谁觉得 AI 行为不对先提修改意见再改文件。CI 里加一个小检查当.contexts/下的文件被修改时强制在 PR 描述里说明改动原因。这样做的好处是模式文件会随着团队经验不断迭代。一个模式文件调整两三次之后AI 在这个团队里的表现会稳定很多因为规则已经贴合了团队的代码风格和协作习惯。4. 三个真实场景的模式配置全拆解光有框架还不够必须有真实场景做参照。这一节我以 Go 微服务开发为背景拆解三个我高频使用的模式安全重构、定位 panic、代码审查。你会看到同一个 AI在不同模式下的行为差异有多大。4.1 场景A安全重构先计划后动手之前让 AI「帮我整理一下这段代码」它直接把三层循环全改了测试挂了一片。问题在于我给了它一个模糊目标它就用它的方式完成了「整理」而忽略了行为不变这一核心约束。进入 refactor 模式之后情况完全不同。refactor.md 的核心规则是改代码之前必须先给计划等确认后才能动手。实际对话是这样的我把 internal/service/order.go 里那个 HandleOrder 函数重构一下逻辑太长了。AIrefactor 模式我先分析一下影响面。函数调用方有三处api handler、event consumer、scheduler。依赖关系包括 OrderRepository 和 PaymentClient。当前主要问题是 300 行里混合了校验、状态推进和通知发送。我计划拆成三个内部方法validateOrder、advanceStatus、notifyConsumer每个方法单独跑单元测试。这是一个纯内部重构不涉及 API 签名变化风险低。是否开始我开始。AI先提取 validateOrder……测试通过……再提取 advanceStatus……相比之前一口气改完现在虽然多了一次交互但返工率从以前的 40% 降到了 10% 左右。关键是 AI 在动手前已经梳理过影响面不会把调用方的行为也改了。4.2 场景B定位线上 panic先复现再定位排错模式是我觉得价值最大的一个模式。以前我让 AI 查 panic它最喜欢直接给结论而且经常给出看似合理、实则没验证的建议。有一次服务运行时报index out of rangeAI 看着日志里的数组下标直接说「这里需要加锁」。但它根本没看并发路径。真正的原因其实是初始化顺序错误某个配置项在加载前就被消费了和并发一毛钱关系都没有。如果当时直接让它改很可能改坏。debug 模式的规则强制它按证据链工作# Debug Mode ## 目标 定位问题的根本原因而不是快速给出修复。 ## 规则 1. 先读取相关日志、堆栈、配置和最近变更列出关键事实。 2. 只基于已有证据提出假设至少给出一个可执行的验证命令。 3. 在验证通过前不要提出修改代码的方案。 4. 复现步骤必须完整不能只说「跑一下测试」。 5. 定位根因后先总结根因和证据链再询问是否需要修复。进入 debug 模式后AI 的行为变成了AI堆栈显示第十六行索引下标是 12切片长度只有 8。我需要看这里的初始化过程。 我配置在 main.go 里加载。 AI看到了options 是延迟加载的但 Handler 在 LoadConfig 之前就被初始化了。我建议先写一个最小复现测试验证这个初始化顺序问题而不是直接改代码。这就是我想要的排错流程。AI 先复现再给出验证确认后再谈修复。debug 模式下我还通过配置禁用了 edit 工具所以 AI 在定位阶段根本改不了代码只能在命令和读取之间工作。4.3 场景C代码审查输出结构化问题清单代码审查模式解决的是另一个痛点。以前我说「帮我 review 一下这个 PR」AI 会输出一段大杂烩文字从格式问题到架构问题全混在一起反而没人认真看。review 模式把输出格式固定成表格并且强制按严重级别排序# Review Mode ## 目标 对指定代码变更做系统性审查输出结构化问题清单。 ## 规则 1. 按严重级别输出问题Critical、Major、Minor、Nit。 2. 每条问题必须包含文件路径、行号、问题描述、证据引用代码或文档。 3. 不要直接修改代码只做评审。 4. 如果某些问题存在多种修法列出选项并给出推荐但不要替开发者做决定。 5. 没有证据的问题一律标注为「猜测」。实际产出效果类似级别位置问题证据建议Criticalinternal/service/order.go:88错误处理没有回滚状态状态改为 Confirmed 后再次校验失败订单卡死先做状态变更前校验Majorinternal/payment/client.go:45超时时间硬编码 1s生产环境第三方平均耗时 800ms极端情况超时改为可配置Minorapi/handler.go:22未使用 context.WithTimeout函数接收了外层 context 但未设置超时设置调用链超时这个表格让讨论非常有焦点。团队 review 从「各说各话」变成了「先按级别看」Critical 和 Major 优先讨论Minor 和 Nit 合并处理。AI 不会动手改代码它只是提供决策依据这让 review 保持在了「讨论层」。代码审查模式适合在提交 PR 前使用也可以用来审查别人的大改动。4.4 组合与父子模式的取舍有人会问能不能一次既是 debug 又是 refactor我的回答是不要试。让 debug 模式专门找到根因然后把结论带到新的 refactor 会话中。如果你确实需要一贯流程可以在 debug 模式里允许 AI 最后输出一份「修复建议清单」但真正的修改仍然交给 refactor 模式。把任务拆成单模式的好处是职责清晰。AI 每轮只需要干一件事干好一件而不是在解释、定位、修改之间反复横跳。这比让一个「全能模式」处理所有事情要稳定得多。5. 实践中的坑与我现在的工作流最后讲坑。这套方案我从一开始设计得挺复杂后来不断做减法才变成今天这个状态。以下几条是我踩过之后觉得最值得分享的经验。5.1 坑1模式贪多结果自己都忘了切第一次设计 context-mode 时我定义了 8 个模式coding、debug、refactor、review、explain、test、doc、sql。到第 10 天就发现我根本记不住什么时候该用哪个。每次打开终端都在思考「现在该用哪个模式」这本身就成了一种负担。后来我砍到 4 个核心模式阶段模式日常写代码coding解释代码/查问题dig合并了 explain debug质量审查review大范围结构调整refactor原则很简单一周用不到一次的模式就删掉每次使用都要临时加额外规则的模式说明没设计好需要重构这个模式文件本身。模式是给人用的如果人记不住再完美的设计也是空转。5.2 坑2AI 不遵守模式声明怎么办很多人在初期会遇到这种挫败明明在第一条消息里写了「现在进入 refactor 模式」AI 还是直接改了一堆代码。原因是模式规则放在了 system prompt 或启动参数里但对话变长后它对后续每条消息的影响力会衰减。我的解决方案有三个叠加使用在每条用户消息开头加一个简短的[MODE:refactor]标签相当于一个醒目的锚点。重要消息里再次强调最关键的一条约束比如「仍然没有我的确认不要改文件」。利用工具限制比如 debug 模式直接禁用 edit。一个实际的消息例子[MODE:debug] 继续上一次的 panic 排查。这是新的堆栈信息。记住在验证根因之前不要提出任何修改方案。加标签这个动作看起来笨但实测下来 AI 的遵守率确实高了很多。因为它在模型眼里相当于一个持续强化信号每隔几轮就提醒一次当前状态。5.3 坑3全局规则和模式规则打架当global.md里写了「所有新代码必须带测试」而 dig 模式只想定位问题时冲突就会发生。AI 可能会在你让它解释代码的时候额外输出一堆测试建议因为它同时遵守了两套指令。我的对策是给全局规则和模式规则划清界限global.md只放原则性的内容比如「不编造 API」「不确定就查文档」「不删除用户数据」。凡是与具体任务相关的行为约束全部放进模式文件。在global.md末尾明确写一句「当全局规则与模式规则冲突时以模式规则为准。」这样一来全局规则像宪法只管底线模式规则像具体法律管行为。两者不会在细枝末节上纠缠。5.4 我现在的精简三模式工作流经过几轮迭代我目前实际使用的是一套「三模式工作流」配置在三台开发机上保持统一。核心命令是这几个别名alias ctx-codingctx use coding claude --append-system-prompt \\$(cat ./.ctx-cache/prompt.md)\ alias ctx-digctx use dig claude --append-system-prompt \\$(cat ./.ctx-cache/prompt.md)\ alias ctx-reviewctx use review claude --append-system-prompt \\$(cat ./.ctx-cache/prompt.md)\实际工作流是这样的早上打开项目运行ctx-coding开始日常开发。coding 模式允许 AI 读、写、跑测试是一个相对自由的状态。遇到 panic 或者奇怪行为先保存当前会话的关键结论运行ctx-dig开一个干净会话排错。dig 模式里 AI 只能读文件和执行测试不能改代码。排完错把根因和证据链写回项目的错误记录文档再ctx-coding继续正常开发。提交 PR 前运行ctx-review对 diff 做一次结构化审查把问题表格贴到 PR 描述里。这套流程跑了两个月最明显的变化是 AI 的输出稳定性上了一个台阶。同一个模型在 context-mode 的约束下表现接近我预期的时间从「偶尔靠谱」变成了「基本靠谱」。回看整个实践context-mode 解决的本质问题是工作记忆的对齐。以前上下文管理权全部交给了聊天历史模型自己决定该关注什么现在管理权回到了开发者手里每个任务都有明确的模式、规则和边界。这个方法不只适用于 AI 编程做文档、排查线上问题、用 AI 学新框架都可以套用同一套思路先定义模式再开始对话而不是打开对话框就噼里啪啦一顿问。
最近这两个月我几乎把所有能交给 AI 的编码活儿都交给了「context-mode」这套方法来管理。起因很直接我同时用 Cursor 和 Claude Code 写一个多模块的 Go 服务发现 AI 的表现特别不稳定——同一个会话里让它解释一段遗留代码它讲着讲着突然开始改实现让它做代码审查它又忍不住要补测试修一个 panic它先给我上了一堂并发编程课。一开始我以为是模型不够聪明后来反复试才发现问题不在模型在我的上下文压根儿没有模式。所谓 context-mode并不是某个大厂官宣的新框架也不是一个必须装的重型工具。它是一套管理 AI 编程上下文的实践像 Vim 有 Normal 模式、Insert 模式、Visual 模式一样我们每次和 AI 协作时也明确设定一种「模式」——这次是解释、重构、排错还是审查——并把该模式专属的规则、工具和记忆边界一次性交给 AI。这篇文章我会给出完整的目录结构、配置文件示例和一个很小巧的切换脚本照着抄就能用。适合所有重度依赖 AI 辅助写代码、又经常觉得 AI 时聪明时糊涂的工程师。1. 单一上下文模式下AI 为什么会越聊越笨先讲清楚问题根源。很多人以为 AI 表现不稳定是玄学其实背后有几个非常具体的机制在起作用。理解这些机制才能理解 context-mode 为什么有效。1.1 上下文漂移同一个会话里装了太多角色当我们在同一个聊天会话中既问问题、又要改代码、还要查 bug 时模型并不知道当前这条消息应该处于什么状态。LLM 的行为是按 token 预测的它会受前文中所有类似操作的统计规律影响。一个很典型的例子我让 AI「解释一下这个函数的调用关系」它解释到一半开始顺手写出改进方案因为前几轮我让它重构过另一个函数。它以为你还想要同样的输出。这种现象叫上下文漂移。上下文漂移的本质是模型没有显式的角色切换开关它只能靠对话内容去猜。猜自然就容易偏。当对话超过一定长度最新的指令会被前面大量的历史信息稀释模型反而更容易参考较早的「旧任务」而不是「当前任务」。我自己的观察是一旦同一个会话里出现过三到四种不同类型的请求AI 的行为就开始「糊」。你问它问题它默认你想让它写代码你让它写代码它又默认你想让它解释原理。整个对话变成一锅粥输出质量直线下降。1.2 全局规则互相污染现在的 AI 编程工具都支持全局规则比如 Cursor 的 Rules、Claude Code 里的 CLAUDE.md。全局规则的好处是约束统一但副作用也在这里——统一意味着所有任务共享同一套约束。当你的全局规则里写着「所有代码必须带单元测试」时哪怕你只想让 AI 快速定位 panic 的原因它也会在结论里建议你补测试当规则里写着「不要改动非相关代码」时你让它做重构它又会畏手畏脚。规则和规则之间还会打架。写测试的要求和只定位不改动的要求叠加在一起模型很难知道哪个优先。我把这种局面叫作「规则叠加污染」——每加一条规则模型的行为约束就多一层但同时它的判断自由度也低了一层。最终结果就是规则越多AI 越僵硬甚至有些规则在特定模式下完全帮倒忙。1.3 注意力预算被长对话吃光还有一个经常被忽略的点LLM 的上下文窗口不是无限的每个字都会占用计算预算。当你和 AI 聊了两百行之后你的核心诉求「把这个 panic 的根因查出来」可能只占上下文的很小一部分。模型为了保证整体连贯会用「折中」来处理——它既想保留前面的闲聊信息又想满足你当前的需求结果就是两者都没做到位。我做过一个简单的对比实验同样一个 bug 的日志放在一个刚开的新会话里和放在一个已经聊了三千字的旧会话里让 AI 排查新会话的准确率高了一大截。原因很简单新会话里所有注意力都可以集中在当前这个 bug 上而旧会话里模型还要兼顾之前讨论过的十几个话题。这不是模型退化了是上下文里的噪声太多了。1.4 模式不是玄学是一种显式的工作状态设计我们需要的不是「更聪明的模型」而是「更明确的上下文」。Vim 的模式切换之所以高效是因为它把键盘命令在不同的模式里重新定义了——Normal 模式下按 j 是移动Insert 模式下按 j 就是输入字母 j。行为完全由模式决定不需要用户反复解释。context-mode 借鉴的正是这个思路给 AI 设一个显式的工作状态。状态由四部分组成指令头Instruction Header一句话说清楚当前目标相当于系统提示词。规则集Rules当前模式下必须遵守的行为边界。工具集Tools允许 AI 调用哪些能力禁止哪些能力。记忆边界Memory Boundary使用哪个会话、保留哪些历史信息。切换模式就是切换这组配置而不是在同一个对话里靠自然语言去「说服」AI。这个区别非常关键。2. 把上下文拆成可切换的配置单元目录结构与文件格式讲完原理直接上方案。这套方案的落点是一个项目根目录下的.contexts/文件夹里面放若干个模式文件外加一个几十行的 shell 脚本。整体结构非常轻不绑定任何具体工具。2.1 四个核心组成一个都不能少先展开说说四部分到底怎么写因为很多人一上来就把模式文件写成了「角色设定」这是不够的。指令头是模式文件的第一段也是最重要的一段。不要小看这一两句话它是所有规则里权重最高、最不容易被遗忘的部分。写的时候要有明确动词比如「你现在的工作是代码审查不是写代码」而不是「请以审查者的角色帮助我」。明确动词能把模型的注意力拉到一个具体动作上。规则集要控制在 5 到 10 条再多模型根本记不住。每条规则只说一个动作能具体到「不允许修改任何文件」就不要写「保持克制」。规则之间不要有隐含的优先级矛盾否则模型会产生困惑。比如既说「先输出计划」又说「尽快完成改动」模型就不知道该等确认还是直接动手。工具集是最多人忽略的部分。AI 工具的能力是可以收放的Claude Code 里可以拒绝 AI 调用某类工具Cursor 里可以通过设置控制是否允许自动编辑。让排错模式的 AI 只能读文件和跑命令它就不会自作主张改代码了。工具约束比文字规则可靠得多。记忆边界指每个模式尽量使用独立的会话。不要在同一会话里切换模式因为再怎么注入新指令旧的历史还在上下文里它会持续干扰模型。正确的做法是保存当前会话的关键结论开一个新的干净会话在新会话里加载目标模式的规则文件。2.2 一个可以直接抄的目录结构下面是我在项目里实际使用的目录结构.contexts/ global.md # 所有模式公用的极简约束 refactor.md # 重构模式 debug.md # 排错模式 review.md # 代码审查模式 explain.md # 代码解释模式 coding.md # 日常编码模式global.md的内容必须极简只放那些「无论什么模式都必须遵守」的底线规则比如# Global Rules 1. 禁止编造不存在的 API、函数或配置项。 2. 不确定的信息必须明确标注「不确定」。 3. 不要删除用户数据涉及删除操作必须先征求确认。 4. 当全局规则与具体模式规则冲突时以具体模式规则为准。然后是refactor.md的例子# Refactor Mode ## 目标 在不改变外部行为的前提下安全地改进现有代码的结构、可读性和可维护性。 ## 规则 1. 不要一开始就修改任何文件。 2. 先梳理目标模块的输入输出、调用方、依赖关系。 3. 输出重构计划至少包含影响面、改动点、风险评估、验证方式。 4. 只有在收到「开始」或「同意计划」后才动手修改。 5. 每次只重构一个函数或一个文件改完运行该模块的测试。 6. 禁止顺手添加新功能、调整格式、优化无关代码。每个模式文件都遵循同样的结构目标在前规则在后。目标让 AI 知道为什么做规则让 AI 知道边界在哪里。2.3 模式之间的切换到底是切什么这部分需要明确一个容易误解的点模式切换不是在同一会话里加一句话而是「新会话 新规则」两个动作的组合。为什么不能在同一会话里切换因为旧模式的历史仍然存在它会持续影响模型的判断。就算你告诉 AI「现在进入 debug 模式」前面那十几轮 refactor 讨论依然在上下文窗口里占据大量权重模型的行为还是会向重构倾斜。正确的流程是当前会话结束时让 AI 输出一份简短的 SUMMARY把关键结论、待办事项、文件路径写清楚。把 SUMMARY 存入项目里的.ctx-sessions/目录文件名带时间戳。关闭当前会话。用切换到目标模式的命令开一个新会话加载对应模式文件并把之前的关键结论作为第一条消息的一部分带进来。我自己的口诀是切换模式相当于给 AI 换了一个干净的工位桌面上只留当前模式需要的资料。那些用过的草稿收进文件夹而不是铺满整个桌面。2.4 用一份 YAML 管理所有模式模式的元信息可以用 YAML 集中管理这样就能写脚本自动组装 prompt。我用的modes.yaml长这样modes: coding: description: 日常编码模式 instruction_file: .contexts/coding.md tools: [read, edit, test, shell] deny_tools: [] # 无额外禁用 session: fresh # 每次都是新会话 refactor: description: 安全重构模式 instruction_file: .contexts/refactor.md tools: [read, edit, test] deny_tools: [shell_persistent] # 禁止长期 shell 会话 session: fresh debug: description: 排错模式 instruction_file: .contexts/debug.md tools: [read, test, shell] deny_tools: [edit] # 定位阶段不让改代码 session: fresh review: description: 代码审查模式 instruction_file: .contexts/review.md tools: [read] deny_tools: [edit, shell] session: fresh有了这个 YAML切换模式就变成了一个简单的命令操作下一节会给出具体的脚本实现。这套配置的要点是每个模式都对应一个新的会话并且在工具层面就做好了权限隔离。文字规则是软的工具限制是硬的只有两者叠加AI 才很难跑偏。3. 在 Cursor、Claude Code 和无插件环境里落地 context-mode方案设计得再好落不了地就是空谈。这一节讲三种最常见的落地方式Cursor、Claude Code以及一个通用的 shell 脚本方案。三种方式我都在真实项目里用过可以根据自己的工具链选一种。3.1 Cursor用 Rules 做手动挂载而不是自动匹配Cursor 支持.cursor/rules/目录规则文件可以按 glob 自动匹配。但我强烈建议模式类规则不要依赖自动匹配而是每个会话开头手动引用。原因很简单自动匹配规则适合「全场通用」的约定比如「这个目录下的代码禁止使用 fmt 包」它是根据路径触发的但模式需要的是精确隔离。如果同时有五个规则文件匹配当前文件AI 会把五套规则叠加在一起执行这正是我们要避免的规则污染。我现在的做法是.cursor/rules/里只放一个context-mode.mdc内容只有一句话--- description: 使用 context-mode 时必须在会话开头手动引用对应的模式文件 globs: * --- 所有 context-mode 的规则文件都放在 .contexts/ 目录。开始新任务时先 引用对应模式文件例如 .contexts/debug.md并明确说明当前模式。这样每次打开新会话AI 会看到这个提醒然后我在第一条消息里主动引用模式文件.contexts/debug.md 现在进入排错模式请按这个文件里的规则处理问题。手动引用比自动匹配多了一步操作但换来的是模式之间的绝对隔离。这一步非常值得。3.2 Claude CodeCLAUDE.md 保持精简用启动参数注入模式Claude Code 会读取工作目录下的CLAUDE.md作为全局指令。我见过很多人把 CLAUDE.md 越写越长最后 AI 行为变得很怪就是因为全局规则太重。我的做法是CLAUDE.md里只放最基础的团队约定比如语言、编码风格、禁止事项。模式规则完全不进 CLAUDE.md而是放在.contexts/下启动时用参数注入claude --append-system-prompt $(cat .contexts/debug.md)或者如果你的 Claude Code 版本支持/context命令也可以在会话里直接加载模式文件。但更稳妥的方式还是启动时注入因为这样相当于从第一轮起 AI 就知道自己处于什么模式不需要中间切换。需要注意的是启动参数注入的 prompt 和 CLAUDE.md 之间是叠加关系不是互斥关系。所以要遵守一个原则CLAUDE.md 只放「所有模式通用」的内容任何与具体任务相关的规则都放到对应模式文件里。比如「禁止编造 API」适合放全局但「先复现再定位」只适合 debug 模式。3.3 无插件环境写一个 30 行的 ctx 切换脚本如果你不想依赖特定工具或者你平时在终端里用各种 AI 命令行工具一个小脚本就够用了。我把这个脚本命名为ctx放在项目根目录#!/usr/bin/env bash # ctx: context-mode switcher set -euo pipefail CONTEXTS_DIR.contexts MODE${1:-} if [[ -z $MODE ]]; then echo Usage: ctx mode 2 echo Available modes: 2 ls $CONTEXTS_DIR/*.md | sed s#$CONTEXTS_DIR/##; s/\.md// 2 exit 1 fi if [[ ! -f $CONTEXTS_DIR/$MODE.md ]]; then echo Unknown mode: $MODE 2 echo Available modes: 2 ls $CONTEXTS_DIR/*.md | sed s#$CONTEXTS_DIR/##; s/\.md// 2 exit 1 fi mkdir -p .ctx-cache { echo 进入 $MODE 模式先阅读以下规则并严格遵守。 echo cat $CONTEXTS_DIR/global.md echo cat $CONTEXTS_DIR/$MODE.md } ./.ctx-cache/prompt.md echo Switched to mode: $MODE echo Context prompt written to: ./.ctx-cache/prompt.md用法很简单chmod x ctx ./ctx debug脚本会把 global 规则和 debug 模式规则拼接在一起写入.ctx-cache/prompt.md。之后无论你用哪种 AI 工具都可以把prompt.md的内容作为 system prompt或者直接复制到对话第一条消息里。这个脚本虽然简陋但最重要的是它把模式切换这个动作固化成了一条命令你不用每次去翻目录、粘贴规则。磨刀不误砍柴工值得花五分钟把脚本配好。3.4 团队共享把模式文件当作代码来维护当 context-mode 在团队里推广时模式文件就不再是个人偏好了它成了团队和 AI 协作的接口。所以这些文件应该放进 Git 仓库并且像代码一样接受评审。我在团队里的做法是.contexts/目录随仓库提交所有成员使用同一套模式。模式文件的改动走 PR 评审谁觉得 AI 行为不对先提修改意见再改文件。CI 里加一个小检查当.contexts/下的文件被修改时强制在 PR 描述里说明改动原因。这样做的好处是模式文件会随着团队经验不断迭代。一个模式文件调整两三次之后AI 在这个团队里的表现会稳定很多因为规则已经贴合了团队的代码风格和协作习惯。4. 三个真实场景的模式配置全拆解光有框架还不够必须有真实场景做参照。这一节我以 Go 微服务开发为背景拆解三个我高频使用的模式安全重构、定位 panic、代码审查。你会看到同一个 AI在不同模式下的行为差异有多大。4.1 场景A安全重构先计划后动手之前让 AI「帮我整理一下这段代码」它直接把三层循环全改了测试挂了一片。问题在于我给了它一个模糊目标它就用它的方式完成了「整理」而忽略了行为不变这一核心约束。进入 refactor 模式之后情况完全不同。refactor.md 的核心规则是改代码之前必须先给计划等确认后才能动手。实际对话是这样的我把 internal/service/order.go 里那个 HandleOrder 函数重构一下逻辑太长了。AIrefactor 模式我先分析一下影响面。函数调用方有三处api handler、event consumer、scheduler。依赖关系包括 OrderRepository 和 PaymentClient。当前主要问题是 300 行里混合了校验、状态推进和通知发送。我计划拆成三个内部方法validateOrder、advanceStatus、notifyConsumer每个方法单独跑单元测试。这是一个纯内部重构不涉及 API 签名变化风险低。是否开始我开始。AI先提取 validateOrder……测试通过……再提取 advanceStatus……相比之前一口气改完现在虽然多了一次交互但返工率从以前的 40% 降到了 10% 左右。关键是 AI 在动手前已经梳理过影响面不会把调用方的行为也改了。4.2 场景B定位线上 panic先复现再定位排错模式是我觉得价值最大的一个模式。以前我让 AI 查 panic它最喜欢直接给结论而且经常给出看似合理、实则没验证的建议。有一次服务运行时报index out of rangeAI 看着日志里的数组下标直接说「这里需要加锁」。但它根本没看并发路径。真正的原因其实是初始化顺序错误某个配置项在加载前就被消费了和并发一毛钱关系都没有。如果当时直接让它改很可能改坏。debug 模式的规则强制它按证据链工作# Debug Mode ## 目标 定位问题的根本原因而不是快速给出修复。 ## 规则 1. 先读取相关日志、堆栈、配置和最近变更列出关键事实。 2. 只基于已有证据提出假设至少给出一个可执行的验证命令。 3. 在验证通过前不要提出修改代码的方案。 4. 复现步骤必须完整不能只说「跑一下测试」。 5. 定位根因后先总结根因和证据链再询问是否需要修复。进入 debug 模式后AI 的行为变成了AI堆栈显示第十六行索引下标是 12切片长度只有 8。我需要看这里的初始化过程。 我配置在 main.go 里加载。 AI看到了options 是延迟加载的但 Handler 在 LoadConfig 之前就被初始化了。我建议先写一个最小复现测试验证这个初始化顺序问题而不是直接改代码。这就是我想要的排错流程。AI 先复现再给出验证确认后再谈修复。debug 模式下我还通过配置禁用了 edit 工具所以 AI 在定位阶段根本改不了代码只能在命令和读取之间工作。4.3 场景C代码审查输出结构化问题清单代码审查模式解决的是另一个痛点。以前我说「帮我 review 一下这个 PR」AI 会输出一段大杂烩文字从格式问题到架构问题全混在一起反而没人认真看。review 模式把输出格式固定成表格并且强制按严重级别排序# Review Mode ## 目标 对指定代码变更做系统性审查输出结构化问题清单。 ## 规则 1. 按严重级别输出问题Critical、Major、Minor、Nit。 2. 每条问题必须包含文件路径、行号、问题描述、证据引用代码或文档。 3. 不要直接修改代码只做评审。 4. 如果某些问题存在多种修法列出选项并给出推荐但不要替开发者做决定。 5. 没有证据的问题一律标注为「猜测」。实际产出效果类似级别位置问题证据建议Criticalinternal/service/order.go:88错误处理没有回滚状态状态改为 Confirmed 后再次校验失败订单卡死先做状态变更前校验Majorinternal/payment/client.go:45超时时间硬编码 1s生产环境第三方平均耗时 800ms极端情况超时改为可配置Minorapi/handler.go:22未使用 context.WithTimeout函数接收了外层 context 但未设置超时设置调用链超时这个表格让讨论非常有焦点。团队 review 从「各说各话」变成了「先按级别看」Critical 和 Major 优先讨论Minor 和 Nit 合并处理。AI 不会动手改代码它只是提供决策依据这让 review 保持在了「讨论层」。代码审查模式适合在提交 PR 前使用也可以用来审查别人的大改动。4.4 组合与父子模式的取舍有人会问能不能一次既是 debug 又是 refactor我的回答是不要试。让 debug 模式专门找到根因然后把结论带到新的 refactor 会话中。如果你确实需要一贯流程可以在 debug 模式里允许 AI 最后输出一份「修复建议清单」但真正的修改仍然交给 refactor 模式。把任务拆成单模式的好处是职责清晰。AI 每轮只需要干一件事干好一件而不是在解释、定位、修改之间反复横跳。这比让一个「全能模式」处理所有事情要稳定得多。5. 实践中的坑与我现在的工作流最后讲坑。这套方案我从一开始设计得挺复杂后来不断做减法才变成今天这个状态。以下几条是我踩过之后觉得最值得分享的经验。5.1 坑1模式贪多结果自己都忘了切第一次设计 context-mode 时我定义了 8 个模式coding、debug、refactor、review、explain、test、doc、sql。到第 10 天就发现我根本记不住什么时候该用哪个。每次打开终端都在思考「现在该用哪个模式」这本身就成了一种负担。后来我砍到 4 个核心模式阶段模式日常写代码coding解释代码/查问题dig合并了 explain debug质量审查review大范围结构调整refactor原则很简单一周用不到一次的模式就删掉每次使用都要临时加额外规则的模式说明没设计好需要重构这个模式文件本身。模式是给人用的如果人记不住再完美的设计也是空转。5.2 坑2AI 不遵守模式声明怎么办很多人在初期会遇到这种挫败明明在第一条消息里写了「现在进入 refactor 模式」AI 还是直接改了一堆代码。原因是模式规则放在了 system prompt 或启动参数里但对话变长后它对后续每条消息的影响力会衰减。我的解决方案有三个叠加使用在每条用户消息开头加一个简短的[MODE:refactor]标签相当于一个醒目的锚点。重要消息里再次强调最关键的一条约束比如「仍然没有我的确认不要改文件」。利用工具限制比如 debug 模式直接禁用 edit。一个实际的消息例子[MODE:debug] 继续上一次的 panic 排查。这是新的堆栈信息。记住在验证根因之前不要提出任何修改方案。加标签这个动作看起来笨但实测下来 AI 的遵守率确实高了很多。因为它在模型眼里相当于一个持续强化信号每隔几轮就提醒一次当前状态。5.3 坑3全局规则和模式规则打架当global.md里写了「所有新代码必须带测试」而 dig 模式只想定位问题时冲突就会发生。AI 可能会在你让它解释代码的时候额外输出一堆测试建议因为它同时遵守了两套指令。我的对策是给全局规则和模式规则划清界限global.md只放原则性的内容比如「不编造 API」「不确定就查文档」「不删除用户数据」。凡是与具体任务相关的行为约束全部放进模式文件。在global.md末尾明确写一句「当全局规则与模式规则冲突时以模式规则为准。」这样一来全局规则像宪法只管底线模式规则像具体法律管行为。两者不会在细枝末节上纠缠。5.4 我现在的精简三模式工作流经过几轮迭代我目前实际使用的是一套「三模式工作流」配置在三台开发机上保持统一。核心命令是这几个别名alias ctx-codingctx use coding claude --append-system-prompt \\$(cat ./.ctx-cache/prompt.md)\ alias ctx-digctx use dig claude --append-system-prompt \\$(cat ./.ctx-cache/prompt.md)\ alias ctx-reviewctx use review claude --append-system-prompt \\$(cat ./.ctx-cache/prompt.md)\实际工作流是这样的早上打开项目运行ctx-coding开始日常开发。coding 模式允许 AI 读、写、跑测试是一个相对自由的状态。遇到 panic 或者奇怪行为先保存当前会话的关键结论运行ctx-dig开一个干净会话排错。dig 模式里 AI 只能读文件和执行测试不能改代码。排完错把根因和证据链写回项目的错误记录文档再ctx-coding继续正常开发。提交 PR 前运行ctx-review对 diff 做一次结构化审查把问题表格贴到 PR 描述里。这套流程跑了两个月最明显的变化是 AI 的输出稳定性上了一个台阶。同一个模型在 context-mode 的约束下表现接近我预期的时间从「偶尔靠谱」变成了「基本靠谱」。回看整个实践context-mode 解决的本质问题是工作记忆的对齐。以前上下文管理权全部交给了聊天历史模型自己决定该关注什么现在管理权回到了开发者手里每个任务都有明确的模式、规则和边界。这个方法不只适用于 AI 编程做文档、排查线上问题、用 AI 学新框架都可以套用同一套思路先定义模式再开始对话而不是打开对话框就噼里啪啦一顿问。
