上下文漂移
AI 编程对话中错误假设进入上下文后被模型持续叠加，导致错误无声扩散到代码各处的失败模式——不会戏剧性崩溃，只会缓慢漂移
简介
上下文漂移（Context Drift）是 Claude Code 等 AI 编程工具中最隐蔽的失败模式。它不同于明显的编译错误或测试失败——大部分对话不会戏剧性地失败，而是漂移：一个错误假设进入上下文，模型继续往上面叠加，导致错误像涟漪一样扩散到代码各处。
这个概念由 @sairahul1 在描述 7 Agent 软件工厂 方法论时明确提出，作为 Vibe Coding 之所以有天花板的核心原因之一。
核心机制
漂移的典型过程
- 你让 Claude 做”订阅管理”，它设计
User → Subscription - 你后来才想起：订阅属于”公司”，不是”使用者”
- 你只说”不对，订阅属于公司”——Claude 打补丁
- 结果：
user.subscriptionId和company.subscriptionId同时飘在四处 - 后续所有基于这个数据模型的代码都继承了这个混乱
关键特征：错误不是一次性的，而是累积性的。每一次补丁都在错误的地基上加砖，直到整个建筑歪到无法修复。
为什么 AI 不会自动纠正
语言模型的工作方式是”基于上下文做最可能的延续”。当一个错误假设已经进入上下文，模型会把它当作既定事实继续推理——它不会质疑上下文中已有的信息，只会往上面叠加。这是上下文工程要解决的核心问题之一。
与其他概念的关系
与上下文工程的关系
上下文工程 是管理 AI 上下文的系统性方法论（CLAUDE.md、Skill、MCP、memory）。上下文漂移是上下文工程要防御的主要威胁之一。两者的关系是：上下文工程是手段，防控上下文漂移是目标之一。
与 7 Agent 软件工厂的关系
7 Agent 软件工厂 通过 Agent 职责隔离实现了上下文漂移的天然防控——每个 Agent 有独立的上下文窗口，一个 Agent 内的错误假设不会传播到其他 Agent。这是工厂设计的隐性收益：不只是分工效率，更是错误隔离。
不同素材中的观点
@sairahul1 的”无声杀手”分析（来源：2026-05-31-blocktempo-7-agents-software-factory）
原文将上下文漂移定位为 AI 编程的”无声杀手”，核心洞察是：大部分 Claude Code 对话不是戏剧性失败，而是漂移。解决方案分两层：①战术层——小错字直接 inline 修正；②战略层——架构假设错了就丢掉整个对话重新开始，把对的假设烙进第一个 prompt。“一个有正确心智模型的干净对话，永远胜过一个打了补丁的对话”。7 Agent 软件工厂从结构上解决了这个问题：通过 Agent 分工把单一大型对话拆成多个干净的小对话，每个只装相关上下文，漂移被天然限制在单个 Agent 内。
@Sean 的”流程漂移”观察（来源：2026-07-11-woshipm-knowledge-base-engineering-practice）
@Sean 在设计知识库 deep-discuss Skill 时观察到另一种形态的漂移——长流程中的执行漂移：LLM 理解 Skill 里写的流程节点，但不一定严格遵守。比如流程写”先完成证据理解校准，再进入经验共创讨论”，但 LLM 有时校准还没做完就跳到共创；流程要求”先扫描历史卡片，再判断动作类型”，但 LLM 有时会跳过扫描直接写新卡片。他的结论和 @sairahul1 一致：用结构而非提示词治理漂移——@sairahul1 用 Agent 隔离，@Sean 用 准入准出条件（在每两个上下游节点之间加检查点，前一节点”盖章”才放行）。核心洞察是”给 AI 写流程，最难的不是告诉它做什么，而是拦住它不做什么，能力越强漂移的破坏力越大”。两篇素材共同说明：漂移不只发生在 AI 编程的代码假设里，也发生在任何长流程 Agent 工作流的节点推进中。
实用信息
识别上下文漂移的信号
- AI 在做你不预期的事情——不是功能错了，而是设计方向偏了
- 代码里出现了你没要求的变量名或数据结构
- 修复一个问题后又出现新问题，而且新问题看起来”合理但不对”
- 对话越来越长，AI 的回答越来越偏离你的核心需求
防治方法
- 架构级错误：丢掉整个对话，重新开始，在第一个 prompt 里把正确的假设写清楚
- 战术级错误：直接 inline 修正，不需要重启对话
- 预防措施：用 7 Agent 软件工厂 把大对话拆成多个干净的小对话
- 制度措施：把关键假设写入 CLAUDE.md，防止不同会话间的假设漂移
- 黄金法则：当不确定是战术错误还是架构错误时，宁可重新开始——修一个被污染的对话比开始一个干净的对话更耗时