21. 最佳实践

本章你将学到

21.1 给 Claude 一种验证方式 ⭐ 最重要

这是所有实践中回报最高的一条。没有验证方式，Claude 可能写出看起来对但实际有 bug 的代码。

场景	差的做法	好的做法
函数实现	实现一个邮箱校验函数	写 validateEmail，测试：user@x.com → true，invalid → false。写完跑测试
UI 开发	让 dashboard 好看点	[粘贴设计稿] 按这个实现，完成后截图对比，列出差异并修复
Bug 修复	构建挂了修一下	构建报错如下：[错误]。修复并验证构建通过，修根因不要压错误

什么时候必须先计划：

什么时候直接做：

模糊提示 → 模糊结果。

# 差：模糊
修复登录 bug

# 好：具体
用户反馈 session 超时后重新登录失败。
错误信息：[粘贴错误]
相关代码应该在 src/auth/session.ts。
先写一个能复现问题的失败测试，再修复。

# 差：没有参照
加个日历组件

# 好：引用已有模式
参考 src/components/DatePicker.tsx 的实现方式，
按同样的 props 接口和样式系统做一个 CalendarView 组件

Claude 走错方向时立刻打断，别等它做完：

# 立刻打断
Esc  ← 打断，保留上下文

# 回滚到检查点
Esc Esc  ← 选择回滚点

# 撤销所有修改
说 "undo that" 或 "撤销刚才的改动"

# 同一问题纠正超过 2 次
/clear  ← 清空，用更好的提示重开

「反复纠错」是危险信号

如果你纠正了 Claude 两次还是不对，说明你的提示词或上下文有问题。别继续纠错——用 /clear 清空，重新从更清晰的描述开始。

上下文就像工作记忆——用完了 Claude 就开始「遗忘」。

# 任务之间清空
/clear

# 查看上下文占用
/context

# 手动压缩
/compact 聚焦于认证逻辑相关的讨论

# 长研究任务交给子代理
用 Explore 子代理分析 src/ 目录的结构，告诉我主要模块和依赖关系

Claude Code 配置得越好，你需要在每次会话里解释的就越少：

大型功能前，你自己可能都没想清楚。让 Claude 帮你梳理需求：

我想做 [功能名称]。

在写代码之前，用问题的方式采访我，覆盖：
- 技术实现方案
- 数据模型设计
- 边界情况处理
- 与现有系统的集成

专注于我可能没考虑到的难点，不要问显而易见的。
采访完后，把完整需求 spec 写到 SPEC.md。

然后开一个新会话执行 spec——干净的上下文专注实现。