第 5 章：对话与代码理解

从本章开始，我们进入本书的第二篇：基础篇。在第 3 章你完成了环境搭建，在第 4 章你了解了平台生态——现在是时候真正动手使用 Claude Code 了。

基础篇覆盖 Claude Code 的四大核心能力：对话与理解、代码编辑、终端命令、Git 集成。本章是整个实战部分的起点：对话与代码理解——这是最基础、最常用、也最容易被低估的能力。

很多人以为"对话"就是打字问问题，但真正高效的开发者知道：怎么问、给什么上下文、用什么交互方式，决定了你从 Claude Code 得到的是"勉强能用的回答"还是"精准到可以立刻执行的方案"。本章的目标就是帮你建立这套对话方法论。

5.1 基础提问

当你打开 Claude Code 侧边栏，面对的是一个空白的输入框。你可以输入任何内容——从简单的一行问题到包含多段代码的复杂需求。对于初学者来说，最自然的起点就是提问。以下是五种最常见的基础提问类型，每一种都有其最佳的表达方式。

问项目

当你刚接触一个新项目、或者面对一个大型代码库时，"问项目"是你和 Claude Code 的第一轮对话。这类问题帮你建立对项目的高层认知。

这个项目是做什么的？主要用了哪些技术栈？

Claude Code 收到这个问题后，会读取 package.json（或 Cargo.toml、go.mod 等）、目录结构、README.md，然后给你一个总结。你不需要手动指定这些文件——它会自动搜索和分析。

更为实际的用法是带着具体目标去问：

这个项目的测试是怎么组织的？用的是哪个测试框架？

这个项目里有没有用到 Redis？如果有，哪些模块在用？

项目中有多少个子项目？它们之间的依赖关系是怎样的？

这些问题帮你跳过"打开几十个文件自己梳理"的阶段，直接获得结构化的答案。关键是问题要具体——"介绍项目"得到的答案往往泛泛，而"项目中有多少个子项目，它们的依赖关系是什么"会让 Claude Code 执行更精准的搜索和分析。

问代码

当你需要理解某个模块、某个函数的实现时，直接指定范围提问。

src/backend/auth/ 目录下的登录认证逻辑是怎么实现的？帮我梳理一下流程。

这个 handleSubmit 函数做了什么？它调用了哪些外部 API？

src/utils/formatDate.ts 里的日期格式化逻辑，支持哪些时区格式？

"问代码"类问题的核心原则是指定范围。不要说"认证逻辑怎么实现的"，而要说"src/backend/auth/ 目录下的认证逻辑"。范围越精准，Claude Code 读取的文件越少，回答越聚焦。对于一个有几万行代码的项目，"认证逻辑"可能分布在十几个文件中，而指定目录后它只会读相关文件。

你还可以要求特定的输出形式：

请用 Mermaid 流程图画出 POST /api/login 的完整处理流程，从请求进来到返回 token。

用表格列出 src/components/ 下所有组件的名称、Props 和职责。

问逻辑

这类问题关注的是"为什么"——代码的设计意图、架构决策的背后原因。

这段代码为什么选择用递归而不是迭代？数据量上有什么考虑？

为什么这个模块用了一个全局锁？去掉它会不会有问题？

这个配置项设计成环境变量而不是配置文件，是什么原因？

"问逻辑"是最考验 Claude Code 推理能力的一类问题。它需要不止读取代码，还要推断设计意图。为了让回答更可靠，一个有效的技巧是要求它先读再答：

先仔细读取 src/core/scheduler.ts 的完整实现，然后分析它为什么选择了时间轮算法而不是优先队列。我要知道设计上的考量，而不是简单描述代码做了什么。

这样 Claude Code 会先系统性读取文件，再给出分析，而不是凭"印象"回答。

问优化

当你怀疑某段代码存在性能问题、安全隐患、或者代码质量问题，直接问。

这个 Dockerfile 有什么可以改进的地方？比如镜像大小、缓存利用率这些方面。

这个 SQL 查询在大数据量下会不会有性能问题？帮我分析一下执行计划。

src/components/Table.tsx 渲染 10000 行数据时很卡，帮我找出原因。

"问优化"类问题的一个好习惯是给出约束条件：

帮我优化这个函数的时间复杂度，但不要改动它的公共接口签名。

帮我改善这个 Dockerfile 的缓存利用率，但不要换基础镜像——必须用 node:20-alpine。

约束条件避免了 Claude Code 给出"技术上正确但实际不可行"的建议——比如建议换一个基础镜像，但你的团队已经标准化了某个镜像。

问文档

Claude Code 能根据代码反向生成文档——API 用法、参数说明、模块概览。

帮我解释这个 API 的用法。它接受哪些参数？返回什么？有什么错误码？

帮我给 src/hooks/useAuth.ts 写一份使用文档，包括函数签名、参数说明、返回值、使用示例。

这个配置文件的每一项是什么意思？帮我加上注释。

"问文档"类问题省去了大量"读代码查用法"的时间。特别是对于没有文档的内部库和工具函数，这个能力几乎是降维打击——你不再需要在团队 Slack 里问"这个函数第三个参数是什么意思"。

5.2 上下文技巧

基础提问能力只解决"问什么"的问题。但同样的问题，给不给上下文、给多少上下文，答案质量天差地别。这一节我们讲五个关键的上下文技巧。

指定文件范围

这是最基础但最重要的技巧。对比以下两组提问：

# 模糊
看看代码，登录是怎么实现的？

# 精准
只看 src/api/ 和 src/middleware/ 两个目录，登录认证的流程是怎样的？

第一个提问下，Claude Code 可能会扫描几十个无关文件，回答冗长而飘忽。第二个提问下，它只读两个目录，回答聚焦且准确。

一个好的范围指定包含三个要素：目录/文件 + 主题 + 期望的输出形式。

只看 src/db/queries.ts 这一个文件，把所有导出的函数名和它们对应的 SQL 操作整理成表格。

引用选中代码

在 VSCode 中选中一段代码，然后打开 Claude Code 侧边栏提问——Claude Code 会自动将选中的代码作为上下文包含在请求中。你不需要复制粘贴，不需要手动说明"我在看这段代码"。

选中后你可以：

这段代码可能有什么 bug？

帮我把这段回调地狱改成 async/await 写法。

这段正则表达式是什么意思？逐行解释。

这个功能的便利性怎么强调都不过分。在传统工作流中，你需要：复制代码 → 粘贴到聊天框 → 加上"帮我解释这段代码" → 发送。有了选中即上下文，你只需要：选中 → Cmd+Shift+L → 输入问题 → Enter。两步操作，零冗余。

@文件引用

在对话中，你可以通过 @文件路径 的方式显式引用文件。这在需要跨文件讨论时非常有用：

@src/types/user.ts 这里定义的 User 接口，和 @src/api/users.ts 里实际使用的字段有哪些不一致？

@src/components/Button.tsx @src/components/Input.tsx @src/components/Modal.tsx
这三个组件都使用了 theme 变量，但来源不同。帮我统一它们的获取方式。

@ 引用是 Claude Code 的一个强大特性——它不是把文件名当字符串传给模型，而是实际读取文件内容并注入到上下文。这意味着即使文件很长、你只说了一个 @路径，Claude Code 也会拿到完整内容。

@ 引用还支持目录：

@src/hooks/
帮我检查这个目录下有没有重复的逻辑——比如两个文件实现了相似的功能。

Add to Context（添加到上下文）

在 VSCode 的文件浏览器中，右键点击一个文件或文件夹，选择 "Add to Context"——这个文件的内容就会被加载到 Claude Code 的上下文中，但你还没有发送任何消息。

这听起来像是一个微小的操作差异，但它的方法论意义很大："Add to Context" 让你先建立上下文，再提问。这意味着你可以：

将 5 个相关文件逐个 "Add to Context"
确认 Claude Code 已经有了完整的上下文视野
再提出一个需要跨文件理解的复杂问题

这种方式比"提一个问题 → Claude 自己去找文件 → 可能找漏"可靠得多。你作为开发者，比 Claude Code 更清楚哪些文件是相关的。主动添加上下文就是你在引导它看对的方向。

我们会在 5.4 节进一步展开这个话题。

打开文件感知

在 VSCode 中，Claude Code 能自动感知你当前打开的文件。如果你正在编辑 src/components/Navbar.tsx，然后在侧边栏中说：

这个组件在移动端布局有问题，帮我修复。

Claude Code 不需要你指定文件名——它知道你正在看 Navbar.tsx，自动将其内容纳入上下文。

这个能力让你的对话体验变得非常自然：看到什么问题就说什么问题，不需要额外解释"我在看哪个文件"。结合"选中代码"和"文件感知"，Claude Code 在 VSCode 扩展中的上下文感知能力远超 CLI 版本——这也是我们推荐 VSCode 扩展作为主力工具的核心原因之一。

5.3 代码解释（Explain This）

"Explain This" 是 Claude Code 在 VSCode 中最实用的右键菜单功能之一。选中一段代码 → 右键 → "Explain This"，Claude Code 会立即给出这段代码的详细解释。

它的工作方式

当你触发 "Explain This"，Claude Code 做的不仅仅是"翻译代码"：

读取选中代码：理解你要解释的具体内容
读取周围上下文：自动分析选中代码所在的文件，提取相关的函数定义、类型声明、导入语句
追踪依赖：如果选中的代码调用了其他函数或模块，Claude Code 会追踪这些依赖关系
解释逻辑：用清晰的自然语言说明代码在做什么、为什么这样写

实战示例

示例 1：解释复杂正则表达式

选中这段正则：

javascript

const EMAIL_REGEX = /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/;

触发 "Explain This" 后，Claude Code 会逐段拆解：

这段正则用于验证电子邮件地址，分为以下几个部分：

1. ^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+ 
   用户名部分，至少一个字符，允许字母、数字和常见特殊字符
   
2. @
   字面量的 @ 符号，分隔用户名和域名

3. [a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?
   域名的主标签（如 gmail），以字母数字开头，可选中间字符但不能以连字符结尾

4. (?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$
   零个或多个子域名（如 .com、.co.uk），最后到字符串结束
   
注意：这个正则不允许域名标签以连字符开头，符合 RFC 规范。

示例 2：解释复杂 SQL 查询

选中一段包含多表 JOIN、子查询、窗口函数的 SQL：

sql

SELECT 
    u.name,
    o.order_date,
    SUM(o.amount) OVER (PARTITION BY u.id ORDER BY o.order_date) AS running_total,
    RANK() OVER (ORDER BY SUM(o.amount) DESC) AS rank
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE o.status = 'completed'
  AND u.created_at > '2024-01-01'
GROUP BY u.id, u.name, o.order_date, o.amount
ORDER BY rank;

Claude Code 的解释：

这个查询为每个用户计算了订单的累计金额和排名：

1. FROM/JOIN 子句
   从 users 和 orders 表联表查询，关联条件是用户 ID

2. WHERE 过滤
   只看 2024 年后创建的用户中状态为 'completed' 的订单

3. 窗口函数 SUM(...) OVER (...)
   按用户分组、按订单日期排序，计算每个用户的历史累计消费金额

4. RANK() 窗口函数
   按累计金额降序排列，给每个用户排名

5. 结果：返回用户姓名、订单日期、累计金额、全站排名

潜在问题：GROUP BY 中含有 o.amount，如果同一日期有多笔相同金额的订单可能产生预期外的去重效果。

注意最后一句——Claude Code 不只是翻译 SQL 语法，它还指出了潜在问题。这是 "Explain This" 超出简单"代码翻译"的地方：它带有代码审查的意味。

什么时候用 Explain This 而不是直接提问

场景	用 Explain This	用对话提问
只看一小段代码	✅	❌
需要逐行解释	✅	❌
需要理解整体架构	❌	✅
需要对比多个文件	❌	✅
解释 + 给出改进建议	❌	✅

简单来说：目光所及的一段代码 → Explain This；需要跨文件追踪逻辑 → 对话提问。

5.4 主动添加上下文（Add to Context）

5.2 节我们提到了 "Add to Context"。这一节我们深入讨论这个功能的正确使用方式——很多人只在"问复杂问题前"才想起来用它，但它其实应该成为你的日常操作习惯。

Add to Context 与直接提问的区别

这两者的区别不是"多了个步骤"，而是控制权的转移：

直接提问：    你问 → Claude Code 自己去猜哪些文件相关 → 可能猜错
Add to Context：你指定文件 → Claude Code 有了完整上下文 → 你提问

Claude Code 的文件发现能力很强，但它基于的是关键词匹配和语义搜索——它可能漏掉那些"关键词不匹配但逻辑相关"的文件。而你知道哪些文件是相关的，因为你了解项目结构。

实战策略

场景：你要重构认证模块，想先全面了解现有实现。

不好的做法：

帮我梳理整个认证模块的实现。  # Claude 可能只读 2-3 个文件

好的做法：

1. 在文件浏览器中，将以下文件逐个 "Add to Context"：
   - src/middleware/auth.ts       # 认证中间件
   - src/services/authService.ts  # 业务逻辑
   - src/models/session.ts        # 数据模型
   - src/routes/auth.ts           # 路由定义
   - src/utils/token.ts           # Token 工具
   - src/types/auth.ts            # 类型定义

2. 所有文件加载后，再提问：
   "以上 6 个文件构成了项目的认证模块。帮我梳理：
    - 整个认证流程（从请求进来到 Token 生成）
    - 各文件之间的依赖关系
    - 是否有重复逻辑可以提取
    - 错误处理是否一致"

区别在于：第一种方式 Claude Code 可能只发现 2-3 个文件就给出回答，遗漏了关键的 token 工具或类型定义；第二种方式你确保了它看到了全部相关文件，回答的完整性和准确性有质的差距。

什么时候必须 Add to Context

以下场景强烈建议主动添加上下文：

跨模块分析：涉及的代码分布在 3+ 个目录中
重构前调研：需要全面理解现有实现再做变更
架构审查：需要纵览一个完整的功能模块
回答依赖于你对项目的了解：你知道相关文件在哪，但你的描述中缺乏关键词让 Claude Code 自动找到它们
复杂项目的简单任务：老项目文件多、命名不规范，自动发现容易遗漏

不要过度使用

Add to Context 不是"把整个项目加进去"。上下文窗口有限，加载过多无关文件反而会稀释关键信息。一个好的经验法则是：加 3-8 个最核心的文件，而不是 20 个可能有关系的文件。

5.5 最佳实践

本节将之前各节中分散提到的技巧，汇总为一套系统的最佳实践清单。每一条都是来自真实使用场景的教训。

把 Claude Code 当新人同事来带

这是使用 Claude Code 最核心的心法。想象一下：团队新来了一个非常聪明但对你项目完全陌生的同事。你不会对他说"帮我搞定认证模块"就转身离开——你会给他项目背景、指出相关文件、说明代码规范。

对 Claude Code 也应该这样做：

# 不好的方式
帮我加一个用户密码重置功能。

# 好的方式
帮我加一个用户密码重置功能。
背景：项目用 JWT 做认证，src/middleware/auth.ts 处理 token 验证。
用户模型在 src/models/user.ts，字段包括 email 和 passwordHash。
请参考现有的 POST /api/auth/login 端点（在 src/routes/auth.ts）的风格来实现。

多打两行字，换来的是 Claude Code 第一版代码就符合项目规范，而不是反复修改。

使用 `/clear` 开启新话题

Claude Code 的每一轮对话都携带完整的历史记录。当你从一个话题切换到另一个完全不相关的话题时，旧对话会成为"噪音"——它可能让 Claude Code 产生混淆，将旧话题的假设带入新问题。

/clear
现在帮我看看 CI 配置文件有什么问题。

养成习惯：换话题、换模块、换思路时，先 /clear。这不是每次都要做的操作——同一个功能内的多轮追问不需要清除——但当话题跨度很大时，清理上下文能显著提升回答质量。

指定文件范围

这条我们在 5.2 节已经展开讲过。这里补充一个原则：宁愿范围小一点、多问一轮，也不要在第一轮就给一个笼统的大范围。

# 第一轮
只看 src/api/ 目录，列出所有导出的路由。

# 第二轮
只看 POST /api/orders 这一条路由，追踪它从 controller 到数据库的完整调用链。

两轮精准的回答，远好过一轮模糊的回答。

要求它先读再答

当问题涉及对现有代码的分析时，明确要求 Claude Code 先读取再回答：

先仔细读取 src/core/engine.ts 的完整实现，不要跳过任何部分。然后分析它的状态管理机制——有哪些状态、状态之间如何转换、有没有死锁的可能性。

"先读取再回答"这个指令看似多余——Claude Code 本来就会读取文件——但它的作用是要求 Claude Code 在分析前完成完整的文件读取，而不是读到一半就开始推理。对于长文件、复杂逻辑，这个指令能显著减少"基于不完整信息给出结论"的情况。

渐进式提问

不要期望一个复杂问题一次问完。好的对话是螺旋式深入的：

# 第一轮：建立全局
这个模块的整体结构是怎样的？

# 第二轮：深入细节
ProcessOrder 这个函数里，第三步的库存校验逻辑，能展开讲一下吗？

# 第三轮：挑战设计
为什么库存校验要在锁内做，而不是在锁外先预检一次？

每一轮都基于上一轮的回答进一步追问。这种渐进式对话模拟了两个人之间的自然讨论——先建立共识，再深入细节，最后挑战假设。

验证理解

当 Claude Code 给出一个复杂的解释后，让它在你的监督下验证自己的理解：

你刚才说这个函数的复杂度是 O(n log n)，是哪些操作导致的？帮我标注出来。

你说这个设计模式是策略模式——帮我指出哪一部分是 Context、哪一部分是 Strategy 接口。

这不仅仅是验证 Claude Code 是否正确，也是加深你自己理解的过程。如果它不能准确地指出代码中的对应部分，说明它的分析可能有问题。

一次只问一件事

多部分问题看起来高效，实际上会降低回答质量：

# 避免
帮我：1）审查认证模块的安全性 2）优化数据库查询 3）补上缺失的测试 4）更新 API 文档。

# 应该
帮我审查认证模块的安全性。重点关注：JWT 过期策略、密码哈希方式、CSRF 防护。

一个焦点明确的问题，Claude Code 可以深入分析。四个问题混在一起，每个都只能浅尝辄止。

给出输出格式期望

当你对输出形式有明确要求时，直接告诉 Claude Code：

用表格列出 src/components/ 下所有组件，包括：组件名、文件路径、Props 数量、状态类型、是否使用了 Context。

用 Mermaid 序列图画出用户登录的完整交互流程，从浏览器输入密码到返回 JWT。

用 3 句话总结这个模块的核心设计思想，每句不超过 50 字。

指定输出格式有两个好处：一是你得到的是直接可用的结构化信息，不需要二次整理；二是格式约束反向迫使 Claude Code 做更结构化的分析。

提供反例

当你纠正 Claude Code 的错误时，附带说明原因：

不要像刚才那样把所有逻辑写在 useEffect 里。因为：
1. 返回的 cleanup 函数每次都会重新执行，容易产生竞态条件
2. 不同关注点的逻辑混在一起，难以维护
3. 不符合项目的 React 编码规范（见 CLAUDE.md）

带原因的纠正比简单地否定更有价值——Claude Code 会从原因中推导出原则，避免在类似的场景中犯同类错误。

5.6 常见对话模式

经过大量实践，我们总结出五种高频使用的对话模式。这些模式不是硬性的"命令模板"，而是思维框架——当你不知道怎么组织提问时，套用这些模式能快速找到切入点。

探索模式

适用于：你不知道不知道什么——想了解一个模块或特性的实现，但没有具体的问题。

这个项目中，用户会话管理是怎么实现的？从登录成功开始，到 token 过期为止。

src/ 目录下，哪些地方用到了 WebSocket？帮我列出文件和作用。

探索模式的特点是开放但聚焦。你不是在修 Bug、不是在加功能——你只是在"了解"。这类问题最容易犯的错误是范围太大（"介绍一下这个项目"），最有效的做法是限定一个明确的范围（"src/backend/ 中，哪些模块用了 Redis 缓存"）。

对比模式

适用于：做技术决策——在两个（或多个）方案之间做选择。

项目里有两个日期处理的地方：src/utils/date.ts 用了 dayjs，src/components/Timeline.tsx 用了原生 Date。帮我对比这两种方式在这个项目里的优劣。如果要统一，你建议用哪个？

这个项目中用了两种错误处理方式：Controller 层抛异常，Service 层返回 Result 类型。这两种做法各有什么优劣？哪种更适合这个项目？

对比模式的关键是把对比的对象限定在项目的实际代码中，而不是抽象的"A vs B"——后者能得到教科书式的对比，但前者能给你的项目带来实际指导。

清单模式

适用于：需要完整的盘点——列出所有满足特定条件的文件、函数、或模式。

列出所有使用了 useState 但没有定义对应类型泛型的文件。

帮我找出 src/ 下所有未被导出的函数——即只在自己的文件中使用、没有对外暴露的函数。

列出项目中所有直接操作 DOM 的地方（使用 document.querySelector、getElementById 等）。

清单模式是 Claude Code 的强项——它在大量文件中搜索、过滤、归类的能力远超人眼逐文件检查。利用这个模式做代码审计、技术债务盘点、或者重构前的摸底调研。

追踪模式

适用于：理解执行链路——从入口开始，追踪一个操作经过的所有代码路径。

从 src/pages/Checkout.tsx 的 handleSubmit 开始，追踪完整的下单流程：表单验证 → API 请求 → 后端路由 → Controller → Service → 数据库写入 → 返回响应 → 前端状态更新。

从 package.json 的 build 脚本开始，追踪完整的构建流程：执行了什么命令、调用了哪些工具、生成了什么产物。

追踪模式帮助你在脑海中建立"代码的执行地图"。传统的做法是手动跳转函数调用、在 IDE 里打开 20 个标签页，而 Claude Code 可以帮你一次性画出整张地图。

总结模式

适用于：建立高层认知——用最短的时间理解一个模块的精髓。

用 5 句话总结 src/core/ 目录的设计思路。每句话描述一个核心设计决策及其理由。

这个中间件系统的设计哲学是什么？用 3 个关键特性概括。

总结模式强迫 Claude Code 做"信息压缩"——从海量代码中提炼出最核心的几条原则。这不仅是帮你快速理解，也是在验证 Claude Code 是否真正理解了代码——如果一个总结只是在复述函数名和文件路径，说明它没有抓住本质。

5.7 本章小结

本章覆盖了 Claude Code 最基础却最重要的能力：对话与代码理解。以下是关键要点：

五种基础提问类型：问项目建立全局认知，问代码理解具体实现，问逻辑探究设计意图，问优化发现改进空间，问文档反向生成说明——每种都有其最佳表达方式。
上下文决定回答质量：不是"问什么问题"，而是"给多少上下文"决定了答案的水平。指定文件范围、引用选中代码、使用 @ 文件引用、主动 Add to Context、利用打开文件感知——这五个技巧是高效对话的基础。
Explain This 是最快的代码理解入口：选中代码 → 右键 → 解释。不只是翻译语法，还包括追踪依赖、指出潜在问题。适用于"目光所及的一段代码"，跨文件逻辑追踪则需要对话提问。
Add to Context 让你掌控上下文：在问复杂问题之前，主动将相关文件加载到上下文中。这比让 Claude Code 自己去猜文件可靠得多。每次添加 3-8 个核心文件，而不是 20 个。
最佳实践是一套思维习惯：把 Claude Code 当新人同事、用 /clear 分隔话题、先读再答、渐进式提问、一次只问一件事、给出格式期望、提供带原因的反例——这些习惯的积累，比任何单一技巧都重要。
五种对话模式是思维的脚手架：探索模式（了解）、对比模式（决策）、清单模式（盘点）、追踪模式（链路）、总结模式（提炼）——当你不知道怎么组织提问时，从这五种模式中选一个就能快速找到切入点。

对话与代码理解是 Claude Code 所有高级功能的基础。当你能够高效地让 Claude Code 理解你的意图、准确地回答你的问题之后，下一章我们将进入更主动的操作：代码编辑与重构——不再只是"问"，而是"让它帮你改"。

第 5 章：对话与代码理解 ​

5.1 基础提问 ​

问项目 ​

问代码 ​

问逻辑 ​

问优化 ​

问文档 ​

5.2 上下文技巧 ​

指定文件范围 ​

引用选中代码 ​

@文件引用 ​

Add to Context（添加到上下文） ​

打开文件感知 ​

5.3 代码解释（Explain This） ​

它的工作方式 ​

实战示例 ​

什么时候用 Explain This 而不是直接提问 ​

5.4 主动添加上下文（Add to Context） ​

Add to Context 与直接提问的区别 ​

实战策略 ​

什么时候必须 Add to Context ​

不要过度使用 ​

5.5 最佳实践 ​

把 Claude Code 当新人同事来带 ​

使用 /clear 开启新话题 ​

指定文件范围 ​

要求它先读再答 ​

渐进式提问 ​

验证理解 ​

一次只问一件事 ​

给出输出格式期望 ​

提供反例 ​

5.6 常见对话模式 ​

探索模式 ​

对比模式 ​

清单模式 ​

追踪模式 ​

总结模式 ​

5.7 本章小结 ​

第 5 章：对话与代码理解

5.1 基础提问

问项目

问代码

问逻辑

问优化

问文档

5.2 上下文技巧

指定文件范围

引用选中代码

@文件引用

Add to Context（添加到上下文）

打开文件感知

5.3 代码解释（Explain This）

它的工作方式

实战示例

什么时候用 Explain This 而不是直接提问

5.4 主动添加上下文（Add to Context）

Add to Context 与直接提问的区别

实战策略

什么时候必须 Add to Context

不要过度使用

5.5 最佳实践

把 Claude Code 当新人同事来带

使用 `/clear` 开启新话题

指定文件范围

要求它先读再答

渐进式提问

验证理解

一次只问一件事

给出输出格式期望

提供反例

5.6 常见对话模式

探索模式

对比模式

清单模式

追踪模式

总结模式

5.7 本章小结