前两天有人把这个情况发我“Claude Code 前十几轮很顺到了后面同一个修复越来越慢是不是它开始不稳了”我先没急着说是模型问题先问了他一句“你是一直在同一个会话里改不同问题吗”这个问题很关键。Anthropic 的说明里其实已经说得很清楚Claude Code 的一轮并不只看你刚才那一句。系统规则、项目说明、历史文件、命令输出都可能继续参与后续判断。所以你觉得“像越聊越累”往往是上下文层面在累积不是模型突然变差。我更愿意把它理解成“背包问题”。你今天要带的工具和文件和昨天那次会话里遗留下来的内容挤在了一起。它会更辛苦体验上就像没加新活却更累。官方还给了一个很实在的提醒第 40 轮仍可能用到前 39 轮的材料并不代表它在盲目重复。有些内容是有用记忆也有些是你不该继续带着走的“旧噪声”。提示缓存可以降低重复成本但缓存有边界缓存也不是每次都像你想象那样稳定。所以先别急着追求更强参数。真正先手的是“背景管理”。把这几点先理一遍很多人会立刻感觉轻松。我给你一个更顺手的开场动作。如果今天只做一个任务先给会话加一个“主题边界”。会话里混了几次不同问题就会出现“本来一个小时能完的拉长到三个小时才停不下来”。/rename可以先把旧线标上名字再把新意图拉进新线这步不复杂但经常是最直接的一刀。再往下是第一件容易被忽略的事。你可能每天都忙着改文件却没先问context。现在/context先看一眼其实很像开工前的简短清点今天必须保留什么、不需要的MCP怎么暂时停用。你不必每次都清到底但不看这一步后面常会被旧背景拖节奏。然后是输入路径。你已经知道文件名时先给它文件名比起先让它到处搜索后面往往少一两轮找来找去。命令输出同理。测试和日志全打“通过”时信息很多却不一定都值得进上下文。能保留失败关键信息和简明摘要的地方尽量别让它每次都吞完整输出。参数这件事也有个节奏。/model、/effort最好开工前定好。中途随时改常常让你以为是会话变乱实际上只是前后策略变了。你把它当成“开局决策”来做会更容易判断哪里真正出问题。最后是离开前的“最后一次收尾”。如果你要离开一阵再回来接着干先/compact。它不是清空而是给会话做个“你知道我还没完成啥”的摘要。你回来时不会先从“它到底记了什么”开始猜能直接接着任务做。做完这些后如果你还觉得慢先按四点回看第一是否把旧任务混进这条会话第二日志是否每轮都刷大量成功项第三是否中途频繁换模型和 effort第四是否长时间后又直接接上同一会话。对应动作也很直接背景混了就先clear要接着干很久就compact输出太吵就先收输出。结尾再说清一点官方给的是方法和边界你的实际体验还会受账号、权限和项目差异影响。先把“背景变轻”这件事做好后面再看哪些环节有没有明显变化。