上个月我在改一个老项目时第一次觉得context-mode这个词开始代表一个必须正视的问题AI 上下文窗口明明已经很大可它偏偏记不住我半小时前让它记住的约束。那是一次颇为典型的翻车我让 AI 按新的接口命名规则重构一个模块改到一半它又开始用旧命名生成新代码。我翻聊天记录发现规则确实在更早的位置写得清清楚楚但它还是“忘了”。后来我把关键上下文单独抽出来重新整理成一种精简、分层、带明确优先级的结构再发过去问题立刻消失。那次之后我开始认真研究“上下文模式”这套做法——也就是给 AI 的输入信息做分层管理按任务需要决定哪些内容全量进入、哪些内容精简进入、哪些内容干脆不进。这就是我这次想分享的context-mode。这个方法不一定只对程序员有用。只要你在用 AI 处理长文档、写报告、做数据分析甚至是在线协作都会遇到同一种尴尬信息越多AI 反而越容易抓错重点。context-mode与其说是一个工具不如说是一套内容组织方式。这篇文章会帮你搞明白它背后的原理给出可以直接套用的格式模板和脚本也把我实际踩过的坑一并列出来。1. 为什么需要 context-modeAI 对话中的“记忆错觉”1.1 一次真实的翻车现场先还原一下当时的环境。项目是一个遗留了差不多五年的内部管理系统前端用 Vue 2后端是 Python 的 Flask。我们要做一次批量重构把所有跟用户状态相关的接口从/api/user/status迁移到/api/v2/account/state并且要求所有新代码不再使用旧的fetchUserStatus函数名。任务不算复杂我直接开了一个新的对话把需求、现有代码路径、接口文档链接都贴给了 AI。前十分钟一切正常AI 生成的代码确实用了新命名。到二十分钟后我要求它继续改另一个相关文件时问题来了它开始生成fetchUserStatus的调用还一本正经地给了一个“保持兼容”的注释。我往回翻发现我最初的需求说明里明确写了“不要使用旧函数名”但那段说明早已经被几十轮问答冲到了很靠后的位置。这其实就是上下文窗口的基础弱点模型能接收的信息总量很大但对不同位置的注意力并不是均匀分布的。中间部分的信息尤其是夹杂在大量代码片段之间的规则很容易被“稀释”。你前几天可能也遇到过类似情况——不是 AI 变笨了而是你没有把它值得关注的东西放到值得关注的位置上。1.2 context-mode 是什么给 AI 的对话内容做“分层管理”context-mode的灵感来自一个很简单的类比收拾行李。把所有东西一股脑塞进箱子找一件小物品要翻半天但如果把证件、衣物、充电线分开放取用效率会高得多。AI 对话也一样把原始资料全部粘进窗口虽然看起来“信息完整”但重点会被冲散。我做了一个之后把所有发给 AI 的内容分为三层骨架层任务目标、硬性约束、最终交付物。这是绝对不能丢的信息。决策层已经拍板的技术方案、命名规范、测试要求、风格偏好。这是为这次任务定下的“法律”。动态层具体的代码片段、日志、报错信息。这些信息只在某个环节需要不需要全程占位置。context-mode强调的就是每次和 AI 对话时先花两分钟把输入内容按这三层重新组织再决定哪些内容以精简摘要形式进入上下文哪些内容通过引用让 AI 在需要时读取哪些内容干脆放到下一次对话。不要觉得麻烦实测下来做好这一步通常能减少三成以上的无效问答。1.3 适合谁用不是只有工程师才需要最开始我以为这套方法只对写代码有用。后来我把同样思路用在了别的地方发现一样有效。如果你是产品经理需要让 AI 帮忙分析一份长访谈记录你可以先告诉 AI“用户最关心的三个问题是以下罗列”而不是直接把 3 万字记录丢进去。如果你是写作者要 AI 续写一章故事你把角色设定、时间线、当前伏笔单独抽出来作为骨架层再让它自由发挥结果通常比“接着上一章继续写”要稳定得多。如果你是数据分析师让 AI 基于一堆报表写结论你最好先给它一个“本次只看收入口径不看成本口径”的决策层说明。所以context-mode不是某个垂直工具的新功能而是一种可以用在任何 AI 对话里的思维框架。接下来的几节我会展开讲我总结的三种核心模式以及把它们落到实操里的具体做法。2. context-mode 的三种核心工作模式2.1 紧凑模式只保留结论、决策和下一步紧凑模式是我最常用的模式适合任务目标明确、改动范围小的场景。它的核心原则是只给 AI 看“决定下来的事情”不给它看“推导这些事情的过程”。举个例子。我要让 AI 为某个 Python 函数补充单元测试之前已经确认过测试必须使用 pytest、必须 mock 掉外部 API、不需要测异常分支。这三条决策就是骨架层。我可以用一段类似于下图的头部信息作为注入开头ctx modecompact goal: 为 utils/price.py 中的 calc_total 函数补充 pytest 单元测试 constraints: - 必须使用 pytest - 所有外部 API 调用必须用 monkeypatch mock - 不测异常分支只测正常路径 scope: - 只修改 tests/test_price.py - 不修改 src 下的任何文件 /ctx这段信息大概一百来个 token但它把最重要的确定性信息都锁定了。AI 在后续生成时即使对话拉得很长也会因为这几行内容位于输入的起始位置而保持较高的注意力权重。我实测过紧凑模式最适合“一次性小任务”比如写一个脚本、补一个配置、生成一封邮件。它的缺点也很明显如果你需要 AI 理解一个复杂业务的前因后果只给结论往往会让它输出“形式上正确但实际不合理”的结果。2.2 追溯模式需要时把历史原样翻出来有时候问题不是出在 AI“记不住”而是我们自己也说不清问题是在哪一步引入的。这时候紧凑模式反而不合适。我会切到追溯模式把历史操作、日志、原始输出作为可回溯的记录但不把它们全部塞进当前上下文而是用 trace-id 这种引用方式让 AI 按需查看。举一个实践过的例子。线上接口偶发超时我怀疑是某个新加的中间件导致的但不确定。我先让 AI 分析当前代码它给出一个初步猜测。接着我把最近十条部署记录、最近二十条错误日志分别打包成两个 trace 文件然后把引用块发给 AIctx modetrace 需要排查的问题POST /api/orders 偶发 5s 超时 已有猜测可能和新增的 auth_middleware 有关 可回溯资料 - 部署记录见 ./traces/deploy.log - 错误日志见 ./traces/error.log - 相关代码见 ./src/middleware/auth.py 请先查看 ./traces/deploy.log 和 ./src/middleware/auth.py 确认时间线后再给出结论。 /ctx因为我没有把 deploy.log 全文贴进去上下文窗口就不会被几千行日志占满。AI 会先根据引用路径做判断如果它能理解就让它基于自己的工具调用去读取文件如果当前对话环境不支持读取本地文件我再用一个tail -n 100把日志最后一百行贴进去。这就是追溯模式的精髓知道“历史记录放在哪”比把历史记录全文背下来更重要。2.3 向导模式分步骤把复杂任务拆给 AI面对复杂任务比如“重构一个模块并且要保证测试全部通过”一次对话很难搞定。如果我把完整需求和一堆约束一次性全给 AI它很容易在某个阶段迷失。向导模式的做法是把任务切成多个 phase每个 phase 只向 AI 展示当前阶段需要的上下文并明确告诉它当前阶段完成后要输出什么。我们用一个实际落地场景来说明。假设我要把旧的用户模块从单体 Flask 路由拆成 service 层ctx modeguide phase: 1/3 goal: 梳理当前路由文件中的所有用户查询逻辑 deliverable: 输出一个函数清单标注每个函数的输入输出和依赖 constraints: - 本轮只做梳理不生成任何新代码 - 只阅读 app/user/routes.py 和 app/user/models.py next_phase_preview: 根据梳理结果设计 service 层接口 /ctx第一轮结束时AI 只会给我一个函数清单。我检查一下清单是否准确然后再进入第二轮把第一轮的结果作为第二轮的骨架层输入。这样做的好处是每一轮的上下文都足够干净AI 不会被前一轮的中间代码干扰。缺点是需要人工参与更多轮次但对于复杂任务这种“可控的笨办法”往往比一口气生成几千行代码最后再来修要靠谱得多。3. 实操把 context-mode 接入我的日常工作流3.1 定义一套轻量的上下文协议光有理念还不够落地上需要一套可复用的格式。我自己用的是一套 Markdown JSON 混合的轻量协议核心文件叫ctx.md放在项目根目录。它包含四个字段goal、decisions、changes、open_questions。# ctx.md ## goal 将用户模块从 Flask 路由中拆分出 service 层保持对外接口返回结构不变。 ## decisions - 使用 repository 模式统一访问数据库。 - service 层只做业务逻辑不直接操作 session。 - 所有接口返回错误时统一用 {code: int, msg: str} 格式。 ## changes - [x] 新建 app/user/repository.py - [ ] 迁移 routes.py 中的查询逻辑到 service.py - [ ] 为 service 层补充单元测试 ## open_questions - 是否需要在 service 层加缓存 - 旧的 admin 页面是否也走新 service 层我为什么用 Markdown 而不是 JSON因为ctx.md的读者不仅有 AI还有我自己和同事。Markdown 里的标题和列表一眼能看出结构即便不经过任何解析工具人也能直接阅读。JSON 结构更严谨但可读性差。如果需要程序处理完全可以写一套解析函数把它转成 JSON。真正重要的是字段名保持固定这样脚本和 AI 都能稳定识别。3.2 写一个自动提取脚本从 git diff 里生成上下文ctx.md维护起来还有个麻烦改动频繁手写容易漏。我给日常项目写了脚本通过读取git diff和git log自动更新changes字段。思路很简单拿到最近一次 commit 与当前工作区的差异提取涉及的文件列表和函数名再存进ctx.md的changes部分。下面是一个可直接改用的 Python 版本import subprocess import json from datetime import datetime REPO_PATH . def run_git(args): result subprocess.run( [git] args, cwdREPO_PATH, capture_outputTrue, textTrue, encodingutf-8 ) return result.stdout.strip() def get_changed_files(): output run_git([diff, --name-only]) files [line for line in output.splitlines() if line] return files def get_latest_commit_message(): output run_git([log, -1, --pretty%s]) return output def build_changes_markdown(): files get_changed_files() if not files: return - 当前工作区没有未提交的变更 lines [] for f in files: suffix [ ] if f.endswith(.py): suffix 待补单元测试 lines.append(f- {suffix} {f}) return \n.join(lines) def update_ctx(): with open(ctx.md, r, encodingutf-8) as fp: content fp.read() changes_body build_changes_markdown() # 简单替换 ## changes 段落 start content.find(## changes) end content.find(## open_questions, start) if start -1 or end -1: return new_changes content[:start] ## changes\n changes_body \n\n content[end:] with open(ctx.md, w, encodingutf-8) as fp: fp.write(new_changes) print(f[{datetime.now().isoformat()}] ctx.md changes updated) if __name__ __main__: update_ctx()目前这个脚本只做了字符串替换适合个人使用。如果你想和别人协作还应该加上文件锁定和冲突处理。实际用起来我习惯每次提交代码前跑一次python update_ctx.py确保ctx.md永远反映最新的工作进度。这样当我开启一段新的 AI 对话时只要让它读取ctx.md就不需要我从聊天记录里翻半天“我们改到哪里了”。3.3 注入策略什么时候全量注入什么时候增量注入有了ctx.md还要决定怎么把它丢给 AI。全部塞进去一定对吗不一定。根据我的观察ctx.md内容多了以后AI 会把它当成背景信息而不是当前任务的指令。所以我用一套简单的注入策略场景注入方式原因项目刚启动AI 不了解背景全量注入ctx.md前 30 行再附上目标字段让 AI 快速建立全局认知已有几轮对话AI 记得目标只注入goal和decisions减少冗余保留核心约束遇到报错需要排查注入changes和最近日志聚焦变化点不重复背景开启新会话延续旧任务先让 AI 阅读ctx.md再补充一个“现状”字段重建状态但不要从零开始这里有个容易被忽略的点AI 对“越靠近上下文开头的指令”遵循得更好。所以我在全量注入时会把goal放在ctx.md的最前部然后才是decisions。如果项目中包含一些很长的模板代码我不会放进ctx.md而是单独存放在需要时告诉 AI “具体写法参考 templates/schema.py不要输出完整模板”。4. 踩坑实录context-mode 使用中的 5 个常见问题4.1 问题一上下文给得太全AI 反而抓不住重点有段时间我为了保险把ctx.md、所有相关需求文档、代码目录树、旧代码片段全部粘贴给 AI。结果它生成出来的方案中规中矩却漏掉了最关键的性能要求——我在文档中段写过“接口必须在 200ms 内返回”但由于这段话周围充斥着别的说明AI 把它当成普通约束没有作为核心设计目标。解决办法是给信息排优先级。我在ctx.md顶部新增了一个critical_reqs字段把“必须”“禁止”“性能阈值”这类硬约束放在这个字段里并且要求 AI 在每次回答前先复述一遍这些约束。你可能会觉得这样有点笨但实测下来这比让它自己“阅读理解”要可靠得多。关键约束的重复率直接和方案正确率挂钩。4.2 问题二切换模式后AI 把之前的状态忘了我在同一段对话里先用了紧凑模式后来又切到追溯模式结果 AI 在追溯模式下完全忘了之前已经讨论出的接口字段。原因是切换模式的命令本身占用了上下文位置而且模式切换后AI 可能会把旧的骨架层理解为已经过期的信息。我的经验是切换模式时一定要在模式标签里附加状态快照。比如切到追溯模式前先写一行“当前状态接口字段已确认见 ctx-state.md”。我通常会在项目里维护一个ctx-state.md记录每次重要讨论后的 checkpoint包括已确认结论、待办、当前分支。切换模式前的状态快照其实就是把ctx-state.md中当前版本的核心信息复制到模式标签中。这样AI 不会因为模式切换而丢失“已经走到哪一步”的认知。4.3 问题三token 预算被模式描述吃掉context-mode如果描述得太啰嗦也会适得其反。我一开始写的模式描述类似“我希望你采用一种紧凑的工作方式在这种方式下你应该优先考虑……”一句话花了 50 个 token但 AI 的理解效果并不比现在这种短格式好。现在我把模式描述压缩成一条短指令比如“只读 ctx.md不读其他代码输出最终结果”。这里我建议你也检查一下自己的指令模板如果模板里有三段以上解释大概率可以精简成一句。token 预算要留给真正有用的内容和 AI 的输出而不是耗在“教它怎么理解模式”这件事上。4.4 问题四多文件项目里引用内容过多追溯模式里我有一次给 AI 列了十几个文件路径希望它能自己定位问题。但那次对话环境里 AI 无法访问文件系统十几个引用路径全都成了无效信息它只能根据文件名猜结果猜错了两处。之后我再遇到多文件引用会先在本地把最相关的内容提取成摘要。例如只把文件中函数定义的开头几行、以及涉及错误的关键段落贴在对话里同时保留文件路径作为索引。这样即便 AI 不能打开文件它也至少有真实代码片段可依据。你这个工具再强如果拿不到源文件内容那就相当于只给了地图却没有实际路况很容易写出与现场不符的答案。4.5 问题五协作场景下别人看不懂你的上下文context-mode如果只给自己用可以非常随意。但如果团队协作别人看到ctx.md里只有寥寥几行可能不知道你为什么决定使用 repository 模式也不会知道open_questions里提到的缓存问题是什么背景。我现在的做法是在ctx.md的每个关键决策后面加一个以why开头的小注释## decisions - 使用 repository 模式统一访问数据库。why: 现有 routes.py 中直接查询 db.session 导致测试困难拆出后 service 层可单测。这么做有两个好处给 AI 额外提供决策依据减少“为什么会这样”的猜测给同事阅读ctx.md提供上下文避免有人在不知情的情况下推翻之前的决定。团队协作场景下ctx.md更像是一份活的架构决策记录而不只是临时提示词。5. 进阶玩法context-mode 与自动化工作流的结合5.1 用 context-mode 写代码评审报告除了编程任务context-mode还能用来做代码评审。过去我让 AI 评审 PR它会泛泛地说“代码风格良好”“逻辑清晰”没什么用。后来我定义了一种“review”模式ctx modereview review_scope: pull request #228 中 app/user/service.py 的变更 focus_points: - 是否有数据库 N1 查询 - 是否有未处理的异常风险 - 是否保持与现有接口返回结构一致 output_format: - 按风险等级列出问题 - 每个问题附上出现的代码行号和修改建议 - 如果没有问题明确说无风险不说“看起来很好” /ctx用了这个模式后AI 的输出从“泛泛而谈”变成了具体的可执行清单。它有风险等级有行号还有修改建议。原因也很简单我把“要检查什么”和“不要说什么废话”都放进了上下文它的注意力自然就被拉到了这几个焦点上。5.2 把 context-mode 做成一个 CLI 小工具如果你每天要用很多次手写ctx标签还是麻烦。我后来写了一个极简易简约的 CLI命名为ct支持三个子命令init生成ctx.mdupdate更新changesset-mode切换模式说明。完整代码不算长核心逻辑可以这样写import argparse import os from pathlib import Path CTX_FIELDS [goal, decisions, changes, open_questions] def cmd_init(args): path Path(args.dir) / ctx.md if path.exists(): print(ctx.md already exists) return content # ctx.md\n\n## goal\n\n\n## decisions\n\n\n## changes\n\n\n## open_questions\n\n path.write_text(content, encodingutf-8) print(fcreated {path}) def cmd_set_mode(args): path Path(args.dir) / ctx.md content path.read_text(encodingutf-8) if path.exists() else mode_tag f\nctx mode\{args.mode}\\n{args.prompt}\n/ctx\n with path.open(a, encodingutf-8) as fp: fp.write(mode_tag) print(fappended mode tag: {args.mode}) parser argparse.ArgumentParser(descriptioncontext-mode helper) sub parser.add_subparsers(destcommand) sub.add_parser(init).add_argument(--dir, default.) s sub.add_parser(set-mode, helpappend a context mode tag) s.add_argument(--mode, requiredTrue, helpcompact/trace/guide/review) s.add_argument(--prompt, requiredTrue) args parser.parse_args() if args.command init: cmd_init(args) elif args.command set-mode: cmd_set_mode(args) else: parser.print_help()你会发现这个工具的核心不是技术而是规范。工具本身只是帮你把context-mode的标签写得更快。真正让 AI 变好用的是你对上下文结构的理解而不是某个神奇的命令。5.3 扩展context-mode 与检索增强的结合前阵子我在测试一个知识库问答场景发现光靠手工维护ctx.md会有点力不从心尤其是当知识库不断更新手动整理决策层会变得繁琐。后来我引入了一种轻量检索把知识库里的文本先按段落切块建立向量索引当用户提问时先检索最相关的几段再把它作为动态层插入到上下文标签里。这仍然是context-mode的思路只是动态层的来源从“手工挑选”变成了“自动检索”。你要注意的是检索回来的内容一样要经过优先级排序不能把所有检索结果都丢进去。我会限制最多返回 3 段每段不超过 200 字。这样既能给 AI 提供新知识又不会污染它的骨架层。将来如果要做更完整的知识问答我觉得可以在这个方向上继续加规则比如对决策层和动态层设置不同的生命周期。回到最初的那个项目我现在每次开新对话前都会问自己三个问题这次任务必须记住什么结论中哪些是已经拍板的哪些历史信息需要“可查”而不是“记住”把这三个问题答完一段清晰的context-mode也就自然浮现在眼前。最后分享一个有点笨但很有效的技巧如果你不确定自己的上下文写得好不好先用不到 150 字把任务目标写成一段话发给 AI让它复述一遍。如果它复述得对再补充约束和决策。这个小测试几乎每次都能帮你提前发现上下文里的模糊点。