给 Claude 接上 MCP 不等于它就懂你的项目——它得先调用工具才能拿到上下文。这篇讲清楚和接了 MCP 的 Claude 高效协作的六个提问技巧：建立上下文、指定工具、缩小范围、组合工具链、提问模板、目标导向，最后归纳成一条核心原则。
给 Claude 接上 MCP（Model Context Protocol）后，它就能读你的项目文件、搜代码、跑命令了。但很多人发现：明明接好了，Claude 还是答不到点上。原因很简单——MCP 只是给了 Claude「能力」，不等于给了它「上下文」。它必须先调用工具才能看见你的项目。怎么提问，直接决定它调得准不准、答得好不好。这篇讲六个提问技巧 + 一条核心原则。
先理解一件事：Claude 不会「自动知道」你的项目
这是所有技巧的前提。MCP 注册成功 ≠ Claude 已经读过你的代码。它和你一样，第一眼什么都看不到，只有当它主动调用 list_files、get_module、search_code 这类工具时，对应内容才会进入它的上下文。
所以本质上你是在和一个**「会用工具、但每次都从零开始看项目」的协作者**对话。下面六个技巧，全都是围绕「怎么帮它又快又准地拿到对的上下文」展开的。
技巧 1：开场先让它建立上下文
第一轮对话，别急着提需求，先让 Claude 主动探索项目，建立全局认知：
✅ 好的开场
"用 list_files 看一下项目根目录结构"
"用 get_project_info 了解这个项目的依赖和脚本"
"用 get_structure 列出所有 sections 和 components"不要假设它已经知道结构。先给它一个「鸟瞰」，后面的对话才有共同的地图。
技巧 2：明确指定用哪个工具
Claude 能自己判断该调哪个工具，但你点名指定会更高效——省去它来回试探的轮次：
❌ 模糊（它可能多次试探）
"帮我看看 upload 组件怎么实现的"
✅ 明确（一击命中）
"用 get_module 读取 src/components/upload，告诉我它的 props 接口"明确 = 指定工具 + 指定目标对象 + 指定你想要的产出。
技巧 3：缩小范围，避免被截断
MCP 工具的返回会进入上下文，输出有长度限制——范围太大要么被截断，要么白白吃掉大量上下文。提问时主动收窄：
❌ 容易被截断
"搜索所有用到 axios 的地方"
✅ 更精准
"用 search_code 在 src/api 目录搜 axios，ext 限定 ts"
✅ 读大文件时指定行范围
"read_file 读 src/app.tsx 的第 1–50 行，看 Provider 嵌套结构"收窄的三个维度:目录范围、文件类型(ext)、行范围。范围越小,结果越准,上下文越省。
技巧 4:把复杂任务拆成工具调用链
大任务别指望一句话搞定,显式地拆成一串工具调用,Claude 会顺着你的链路走:
"我想给项目加一个新的 section:
1. 先用 get_structure 看现有 sections 的目录结构
2. 再用 get_module 读一个简单的 section 作参考
3. 然后帮我生成新 section 的代码"「先看结构 → 再读参考 → 最后生成」是一条典型的链:先建立认知,再动手产出。
技巧 5：常用场景的提问模板
把高频场景固化成模板，照着填就行：
| 场景 | 提问方式 |
|---|---|
| 了解某功能怎么实现 | 用 get_module 读取 src/sections/xxx，解释它的实现逻辑 |
| 查某个 API 的用法 | 用 search_code 搜 useRouter，ext 限定 tsx |
| 修改配置 | 用 get_config 读 vite.config.ts，我想加一个 proxy |
| 检查类型定义 | 用 read_file 读 src/types/user.ts，列出所有接口 |
| 构建报错 | 用 run_yarn 执行 build，把错误信息给我分析 |
| 仿照现有组件写新代码 | 用 get_module 读 src/components/upload 作参考，帮我写一个类似的 ImagePicker |
这里的工具名是示例（来自一套项目级 MCP）。换成你自己接的 MCP，把工具名替换掉、思路照搬即可。
技巧 6：描述目标，让 Claude 自主决策
前面几招是「你指挥它用哪个工具」。当任务复杂、你也不确定该怎么拆时，可以反过来——只描述目标，把工具编排交给 Claude：
✅ 目标导向（推荐用于复杂任务）
"我想在项目里加 JWT 刷新 token 的逻辑，
帮我找到现有的 auth 实现，分析后告诉我该改哪些文件"这时 Claude 会自己组合工具链：
flowchart TD
G["你只给目标
「加 JWT 刷新 token」"] --> C["Claude 自主编排"]
C --> T1["get_structure
看 auth 目录"]
T1 --> T2["get_module
读 auth 实现"]
T2 --> T3["search_code
找 token 相关代码"]
T3 --> R["综合分析 → 给出改动方案"]
style C fill:#dbe9ff,stroke:#2563eb,stroke-width:2px
style R fill:#d6f5e3,stroke:#1f9e57
关键判断：什么时候「指定工具」，什么时候「给目标」
技巧 2（明确指定）和技巧 6（目标导向）看似矛盾，其实是光谱的两端，按任务确定性来选：
| 明确指定工具（技巧 2） | 目标导向（技巧 6） | |
|---|---|---|
| 适用 | 你清楚该看哪个文件/调哪个工具 | 任务复杂、你也不确定从哪下手 |
| 优点 | 一击命中、轮次最少、最省 token | 省心，让模型发挥编排能力 |
| 代价 | 你得先想清楚 | 可能多绕几轮工具调用 |
| 一句话 | 简单、确定的任务用它 | 复杂、探索性的任务用它 |
注意它和「缩小范围」（技巧 3）不冲突：哪怕目标导向，也该在提示里给出范围线索（「只在
src/auth下找」），帮 Claude 少走弯路。
这其实就是一个 ReAct 循环（推理 → 调工具 → 观察 → 再推理）——只不过你通过提问，决定了是「自己掌舵每一步」还是「交给模型自动驾驶」。关于 Agent 的这套循环，可以看 AI Agent 开发入门 那篇。
核心原则
把六个技巧浓缩成一句:你不是在「问一个已经懂项目的人」,而是在「指挥一个会用工具、但每次从零看项目的协作者」。由此推出三条:
- 先给上下文,再提需求——它得先调工具才能「看见」,别让它瞎猜。
- 能缩小就缩小——目录、文件类型、行范围,范围越小,越准越省。
- 任务确定就点名工具,任务模糊就给目标——简单的你掌舵,复杂的交给它编排。
把这三条变成习惯,MCP 才真正从「接上了」变成「用顺了」。