新 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

Claude Code 不是"更聪明的 Copilot"，而是"需要你主动驾驭的协作伙伴"。你给它的上下文越精确、约束越清晰、任务拆得越细，它就越能帮你省时间。那些"隐藏功能"，本质上都是在教你怎么更好地跟 AI 说话。

当一个对话快到上下文上限时，在开新对话之前，让 Claude Code 做一个摘要：请用200字以内总结我们这个对话里确定的所有技术决策和已完成的实现细节，我会把这段摘要带到下一个对话继续。然后把它生成的摘要贴到新对话的开头。这个习惯养成之后，上下文丢失的问题基本消失了。