Claude Code 响应慢怎么办？提速的5个技巧

我测过。同样的 Prompt发给它两次。一次 8 秒出结果一次等了 47 秒。网络没动VPN 没换什么都没变。后来我才搞清楚Claude Code 的响应速度70% 取决于你喂给它多少上下文。不是带宽不是服务器是你自己。慢但你不知道慢在哪用 Claude Code 开发时间成本里有一块很隐蔽的损耗等待。不是那种卡死不动的等待是那种感觉快好了但就是没好的等待。每次等个 30 到 60 秒一天下来可能积累了 40 分钟什么都没干。我自己记录过一周的使用数据在一个 Next.js 项目里平均单次响应时间是 34 秒。其中有几次超过 90 秒。那几次发生的共同点是我在一个对话里已经来回了超过 20 轮而且每次都附带了完整的报错信息和代码片段。说人话就是对话越长、单次喂的内容越多它就越慢。不是偶然是必然。原因在于模型处理请求时要先消化整个上下文窗口里的所有内容才开始生成回答。上下文越大消化时间越长。这不是 Claude 独有的问题是所有大语言模型的共性。但 Claude Code 因为会自动读入项目文件上下文膨胀得特别快。以下是我摸索出来的 5 个实际有效的方法。技巧一对话超过 15 轮立刻开新会话这是最有效、最反直觉的一条。很多人以为同一个对话里保留越多历史Claude Code 越了解你的项目回答越准确。错。超过一定长度历史对话反而成了负担。它需要花更多算力处理那些可能已经没有参考价值的早期信息而不是集中在你现在的问题上。我的做法是以任务为单位开会话而不是以项目为单位。做完认证模块关掉新开一个会话做支付模块。不要在同一个对话里跨越太多功能边界。开新会话之前花两分钟写一段交接摘要喂给它上下文我在开发一个 SaaS 订阅工具Next.js 14 Prisma Stripe。认证模块已完成用 NextAuth v5Session 里有 userId 和 subscriptionStatus 两个字段。当前任务接入 Stripe Checkout用户点击升级按钮后跳转到 Stripe 支付页面支付成功后更新数据库里的 subscription 状态。相关文件app/api/payment/create-checkout/route.ts还没写lib/stripe.ts已有 Stripe client 初始化两分钟写这段换来后续更快的响应和更准确的输出。这个账很合算。技巧二报错信息只贴关键部分不要全量粘贴这个坑我踩了很久才发现。遇到报错我之前的习惯是把整个 Terminal 输出全部复制进去——可能有 200 行。我以为信息越全越好。实际上大多数报错的关键信息就在前 10 行和最后 5 行。中间那 185 行是 stack trace对找问题帮助不大但会让上下文膨胀一大块。正确做法只贴错误类型、错误信息和第一条 at 指向。比如这样Error: PrismaClientKnownRequestError Invalid prisma.subscription.create() invocation Foreign key constraint failed on the field: userId at Object.request (/app/node_modules/prisma/client/runtime/library.js:130:15)后面那一百行 node_modules 的堆栈删掉。它不需要看那些它只需要知道在哪个函数、什么错误、指向哪个字段。这一个习惯让我的单次响应时间平均缩短了 8 到 12 秒。技巧三用--model参数按任务选模型这条是大多数教程不告诉你的。Claude Code CLI 支持指定模型。不同任务用不同模型速度差异显著。# 快速任务改一个函数、查一个语法——用速度更快的模型 claude --model claude-haiku-4-5-20251001 帮我把这个函数改成 async/await 写法 # 复杂任务架构设计、全量代码审查——用能力更强的模型 claude --model claude-sonnet-4-6 Review 整个 payment 模块的安全性说人话就是杀鸡别用牛刀。改个变量名、写个小工具函数用 Haiku 够了而且快得多。复杂的架构决策、需要跨文件理解的 bug再上 Sonnet。这个参数我之前完全不知道一律用默认模型结果每次改个两行代码都在等半分钟。在 CLAUDE.md 里也可以固定默认行为但建议保持灵活——根据任务类型手动指定更合适。技巧四--print模式处理批量独立任务如果你有一批互相不依赖的小任务不要一个个在交互模式里等用--print参数批量处理。这个场景在出海开发里很常见比如你需要把十个组件里的硬编码文案改成 i18n key。写一个 shell 脚本#!/bin/bash # 这段脚本遍历 components 目录对每个文件单独调用 Claude Code # 每次调用都是独立的会话互不干扰避免上下文堆积 components( components/features/PricingCard.tsx components/features/TrialBanner.tsx components/features/UpgradeModal.tsx ) for component in ${components[]}; do echo Processing: $component claude --print 把 $component 里所有硬编码的英文文案替换为 next-intl 的 t() 调用key 格式用 组件名.功能.文案同时在 messages/en.json 里添加对应的 key-value保持原有文案内容不变 \ --allowedTools Edit,Write echo Done: $component done每个文件独立一个 Claude Code 调用上下文始终干净速度稳定。细节--print加上--allowedTools让它可以直接写文件不需要你确认。适合你信任输出结果的重复性任务。对于不确定的任务去掉--allowedTools让它只输出建议你来决定要不要执行。技巧五.claudeignore排除无关文件Claude Code 在读取项目上下文时会扫描目录结构。如果你的项目里有大量无关文件——比如node_modules它应该自动忽略但有时候不够彻底、构建产物、大量的测试快照文件——都会拖慢上下文加载。在项目根目录创建.claudeignore# 依赖和构建产物 node_modules/ .next/ dist/ build/ out/ # 测试快照体积大但对 Code 无帮助 **/__snapshots__/ **/*.snap # 日志文件 *.log logs/ # 本地环境配置里面也不该有密钥 .env.local .env.*.local # 大型静态资源 public/videos/ public/images/*.psd格式和.gitignore完全一样直接复用也行但根据你的项目结构做减法。说人话就是你不想让它看的文件写进这里它就不会把这些内容算进上下文。这个文件存在的事实Claude Code 的官方文档提了一句就没了。我是在源码里翻到这个逻辑才知道它支持这个特性。踩坑环节坑一以为切节点能解决慢的问题折腾了一下午响应慢的那段时间我把节点换了四五个香港、日本、美西挨个试感觉没什么区别。后来用claude /status看了一下会话状态发现我那个对话的上下文已经接近 150K token 了——基本上是我把项目里所有文件都拖进去问过一遍全积累在那了。开了个新会话写了两句交接说明响应立刻回到了正常水平。解决方案慢的时候先看上下文大小不要先怀疑网络。/status命令或者看 CLI 的 token 统计找到真正的瓶颈再对症下药。坑二把.claudeignore写错了位置完全不生效我第一次试.claudeignore的时候把它放在了src/目录下。跑了一圈发现一点用没有node_modules还是被扫描进去了。研究了半小时发现它必须放在 Claude Code 启动时的工作目录也就是你执行claude命令的那个目录通常是项目根目录。解决方案确认.claudeignore和package.json在同一层级。可以用ls -la | grep claude验证文件是否存在于正确位置。总结Claude Code 慢本质是上下文管理的问题不是工具的问题。你给它的信息越精准它越快你给它的信息越杂它越慢。五个技巧里优先级顺序是新开会话 精简报错 排除无关文件 按任务选模型 批量并行。前三个能解决 80% 的慢问题。问你一个具体的问题你现在用 Claude Code 时平均一个对话会跑多少轮才结束——是做完一个功能点就开新的还是同一个会话从项目开始一直用到上线如果是后者你觉得你的响应速度有没有随着对话变长而明显下降