有一次我半夜接到线上告警日志里反复冒出ERROR关键字。我熟练地复制报错行去搜索结果一头雾水——单看这一行根本不知道是哪个服务、哪条链路、哪段业务出的问题。后来同事远程丢过来一条命令grep -n -C 5。那是我第一次认真体会context-mode这个东西——它不是什么高深概念而是只看局部时必须把前后语境一起带上这个朴素道理的工程化。这些年我用过的工具里几乎没有哪个叫context-mode的统一点击项但它以各种形态散落在终端、编辑器、编程框架和AI辅助工具中grep的上下文参数、编辑器里粘在窗口顶部的函数名、React的Context、Go的context.Context、AI编程助手的上下文窗口……它们解决的问题都是同一个局部信息如果没有上下文价值就少了一大半。这篇文章我就按自己实际用下来的路径把这几个层面的context-mode拆开讲一遍。前端、后端、运维、以及现在重度依赖AI辅助写代码的朋友应该都能找到点有用的东西。1. 从终端工具开始为什么只看一行永远不够1.1 grep的-C/-B/-A参数context-mode的第一课大多数人在终端里搜日志第一条命令通常是这样的grep -n ERROR app.log然后对着输出里孤零零的一行报错发呆。这行里面可能只有一个异常类名、一个时间戳、一个残缺的消息片段你根本不知道它前面发生了什么、后面有没有堆栈。这时候grep自带的上下文参数就是最朴素的context-mode# -B 是 before显示匹配行之前的若干行 grep -n -B 2 ERROR app.log # -A 是 after显示匹配行之后的若干行 grep -n -A 5 ERROR app.log # 更常用的是 -Ccontext前后各给几行 grep -n -C 5 ERROR app.log我现在几乎不用裸grep因为95%的情况下都需要上下文。前后各5行是我个人最常用的默认值前面能覆盖服务名、请求ID、时间戳所在的日志前缀后面能覆盖一个常见长度堆栈的主体。如果5行不够再加到10行或者20行也行但先在5行这个档位上跑一遍信息密度最合适。1.2 用ripgrep替换grep顺手把context变成默认行为我日常工作里用的是ripgreprg而不是传统grep原因很多这里只说和上下文相关的两点一是rg的默认输出就带颜色二是它的-C参数在扫描大文件时快得几乎没有感知。同样一条搜索命令rg -n -C 3 request_timeout src/在几万行日志里基本毫秒级返回。如果搜的是后端服务的堆日志我一般会直接写别名把context参数固化成肌肉记忆alias rgcrg -n -C 3 alias lgerrrg -n -C 5 --no-heading ERROR|WARN|panic|exception 有了lgerr这个别名之后我连日志grep动作都简化了一个命令直接得到报错行和前后的完整语境。别小看这点改进半夜处理告警的时候少敲几个参数、少一次什么也没搜到的重复尝试心态完全不一样。需要提醒的是context行数并不是越多越好。有一次我搜分布式任务的报错直接把-C 10加上结果一次命中几百个匹配每个匹配前后各10行整个终端刷出上万行关键线索全被淹没了。后来我把策略改成先-C 3快速扫一遍锁定文件和时间段再针对性地-A 20看堆栈。1.3 排查故障时的实际收益一个分布式锁失效的案例说一个让我对context-mode彻底改观的真实案例。某天凌晨服务告警日志里刷了大量ERROR: could not acquire lock。我第一反应是数据库连接池出问题了跑了半天连接数、慢SQL检查毫无收获。把命令换成rg -C 5 could not acquire lock之后前一行清清楚楚地写着INFO: queue_task receivedtask_id...后两行是WARN: duplicate task detectedskip it再往后是ERROR: could not acquire lock。真相和数据库一点关系没有某个调度节点重启后没有释放旧的分布式锁新节点反复抢锁失败同时另一条链路收到重复任务。单看ERROR行方向完全错误带上上下文两分钟定位到锁未释放这个根因。类似的情况在堆栈日志里更常见。很多语言打印异常时光看第一行只知道异常类型真正的根因往往在caused by那一层也就是往后的10到20行。忽略context等于主动丢掉最关键的证据。2. 编辑器里的context-mode让长文件不再迷路2.1 从滚动后我写到哪了说起Sticky Scroll和面包屑写代码和看日志其实有同样的痛点。一个文件超过300行函数嵌套三层以上滚动到中间位置时你常常忘了光标所在代码属于哪个类、哪个方法。这个问题在我维护一个5000行的老模块时尤其明显——每次滚动回来都要往上翻好一阵才想起来噢原来我还在handleRetry里面。VS Code里我把这几个开关全开之后情况改善非常明显{ editor.stickyScroll.enabled: true, editor.stickyScroll.maxLineCount: 5, breadcrumbs.enabled: true, editor.foldingStrategy: auto }stickyScroll就是常说的粘性滚动滚动时当前作用域的类名、方法名会一直贴在编辑器顶部。它的作用本质就是context-mode的图形化——编辑器帮你把我在哪个上下文里这个问题永远保持在视野内。面包屑则是展示当前光标位置的完整路径比如src/service/order.ts OrderService createOrder validateParams点击任意一级都能跳转。2.2 代码折叠调试时只看当前分支的上下文策略另一个我强烈建议养成的习惯是代码折叠。大文件之所以劝退不是因为行数多而是因为视觉上所有代码平等地摊在你面前大脑被迫把当前关心的分支从大量无关代码里挑出来。调试一个具体函数时我的做法是先把整个文件完全折叠只保留函数签名和顶部注释。根据签名判断哪个函数可能是问题所在展开那一个。如果函数还是太长用编辑器折叠到if/for/try块层级只展开当前怀疑的分支。核心快捷键我背得很熟CtrlShift[折叠、CtrlShift]展开、CtrlK Ctrl0全部折叠。一圈操作下来屏幕上只保留两三个关键代码块注意力一下子就集中了。有人觉得把代码折叠一层层展开太折腾不如直接全文阅读。但全文阅读是非常消耗工作记忆的而折叠相当于主动裁剪上下文——只把当下关心的信息留在视野里其他全部收起。这和查看调用栈、查看git blame一样都是按需取上下文的手段。2.3 编辑器可视化全开的信息过载陷阱编辑器厂商提供了很多帮助你看上下文的功能但全开不一定好。我自己试过把缩略图、面包屑、粘性滚动、行号、代码透镜全部打开结果是整个编辑区四面楚歌看哪都花眼。我的取舍原则非常简单用一个表格记录在案功能解决什么问题我现在的开关理由Sticky Scroll滚动时丢失所在函数/作用域开开5行足够不占空间面包屑 Breadcrumbs跳转和查看所属模块路径开信息密度低偶尔点一下缩略图 Minimap快速扫文件结构关看久了眼睛累有折叠就够代码透镜 CodeLens显示引用数、运行测试入口按项目开某些语言下会大量刷屏括号对着色区分嵌套层级开看复杂条件表达式的救星每个人的视觉偏好不一样但核心逻辑是通用的context-mode不是信息越多越好而是和当前任务相关的信息越多、无关的信息越少越好。这和grep的-C 3还是-C 10的选择完全一致。3. 设计模式里的ContextReact和Go给出的两种答案3.1 React Context从props drilling到跨层状态共享在编程框架层面最直接叫Context的前端开发应该第一个想到React的Context API。它的出现是为了解决一个很具体的问题props drilling。假设你的应用有个theme变量从顶层组件传到最底层按钮中间隔着五六层组件。如果每一层都用props传递那么中间层哪怕和主题毫无关系也得在函数签名里写一遍theme、传给子组件。这个过程的痛苦写过三层以上嵌套的人都懂。Context把跨层传递变成了一种显式的模式const ThemeContext createContext(light); function App() { return ( ThemeContext.Provider valuedark Toolbar / /ThemeContext.Provider ); } function Toolbar() { return Button /; } function Button() { const theme useContext(ThemeContext); return button className{theme}OK/button; }Button不再需要通过Toolbar拿theme而是直接从最近的ThemeContext.Provider里读取。这里的Provider就像一个上下文作用域从它包住的组件边界往里所有子组件都可以通过useContext读取到同一个值。这段代码模式本身就是context-mode只是用了声明式的写法。但要特别注意一个使用边界Context不适合存放高频变化的状态。如果一个输入框每次按键都更新Provider的value那么所有消费该Context的组件都会一并重渲染。我试过把一个表单草稿放到Context里管理结果整个页面每次打字都卡后来把状态挪回组件内、只把低频的提交状态放Context才恢复正常。3.2 Go的context.Context超时、取消和链路信息如果说React的Context偏向状态共享的上下文那Go标准库里的context.Context则是完全不同的思路——它负责的是控制流的生命周期。写Go后端时一个HTTP请求从进入handler到查询数据库中间会开多个goroutine。如果客户端断开了、或者整个请求超时了这些goroutine如果感知不到就会继续跑下去甚至造成泄漏。context.Context就是为了让这次请求的结束信号穿透整个调用链而设计的ctx, cancel : context.WithTimeout(r.Context(), 3*time.Second) defer cancel() rows, err : db.QueryContext(ctx, SELECT * FROM orders WHERE user_id ?, uid)这里的关键动作有两个。第一从r.Context()继承父级上下文保证数据库查询的取消信号和HTTP请求绑定在一起第二用WithTimeout给这个查询单独设了3秒的上限。当调用链某一层触发cancel()下游所有感知到这个Context的调用都会收到通知。实际项目里最常见的错误就是自己新造一个context.Background()然后把父级的超时设置丢掉。有一个线上服务超时问题根因就是内部调用没有沿用request.Context()导致上游超时了下游的数据库查询还在傻等锁。这相当于人为切断了上下文链路和日志搜索里只输出一行、不带上文本质上是同一个错误。3.3 我踩过的Context相关坑写在代码里不如写进脑里前面提到了React重渲染和Go超时丢失两个坑还有一类特别典型的发生在Python的上下文管理器。很多人知道用with open(...)但未必意识到contextmanager本身就是语言层面的context-modefrom contextlib import contextmanager contextmanager def db_session_scope(): session create_session() try: yield session session.commit() except Exception: session.rollback() raise finally: session.close() with db_session_scope() as session: session.query(...)这段代码的精髓在于会话的打开、提交、回滚、关闭这些生命周期信息被封装成了with语句的上下文使用者不需要关心前后逻辑。我写过一个支付回调服务最初所有数据库操作都手写session.close()后来发现有两条异常路径忘记关session连接池被打满。切换到上下文管理器之后这类问题在结构上就被杜绝了。这些框架层面的Context讲的其实是同一件事把处于什么环境、什么生命周期阶段、可以访问哪些资源这些隐含信息显式地封装起来要么通过Provider广播要么通过参数传递要么通过with语句圈定边界。命名各异本质相同。4. AI辅助编程里的context-mode新一代开发者的主战场4.1 上下文窗口为什么AI总是忘记你前面的要求这两年用AI辅助编程绕不开一个词上下文窗口。大模型的记忆空间是有限的通常以token数量计量。你可以把它理解成AI同事的工作台你往上面放的信息越多它能同时参考的信息就越多但工作台满了以后最早放上去的东西会被挤掉——表现就是你前面交代过要保留A方案聊了二十轮之后它突然把ABCD全混淆了。很多AI编程工具里都有一种自动读取当前文件的模式这就是工具层面的context-modeAI在生成代码时会先读取当前打开的文件甚至相关文件和编译错误信息用这些作为回答的背景。这个机制开与不开效果差距极大。我试过同样的需求在不开任何上下文的情况下让AI写一个函数它给出的版本用的是完全不同的变量命名和模块边界打开上下文之后它知道我现有的工具函数、命名风格和目录结构生成的代码基本能直接跑。4.2 我维护AI上下文的三条经验用AI写代码越久越觉得上下文维护能力比提示词技巧更重要。下面三条是我真实干活时沉淀下来的。第一每个会话开始前固定写一个四段式上下文模板## 背景 这个模块负责订单状态的流转改动会影响支付回调。 ## 目标 请为 OrderService.refund() 补充一个失败重试逻辑。 ## 约束 - 不改数据库表结构 - 保持现有函数命名风格 - 不在 Controller 层加业务逻辑 ## 验收标准 1. 单测覆盖首次失败和重试成功的路径 2. 重试不超过3次 3. 不引入额外的外部依赖模板本身不复杂但能有效防止AI自由发挥。尤其是约束这一项——没有它AI经常自作主张给你换库、换框架、改公共方法。第二需求变更时宁可新开会话也不要在一个长对话里打补丁。我一开始图省事在同一会话里不断说不对改成这样其实不是这个意思结果AI把早期要求还记在心里生成结果越来越别扭。后来只要需求口径变了我就新开会话把模板重新贴一遍只保留最新口径。说白了新会话等于一个干净的上下文窗口比继续在一个混乱的上下文上堆叠高效得多。第三需要精确改动某个文件时务必把文件和行号手动引进来。以前我以为工具会自动理解我的项目后来发现如果不显式把文件加进上下文AI经常会去猜、去编一个看似存在其实不存在的函数。手动引用一次准确率立竿见影。4.3 上下文污染的代价一次改错模块的翻车实录如果说没上下文是AI蠢那塞了太多不相关上下文就是AI想当然。我有一次让AI重构某个模块的缓存逻辑为了保险把之前查过的另一个旧模块的历史对话也保留着。结果AI把旧模块里已经被废弃的状态机方案混进了新模块的设计里把缓存失效的逻辑写成了状态转移上线后数据不一致回滚了一整轮。复盘下来问题不在于AI能力而在于我给它的上下文里混入了过时的、不相关的信息而它的窗口是有限的有用信息反而被稀释了。这和终端里rg -C 100刷屏导致找不到关键行是同一个原理。从那以后我对AI工具的上下文策略变成需要看的相关文件最多加两三个必须和改动点直接相关。历史讨论、旧的方案设计除非明确需要参考否则一律不带到新会话。每轮生成后如果方向对了我就在上下文里明确写保持这个方向避免它自我推翻。4.4 写给人看的上下文commit、PR、ADR上下文不只是写给AI的更是写给人看的。我评审别人代码的时候最怕看到的commit message就是fix bug或update。它提供的信息量约等于grep输出的一行ERROR——你知道坏了但不知道坏在哪、为什么坏、影响什么。后来我在团队里推了一个简单的commit模板## 背景 队列消费偶尔重复扣款根因是消费后未更新消息状态。 ## 改动 - 消费成功后增加 ACK 回执 - 失败时增加可重试的退避策略 ## 影响范围 仅影响 queue_worker 模块不影响手动退款链路。这个模板本质上就是给人看的context-mode。代码评审、缺陷排查、两三个月后的历史考古靠的全是这些额外记录下来的上下文。更正式的架构决策可以用ADRArchitecture Decision Record沉淀把当时为什么在A和B之间选了A写清楚这些都算是文档形态的上下文。5. 把context-mode固化成一整套日常实践5.1 终端与编辑器两分钟可复制的配置清单我把这些年最顺手的context相关配置放在一起新机器一次配完终端侧alias rgcrg -n -C 3 alias lgerrrg -n -C 5 --no-heading ERROR|WARN|panic|exception alias gitloggit log --oneline --decorate -20VS Code侧{ editor.stickyScroll.enabled: true, editor.stickyScroll.maxLineCount: 5, breadcrumbs.enabled: true, editor.foldingStrategy: auto, editor.guides.bracketPairs: true }Vim/Neovim侧如果编辑器是Vim系折叠命令和sticky scroll没法直接抄但至少要把foldmethodindent设起来set foldmethodindent set foldnestmax35.2 编码时先问一句这一层的Context该归谁管写代码之前我给自己定了个决策表碰到上下文相关需求时照着查场景推荐做法不太推荐前端跨层级共享低频状态React Context / Provider每一层手动传props前端高频变化状态组件内state或专门的状态管理库塞进Context导致全局重渲染后端链路超时/取消Go context.Context 或等效的协程上下文裸调数据库、不传超时参数资源需要安全打开和关闭with语句/上下文管理器手动open/close异常路径容易漏调用下游依赖显式透传请求级Context内部自己造background/root上下文日志、异常排查记录trace_id、request_id、业务唯一键只打一行ERROR没有前后文AI辅助编程每次会话带上背景/约束/验收标准大聊天里反复打补丁上下文混乱这张表不是标准答案但它帮我减少了90%的上下文相关翻车。5.3 给AI用的项目级上下文包如果团队里常驻AI辅助编程我强烈建议在仓库里放一个CONTEXT.md开新会话时让AI先读一遍相当于给AI一个标准上下文注入源# 项目Context ## 技术栈 - 后端Go PostgreSQLORM使用sqlx - 前端React TS状态管理用Zustand - 部署Docker Compose非Kubernetes ## 代码约定 - 错误处理统一返回 AppError不裸抛字符串 - 数据库迁移文件放 ./migrations禁止直接改线上表 - API响应统一结构为 { code, data, message } ## 常见坑 - 支付回调可能重复触发刷新接口必须幂等 - 直播服务依赖Redis重启Redis后任务会重放需检查幂等键 ## 常用命令 - 本地测试make test - 运行服务docker compose up有了这个文件AI生成代码的命中率比裸聊高非常多。它相当于把散落在文档、wiki、老同事脑子的上下文变成一个显式的、可引用的入口。5.4 团队协作中的上下文习惯从个人到组织个人习惯好改团队习惯难养。我观察下来最容易立竿见影的是两件事。第一件所有bug报告和复盘文档里强制填写预期行为和实际行为两块。缺了这两个信息讨论起来全靠猜上下文我也是踩过很多次坑之后才体会到排查问题时候的无效沟通本质上都是上下文没对齐。第二件代码评审的PR描述里除了改了什么必须写为什么这么改。我见过不少PR改动本身质量很高但description只有一句fix issue #123。半年后有人想追溯当时的决策链接又失效就得靠考古。给未来留上下文是成本最低的技术债投资。最后说点个人体会。用过这么多带context字眼的功能和设计模式之后我最大的感受是context-mode并不是某一个工具的专属开关而是一种思维习惯——做任何局部操作之前先确认自己掌握了足够的前后语境同时又要有意识地控制上下文量别让无关信息淹没主线。终端里的-C 5、编辑器里的Sticky Scroll、代码里的Provider、AI会话里的四段式模板本质上是同一个动作在不同场景下的落地。下次看到工具里出现context相关的开关或参数别急着关掉或忽略。先停下来想一想你真正需要的是打开更多上下文还是把当前这些裁剪到恰好够用。这个尺度拿捏得越好开发效率的隐形提升就越大。 
长河君 · 2026/10/28 21:22:35 · 阅读 1.2k 上下文模式：从grep到AI编程的工程实践
有一次我半夜接到线上告警日志里反复冒出ERROR关键字。我熟练地复制报错行去搜索结果一头雾水——单看这一行根本不知道是哪个服务、哪条链路、哪段业务出的问题。后来同事远程丢过来一条命令grep -n -C 5。那是我第一次认真体会context-mode这个东西——它不是什么高深概念而是只看局部时必须把前后语境一起带上这个朴素道理的工程化。这些年我用过的工具里几乎没有哪个叫context-mode的统一点击项但它以各种形态散落在终端、编辑器、编程框架和AI辅助工具中grep的上下文参数、编辑器里粘在窗口顶部的函数名、React的Context、Go的context.Context、AI编程助手的上下文窗口……它们解决的问题都是同一个局部信息如果没有上下文价值就少了一大半。这篇文章我就按自己实际用下来的路径把这几个层面的context-mode拆开讲一遍。前端、后端、运维、以及现在重度依赖AI辅助写代码的朋友应该都能找到点有用的东西。1. 从终端工具开始为什么只看一行永远不够1.1 grep的-C/-B/-A参数context-mode的第一课大多数人在终端里搜日志第一条命令通常是这样的grep -n ERROR app.log然后对着输出里孤零零的一行报错发呆。这行里面可能只有一个异常类名、一个时间戳、一个残缺的消息片段你根本不知道它前面发生了什么、后面有没有堆栈。这时候grep自带的上下文参数就是最朴素的context-mode# -B 是 before显示匹配行之前的若干行 grep -n -B 2 ERROR app.log # -A 是 after显示匹配行之后的若干行 grep -n -A 5 ERROR app.log # 更常用的是 -Ccontext前后各给几行 grep -n -C 5 ERROR app.log我现在几乎不用裸grep因为95%的情况下都需要上下文。前后各5行是我个人最常用的默认值前面能覆盖服务名、请求ID、时间戳所在的日志前缀后面能覆盖一个常见长度堆栈的主体。如果5行不够再加到10行或者20行也行但先在5行这个档位上跑一遍信息密度最合适。1.2 用ripgrep替换grep顺手把context变成默认行为我日常工作里用的是ripgreprg而不是传统grep原因很多这里只说和上下文相关的两点一是rg的默认输出就带颜色二是它的-C参数在扫描大文件时快得几乎没有感知。同样一条搜索命令rg -n -C 3 request_timeout src/在几万行日志里基本毫秒级返回。如果搜的是后端服务的堆日志我一般会直接写别名把context参数固化成肌肉记忆alias rgcrg -n -C 3 alias lgerrrg -n -C 5 --no-heading ERROR|WARN|panic|exception 有了lgerr这个别名之后我连日志grep动作都简化了一个命令直接得到报错行和前后的完整语境。别小看这点改进半夜处理告警的时候少敲几个参数、少一次什么也没搜到的重复尝试心态完全不一样。需要提醒的是context行数并不是越多越好。有一次我搜分布式任务的报错直接把-C 10加上结果一次命中几百个匹配每个匹配前后各10行整个终端刷出上万行关键线索全被淹没了。后来我把策略改成先-C 3快速扫一遍锁定文件和时间段再针对性地-A 20看堆栈。1.3 排查故障时的实际收益一个分布式锁失效的案例说一个让我对context-mode彻底改观的真实案例。某天凌晨服务告警日志里刷了大量ERROR: could not acquire lock。我第一反应是数据库连接池出问题了跑了半天连接数、慢SQL检查毫无收获。把命令换成rg -C 5 could not acquire lock之后前一行清清楚楚地写着INFO: queue_task receivedtask_id...后两行是WARN: duplicate task detectedskip it再往后是ERROR: could not acquire lock。真相和数据库一点关系没有某个调度节点重启后没有释放旧的分布式锁新节点反复抢锁失败同时另一条链路收到重复任务。单看ERROR行方向完全错误带上上下文两分钟定位到锁未释放这个根因。类似的情况在堆栈日志里更常见。很多语言打印异常时光看第一行只知道异常类型真正的根因往往在caused by那一层也就是往后的10到20行。忽略context等于主动丢掉最关键的证据。2. 编辑器里的context-mode让长文件不再迷路2.1 从滚动后我写到哪了说起Sticky Scroll和面包屑写代码和看日志其实有同样的痛点。一个文件超过300行函数嵌套三层以上滚动到中间位置时你常常忘了光标所在代码属于哪个类、哪个方法。这个问题在我维护一个5000行的老模块时尤其明显——每次滚动回来都要往上翻好一阵才想起来噢原来我还在handleRetry里面。VS Code里我把这几个开关全开之后情况改善非常明显{ editor.stickyScroll.enabled: true, editor.stickyScroll.maxLineCount: 5, breadcrumbs.enabled: true, editor.foldingStrategy: auto }stickyScroll就是常说的粘性滚动滚动时当前作用域的类名、方法名会一直贴在编辑器顶部。它的作用本质就是context-mode的图形化——编辑器帮你把我在哪个上下文里这个问题永远保持在视野内。面包屑则是展示当前光标位置的完整路径比如src/service/order.ts OrderService createOrder validateParams点击任意一级都能跳转。2.2 代码折叠调试时只看当前分支的上下文策略另一个我强烈建议养成的习惯是代码折叠。大文件之所以劝退不是因为行数多而是因为视觉上所有代码平等地摊在你面前大脑被迫把当前关心的分支从大量无关代码里挑出来。调试一个具体函数时我的做法是先把整个文件完全折叠只保留函数签名和顶部注释。根据签名判断哪个函数可能是问题所在展开那一个。如果函数还是太长用编辑器折叠到if/for/try块层级只展开当前怀疑的分支。核心快捷键我背得很熟CtrlShift[折叠、CtrlShift]展开、CtrlK Ctrl0全部折叠。一圈操作下来屏幕上只保留两三个关键代码块注意力一下子就集中了。有人觉得把代码折叠一层层展开太折腾不如直接全文阅读。但全文阅读是非常消耗工作记忆的而折叠相当于主动裁剪上下文——只把当下关心的信息留在视野里其他全部收起。这和查看调用栈、查看git blame一样都是按需取上下文的手段。2.3 编辑器可视化全开的信息过载陷阱编辑器厂商提供了很多帮助你看上下文的功能但全开不一定好。我自己试过把缩略图、面包屑、粘性滚动、行号、代码透镜全部打开结果是整个编辑区四面楚歌看哪都花眼。我的取舍原则非常简单用一个表格记录在案功能解决什么问题我现在的开关理由Sticky Scroll滚动时丢失所在函数/作用域开开5行足够不占空间面包屑 Breadcrumbs跳转和查看所属模块路径开信息密度低偶尔点一下缩略图 Minimap快速扫文件结构关看久了眼睛累有折叠就够代码透镜 CodeLens显示引用数、运行测试入口按项目开某些语言下会大量刷屏括号对着色区分嵌套层级开看复杂条件表达式的救星每个人的视觉偏好不一样但核心逻辑是通用的context-mode不是信息越多越好而是和当前任务相关的信息越多、无关的信息越少越好。这和grep的-C 3还是-C 10的选择完全一致。3. 设计模式里的ContextReact和Go给出的两种答案3.1 React Context从props drilling到跨层状态共享在编程框架层面最直接叫Context的前端开发应该第一个想到React的Context API。它的出现是为了解决一个很具体的问题props drilling。假设你的应用有个theme变量从顶层组件传到最底层按钮中间隔着五六层组件。如果每一层都用props传递那么中间层哪怕和主题毫无关系也得在函数签名里写一遍theme、传给子组件。这个过程的痛苦写过三层以上嵌套的人都懂。Context把跨层传递变成了一种显式的模式const ThemeContext createContext(light); function App() { return ( ThemeContext.Provider valuedark Toolbar / /ThemeContext.Provider ); } function Toolbar() { return Button /; } function Button() { const theme useContext(ThemeContext); return button className{theme}OK/button; }Button不再需要通过Toolbar拿theme而是直接从最近的ThemeContext.Provider里读取。这里的Provider就像一个上下文作用域从它包住的组件边界往里所有子组件都可以通过useContext读取到同一个值。这段代码模式本身就是context-mode只是用了声明式的写法。但要特别注意一个使用边界Context不适合存放高频变化的状态。如果一个输入框每次按键都更新Provider的value那么所有消费该Context的组件都会一并重渲染。我试过把一个表单草稿放到Context里管理结果整个页面每次打字都卡后来把状态挪回组件内、只把低频的提交状态放Context才恢复正常。3.2 Go的context.Context超时、取消和链路信息如果说React的Context偏向状态共享的上下文那Go标准库里的context.Context则是完全不同的思路——它负责的是控制流的生命周期。写Go后端时一个HTTP请求从进入handler到查询数据库中间会开多个goroutine。如果客户端断开了、或者整个请求超时了这些goroutine如果感知不到就会继续跑下去甚至造成泄漏。context.Context就是为了让这次请求的结束信号穿透整个调用链而设计的ctx, cancel : context.WithTimeout(r.Context(), 3*time.Second) defer cancel() rows, err : db.QueryContext(ctx, SELECT * FROM orders WHERE user_id ?, uid)这里的关键动作有两个。第一从r.Context()继承父级上下文保证数据库查询的取消信号和HTTP请求绑定在一起第二用WithTimeout给这个查询单独设了3秒的上限。当调用链某一层触发cancel()下游所有感知到这个Context的调用都会收到通知。实际项目里最常见的错误就是自己新造一个context.Background()然后把父级的超时设置丢掉。有一个线上服务超时问题根因就是内部调用没有沿用request.Context()导致上游超时了下游的数据库查询还在傻等锁。这相当于人为切断了上下文链路和日志搜索里只输出一行、不带上文本质上是同一个错误。3.3 我踩过的Context相关坑写在代码里不如写进脑里前面提到了React重渲染和Go超时丢失两个坑还有一类特别典型的发生在Python的上下文管理器。很多人知道用with open(...)但未必意识到contextmanager本身就是语言层面的context-modefrom contextlib import contextmanager contextmanager def db_session_scope(): session create_session() try: yield session session.commit() except Exception: session.rollback() raise finally: session.close() with db_session_scope() as session: session.query(...)这段代码的精髓在于会话的打开、提交、回滚、关闭这些生命周期信息被封装成了with语句的上下文使用者不需要关心前后逻辑。我写过一个支付回调服务最初所有数据库操作都手写session.close()后来发现有两条异常路径忘记关session连接池被打满。切换到上下文管理器之后这类问题在结构上就被杜绝了。这些框架层面的Context讲的其实是同一件事把处于什么环境、什么生命周期阶段、可以访问哪些资源这些隐含信息显式地封装起来要么通过Provider广播要么通过参数传递要么通过with语句圈定边界。命名各异本质相同。4. AI辅助编程里的context-mode新一代开发者的主战场4.1 上下文窗口为什么AI总是忘记你前面的要求这两年用AI辅助编程绕不开一个词上下文窗口。大模型的记忆空间是有限的通常以token数量计量。你可以把它理解成AI同事的工作台你往上面放的信息越多它能同时参考的信息就越多但工作台满了以后最早放上去的东西会被挤掉——表现就是你前面交代过要保留A方案聊了二十轮之后它突然把ABCD全混淆了。很多AI编程工具里都有一种自动读取当前文件的模式这就是工具层面的context-modeAI在生成代码时会先读取当前打开的文件甚至相关文件和编译错误信息用这些作为回答的背景。这个机制开与不开效果差距极大。我试过同样的需求在不开任何上下文的情况下让AI写一个函数它给出的版本用的是完全不同的变量命名和模块边界打开上下文之后它知道我现有的工具函数、命名风格和目录结构生成的代码基本能直接跑。4.2 我维护AI上下文的三条经验用AI写代码越久越觉得上下文维护能力比提示词技巧更重要。下面三条是我真实干活时沉淀下来的。第一每个会话开始前固定写一个四段式上下文模板## 背景 这个模块负责订单状态的流转改动会影响支付回调。 ## 目标 请为 OrderService.refund() 补充一个失败重试逻辑。 ## 约束 - 不改数据库表结构 - 保持现有函数命名风格 - 不在 Controller 层加业务逻辑 ## 验收标准 1. 单测覆盖首次失败和重试成功的路径 2. 重试不超过3次 3. 不引入额外的外部依赖模板本身不复杂但能有效防止AI自由发挥。尤其是约束这一项——没有它AI经常自作主张给你换库、换框架、改公共方法。第二需求变更时宁可新开会话也不要在一个长对话里打补丁。我一开始图省事在同一会话里不断说不对改成这样其实不是这个意思结果AI把早期要求还记在心里生成结果越来越别扭。后来只要需求口径变了我就新开会话把模板重新贴一遍只保留最新口径。说白了新会话等于一个干净的上下文窗口比继续在一个混乱的上下文上堆叠高效得多。第三需要精确改动某个文件时务必把文件和行号手动引进来。以前我以为工具会自动理解我的项目后来发现如果不显式把文件加进上下文AI经常会去猜、去编一个看似存在其实不存在的函数。手动引用一次准确率立竿见影。4.3 上下文污染的代价一次改错模块的翻车实录如果说没上下文是AI蠢那塞了太多不相关上下文就是AI想当然。我有一次让AI重构某个模块的缓存逻辑为了保险把之前查过的另一个旧模块的历史对话也保留着。结果AI把旧模块里已经被废弃的状态机方案混进了新模块的设计里把缓存失效的逻辑写成了状态转移上线后数据不一致回滚了一整轮。复盘下来问题不在于AI能力而在于我给它的上下文里混入了过时的、不相关的信息而它的窗口是有限的有用信息反而被稀释了。这和终端里rg -C 100刷屏导致找不到关键行是同一个原理。从那以后我对AI工具的上下文策略变成需要看的相关文件最多加两三个必须和改动点直接相关。历史讨论、旧的方案设计除非明确需要参考否则一律不带到新会话。每轮生成后如果方向对了我就在上下文里明确写保持这个方向避免它自我推翻。4.4 写给人看的上下文commit、PR、ADR上下文不只是写给AI的更是写给人看的。我评审别人代码的时候最怕看到的commit message就是fix bug或update。它提供的信息量约等于grep输出的一行ERROR——你知道坏了但不知道坏在哪、为什么坏、影响什么。后来我在团队里推了一个简单的commit模板## 背景 队列消费偶尔重复扣款根因是消费后未更新消息状态。 ## 改动 - 消费成功后增加 ACK 回执 - 失败时增加可重试的退避策略 ## 影响范围 仅影响 queue_worker 模块不影响手动退款链路。这个模板本质上就是给人看的context-mode。代码评审、缺陷排查、两三个月后的历史考古靠的全是这些额外记录下来的上下文。更正式的架构决策可以用ADRArchitecture Decision Record沉淀把当时为什么在A和B之间选了A写清楚这些都算是文档形态的上下文。5. 把context-mode固化成一整套日常实践5.1 终端与编辑器两分钟可复制的配置清单我把这些年最顺手的context相关配置放在一起新机器一次配完终端侧alias rgcrg -n -C 3 alias lgerrrg -n -C 5 --no-heading ERROR|WARN|panic|exception alias gitloggit log --oneline --decorate -20VS Code侧{ editor.stickyScroll.enabled: true, editor.stickyScroll.maxLineCount: 5, breadcrumbs.enabled: true, editor.foldingStrategy: auto, editor.guides.bracketPairs: true }Vim/Neovim侧如果编辑器是Vim系折叠命令和sticky scroll没法直接抄但至少要把foldmethodindent设起来set foldmethodindent set foldnestmax35.2 编码时先问一句这一层的Context该归谁管写代码之前我给自己定了个决策表碰到上下文相关需求时照着查场景推荐做法不太推荐前端跨层级共享低频状态React Context / Provider每一层手动传props前端高频变化状态组件内state或专门的状态管理库塞进Context导致全局重渲染后端链路超时/取消Go context.Context 或等效的协程上下文裸调数据库、不传超时参数资源需要安全打开和关闭with语句/上下文管理器手动open/close异常路径容易漏调用下游依赖显式透传请求级Context内部自己造background/root上下文日志、异常排查记录trace_id、request_id、业务唯一键只打一行ERROR没有前后文AI辅助编程每次会话带上背景/约束/验收标准大聊天里反复打补丁上下文混乱这张表不是标准答案但它帮我减少了90%的上下文相关翻车。5.3 给AI用的项目级上下文包如果团队里常驻AI辅助编程我强烈建议在仓库里放一个CONTEXT.md开新会话时让AI先读一遍相当于给AI一个标准上下文注入源# 项目Context ## 技术栈 - 后端Go PostgreSQLORM使用sqlx - 前端React TS状态管理用Zustand - 部署Docker Compose非Kubernetes ## 代码约定 - 错误处理统一返回 AppError不裸抛字符串 - 数据库迁移文件放 ./migrations禁止直接改线上表 - API响应统一结构为 { code, data, message } ## 常见坑 - 支付回调可能重复触发刷新接口必须幂等 - 直播服务依赖Redis重启Redis后任务会重放需检查幂等键 ## 常用命令 - 本地测试make test - 运行服务docker compose up有了这个文件AI生成代码的命中率比裸聊高非常多。它相当于把散落在文档、wiki、老同事脑子的上下文变成一个显式的、可引用的入口。5.4 团队协作中的上下文习惯从个人到组织个人习惯好改团队习惯难养。我观察下来最容易立竿见影的是两件事。第一件所有bug报告和复盘文档里强制填写预期行为和实际行为两块。缺了这两个信息讨论起来全靠猜上下文我也是踩过很多次坑之后才体会到排查问题时候的无效沟通本质上都是上下文没对齐。第二件代码评审的PR描述里除了改了什么必须写为什么这么改。我见过不少PR改动本身质量很高但description只有一句fix issue #123。半年后有人想追溯当时的决策链接又失效就得靠考古。给未来留上下文是成本最低的技术债投资。最后说点个人体会。用过这么多带context字眼的功能和设计模式之后我最大的感受是context-mode并不是某一个工具的专属开关而是一种思维习惯——做任何局部操作之前先确认自己掌握了足够的前后语境同时又要有意识地控制上下文量别让无关信息淹没主线。终端里的-C 5、编辑器里的Sticky Scroll、代码里的Provider、AI会话里的四段式模板本质上是同一个动作在不同场景下的落地。下次看到工具里出现context相关的开关或参数别急着关掉或忽略。先停下来想一想你真正需要的是打开更多上下文还是把当前这些裁剪到恰好够用。这个尺度拿捏得越好开发效率的隐形提升就越大。