我做过一个不严谨的统计：在我们团队几个开发交流群里，每周出现频率最高的求助，前三名全是 Claude Code 的报错问题。而且每次都是同样的几个错误。……这些报错不复杂，但每次出现，都能让刚上手的人卡半天——因为报错信息本身说的是英文，而且通常不会直接告诉你根本原因在哪。我自己也在这些坑里趟过。这篇文章是我的踩坑记录，按"我遇到这个报错时需要知道什么"来组织，不是 API 文档的翻译版。

让 Claude Code 做"精确打击"，而不是"地毯式轰炸"。分层读取：先目录结构，再入口文件，最后按需深挖依赖地图：改动之前，先问"谁在用它"分模块隔离：一次只做一个模块，做完验证再做下一个CLAUDE.md：给 Claude Code 一份项目说明书这些策略的本质是：主动管理上下文，而不是被动接受信息过载。你在用 Claude Code 处理大型项目时，遇到过最头疼的问题是什么？是上下文溢

新 Session。打开，把 API 路由文件也参考已加载的 API 路由文件，更新 User 相关的 TypeScript 类型定义，加上timezone字段，类型为。这一步通常很快，Claude 只需要加一行类型，但必须做——否则前端用这个类型的地方会报 TypeScript 错误。

用了一年多 Claude Code，我有个发现：用 VS Code 插件的人，大概只用到了 Claude Code 能力的一半。另一半在 CLI 里。插件模式适合"交互式"的工作——你在编辑器里写代码，遇到问题随手问 Claude。CLI 模式适合"批处理式"的工作——你需要对一批文件做同样的操作，或者把 Claude 嵌入自动化流程，或者在没有 GUI 的服务器环境里使用。这两个模式不是替代关系

不是因为 Opus 不强。是因为它强得用错了地方。你让 Opus 帮你写个表单验证，它会开始考虑边界情况、提出你没问的架构问题、给你三个方案让你选。你只是想要一个能跑的函数，它在帮你做产品决策。结果是：时间花了更多，token 烧了更多，你还得从三个方案里再做一次选择。

CLAUDE.md 的本质是：把你脑子里的隐性知识，变成它每次都能读到的显性规则。它的上限不是你有多聪明，是你愿意花多少时间把项目规则写清楚。你现在的项目里，有没有某个"不成文的规定"——比如某个文件不能动、某个库是禁忌、某种写法是团队共识——这种规定，你写进 CLAUDE.md 了吗？如果没有，你觉得是什么让你没写？

人工 Review 的上限是 reviewer 的认知边界；AI Review 的上限是你 Prompt 的具体程度。你问得越具体，它看得越深。你问得越模糊，它越是在陪你走过场。你的项目里，现在有没有某个模块你心里隐约觉得"可能有问题但一直没细看"——如果用上面那套 Prompt 去 Review，你最怕它发现什么？

它的边界不是枷锁，是一个强制你把需求想清楚的过滤器。你的需求越具体、上下文越充分，这个过滤器越透明。模糊的需求，不仅 Claude Code 搞不定，人也搞不定。你有没有遇到过"需求完全正当，但被 AI 拒绝"的情况？你当时是怎么重新描述需求的——是补充了上下文，还是换了一个方向表达？

Claude Code 慢，本质是上下文管理的问题，不是工具的问题。你给它的信息越精准，它越快；你给它的信息越杂，它越慢。五个技巧里，优先级顺序是：新开会话 > 精简报错 > 排除无关文件 > 按任务选模型 > 批量并行。前三个能解决 80% 的慢问题。你现在用 Claude Code 时，平均一个对话会跑多少轮才结束——是做完一个功能点就开新的，还是同一个会话从项目开始一直用到上线？如果是后者，

装完 Claude Code 不代表你就能"AI 编程"了，就像买了健身卡不代表你能练出腹肌。Claude Code 不是用来替你写代码的，而是用来加速你已经知道怎么做的事情。如果你连基本的 Web 开发概念都不懂，AI 生成再多代码你也看不懂为什么能跑、为什么会报错。装完这套流程，你应该能做到：30 秒生成一个标准的 API 接口5 分钟完成重复性的 CRUD 代码遇到不熟悉的库时，让 Clau