大多数开发者打开 Claude Code，问一句"帮我写个函数"，拿到答案就走了。这跟用搜索引擎没什么本质区别。Arpan Patel 最近发布的深度指南覆盖了 12 个核心主题，核心观点很明确——Claude Code 是一个可训练、可配置、可运营的智能体，不是问答机器人。如果你只停留在"提问—回答"的循环里，等于买了一台 CNC 机床只用来切菜。
下面挑几个最影响日常效率的主题展开，配上可以直接跑的配置和命令。
把心智模型从"聊天"切换到"协作"
用 Claude Code 最常见的误区：把它当成 Stack Overflow 的对话版。你抛一个问题，它抛一段代码，结束。这种模式下你永远是被动消费者。
正确的模型是结对编程——你负责方向和约束，它负责执行和探索。区别在于：
- 聊天模式：
帮我写一个 FastAPI 的用户注册接口→ 拿到一段代码，手动粘贴，手动调试 - 协作模式：先让 Claude Code 读项目结构，理解现有模式，再让它按项目风格生成接口，并自动跑测试
第二种方式的前提是你得给它足够的上下文。Claude Code 能读本地文件、执行命令、浏览目录树，但这些能力不会自动触发——你得主动告诉它"先看什么"。
用 CLAUDE.md 把项目约束写进机器的记忆
Claude Code 启动时会自动读取项目根目录下的 CLAUDE.md，这是你给它写的行为手册。不写这个文件，每次对话它都在盲猜你的偏好。
一个实际项目中的 CLAUDE.md 示例：
# 项目规范
## 技术栈
- Python 3.11，FastAPI + SQLAlchemy 2.0
- 测试用 pytest + httpx 异步客户端
- 数据库迁移用 Alembic
## 代码风格
- 类型注解必须完整，禁止 Any
- 函数不超过 30 行，超过就拆
- API 路径用 kebab-case：/user-profile，不用 /userProfile
- 错误处理统一用自定义异常类，映射到 HTTP 状态码
## 测试要求
- 每个新接口必须带集成测试
- 测试文件放在 tests/ 下，镜像 src/ 的目录结构
- 先跑 `pytest --tb=short` 再提交
## 数据库
- 模型定义在 src/models/ 下
- 新增字段必须生成 Alembic migration，不要直接改表
- 用 `alembic upgrade head` 验证迁移
## Git
- commit message 用 conventional commits 格式
- 不要自动 commit，先让我 review
把这个文件放在项目根目录，Claude Code 每次启动都会加载。你再也不用反复说"记得加类型注解""测试用 pytest"——它已经知道了。
关键原则：写你真正会检查的规则，不写愿望清单。如果你实际从不跑 lint，就别在 CLAUDE.md 里写"必须通过 flake8"，否则它会浪费时间在你不关心的事情上。
让 Claude Code 先读项目再动手
新手直接说"帮我加个功能"，老手先让它理解现状。差别巨大——前者生成的代码风格可能和项目完全脱节，后者能复用已有的模式。
实际操作流程：
# 启动 Claude Code 后，先发这几条指令
> 看一下项目目录结构，列出主要模块和它们的职责
> 读 src/models/ 下所有模型定义，总结当前的数据模型设计
> 看 tests/ 目录，总结现有的测试覆盖范围和测试风格
> 现在按项目已有的模式，在 src/api/ 下新增一个 /notification-preference 的 CRUD 接口，
包含模型、路由、schema 和对应的集成测试
这种"先侦察再行动"的方式，生成的代码几乎不需要大改。因为它已经看到了你用 SQLAlchemy 2.0 的 Mapped 类型、你的路由注册模式、你的测试结构，它会复用这些模式而不是从零发明。
自定义 Agent：把重复流程封装成可复用工作流
指南中最有价值的话题之一。当你发现每次都在重复同样的指令序列——比如"读代码→找 bug→写修复→跑测试→提交"——就该把它封装成 Agent。
Claude Code 支持通过 .claude/ 目录下的配置定义自定义命令。一个实际例子：定义一个 debug 命令，专门用来排查和修复 bug。
在项目根目录创建 .claude/commands/debug.md：
你是一个专门排查和修复 bug 的 Agent。按以下步骤执行：
1. 读取用户描述的 bug 现象
2. 在项目代码中搜索可能相关的文件，重点关注：
- 错误信息中提到的模块名
- 最近 git commit 改动过的文件（用 `git log --oneline -10` 查看）
- 测试失败的具体断言
3. 定位根因，给出简要分析（不超过 5 行）
4. 生成修复代码，确保：
- 不引入新依赖
- 符合项目 CLAUDE.md 中的代码风格
- 修复范围最小化，不重构无关代码
5. 运行相关测试验证修复（`pytest --tb=short -x`）
6. 如果测试通过，展示 diff；如果失败，回到步骤 3
输出格式：
- 分析：[根因描述]
- 修复：[改动文件列表和 diff]
- 验证：[测试结果]
使用方式：
# 在 Claude Code 中调用自定义命令
> /debug 用户反馈：点击"保存偏好"按钮后返回 500，日志显示 KeyError 'notification_type'
Claude Code 会按你定义的流程自动执行：搜代码→定位→修→跑测试→展示结果。你只需要在最后 review diff 确认。
再举一个更贴近日常的例子——代码审查 Agent。创建 .claude/commands/review.md：
执行代码审查，关注以下维度：
1. 运行 `git diff HEAD~1` 查看最近一次提交的改动
2. 对每个改动文件检查：
- 是否有明显的逻辑错误或边界遗漏
- 类型注解是否完整
- 是否有未处理的异常路径
- 新增代码是否遵循项目 CLAUDE.md 规范
3. 检查测试覆盖：
- 新功能是否有对应测试
- 测试是否覆盖了边界情况
4. 输出审查结果，格式：
- 🔴 必须修改：[问题列表]
- 🟡 建议改进：[建议列表]
- 🟢 看起来没问题：[确认列表]
# 提交前快速审查
> /review
几个容易被忽略的效率技巧
用 --resume 续接上次对话。复杂任务往往需要多轮迭代，每次重新开对话会丢失上下文：
# 续接最近的对话
claude --resume
# 续接特定会话（先用 claude --list-sessions 查看 ID）
claude --resume abc123
用 --print 做非交互式调用。适合在脚本或 CI 中使用：
# 让 Claude Code 分析测试失败原因，输出到 stdout
claude --print "分析 pytest 的失败输出，给出修复建议" < test_output.log
用权限控制限制它的操作范围。你不希望它随意删文件或推代码到远程：
# 启动时只允许读文件和执行测试命令
claude --allowedTools "Read,Write,Bash(pytest:*),Bash(git diff:*)"
这个功能在团队协作中特别重要——你可以让 Claude Code 在 CI 环境中只做代码审查，不碰生产代码。
从问答工具到工程资产：一个渐进路线
不要试图一天就把 12 个主题全用上。按这个顺序逐步引入：
| 阶段 | 动作 | 预期收益 |
|---|---|---|
| 第一周 | 写 CLAUDE.md，每次启动先让它读项目结构 |
生成代码风格一致性提升 |
| 第二周 | 定义 1-2 个自定义命令（debug / review） | 重复流程耗时下降 |
| 第三周 | 用 --resume 处理多轮任务，用 --print 接入脚本 |
复杂任务上下文不丢失 |
| 第四周 | 在 CI 中接入 Claude Code 做自动审查 | 代码质量门禁自动化 |
每个阶段都有明确的收益，不需要等到"全部配好"才见效。
最后一点：Claude Code 的能力边界取决于你给的上下文质量。一个空的 CLAUDE.md 和一个写满项目规则的 CLAUDE.md，产出差距是十倍级别的。花半小时把你的项目约束写清楚，这笔时间投资会在接下来每一次对话中持续回报。