WebStorm + Claude Code：JS/TS 项目实战工作流

WebStorm 在 JS/TS 项目里有一个 Cursor 和 VS Code 都比不了的优势：完整的语义索引。Find Usages 能找到一个函数在整个 monorepo 里所有调用点（包括动态字符串引用），Rename Refactoring 是基于 AST 的精确改名，不会误伤注释和字符串字面量。这些是几十年磨出来的静态分析能力，AI 短时间内追不上。但 WebStorm 也有它的盲区：写代码、生成测试、跑命令、连续多步推理。这些恰好是 Claude Code 的主场。本文讲怎么把两者的强项叠加起来。

WebStorm 的杀手级特性 vs Claude Code

任务类型	用 WebStorm	用 Claude Code
重命名一个变量/函数/类	Rename Refactoring (`Shift+F6`)	× （AI 容易漏掉动态引用）
找一个函数所有调用点	Find Usages (`Alt+F7`)	×
提取方法 / 内联方法	Extract Method (`Ctrl+Alt+M`)	×
移动文件 + 自动改 import	Refactor → Move (`F6`)	×
看一个 union 类型展开	Quick Type Info (`Ctrl+Shift+P`)	×
跨文件批量改实现	× （要手动一个个改）	一次描述，全改完
生成测试用例	模板生成（只是骨架）	写出有意义的测试体
修一堆 TS 类型错误	× （只能点提示一个个改）	批量分析与修复
写新 feature	×	主场
看一段你不懂的代码	×	Alt+F12 打开终端问
跑测试 + 看失败 + 修复	手动	Agent 自动循环

核心原则：涉及精确重命名 / 移动文件 / 引用追踪的，用 WebStorm 菜单；涉及生成 / 修复 / 解释 / 跑测试的，用 Claude Code。

跨项目大重构：哪一步用哪个

来看一个真实场景：项目把状态管理从 Redux 迁到 Zustand。这个任务横跨 50+ 个文件，纯 AI 干风险高（漏改、引用乱），纯手工又慢。正确做法是分阶段交替：

第 1 阶段：用 Claude Code 生成新的 store

任务比较开放，让 Agent 自由写：

项目当前用 Redux Toolkit 管理用户、收藏、购物车三个 slice。
请保持业务行为不变，改写为 Zustand：
- 每个 slice 改为一个 store（lib/stores/user.ts 等）
- 复用现有的 selector 行为
- 类型签名要和原来一致，方便组件迁移
- 先不动组件，只生成新 store

Claude Code 会读完 store/、参考 Redux selector 结构、生成新的 Zustand stores。

第 2 阶段：用 WebStorm 做精确文件移动

Claude Code 生成完后，新文件在 lib/stores/，旧文件在 store/。这一步不要让 AI 改 import 路径——用 WebStorm 的 F6 (Move) 或者把旧文件直接 Delete，WebStorm 会弹窗问要不要更新所有引用。

第 3 阶段：让 Claude Code 改组件

我已经在 lib/stores/ 下放好了 Zustand 版的三个 store。
请把所有用 useSelector / useDispatch 的组件，改为用对应的 Zustand store hook。
useSelector(state => state.user.name) → useUserStore(s => s.name)
useDispatch + dispatch(action) → useUserStore(s => s.action)
完成后跑 npm test 确认。

第 4 阶段：用 WebStorm 兜底

Agent 改完后，在 WebStorm 里全局搜 useSelector、useDispatch、createSlice 还剩多少。任何 AI 漏掉的，用 Find Usages 看引用链、Quick Fix 改完。

第 5 阶段：清理 Redux

package.json 里删掉 @reduxjs/toolkit 和 react-redux，
src/store/ 整个目录删掉，
跑一次 npm run build 确认编译过。

整个流程跑下来：AI 干了 80% 的重复劳动，WebStorm 兜底了精确重命名和路径更新两个 AI 容易出错的环节。

TypeScript 类型错误批量修复流程

WebStorm 的 TS 错误显示是按文件分散的，看到一处修一处效率低。改成下面这个流程能快很多：

第 1 步：让 WebStorm 列全错误

View → Tool Windows → Problems，或者快捷键 Alt+6。这里显示项目所有 TS / ESLint 问题，按文件分组。

或者直接命令行跑：

npx tsc --noEmit > ts-errors.txt

第 2 步：把错误丢给 Claude Code

WebStorm 底部按 Alt+F12 打开终端，启动 Claude Code：

claude

我跑了 npx tsc --noEmit，错误列表保存在 ts-errors.txt 里。
请按文件分组，修复所有错误。原则：
- 优先修源头，不要到处加 any
- 如果是配置问题（比如缺 @types/xxx），直接装上
- 如果一个错误需要修改公共类型才能修，先改公共类型
- 修完每个文件都重新跑 tsc 看是否消减

Agent 会按文件分批修，每修一批跑一次 tsc --noEmit 看错误数是否下降。

第 3 步：WebStorm 复查疑难

Agent 跑完后剩下的几个特别难的，在 WebStorm 里逐个打开，Ctrl+Shift+P 看类型推断（macOS 是 Ctrl+Shift+P，Windows 是 Ctrl+Q），手工解决。

DataGrip / 数据库工具 + Claude Code 写迁移脚本

WebStorm 内置 Database 工具（和 DataGrip 同一套）。常见组合：

场景：根据现有表结构生成 Prisma migration

打开 Database 工具，连上数据库，选中表，右键 → Copy DDL。然后切到 Claude Code：

我把现有的 users 和 orders 表 DDL 贴在下面（含外键约束）。
请生成对应的 prisma/schema.prisma 模型定义，
然后跑 npx prisma migrate dev --name init --create-only 生成 migration 文件，
不要执行 migration，只生成文件，我要 review 后再决定。

[DDL paste here]

场景：根据查询日志优化索引

WebStorm Database 工具能开 SQL Log（Database 面板的钟形图标），把慢查询日志复制出来给 Claude Code：

以下是过去 24 小时的 slow query log。
请分析查询模式，给出索引建议（CREATE INDEX 语句）。
索引不要过度，每个表最多新增 3 个。
解释每个索引是为了优化哪个查询。

场景：seed 数据生成

prisma/schema.prisma 已经定义好。
请生成 prisma/seed.ts，
为 users 表创建 50 条假数据（用 @faker-js/faker），
为每个 user 创建 3-10 条 orders。
然后修改 package.json 加上 "prisma": { "seed": "tsx prisma/seed.ts" }。
最后跑 npx prisma db seed 确认能跑通。

npm scripts / Run Configurations / 调试器配合

WebStorm 的 Run Configuration 是它另一项强能力：可以保存运行参数、断点、环境变量。Claude Code 不直接操作 Run Configuration，但写完代码后让它生成对应的运行配置是个隐藏技巧。

让 Claude Code 维护 npm scripts

看一下 package.json 的 scripts 段，做以下调整：
- 加一个 "test:unit" 只跑 lib/ 下的测试
- 加一个 "test:e2e" 跑 e2e/ 下的测试
- 加一个 "check"，并行跑 lint + typecheck + test:unit
- 现有的 "dev" 加上 --turbo 参数

完成后回到 WebStorm，右上角 Run Configuration 下拉会自动识别新 script。

调试 Claude Code 写的代码

让 Agent 写完代码后，在 WebStorm 里：

在可疑的函数打断点（鼠标点行号左边）
右上角选 npm test 配置，点旁边的小虫子图标（Debug）
WebStorm 在断点处停下，看变量值、调用栈

这一步不要让 Claude Code 调试——它没法实时看变量值，只能盲改。WebStorm 调试器是真正的「单步执行 + 看值」。

把调试发现回喂 Agent

调试看到「user.permissions 应该是数组但传进来是 undefined」，回到 Claude Code 终端：

我刚在调试器里看到，调用 lib/auth.ts:42 的 hasPermission 时，
user.permissions 是 undefined（应该是数组）。
原因是 sessionUser 反序列化时丢了字段。
请定位反序列化逻辑并修复。

精确的「现象 + 行号」描述能让 Agent 直奔问题点，不用它自己瞎猜。

WebStorm AI Assistant vs Claude Code 的取舍

WebStorm 自家的 AI Assistant 是付费订阅（10 美元/月起），主要功能：内联补全、聊天框、生成单元测试、生成提交信息。

	WebStorm AI Assistant	Claude Code CLI
模型	OpenAI + Anthropic 切换	仅 Claude
项目级 Agent	有限（最近版本有了 Junie）	完整
编辑器深度集成	极深（懂 WebStorm 索引）	仅终端
跑命令	×	√
改十几个文件	△	√
单文件内补全	√	×

实际推荐：

已经用 WebStorm AI 且满意补全 → 留着，Claude Code 只用来跑 Agent 任务
没订 → 不用订，让 WebStorm 做 IDE 该做的事（重构、调试、索引），把 AI 全交给 Claude Code

WebStorm 的 Junie（2024-2025 推出的 Agent 产品）和 Claude Code 功能上有重叠，体验上 Junie 更深度集成进 IDE，但 Claude Code 在跨项目可移植性、订阅性价比、社区配置（CLAUDE.md 生态）上更强。

远程开发：JetBrains Gateway 下用 Claude Code

JetBrains Gateway 让 WebStorm 通过 SSH 连远程服务器跑 IDE backend，本地只是个瘦客户端。这个场景下 Claude Code 怎么用？

方案：把 Claude Code 装在远端

Gateway 连接后，打开远端的内置终端（Alt+F12），它已经是远端 shell：

# 在远端装 Node 和 Claude Code
nvm install --lts
npm install -g @anthropic-ai/claude-code

# 登录（OAuth 链接需要在本地浏览器打开）
claude /login

OAuth 流程会显示一个 URL，复制到本地浏览器打开授权，回调会贴 token 回远端。

配置 API key 持久化

远端如果是临时容器（Codespaces / DevPod），每次重建都要重登。改用环境变量更稳：

# 在远端 ~/.bashrc 加
export ANTHROPIC_API_KEY="sk-ant-..."

或者用 JetBrains Gateway 的项目级环境变量配置（Run/Debug Configurations → Environment Variables），把 key 传给所有终端会话。

远端 + 本地编辑器同步

Gateway 模式下文件其实在远端，本地 WebStorm UI 是镜像。Claude Code 在远端改文件，Gateway 协议会把变更同步回本地视图，但偶尔有几百毫秒延迟。如果发现 UI 还在显示旧代码：

File → Reload from Disk，或者直接 Ctrl+Shift+A 搜「Synchronize」。

长任务防断网

Gateway 连接断了不影响 Claude Code 本身。但如果 Claude Code 是在 Gateway 的内置终端里跑，终端会随 Gateway 断开而 SIGHUP 终止。长任务一定用 tmux 包一层：

tmux new -s claude
claude
# 任务跑起来后 Ctrl+B D 脱离
# 网断了重连后 tmux attach -t claude 接回去

实战搭配建议

最后一条主线：

新 feature 开工 → Claude Code 起骨架 + 生成首版实现
类型 / 引用混乱 → 切 WebStorm，Find Usages / Type Info
要改名 / 移动文件 → 必须 WebStorm，AI 不要碰
要补测试 / 修一堆错 → 切 Claude Code，让 Agent 跑循环
调试运行时问题 → WebStorm 调试器看值，把发现回喂 Agent
提交前 review → WebStorm 自带 Git 面板看 diff，Claude Code 写提交信息

WebStorm 是地基（精确、稳定、慢），Claude Code 是发动机（快、能跑、偶尔出格）。两者搭配比单独用任何一个都强。