EP03. “实战案例与使用技巧”

• 接着 EP01、EP02，用三个真实场景示范 Claude Code 实际怎么运作：修 bug、加新功能、大规模重构
• 整理一套实用的使用技巧（Tips），和几个新手容易踩的坑（Common Pitfalls）
• 前置知识：先看过 EP01（安装、CLAUDE.md、四阶段工作流程）和 EP02（Skills/Plugins/Routines），这篇是把前面学到的东西套进实际场景

重点内容

实战示例一：修 Bug

场景：

> There's a bug where the newsletter form doesn't show success state
> after submission. Users click subscribe and nothing visible happens.
（订阅表单提交后不显示成功状态，用户点了订阅但画面上什么反应都没有）

Claude 的处理过程：

1. 探索——读 newsletter 组件、表单处理逻辑、API 路由、状态管理
2. 找出问题——handleSubmit 函数调用 API 后更新的是 isSubmitted 状态，但成功讯息渲染时判断的却是另一个变量 isSuccess，两个状态变量对不上
3. 提出修法：统一用 isSubmitted 来判断，移除没用到的 isSuccess 状态
4. 实作——更新组件，清掉死代码
5. 验证——跑 build，确认没有类型错误，检查组件渲染正常

实战示例二：加新功能

场景：

> Add a reading progress bar to blog posts that shows scroll position
> at the top of the page
（给部落格文章加一个显示滚动位置的阅读进度条，放在页面顶部）

Claude 的处理过程：

1. 探索——读部落格文章的 layout、看现有组件、看用的样式方案（这个案例是 Tailwind）
2. 提出方案：做一个 ReadingProgress 组件，追踪相对文章内容的滚动位置、在视口顶部渲染一条细的固定进度条、用 Tailwind 配合现有样式风格、只在部落格文章页挂载
3. 实作——建 src/components/blog/ReadingProgress.tsx 作为客户端组件，带滚动事件监听和 CSS transform 做平滑动画，整合进部落格文章的 layout
4. 验证——build 成功，没有版面跳动（layout shift），手机上也正常

[截图：部落格文章页顶部新增的阅读进度条，滚动时随位置变化的效果]

实战示例三：大规模重构

场景：

> Consolidate the 17 blog categories down to 7. Here's the mapping:
> "AI", "Machine Learning", "Deep Learning" → "AI & ML"
> "JavaScript", "TypeScript", "React", "Next.js" → "Web Development"
> ...
（把 17 个部落格分类合并成 7 个，附上对照表）

这正是 Claude Code 真正厉害的地方——这类重构会牵涉到 55 个 markdown 文件、分类筛选组件、分类页路由、sitemap 生成器，可能还有 SEO 设置。

Claude 有条理地处理：

1. 读每篇部落格文章的 frontmatter，了解目前的状态
2. 建好对照表，跟你确认
3. 更新全部 55 个 markdown 文件的分类
4. 更新分类筛选 UI
5. 验证 build 通过、所有分类页面都能正常渲染

使用技巧（Tips）

• CLAUDE.md 要经常维护：给的项目背景（偏好的写法模式、命名规范、架构决策）越多，输出质量越好
• 会话拖长了就 /compact：工作一段时间后如果感觉回应变慢或变不准，压缩一下上下文——不会丢失重要信息
• 不简单的任务先用 Plan Mode：任务牵涉多个文件或架构决策时，按 Shift+Tab 先进规划模式——逼 Claude 先想清楚再动手，让你在写代码之前就能纠正方向

[截图：终端机 Plan Mode 底下 Claude 提出的方案文字，尚未有任何文件被改动]

• 模型要配任务：不是每件事都用最贵的"脑子"——日常代码用 /model sonnet，硬的架构或长周期任务用 /model opus 或 /model fable，快速查阅用 /model haiku——省钱，而且经常也更快
• 减少权限确认的次数：反复批准同样安全的指令（npm test、git status）的话，一次性加进 .claude/settings.json 的白名单；紧盯每个 diff 的场景下，直接切到 auto-accept-edits 模式
• 用 /context 盯着上下文，/clear 来重置：回应开始跑偏时，先查 /context 看什么占满了空间；开始一个不相关的新任务，/clear 比 /compact 更快更准（没有值得保留的东西时不用留着旧上下文）
• 独立工作交给 subagent：像"去读完 X 整个模块，告诉我它怎么运作"这种任务，丢给 subagent 处理——它在自己的上下文里挖，只把答案带回来，你的主对话不会被弄乱
• 让 Claude 自己跑 build：不要只看 diff，让 Claude 直接执行 npm run build 和 npm run test——它会立刻发现问题并在同一个会话里修好
• 信任但要查证（Trust but verify）：Claude 很强，但不是零失误——每个改动都要看一遍，读 diff，弄清楚改了什么。工具最强大的用法是配合一个投入其中的开发者一起用
• 独立任务用后台 agent：需要一边修一个分支的 bug、一边在另一个分支加功能时，后台 agent 能干净地处理这种并行——每个 agent 在自己的 git worktree 里工作，不会中途产生合并冲突

常踩的坑（Common Pitfalls）

• 别跳过审查步骤：研究显示，开发者盲目接受 AI 生成的建议时，代码引入的漏洞可能多达 2.74 倍——Claude Code 的 diff 式工作流本来就是设计来让你保持在决策回路里的，务必善用它
• 别给太模糊的指令：「让这个页面变好一点」只会得到普普通通的结果；「给部落格列表页加分页功能，每页 10 篇文章，手机上无限滚动，桌面版用数字页码」才会得到你真正要的东西——具体程度就是你的杠杆
• 别跟工具对着干：Claude 提出的做法跟你原本想的不一样时，先听听看——它见过数百万个代码库，经常会建议一些你没想到的模式。你随时可以否决，但这些建议通常值得先理解一下
• CLAUDE.md 要保持更新：换了数据库、换了框架、定了新规范，都要记得回来更新这份文件——过时的说明会导致过时的代码

常见错误

• ❌ 看到 Claude 生成的 diff 直接全部接受不细看——盲目接受 AI 建议可能引入更多安全漏洞，diff 式工作流就是设计来让你把关的，务必每次都看一遍改动
• ❌ 指令写得太模糊（比如「让这个页面变好一点」）——具体到页数、交互方式、桌面/手机差异，得到的结果才会贴近需求
• ❌ Claude 提的方案跟自己预想的不一样，直接否决不听——它见过海量代码库，提出的替代方案经常值得先理解一下再决定要不要采用
• ❌ 项目换了数据库/框架/团队规范之后，忘记回头更新 CLAUDE.md——说明文件过时，Claude 写出来的代码风格也会跟着过时
• 💡 大规模重构（比如同时改几十个文件）正是 Claude Code 最擅长的场景，手动做要几小时的批量替换，交给它可能几分钟就搞定

Sources

Blog / Website：

1. Claude Code Tutorial（Beginners Guide 2026）— https://www.techlifeadventures.com/post/claude-code-tutorial-beginners-guide-2026