前端开发

前端项目文件多、状态碎、构建链路长。Claude Code 的价值不是替你写代码，而是替你在这些琐碎的地方省时间。

前端开发是 Claude Code 用得最勤的场景之一。原因很简单，前端工程有大量重复但又不完全一样的活。加一个表单、修一个渲染 bug、升级一个大版本依赖，这些任务都符合 Claude Code 擅长的模式：需要读代码上下文，输出可执行的补丁，还能顺手把测试补上。

下面用三个具体场景把这套流程走一遍。项目假设是 React 18 + Vite + Tailwind CSS + shadcn/ui + Vitest + Playwright，如果你用 Vue 或 Svelte，把关键词替换掉即可，思路完全一样。

场景一：加一个带校验的表单组件

假设产品让你加一个 SubscribeForm 组件，收集邮箱和公司名，要求前端校验邮箱格式，非空校验公司名，提交后调用 /api/subscribe。同时要覆盖单元测试。

进入项目根目录，claude 起会话，直接把需求说清楚。

> 帮我在 src/components 下新建 SubscribeForm.tsx。要求：
> 1. 使用 shadcn/ui 的 Input 和 Button 组件，样式跟现有的 LoginForm 保持一致
> 2. 邮箱字段用 zod 校验，非法时红字提示
> 3. 提交按钮在请求中显示 loading 状态
> 4. 成功后 toast 提示，失败保留输入
> 5. 在 src/components/__tests__/SubscribeForm.test.tsx 加一份 Vitest 单测，覆盖校验、提交、错误三条路径

Claude Code 通常会先扫一遍你现有的 LoginForm.tsx，把已有的 zod schema 引用方式、shadcn 的 Input 用法、toast 组件的路径都对齐好。你会在会话里看到它连续读了几个文件的 diff 提示。

● Read(src/components/LoginForm.tsx)
● Read(src/lib/toast.tsx)
● Read(src/components/__tests__/LoginForm.test.tsx)
● Write(src/components/SubscribeForm.tsx)
● Write(src/components/__tests__/SubscribeForm.test.tsx)
● Bash(npm test -- SubscribeForm)

跑测试之前它会先让你确认 Bash 权限。测试挂了它会自己去看失败信息，改代码，重跑。整个流程结束你只需要审一遍 diff，没问题就 /commit。

加分动作

在开头这段 prompt 里加一句"参考 LoginForm 的风格"，比啥都不写有效得多。Claude Code 会主动把新组件的目录结构、命名习惯、错误处理都对齐已有代码，减少后续的 review 成本。

场景二：定位一个 useEffect 引起的重复渲染

一个 dashboard 页面刷新之后，浏览器 network 面板里同一个接口被打了三次。你自己不知道是哪个 useEffect 出的问题。

> 我在 src/pages/Dashboard.tsx 里发现打开页面时 /api/metrics 被请求 3 次，但只该请求 1 次。
> 帮我复现这个问题：先启动 vite dev，然后用 Playwright 打开 /dashboard，
> 抓 network 里的 /api/metrics 请求次数，输出出来。然后定位是哪段代码触发的重复。

Claude Code 会连续做几件事。先起一个后台的 npm run dev，接着写一段一次性的 Playwright 脚本，跑一遍，把结果拉出来。你会看到类似这样的输出。

● Bash(npm run dev &, background)
● Write(scripts/repro-metrics.spec.ts)
● Bash(npx playwright test scripts/repro-metrics.spec.ts)

复现结果：/api/metrics 被调用 3 次
- 第 1 次：Dashboard mount 时的 useEffect
- 第 2 次：AuthContext 更新 token 后触发 rerender
- 第 3 次：MetricsChart 内部 useEffect 依赖数组里包含了 fetchMetrics 引用，
         每次父组件 rerender 都会重建这个函数

到这一步问题基本水落石出。让它把 fetchMetrics 用 useCallback 包起来，或者把 useEffect 的依赖数组改成稳定引用，再跑一次脚本确认次数变回 1。修复完成后记得让它把这个复现脚本转成一个正式的回归测试，加进 tests/e2e 目录。

别只信它的定位

大模型定位 bug 有时会自信满满地指错地方。养成让它先复现、再定位、再改的习惯。如果一步就想让它直接改，容易越改越乱。

场景三：React 18 升到 19

大版本升级是最能体现 Claude Code 价值的场景，因为你要读 changelog、改代码、跑测试、改一遍构建配置，全流程都很琐碎。

> 帮我把这个项目从 React 18.3 升到 React 19。步骤：
> 1. 更新 package.json 里的 react 和 react-dom 到 ^19，同时更新 @types/react
> 2. 扫一遍代码，找出 React 19 里被移除或改行为的 API（比如 defaultProps on function components、
>    Legacy Context API、propTypes 上的 exact），列出所有需要改的位置
> 3. 逐个改掉，改完跑 tsc --noEmit 和 npm test，把出错的地方也修掉
> 4. 更新 CLAUDE.md 里对 React 版本的描述

Claude Code 会先跑 npm outdated，把包版本对齐，然后按目录做全文搜索，把 defaultProps、propTypes、ReactDOM.render 这些历史用法都圈出来。你会在会话里看到一个明确的清单。

需要修改的位置（共 8 处）：
- src/components/Card.tsx:12 使用了 defaultProps，需改为参数默认值
- src/components/Modal.tsx:34 使用了 propTypes，已不再推荐，删除
- src/main.tsx:9 使用了 ReactDOM.render，改为 createRoot
- src/utils/legacy.tsx:5 使用了 findDOMNode，需换为 ref

它会按顺序一个个改，每改完一批就跑一次类型检查和测试。这里的关键 trick 是让它把整个变更列出来之后，你先审一遍再让它动手。如果全交给它一口气改完，中间某个改动出问题，后面的 diff 会连锁污染，回滚成本很高。

Tailwind 与 shadcn/ui 的小 trick

Tailwind 和 shadcn/ui 是当下前端项目里最常见的一对组合。用好这两个的关键是让 Claude Code 理解你项目里的设计系统。

• 让 Claude Code 读 tailwind.config.ts 里定义的 theme.extend，它会知道你项目里 primary、accent 这些语义色的具体色值，写新组件时不会随便贴一个 bg-blue-500 上来。可以在 CLAUDE.md 里直接写一句"新组件颜色只能引用 tailwind.config.ts 里已定义的语义色"，它会自觉遵守。
• shadcn/ui 组件是复制到项目里而不是 npm 依赖，路径通常在 src/components/ui/。跟 Claude Code 说用 shadcn 的 Button，它会自动从这个目录里找现成的，不会去新装依赖。它也会顺手把 cn() 工具函数、cva() 变体、className 合并这些惯用写法带上。
• 想让它加一个新的 shadcn 组件，直接说跑 npx shadcn@latest add dialog，它会在权限允许时执行完命令，再把 Dialog 集成到你的目标页面。生成之后它会把这个组件的用法在 storybook 或者 examples 里补一份，方便队友后续查阅。
• 深色模式支持也可以让它一步到位，让它扫一遍 class="bg-white text-gray-900" 这种硬编码颜色，全部换成 bg-background text-foreground 这样的语义 token，深色模式无需再改一次。

Playwright 与 Cypress 的配合

Claude Code 写端到端测试时的一个常见问题是使用了脆弱的选择器，比如 page.click('.btn-primary:nth-child(2)')。避免这类问题的办法是在 CLAUDE.md 里加一条硬性规定。

## 测试规范
- 端到端测试一律用 data-testid 属性做选择器，不用 class name 或 nth-child
- 新组件如果需要被测试触达，先加 data-testid 再写测试

这条规则加进去之后，Claude Code 每次写 Playwright 或 Cypress 用例都会自觉地在组件里补 data-testid，测试稳定性会显著提升。

另一个常用的组合是让 Claude Code 边写测试边跑测试。Playwright 有 --ui 交互模式，但在 Claude Code 会话里更适合 headless 模式加 --reporter=list，它会拿到清晰的失败信息，然后自动去看 DOM 快照定位问题。Cypress 也类似，用 cypress run --spec 指定具体文件，避免每次跑全套。

如果你的项目已经有一批测试，让它先跑一遍 npx playwright test --list 或者 npx cypress list-tests 感受一下测试结构，写新用例时会更贴合你的组织习惯，包括 fixture 命名、共享 Page Object 的用法。

交给它一个完整闭环

前端场景里最好的 prompt 是加代码加测试跑测试通过前不算完，这样一个完整闭环。让 Claude Code 自己去撞测试失败、去改、再跑，比你手动传结果给它高效得多。

前端场景总结起来就一句话，把琐碎但有边界的任务打包成一个 prompt 交给它，然后审 diff。真正难的架构决策还是你自己做，但那些机械劳动全部可以外包出去。