摘要： 本文解释 Claude Code 长会话为何会出现“越做越偏”：问题通常不是模型突然变笨，而是上下文持续膨胀后，早期约束被大量日志与中间结论稀释；自动压缩又会把细节改写成摘要；未经验证的假设、临时补丁和错误状态随轮次累积，最终让目标、代码与会话记忆脱节。本文适合使用 Claude Code 开发中大型项目的个人开发者和团队。建议继续使用 Claude Code，但不要把“一条无限延长的聊天”当作项目管理系统；应采用任务分段、外部状态文件、验证门禁、主动压缩与适时重开会话。读完后，你可以判断何时该 /compact、何时该 /clear，并建立一套可复用的防跑偏工作流。
核心结论
Claude Code 长会话越做越偏，核心原因是有效上下文质量下降，而不只是上下文长度增加。会话里同时堆积需求、代码、工具输出、失败尝试、旧计划和新决定；模型每轮都要从这些信息中重新判断“现在真正要做什么”。临近上下文阈值时，Claude Code 会通过 auto-compaction 总结较早历史以腾出空间，摘要能保留主线，却不保证保留每一个隐含约束、失败原因和细节。若项目的真实状态没有落到文件、测试和 Git 中，偏差就会被后续操作继续放大。
- Claude Code 仍值得用于长任务，但任务可以长，会话不应无限长。 一个会话最好只承担一个可验收目标。
- 最危险的不是 Token 用完，而是“旧信息仍在、优先级却不清楚”。 已废弃方案、错误日志与临时指令会争夺注意力。
- 自动压缩解决容量问题，不等于解决项目状态管理。 压缩后的摘要可能丢失细粒度约束，因此关键事实必须写进仓库文件。
- 防跑偏最有效的组合是：短任务单元 +
CLAUDE.md稳定规则 +TASK.md当前状态 + 自动测试门禁。 - 发现连续两轮误解、重复修改或测试回退时，应停止追加提示词。 先生成交接摘要，提交或保存检查点，再开新会话。
背景与主要变化
结论先说：所谓“长会话跑偏”通常不是单一 Bug，而是 Agent 工作方式的结构性结果。Claude Code 不只是回答问题，它会读取文件、搜索代码、运行命令、修改多个模块，再根据工具结果决定下一步。每一次工具调用都会把新的证据带入对话，同时也可能带入几百到几万行低价值输出。
Anthropic 官方把 Claude Code 定义为能够读取代码库、编辑文件、运行命令并连接开发工具的 agentic coding tool。官方成本与上下文文档也明确说明：上下文越大，每条消息处理的 Token 越多；接近窗口阈值时会自动压缩较早历史。/usage、/context、状态栏、/compact、/clear 等能力，本质上都在帮助用户管理有限的“工作记忆”，而不是承诺一个会话能永久、无损地保存全部决策。
需要区分三个概念：
| 概念 | 保存的内容 | 主要风险 | 正确用途 |
|---|---|---|---|
| 当前会话上下文 | 对话、工具结果、读取的代码与临时推理线索 | 膨胀、噪声、压缩后细节损失 | 完成当前可验收任务 |
CLAUDE.md / 项目指令 | 团队长期规则、命令、架构约束 | 写得太长、冲突、过时 | 提供稳定且高优先级的项目规范 |
| 仓库状态文件与 Git | 需求、计划、接口、测试结果、变更历史 | 不及时更新会与真实代码脱节 | 作为跨会话的项目事实来源 |
因此，200K 或 1M 上下文并不自动等于“可放心连续开发几十小时”。更大的窗口可以容纳更多材料，却也会容纳更多互相冲突的材料。官方当前文档显示，部分模型或配置可使用扩展上下文，并在接近窗口上限前自动压缩；具体可用模型、阈值和套餐资格会变化，应以 Claude Code 的 /model、/status 和官方模型配置页为准，而不要在团队规范中写死。
想继续了解类似编码工具的实践，可查看 AI Stack Nav 的 Claude Code 教程站内搜索 与 AI Agent 工作流相关文章。
核心功能拆解：偏差是怎样一步步形成的
结论是：跑偏通常由五条链路共同造成，而且会形成正反馈。
1. 指令稀释：真正目标被大量过程信息包围
最初提示可能很清楚：“只修改登录超时，不改变数据库结构，并保持旧 API 兼容。”经过数十轮后，会话里出现探索记录、多个候选方案、测试日志、用户临时纠正和已被否决的建议。模型虽然仍可能“看见”原始要求，却必须判断哪些内容仍有效。当新提示只写“继续”“把剩下的也改了”，任务边界会变得依赖历史推断。
这并不意味着模型随机遗忘，而是相关信息的信噪比下降。越依赖口头约定、越少把验收条件写入文件，风险越高。
2. 压缩损失：摘要保留主线，却可能舍弃隐含条件
官方说明 Claude Code 会在接近上下文窗口时自动压缩历史，也可以手动运行 /compact。压缩必须把长历史转成更短表示，因此它天然是有损过程。诸如“这个失败方案已经试过”“某个兼容性约束只在 Windows 生效”“不要碰用户已有的未提交修改”等细节，如果没有被明确标为关键事实，就可能弱化。
这里要避免一个误区：频繁 /compact 不是万能药。它能降低上下文占用，却不能自动判断什么对你的项目最重要。更可靠的做法是在压缩前先要求 Claude 更新任务状态文件、记录未决问题与验证结果，再执行定向压缩，例如：
/compact 保留：当前目标、不可违反的约束、已修改文件、失败尝试、测试结果、剩余任务和回退方法。3. 错误累积：早期假设未经验证，被当成后续事实
Agent 可能先推断“这个函数没有外部调用”，随后基于该推断重构接口；若没有使用搜索、类型检查和测试验证，后续每一步都会在错误地基上继续建设。长会话中，人容易因为已经投入大量时间而默认之前结论可靠，模型也会继承对话里反复出现的说法。
解决办法不是要求“更仔细”，而是设置证据门槛：任何关于调用关系、兼容性、测试通过或部署成功的结论，都必须对应命令、文件位置或测试输出。
4. 状态漂移：对话中的计划与磁盘上的代码不同步
用户可能手动改文件，另一个分支可能合并变更，格式化工具也可能批量改写代码。若 Claude 继续依赖十轮前读取的内容，就会以旧快照规划新操作。恢复会话也不代表磁盘状态与当时完全一致。因此每个阶段开始前都应重新检查 git status、目标文件和关键测试，而不是只说“从刚才继续”。
5. 工具输出污染：日志、搜索结果和大文件挤占有效注意力
完整构建日志、压缩后的产物、依赖锁文件、生成代码以及过宽的代码搜索，会占用大量上下文，但它们对最终决策的价值很低。Anthropic 官方建议将会淹没主上下文的搜索、日志或文件阅读交给独立 subagent，让主会话只接收摘要。这个建议尤其适合大型仓库研究，但 subagent 的结论仍应经过主任务的测试或源码证据验证。
上述五类问题会形成循环：上下文越乱，计划越模糊；计划越模糊，探索和返工越多；返工产生更多日志和冲突信息；最后再次触发压缩，又进一步减少细节。
适用人群与高风险场景
结论是：单文件、短修复不太容易触发严重漂移；跨模块、跨阶段、带大量工具输出的任务最危险。
| 场景 | 跑偏风险 | 原因 | 推荐会话粒度 |
|---|---|---|---|
| 修复一个可复现 Bug | 低 | 目标与验证方式明确 | 复现、修复、测试可在同一会话 |
| 跨 10 个以上文件重构 | 高 | 接口约束与调用关系复杂 | 研究、设计、分批实现分别验收 |
| 从零开发完整 SaaS | 极高 | 产品需求、架构与 UI 同时变化 | 按里程碑与功能切分会话 |
| 大量日志排障 | 高 | 无关输出迅速占满上下文 | 独立诊断会话或 subagent |
| 数据库迁移与生产部署 | 极高 | 误操作成本高且状态不可只靠对话 | 单独会话、审批、备份与回退门禁 |
| 文档或测试补齐 | 中 | 容易依据过时代码生成 | 每批先重读目标模块并执行验证 |
团队还应关注并行修改：如果多名开发者、多个 worktree 或多个 Agent 同时工作，必须明确文件所有权、分支边界与集成顺序。官方工作流建议使用 Git worktree 隔离并行会话，避免并发编辑相互覆盖。对于付款、删库、生产发布、权限修改和外发消息等高风险操作，必须设置人工审批，不能因为长会话已经建立“信任感”就放宽权限。
安装、配置与防跑偏步骤
结论是：最实用的方案不需要复杂插件，只需把稳定规则、当前状态和验证命令分开保存。
- 建立最小
CLAUDE.md。 只写长期稳定的信息：项目结构、常用命令、代码规范、安全红线和完成定义。不要把每日进度、长篇架构说明或所有 API 文档塞进去。 - 为当前目标建立
TASK.md。 写明目标、非目标、验收条件、已完成项、剩余项、失败尝试和回退方法。每完成一个阶段就更新。 - 先探索，再计划，再修改。 对陌生模块先要求 Claude 只读分析；计划经确认后再编辑，避免探索过程直接产生散乱补丁。
- 设置小型验证门禁。 每一批修改后运行格式化、静态检查、相关单元测试；跨模块变更再运行集成测试。没有证据不得标记完成。
- 控制工具输出。 搜索限定目录与文件类型；测试失败时先保留错误摘要和首个根因，避免反复粘贴整段日志。
- 主动监控上下文。 使用
/context或/usage，也可按官方状态栏文档显示上下文百分比。接近压缩阈值前先更新TASK.md。 - 在正确时机压缩或重开。 同一目标仍在推进且状态清楚时用
/compact；切换到无关任务时用/clear；连续误解、回退或范围变化时先交接，再新开会话。 - 使用 Git 检查点。 在测试通过后提交一个小而清晰的 commit；至少确保
git diff可审查。不要让“聊天记录”成为唯一回退机制。
下面是精简的 CLAUDE.md 示例：
## Project rules
- Package manager: pnpm. Do not use npm or yarn.
- Preserve public API compatibility unless TASK.md explicitly approves a break.
- Never edit generated files under dist/ or coverage/.
- Before completion run: pnpm lint && pnpm test.
- Do not claim a test passed unless the command was executed in this session.
- Ask for approval before database migrations, production deploys, or destructive commands.
## Source of truth
- Current task and acceptance criteria: TASK.md
- Architecture decisions: docs/adr/
- API contract: openapi.yamlTASK.md 可采用下面的结构：
## Goal
修复登录令牌刷新并保持现有 API 响应兼容。
## Non-goals
- 不调整数据库表
- 不更换认证框架
## Acceptance criteria
- 过期前 5 分钟可刷新
- 重放旧 refresh token 被拒绝
- 现有 API contract test 全部通过
## Current state
- [x] 已复现
- [ ] 实现最小修复
- [ ] 单元与契约测试
## Evidence
- 待填写执行命令、结果与 commit这些文件的价值在于让关键状态脱离会话，成为 Claude 与人都能重新读取的外部事实。不过文件也会过时，所以每次接手前仍要与 git diff 和测试结果交叉核验。
实际工作流示例：两小时以上任务如何分段
结论是：把“长会话”改造成“有检查点的长任务”，通常比单纯选择更大上下文模型有效。
假设任务是把一个旧认证模块迁移到新接口，同时保持前端兼容。推荐流程如下：
阶段 A：研究会话
只允许读取与搜索，输出调用图、风险清单、受影响测试和待确认问题。将确认后的结论写入 TASK.md 或架构决策记录。此时不做大规模修改，避免错误理解快速扩散。
阶段 B：实现会话
新会话首先读取 CLAUDE.md、TASK.md、相关接口定义和最新 git status，然后只完成一个最小批次。例如先实现服务端兼容层，不同时改前端、数据库和部署脚本。修改后立即运行局部测试。
阶段 C：验证会话
让独立会话以审查者视角检查 diff、验收条件和安全边界。它不依赖实现过程中的自我解释，更容易发现“代码实现了计划，但计划本身漏项”的问题。之后执行契约测试、集成测试和必要的人工验证。
推荐的交接提示词
在准备 /clear 或开新会话前，可使用：
停止继续修改。请基于当前磁盘状态完成交接：
1. 更新 TASK.md，记录目标、非目标和验收条件；
2. 列出已修改文件及每个文件的目的；
3. 记录已执行测试的准确命令与结果；
4. 记录失败尝试及不要重复的原因；
5. 列出剩余任务、风险和建议的下一步；
6. 检查 git diff，指出任何与任务无关的改动。
不要声称未执行的验证已经通过。新会话启动提示词则应短而可验证：
读取 CLAUDE.md 和 TASK.md，并检查 git status 与 git diff。
先用不超过 10 条要点复述当前目标、不可违反的约束、已完成工作和下一验收点。
发现文件状态与 TASK.md 不一致时先报告，不要直接修改。对比与选型建议
结论是：/compact、/clear、恢复旧会话和 subagent 解决的是不同问题，不能互相替代。
| 方法 | 适合情况 | 优点 | 局限 |
|---|---|---|---|
/compact | 同一目标继续推进，上下文接近阈值 | 保留摘要并腾出空间 | 有损；无法替代外部状态文件 |
/clear | 切换无关任务或旧上下文污染严重 | 获得干净上下文 | 若没有交接文件，会丢失关键进度 |
/resume | 回到一个明确命名的旧任务 | 便于跨时段继续 | 恢复的是会话，磁盘与依赖可能已变化 |
| subagent | 搜索、日志分析、代码库探索会产生大量材料 | 隔离噪声，只返回总结 | 总结仍可能错，必须用源码和测试验证 |
| Git worktree | 多会话或多人并行实现 | 文件与分支隔离清晰 | 最终仍需解决合并与接口冲突 |
| 更大上下文模型 | 必须同时参考大量真实材料 | 减少过早压缩 | 成本与噪声增加，不能保证不跑偏 |
实务选择可以简化为一句话：容量不足用压缩，任务切换用清空，噪声隔离用 subagent，并行编辑用 worktree，项目连续性用仓库内状态文件。 如果团队经常执行相同流程，可使用 Hooks 在工具调用前后执行确定性检查。例如在提交前强制跑 lint，或在 PreCompact 阶段提醒更新状态。官方强调 Hooks 是用户定义的确定性命令；它们适合执行规则，不应把高风险判断完全交给自动脚本。
风险、限制与注意事项
结论是：上述方法能显著降低漂移，却不能保证零错误；最终可靠性来自最小权限、可重复验证和可回退变更。
CLAUDE.md冲突与过载： 规则越多不一定越好。冲突、过时或深层目录中的局部规则会造成不同理解。应定期删除无效规则，并用/status、/doctor等官方诊断方式确认配置。- 自动记忆不是数据库： 官方文档说明项目记忆有加载范围和长度限制，详细主题文件可能按需读取；不要假设任何自动记忆会在所有机器、云环境或 subagent 中完整共享。
- Prompt Injection： 代码注释、网页、issue、日志和 MCP 返回内容都可能包含诱导指令。外部内容应视为不可信数据，不能覆盖项目安全规则。
- 权限过宽： Claude Code 能执行命令和写文件。生产数据库、发布、付款、删除、权限变更必须使用最小权限与人工审批。
- 测试的假阳性： 只跑局部测试可能漏掉跨模块回归；只看 Claude 的总结不等于测试执行。关键发布应保留 CI 日志、构建产物和审查记录。
- 无限循环与重试： Agent 若不断尝试相似补丁，会消耗上下文和预算。对同一错误最多尝试若干次，之后强制回到根因分析或请求人工决定。
- 成本与延迟： 长上下文每轮处理更多 Token。具体套餐额度、模型价格和速率限制会变化，应以官方控制台和文档为准。
- 扩展上下文的错觉： 1M 窗口可以延后压缩，但无法消除矛盾信息、错误假设和旧状态；它是容量选项，不是项目治理方案。
发现以下信号时应立即停止继续编码：Claude 连续两次忘记明确约束；同一文件来回改动；已经通过的测试重新失败；开始修改非目标模块；重复使用已否决方案；无法准确列出当前 diff；或把“计划执行”误报为“已经验证”。此时正确动作是保存证据、更新交接、检查差异并重启上下文，而不是再追加一段更长的纠正提示。
事实依据与来源
本文的官方事实主要来自 Anthropic Claude Code 文档：官方确认 Claude Code 会在接近上下文限制时自动压缩，会话可用 /compact、/clear、/usage 等方式管理；subagent 拥有独立上下文，可隔离大量搜索与日志；Hooks 可在生命周期事件上执行确定性动作；项目指令与自动记忆存在明确的加载规则与范围。
“长会话跑偏由指令稀释、摘要损失、错误累积、状态漂移和工具噪声共同造成”是基于这些机制和 Agent 软件工程实践作出的编辑分析，不是 Anthropic 发布的故障率统计。文中的 TASK.md 模板、两轮误解后重开、按阶段拆分会话和测试门禁属于实施建议，需要结合仓库规模、模型、Claude Code 版本、团队权限和 CI 环境验证。本文未引用第三方 Benchmark，也未声称某种流程能够百分之百消除偏差。
Claude Code 的模型名称、上下文资格、自动压缩阈值、命令行为与套餐可能更新。实际使用前应在当前版本运行 /status、/model、/context 或查阅最新官方文档。
FAQ
Claude Code 长会话跑偏，是不是因为上下文满了？
不完全是。上下文接近上限会触发压缩，确实可能损失细节；但在触发压缩之前，旧计划、失败尝试、日志和临时指令已经可能降低信噪比。真正问题是有效信息的优先级和项目状态没有被可靠外置，而不是单一的 Token 数字。
使用 1M 上下文能彻底解决跑偏吗？
不能。更大上下文能容纳更多代码和历史、减少过早压缩，但也会容纳更多冲突信息和噪声。它适合需要同时参考大量材料的任务；稳定开发仍需要任务切分、状态文件、测试和 Git 检查点。具体 1M 支持范围以最新官方模型配置和账户界面为准。
/compact 应该多久执行一次？
不要按固定分钟数执行。更合理的触发点是一个阶段刚验收完、TASK.md 已更新，并且 /context 或状态栏显示占用较高。若任务已经更换或上下文严重污染，应使用交接加 /clear，而不是反复压缩旧会话。
/clear 后 Claude 会不会忘记项目？
它会清除当前聊天上下文，但项目文件、Git 状态以及按规则加载的 CLAUDE.md 仍然存在。关键进度若只存在聊天里就可能丢失，所以清空前应写入 TASK.md、架构决策、测试结果或 commit。新会话还应重新读取磁盘状态，不要只依赖记忆。
CLAUDE.md 写得越详细越好吗？
不是。它应短、稳定、无冲突，重点放在项目命令、结构、编码规范、安全红线与完成定义。长篇参考资料应放到单独文档，并说明何时读取；每日进度应放在任务状态文件。过长规则本身也会消耗上下文并降低重点。
什么时候适合使用 subagent？
当代码库探索、网页研究、日志分析或测试输出会产生大量一次性材料时适合使用。subagent 在独立上下文工作，只把结论返回主会话，可以减少污染。但它的摘要不是自动可信证据；涉及接口、依赖和安全结论时仍要由主流程查源码或跑测试。
恢复旧会话后可以直接继续改代码吗？
不建议。先检查 git status、git diff、依赖版本、目标文件和 TASK.md。旧会话保存的是当时的对话状态，而仓库可能已被人、脚本、另一个 Agent 或分支修改。两者不一致时，应以当前磁盘证据和已确认需求为准。
如何判断 Claude Code 已经开始跑偏？
常见信号包括：重复问已回答的问题、违反明确非目标、同一处来回改、再次采用失败方案、把未运行的测试说成已通过，以及修改范围持续扩大。出现多个信号时先停止编辑，要求生成基于 git diff 和测试证据的状态报告，再决定压缩或重开。
参考来源
- Anthropic：How Claude remembers your project
- Anthropic：Manage costs effectively（上下文与自动压缩）
- Anthropic：Claude Code model configuration
- Anthropic：Create custom subagents
- Anthropic：Automate actions with hooks
- Anthropic：Claude Code common workflows
- Anthropic：Customize your status line
工具选型与提示词资料
适合阅读工具评测、工具推荐、对比测评类文章后继续转化。
