这 20 个技巧来自大量实际使用经验，每一条都针对真实场景的痛点。
上下文管理
技巧 1：精准投喂，而不是全量读取
❌ 低效："读取整个 src/ 目录，帮我找 Bug"
✅ 高效："我怀疑问题在 UserService 的 createToken 方法，
/add src/services/user.service.ts 和 src/utils/jwt.ts，
看看这两个文件里 token 生成逻辑有什么问题"
精准投喂节省 Token、提升焦点、减少无关信息干扰。
技巧 2：.claudeignore 不只是排除 node_modules
常被忽略但应该排除的文件：
*.generated.ts # 自动生成代码，看源头就够
*.d.ts # TypeScript 类型声明，Claude 会自动推断
*.lock # 锁文件
dist/ build/ # 构建产物
技巧 3：会话很长时主动 /compact
感觉 Claude 开始「忘事」或输出质量下降，说明上下文太长了：
/compact 15 # 保留最近 15 轮对话，其余压缩为摘要
CLAUDE.md 高价值写法
技巧 4：写「做什么」而不是「不做什么」
# ❌ 低效：充满禁令
不要修改 schema，不要直接查数据库，不要改 CI 配置...
# ✅ 高效：清晰的正向规则
修改数据库 schema 前，先提交当前改动，再创建 migration 文件。
数据库查询写在 Repository 类中，通过 Service 暴露接口。
CI 配置变更需要单独 PR 并由 DevOps 审批。技巧 5：把最重要的信息放在 CLAUDE.md 顶部
Claude 读取 CLAUDE.md 时，前面的内容权重更高。 把最关键的约束（比如「严禁直接 push main」）放最前面。
技巧 6：用 CLAUDE.md 解释「为什么」
## 为什么要这样做
OrderService 使用乐观锁而不是数据库事务，
是因为历史原因（PostgreSQL Advisory Lock 有性能问题），
这是已知的技术债，不要改成事务方式，除非做了充分的性能测试。背景信息能防止 Claude 「聪明地」改掉你刻意保留的设计。
自定义命令设计
技巧 7：命令要有具体的「验收标准」
# .claude/commands/refactor.md
分析 $ARGUMENTS 文件，给出重构建议。
验收标准（必须满足才算完成）：
1. 没有新增任何 TODO 注释
2. 重构后的代码可以直接运行 npm test 通过
3. 每个提取的函数都有参数说明
4. 不改变现有的外部接口签名技巧 8：为不同场景建立命令集
.claude/commands/
code-review.md # 提交前快速审查
pre-deploy.md # 上线前检查清单
perf-check.md # 性能问题排查
security-scan.md # 安全漏洞扫描
子代理并行化
技巧 9：识别可以并行的任务
适合并行（子任务之间没有依赖）：
✓ 为 5 个独立模块各写单元测试
✓ 同时翻译 10 个文档文件
✓ 对多个接口各做一次性能分析
不适合并行（子任务有顺序依赖）：
✗ 先设计 Schema，再实现 Resolver（有顺序）
✗ 先写功能，再写测试（需要先有实现）
技巧 10：子代理任务要完全自包含
每个子代理的描述要包含全部上下文，不能依赖「主代理知道的背景」：
❌ 「帮我测试 UserService」（子代理不知道 UserService 在哪）
✅ 「读取 src/services/user.service.ts，为 createUser 方法
写完整的 Jest 测试，覆盖成功/用户已存在/邮箱无效三种情况，
保存到 src/services/user.service.test.ts」
代码审查最佳提示词
技巧 11：审查时分层次
第 1 轮（快速）：
"扫描这次改动，只报告 Critical 级别的安全漏洞和可能导致崩溃的 Bug"
第 2 轮（深度，如果需要）：
"对 src/payment/ 目录做深度审查，包括逻辑正确性、边界条件和测试覆盖"
技巧 12：让 Claude 先理解意图再审查
"这次 PR 的目的是：把同步数据库操作改成异步，提升 API 响应速度。
请在理解这个意图的前提下做 Code Review，
重点检查异步改造是否完整（有没有遗漏的地方）"
避免「过度自信」
技巧 13：对不确定的改动，让 Claude 先解释再修改
"在修改 auth.middleware.ts 之前，先解释你对这个文件的理解：
它做什么，为什么这样设计，你打算改哪里，为什么这样改更好。
我确认理解正确后，再执行修改。"
技巧 14：让 Claude 标记不确定的假设
"如果你在修改过程中做了假设（比如某个变量的含义、某个函数的行为），
请在代码注释中标注 [假设: ...]，我会逐一确认。"
Git 工作流集成
技巧 15：每次功能完成后让 Claude 写 Commit Message
让 Claude 写 Conventional Commits 格式的提交信息：
"根据这次修改的内容，生成一个 Conventional Commits 格式的 commit message，
包含 type/scope/subject，如果有 breaking change 也要标注"
技巧 16：让 Claude 生成 PR 描述
"根据以下 git diff，写一个 GitHub PR 描述：
- Summary：本次改动做了什么
- Motivation：为什么要改
- Testing：如何验证
- Screenshots：[我会自己加]"
其他高价值技巧
技巧 17：用 plan 模式探索风险
重要改动前，用 --permission-mode plan 先看方案再执行：
claude --permission-mode plan "重构 AuthService，分析改动范围和风险"
# Claude 只分析不执行，确认方案后再正式运行技巧 18：让 Claude 生成可复用的脚本
"把这个操作封装成一个 Bash 脚本，让我以后可以直接运行，
不需要每次都来问 Claude"
技巧 19：复杂问题先问「应该怎么做」
# 先问方向（便宜），确认对了再问实现（昂贵）
Round 1（用 Haiku）：
"用 3 种方式描述如何解决 [问题]，各自优劣"
Round 2（用 Sonnet/Opus，选定方向后）：
"选方案 2，帮我完整实现"
技巧 20：定期让 Claude 审查 CLAUDE.md 本身
"读取 CLAUDE.md，找出：
1. 有没有和当前代码现实不符的描述
2. 有没有已经过时的约定
3. 有没有缺失的重要信息
提出修改建议（不直接修改，我来确认）"
来源：Claude Code 官方文档 - docs.anthropic.com/en/docs/claude-code